SMS pumping is fraud in which bots fill in your sign-up or login forms so that your platform sends one-time passcodes to phone numbers the fraudster profits from, and you pay for every message. You stop it by limiting who can trigger a send, where and how often, and by watching how many codes are actually verified; an OTP verification API that ties fees to successful verifications also caps what an attack can cost you.
The same scheme is also called artificially inflated traffic (AIT) or SMS toll fraud. This guide explains how it works from the operator side, the signals that give it away, and the controls that stop it without hurting real users.
How does SMS pumping work?
The GSMA defines AIT as SMS traffic “generated for the fraudulent purpose of generating revenue associated with its delivery for certain parties in the SMS traffic chain”, as quoted in an Ericsson white paper on AIT. In practice an attack follows four steps:
- Find an open trigger. Any form that sends an OTP, a download link or a “text me” message to a number the visitor types in is a target.
- Automate requests. Bots submit thousands of numbers, usually in ranges that belong to one mobile network or to high-cost destinations.
- Route the traffic through a complicit party. Every A2P message carries a termination fee. Somewhere in the chain, a rogue operator or intermediary collects that fee and shares it with the fraudster. Twilio’s support guide describes it the same way: messages go to “a range of numbers controlled by a specific mobile network operator (MNO)” and the fraudsters “receive a share of the generated revenue”.
- Cash out. Nobody ever enters a code. The numbers may not even belong to real subscribers, and Group-IB’s analysis notes that rogue aggregators can manipulate delivery reports so the traffic looks normal.
From a carrier’s perspective, the messages are technically valid. They are submitted by your account, routed and billed like any other OTP. That is why the defence has to start in your own application.
How big a problem is SMS pumping?
The best-known public case is Twitter. In a Twitter Spaces session in December 2022, Elon Musk said the company was losing about $60 million a year to fake 2FA messages and that 390 telcos were involved, as reported by Commsrisk. In February 2023, Twitter announced that SMS two-factor authentication would be limited to paying subscribers, saying phone-number-based 2FA had been “used – and abused – by bad actors”.
You do not need Twitter’s scale to feel it. A single unprotected sign-up form can generate a month’s messaging budget in a night, because bots do not sleep and each request costs you a message.
What are the warning signs of SMS pumping?
Most attacks show up in your own data before they show up on your invoice. Watch for these patterns:
| Signal | What it looks like | Why it matters |
|---|---|---|
| Spikes to unusual countries | Sudden volume to destinations where you have few or no customers | Attackers pick destinations with high termination fees, not your market |
| Low verification conversion | Codes sent rise sharply while codes verified stay flat | Real users enter codes; bots do not |
| Sequential or clustered numbers | Numbers such as …1000, …1001, …1002, or many numbers sharing one prefix and one network | Twilio lists sequential numbers as a classic sign of scripted requests |
| Repeated devices and hosting IPs | Many requests from one device fingerprint, data-centre IPs or high-risk ISPs | Group-IB found hundreds of fake accounts created from one device fingerprint in one case |
| Odd form behaviour | Instant form completion, disposable email addresses, identical user agents | Automation leaves timing and pattern traces |
| “Good” delivery, no engagement | Delivery reports look healthy but nobody logs in | Delivery status alone does not prove a human received the code |
The single most useful metric is verification conversion by country and by network: codes verified divided by codes sent. A legitimate market is stable from day to day. A pumped market falls off a cliff.
How do you prevent SMS pumping?
No single control is enough. Layer them so that an attacker who gets past one still hits the next. Twilio’s own Verify fraud guidance recommends a similar mix and notes that customer-side controls are essential.
Rate limit per IP, device, number and account
Set limits on every key you can see: requests per phone number per hour, per IP address, per device fingerprint and per session. Add exponential delays between resends. Tight limits on a single number stop brute-force resends; limits per IP and device stop bots cycling through number ranges.
Allow only the countries you serve
If you only operate in five markets, do not let your form send to 200. Keep a country allowlist and review it whenever you launch a new market. For markets you do serve, compare prefixes against the networks you expect to see.
Put a bot check in front of the send
Add CAPTCHA or a similar human check before the first send, or at least on repeat attempts, and combine it with device and IP reputation. Block requests from known hosting ranges where your users would not normally be.
Check the number before you pay to message it
An HLR lookup tells you whether a number is a live mobile line, which network it is on and whether it has been ported. Reject landlines, unreachable numbers and networks that do not match the country the user selected. With SMS.to, a single lookup is one call:
curl -X POST https://hlr.sms.to/api/v2/lookup \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"number": "+35799585001"}'Our guide to HLR and MNP checks covers which fields to act on.
Monitor conversion and alert on it
Alert when conversion in any country or network drops below its normal band, and when volume to a destination jumps above its usual range. Automate the first response: pause sends to that destination or require a stronger human check until someone reviews it.
Choose pricing that follows outcomes
If your verification provider charges a fee only when the user verifies, an attack that produces no verifications costs less. It does not make SMS free: on most platforms, including ours, the SMS itself is billed when it is sent. So pricing reduces the damage; rate limits and allowlists prevent it.
Shorten expiry and limit attempts for risky actions
Short code lifetimes and a small number of attempts per code reduce the value of every request. Use shorter expiry for password resets, payout changes and other sensitive actions.
What should you do during an active attack?
- Block the destination. Remove the affected country or prefix from your allowlist immediately.
- Tighten limits. Lower per-IP and per-device thresholds and force a CAPTCHA on every send for the affected flow.
- Cancel pending verifications you know are fraudulent so they cannot trigger retries or fallback sends.
- Export the evidence. Keep request logs, IPs, numbers and timestamps. Your provider needs them to investigate routes.
- Talk to your provider. Share the time window and destinations so they can review the traffic with their carriers.
If you also see failed or unexpected delivery statuses during the attack, our guide to SMS error codes explains what each one means.
How SMS.to helps you stop SMS pumping
The SMS.to Verify API is built around the controls above:
- Billing tied to outcomes. For WhatsApp, Viber and Telegram you pay the channel fee only if the message is delivered. For SMS you pay the send fee when the message is sent, even if it is not delivered. In both cases the Verify fee is charged only when the OTP is verified, and channels that are not attempted are not charged.
- Channels and fallback. Choose SMS, WhatsApp, Viber or Telegram and set the order. Starting with an app-based channel where it is widely used, and keeping SMS as the safety net, reduces how much SMS an attacker can trigger.
- Rules per request. Set expiry, code length and format, templates and language once in a Verify App, then override them per request, for example a shorter expiry on a risky action. The application settings also include a maximum number of tries per code.
- Webhooks, logs and charts. Delivery and verification webhooks, searchable logs and statistics show completion and drop-off, so a falling conversion rate is visible quickly.
- Cancel on demand. A cancel endpoint invalidates an active verification you no longer trust.
- Number checks. The HLR and MNP lookup API returns reachability, portability, MCC and MNC and number type before you send.
We also recommend the same best-practice controls on the Verify API page: rate limits for user, IP and device, shorter expiry for risky actions, HLR or MNP lookups, and a human check such as CAPTCHA on repeat attempts. If you want a second pair of eyes on your flow, our team can review your country mix and limits with you.
FAQs
Is SMS pumping the same as artificially inflated traffic?
Yes. SMS pumping, artificially inflated traffic (AIT) and SMS toll fraud describe the same scheme: generating fake message traffic so that someone in the delivery chain earns termination revenue.
Can a CAPTCHA alone stop SMS pumping?
No. CAPTCHA raises the cost for bots, but some attacks use human solvers. Combine it with rate limits, country allowlists, number checks and conversion monitoring.
Do delivery reports show that a message reached a real person?
Not on their own. A delivery report confirms the network accepted the message for a number. Verification conversion, whether the code was entered, is the better signal of a real user.
Does paying only for successful verifications remove the risk?
It reduces it. With SMS.to Verify, the Verify fee applies only when the user verifies and failed app-channel attempts are not charged, but SMS send fees still apply when a message is sent. You still need rate limits and allowlists.
Want to test these controls on your own sign-up flow? Create a free account, no credit card needed, and send your first verification in minutes.
