An SMS pumping attack doesn't break in. It signs up. Every request looks like a legitimate user asking for a verification code, because that's exactly what it is — the send is the attack, and the attacker's payout is the send itself.
The economics
The attacker controls, or has a revenue-share deal with, a block of premium phone-number ranges. Every SMS that terminates on those ranges pays a termination fee, and the attacker collects a cut of it.
So they don't need to steal anything. They just need your backend to fire OTPs at their numbers. You pay your SMS provider full freight; they pocket their share of the carrier fee. It's fraud where the victim's own infrastructure does all the work.
Sourcing the numbers
The number ranges are cheap and plentiful. Attackers rent or provision blocks in countries where termination fees are high and oversight is thin, then feed them into your signup form, password reset, or "resend code" flow.
There is no clever payload. A valid-looking international number in the form field is the entire exploit.
The patient cadence
The tell that isn't there: speed. A competent pumping operation runs slow and wide, spreading sends across many numbers, many source IPs, and long intervals — deliberately staying under any single rate limit you've set.
Ten sends an hour across a thousand numbers doesn't trip a per-account throttle. It doesn't look like a spike. It looks like modest, healthy signup growth. That's the point.
Why it stays invisible
Each request passes every check you have. The number is well-formed. The account is new but plausible. The velocity is low. Nothing in the send path distinguishes a real user who will type the code from a farm that never will.
So it runs. For weeks. The first hard signal usually arrives as a line item on the SMS invoice — a country you don't serve, a volume you can't explain, a bill that's already been paid.
The only cheap place to stop it
Once the message leaves your provider, you own the cost. Refunds are rare and slow. Every layer downstream is cleanup.
The one place to stop an AIT attack cheaply is before the send — a single pre-send decision that rejects impossible and premium-rate destinations for free, watches velocity across account, number, IP, and network at once, and scores networks by whether their codes ever get entered. A denied send costs nothing, because it never happened.
The invoice is the wrong place to discover the attack. The /v1/check call is the right one.