SMS pumping and gray-route fraud: the operator explainer

Quick answer: The 2026 SMS fraud wave has two halves that increasingly arrive as one fingerprint. SMS pumping — artificially inflating traffic to premium-rate or revenue-share numbers so someone downstream shares the revenue — stopped being a messaging-ops nuisance and became a board-level fraud line item. Gray routes and SIM farming are the route side of the same class: gray routes deliver application-to-person (A2P) traffic dressed as ordinary person-to-person (P2P) foreign-origin traffic, and SIM farms terminate it through boxes of physical SIM cards — often to pump OTP traffic for revenue. Carriers now price unregistered-origin surcharges above the registered tariff and screen blocked ranges before delivery, so the gray route stopped being cheap and became a billing trap, while the FCC's actions against carriers that knowingly carry pumped traffic moved the exposure from a billing dispute to a compliance question. On Orbit, the whole posture is tenant-owned: you set the fraud policy, you read the anomaly report, you register the sender identity — you own the levers.

If you buy CPaaS this year, this is the fraud class to design twice for — once on the volume side (pumping converts an ordinary OTP integration into an unbounded spend attack the moment your form is reachable from the open internet) and once on the route side (a cheap upstream route is still a gray route even when you did not choose it, and "your sender ID arrived spoofed" is a regulator-side violation, not a billing surprise).

Updated 2026-09-17: this post consolidates the two overlapping SMS-fraud explainers — the pumping news explainer and the gray-routes / SIM-pumping explainer — into one canonical operator post. The retired gray-routes URL redirects here.

What SMS pumping fraud is, and why 2026 is the year it went mainstream

SMS pumping — the industry also calls it AIT, artificially inflated traffic — has a simple mechanic. A fraudster signs up with numbers in ranges or destinations that carry a revenue-share arrangement: the carrier pays a share of each terminated message back to the range holder. The fraudster then drives your verification form with automation, triggering thousands of OTP sends to numbers nobody will ever verify. You pay per message; the range holder collects revenue share; the "user" never completes a verification because there is no user.

Three things made 2026 the breakout year for this attack:

Regulators named it. The FCC has spent the cycle pushing carriers and messaging providers on robotext and fraud-traffic duties, and its actions against carriers that knowingly carry pumped traffic moved the exposure from a billing dispute to a compliance question. When a regulator starts asking carriers to prove they are not profiting from artificial traffic, the cost of looking the other way goes up for everyone in the chain — including the CPaaS account holder the traffic is billed to.
Carriers started publishing the numbers. Mobile-network-operator fraud reports this cycle consistently put AIT among the fastest-growing fraud categories by operator cost, which pulled it out of the security team and into procurement: an attack that can multiply your messaging spend is a buying criterion, not an ops note.
The tool got cheap. Pumping used to need bespoke automation. Scripts that walk a signup form, rotate IPs, and feed disposable or bot-farmed numbers are commodity tooling now, and any public OTP form is a viable target — which is why the attack lands on verification endpoints first.

The victim profile is consistent: you run an OTP form, the form has no pre-send gate, and you find out when the bill arrives. The design question for a buyer is therefore not "how do I detect pumping eventually" — it is "what refuses the send before the money moves, and what tells me a destination is pumped before the month closes."

How gray routes work — and why 2026 carriers price them as a penalty

A legitimate A2P SMS route is registered end to end: a declared sender ID, a campaign or brand registration where the destination regime requires it (10DLC in the US, DLT in India, sender-ID registries in much of Europe and APAC), and an agreed per-message tariff. A gray route substitutes for any of that:

Sender-ID spoofing. The message arrives from a stolen or generic alphanumeric ID attached not to your brand but to the gray-route operator's pool — so the destination carrier sees an unregistered origin and the recipient sees a sender that cannot be held accountable.
P2P-path injection. A2P traffic is pushed onto consumer person-to-person SIM paths where the per-message termination fee is lower or nonexistent, avoiding the A2P tariff that funds carrier screening and registration.
Hop washing. The message crosses an intermediate aggregator that re-originates it, so the leg responsible to the destination carrier is not the originator — laundering the origin into "foreign P2P" before delivery.

In 2026 all three moved from grey-area discounting to explicit liability. Carrier and regulator regimes — including the US TCR regime, India's DLT, and EU sender-ID registration pushes this cycle — increasingly impose unregistered-origin surcharges priced above the registered tariff, and carriers apply screening-level blocking before delivery. The gray route stopped being "cheap" and became "billable-as-spam": the real cost has inverted the discount.

SIM farms: pumping at the box level, one fingerprint for both halves

SIM farming — "SIM boxing" — terminates traffic through racks of physical SIM cards (hundreds or thousands of consumer subscriptions in one box), making A2P traffic indistinguishable from P2P at the carrier's inbound switch. A SIM farm is the physical incarnation of a gray route; it is also the infrastructure for SMS pumping, where the farm's own pool of numbers drives traffic for revenue.

The 2026 SIM-farm news is not a new technique; it is enforcement catching up. Carriers now treat a SIM box hammering A2P traffic as a fingerprint for both gray-route avoidance and OTP pumping, and the same fraud-screening feeds that name SIM-farm ranges name destination prefixes flagged for artificially inflated traffic. If your provider routes your OTPs through a SIM-farm gray route — or your own verification form drives publishes to one — carrier-side screening blocks it by range, not by message.

That shared fingerprint is why one routine now serves both halves: a destination prefix arriving through a SIM-farm range reads exactly like a pumped prefix — high send volume, near-zero verified or delivered — so the same per-destination conversion report flags the two halves of the class.

Where the attack lands: Verify and OTP endpoints, under-designed vs. defended

A marketing SMS campaign is a poor pumping target: you choose the recipients, so the attacker cannot aim your sends at their numbers. A verify endpoint is the opposite — the caller nominates the destination, and the endpoint sends on demand. Every property that makes OTP a good product makes it a good attack surface.

The under-designed version has three holes:

The form sends before it thinks. Phone number goes in, SMS goes out, no risk decision in between. The attacker's cost is near zero; your cost is per-send.
No destination-level visibility. Aggregate SMS volume looks healthy while one prefix quietly multiplies, because nobody is reading conversion per destination.
No velocity shaping. Unlimited sends to the same range, and the only cooldown is a client-side timer the bot ignores.

The defended version wires the decision into the flow itself. On Orbit's Verify API, the checks land at three points in the lifecycle, and each is a tenant-owned setting:

Before the send. A pre-send Fraud Guard scores the destination against your fraud policy. A refused send comes back synchronously as a 403 VERIFY_FRAUD_BLOCKED error carrying the risk score and reasons, and the same decision is emitted as a verification.fraud_blocked webhook event. SIM-swap and line-type policy blocks are also synchronous (SIM_SWAP_DETECTED, VERIFY_LINE_TYPE_BLOCKED) — none of them ever create a verification row, so a refused attack never sends a message. (Full payload shapes: the webhook events reference.)
Across the whole window. GET /api/v1/verify/conversion-anomaly scores each destination prefix by its OTP completion rate — verified over sent — flags destinations converting far below your tenant baseline on material volume, and headlines an estimated spend-at-risk in USD (see the Verify API reference). A pumped prefix reads as exactly what it is: high send volume, near-zero completion.
At the channel level. Verify sends across SMS, voice, WhatsApp, and email, with fallback advancement, so a channel under attack is not the only door — and velocity controls (attempt limits, per-profile cooldowns) cap how much a single hostile destination can ever draw.

The pre-send gates ride a lookup dip against the destination number (validity, reachability, SIM-swap, line type). For the buyer-side walk-through of that lookup surface — the three acceptance patterns, the single-dip and bulk-scrub endpoints, and the per-query billing rules — the sibling guide Phone-Number Lookup and SIM-Swap Pre-Send covers what this post names but does not teach.

The sibling comparison — which providers ship this combination and which treat "fraud protection" as a marketing row — is the ranked guide Best SMS-Pumping Anti-Fraud Verification APIs 2026. This post is the operator side of the same question: the comparison tells you who ships the controls; the sections below tell you which controls to actually configure.

Tenant-side controls to configure — volume and route, one posture

Fraud posture on Orbit is tenant-owned by design — the platform provides the levers and the enforcement points; what your traffic declares and tolerates is your compliance and risk call. None of them is a platform guarantee that no third party will ever gray-route or pump your traffic — they are the levers you own when they try.

Volume-side levers (pumping, SIM-farm ingest)

Turn on and tune the pre-send fraud policy. The Fraud Guard only helps if your policy says what to do with a risky destination: refuse the send, or pass with the signal attached for your own risk engine. Choose per channel and market — a blanket "block everything flagged" policy will burn legitimate users in high-risk ranges your product actually serves.
Set velocity controls per destination and per recipient. Attempt limits on verification checks, cooldowns before a resend to the same number, and profile-level defaults all narrow the window a bot has. A pump run that can only get 12 messages to a prefix is a failed pump run.
Mix the verification channels deliberately. Email-first for low-assurance flows, SMS where it converts, voice fallback where SMS deliverability is weak. Every OTP that never needs to be an SMS is spend the attacker cannot drive.
Rotate verification-code validity windows. Keep OTP codes on short rotation so a farmed interception ages out before it can be replayed.

Route-side levers (gray routes, sender identity)

Register your sender identity with the regime that governs the destination. For US destinations that means a 10DLC brand and campaign; for India, DLT registration; for alphanumeric destinations that require it, a registered sender ID filed through the dashboard. Legitimate-registered is the only posture any of these routes respect — and when a carrier or regulator asks, the evidence for the destination regime is yours to present because the filing is tenant-filed.
Set frequency caps per recipient and destination via the [frequency caps guide](https://docs.orbit.devotel.io/guides/frequency-caps). A bot that probes your OTP form or your campaign flow hits a tenant-side limit before it accumulates synthetic traffic volume.
Configure message suppression for complaint-driven removals. Wire the message suppression guide so a number that opts out, or that triggers a complaint-level block, stops drawing sends — both a spam-complaint guard and a pump-run stop-loss.

Detection levers (wired into your incident path)

Subscribe to the decision events. verification.fraud_blocked and account.fraud.alert are subscribable webhook events; detection you do not route anywhere is detection you did not do — wire the events into the same incident path as your other production alerts. The OTP fraud-monitoring post walks the full posture.
Read the conversion-anomaly report per destination. The endpoint ranks prefixes against your tenant baseline and prices the exposure — a pumped prefix and a SIM-farm range read the same way, so one report serves both halves of the class.

Worked examples

(a) Detection: the `verification.fraud_blocked` payload

When the pre-send Fraud Guard refuses an OTP send under your policy, two things happen: the send call returns 403 VERIFY_FRAUD_BLOCKED synchronously, and a webhook event fires. The event deliberately carries no verification_id — the verification never existed:

{
  "type": "verification.fraud_blocked",
  "data": {
    "channel": "sms",
    "to": "+14155552671",
    "reason": "fraud_blocked",
    "risk_score": 87,
    "fraud_reasons": ["risk_block", "roaming"]
  }
}

Handle it as a signal, not a failure: increment a per-prefix counter, page on rate spikes, and feed the fraud_reasons into your own risk review. Because the refusal is pre-send, handling it costs no messages. The ones to page on are the signatures naming roaming plus risk-block — the classic SIM-farm fingerprint. The analogous pumping-discovery query is the anomaly report:

GET /api/v1/verify/conversion-anomaly?window_days=30

which returns your tenant baseline conversion rate, the flagged destination prefixes, and estimated_spend_at_risk_usd — the number to bring to the carrier dispute if one turns out to be warranted.

(b) Mitigation: a flow that turns a block into an action

The detection events are only as useful as what they trigger. The shipped pattern is the Orbit flow builder (documented under flows/builder):

Trigger — Incoming Webhook. Point a flow's webhook trigger at your webhook endpoint subscription for verification.fraud_blocked. Every refusal now starts a run, with the destination and reasons available as {{variable}} placeholders from the trigger payload.
Condition. Branch on volume — e.g. proceed only when the same destination prefix has blocked more than N times in the hour (your own counter, or a lookup against your warehouse via an HTTP Request node).
Actions. On a real spike: send an internal alert (email or chat notification to the on-call channel), tighten the fraud policy on the affected channel via the API, and open a ticket with the prefix evidence attached.

The point of the flow shape is that the response is automatic but the policy move is still yours — the flow enforces your thresholds; it does not silently rewrite your posture. If you suspect a vendor or route put your traffic off the record rather than pumping your OTP form, the remediation is the same tenant-owned reset: re-register the sender identity, tighten the frequency caps and suppression, and run the anomaly report against the suspect window — without waiting for a provider-side decision.

How to keep your SMS traffic off gray routes and pump farms

Register every sender identity with the destination regime before first send. US 10DLC, India DLT, alphanumeric sender registries — filed in the dashboard as your tenant posture, verified as shipped.
Turn on and tune the pre-send fraud policy on Verify. Refuse, or pass with the signal attached — set per channel and market.
Configure frequency caps per recipient and destination. Set the caps before traffic touches them; the guide is the reference.
Wire message suppression to complaint and opt-out events. Configure it in the message suppression guide so a stop-loss never waits for support.
Subscribe to fraud-monitoring events and check conversion-anomaly by destination before every campaign. verification.fraud_blocked and account.fraud.alert go into your incident route; the endpoint ranks prefixes against your tenant baseline and prices the exposure.

Frequently asked questions

What is SMS pumping fraud?

SMS pumping (artificially inflated traffic, AIT) is traffic driven to premium-rate or revenue-share number ranges so the range holder collects a share of termination fees. Bots hit a public OTP or signup form to trigger the sends; the account holder pays per message and the "users" never verify, because none exist.

What is an SMS gray route?

A message path that delivers A2P traffic as if it were P2P foreign-origin traffic — spoofed sender IDs, P2P-path injection, or hop-washed origin — to avoid the per-message tariffs and screening of a registered route. In 2026, carriers price that avoidance above the registered tariff.

What is SIM farming (SIM boxing)?

Racks of physical SIM cards terminating traffic so A2P flows look like consumer P2P at the inbound switch; the SIM farm is also the infrastructure for OTP pumping, since the farm's number pool drives the traffic. Carrier fraud screening treats SIM-farm ranges as a blocking signal.

Is a gray route cheaper than a legitimate route?

No — not in 2026. Destination carriers impose unregistered-origin surcharges and pre-delivery blocking that exceed the registered route's per-message cost, so the gray route is now a billing trap plus a compliance violation.

How do attackers exploit OTP endpoints specifically?

A marketing campaign sends to recipients you choose, so it cannot be aimed. An OTP endpoint sends on demand to whatever number the caller submits — so automation can nominate revenue-share numbers and convert your verification product into a spend generator with no gate in the way.

What does Orbit's Verify API do about pumping before a message is sent?

A pre-send Fraud Guard scores the destination against your tenant fraud policy. Refused sends return a synchronous 403 VERIFY_FRAUD_BLOCKED error and a verification.fraud_blocked webhook event, and no verification row is ever created. SIM-swap and line-type policy blocks are also synchronous and webhook-free. The policy — refuse, or pass with the signal — is a tenant setting.

How do I spot a pumped or gray-routed destination after the fact?

GET /api/v1/verify/conversion-anomaly scores each destination prefix by OTP completion rate over a rolling window, flags prefixes converting far below your tenant baseline on material volume, and reports estimated spend-at-risk in USD. A pumped prefix and a SIM-farm range both read as high sends, near-zero verified — the one report flags both halves of the class.

How do I know my traffic hasn't been gray-routed by an upstream provider?

If your sender ID arrives spoofed, your destination conversions drop, and your delivery receipts disagree with your sender-side sends, re-register your sender identity, set tenant-side frequency caps, run the conversion-anomaly report against the suspect windows, and subscribe to account.fraud.alert so the next route-side anomaly reaches your incident path.

Who is responsible for SMS-fraud controls — the platform or the tenant?

The posture is tenant-owned. The platform provides the pre-send gate, the synchronous refusal, the detection events, the anomaly report, and the policy knobs; which policy your traffic runs under, and what your incident process does with the signals, is your compliance and risk decision.

The takeaway

SMS pumping and gray routes are the two halves of one 2026 fraud class: traffic driven to revenue-share ranges, and traffic that dodges registration or terminates in a SIM box. Both now price out as penalties — one as an unbounded spend attack, the other as billable-as-spam. Design against the class the way you design against any other abuse: refuse the send before the money moves, register the sender identity the destination regime expects, cap the velocity a bot can draw, measure conversion per destination so a bad prefix — pumped or gray-routed — surfaces in days, and keep the posture in your own hands so it matches your markets. If you are comparing providers on these controls, the ranked guide Best SMS-Pumping Anti-Fraud Verification APIs 2026 scores who actually ships the gate; the Verify API, the frequency caps guide, and the message suppression guide show how the shipped version behaves when you turn it on.