SMS pumping fraud: why a phone verification form can quietly drain a classifieds site's messaging budget

The SMS bill arrives, and it is three or four times what it normally is. Nothing else moved: the number of new advertisers looks ordinary, the listings board looks ordinary, the payment account shows no unusual activity at all. The natural first guess is a billing error, so the operator opens a support ticket with the messaging provider and waits. The answer that comes back is worse than a billing error, because it means every one of those messages actually went out, and the provider is not going to reverse a charge for a text that was genuinely delivered.

What happened has a name: SMS pumping, also called SMS toll fraud or artificially inflated traffic. It targets exactly the kind of form a classifieds directory relies on to keep listings honest, the one where an advertiser types a phone number and taps a button that says send code. This blog has already covered why that check exists in the first place, since phone and identity checks are what actually keeps a listings board from filling up with fake accounts. The fraud described here does not care about the listing at all. It cares only about the button.

How the fraud actually works

SMS pumping is a variant of a much older telecom scheme called international revenue share fraud, and the mechanism is not subtle once it is laid out. A fraudster sets up an arrangement, formal or exploited, with a carrier that earns money on message termination fees, often in a country far from where the business operates. The fraudster then uses bots to trigger the site's send code action over and over, pointed at real phone numbers that sit on that carrier's network. Every one of those numbers is a live SIM card capable of receiving a text, so the messages are not bouncing or failing. They are arriving.

Because the messages are genuinely delivered, there is no fraud signal on the telecom side that would make a carrier refuse to send them or a messaging provider refuse to bill for them. The carrier collects a termination fee for each message it delivers, and under the revenue-share arrangement, a cut of that fee flows back to whoever is running the bot traffic. The business paying for the messages is, from the network's point of view, simply a customer who asked for a very large number of texts to be sent. Nobody upstream has a reason to stop it on its own.

No party upstream of the business is motivated to stop this on its own, and that is the detail worth sitting with. The carrier is being paid for messages it is actually delivering, so from its own records nothing looks wrong. The messaging API sits between the business and the carrier and bills faithfully for what it was asked to send. The responsibility for noticing that the traffic hitting a signup form does not look like advertisers ends up sitting with the one party that has both the motive and the visibility to notice it: the business paying the bill.

The part that makes this attractive to fraudsters, and expensive for a directory, is that none of it requires a real account. The bot does not need to complete the verification, does not need to post a listing, and does not need the code to ever be typed into a box. It only needs the site's form to accept a phone number and dispatch a message. A signup flow that never finishes a single successful verification can still generate a full month of billable traffic.

Why the bill arrives before anything else does

Most SMS and verification APIs, Twilio's among them, charge per message sent or attempted, not per verification that is actually completed. That billing model is not a design flaw specific to one vendor, it is how the underlying telecom network already charges the business for delivering a message, and the API simply passes that cost along. The practical effect is that a fraud campaign costs the operator money from the very first message, hours or days before anyone notices that the completion rate on the signup form has quietly collapsed.

The scale this can reach is not theoretical. In December 2022, Elon Musk stated publicly, during a Twitter Spaces session, that Twitter was losing roughly sixty million dollars a year to exactly this scheme, and named around 390 telecom operators he said were involved in pumping fraudulent two-factor authentication traffic toward the platform. That figure was Musk's own claim rather than an audited company disclosure, but the response was real and reported well beyond fraud-prevention marketing: Twitter cut ties with carriers whose traffic looked fraudulent, and a few months later restricted free SMS-based two-factor authentication to paying subscribers specifically because of the cost. A company with Twitter's volume and technical staff still took months to notice and react. A directory running on a single independent messaging account, with no fraud team reading the logs every morning, has far less warning built in.

The number that actually reveals the fraud is not the volume of messages sent, since a real marketing push or a genuinely busy week can also raise that number. It is the ratio between codes sent and codes successfully entered. A completion rate that quietly drops from what it normally is, even while total volume climbs, is the signal that the traffic hitting the form is not made of people who intend to finish signing up.

Why an open listing form is exactly the target profile

A classifieds directory has a structural reason to make the send code button easy to reach: anything that adds friction to a first-time advertiser's signup costs conversions, and this blog has already gone through why that friction is worth guarding carefully at the door even before payment enters the picture. A phone verification step that is quick and welcoming to a legitimate advertiser is, by the same design, quick and welcoming to a bot that has no intention of becoming one.

The exposure is also sharper for a smaller, independent operator than it looks from the outside. A large platform negotiates volume pricing and usually has a contract that includes some fraud monitoring as part of the relationship. A directory running its signup flow through a standard pay-as-you-go messaging API has no such cushion: every fraudulent message is billed at the same per-message rate as every legitimate one, straight through to the card on file, with nothing absorbing the spike until a human notices the invoice.

None of this means blocking a country prefix is a decision to set once and forget. A directory that expands into a new city, or picks up advertisers who travel, can find a legitimate cluster of signups sitting behind a prefix that was blocked for good reason a year earlier. Treating the list of restricted prefixes as something to revisit every few months, alongside whatever else gets reviewed on that cadence, keeps the defense from quietly turning into a second source of lost signups.

This is a different failure from the one this blog described when it covered why a verification email sometimes never reaches an advertiser's inbox at all. That piece was about a message that fails silently, costing nothing but a lost signup. This one is about a message that succeeds loudly, arriving exactly as intended, and costing real money every single time it does.

What actually stops it

The first layer is rate limiting on the send code action itself, enforced on the server rather than trusted to the browser: a hard cap on how many codes a single IP address, session, or phone number can request within a short window. This alone will not stop a distributed bot network using many IP addresses, but it removes the cheapest, laziest version of the attack and forces anything more determined to work harder.

The second layer is a bot check placed before the send action fires, not after: something that confirms a human triggered the request without asking that human to solve anything annoying, such as an invisible challenge that scores the request in the background. Because the entire fraud depends on triggering sends automatically and at volume, anything that meaningfully slows down automated triggering directly reduces the cost of the attack, even if it lets some bots through.

The third layer is applying friction, not necessarily an outright block, to phone number prefixes that a directory's real advertiser base essentially never uses. A site serving cities in one country has little reason to accept, without a second check, a wave of verification requests aimed at a country code where the advertiser base has never had a meaningful presence.

The fourth layer is turning on whatever fraud protection the messaging provider already offers rather than assuming the default settings cover it. Twilio, for one concrete example, offers a feature called Verify Fraud Guard that analyzes traffic patterns to detect and automatically block suspected pumping activity, and it ships enabled by default for Verify customers, with adjustable protection levels that trade a small rate of false positives for a higher rate of blocking. Confirming a feature like this is switched on, and set to a level appropriate for the site's real traffic, costs nothing and catches what the site's own logic will miss.

The fifth layer is a spend alert set with the provider directly, not discovered a month later on an invoice. A threshold that fires a notification once daily messaging spend crosses a level that has no ordinary explanation turns a fraud campaign that would otherwise run silently for weeks into one that gets noticed within hours.

What to do this week

Pull last month's messaging logs and calculate the actual ratio of codes sent to codes successfully verified, not the total volume alone. A number that looks fine in aggregate can still be hiding a specific week or a specific country prefix where the ratio collapsed. That single calculation will tell an operator more about whether this fraud is already happening than anything else in this piece.

Then check three settings directly with the messaging provider: whether fraud protection like Fraud Guard is active and at what level, whether a spend alert exists and at what threshold, and whether the send code endpoint has a server-side rate limit that does not depend on anything the browser can be told to ignore. None of these three checks require new software or a new vendor relationship, only the time to ask the provider directly and read the answer that comes back.