Voice biometrics plus OTP? Build payment AFA without trusting the voice channel

Please do not ask a caller to read an OTP into the same voice agent that is preparing the payment.

Yes, teams still design this.

The bot hears the transaction, prompts for the code, writes the transcript, sends events to observability, and may pass audio through several providers. A secret meant to prove possession has just toured the voice stack.

Voice biometrics do not rescue that design. A voiceprint can be one inherence signal inside an approved authentication system. It is not a magical signature, not replay-proof, and not permission for the agent to move money.

Voxeval’s stance: keep conversation and payment authorization in separate control planes. The voice agent can explain, collect intent, and launch an approved step-up flow. The bank or payment service owns authentication, transaction binding, risk, and the final commit.

The call sounds like the customer. So what?

Generative voice cloning made the old intuition, “I know that voice,” a weak control. Recordings can be replayed. A real customer can call from a compromised phone. Background speech can trigger a passive matcher. Illness, ageing, stress, and a cheap microphone can reject the right person.

A biometric system needs more than a similarity score:

• enrolment provenance;

• liveness and anti-spoof testing against the attacks you expect;

• threshold tuning with false-accept and false-reject costs;

• secure template storage and revocation when compromised;

• a fallback that does not punish people whose voices cannot be matched.

And even a successful match says “this voice resembles the enrolled template under this test.” It does not say “approve ₹48,000 to this new beneficiary.”

What RBI’s AFA directions change

RBI’s 2025 directions on authentication mechanisms for digital payment transactions take effect from April 1, 2026. They require at least two distinct factors for covered digital payment transactions, with at least one factor specific to the transaction for non-card-present payments, subject to the directions’ scope and exemptions.

Read the actual directions with your compliance team. Do not turn that sentence into a product spec by itself.

The engineering idea is clear, though. Authentication factors must be independent enough that compromise of one does not collapse the others. The approval also needs to be tied to the payment the customer is making, not to a vague session that can be swapped underneath them.

For a voice flow, that means the payment service builds a challenge from the resolved amount, payee, rail, and expiry. The customer approves through a controlled factor path. The result returns as a signed authorization for that exact transaction.

Change the amount? New authorization.

Change the beneficiary? Again.

A fictional attack in Hyderabad

An attacker has a cloned sample of a customer’s voice and control of the customer’s diverted phone number. They call the bank’s voice agent and request a transfer to a new UPI handle.

The voice matcher passes. An SMS OTP also reaches the attacker. Two checks appeared on the product diagram, yet both were defeated through linked compromises.

This is why factor counting is not threat modelling.

The risk engine may need device binding, known-app approval, transaction details shown in a trusted channel, beneficiary cooling periods, fraud signals, and human review for an unusual payment. Exact controls depend on the bank, rail, customer, and transaction risk.

The voice agent should not decide that combination from free-form reasoning. It requests an authorization policy from the payment service and follows the returned state.

Keep the OTP out of the transcript

If an approved flow still uses an OTP, prefer collection through a separate protected input path provided by the regulated system. For telephony, that may mean DTMF capture isolated from speech transcription and excluded from ordinary logs, if the bank’s approved design permits it. For an app user, a trusted in-app confirmation may show the transaction details and collect approval there.

Never echo the full code back. Do not send it to the language model. Do not store it in call summaries. Do not expose it in support dashboards.

Test the plumbing, not just the policy statement:

• search logs for a fictional test OTP;

• inspect transcript events and analytics payloads;

• can a support user view keypad entries?

• replay the same code against a changed transaction;

• retry after expiry;

• interrupt the agent while the protected capture is open.

One leaked test code means the route is not isolated.

DoT risk signals are not identity proof

The Department of Telecommunications has described systems such as the Digital Intelligence Platform, Financial Fraud Risk Indicator, and Mobile Number Revocation List. The MNRL includes disconnected mobile numbers with reasons and dates, while financial institutions can use telecom risk signals to strengthen fraud controls.

Useful input. Not a verdict.

A risky number may require step-up checks or block a sensitive action under approved policy. A number absent from a list is not proof that the caller is genuine. These signals can be stale, incomplete, or unrelated to the person currently holding the phone.

Record which signal version and policy affected the decision. Give legitimate customers a recovery path.

The control plane should be boring

Picture the system as two lanes.

The conversation lane handles audio, language, turn-taking, explanations, and intent. It can say, “I have prepared a transfer of ₹2,500 to Anita Rao. Please approve it in your banking app.”

The authorization lane receives a resolved transaction ID, fetches policy, runs factors, verifies transaction-specific approval, and issues a short-lived signed result. The commit service accepts that result once.

The voice model never sees secret factor values. It sees safe states:

• AUTH_PENDING
• AUTH_APPROVED_FOR_TXN_7F2
• AUTH_EXPIRED
• AUTH_DENIED
• HUMAN_REVIEW_REQUIRED

It can explain the next step. It cannot rewrite the state.

Biometrics have a human failure mode

False rejects are not edge trivia. A customer with a cold, a speech disability, a changed voice after treatment, or a poor phone line may fail matching repeatedly. If the fallback is “visit a branch” for every case, the design has shifted cost onto the people least able to absorb it.

Measure false rejects by lawful, consented user slices and audio conditions. Offer an approved alternate path. Limit repeated biometric attempts so the caller is not trapped in an embarrassing loop. Train human agents not to treat a failed match as proof of fraud.

And give customers a way to revoke or re-enrol a compromised voice template through a strong recovery process.

Attack the whole ceremony

Use Voxeval’s voice payment AFA threat model to review the ceremony from enrolment to recovery. It includes replay, cloning, number takeover, prompt injection, OTP exposure, transaction swapping, approval replay, support access, and fallback abuse.

Run it with payments, fraud, security, legal, voice engineering, and operations in the same room.

Then place a fictional payment. Change the beneficiary after approval. If anything moves, stop.