In 2024, the UK fraud prevention service Cifas recorded nearly 3,000 unauthorised SIM swaps — a 1,055% jump in a single year (Cifas, 2025). Every one of those hijacked numbers kept receiving the victim’s SMS one-time passwords. Nothing was "hacked". The codes worked exactly as designed — they just arrived on a criminal’s device.
This is the problem voice OTP solves. Instead of sending the code as a text message, the platform places an automated call, and a synthesized voice reads the code aloud. At BSG, this service is called One Voice Calls (OVC), and it exists for one reason: to take high-risk verification off the SMS rail. Below is how the mechanism works, which attack paths it closes that SMS cannot, and how to run both channels behind one API.
Voice OTP is a verification method that delivers a one-time password (OTP) through an automated outbound phone call. A text-to-speech (TTS) engine reads the numeric code aloud — typically twice — and the user types it into the app or website to confirm the action. No message is sent, stored, or displayed anywhere on the device.
That last detail is the whole point. Because the code travels over the voice channel rather than SMS, it works on any device that can receive a call: smartphones, feature phones, even landlines. There is no app to install and no dependency on the user’s SMS inbox — which, as the next sections show, is exactly where most OTP theft happens.
One Voice Calls (OVC) is BSG’s implementation of this method. It bundles the outbound call, TTS code reading, retry logic, and delivery reporting into one product, with SMS fallback available through the same API when a call cannot be completed.
From the user’s perspective, the flow mirrors SMS: request a code, receive it, type it in. What changes is the delivery rail. A typical OVC transaction looks like this:
End-to-end latency is comparable to SMS: the phone is usually ringing within seconds of the API request. If the user does not pick up, the platform retries or cascades to SMS — more on that below.
SMS OTP fails not because the codes are weak, but because the delivery channel can be redirected, intercepted, or read by malware without the victim noticing. Voice OTP removes that channel entirely. Here is what disappears in practice.
In a SIM swap attack, a criminal ports the victim’s number to a SIM they control and silently collects every incoming text — OTPs included. The FBI’s IC3 logged over $68 million in reported SIM swap losses in 2021 alone (FBI IC3, 2022). Voice delivery changes the economics: there is no stored message to harvest. The code exists only inside a live call that must be answered in real time, which breaks automated collection and produces detectable anomalies. Running a Number Verifier check before sending — it flags recent SIM changes and porting activity on the number — closes the loop on this vector.
SS7, the signaling protocol that routes calls and texts between carriers, has known weaknesses that let attackers reroute SMS traffic. In 2017, criminals used SS7 access to redirect German bank customers’ SMS transaction codes and drain accounts at O2 Telefónica — confirmed by the operator itself (SecurityWeek, 2017). Rerouting a text message over SS7 is cheap and silent. Hijacking a live voice call is noisier, harder to sustain, and rarely worth the effort for code theft.
Android banking trojans routinely request SMS permissions, then forward incoming codes to attacker servers while hiding the notification — the victim never sees a thing. A voice call leaves no artifact in any inbox. There is no message for malware to read, forward, or delete.
Real-time phishing kits relay SMS codes easily because the code sits on screen, ready to be retyped into a fake page. A spoken code adds friction: it must be heard, held in memory or written down, and relayed before it expires. That does not stop a determined live-phishing operation, but it measurably raises the attacker’s cost per attempt.
One caveat worth stating plainly: NIST classifies all phone-network OTPs — SMS and voice alike — as "restricted" authenticators in SP 800-63B, because the public telephone network is not a secure channel (NIST, 2017). Voice delivery is not cryptographic proof of possession. What it does is remove the SMS-specific attack surface where the overwhelming majority of real-world code theft actually happens — and for phone-number verification, that is the difference between a common attack and a rare one.
The table below summarizes where each channel is strong. Read it as a risk-tiering tool, not a verdict: most authentication stacks end up using both.
| Criterion | Voice OTP (OVC) | SMS OTP |
|---|---|---|
| Delivery mechanism | Automated call; TTS reads the code aloud twice | Text message stored in the inbox |
| SIM swap exposure | Low — code exists only in a live, answered call | High — all texts silently redirected to the attacker |
| SS7 interception | Low — call rerouting is complex and conspicuous | Documented real-world attacks on SMS routing |
| Device malware exposure | None — no message stored on the device | High — trojans read and forward SMS codes |
| Device compatibility | Any phone, including feature phones and landlines | Any phone with SMS support |
| Accessibility | Audio only — an alternative path is required for hearing-impaired users | Readable; works without audio |
| Environment sensitivity | Weaker in noisy surroundings; retries help | Works silently anywhere |
| Cost per verification | Somewhat higher than SMS | Lowest-cost channel |
| Best suited for | High-risk actions: withdrawals, payout changes, account recovery | Routine logins and low-risk confirmations |
Voice OTP is regularly mixed up with flash call verification. Both use the voice network — and that is where the similarity ends.
A flash call is a dropped call: the platform dials the user’s number and hangs up before anyone can answer. The verification code is embedded in the last digits of the caller ID, and on Android the app reads it automatically from the call log. The user never hears anything.
Voice OTP works the opposite way. The call is meant to be answered, and a TTS voice reads the code aloud to a listening human. The practical consequences are significant: flash call depends on call-log access, which Google has been progressively restricting, and on iOS it cannot auto-verify at all. An otp voice call needs no special permissions and behaves identically on every platform, because the user simply listens and types.
One Voice Calls is a voice OTP product, not a flash call service. If a provider quotes you "voice verification", ask which mechanism they mean — the security properties and platform dependencies are not the same.
You do not have to pick one channel for everything. In our experience working with fintech and iGaming clients in Germany and the UK, the teams with the best completion-to-fraud ratio run a tiered model: SMS by default, voice where the risk justifies the cost.
SMS is enough for routine, low-value events — standard logins from known devices, opt-in confirmations, order updates. It is the cheapest channel, every user understands it, and the loss potential per event is small.
Voice OTP verification earns its cost on high-risk events: withdrawal confirmations, payout account changes, account recovery, first logins from new devices — any moment in BFSI, fintech, or iGaming where an intercepted code converts directly into stolen money. These are precisely the events SIM-swap operators wait for. How to structure these tiers in regulated finance is covered in our guide to 2FA for fintech.
Two honest limitations. Voice is an audio channel, so users with hearing impairments need an alternative path — never make it the only option. And background noise can force retries. Neither is a reason to avoid the channel; both are reasons to deploy it as a tier, not a monolith.
A tiered model only works if switching channels does not mean a second integration. OVC ships with SMS fallback as a cascade: one API call, and the platform tries voice first, then falls back to SMS if the call fails or goes unanswered — or the reverse order for lower-risk flows.
Based on what we observe across the OTP traffic we route, cascade logic moves two numbers at once. Completion rates go up, because a failed channel no longer means a failed verification. And costs go down, because each code takes the cheapest path that actually delivers — across the OTP cascades we support, clients typically cut delivery costs by 20–40% (how cascade fallback cuts costs).
A European trading platform we work with shows the before-and-after clearly. Before the cascade, a failed SMS on a high-value withdrawal confirmation went straight to a support ticket — a user locked out of their own money, an agent verifying identity by hand. After moving withdrawals to voice OTP with SMS fallback, a stuck verification became a retry the user never notices, and SMS interception dropped out of the threat model for the platform’s highest-value action.
Integration follows the same pattern as any voice otp api. You send a request with the destination number and either your own generated code or an instruction for the platform to generate one. BSG places the call over direct voice routes, and call status plus validation results return via webhook.
Practical points our clients ask about at this stage: TTS languages are configured per request — German and English voices for DE and UK traffic are standard. Retry counts and the voice-to-SMS cascade order are set per message profile, not hardcoded. And delivery reporting distinguishes "answered" from "rang out", so your risk engine can treat an unanswered verification call as a signal in its own right. OVC runs on BSG’s 2FA and OTP platform, so codes, validity windows, and attempt limits are managed in one place across both channels.
For EU traffic, calls originate from BSG’s own infrastructure: the company holds 15+ national telecom licenses in the EU and operates direct connections to 60+ mobile network operators — which is what keeps latency low on German and UK routes.
If your highest-risk verifications still travel over SMS, the attack surface is the message itself — and that is fixable in a single integration. One Voice Calls delivers codes over an answered call, falls back to SMS automatically, and runs on the same BSG API as the rest of your messaging. Tell us which flows you want to move first — withdrawals and payout changes are where most fintech teams start — and we will map the cascade with you. Talk to the BSG team about adding OVC to your authentication stack.
Against most real-world attacks, yes. Voice OTP removes the SMS delivery channel, which is where SIM swap harvesting, SS7 rerouting, and SMS malware all operate. The code exists only in a live call, so there is no stored message to intercept — though it is still phone-based verification and belongs inside a layered authentication strategy.
Voice OTP is an answered call in which a TTS voice reads the code aloud and the user types it in. A flash call is a dropped call in which the code is the last digits of the caller ID, read automatically from the Android call log. They are different products with different permissions, platform support, and security properties.
Yes. Voice OTP only requires the ability to answer a call, so it works on any feature phone and on landlines — no app, no SMS support, no internet connection. That makes it a practical verification channel for user bases that smartphone-only methods exclude.
Time to move on from MMS and look to the future of SMS. Stay ahead of the game by discovering the latest and greatest in SMS technology. Embrace change and elevate your messaging game today.
Summer is coming in 2 days! Your customers are gearing up for the hot season
From STT to action: how an AI voice assistant handles sales and support calls end to end.
