SMS Pumping Fraud Prevention: How to Detect and Stop Artificially Inflated Traffic

SMS Pumping Fraud Prevention: How to Detect and Stop Artificially Inflated Traffic

SMS pumping fraud prevention: a rate-limit gate with a lock blocks a flood of bot-driven OTP SMS requests, letting one genuine request through to a verified phone

SMS pumping fraud is the line item quietly draining your verification budget while real signups stay flat. Bots flood your OTP endpoint, your provider delivers real messages to numbers that earn the attacker a cut, and you pay the bill. Call it artificially inflated traffic (AIT), SMS toll fraud or International Revenue Share Fraud (IRSF): the attack pattern is the same, and it cost brands $1.16 billion in 2023, according to Enea and Mobilesquared.

This guide covers SMS pumping fraud prevention from end to end: the detection signals to watch, runnable rate-limit code, and the layered defenses that stop pumped traffic before it reaches your invoice.

What Is SMS Pumping Fraud?

SMS pumping fraud, also called artificially inflated traffic (AIT) or SMS toll fraud, is a scheme where attackers abuse OTP and verification endpoints to generate large volumes of fake SMS messages. Those messages go to premium-rate or high-cost numbers tied to the attacker. Every message you send earns them a share of the termination fee the receiving network collects.

The name changes with who is talking, but the attack is the same:

TermWhere you will see it
SMS pumpingCommon name for the attack pattern
Artificially Inflated Traffic (AIT)Telecom industry term
SMS toll fraudTelecom billing perspective
IRSF (International Revenue Share Fraud)When routing crosses international borders
SMS traffic pumpingAlternative name for the same attack

The scale is large. Between 19.8 billion and 35.7 billion fraudulent AIT messages were sent in 2023, according to Enea, making up 4.8% of international A2P traffic.

One public case came from Twitter (now X). Elon Musk said Twitter was losing about $60 million a year to pumped SMS, not counting North America, and that 390 telcos were involved, as reported by Commsrisk.

In February 2023, Twitter announced that after March 20 only paid Twitter Blue subscribers could use text messages for two-factor authentication, as reported by NBC News, citing Reuters. Other two-factor methods stayed available to everyone.

How Does SMS Pumping Work?

Every SMS pumping attack follows the same chain. Understanding it is the first step to breaking it.

The four steps of an SMS pumping attack: reconnaissance of an open OTP endpoint, bot-driven requests to premium-rate ranges, routing and revenue-share payout, then scale and repeat

Step 1: Reconnaissance

The attacker finds an unprotected OTP or verification endpoint: a signup form, password reset or phone verification flow that sends an SMS without meaningful bot protection. Public forms with no CAPTCHA and no rate limiting are the easiest targets.

Step 2: Bot-Driven OTP Requests

Automated scripts submit phone numbers in bulk to the target endpoint. The numbers sit in premium-rate ranges or destinations where the attacker has a revenue-share arrangement with the terminating carrier.

A bot campaign can fire requests far faster than any real signup flow. Each request triggers a real SMS delivery, and a real charge on your account.

Step 3: Message Routing and Revenue Collection

Your SMS provider delivers the messages through its carrier routes. The terminating carrier collects a fee for each message, and part of that fee flows back to the attacker through the revenue-share arrangement.

International and cross-network messages can pass through intermediary carriers before they reach the destination. Every extra hop is another place such an arrangement can sit.

Step 4: Scale and Repeat

The attacker spreads the campaign across endpoints and rotates number ranges to avoid detection. A careful operation can time its bursts around legitimate peaks, such as payday or holiday weekends, to hide the artificial volume inside real spikes.

Without detection controls, a pumping campaign can run unnoticed until the invoice arrives.

How to Detect SMS Pumping Attacks

Detection starts in your logs. Monitor these five signals together. The thresholds below are illustrative starting points: tune each one against your own traffic baseline.

Five signals for detecting SMS pumping with illustrative starting thresholds: burst rate, verify-to-send ratio, country-code anomaly, IP and device clustering, and first-message-fail rate

SignalWhat to MeasureIllustrative Starting Threshold
Burst rateOTP requests per minute per endpoint>10x your 7-day rolling baseline
Verify-to-send ratioOTP verifications ÷ OTP sends (rolling 1-hour window)A sharp fall below your normal ratio
Country-code anomalyOTP sends to country codes outside your top 5Any sudden spike to an unused country code
IP/device clusteringUnique phone numbers per IP per hour>5 numbers from one IP in 60 minutes
First-message-fail rateOTPs returning operator-side delivery failuresSudden rise alongside a cost spike

The verify-to-send ratio is the most useful single metric to start with, because legitimate users verify and bots do not. If your ratio drops to less than half its usual level within an hour, with no product change to explain it, treat it as artificially inflated traffic until proven otherwise.

Burst-Detection Pseudocode

The core logic fits any language. Track request counts per identifier (phone, IP, device) in a sliding window, and block when a threshold is exceeded.

FUNCTION check_otp_rate_limit(identifier_type, identifier_value):
    key = "otp_limit:" + identifier_type + ":" + identifier_value
    current_count = INCREMENT(key)
    IF current_count == 1:
        SET_EXPIRY(key, window_seconds)
    RETURN current_count <= max_allowed

FUNCTION handle_otp_request(phone, ip, device_id):
    IF NOT check_otp_rate_limit("phone", phone): BLOCK
    IF NOT check_otp_rate_limit("ip", ip): BLOCK
    IF NOT check_otp_rate_limit("device", device_id): BLOCK
    send_otp(phone)

Node.js Implementation with Redis

For production, use Redis for distributed rate-limit counters tied into your OTP send path.

const Redis = require('ioredis');
const redis = new Redis();

const OTP_LIMITS = {
  phone:  { max: 5,  windowSeconds: 3600 },
  ip:     { max: 10, windowSeconds: 3600 },
  device: { max: 5,  windowSeconds: 3600 }
};

async function checkRateLimit(type, identifier) {
  const key = `otp_limit:${type}:${identifier}`;
  const current = await redis.incr(key);
  if (current === 1) {
    await redis.expire(key, OTP_LIMITS[type].windowSeconds);
  }
  return current <= OTP_LIMITS[type].max;
}

async function handleOtpRequest(req, res) {
  const { phoneNumber } = req.body;
  const clientIp = req.ip;
  const deviceId = req.headers['x-device-id'] || 'unknown';

  const checks = await Promise.all([
    checkRateLimit('phone', phoneNumber),
    checkRateLimit('ip', clientIp),
    checkRateLimit('device', deviceId)
  ]);

  if (checks.some(allowed => !allowed)) {
    return res.status(429).json({
      error: 'Too many OTP requests. Try again later.'
    });
  }

  const otpResponse = await sendOtp(phoneNumber);
  return res.json({ success: true, message: 'OTP sent.' });
}

Python (Flask + Redis) Equivalent

import redis
from flask import Flask, request, jsonify

app = Flask(__name__)
r = redis.Redis()

OTP_LIMITS = {
    "phone":  {"max": 5,  "window": 3600},
    "ip":     {"max": 10, "window": 3600},
    "device": {"max": 5,  "window": 3600},
}

def check_rate_limit(limit_type, identifier):
    key = f"otp_limit:{limit_type}:{identifier}"
    current = r.incr(key)
    if current == 1:
        r.expire(key, OTP_LIMITS[limit_type]["window"])
    return current <= OTP_LIMITS[limit_type]["max"]

@app.route("/api/otp/send", methods=["POST"])
def send_otp_endpoint():
    phone_number = request.json.get("phone_number")
    client_ip = request.remote_addr
    device_id = request.headers.get("X-Device-Id", "unknown")

    if not all([
        check_rate_limit("phone", phone_number),
        check_rate_limit("ip", client_ip),
        check_rate_limit("device", device_id),
    ]):
        return jsonify({"error": "Too many OTP requests."}), 429

    otp_response = send_otp(phone_number)
    return jsonify({"success": True, "message": "OTP sent."})

Rate-Limit Configuration Pattern

Tune these thresholds to your traffic. Start conservative, then relax them based on your false-positive rate:

DimensionStarting LimitWindowEscalation
Per phone number5 OTPs1 hourBlock + flag for review
Per IP address10 OTPs1 hourBlock + alert ops team
Per device fingerprint5 OTPs1 hourBlock + require CAPTCHA
Global endpoint200% of baseline5 minutesThrottle all traffic + alert

For deeper guidance on rate-limit windows and OTP expiry timing, see our guide on OTP rate limiting and expiration best practices.

Warning Signs Your OTP Endpoint Is Being Pumped

Not every anomaly is an attack. When several of these patterns appear together, though, SMS pumping is the likely cause.

Traffic Volume Spikes

OTP request volume jumps to several times your normal baseline with no product launch, marketing push or seasonal event to explain it. The spike concentrates in a narrow window of minutes, not hours.

Unusual Geographic Distribution

OTP requests suddenly target country codes where you have no users. A Lagos-based fintech receiving a burst of requests for Maldives or Tonga numbers is not seeing organic growth.

Concentrated Request Patterns

Many phone numbers arrive from a single IP, a narrow IP range or the same device fingerprint. Legitimate signups spread across diverse IPs and devices.

SMS Cost Anomalies

Your SMS spend rises without a matching increase in verified users or completed transactions. The gap between messages sent and users verified is the financial footprint of artificially inflated traffic.

How to Prevent SMS Pumping Fraud: 7 Defenses

No single technique stops SMS pumping, because attackers adapt. Effective SMS pumping fraud prevention layers several controls, so bypassing one still trips another.

Seven layered SMS pumping fraud prevention defenses: rate limits, a country allow-list for +233, +234, +27 and +255, server-side CAPTCHA, device fingerprinting, number-type checks, knowing how unverified OTPs are billed, and spend alerts

1. Per-Number and Per-IP Rate Limiting

Cap OTP requests per phone number and per IP address within a sliding time window. This is your first line of defense: it limits the volume any single attacker source can generate.

The code examples above implement this pattern. Start with 5 OTPs per phone per hour and 10 per IP per hour, then adjust based on your legitimate traffic.

2. Country Prefix Allow-Listing (Geo-Fencing)

If your application serves users in Ghana, Nigeria, South Africa and Tanzania, block OTP delivery to every other country code.

const ALLOWED_COUNTRY_CODES = [
  '+233', // Ghana
  '+234', // Nigeria
  '+27',  // South Africa
  '+255', // Tanzania
];

function isAllowedCountry(phoneNumber) {
  return ALLOWED_COUNTRY_CODES.some(
    code => phoneNumber.startsWith(code)
  );
}

The prefix check expects numbers in international format with a leading +. Normalise numbers before the check, then update the list only when you launch in a new market. Default to deny: every unblocked country code is an open door for SMS pumping attacks.

3. CAPTCHA on Verification Endpoints

Place a CAPTCHA challenge before the OTP request, not after it. If a bot can trigger the SMS without solving a challenge, the CAPTCHA does nothing.

Common choices include Google reCAPTCHA, hCaptcha and Cloudflare Turnstile. Pick one whose challenge your mobile users will tolerate.

The key: the CAPTCHA must gate the API call that triggers SMS delivery. Checking it on the frontend form without validating it server-side leaves the OTP endpoint open to direct API calls.

4. Device Fingerprinting

Collect a device fingerprint (browser hash, screen resolution, installed fonts, timezone) and rate-limit per fingerprint. This catches bot farms that rotate IP addresses but reuse the same browser automation setup.

Device fingerprinting works best as a secondary signal alongside IP-based rate limiting, not as a standalone defense.

5. Carrier-Level Fraud Protection

A number-type lookup before sending tells consumer mobile numbers apart from premium-rate ranges, VoIP lines and disposable numbers. Where your provider or a number-lookup service offers one, run it before the send, so the destinations that exist only to collect termination fees never receive a message.

Route choice matters too. The fewer intermediary hops between you and the destination network, the fewer places a revenue-share arrangement can sit, which is why direct network connections in your operating markets are worth asking about.

Arkesel connects directly to MTN, Telecel and AirtelTigo in Ghana, and routes onward to Nigeria, South Africa and Tanzania. Phone Number Verification delivers and verifies OTPs for users in all four markets. See how it works →

6. Know How Unverified OTPs Are Billed

Ask each provider how it bills OTPs that are never verified: per message sent, or per successful verification. Billing per successful verification shifts the cost of pumped traffic away from you. If a bot triggers 1,000 OTP sends and none verify, you would not pay for them.

On a per-send model, every OTP you send is a charge, whether or not anyone enters the code. Pumped requests cost you, and so do resends from impatient real users. That makes the rate limits, geo-fencing and CAPTCHA in defenses 1 to 3 your cost control as well as your security control.

Arkesel bills OTPs per message sent, not per successful verification. Current rates are on the Arkesel pricing page.

Whichever provider you use, get the answer in writing before you commit. For a side-by-side view of providers, see our OTP API provider comparison for 2026.

7. Real-Time Anomaly Detection and Alerting

Set spend alerts that fire before costs run away, and add a hard spending cap or automatic pause if your provider offers one. On Arkesel, low balance alerts notify you by email or webhook when your credits fall below a threshold you set, which gives you an early cost signal during an attack.

Combine cost alerts with verify-to-send ratio monitoring. A sudden cost spike paired with a sharp fall in the ratio is a strong SMS pumping signal and should trigger automatic throttling on your side.

SMS Pumping in Africa: Mobile Money and Fintech Scenarios

Teams running OTP flows in Ghana, Nigeria, South Africa and Tanzania should plan for a few patterns that country-code rules alone will not catch.

Cross-Border Pumping via Inter-Operator Routes

A message can pass through one or more intermediary carriers between your provider and the destination handset. Each hop is a potential collusion point, and a fraud route through an allowed country code does not show up on a country-code allowlist.

The defense: ask providers how they reach each network in your markets, and prefer direct connections where they exist. Direct termination removes the intermediary leg where pumping arrangements can live.

Premium-Rate and High-Cost Number Ranges

Attackers aim your OTP endpoint at premium-rate and high-cost number ranges. Because these are technically valid numbers under a country code you allow, a country-code check lets them through.

The defense: number-type validation that separates consumer mobile ranges from premium-rate ranges. Ask whether your provider or a number-lookup service can tell them apart before a message is sent.

Mobile Money Verification Fraud

Fintech and mobile money platforms in Ghana, Nigeria, South Africa and Tanzania are exposed to the same attack on their signup and transaction verification OTPs. The attacker profits from the SMS termination fees while the platform’s OTP budget absorbs the cost.

For regulated fintech workloads, the OTP layer needs both SMS pumping protection and transaction-grade reliability. Our guide on OTP for fintech and banking covers the compliance and audit-log requirements that sit alongside these defenses.

Bursty Patterns on Local-Holiday Schedules

An attacker can time a burst to payday or a public holiday, when legitimate signups also rise, so the artificial volume hides inside a real spike. Volume alone looks normal in that window. The verify-to-send ratio is the signal to watch, because pumped sends still do not verify.

How to Respond When SMS Pumping Is Detected

When your monitoring flags an active pumping attack, work through this sequence:

  1. Block suspicious country prefixes immediately. If the attack targets country codes outside your operating markets, add them to your deny list within minutes. This stops the bleeding.
  2. Throttle the verification endpoint. Reduce allowed request rates across every identifier: phone, IP and device. Legitimate users see a brief delay; the attacker’s throughput collapses.
  3. Review your SMS usage and invoices. Compare messages sent against verifications completed for the attack window. The gap is your exposure.
  4. Report the attack to your SMS provider. Share the attack window, the destination number ranges and your verify-to-send data, so the provider can trace the route and block the numbers involved. Ask how charges for the fraudulent traffic will be handled.
  5. Put permanent prevention controls in place. Use the attack as the push to deploy the layered defenses above: rate limiting, geo-fencing, CAPTCHA and number-type checks. A complete SMS pumping fraud prevention strategy combines all seven defenses from this guide.

Choosing an OTP Provider with Built-In Fraud Protection

When you evaluate OTP providers, ask about each of these capabilities:

  • Built-in rate limiting at the platform level, not just documentation telling you to build your own
  • Phone number intelligence: number-type validation, carrier lookup and premium-rate detection before delivery
  • Direct carrier connections in your operating markets, which remove intermediary routing hops
  • Delivery reporting that lets you compare messages sent against codes verified, by country
  • Geographic controls you can change from a dashboard without an API release
  • Billing model for unverified OTPs: whether you pay per message sent or per successful verification, which decides who carries the cost of pumped sends

Confirm each answer for the specific countries you serve, not just the provider’s headline coverage. For a head-to-head comparison across providers, see our OTP API provider comparison for 2026.

If your users are in Ghana, Nigeria, South Africa or Tanzania, Arkesel’s Phone Number Verification is available in all four.

The Arkesel SMS Platform shows each message’s delivery status in a per-recipient report, usually within about one minute, so a spike in sends to unfamiliar numbers is visible in your own reporting. Arkesel bills per OTP sent, so pair it with the rate limits and CAPTCHA above to keep pumped sends off your bill.

The Wider SMS Fraud Picture: Why Your Own Controls Still Matter

Some SMS fraud numbers are heading down. As reported by Infosecurity Magazine, citing Juniper Research, subscriber losses to smishing, account takeover and other SMS threats are forecast to fall from $80 billion in 2025 to $71 billion in 2026, an 11% decrease. Juniper points to improved operator security and falling message volumes as the drivers.

That forecast measures what consumers lose to SMS scams. It says nothing about what pumped OTP traffic costs you as the sender.

Mobile operators and industry bodies continue to work on messaging fraud, but that work sits outside your application and does not stop a bot from hitting your endpoint. The SMS pumping fraud prevention defenses in this guide protect your endpoints regardless of what happens further down the delivery chain.

Implementation Checklist

Use this checklist to audit your current SMS pumping protection and find the gaps:

  • Rate limiting active: per phone number, per IP and per device fingerprint, with sliding time windows
  • Country code allowlist enforced: OTP delivery restricted to your operating markets only
  • CAPTCHA gates the OTP trigger: validated server-side, not just on the frontend
  • Verify-to-send ratio monitored: alert threshold set against your own normal ratio
  • Spend alerts configured: a balance or budget alert that fires early, plus a hard cap or pause if your provider offers one
  • Number-type checks in place: premium-rate and high-cost ranges screened before delivery, where your provider or a lookup service supports it
  • Geographic anomaly alerts configured: notification on OTP sends to unexpected country codes
  • Incident response plan documented: your team knows the block → throttle → review → report sequence
  • Provider answers confirmed: route to each network, billing model for unverified OTPs, delivery reporting

For teams building OTP systems from scratch, the OTP API integration guide covers the full implementation path.

Frequently Asked Questions

What is SMS pumping fraud?

SMS pumping fraud, also called artificially inflated traffic (AIT fraud) or SMS toll fraud, is an attack where bots flood an OTP or verification endpoint so it sends real SMS messages to premium-rate or high-cost numbers tied to the attacker. The attacker earns a share of the termination fee on every message sent.

How do you detect SMS pumping in your logs?

Monitor five signals together: burst rate per endpoint, verify-to-send ratio, country-code anomalies, unique phone numbers per IP per hour, and first-message-fail rate. Set each threshold against your own baseline. The verify-to-send ratio is the most useful single signal, because real users verify and bots don’t.

What is the difference between SMS pumping and smishing?

SMS pumping generates fraudulent outbound traffic through your endpoints to earn carrier revenue, and it costs you money directly through inflated SMS bills. Smishing sends phishing messages to your users to steal their credentials or money. Different attack vectors need different defenses.

How much does SMS pumping cost businesses annually?

AIT cost brands $1.16 billion in 2023, according to Enea. Individual losses vary widely: Elon Musk said Twitter was losing about $60 million a year, not counting North America, and Twitter later restricted SMS two-factor authentication to paid subscribers. Your own cost depends on your OTP volume, your rate limiting and how quickly you detect the attack.

What is artificially inflated traffic (AIT)?

AIT is the telecom industry term for SMS pumping: artificially generated message volume designed to earn termination revenue. The terms are interchangeable, and you will see AIT used in industry research such as the Enea report cited above.

How can African businesses defend against SMS pumping?

Layer three controls: geo-fence OTP delivery to your operating country codes (Ghana +233, Nigeria +234, South Africa +27, Tanzania +255), screen numbers for premium-rate and high-cost ranges before sending where a lookup is available, and ask providers how they reach each mobile network in your markets. Fewer intermediary hops leave fewer places for pumping arrangements. See our guide on OTP API security best practices for the wider security framework.

Protect Your OTP Endpoints from SMS Pumping

SMS pumping fraud is a solvable problem. Rate limiting, geo-fencing, CAPTCHA before the send and number-type checks, layered together, cut off the easy routes attackers rely on before the traffic reaches your invoice.

Arkesel’s Phone Number Verification serves users in Ghana, Nigeria, South Africa and Tanzania. Talk to Arkesel about OTP delivery for your markets, or create an Arkesel account to get started.

Related Articles

Scroll to Top