AI voice agents for OTP and identity verification callbacks confirm a sign-in, account change or payment your system already flagged. On the callbacks you place, the agent names the bank and asks only for a yes or a no, with no personal details and no code. Proof that the customer holds the phone comes from approval in your app.
Key Takeaways
- The callback you place asks "was this you" and never asks for a code.
- Your app, where the customer taps approve or deny, proves they hold the phone.
- A spoken code stays in the transcript and recording after the call.
A bank that asks for a one time code on its own callbacks undoes the warning customers hear most. We cover which events earn a callback, the yes or no call from Dograh, when a spoken code still fits and what follows a no. It is part of our guide to KYC and identity calls.
Which events get a confirmation callback
A confirmation callback follows an event your risk system already saw and did not like. The common ones are a sign-in from a new device, a new payee added to an account, a transfer far above the customer's usual amount, and a change of phone number or email. Each is a moment when someone other than the customer could be in control.
The losses behind these checks are large. The Federal Reserve's household survey estimated fraud outside credit cards at $100 billion in 2025, with $56 billion of it borne by consumers. Account takeovers and pushed payments sit inside that figure, and a short call at the right moment can stop one before the money moves.
Card transactions are a separate call with their own script. Fraud alert callbacks for card payments covers that one. This post covers logins, account changes and step-up checks before a payment goes out.
The default call: was this you?
The callback starts in your system. When a rule fires, your risk system calls the API Trigger with the number on file and the event in the context, such as "sign-in from a new Android phone". Calling the number on file, never a number given in the session, is what makes this a separate channel. The guide to API-triggered calls covers the setup in full.
The Greeting Text names the bank in fixed words, and the agent says the call is about a sign-in or account change the bank wants to confirm. It asks for no personal details and no code. The call reveals nothing from the account, so whoever answers learns nothing, and the device and time stay in the context for your records. The agent then asks whether it was the customer, and waits for a yes or a no.
An HTTP API tool sends the answer to your risk system, which clears the event or blocks it. For proof that the customer holds the phone, your app sends an approve-or-deny prompt during the call and the agent asks the customer to tap it. On every call you place, that tap is the check. Nothing secret crosses the call, and the app's answer goes straight to your system.
Open Source Alternative to Vapi / Retell
Self-hosted voice agent platform — no per-minute fees
dograh-hq/dograh
Star on GitHub
Why the agent never asks for the code
The strongest reason is what customers have been taught. The FTC's advice to consumers is that no real caller from a bank will ever ask for a verification code. A bank whose own calls ask for one undoes that lesson, and scammers make the same request in the same tone.
Phone-network codes are also weaker than they look. NIST's digital identity guidance restricts codes sent over the phone network, asks that a safer alternative be offered, and points to SIM changes and number porting as risk signals before one is sent. NIST writes the standard for federal agencies, and banks often treat it as a benchmark rather than a rule. A SIM swap moves the customer's number to a fraudster's phone, so a code sent there proves nothing.
The caller's voice is no proof either. Federal Reserve Governor Michael Barr warned that voice-based identity checks may become vulnerable to generative AI tools. The yes or no carries weight because the app approval sits beside it, never because the voice sounded right.
When your flow needs a code read back
Some flows still use a spoken code, and they belong on calls the customer starts, for example a customer without your app who rings to approve a transfer. On those inbound calls the agent first runs your full check, such as date of birth plus the last digits of the account number. Then it captures the code by voice, since callers answer by voice throughout. It can be an HTTP API tool parameter the agent fills from what the customer said and sends to your verify endpoint, or a value taken with variable extraction, which you turn on with Enable Variable Extraction in the agent's settings. The tool route is better, because your endpoint checks the code and returns only match or no match.
Count the costs before you build it. The code lands in the transcript and in the recording, and transcripts are always kept with nothing masked. Recording can be switched off only for a whole self-hosted server. Speech-to-text can also mishear digits, so a correct code can fail and the customer has to repeat it.
If you go ahead, make the code single-use and short-lived, tied to this one event, and send it only from your own system after the check passes. Offer the app approval first on every call, and keep the spoken code for customers who have no other option. Calls you place stay on app approval.
Join the Dograh Community
Dograh is an OSS alternative to Vapi. Join our Slack community for queries, releases, best practices & community interactions.
When the answer is no
A "no" is the answer this call exists for. The agent sends it to your system first, and your system locks the session or holds the payment straight away. Then the customer needs a person.
Transfer Call works on Twilio, Telnyx, Plivo, Cloudonix and Asterisk ARI. Your fraud analyst's phone rings first, and the customer joins only after the analyst picks up. On Twilio, the agent can also tell both of them out loud who is joining before the line opens. No summary is sent by default, so the HTTP API tool writes the event and the answer to your case first. Where the bank calls from Exotel or Vobiz numbers, the agent records a request for the fraud team to call the customer back. The agent can also ask the customer to call the number on the back of their card, a line they already trust.
Your security and compliance teams decide which events get a call and whether any flow may ask for a code. Confirm that design with counsel before the first live callback.
Glossary
- Out-of-band verification
- Confirming something through a second channel, such as a call to the number on file or an approval in the bank's app. It works only when the second channel was not given by the person being checked.
- Step-up verification
- An extra check before a risky action, such as a large transfer or a new payee. The callback asks whether the customer started it, and the app can hold the proof.
- SIM swap
- Moving a customer's phone number to a new SIM card, often by fraud. After a swap, codes sent by text or voice reach the fraudster, which is why NIST treats SIM changes as a risk signal.
- Variable extraction
- A Dograh setting that pulls values from the conversation into the call's data. It is an AI step, so a spoken code captured this way can be misheard and stays in the transcript.
