SMS OTP is being phased out. Here is what to use instead.

Published 29 August 2026 · Replio

Three central banks have now restricted SMS one-time passcodes. The headlines say OTPs are dead. They are not, and the difference matters if you are deciding what to build this quarter.

What actually changed

Over the past year, three regulators moved against passcodes delivered by SMS and email. These are real, dated and enforceable, so they are worth stating precisely rather than as a vibe.

The UAE is the strictest of the three. Notice 2025/3057, issued in May 2025, requires licensed institutions to replace SMS and email passcodes with stronger authentication, and it carries an administrative penalty for non-compliance. It also moved liability for 3D Secure fraud onto institutions that keep using SMS OTP, which in practice is the part that changes behaviour fastest.

The Philippines followed with Circular 1213, pushing supervised institutions onto biometric, behavioural or passwordless methods for high-risk transactions. It flows from the Anti-Financial Account Scamming Act, and compliance comes with liability protection while non-compliance means reimbursing customers for scam losses.

India is the one most often reported wrong. The Reserve Bank now requires two factors on every digital payment with at least one of them dynamic. A passcode can still be one of those factors. It simply cannot be the only one. India did not ban the OTP. It banned relying on the OTP alone.

Why SMS specifically, and not the passcode

Nothing in these rules says a six-digit code is a bad idea. What they say is that the pipe it travels through cannot be trusted. Three well-documented attacks explain why:

• SIM swap. An attacker persuades a carrier to move a victim's number onto a new SIM. Every code then arrives on the attacker's phone, and the victim usually notices only when their own service goes dead.
• SS7 interception. The signalling protocol that routes messages between carriers was designed in an era when every participant was assumed to be trustworthy. It has no real authentication, and access to it can be rented.
• Smishing. The code is delivered correctly to the right person, who then types it into a convincing fake page. The passcode worked exactly as designed and the account was still lost.

That framing is the useful takeaway for anyone choosing a stack. The industry did not conclude that one-time passcodes are broken. It concluded that the SMS channel is the weak link, which is why every one of these rules names the channel.

What this means if you are not a bank

Here is the part that gets flattened in most coverage. All three rules bind licensed financial institutions, and mostly for high-risk transactions: banks, card issuers, payment service providers, e-wallets. If you run a restaurant, a clinic, an online store, a logistics company or a software product, and you send a code so someone can confirm their phone number at signup, none of these instruments apply to you.

The practical questions for a normal business were always the same three. Does the code arrive? What does it cost per send? Does the message look like it came from us, or from an anonymous shortcode? SMS has been quietly losing on all three for years, in exactly the markets where phone verification matters most.

WhatsApp is the migration most teams actually make

If the problem is the delivery channel, the fix is a better delivery channel. For a large share of the world, that is WhatsApp, and the reasons are unglamorous and practical:

• It is where people already are. In most of the Middle East, Africa, South Asia and Latin America, WhatsApp is the default messaging app. A code there gets seen, not buried under delivery notifications and promotions.
• It is bound to an app install, not to a SIM. That takes plain SS7 interception off the table, and the message is end-to-end encrypted in transit.
• It comes from your business. Your own verified number and business name, not a shared shortcode that any sender can rent. That alone removes a large slice of smishing plausibility.
• It costs a fraction of an SMS in most markets. For high-volume signup verification, this is usually the line item that decides the argument.

None of that is a compliance claim. It is a channel-quality claim, which is the claim that actually applies to the businesses these rules do not cover.

How Replio's WhatsApp OTP API works

We shipped our WhatsApp OTP API for exactly this job: send a one-time passcode over WhatsApp with a single HTTP request, through your own verified number, with no Meta app review to pass and no template plumbing to maintain.

There are two ways to use it, and the first one is deliberately boring.

Keep your own codes

If you already generate and check codes, change nothing about that logic. Send us the number and the code, and we deliver it.

curl -X POST https://replio.live/api/otp/send \
  -H "Authorization: Bearer rpl_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{"phone":"447911123456","code":"483920"}'

Or let us handle verification too

Omit the code and Replio generates one, stores only a hash of it with an expiry you control, and gives you a matching verify endpoint to check what the user typed back. That deletes the whole store-and-compare layer from your codebase, including the parts teams usually get wrong: single-use consumption, attempt ceilings, and making sure a fresh code retires the previous one.

Because this is security infrastructure and not a marketing feature, it is worth being specific about what we hardened rather than saying "enterprise-grade" and moving on. Stored codes are kept as keyed hashes, so a database copy does not hand over usable codes. Codes are consumed atomically, so two simultaneous requests cannot both spend the same one. Rate limits are enforced per recipient in the database rather than in process memory, so they survive a restart instead of quietly resetting. Calls that arrive from a browser are refused outright, because a secret key in front-end code is a key that has already leaked. Verification records are swept on a retention schedule instead of accumulating forever. There is a full test mode so you can build against the API without spending credits.

Replio is a Meta Tech Provider, so the WhatsApp side is a supported integration rather than a workaround.

Where WhatsApp OTP is not the answer

Being straight about this is more useful than a clean pitch, and it is the section most vendors leave out.

• If you are a licensed financial institution under one of these rules, WhatsApp OTP will probably not satisfy them either. Those regulators are pointing at device-bound factors: biometrics, FIDO2 passkeys, in-app push approval. A code delivered over any messaging channel is not one of those. Our OTP API is not a compliance product for regulated finance and we will not sell it as one.
• It is not immune to account takeover. Someone who successfully hijacks a phone number and re-registers WhatsApp on it can receive the codes. Better than SMS on the attacks that matter, not invulnerable.
• A passcode is still one factor. If you are protecting something genuinely valuable, pair it with something else. That is precisely the point the Reserve Bank of India is making, and it is good advice well outside India.
• Some users will not have WhatsApp. Keep an SMS fallback. Route to WhatsApp first, fall back on failure. You will use the fallback less than you think.

Frequently asked questions

Related