Voice AI for OTP Verification and Payment Reminder Calls in India 2026: Flows, Fraud Risk and the Compliance Stack
The fraud team at a mid-sized NBFC pulled a recording in March and played it for the collections vendor. An outbound agent had called a borrower, asked her to confirm her identity, and then asked her to read out the six-digit code that had just landed on her phone. She read it out. The call was legitimate. Every part of it was logged, consented and DLT-scrubbed.
That was the problem. The NBFC had spent eighteen months telling customers that nobody from the bank will ever ask for an OTP, and its own collections stack had just spent forty seconds teaching one customer the opposite. Multiply by 40,000 calls a month and you are running the highest-volume phishing training programme in your district, at your own expense.
This is the part of voice automation that nobody demos. Verification and payment reminders are the two highest-volume outbound flows in Indian financial services, they sit next to each other in almost every deployment, and the seam between them is where both fraud losses and regulatory exposure concentrate.
What this post argues
An AI voice agent should deliver a one-time passcode and should almost never collect one by voice. That single rule reshapes the architecture: identity confirmation moves to DTMF keypad entry or to a callback on the registered number, OTP delivery becomes a fallback channel rather than a primary one, and payment reminders get separated from authentication so that a compromised reminder call cannot escalate into an account takeover. This post covers the flows that work in Indian conditions, the DTMF and telephony mechanics that break them, the TRAI and RBI constraints that govern both, realistic numbers for connect and completion rates, and the seven failure modes that show up in production but never in a pilot.
Why this changed in 2026
For most of the last decade, SMS OTP was the default second factor in India and voice was the ugly fallback nobody planned for. Three shifts moved voice from afterthought to design decision.
Authentication stopped being SMS-only by regulation. The Reserve Bank of India has been steadily widening the definition of an acceptable additional factor of authentication beyond the SMS OTP, opening the door to authentication approaches that are not tied to a text message arriving on a specific handset. The practical consequence for anyone building outbound flows is that "we send an SMS OTP" is no longer the automatic answer, and the alternatives have different failure profiles. The RBI's payment systems and authentication material is the primary source your compliance team will want to work from.
Transactional voice got its own numbering series. TRAI's move to the 1600 series for transactional and service voice calls means the phone number a verification call originates from is now itself a trust signal, and one that customers are being actively taught to recognise. A verification call placed from a random ten-digit mobile number in 2026 reads as fraud to an increasingly large share of the population, which is exactly what it was designed to do. If you have not migrated, start with our breakdown of the TRAI 1600 series rollout and cooperative bank deadlines.
Voice fraud got cheap. Synthetic voice cloning that used to need a lab now needs a laptop and thirty seconds of reference audio. Any flow whose security rests on the customer believing the caller sounds legitimate is already obsolete. We covered the downstream trust problem in AI voice deepfakes and caller trust in India.
Put together: the channel is more capable, more regulated, and more attacked than it was two years ago. The design has to reflect all three.
Deliver versus collect: the rule that shapes everything
There are two entirely different operations that get lumped together under "OTP verification on a call", and conflating them is the root of most bad designs.
Delivery means the system reads a code to the customer, which the customer then enters somewhere else: an app, a web checkout, an IVR. The customer is the recipient. Risk is moderate and manageable.
Collection means the system asks the customer to supply a code that was sent to them through another channel, to prove they are who they claim to be. The customer is the source. Risk is severe, because the request itself is indistinguishable from the most common vishing script in India.
| Operation | Who holds the code | What the customer does | Fraud exposure |
|---|---|---|---|
| Voice OTP delivery | Your system generates it | Listens, enters it elsewhere | Moderate: call interception, voicemail capture |
| Spoken OTP collection | Customer's handset receives it | Reads it aloud to the agent | Severe: trains customers to disclose codes on calls |
| DTMF OTP collection | Customer's handset receives it | Types it on the keypad | Low to moderate: no audio disclosure, no agent exposure |
| Callback verification | No code at all | Calls the registered number back | Low: possession proven by the callback itself |
The operating rule that has held up across Indian deployments: never build a flow whose success depends on a customer reading a secret aloud to an inbound or outbound caller. Not to a human agent, not to a bot. Use DTMF, use a callback, use an app push, or restructure the flow so it does not need authentication at that step.
The objection you will hear from operations is that DTMF has lower completion than speech. That is true and it is worth it. The difference is a few percentage points of completion against a systemic fraud exposure that compounds across your entire customer base.
The mechanism: how a verification call actually runs
Here is the end-to-end shape of a verification-plus-reminder flow that survives contact with Indian telephony and Indian regulators.
Step 1: Pre-dial eligibility
Before the dialer touches the number, four checks fire:
- Consent check. Is there a purpose-bound consent record covering this specific communication? Under the DPDP framework, blanket consent captured at onboarding does not automatically cover a collections call two years later. Our DPDP compliance checklist for voice AI walks through what purpose-binding means in practice.
- DLT and preference scrubbing. Scrub at dial time, not at queue-build time. A list built on Monday and dialled on Thursday is a compliance incident waiting to be audited.
- Number hygiene. Is this the registered number of record? Verification against a number the customer changed eight months ago is not verification.
- Frequency cap. How many times has this customer been called this week, across all campaigns, including the ones run by other teams? This is the check most organisations skip because it requires a shared counter.
Step 2: Identification without authentication
The agent opens by identifying itself and the institution, states the purpose, and discloses recording. It does not ask the customer to confirm anything sensitive yet.
The critical design point: the opening must let a customer who suspects fraud exit safely and verify independently. That means naming the institution, giving a reference number, and telling the customer they can hang up and call the official number on the back of their card. Vendors resist this because it depresses completion. It also depresses the fraud losses you are not currently attributing to your own outbound programme.
Step 3: Possession proof
This is where the design forks based on what you actually need.
If you need to prove the customer holds the registered handset, the cleanest mechanism is DTMF entry of a code you have just pushed via SMS or app notification. The customer types, the system validates, nobody speaks a secret. Expect entry to take 12 to 20 seconds including the pause where the customer switches to their messages and back, and design your timeout accordingly. A four-second DTMF timeout will fail most real users.
If you need lower friction and the risk tier allows it, use a callback: end the call, invite the customer to dial your 1600-series number, and treat the inbound call from the registered CLI as the possession proof. Completion drops sharply, but for high-value actions the drop is the point.
If the action is low risk, do not authenticate at all. A payment reminder that discloses no account details and asks for no action beyond "your instalment is due" needs no second factor, and adding one is friction you are paying for with completion rate.
Step 4: The payment reminder branch
Once identity is settled, or deliberately not required, the reminder itself runs. The structure that performs best in Indian collections:
- State the amount and the due date. Nothing else first.
- Offer the payment path immediately, not after an explanation.
- Branch on intent: will pay now, will pay later with a date, disputes the amount, cannot pay.
- For "will pay now", push the payment link over SMS or WhatsApp while the customer is still on the call. The link arriving during the call converts materially better than the same link arriving after.
- For "will pay later", capture the date and set the follow-up. A promise-to-pay with a specific date is worth several times a vague assurance.
- For "disputes" or "cannot pay", route to a human. Do not let the bot negotiate.
The detailed version of this flow, including the timing windows that matter, is in our EMI payment reminders use case.
Step 5: Disposition and audit
Every call writes a record that can answer, months later: what consent covered this, what was said, what the customer agreed to, what channel the payment link went out on, and who could access the recording. If your stack cannot reconstruct that from a single reference number, you do not have an auditable programme, you have a call log.
What goes wrong
Seven failure modes account for most of the damage in production.
The bot asks for the OTP. Already covered, and still the most common. It usually enters the system not through the main flow but through an edge case: an escalation path, a retry branch, or a script someone added for "when DTMF fails". Audit every branch, not just the happy path.
DTMF does not reach the platform. This is the single most common technical failure in Indian deployments. In-band DTMF tones get mangled by codec transcoding, particularly when the call traverses multiple carriers or when a low-bitrate codec is negotiated. The fix is out-of-band signalling, and the time to confirm your telephony partner supports it end to end is before the pilot, not during it. Our telephony integration notes cover what to ask.
Timing windows are ignored. Outbound answer rates in India concentrate between roughly 11am and 1pm and again between 5pm and 8pm. Hindi-belt borrowers in particular do not pick up before 10:30am. A verification campaign that dials at 9:15am because that is when the batch job finishes will show a connect rate that has nothing to do with your platform quality.
Voicemail and call-forwarding capture the code. If your flow reads a code aloud and the call is forwarded or answered by voicemail, the code is now sitting in a mailbox. Any delivery flow needs answering-machine detection and a hard rule: no code is spoken until a human answer is confirmed.
The number of record is stale. Tier-2 and tier-3 numbers churn considerably faster than Tier-1. A verification call to a recycled number is not a failed verification, it is a disclosure of your customer's name and outstanding amount to a stranger. Re-verify the number of record on a schedule, and never state an amount before possession is proven on medium and high risk flows.
Language handling collapses outside the demo. "Hindi" in a vendor demo is Delhi Hindi. Real collections books hit Bhojpuri-influenced Hindi in Patna, Marwari-influenced Hindi in Jodhpur and Awadhi around Lucknow, and word error rates on those run roughly 1.6 to 2.4 times the demo figure. For digit recognition specifically this matters enormously, which is another argument for DTMF: a keypad has no accent.
Frequency caps are per-campaign, not per-customer. Collections calls the customer on Tuesday, the renewal team on Wednesday, the cross-sell team on Thursday. Each team is inside its own limit. The customer experiences harassment and, increasingly, reports it.
The numbers
Realistic ranges from Indian outbound deployments. Treat these as bands to design against, not guarantees.
| Metric | Typical range | Notes |
|---|---|---|
| Connect rate, verification calls | 38% to 62% | Higher within the 11am to 1pm and 5pm to 8pm windows; 1600-series CLI lifts this |
| Human answer (not voicemail) | 72% to 88% of connects | Answering-machine detection accuracy is the swing factor |
| DTMF entry completion | 61% to 79% of human answers | Depends almost entirely on timeout generosity |
| Spoken digit capture accuracy | 84% to 95% | Falls hardest on regional Hindi variants; the reason to prefer DTMF |
| Payment reminder to promise-to-pay | 22% to 41% | Higher when the payment link goes out during the call |
| Promise-to-pay to actual payment | 48% to 67% | Specific-date promises convert far better than vague ones |
| Escalation to human | 9% to 18% | Anything under 5% usually means the bot is refusing to escalate |
Two of these deserve comment. DTMF completion in the low 60s is a configuration problem, not a ceiling. Teams that widen the timeout to 20 seconds, repeat the prompt once, and allow the customer to press a key to hear it again routinely land in the mid to high 70s. Escalation rates below 5% are a red flag, not an efficiency win. It almost always means the bot is looping on customers who asked for a human.
On cost, the useful unit is not per minute. It is cost per verified contact and cost per rupee recovered. A flow with a 20% lower per-minute cost and a 30% lower completion rate is more expensive on both.
Build, buy, or split the difference
Build in-house when verification is your product. If you are a payments company and authentication flows are core intellectual property, owning the state machine and the fraud logic is worth the engineering cost. You will still buy telephony.
Buy a platform when verification and reminders are operations, not product. The integration surface, the DLT plumbing, the recording retention and the regional language handling are all things that look simple and are not.
The split that usually works: own the risk decisioning and the code generation, buy the conversational layer and telephony. Your fraud team keeps control of what triggers a step-up; the platform handles the call.
Questions worth asking any vendor:
- Do you support out-of-band DTMF end to end, and can you demonstrate it across two carriers?
- How do you detect answering machines, and what is your false-positive rate on Indian carriers?
- Can you show me a call where the customer interrupted mid-prompt and the bot handled it?
- Show me word error rate on my audio, from my collections book, not your demo set. Demo audio is choreographed. Ours is a borrower on a moving bus in Kanpur.
- What is your DLT scrub timing: at queue build or at dial?
- Where do recordings live, for how long, and who can pull them?
The vendor evaluation framework we use for regulated buyers is in the voice AI vendor selection framework for banks and NBFCs.
Compliance and regulatory considerations
Four regimes touch these flows simultaneously.
TRAI. Commercial communication rules govern consent, preference registration and the distinction between promotional and transactional or service communication. Payment reminders to an existing customer about an existing obligation generally sit on the transactional side, but the moment a reminder carries an upsell it changes character. The migration to the 1600 numbering series for transactional voice is the operationally significant change. TRAI's current framework documents are at trai.gov.in.
DPDP. Consent must be purpose-bound and revocable, notice must be meaningful, and retention must be justified. Call recordings containing financial information are personal data with real retention consequences. The Ministry of Electronics and IT publishes the Act and subsequent rules.
RBI. For regulated entities, the Fair Practices Code governs collections conduct: permitted hours, prohibition on harassment, escalation and grievance routes. Authentication requirements govern the verification side. Both are enforceable against you regardless of whether a bot or a human made the call. Master directions are indexed at rbi.org.in.
Sector overlays. Insurance flows pick up IRDAI conduct requirements including recording disclosure; see the IRDAI-compliant calling guide. Securities flows pick up SEBI requirements.
The point that gets missed: outsourcing the call does not outsource the obligation. If your vendor's bot breaches conduct rules, the regulated entity answers for it.
Implementation playbook
A realistic eight-week rollout for a first verification-plus-reminder programme.
Weeks 1 and 2: Foundations. Confirm out-of-band DTMF across your carriers with a live test, not a datasheet. Map every consent record you hold to the purposes it actually covers. Build the shared per-customer frequency counter before you build anything else, because retrofitting it is painful. Migrate CLI to the 1600 series if you have not.
Weeks 3 and 4: Flow design. Write the state machine including every failure branch. Run an explicit audit against one question: is there any path where the bot asks the customer for a secret? Set DTMF timeouts at 20 seconds with one repeat. Build answering-machine detection with a bias toward false negatives, because speaking a code to a voicemail is worse than hanging up on a slow human.
Week 5: Closed pilot. 500 to 1,000 calls on a single segment, single language, single time window. Listen to at least fifty calls end to end yourself. Not the summary dashboard, the audio.
Week 6: The hard segment. Repeat the pilot on your worst audio: regional accents, noisy environments, older handsets. This is where the vendor's numbers and reality diverge, and it is the only pilot result worth quoting internally.
Week 7: Compliance dry run. Have your audit team try to reconstruct ten specific calls from a reference number alone. If they cannot get consent basis, transcript, disposition and access log, fix that before scaling.
Week 8: Scale with a governor. Ramp volume, but cap daily calls per customer across all campaigns at the shared counter you built in week 1. Watch complaint rate as your primary safety metric, not connect rate.
What changes in the next twelve months
Three things worth planning for.
SMS OTP keeps losing ground as a sole factor. As the regulatory framework accommodates a wider set of authentication mechanisms, expect device-bound and app-based factors to displace SMS in higher-value flows. Voice becomes more important as the accessibility fallback for feature phones and low-literacy segments, and less important as a primary channel.
Caller identity becomes a first-class trust signal. Between the 1600 series and handset-level caller name display, the number a call comes from is going to carry more weight than what the caller says. Organisations that have not consolidated their outbound CLIs will find their legitimate calls being treated as spam by their own customers.
Fraud detection moves onto the call. Real-time detection of synthetic voice and of scripted social-engineering patterns is moving from research into production. The organisations that benefit first are the ones whose call data is already structured well enough to feed it.
Bottom line
Verification and payment reminders are the highest-volume outbound flows in Indian financial services, and they sit close enough together that a weakness in one becomes an exposure in the other. The design rule that matters more than any vendor choice: an AI voice agent may deliver a code, but it should not ask a customer to speak one. Move possession proof to DTMF or to a callback, keep low-risk reminders unauthenticated so you are not paying friction for nothing, scrub at dial time, cap frequency per customer rather than per campaign, and test on your worst audio rather than the vendor's best. Get those right and the platform choice becomes what it should be: a procurement decision rather than a risk decision.
Frequently Asked Questions
Tags :
