If you send SMS one-time codes, there's a decent chance you're paying scammers to phone-spam themselves on your dime. It even has a name: SMS pumping. And it's not a rounding error — Elon Musk claimed Twitter was losing ~$60M/year to fake 2FA traffic before they killed SMS 2FA for free accounts.
Here's how the scam works, why SMS 2FA is structurally expensive, and why flipping the direction — mobile-originated (MO) 2FA, taken to its logical end over iMessage — fixes both the cost and the fraud at once.
What is SMS pumping?
SMS pumping (also called AIT — Artificially Inflated Traffic, or SMS toll fraud) is a scheme where bad actors abuse a form that sends SMS one-time codes. They pump thousands of phone numbers — usually premium ranges they secretly control with a telecom — into your "send me a code" endpoint.
You pay for every one of those messages. A cut of that termination fee flows back to the fraudsters via the carrier. The "users" never log in. They were never users. The entire point was to make your verification endpoint dial a meter that pays them.
The structure that makes this possible is simple: you, the company, send (and pay for) the message. Every code is revenue for someone in the delivery chain — so there's a direct financial incentive to trigger as many as possible.
Why SMS 2FA is expensive even without fraud
Even with zero abuse, application-to-person (A2P SMS) is a bad cost curve:
You pay per message. Volume spikes — a launch, a bot attack, an international audience — turn into surprise bills.
International is brutal. Cross-border A2P carries steep carrier surcharges that vary wildly by destination.
Carrier fees and registration overhead. In the US you're funneled through A2P 10DLC registration, brand vetting, and per-segment fees before you send a single legit code.
So your 2FA line item is pay-per-event, unpredictable, and exploitable. Three bad properties for something that's supposed to be boring infrastructure.
The Twitter/X case
This isn't theoretical. When X announced it was removing SMS 2FA for non-paying users, the stated reason was fraud at scale:
A company that size could "fix" it by paywalling a security feature. Most teams can't — and shouldn't have to make 2FA a paid tier just to dodge a billing exploit.
The fix: flip the direction (mobile-originated 2FA)
Here's the key insight. SMS pumping only works because the company sends the message. That outbound, pay-per-code flow is the thing being gamed.
So flip it. In mobile-originated (MO) 2FA, the user sends a message to you to prove possession of their device. There's no outbound code to pump, no per-message payout to harvest, and nothing for a bot farm to monetize. The incentive that powers the entire scam disappears.
MO verification has been around (think shortcodes), but shortcodes are clunky, region-locked, and still cost money to provision. The modern version is much nicer.
Taking it further: reverse 2FA over iMessage
We built a live demo of this. Instead of us texting you a code to type back, you text a one-time code to us from your own iMessage — and we verify you the instant the message lands.
👉 Try it:
If you want to build it into your own auth flow, Blooio is an iMessage API for developers — REST API, webhooks, and SDKs. Start free — no credit card, no A2P registration, no DUNS.
SOCIAL SHARE CARD GENERATOR