A verification endpoint can look healthy in application metrics while steadily draining the messaging budget. Requests arrive, the SMS provider accepts them, and the application records successful sends. Only later does someone notice that registrations, logins, or checkouts never followed the traffic. That pattern is often SMS pumping, also called artificially inflated traffic, and it targets the business logic that triggers messages rather than the SMS gateway itself.
The practical answer is to stop treating this as only a telecom rate-limit problem. Protect the web action before it reaches the messaging provider, combine network signals with browser and device evidence, bind verification to fresh server-checked state, and roll out enforcement in Observe mode. That approach reduces cost exposure without forcing every legitimate customer through a CAPTCHA.
Table of Contents
- The Mechanics of SMS Pumping Fraud
- Identifying Attack Indicators and Logging Signals
- Technical Mitigation Patterns for Web Actions
- Integrating Verification Across Your Stack
- Rolling Out Defenses with Observe Mode
- Real-World Scenarios and Sample Detection Rules
- Securing High-Value Actions Without Friction
The Mechanics of SMS Pumping Fraud
SMS pumping starts with a public action that causes a business to send a text. The action might be an OTP request, a signup form, a password reset, an app-download link, a promotional campaign, or a survey endpoint. Bots submit phone numbers at scale, and the application follows its normal path because each request can look like a valid customer interaction.
The attacker's objective usually isn't to take over the account. It's to create message volume. Destinations are selected where termination fees or revenue-sharing arrangements make delivery valuable to someone in the telecom chain. The business pays for each message, while the attacker receives a share of the resulting revenue. MITRE's description of telecommunications fraud documents this pattern as abuse of a victim's messaging infrastructure for financially motivated traffic.
Why the economics change the defense
A conventional account takeover campaign tries to obtain access. A pumping campaign tries to complete the trigger that sends the message, then repeats it. That distinction matters because a successful OTP delivery can represent a successful attack even when no account is created and no code is entered.
The mechanical flow is straightforward:
- Discovery: An attacker finds a public endpoint that sends an SMS.
- Automation: A script submits phone numbers, often across many sessions and IP addresses.
- Message generation: The application asks its provider to deliver an OTP or another text.
- Revenue extraction: The attacker benefits from traffic routed to profitable destinations.
- Cost transfer: The business absorbs the delivery charge and the operational burden.
The strongest business indicator is a divergence between send volume and downstream conversion. A large number of messages with almost no completed registrations, logins, or transactions points to abuse, especially when destinations cluster by country code, prefix, carrier, or adjacent numbers. Twilio describes one concrete pattern as bursts sent to sequential numbers on the same network, while Infobip's SMS pumping glossary also identifies sequential phone numbers as a useful clue.
Scale makes the exposure hard to dismiss. Twilio reporting cited by MediaPost measured SMS pumping at 1.1% of global SMS traffic in October 2023 and 5.4% of international traffic outside the U.S. and Canada. The same report cited a Mobile Ecosystem Forum projection that A2P SMS would reach 1.62 trillion messages per year by 2025, alongside industry summaries estimating 20 billion fake A2P SMS messages in 2023, about 5% of A2P SMS traffic, and approximately $1.16 billion in business spending on those messages.
The common mistake is to protect the code itself while leaving the message trigger open. Replay protection still matters for intercepted requests, so teams should understand the difference between pumping and a replay attack. But the first control point is earlier. A request that never earns permission to invoke the SMS provider cannot generate a delivery charge.
Identifying Attack Indicators and Logging Signals
Raw send rate is useful, but it isn't enough. A legitimate campaign can create a sharp increase in traffic, while a distributed pumping operation can keep each individual IP below a basic threshold. Detection works better when the system compares the request, the client, the destination, and the business result in one event record.
Start with a rolling baseline for each message-triggering workflow. Track OTP sends separately from password resets, marketing messages, app links, and chatbot replies. The alert should compare current activity with the normal behavior of that route, not only with an organization-wide total.
Signals that belong in the event record
Log the following fields before the SMS provider is called:
- Action context: Record the route, product flow, account state, session identifier, and whether the request came from signup, login, checkout, or another action.
- Destination context: Store country code, carrier or prefix where available, number type, and whether neighboring or sequential destinations are appearing.
- Client context: Preserve IP reputation, autonomous system information, device or browser identifier, user agent, cookie state, and browser-proof results.
- Velocity context: Count attempts by IP, phone number, prefix, account, device, session, and network cohort over several windows.
- Outcome context: Join send events to code verification, registration completion, login completion, transaction completion, delivery status, and provider cost.
A strong benchmark combines these values into an anomaly score. Arkesel's guidance on SMS pumping prevention describes watching for bursts greater than about 10 times the seven-day baseline, a collapsing verify-to-send ratio over short windows, and destination activity outside the markets the business serves. Those signals are more informative together than in isolation.
Why destination and conversion signals matter
An IP-only rule breaks down when attackers use residential proxies. A campaign can distribute requests across apparently ordinary home connections while concentrating the economic activity on one prefix, carrier, or destination region. Sequential numbers are especially valuable because ordinary users rarely request codes for adjacent numbers in a short period.
Use alert combinations rather than a single hard block. For example, a request may be low risk if it comes from a known browser, a normal country, and a returning account. The same request deserves stronger treatment when it arrives from a new device, targets an unusual destination, follows a burst above the rolling baseline, and produces no completed verification.
Teams can also compare their logging design with methods for mirroring production traffic patterns so detection rules are tested against realistic request sequences rather than isolated synthetic calls. The objective is to reproduce the relationship between request velocity, client state, destination selection, and business completion.
Keep a separate label for a proposed block, a provider rejection, a verification failure, and a failed business operation. Without those distinctions, dashboards can make a control look effective just because it moved the failure downstream. A useful review also covers e-commerce fraud detection, because the same request-quality signals can affect checkout and account flows even when no SMS is sent.
Technical Mitigation Patterns for Web Actions
Traditional controls still have a role, but they should not carry the whole defense. IP reputation can identify known infrastructure, and per-IP rate limiting can stop unsophisticated bursts. Neither control proves that the browser initiated the request legitimately, and both weaken when an attacker distributes traffic through residential proxies.
A practical design uses several layers with different failure modes.
What network controls do well
Network controls are cheap and close to the edge. They can reject obviously abusive sources, reduce request volume before it reaches application servers, and provide an emergency response during a visible spike. Country and carrier policies can also make sense when a product genuinely serves a defined market.
Their weakness is identity ambiguity. An IP address may represent many legitimate users, and a residential proxy can make automated traffic look geographically ordinary. A phone prefix block can stop one campaign but may also reject real customers, while an attacker can move to another prefix. Rate limits based only on IP are particularly easy to evade through distributed clients.
Provider-side controls remain important because the SMS provider sees routing and delivery information that the application cannot. Number intelligence can reject unallocated or non-mobile ranges before sending, and provider monitoring can hold suspicious prefixes or spikes. Those controls reduce exposure, but they happen close to the cost event, after the application has already accepted the request.
What browser proof adds
Application-layer browser proof asks whether the request came through a client that can produce valid, fresh evidence of a real browser environment. The server validates that evidence before allowing the high-cost action. This doesn't make the signal absolute, and it shouldn't be marketed as unbypassable, but it gives the decision engine information that an IP list cannot provide.
The most useful pattern is stateful:
- The browser obtains proof tied to the current session and action.
- The server validates the proof, freshness, and origin.
- The backend binds acceptance to the intended request and destination.
- The system rejects or steps up requests with missing, stale, mismatched, or reused evidence.
- The application records the decision before calling the SMS provider.
Token binding and replay protection prevent a captured payload from being reused as a fresh message trigger. A token-bucket algorithm can still enforce action-specific quotas, but the bucket should be keyed to more than the source IP. Use combinations of account, destination, device, session, prefix, and verified browser state.
Practical rule: Use network reputation to reduce obvious noise, browser proof to assess the request, and provider intelligence to assess the destination. No single layer sees enough of the attack to decide alone.
CAPTCHAs can interrupt basic scripts, but they add friction and often become another surface for automation or outsourcing. Invisible controls are preferable for ordinary users, with stronger handling reserved for requests that combine several risk signals.
Integrating Verification Across Your Stack
Place the decision as close as possible to the action that creates cost. The exact deployment point depends on the application, but the sequence should remain consistent: collect client evidence, validate it on the server, apply stateful policy, then invoke the SMS provider.
At the edge, a CDN worker or serverless function can reject requests with missing proof, malformed state, or an obvious velocity violation. This reduces origin compute and prevents clearly abusive traffic from reaching application middleware. Edge controls should avoid making irreversible decisions from one weak signal, because shared networks and privacy tools can produce false positives.
Within a cloud platform, put the verification result into the request context passed to the service that owns signup, login, checkout, or messaging. The service should make the final authorization decision, because it knows whether the user has already started a valid flow and whether sending a message is necessary. A separate messaging service should accept only an authorized, fresh action rather than a raw public request.
A useful integration sequence
For a Next.js application, the browser-facing route can request proof before submitting the phone number. Server-side middleware validates the proof, attaches a decision to the request context, and applies a route-specific quota. The API handler then checks account state, number intelligence, and destination policy before calling the provider.
For a SaaS product, protect the endpoints that create invitations, start trials, reset passwords, and send team notifications. Don't assume that only an OTP route carries risk. Any public form that triggers a billable message deserves the same pre-send review.
For checkout and account recovery, preserve the business action's identity across the entire flow. A valid browser proof for a product page shouldn't automatically authorize a phone-code send from a different session or destination. Freshness, action binding, and destination binding are what stop a harmless request from becoming a reusable authorization artifact.
The logging path should record the edge decision, application decision, provider response, and eventual business outcome in one trace. That lets incident responders answer the questions that matter: which control stopped the request, which requests were allowed, whether legitimate completion changed, and whether the provider still billed any traffic.
Rolling Out Defenses with Observe Mode
Blocking rules are hardest to tune when the first deployment happens during an incident. A team may know that a pattern looks suspicious, but it may not know whether the pattern includes legitimate customers, shared devices, accessibility tools, or an expected campaign. Observe mode provides a safer transition by recording proposed decisions without enforcing them on the critical path.
Start with one high-cost route, such as signup OTP. For each request, record what the policy would have done, the signals behind that decision, and the eventual outcome. Keep the existing flow active while the team reviews samples from allowed traffic, proposed rejections, verification errors, provider failures, and completed registrations.
A staged operating pattern
Stage one, visibility: Log browser proof status, route, destination characteristics, velocity, and business completion. Don't change user behavior yet. Confirm that events can be joined across the edge, application, and provider.
Stage two, shadow decisions: Apply the proposed policy in Observe mode. Review requests that would be blocked, especially those from served countries, returning accounts, and known customer devices. Look for clusters where one signal is responsible for nearly every proposed rejection.
Stage three, narrow enforcement: Enforce only the clearest combinations, such as invalid proof plus a burst, or a destination anomaly plus a collapsing verification ratio. Leave uncertain requests allowed or delayed while collecting more evidence.
Stage four, expand carefully: Move the policy to password resets, invitations, app links, and promotional forms only after the first route's false-positive rate is understood qualitatively through customer support and conversion review.
A failed business operation must not be counted as a successful fraud block. If an SMS provider times out, the user's code expires, or the application rejects an invalid form, the dashboard should preserve that reason separately. Otherwise, the team may celebrate lower message volume while genuine users slip away from the flow.
Observe mode is valuable because it turns policy design into an evidence review instead of a production gamble.
Set an explicit rollback owner and a maximum exposure policy before enforcement. During a live campaign, responders should be able to pause a destination, route, or provider integration without deleting the underlying evidence. Afterward, remove temporary rules that no longer have a defined purpose.
Real-World Scenarios and Sample Detection Rules
The most obvious target is an OTP endpoint, but the same abuse can hide in less protected flows. An attacker can submit phone numbers to an app-download form, trigger promotional messages through a lead-generation page, or create automated replies that cause a chatbot to send more messages. Recent coverage also frames SMS pumping as a broader traffic-quality and business-logic problem, not only a verification-cost issue. One dataset reported by Abiboe's fraud-prevention analysis analyzed 205 million authentication requests, blocked 24.3 million as fraudulent, and identified fraud in 11.83% of all traffic, preventing an estimated $3.26 million in SMS costs.
The rule engine should combine signals rather than make a decision from a single country, IP, or device attribute. The following table shows a starting point. The syntax is intentionally conceptual, because each team will map it to its own event schema and policy engine.
| Signal Category | Indicator | Sample Rule Logic |
|---|---|---|
| Velocity | Sends exceed the rolling baseline | if sends_5m > 10 * baseline_7d_5m then risk += high |
| Conversion | Verification collapses after sends | if verify_to_send_ratio < route_threshold then risk += medium |
| Destination | Unserved country or unusual prefix | if country not in served_markets then require_review |
| Number pattern | Adjacent or sequential destinations | if sequential_prefix_cluster then risk += high |
| Browser state | Missing or stale browser proof | if proof_missing OR proof_age > action_window then deny_send |
| Device continuity | Many accounts share one device identity | if accounts_per_device > local_limit then step_up |
| Network distribution | Residential proxies across many IPs | if proxy_signal AND same_device_cohort then risk += high |
| Business outcome | No registration, login, or transaction | if sends_high AND completions_low then hold_route |
Applying the rules to real flows
For an app-download link, a destination anomaly may be more useful than account history because the user may not yet have an account. Require fresh browser proof, limit repeated requests per destination, and compare the destination region with the product's normal acquisition markets.
For a promotional campaign, don't blindly block a planned traffic surge. Tag the campaign, establish its expected route and geography, and measure message sends against completed opt-ins or purchases. Requests outside the campaign's stated scope can receive a higher risk score without disrupting the expected audience.
For a chatbot, log inbound messages and the outbound action they trigger. Stop reply loops when the same session or destination repeatedly causes a new message without a meaningful state change. The same stateful check should apply to OTP resend buttons. A legitimate user may need a resend, but repeated sends without a changed verification state are not equivalent to separate customer journeys.
Residential proxies deserve special handling. Prelude's analysis of SMS pumping solutions reports that residential proxy networks became the dominant attack infrastructure in one 2025 dataset. That makes IP reputation a supporting signal, not a verdict. Browser continuity, action binding, destination behavior, and completion evidence should carry more weight.
Securing High-Value Actions Without Friction
SMS pumping is best treated as a business-logic abuse problem with a messaging cost attached. The protected object isn't merely the SMS API key. It's the public action that grants permission to spend money, whether that action starts a signup, resets a password, sends an app link, or triggers a promotional message.
A reliable design asks three questions before sending:
- Is this request tied to a valid browser session?
- Is the evidence fresh and bound to this exact action?
- Does the destination and request history support genuine user intent?
Network limits, prefix controls, number intelligence, provider monitoring, and spending alerts all remain useful. They're less effective when used as the only decision layer, particularly against distributed residential proxies and low-volume campaigns. Browser proof and stateful verification let the server evaluate the request itself, while Observe mode gives teams a way to tune policy before customer impact becomes the main metric.
Teams designing a secure login with phone codes should also audit every other endpoint that can send a message. Attackers follow the cheapest trigger, not the product team's intended use case. A short inventory of message-producing actions, their conversion outcomes, destination policies, and emergency controls will expose cost paths that ordinary authentication reviews often miss.
The strategic shift is simple: verify the client environment before authorizing the expensive action, bind the authorization to fresh state, and enforce based on several related signals. That won't guarantee that every abusive request is identified, but it makes distributed automation substantially harder to operate undetected and gives responders evidence they can act on.
MANDATE protects important website actions from automated abuse with invisible browser verification, server-side proof validation, and enforcement without CAPTCHAs. Use its Observe mode to review decisions before applying them to signup, login, checkout, or SMS-triggering flows, then visit MANDATE to evaluate the integration options for your stack.