SMS pumping, also called artificially inflated traffic, is fraud that exploits any flow where a stranger can cause you to send a message. The attacker drives large volumes of passcode or verification messages to numbers on routes where they, or a party they work with, earn a share of the termination fee. You pay for every message. Nobody reads any of them.
Why does anyone do this?
Because sending an SMS to certain destinations moves money, and some of it can be captured downstream.
Terminating a message costs the sender and pays parties along the route. Where an attacker controls or is paid by a party on that route, generating traffic to it is directly profitable. They do not need to read the passcodes or compromise any account: the send itself is the product.
That is what makes pumping different from most abuse. There is no account takeover to detect and no data to protect. The damage is the bill, and it accrues while every individual request looks legitimate.
What does it look like?
A spike with a distinctive shape, and the shape matters more than the size.
- Concentrated on unusual destinations. Requests cluster on country codes and number ranges you would not normally serve, often ones with high termination rates.
- Almost no completions. Passcodes are requested and never entered, so the ratio of sends to successful verifications collapses.
- Numbers that look synthetic. Sequential or patterned ranges rather than the scatter of real customers.
- A source that is hard to block by identity. Requests arrive from many addresses, because the flow being abused does not require an account.
The last point is why per-user rate limiting is weak on its own: there is no user. The abuse lives in the part of your product that deliberately works for strangers.
How do I stop it?
Four measures, roughly in order of how much they buy for the effort.
- Restrict destinations to the ones you serve. The single most effective control. If your customers are in five countries, sending to the other two hundred is loss with no upside. Bird gates sending per destination, so a country has to be enabled before traffic can reach it at all.
- Rate limit on what you have, not on who they are. Per phone number, per number prefix, per address, per session. Fraud that cannot be tied to an account can usually still be tied to a destination range.
- Add friction ahead of the send. A challenge before a passcode is requested costs a real user a moment and costs an automated attacker their economics.
- Watch the completion ratio rather than the volume. Sends rising is ambiguous. Sends rising while completions stay flat is the signal, and it moves before the invoice does.
Bird also enforces its own ceiling underneath whatever you configure. The verification sending guide puts it plainly:
Independent of your settings, Verify enforces platform caps to keep OTP traffic from being weaponized, whether against your wallet (SMS pumping) or against a victim's inbox
That is worth knowing for two reasons: a misconfigured limit of your own is not the only thing standing between you and a bill, and a cap you did not set may be what you are hitting if legitimate traffic is being refused.
Is this the same as a passcode-flooding attack?
Related, and aimed at a different victim.
The same quotation names both. Pumping is aimed at your wallet: the attacker wants messages sent, and the recipient is incidental. Flooding is aimed at a person's handset: the attacker wants one victim buried in passcode messages, often as harassment or to bury a real alert.
The defences overlap, which is convenient, but the detection does not. Pumping shows as many destinations and no completions; flooding shows as one destination and many requests. A per-recipient limit catches the second and does nothing about the first, which is why destination restriction and per-recipient limits are both worth having.
For the surrounding context on verification flows, what does OTP mean covers the mechanism this abuse rides on.