SMS Pumping Fraud: Why Your Verification Endpoint Is the Cheapest Thing to Attack

Your verification endpoint is the cheapest thing an attacker can make you pay for, and the bill arrives weeks after the damage is done. SMS pumping — also called artificially inflated traffic, or SMS toll fraud — turns a legitimate OTP flow into a revenue channel for someone else, and it does so without breaching anything. No credential is stolen, no data is exfiltrated, no alarm fires. The only symptom is a messaging bill that grows faster than the business does.

That is what makes it worth understanding before it happens to you. The attack does not look like a security incident, so the usual detection does not catch it. It looks like a traffic spike, and traffic spikes are supposed to be good news.

The scale is not marginal. Enea, which studies this fraud directly, puts roughly 5% of all international A2P messaging traffic into the artificially-inflated category and estimates the cost to brands between 2022 and 2024 at at least $2.4 billion — while noting that most of the traffic is not generated on brand websites at all. That distinction matters: the scheme is profitable enough that it now runs through compromised provider accounts, exploited APIs, and intermediaries as well as through public forms. Industry projections published in 2026 continue to place artificial inflation among the fastest-growing categories of messaging fraud. This is a measured, ongoing loss rather than a theoretical risk, and it is concentrated on exactly one type of endpoint.

The Mechanism, Step by Step

The attack is simple enough to describe completely, which is part of why it spreads so easily. There is no exploit and no privilege escalation. It is an abuse of a paid action that you made publicly available.

1. The attacker identifies a form that sends an SMS. Any flow where submitting a phone number triggers a paid message: registration, login, password reset, new-device confirmation, transaction approval. Public-facing and unauthenticated by design, because real users need to reach it before they are logged in.
2. A script submits that form thousands of times. Each request carries a phone number the attacker controls, or one that routes into a number range they profit from.
3. Your system sends a real message every time. It has no reason to refuse. The number is well-formed, the request is valid, and the code is generated and dispatched as designed.
4. Nobody completes the verification. The attacker never uses the code. The only thing they wanted was the outbound message, which has now been billed to you.
5. The messages terminate on premium or revenue-shared routes, where a portion of the charge flows back to the party that originated the traffic — sometimes through intermediaries or carriers that participate in the scheme.

Repeat at volume and the economics invert. The attacker's cost is a script and a list of numbers. Your cost is a per-message charge multiplied by however many requests they choose to send, and you have agreed in advance to pay it.

Why Verification Is the Target and Not, Say, Marketing Mail

Attackers concentrate on OTP endpoints for four structural reasons, and each one is a property of the flow rather than a flaw in the implementation.

Compare that with a marketing send. It goes to a list you built, on a schedule you choose, after review. The attacker cannot redirect it anywhere. A verification endpoint inverts all four properties at once, which is why the same abuse pattern appears across industries that share nothing else.

An additional factor makes it worse than a pure cost problem. High-cost destination countries and specific number ranges are where the margin concentrates, so the attack naturally produces traffic concentrated in a handful of destinations you may not even serve. A business operating in three countries can find itself paying for messages to a dozen. The unit economics are what make the volume dangerous: a verification message to a high-cost destination commonly costs somewhere in the region of ten to fifty cents, and a script can request thousands per hour. That is the multiplier — a per-message price that would be unremarkable in normal use, applied to a request rate no legitimate user base would ever generate.

The Warning Signs Are In Your Own Data

Pumping is invisible if you only look at messaging volume, and obvious if you look at it alongside outcomes. The single most diagnostic comparison is between messages sent and verification completed.

The completion-rate metric deserves particular attention because it is cheap to instrument and almost nobody watches it. Requiring that a code be entered before counting a verification as an attempt changes the picture entirely: a pumping attack converts a rising volume curve into a collapsing success ratio, and that is a signal you can alert on. Published detection guidance converges on the same two-way threshold — legitimate OTP flows typically verify in the region of 70–95% of the time, while pumped traffic sits well under 20%. A per-destination rate that drops below roughly a third deserves investigation; below a tenth is a strong indication of fraud. Crucially, the useful comparison is by destination, not globally: a global average will stay comfortable while one country's ratio collapses, because the attack is aimed rather than distributed.

The Countermeasures, Roughly in Order of Value

No single control stops this. Attackers adapt routes, numbers, and request patterns as soon as one layer starts blocking them, so the defence is a stack of independent limits rather than one strong gate.

Put something cheaper in front of the SMS send. The highest-leverage change is usually to move the message later in the flow. A page that dispatches a code the instant a phone number is typed is trivially abusable; one that requires an email confirmation, a password, or a bot check first costs the attacker real effort per attempt. Anything that makes the per-request cost non-zero for the attacker improves the economics immediately.

Rate-limit on several axes at once. Per number, per IP, per device, per account. IP limits alone are insufficient, because distributed bots and rotating proxies make each request look new. Combinations are far harder to defeat than any single counter, and normal retry behaviour can be preserved as an exception rather than by leaving the limit loose.

Control destinations instead of accepting all of them. If your product serves specific markets, allow those and block the rest by default. Pumping concentrates in high-cost countries and number ranges, so destination control removes the most profitable attack surface at the cost of a manual review process for genuine exceptions. This is the control that most reliably caps the worst-case bill.

Validate the number before paying to message it. A well-formed number is not a reachable number. Checking syntax, domain and MX records where applicable, and — for phone specifically — number type and range flags invalid or suspicious destinations before a message is billed. Since every unnecessary send has a direct cost, this converts waste into savings even when there is no attack in progress.

Set spending limits with automatic action, not just alerts. An alert tells you about a problem you may not see for hours. A volume threshold that pauses sending for an affected application or route limits the damage window to minutes. Configure both: warnings at a level that invites investigation, hard limits above it.

Keep a stop switch ready and tested. During an active attack you need to pause sending for one application, country, or route without taking the product down entirely. This is a last-resort control rather than a substitute for rate limits, and its value is entirely in whether it works under pressure — so test it before you need it.

Keep credentials server-side. An SMS API key embedded in client code hands the attacker a free send capability with no rate limit of yours in the path. Sending must be authorised by your backend, on every request, with no exceptions for convenience.

Where SMS Stops Being the Only Option

One structural improvement is worth separating from the security controls, because it changes the risk profile rather than the detection.

SMS is expensive per message, universal, and reachable by anyone who knows a number — which is exactly what makes it the preferred target. Other verification channels trade some reach for a materially different exposure. Email costs a fraction of an SMS and has no per-message revenue-sharing route to abuse. Authenticator apps and passkeys cost nothing per verification and cannot be pumped at all, because there is no message to send. WhatsApp and voice can be appropriate where the user base is already there.

The practical conclusion is not to abandon SMS, which remains the only channel that reaches every user without an install. It is to route by risk: reserve SMS for users who need it, prefer cheaper channels where the user journey allows, and make sure the SMS path is the one with the tightest limits rather than the one with the loosest.

Why This Is a Cost-Control Problem Before It Is a Security Problem

The framing affects who owns the fix.

Treated as a security incident, pumping is hard to triage. There was no intrusion, no vulnerability to patch, no indicator of compromise to hunt. The security team correctly reports that nothing was breached. Treated as a cost anomaly, it is straightforward: a spend line moved faster than its driver, and the driver can be measured.

That is why the most effective implementations pair the controls above with a finance-adjacent metric — cost per completed verification rather than cost per message. A pump raises the former and leaves the latter looking unremarkable, and the ratio makes the problem visible to everyone who needs to act on it.

The other reason to treat it as an operations problem is that prevention is entirely within your control. You cannot stop someone from submitting your form. You can decide what a submission costs you, and how many you are willing to absorb before the system changes its own behaviour.

Choosing a Platform That Exposes the Signals

The controls available to you are bounded by what your messaging provider lets you see and change, so the evaluation criteria are specific rather than general.

Four things are worth checking before committing, in rough order of how much they limit the damage. Whether you can restrict sending by country and route, since that caps the worst case. Whether frequency limits can be set per number and per IP independently, rather than through a single global throttle. Whether volume thresholds can pause sending automatically or only notify. And whether delivery events and completion data are exposed through an API, because a signal you cannot export is a signal you cannot alert on.

uSpeedo is SurferCloud's communications platform, and it treats SMS as a destination-and-route problem rather than a single flat rate. Pricing for global SMS is quoted around your destinations, with rates varying by country, operator, message type, and volume, and the commercial terms are negotiated with route-specific evaluation — which is the shape of pricing you want if destination control is going to be one of your defences, because it makes the cost of each route visible instead of averaging it away. Email sending is available through a console, an API, and an SMTP relay, so the same access model applies whether a message originates from a marketing tool or from your own application code, and it is priced from $0.20 per 1,000 messages at qualifying volume tiers — a useful reference point for comparing what an SMS-heavy verification flow actually costs against the alternatives above.

One further detail matters if you also send email, which most products do. The same platform includes list validation with multi-layer checks, and the platform reports validation outcomes in the categories that decision-making needs: valid, risky, invalid, and uncertain, with uncertain results not charged. For verification specifically, that division is the useful one — an invalid address should never be sent to, and an uncertain one should be handled by policy rather than by guesswork.

If you are evaluating the platform for verification traffic specifically, the uSpeedo overview sets out the channels, the pricing model, and the integration options. The trial offering is the reasonable way to measure your own completion rate against the baseline before committing, since the number that matters is particular to your user base rather than comparable across products. And if verification is one part of a larger workload, the cloud server range covers the compute side.

The general principle holds with any provider: choose the platform that lets you cap the loss, not the one with the lowest headline rate per message. A cheaper per-message price multiplied by an unbounded request rate is not a saving.

FAQ

What is SMS pumping?
An attacker triggers large volumes of OTP or verification messages to numbers they control or that route through premium and revenue-shared paths. The business pays for every message; the attacker never completes a verification and extracts value from the routing.

Is this a security breach?
No. No account is compromised and no data is taken. It is abuse of a paid action and is better classified as fraud and cost control, which is also why security tooling often misses it.

How do I tell pumping apart from genuine growth?
Compare messages sent with verifications completed. Real growth raises both. Pumping raises only the first, and the completion rate falls at the same time.

Will rate limiting alone stop it?
Rarely. Distributed sources and rotating proxies defeat single-axis limits. Combine per-number, per-IP, per-device, and per-account limits, and add destination controls, which are usually the more effective constraint.

Should I just switch off SMS?
Usually not — it reaches every user without an install. Route by risk instead: use it where it is needed, prefer cheaper channels where the journey allows, and apply the tightest limits to the SMS path.

What is the fastest single change I can make?
Move the send later in the flow so something cheaper must be completed first. It raises the attacker's cost per attempt immediately and requires no new tooling.

How quickly can this become expensive?
Within hours. The attack runs at machine speed while the invoice arrives on a monthly cycle, so the window between onset and discovery is the entire exposure.

Summary

SMS pumping exploits a property of verification rather than a defect in it: the endpoint must be reachable by unauthenticated users, every request costs money, and the sender chooses the destination. Those three facts together are enough to turn a legitimate flow into someone else's revenue, and none of them can be removed without breaking the flow itself.

The response is therefore layered. Make the send expensive for the attacker by requiring something cheaper first. Limit requests across several axes rather than one. Restrict destinations to the markets you actually serve. Set volume thresholds that pause sending rather than merely reporting after the fact. Watch the ratio of messages sent to verifications completed, because that is the number that moves first and the one almost nobody instruments.

The most useful mental adjustment is to stop treating a sudden rise in verification traffic as a sign of growth. When volume climbs and completion does not, the correct assumption is that you are paying for someone else's traffic — and the metric that detects it costs nothing to add.