Key Takeways
- SMS pumping (IRSF) drains $10K-$100K from unprotected OTP senders within weeks; it's a multi-billion-dollar fraud category per GSMA tracking.
- Three reliable detection signals: unusual destination-country concentration, send-to-verify ratio collapse (above 2:1), unexplained volume spikes.
- Seven architectural defenses to demand: per-number/per-IP rate limiting, prefix blocking, anomaly detection, CAPTCHA, country allow-listing, per-success billing.
- For US-only apps, country-prefix allow-listing alone (only allow +1) blocks 95% of pumping in one configuration change.
- Full-stack defenses drop fraud share from 5-15% to under 0.5%; cost of protection is essentially zero, cost of skipping it scales with traffic.
SMS pumping fraud — also called International Revenue Share Fraud or IRSF — is the largest unaddressed line item in most US OTP-sending businesses' budgets. The GSMA Fraud and Security Group tracks pumping as a multi-billion-dollar industry, draining real money from companies that didn't realize their OTP signup form was being weaponized. This guide is the definitive reference for US senders: how SMS pumping actually works, the warning signs, the architectural defenses that work, and the operational playbook for detecting and shutting down active campaigns.
What is SMS Pumping (IRSF)?
SMS pumping is a fraud where attackers script your OTP signup or verification flow to repeatedly trigger SMS sends to phone numbers under their control on premium-rate international routes — collecting kickback revenue from the operator on every delivered message. Each individual OTP send looks legitimate to your application. The attack is in the aggregate: thousands or millions of OTP sends to a small set of numbers in countries where SMS termination shares revenue with the destination operator.
The economics: attackers acquire phone-number ranges (often very cheaply) in countries with revenue-share agreements between SMS senders and destination operators. They write scripts that hit your signup form repeatedly with these numbers as the destination. Your OTP API dutifully sends the SMS. The destination operator pockets a chunk of your per-SMS spend (sometimes $0.05–$0.20 per message) and shares revenue with the attacker who's directing the traffic.
For a US business sending OTP without protection, a moderately-aggressive pumping campaign can rack up $10K–$100K in fraud in a few weeks. The attacker's payoff per message is small; their volume is enormous.
How an Attack Plays Out
The standard playbook in 2026:
- Reconnaissance. Attacker scans the web for unauthenticated OTP signup endpoints; typically signup forms or password-reset flows that don't require CAPTCHA.
- Number acquisition. Attacker acquires phone-number ranges in target countries; commonly small African nations (+225 Côte d'Ivoire, +211 South Sudan), Pacific islands (+678 Vanuatu, +691 Federated States of Micronesia), or Eastern European prefixes — where premium SMS termination shares meaningful revenue.
- Script the attack. Attacker writes a script that POSTs to your signup form, providing one of their numbers as the phone field. Each request triggers an OTP send.
- Scale. Attacker runs the script through residential proxies or compromised IPs to evade per-IP rate limits, hitting your OTP send endpoint hundreds or thousands of times per hour.
- Collect revenue. The destination operator receives the SMS, terminates it (or doesn't; the kickback often happens regardless of actual delivery), and remits the kickback to the attacker.
The campaign typically runs for weeks before the target notices; by which point the bill is already five or six figures. Many businesses only catch on when their OTP-API monthly invoice triples.
The Three Detection Signals
Three patterns reliably indicate active pumping. Set monitoring on all three.
1. Unusual destination-country concentration
A US-only fintech that's suddenly sending 30% of its OTPs to country code +211 (South Sudan) or +678 (Vanuatu) is being pumped. Your real US-only user base sends 99%+ of OTPs to +1; any other country code is anomalous.
Even US-plus-global apps have stable destination distributions over time. Sudden jumps in a specific country's share (particularly if the country is small, has a small US diaspora, and is in the GSMA fraud-prone list) is a pumping signature. Industry threat feeds maintained by GSMA's Fraud and Security Group publish the country prefixes most associated with abuse.
2. Send-to-verify ratio collapse
In normal operation, the ratio of OTP sends to OTP verifications is roughly 1.2:1; most users complete the OTP they started, with some retries. During pumping, the ratio collapses: attackers trigger sends but never complete the verification (they don't actually receive the OTP since they don't control the destination phone, just the operator).
If you see send-to-verify ratios climb to 2:1, 5:1, or higher, especially concentrated on specific country prefixes, it's pumping.
3. Spike in send volume not correlated with marketing or product changes
Sudden 5x spikes in OTP volume that don't match a marketing campaign launch, product release, or known seasonal traffic pattern are almost always either (a) a fraud campaign, (b) a regression in your application code that's triggering duplicate sends, or (c) a bot probing your forms. None of those are good. Investigate every unexplained spike within hours.
The Architectural Defenses That Work
Seven defenses that should ship enabled by default. If your provider gates any of these behind a higher tier, switch.
1. Per-number rate limiting
No single phone number should be able to request more than 3–5 OTPs in an hour. Hard cap with exponential backoff for repeat failures.
2. Per-IP rate limiting
No single IP should be able to request OTPs for more than 10–20 unique phone numbers in an hour. The signature of pumping is one IP requesting OTPs to many destinations.
3. Premium-rate prefix blocking
Pre-block known-bad country prefixes by default. Maintain an allow-list for legitimate destinations. Update the block list continuously from threat-feed data.
4. Anomaly detection on traffic patterns
ML-based pattern detection on top of static rules. Sudden destination-country shifts, send-to-verify ratio jumps, and unusual IP-distribution patterns trigger automatic throttling or human review.
5. CAPTCHA or proof-of-work integration
A friction layer before triggering OTP sends raises attacker cost dramatically. Cloudflare Turnstile and Google reCAPTCHA v3 are invisible to legitimate users via risk-based triggering.
6. Country-prefix allow-listing
If your business is US-only, allow-list +1 only. If you serve specific countries, allow-list those and block the rest. This single defense eliminates 95% of pumping attempts in one configuration change.
7. Per-success billing
Per-message billing makes you the attacker's profit center; every send costs you regardless of whether it completes a verification. Per-successful-verification billing aligns the cost to actual user value, making pumping unprofitable for the attacker (since the verifications never complete) and for the provider (no incentive to allow suspicious traffic).
Application-Layer Defenses
Beyond what your OTP provider does, three application-layer defenses are essentially free and materially raise attacker cost:
Require successful CAPTCHA before OTP send
For unauthenticated signup endpoints, run an invisible CAPTCHA (reCAPTCHA v3, Turnstile, hCaptcha) on every request. Trigger a visible challenge for low-confidence scores. Most legitimate users never see it; bots fail at high rates.
Honeypot fields
Add a hidden form field that legitimate browsers won't fill but scripts will. Reject any submission that fills the honeypot. Catches naive scripts at zero UX cost.
Email verification before phone OTP
Require an email verification step before allowing OTP send. Adds 30 seconds of legitimate-user friction but eliminates the easiest class of pumping (where attackers don't even bother creating real accounts, they just hit the OTP endpoint).
The Detection Playbook (Operational)
When you suspect pumping is active:
- Pull destination-country distribution for the last 24 hours. Compare to the prior week's distribution. Identify country codes with anomalous share growth.
- Pull send-to-verify ratio per destination prefix. Anything above 2:1 in countries you don't normally serve is suspect.
- Identify source IPs by destination-country. Pumping campaigns typically concentrate sending across a relatively small set of source IPs or IP ranges. Block them at your edge.
- Add temporary country-prefix block on the affected destination(s). If you don't legitimately serve users in +211 South Sudan, block all OTP sends to that prefix immediately.
- Open a ticket with your CPaaS provider. They have additional threat-intelligence and can coordinate with destination operators to halt the kickback flow.
- Audit your OTP signup endpoint for the missing CAPTCHA, missing rate limits, or missing prefix allow-listing that allowed the campaign in the first place.
Total response time from detection to mitigation should be under an hour for known-pattern attacks. Longer response means more direct fraud loss.
What Pumping Costs (Real Numbers)
Industry benchmarks for unprotected vs protected OTP infrastructure in the US in 2026:
- Unprotected OTP signup flow: 5–15% of OTP traffic is fraudulent during active pumping campaigns. For a 100K-OTP/month workload, that's $500–$2,500 in pure waste — and that's the lower bound. Active campaigns can hit 30–50% fraud share.
- Basic protection (per-number + per-IP rate limiting): drops fraud share to 1–3%. Saves $250–$2,000 per month for the same 100K workload.
- Full stack (the seven defenses above): drops fraud share to under 0.5%. Some teams see steady-state fraud at 0.05% — essentially zero.
The cost of full-stack protection is essentially zero (it's part of any reputable verification API's base price). The cost of skipping it scales with your traffic.
FAQs
How do I tell if I'm currently being pumped?
Three quick checks: (a) pull the last 7 days' OTP volume and look for anomalous spikes that don't match marketing or product changes; (b) check the destination-country distribution and look for unusual concentrations in countries you don't typically serve; (c) check the send-to-verify ratio per destination — anything above 2:1 in low-volume countries is suspect. Most CPaaS dashboards expose all three within five clicks.
Can I prevent pumping if my application is US-only?
Yes, easily. The single most effective defense for US-only apps is country-prefix allow-listing: configure your verification API to only send OTPs to +1 destinations. This blocks ~95% of pumping campaigns in one configuration change. Layer on the other six defenses for resilience.
Will my legitimate international users be blocked by anti-pumping defenses?
Not if implemented well. Per-number and per-IP rate limits are above any normal user's behavior (5 OTPs/hour, 20 destinations/hour). Anomaly detection focuses on aggregate patterns, not individual users. Country-prefix allow-listing affects only countries you don't serve. The only place legitimate users notice anti-pumping defenses is when an invisible CAPTCHA escalates to a visible challenge — and that escalation happens to under 1% of legitimate users.
Stop Paying for Fraud You Can Prevent
Most US OTP fraud is preventable with defenses that should ship enabled by default. VerifyNow for USA includes the full seven-defense pumping-protection stack at no upcharge: per-number rate limiting, per-IP rate limiting, premium-prefix blocking, ML anomaly detection, CAPTCHA integration, country allow-listing, and per-success billing. Free test credits, no credit card required to validate the defenses on your own traffic before you commit.

.svg%20(1).png)




