SMS Pumping
If you ask for a phone number at signup, you've already met this fellow.
He doesn't want the account. He wants the text. A script leans on the send button, the message goes out, nobody types it back, and the script leans again. Each text is a small charge on your bill. Collected with the indefatigable patience of a metronome, the small charges are the whole business.
Dregs scores the identity behind those requests, so you can stop paying for messages nobody reads.
What Is SMS Pumping?
SMS pumping is the abuse of a phone verification or one-time code flow so that text messages are sent and the codes are never completed. Whoever requests the codes never finishes signing in, and the application that sent the messages pays the carrier. SMS pumping is also called SMS toll fraud, and in this verification sense it's a form of SMS fraud: the codes exist to run up a bill, not to let a person in.
On a SaaS product, the usual target is a public "send code" action. Signup, login, or a phone verification step calls your SMS provider, and your provider bills you per message. A real customer requests a code once, occasionally twice, and then signs in or confirms the email. A pumping script requests the code in a loop, with a devotion to the send button that no customer has ever shown. Sometimes the texts are aimed at numbers where sending is expensive, and a share of the fee flows back to whoever is generating the traffic. Sometimes the only goal is to exhaust your verification budget. Either way, what you see on the invoice is the same: codes requested, codes never completed, bill inflated.
The account, if one is created at all, is incidental, and that's what separates SMS pumping from signup bots and free trial abuse. The more industrious of these pests don't bother finishing the form at all.
The usual defenses each cover a piece of the problem, and a determined pumper walks around all of them.
| The Traditional Defense | Why It Often Fails |
|---|---|
| Limits per number | Each number stays politely under the cap, and the script simply brings more numbers. Your bill doesn't care that no single handset looked greedy. |
| Country blocks | Real customers sign up from abroad, so a hard country list punishes them. A patient pumper stays inside the countries you allowed and sends more. |
| CAPTCHAs | Solver farms clear the puzzle, and the request that follows is the one that costs money. The puzzle never sees whether anyone typed the code back in. |
| IP blocking | Proxies and shared mobile networks make an address a suggestion. The same script arrives from a fresh one whenever the last one was noticed. |
| An SMS firewall | A gateway firewall can refuse a bad route or a costly destination. It doesn't know which account in your application asked for the text, so it can't quarantine that identity or spare everyone else. |
| Manual review | The invoice is the review. By the time someone on your team reads the spike, the sends have already been billed. |
The messages leave on your account, addressed to numbers that will never answer — which is the whole of the trade.
How SMS Pumping Differs from Signup Bots and Free Trial Abuse
Three patterns hit the same signup form and want three different things. Mixing them up leads to the wrong control: a CAPTCHA for a human freeloader, a trial limit for a script that never comes back, a gateway rule for an identity your application could have stopped itself.
The nearest cousin is registration bombing, which conscripts your confirmation email to flood an inbox the attacker doesn't own. SMS pumping conscripts your verification text instead. In both cases your product was never the point. The difference is who takes the damage: a third party's inbox there, your SMS bill here.
What SMS Pumping Costs Your Business
The charge is small per text and rude in aggregate. It also arrives before any of the usual signup abuse has had time to look expensive.
The verification bill
Every unanswered code is a line on the provider invoice. Point the traffic at destinations where a text costs more, and the same script becomes SMS toll fraud rather than a nuisance.Real signups blocked
The usual reaction to a spiked bill is a spending cap or a provider block. Legitimate customers then fail at the phone step, which is a poor way to discover that a script was here overnight.A fake growth spike
Verification attempts and unfinished accounts show up as signup activity, and any decision made on that chart treats a pumping run as demand.How Dregs Detects SMS Pumping
Dregs sits outside the message path. Instead of routing texts, it scores the identity that asked for the code, from events your application already records, across four scores. The Behavior score carries send velocity, the Humanity score carries automation, and the Uniqueness score carries device clusters, while Authenticity still scores whatever profile arrived. A pumper can disguise one of those. Disguising all four at once is considerably harder. How the scores are built is covered in scoring.
Send the verification request, and the later login or email confirmation, as events. Name them however your application already names them, then map the verify send to OTP Request, or to Message Send when that outbound message is the event you track, and a successful login or email confirmation to Login or Email Confirmation. Without that mapping, a code request is just another event name.
Behavior Score
The decisive signal is velocity on the verify events, the same family of velocity checks Dregs already uses for logins and password resets. One-time code sends are counted against later logins and email confirmations on the same identity. Requests followed by a login stay quiet, and a run of sends with no completion doesn't. The Behavior score drops, and the observation shows the counts, so you can see exactly why.
Humanity Score
Pumping at volume is usually a script. The Humanity score reads device and timing evidence: headless browsers, gaps as regular as a machine, and hosting networks rather than a phone a person is holding. A passed CAPTCHA doesn't repair that. The bot detection page walks through the same signals on a signup form.
Uniqueness Score
One browser requesting codes for a series of numbers is the simple case. The Uniqueness score links those identities by device. A phone farm is built to defeat a check for one shared device: many real handsets, one operator. The cluster still shows up when the handsets share a network, a schedule, and a way of moving.
Authenticity Score
Many pumping attempts never submit a profile worth the name. When one does arrive, the Authenticity score measures whether it looks inhabited: a disposable inbox, a name assembled in a second, empty optional fields. It's a supporting signal, since the bill is explained by the sends, not by the spelling of the name.
Example: Catching an SMS Pumping Run
Here's what it looks like when a script leans on your phone verification:
No one had to read the invoice first... the loop is flagged almost instantly once the sends pile up without a completion. Because each score opens into its observations, you can see exactly why before withholding a code from a customer who simply lost the first text.
Stopping SMS Pumping
The path from detection to action is a badge, then an escalation, then a webhook your application uses to slow or stop the next send. Custom rules and lists decide the threshold, which is far less manual review than watching the provider dashboard overnight.
Slow the next send
Apply a rate limit, or hold the next code, when the Behavior score drops or the Pumping Suspected badge appears. The script's throughput collapses, while a customer who then signs in is unaffected.
Quarantine the identity
Stop provisioning, and stop sending, for identities that request codes and never complete them. The campaign returns nothing, and your user table doesn't fill up with accounts that existed only to generate traffic.
Spare ordinary retries
A second code followed by a login is normal. Keep the hard stop for the clear cases, and use the observations behind the score when a false positive would cost a signup. The evidence is already attached.
Webhooks deliver the scores and the badge to your application moments after the events land, in time to refuse the next send while it still costs money.
SMS pumping sits next to the rest of the signup mess, and the same integration covers it. Scripts that do want accounts are signup bots and fake signups. People who finish signup and come back are free trial abuse. Confirmation email used as a weapon against someone else's inbox is registration bombing. How the four scores stay separate on the account is fraud scoring.
Frequently Asked Questions
Q: What is SMS pumping?
A: SMS pumping is the abuse of a phone verification or one-time code flow so that a large number of text messages are sent and the codes are never completed. Whoever requests the codes never finishes signing in, and the application that sent the messages pays the bill. It's also called SMS toll fraud.
Q: What is SMS toll fraud?
A: SMS toll fraud is SMS pumping aimed at the message fee. The texts are pointed at numbers or routes where sending is expensive, and a share of that fee can flow back to whoever is generating the traffic. Exhausting a SaaS verification budget is the same pattern with a simpler motive. Either way, you see codes requested, codes never completed, and an inflated SMS bill.
Q: How do you detect SMS pumping on a SaaS app?
A: Compare verification sends with later logins on the same identity, and look at the device and the automation around them. Dregs lowers the Behavior score when one-time codes pile up without a completion, lowers the Humanity score when a script is driving the requests, and lowers the Uniqueness score when one device or a tight device cluster is behind the run. The Authenticity score still weighs whatever profile arrived. A strong pattern applies a Pumping Suspected badge, and escalations and webhooks then let your application slow or stop further sends with less manual review. Every score opens into its observations, so you can see exactly why.
Q: How is SMS pumping different from signup bots and free trial abuse?
A: Signup bots want accounts in your user table. Free trial abuse wants the product, and the person comes back. SMS pumping wants the message: the signup may never finish, and the damage is the verification bill rather than junk rows or a burned trial. Fake signups are a neighboring problem, and registration bombing is the email version of the same trick, with your outbound message as the weapon.
Q: Will stopping SMS pumping create false positives?
A: It can, if every extra code request is treated as an attack. People lose a text, ask again, and then sign in, and that pattern is ordinary. Dregs leaves a healthy proportion of completions alone, opens every score into its observations so you can see exactly why an identity was flagged, and supports custom rules and lists for a graduated response. Slow or hold the next send on a suspicious identity and reserve a hard stop for the clear cases, so false positives stay off customers who simply mistyped a code.
Q: Does Dregs replace an SMS firewall or gateway?
A: No. Dregs doesn't carry text messages, choose routes, or block destination countries, and an SMS firewall can still refuse a bad route. Dregs scores the identity that asked for the code, from the verification events your application already records, and a webhook tells your application when to stop sending. The two answer different questions.
Stop SMS pumping before it inflates your verification bill.
Dregs helps you detect identities that request verification codes and never sign in. The Pumping Suspected badge, escalations, and webhooks give your application the evidence to slow or stop further sends, with less manual review.
Schedule a Demo