At Authenticate APAC, Justin Soong, Authsignal's Director of Product, spoke about the next stage of passwordless authentication: getting rid of SMS OTP without breaking the customer journey.
Regulators across APAC and the Gulf are moving SMS and email OTP out of high-risk banking authentication. Some markets have set hard phase-out dates. Others have narrowed the use of OTPs to specific fallback scenarios. But the direction across is consistent, banks can no longer treat a code sent over SMS as the main control for login, payment approval, device binding, or recovery.
Login is not where the work ends. Removing SMS creates pressure much earlier, the moment a new customer enters a phone number.
If SMS OTP is no longer the right default, how should a bank verify that the customer actually controls that number?
That is the gap Justin focused on. The regulatory direction is settled. The hard part is the migration path, especially at the point where the customer relationship begins.
Why SMS OTP is broken
The case against SMS OTP usually gets framed as a security problem. It is one. It is also a cost problem, and now a compliance problem.
On security, SMS was never designed to carry authentication secrets. Codes can be exposed through SIM-swap fraud, social engineering, malware, phishing pages, and weaknesses in telecom routing infrastructure. Once an attacker controls the number or tricks the customer into sharing the code, the bank's second factor becomes part of the attack path.
On cost, there is SMS pumping. Fraudsters use bots to trigger OTP sends to number ranges they control or monetise. The business pays for traffic that was never going to a real customer. Elon Musk claimed Twitter was losing around $60 million a year to this kind of SMS abuse in late 2022. The exact figure was never formally audited in public, but the pattern is familiar to any team that has watched OTP costs spike without a matching increase in real users.
On compliance, regulators have run out of patience with treating SMS OTP as the default answer.
The regulators have already decided
Six jurisdictions across APAC and the Gulf have moved against SMS OTP, each with different scope and timing:
- Malaysia: Bank Negara Malaysia's updated Risk Management in Technology policy, issued on 28 November 2025, makes unencrypted SMS OTP non-compliant as a standalone MFA method for financial institutions. The rule pushes institutions toward interception-resistant MFA and stronger device binding.
- Singapore: On 9 July 2024, MAS and the Association of Banks in Singapore announced that major retail banks would phase out OTPs for bank account login by customers who had activated digital tokens, over the following three months.
- Hong Kong: HKMA's "E-Banking Security ABC" guidance requires banks to make in-app authentication the default for Internet banking logins and high-risk transactions by Q4 2025, while allowing SMS OTP only in limited scenarios with extra risk controls.
- UAE: CBUAE Notice 2025/3057 set a 31 March 2026 deadline for licensed financial institutions to phase out SMS and email OTPs as standalone authentication methods, with liability pressure already attached to weak OTP-based fraud flows.
- India: RBI's 2025 digital payment authentication directions require two-factor authentication for domestic digital payments from 1 April 2026, with at least one dynamic factor. India has not banned SMS OTP, but the rule raises the baseline and opens the door to stronger alternatives.
- Philippines: BSP Circular 1213 requires supervised financial institutions to limit interceptable authentication mechanisms, including SMS and email OTPs, and move to stronger authentication for high-risk financial flows by June 2026.
The exact rules differ, but the pattern is clear. Regulators are pushing authentication away from shared secrets sent over channels the bank does not control, and toward device-bound, phishing-resistant, or risk-aware methods.
That pressure does not stop at tier-one retail banks. E-money issuers, payment operators, wallets, and fintechs are increasingly inside the same authentication and fraud-control expectations.
The gap that needs to be filled
A bank's relationship with a customer has a shape to it.
First, the customer creates an account. Then the bank verifies the phone number. Then it proves the customer's identity. Then it binds a credential to the customer's device. After that come the recurring logins, payments, step-ups, device changes, and recovery flows.
SMS OTP used to sit in two places at once. It verified the phone number at onboarding, and it challenged the user during sensitive actions later.
Regulators have mostly addressed the second job: stop relying on SMS OTP for high-risk authentication and move to stronger controls. But they do not prescribe a single replacement for the first job. If a customer enters a phone number during sign-up, and SMS OTP is no longer the right default, what should the bank use instead?
That is the operational gap. Replacing SMS at login is relatively well understood. Replacing SMS for phone verification at onboarding is where teams often discover complexity late.
The replacement stack at onboarding
Justin's answer is a three-layer stack. Each layer covers a job SMS OTP used to pretend it covered.
Layer one: Verify the phone without sending a code
The cleaner way to confirm that a customer controls a mobile number is to verify it through the carrier network rather than sending a code over SMS.
Silent Network Authentication does this in the background. The customer enters their phone number, the app or backend starts a verification check, and the carrier confirms whether the number matches the SIM being used on the device. With GSMA Open Gateway and CAMARA-style Number Verification APIs, the check can happen without a message being sent and without the customer reading or typing a code.
This closes off the weaknesses SMS introduced. A phishing page has no code to harvest and malware has no message to read. It also removes the premium-rate SMS traffic that pumping depends on.
SNA has a real limitation, though. It works best in a mobile app when the device is on the cellular network. If the user is on Wi-Fi, using a desktop browser, roaming, or in a market where carrier coverage is incomplete, the check may fail or be unavailable.
GSMA TS.43 and related SIM-based authentication work are designed to close more of that gap over time by moving more verification capability toward the SIM and device layer. But this is still evolving, so SNA should be treated as the primary path where it works, not the only path.
When SNA is unavailable, the fallback should not automatically be SMS. In many APAC markets, WhatsApp OTP is a better fallback channel. It is not exposed to SS7 in the way SMS is, it avoids the same premium-rate SMS pumping model, and it reaches users in a messaging app they already check frequently.
The caveat is, WhatsApp OTP is still a code. A phishing site can still try to trick a customer into entering it. WhatsApp reduces carrier-level SMS weaknesses; it does not remove the human risk. That is why it belongs underneath SNA, not above it.
Layer two: Bind the number to a real, present person
A verified phone number tells you a SIM and number are associated with the session. It does not tell you the right human is present.
That is where liveness and facial biometrics come in.
A liveness check, whether active or passive, is designed to detect presentation attacks such as photos, masks, replays, and synthetic media. Pairing a verified number with a verified live face gives the bank a stronger identity anchor than a phone number alone.
This also changes account recovery. Instead of falling back to "text me a code," recovery can use the original identity anchor: passkey plus liveness, or re-binding with biometric verification under risk controls.
For this layer, vendor selection matters. Look for independent ISO/IEC 30107-3 PAD testing, preferably iBeta Level 2 or Level 3 confirmation for the relevant platform and configuration. Also look for documented controls against injection attacks, replay attacks, and deepfakes; demographic bias testing; and options for on-device templates where data residency matters.
Layer three: Issue a passkey for everything after
Once the phone and person are anchored, the next step is to issue a passkey.
Passkeys are FIDO2/WebAuthn credentials based on public-key cryptography. The private key stays with the user's device or credential manager, and the public key is stored by the service. Authentication succeeds only when the credential is used for the legitimate relying party, which makes passkeys phishing-resistant by design.
This is where the migration starts to pay off.
Before, SMS was triggered repeatedly:
- Login: SMS OTP
- High-value transfer: SMS OTP
- Add payee: SMS OTP
- Device change: SMS OTP
- Account recovery: SMS OTP
After, the passkey carries the relationship:
- Login: passkey
- High-value transfer: passkey plus risk-based step-up
- Add payee: passkey plus contextual checks where needed
- Device change: re-bind with liveness
- Account recovery: passkey plus liveness, not a texted code
The heavy verification happens at the front door. After that, the bank relies on a credential that is harder to phish and does not interrupt the user on every action.
After onboarding, the passkey carries the relationship
The complete flow, put together.
During onboarding, the customer enters their phone number. The bank attempts SNA. If SNA is unavailable, it routes to a stronger fallback such as WhatsApp OTP. The customer completes liveness and identity checks. The bank issues a passkey and binds it to the account.
On return visits, the customer signs in with the passkey. Higher-risk actions trigger step-up rules based on transaction value, device history, location, velocity, and fraud signals. A new device requires re-binding. Recovery uses the identity anchor rather than reverting to SMS.
This is an orchestration problem as much as a security one. Different users, devices, markets, and channels need different paths. Some users will be on mobile data. Some will be on Wi-Fi. Some will have WhatsApp. Some will need an assisted or branch-backed path. The stack works only if the bank can route intelligently before sending a fallback challenge.
The real question is sequencing
The technology is not speculative. Carrier-based number verification is rolling out through GSMA Open Gateway and CAMARA APIs. Liveness vendors have mature PAD testing programs. Passkeys are already in production across consumer and financial services use cases.
The hard part is sequencing.
Onboarding is the most sensitive conversion flow in the product. It is also where compliance, fraud, identity, growth, and customer support all meet. Move too fast and you lock out legitimate users who cannot complete the primary path. Move too slowly and you keep paying for SMS, absorbing fraud risk, and carrying a control regulators increasingly dislike.
The right migration is staged.
Start by mapping every place SMS OTP is used. Separate phone verification, login, transaction approval, device binding, and recovery. Then replace the highest-risk and highest-cost flows first. Add SNA where carrier coverage supports it. Add WhatsApp or another stronger fallback where SNA does not. Bind identity with liveness. Issue passkeys once the customer has been anchored. Use rules and risk signals to decide when to step up, rather than sending an OTP by habit.
That is the point of the roadmap Justin laid out. Eliminating SMS OTP is not one switch. It is a sequence of decisions about when to verify the phone, when to verify the person, when to issue a credential, and when to ask for more proof.
The regulators have settled the direction. The product work is deciding how to get there without breaking the front door.
Authsignal helps teams manage that migration with passkeys, adaptive step-up, channel routing, and configurable rules, so SMS can be removed flow by flow instead of all at once. Talk to us if you’re also planning to phase out SMS OTPs.
.svg)
.png)