A verification code that never arrives is a support call, and a support call is the most expensive way to complete a login. That is why financial services increasingly run more than one delivery channel for the same code.
This article sets out why SMS alone leaves a gap, how voice OTP and missed-call verification differ in what they prove, how to plan capacity for the spikes that matter, and how verification events are reconciled against the system that granted access.
Why does SMS alone leave a verification gap?
Because delivery is best-effort on someone else’s network.
Every messaging path depends on the recipient’s network, their device and their subscription, and none of those are conditions the sender can fix.
The gap is not a defect in SMS; it is a property of the channel. A code can be delayed by a congested network, blocked because a subscription has been actioned, or simply not read because the recipient’s device is offline. For a login flow with a short validity window, each of those becomes a failed attempt and then a support contact, and the volume of those contacts is what makes a second channel worth operating.
The message layer that carries the SMS path is defined in ETSI TS 123 040, and the subscription states a device passes through before it can receive anything are defined in 3GPP TS 24.301. Neither specification changes the fact that the last leg belongs to somebody else, which is why the design question is not how to make SMS perfect but what happens when it does not arrive.
How does voice OTP work, and what does missed-call verification add for banks?
Either, and the choice changes the failure modes.
A spoken code is simple and familiar to users, while keypad entry confirms that a person is present with the handset rather than a voicemail or an answering service.
The two variants fail differently, which is the useful way to choose between them. A spoken code that reaches voicemail has been disclosed to whoever can retrieve the message, so the delivery must be considered complete only when the call is answered by a person. Keypad entry requires an interaction, which is stronger evidence of presence and a higher barrier for users in poor coverage or in a noisy environment. Many financial services offer the spoken variant first and switch to keypad entry when the call centre can tolerate the additional support load.
The signalling that establishes and tears down the call is defined in RFC 3261, and the media transport that carries the prompt is described in RFC 3550. Operationally, the figures that matter are the answer rate, the completion rate and the time from request to a confirmed interaction, and those three should be measured per market rather than per deployment because they vary with local network conditions.
| Channel | What it proves | Main failure mode |
|---|---|---|
| SMS code | Control of the handset that received it | Delay, block or no delivery |
| Voice OTP, spoken | Control of the line that answered | Answering service or voicemail captures it |
| Voice OTP, keypad | Presence plus control of the line | Higher user effort, more support contacts |
| Missed call | Control of the handset that called | Proves little about the person holding it |
What does missed-call verification actually prove?
That the caller controls the number.
A missed call is a cheap signal: the user calls a number, the system sees the incoming call and treats the presence of that number as verification.
The strength of the signal comes from what it costs to produce. A missed call requires the caller to have the handset, which is the same assurance SMS provides, and it requires nothing else. It does not establish that the caller is the person the account belongs to, does not work from numbers that cannot call, and does not work where the user is roaming on a network that presents a different identity. For those reasons it is usually positioned as a convenience channel for low-risk steps rather than as a substitute for a code in a high-value transaction.
The practical design question is what the missed call is allowed to authorise. Using it for a password reset or a payment authorisation places more weight on it than it can carry, while using it to confirm that a number is reachable is exactly what it is good at. Guidance on authenticator assurance, including how different factors are classified, is set out in NIST SP 800-63B.
Capacity planning for verification spikes
Verification traffic is spiky in a way campaign traffic is not.
Logins cluster at the start of a working day, around paydays and during incidents, and the peak is what the estate has to be sized for.
Two characteristics make verification volume harder to plan. The first is that the peak arrives without warning, because it follows user behaviour rather than a campaign schedule. The second is that the consequence of a delay is immediate: a user who has not received a code in thirty seconds will try again, which adds a second request to the peak and compounds it. Designing for the average therefore produces a system that degrades exactly when it matters.
The practical approach is to size from the observed peak rather than the daily average, to keep a defined amount of headroom, and to make the retry behaviour of the application gentle: a retry that is triggered by a timer rather than by the user produces additional load without improving the outcome. Where the deployment carries voice as well, the voice channel has its own capacity limit, and the reference for end-to-end delay in speech applications is ITU-T G.114, which is worth reading before committing to a response-time target for the voice path.
Local number presence and answer rates
Recipients answer numbers that look local.
The number a verification call presents affects whether it is answered, and answer rates differ between a familiar local prefix and an unfamiliar one.
That effect is the reason local numbers matter for the voice channel more than for the messaging channel. A message can be read at leisure; a call has to be answered while it rings, and an unfamiliar number is frequently declined. Where the deployment serves several markets, presenting a number that is local to the recipient improves the completion rate without changing anything about the code itself, and the numbering conventions behind that choice are described in ITU-T E.164.
The same reasoning applies to the sender identity on the SMS side, where a registration or identity rule may constrain what can be presented. Both decisions belong in the per-market record rather than in a global setting, because the answer differs by country and by operator.
Reconciling verification events with the core banking log
The code that was sent and the login that succeeded have to be matched.
Reconciliation links three records: the request, the delivery or answer, and the action the user completed afterwards.
Without that link, a dispute about an unauthorised transaction becomes a conversation about what the delivery system believes it did. With it, the institution can show which channel delivered, at what time, and which session completed afterwards. The reconciliation is usually a scheduled job that reads the messaging record and the access log and reports the events that do not join, which is a smaller piece of work than building a combined system.
Two fields make the join possible. The first is a request identifier generated by the institution, carried through every channel, rather than relying on identifiers produced by an operator or a device. The second is a normalised subscriber number, because the same person can appear in the access log with a national format and in the messaging log with an international one. Record-keeping practice for the operational logs involved is covered in NIST SP 800-92.
An implementation outline
The outline sequences the work in the order the dependencies appear, starting with the decisions that constrain everything else. It assumes the delivery channels have already been chosen, and it covers what has to be built, measured and recorded before the flow carries live authentication traffic.
- Define what each channel is allowed to authorise, and record the decision.
- Generate a request identifier for every verification and carry it through all channels.
- Measure the answer rate and completion rate per market for the voice channel.
- Size the estate from the observed peak, with a defined headroom figure.
- Make application retries timer-driven rather than user-driven.
- Choose the presented number per market, and record the choice.
- Run the reconciliation job on a schedule and keep its output as a series.
The outline is deliberately channel-neutral, because the same structure applies whether the fallback is a voice call, a missed call or a second messaging path. What changes is the strength of the signal each channel provides and the speed at which it can be delivered, and both belong in the decision rather than in the integration.
One operational detail is worth settling early: what the support desk says when a customer reports that no code arrived. A script that asks which channel was used, which number was entered and what the customer saw produces a categorised reason, and the categories are what make the monthly review useful. A script that simply resends the code produces a second attempt and no information.
Decide what each channel may authorise before you deploy it. Send your verification volume profile, markets and channel requirements to service@telarvo.com, or review the published configurations on the VoIP gateway range and the VoIP gateway solution page. Telarvo publishes the SK VOIP gateway range and the GoIP models on its product pages, and the configurations referenced above come from those listings.
FAQ
How do banks verify identity over the phone?
Commonly through a code delivered on a channel the caller controls, supported by knowledge questions and behavioural checks. The channel only establishes control of a device or a line; the identity assessment is the bank process, which is why no single channel is treated as proof on its own. The delivery channel and the identity decision should be documented as separate steps.
Why do banks send SMS codes if the channel is not guaranteed?
Because it is cheap, fast and familiar, and because the alternative channels have their own limitations. Most institutions treat delivery as best-effort and measure the gap: the proportion of verifications that fail on one channel and succeed on another is exactly the figure that justifies running a second one. Without that measurement the second channel is a cost rather than a control.
What should a user do if someone calls asking for their code?
No legitimate institution asks for a code that was sent to the customer. The code is evidence that the customer is present, and sharing it transfers that evidence to whoever receives it. Any instruction to read a code aloud during an inbound call should be treated as a fraud attempt rather than as verification. The same applies to a code forwarded by message to a third party.
Does missed-call verification work for customers who are roaming?
Not reliably. A roaming handset may present a different identity, and some prepaid subscriptions cannot place calls at all. Where a market has a high proportion of roaming or prepaid users, the missed-call channel should be offered alongside a code rather than as the only route. The measured success rate per channel is what shows whether the fallback is doing useful work.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How do banks verify identity over the phone?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Commonly through a code delivered on a channel the caller controls, supported by knowledge questions and behavioural checks. The channel only establishes control of a device or a line; the identity assessment is the bank process, which is why no single channel is treated as proof on its own. The delivery channel and the identity decision should be documented as separate steps.”
}
},
{
“@type”: “Question”,
“name”: “Why do banks send SMS codes if the channel is not guaranteed?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Because it is cheap, fast and familiar, and because the alternative channels have their own limitations. Most institutions treat delivery as best-effort and measure the gap: the proportion of verifications that fail on one channel and succeed on another is exactly the figure that justifies running a second one. Without that measurement the second channel is a cost rather than a control.”
}
},
{
“@type”: “Question”,
“name”: “What should a user do if someone calls asking for their code?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “No legitimate institution asks for a code that was sent to the customer. The code is evidence that the customer is present, and sharing it transfers that evidence to whoever receives it. Any instruction to read a code aloud during an inbound call should be treated as a fraud attempt rather than as verification. The same applies to a code forwarded by message to a third party.”
}
},
{
“@type”: “Question”,
“name”: “Does missed-call verification work for customers who are roaming?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Not reliably. A roaming handset may present a different identity, and some prepaid subscriptions cannot place calls at all. Where a market has a high proportion of roaming or prepaid users, the missed-call channel should be offered alongside a code rather than as the only route. The measured success rate per channel is what shows whether the fallback is doing useful work.”
}
}
]
}