Field guideNo. 05
Shutting down OTP bots: a fraud team’s field guide
OTP bots automate the call that talks a customer into reading out their code. The durable fix is removing the code; until then, context, timing and customer education narrow the window.
The short answer
How can banks stop OTP bot attacks?
The durable fix is to remove the code the bot asks for, using passkeys, in-app approval on a registered device or network-based verification. While codes remain, say in every message what the code approves and that the bank will never ask for it, and treat a new-device sign-in during an inbound call as a strong fraud signal.
If you read nothing else
- OTP bots work because a one-time code can be used by whoever has it.
- Removing the code removes the thing the bot asks for.
- Message context and timing signals narrow the window while codes remain.
- Expect criminals to pivot to scams where the customer authorizes the payment.
How the attack runs
- The criminal already has the victim’s username and password, usually from a breach or a phishing page.
- They start a sign-in or payment, which makes the bank send the victim a one-time passcode.
- At the same moment, the bot calls the victim, claims to be the bank’s fraud team, and asks them to “confirm” the code they just received.
- The victim reads it out or types it into the keypad, and the bot passes it straight to the criminal.
The call arrives exactly when the real code does, which is what makes it convincing. And a one-time passcode has no way of knowing who is typing it in or where: it works for anyone who has it within its validity window.[1]
Step 1 Remove the code where you can
Passkeys, in-app approval on a registered device and network-based verification leave the customer nothing to read out. Start with the flows bots target most: sign-in from a new device, new payees and payment step-up. NIST treats SMS and voice codes as restricted authenticators and expects organizations that keep them to offer an alternative.[3] See our field guide to moving off SMS OTP.
Step 2 Put the context in every code message
If a code is unavoidable, make the message do some of the defending:
- Say what the code approves: “to add payee J. Smith”, not just “your code is 123456”.
- Say who will never ask for it: “We will never call you to ask for this code.”
- Keep it short enough to read on a lock screen, where most customers will see it.
Step 3 Use timing as a signal
A sign-in from a new device while the customer is on an inbound call is a strong fraud signal. If your app or data providers can tell you the customer is on a call, feed that into the decision to send or accept a code. [YOUR DATA: which call-state or device signals your platform exposes]
| Signal combination | Suggested response |
|---|---|
| New device + code requested + customer on a call | Hold; confirm in-app on the registered device |
| New device + new payee within minutes | Hold the payment; step up outside SMS |
| Several code requests in a short window | Throttle and alert the customer in-app |
Step 4 Teach customers one rule
“The bank will never ask you for a code” only works if the bank never does. Audit your own contact-center and collections scripts for any step that asks a customer to read out a code, and remove it before you tell customers the rule.
Step 5 Prepare for the pivot to authorized payments
When the code is gone, the same callers can talk customers into sending a payment themselves. Strong authentication doesn’t help there: it confirms that the customer made the payment, which is exactly the problem. In the UK, payment firms have had to reimburse most victims of authorized push payment scams on Faster Payments since October 7, 2024, up to £85,000 per claim, with the cost shared between sending and receiving firms.[2] See our dispatch on the UK rules.
What each control stops
| Control | Stops | Doesn’t stop |
|---|---|---|
| Passkeys | Code relay; look-alike phishing sites | Scams where the customer authorizes a payment |
| In-app approval on a registered device | Code relay | Customers talked into approving a request |
| Context in code messages | Some social engineering | Determined or rushed customers |
| Timing and call signals | Real-time relay during a call | Attacks that don’t coincide with a call |
Who owns this
| Activity | Fraud & risk | Product | Security eng. | Support | Compliance |
|---|---|---|---|---|---|
| Removing codes from bot-targeted flows | C | A/R | R | I | C |
| Code message wording | C | A/R | I | C | C |
| Timing and call-signal rules | A/R | C | R | I | I |
| Script audit and customer rule | C | C | I | A/R | C |
| APP scam controls | A/R | R | C | C | C |
Questions readers ask
What is an OTP bot?
An automated calling or messaging service that impersonates a bank or other service and persuades the victim to read out or type in a one-time passcode, which the criminal uses at the same moment.
Does a longer or more complex code stop OTP bots?
No. The bot doesn’t guess the code; it asks the customer for it. Any code the customer can read out can be relayed.
Will removing codes end phone-based fraud?
No. Criminals can move to scams in which the customer authorizes a payment themselves, which strong authentication doesn’t stop.
Sources
- BankInfoSecurity One-time passcodes are gateway for financial fraud attacks (2026-04-03)
- Payment Systems Regulator PS24/7: Faster Payments APP scams reimbursement requirement: confirming the maximum level of reimbursement
- NIST SP 800-63B-4: Authentication and Authenticator Management
Changelog
- : First edition, assembled from Tradecraft’s sourced explainers. Awaiting editorial verification.
Cite this
Tradecraft. “Shutting down OTP bots: a fraud team’s field guide.” Tradecraft, September 24, 2026. https://glide-tradecraft.pages.dev/field-guides/otp-bot-defense/
Read next
Explainer
Why OTP bots keep working against bank customers
An OTP bot is an automated calling or messaging service that impersonates a bank or other service and persuades the victim to read out or type in a one-time passcode, which the criminal uses at the same moment to log in or approve a payment.
Dispatch
What the UK’s APP fraud reimbursement rules changed for fraud teams
Since October 7, 2024, UK payment service providers must reimburse most victims of authorized push payment scams on Faster Payments, up to £85,000 per claim, with the cost split between the sending and receiving firms.
Field guide
Moving a bank off SMS OTP: the field guide
Inventory every flow that sends a code, write the risk assessment NIST SP 800-63B-4 asks for, fix account recovery and new-payee setup first, then move customers to phishing-resistant or device-bound methods such as passkeys and in-app approval. Keep SMS only as a restricted fallback, with a dated plan to remove it.
Take the checklist
Checklist
OTP bot hardening
Controls that narrow the window for code-relay attacks while codes remain.