The short answer
- What it is: automated requests that make your application send passcodes or other SMS to numbers chosen by an attacker, who profits from the delivery.
- Who pays: you. The messages are real messages sent from your account, so they are billed like any other.
- The main sign: many more codes sent than codes entered, often to countries or number ranges your customers do not use.
- What stops it: several controls together: rate limits, a human check before sending, allowing only the countries you serve, monitoring codes sent against codes entered, and spending limits with your providers.
Signs your OTP traffic is being pumped
Check your sending data for these patterns. One on its own may have an ordinary cause; several together usually do not.
- Messages rise, sign-ups do not. SMS volume or cost goes up with no matching growth in new accounts or logins.
- Codes sent but never entered. The share of passcodes that users actually type in drops sharply.
- Unusual destinations. Messages go to countries, operators or number ranges where you have few or no customers.
- Similar numbers in a row. Many requests for numbers that differ only in the last digits.
- Bursts from a few sources. Large numbers of requests from a small set of IP addresses, devices or sessions, or from clients that do not behave like a real browser or app.
How the attack works
- The attacker obtains phone numbers, or ranges of numbers, that earn a share of the revenue when a message is delivered to them.
- A script finds a screen in your product that sends an SMS on request: sign-up, login, password reset or "resend code".
- The script requests codes for those numbers again and again, often from many IP addresses to avoid simple blocking.
- Each message is delivered and billed to you. The attacker is paid from the delivery revenue, and nobody ever enters a code.
The OWASP API Security Top 10 uses an SMS "forgot password" flow as its example of this risk: a script calls it tens of thousands of times, and the company loses money within minutes.
Controls to build into your application
| Control | What it does | How to apply it |
|---|---|---|
| Rate limits | Caps how often one client can trigger a code | Limit requests per phone number, per device, per IP address and per session, with a growing delay between resends |
| Human check before sending | Makes automated requests harder | Show a challenge before the code is sent, or only when a request looks unusual |
| Block unexpected clients | Stops scripts that do not behave like your app or a real browser | Deny requests from headless browsers; consider blocking Tor exit nodes and well-known proxies |
| Allow only the countries you serve | Removes the destinations attackers profit from | Accept phone numbers only from the countries where you have customers; review the list before you add one |
| Check numbers before sending | Filters numbers that cannot be real customers | Validate the number format and reject ranges you never expect |
| Ask for something else first | Reduces how often an SMS is sent at all | For logins, check the password or another factor before sending the code |
| Monitor codes sent against codes entered | Shows an attack early | Track the rate per country and per operator, and alert when it falls below your normal level |
| Spending limits with providers | Caps the damage | Set spending limits for each messaging provider; where that is not possible, set billing alerts |
No single control is enough on its own. OWASP lists rate limiting, limits on how often one client can run an operation, and spending limits as separate measures for this risk, and recommends human detection and client screening for flows that bots abuse.
What to monitor every week
- Codes sent and codes entered, by country and by operator.
- Requests per phone number, per IP address and per device.
- Messages sent to countries you do not normally serve.
- Spend per day against your normal range.
- Delivery receipts for each message, so you can see exactly where your messages went.
Questions to ask your SMS provider
- Can you show a delivery receipt for each message, and break reporting down by operator?
- Can API access to our account be limited to our own IP addresses?
- Can we restrict the countries our account sends to?
- Do you offer spending limits or alerts when volume rises above our normal level?
- How are our messages routed to the receiving operators?
- If our account is attacked, how do you investigate with us, and how are the messages billed?
How Digital Connect fits
Digital Connect, Interkey's business messaging platform, sends one-time passcodes over SMS. Several of the provider-side checks above are part of the platform:
- Fraud protection on your account's traffic.
- Country blocking, so your account sends only to the countries you allow.
- Spending limits for your account.
- A delivery receipt for each message.
- API access restricted to whitelisted IP addresses or a VPN connection.
- Account controls: admin and user permission levels, and two-factor login to the platform with a verification code sent by email.
- SMS sender registration with the regulator and operators, handled during onboarding.
- Pricing quoted for your volumes.
Ask us during onboarding how the country list and spending limits are set for your account. The application-side controls in this guide, such as rate limits, human checks and number validation, are still built in your own product.
When it is not a good fit: if almost all of your users are outside Saudi Arabia, or you send only a few hundred codes a month.
Questions teams ask about SMS pumping
What is SMS pumping?
It is fraud in which bots trigger your application to send SMS, usually passcodes, to numbers that attackers control, so that the attackers earn a share of the delivery revenue. It is also called artificially inflated traffic.
Is SMS pumping the same as SMS phishing?
No. Phishing messages try to trick the person who receives them. SMS pumping targets the business that sends the messages: the goal is to make it pay for messages nobody needs.
Do we pay for pumped messages?
Yes, in most cases. The messages are sent from your account and delivered, so they are billed like any other message. That is why spending limits and early monitoring matter.
Will a CAPTCHA alone stop it?
It makes automated requests harder, but it should be combined with rate limits, country rules and monitoring of codes sent against codes entered.
Does blocking countries affect real users?
Only if you have customers in the countries you block. Start from where your customers are, and review the list when you launch in a new country.
Can controls on the provider side stop SMS pumping on their own?
No. Country blocking, spending limits and fraud protection on the provider side reduce the damage, but bots still reach your sign-up and login screens. Combine them with the rate limits, human checks and monitoring in your own application.