What Is SMS Pumping Fraud? How to Detect and Stop It

Your OTP bill doubled overnight, verification completion collapsed, and the traffic all points at number ranges you have never sold to. That is SMS pumping fraud, and it is billed to you at full price. This guide covers how the scheme works, what it costs, the signals that expose it, and a pre-send gate you can deploy today.

Try Phone Validation for free and check any number’s line type and country before you send the OTP. 100 free requests a month, no credit card required.

What is SMS pumping fraud?

SMS pumping fraud is a scheme where attackers trigger large volumes of SMS messages, usually one-time passcodes, from your app to premium-rate or revenue-share numbers they control. The fraudster splits the termination fee with a complicit party in the delivery chain, and you pay for every message. It is also called SMS traffic pumping or artificially inflated traffic (AIT).

How an SMS pumping attack works

The attack needs only a form that sends an SMS: a signup flow, a login with SMS 2FA, or a phone verification step. Bots submit thousands of numbers from ranges where the attacker earns a share of the termination fee. Your platform dutifully sends each message, and none of the codes is ever entered.

1. The attacker acquires or controls number ranges with high termination payouts.
2. Bots feed those numbers into your signup or 2FA form.
3. Your backend sends an OTP to each number at your cost.
4. The carrier or aggregator in the chain pays a revenue share to the attacker.
5. Verification is never completed, and the cycle repeats until you notice the bill.

What SMS pumping costs: a worked model

The cost is send volume times per-message price, minus nothing, because no fraudulent send converts to revenue. The table below uses explicitly labeled assumptions so you can substitute your own numbers: 10,000 bot-driven OTP requests per day, an assumed average of $0.05 per international A2P message, and an assumed 80% of fraudulent sends hitting high-payout ranges.

These per-message prices are illustrative assumptions, not quotes. Your real rates come from your SMS provider invoice, and they vary widely by destination and route.

The reduction factors are also assumptions to calibrate, not guarantees: gating removes the share of attack traffic that resolves to VoIP or to countries you never sell to, and that share is different for every service. Measure your own split before and after enabling each control.

Which destinations carry the most risk?

SMS pumping concentrates where termination fees are highest and oversight is weakest. Rather than publishing a rate sheet that would be stale in a quarter, classify destinations into three buckets and set a default action per bucket. Review the buckets monthly against your own delivery invoice, which is the one rate source that is always current for you.

Detection signals and starting thresholds

No single signal is conclusive. Combine the five below, and treat every threshold as a calibration starting point against your own baseline, not an industry constant. Each row notes what legitimate traffic looks like so you tune rather than copy.

Build a pre-send gate

The cheapest message is the one you never send. Before your backend hands a number to the SMS provider, resolve its line type and country with one request to Abstract’s Phone Validation, then refuse VoIP numbers and countries outside your allowlist. A real response looks like this:

{
  "phone": "+14152007986",
  "valid": true,
  "format": { "international": "+14152007986", "local": "(415) 200-7986" },
  "country": { "code": "US", "name": "United States", "prefix": "+1" },
  "location": "California",
  "type": "voip",
  "carrier": "Twilio"
}

The type field and the country object are the two decision inputs. Here is the same gate in Node.js and Python, returning a structured reason code your risk team can log:

// Pre-send gate: refuse to send an OTP to risky numbers
const API_KEY = process.env.ABSTRACT_PHONE_KEY;
const ALLOWED_COUNTRIES = ["US", "CA", "GB"];

async function canSendOtp(phone) {
  const url = "https://phonevalidation.abstractapi.com/v1/?api_key="
    + API_KEY + "&phone=" + encodeURIComponent(phone);
  const res = await fetch(url);
  const data = await res.json();

  if (!data.valid) {
    return { allow: false, reason: "invalid_number" };
  }
  if (data.type === "voip") {
    return { allow: false, reason: "voip_line_type" };
  }
  if (!ALLOWED_COUNTRIES.includes(data.country.code)) {
    return { allow: false, reason: "country_not_allowed" };
  }
  return { allow: true, reason: "ok" };
}

# Pre-send gate: refuse to send an OTP to risky numbers
import os
import requests

API_KEY = os.environ["ABSTRACT_PHONE_KEY"]
ALLOWED_COUNTRIES = {"US", "CA", "GB"}

def can_send_otp(phone):
    res = requests.get(
        "https://phonevalidation.abstractapi.com/v1/",
        params={"api_key": API_KEY, "phone": phone},
        timeout=5,
    )
    data = res.json()
    if not data.get("valid"):
        return {"allow": False, "reason": "invalid_number"}
    if data.get("type") == "voip":
        return {"allow": False, "reason": "voip_line_type"}
    if data.get("country", {}).get("code") not in ALLOWED_COUNTRIES:
        return {"allow": False, "reason": "country_not_allowed"}
    return {"allow": True, "reason": "ok"}

You can sanity-check any suspicious number by hand first: check a number’s line type free, no key required, or confirm the number is live on a network with an HLR check before trusting a burst of signups.