SMS OTP Security: Stop SMS Pumping, SIM Swap and OTP Bots

SMS OTP is still required, and still worth protecting

RBI's Authentication Mechanisms for Digital Payment Transactions Directions, 2025, which apply from 1 April 2026, require two factors for domestic digital payments, with at least one dynamic factor for payments made without a card present. RBI encourages new kinds of factors, but it says the framework does not call for SMS OTP to be discontinued.

So SMS OTP will stay in Indian apps for years. The job is to make it harder to abuse. That means stopping fake requests that cost you money and attacks that steal real users' codes.

SMS pumping: fake requests that inflate your bill

SMS pumping, also called artificially inflated traffic (AIT), happens when bots use your sign-up or login form to request OTPs to numbers the fraudster benefits from. Each SMS earns them a share of the revenue, and you pay for it. Nobody ever enters the codes.

Watch for the signs: a sudden rise in OTP requests with few codes entered, many requests to numbers in the same series, and traffic to countries where you have no customers. If you do not serve users abroad, do not send OTPs to international numbers at all.

SIM swap: when the number itself is stolen

In a SIM swap, a criminal convinces an operator to issue a new SIM for the victim's number, then receives their OTPs. India's operators have added protections. Since 2022, SMS is barred for 24 hours on a SIM after a swap or replacement, and since 1 July 2024 a number cannot be ported out within 7 days of a SIM swap.

Your app can add its own layer. Bind accounts to a known device where you can, alert the user by email or in the app when the mobile number changes, and hold high-risk actions, such as adding a payee or changing a password, for a cooling-off period after a number change.

OTP bots and social engineering

OTP bots are automated calls that pose as a bank or a delivery company and ask the user to read out or type in the code they just received. They work because users often cannot tell what a code is for.

Your message wording is the best defence. Say what the code is for and, for payments, the amount and the merchant. Add a line such as Do not share this code with anyone, and say that your company will never ask for it. A user who reads OTP for payment of Rs 49,999 to a merchant they do not know is far more likely to stop.

A checklist for safer OTPs

Most attacks fail against a few simple controls.

• Use 4 to 6 digit codes that expire in 5 to 10 minutes, with one active code per user
• Allow only a few wrong attempts before you lock the code and ask for a new one
• Limit OTP requests per number, IP address and device, with a cooldown before a resend
• Put a captcha or similar check before the first OTP request on public forms
• Send OTPs only to countries you serve and watch the ratio of codes sent to codes entered
• Use an approved OTP template on a service header, so it reaches DND numbers at any hour
• Offer a voice or WhatsApp backup with the same limits, not unlimited retries

How our platform helps

Messages that do not match an approved DLT template are not sent, so an attacker cannot use your account to send arbitrary text. API keys have request limits and, in the v2 API, are tied to your servers' IP addresses, and repeated failed logins from one address are blocked automatically. Numbers are checked for a valid format, and a platform-wide block list stops known bad numbers. For international and voice traffic, premium-rate and known toll-fraud destinations are refused.