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. The party requesting the codes does not finish signing in. The application that sent the messages pays the carrier. SMS pumping is also called SMS toll fraud, and in this verification sense it is a form of SMS fraud: the codes exist to run up a bill, not to let a person in.
The usual shape on a SaaS product 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. Sometimes the texts are aimed at numbers where sending is expensive, and a share of the fee flows back to the party generating the traffic. Sometimes the only goal is to exhaust the verification budget. For the operator paying the invoice, the pattern is the same: codes requested, codes never completed, bill inflated.
The account, if one is created at all, is incidental. That is what separates SMS pumping from signup bots and free trial abuse. An SMS firewall answers a different question: which route to refuse, not which identity in your app to stop.
The conventional defenses are built for a different question, and a determined pumper walks around them.
| The Traditional Defense | Why It Often Fails |
|---|---|
| Limits per number | Each number stays politely under the cap. The script simply brings more numbers. The bill does not 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 does not know which account in your application asked for the text, so it cannot quarantine that identity or spare everyone else. |
| Manual review | The invoice is the review. By the time a human 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 does not own. SMS pumping conscripts your verification text. In both cases the product was never the thing being used. The difference is who receives 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. Decisions made on that chart treat a pumping run as demand.How Dregs Detects SMS Pumping
Dregs is not an SMS gateway and not a firewall in the message path. It does not choose routes or carry 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. The Uniqueness score carries device clusters. Authenticity still scores whatever profile arrived. A fraudster 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 that are followed by a login stay quiet. A run of sends with no completion does not. 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 does not 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 is a supporting signal. The bill is explained by the sends, not by the spelling of the name.
Example: Catching an SMS Pumping Run
Here is what it looks like when a script leans on 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
Dregs does not send the text and does not block it in the gateway. The path 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. That is 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. 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. Your user table does not 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. The requesting party does not finish signing in. The application that sent the messages pays the bill. It is also called SMS toll fraud.
Q: What is SMS toll fraud?
A: SMS toll fraud is SMS pumping aimed at the message fee. Texts are pointed at numbers or routes where sending is expensive, and a share of that fee can flow back to the party generating the traffic. Exhausting a SaaS verification budget is the same pattern with a simpler motive. Either way the operator sees 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. Escalations and webhooks then let your application slow or stop further sends, with less manual review, and 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 the 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. Signup bots, free trial abuse, and fake signups are neighboring problems. Registration bombing is the email version of the same trick: your outbound message is 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 and ask again, 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. Reserve a hard stop for the clear cases, and false positives stay off customers who simply mistyped a code.
Q: Does Dregs replace an SMS firewall or gateway?
A: No. Dregs does not carry text messages, choose routes, or block destination countries. 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