SMS Pumping Fraud: How AIT Works and How to Stop It

This guide is for engineers, product owners and fraud teams who run any feature that sends SMS to a phone number a user types in. It goes deeper than our OTP messages guide: how pumping attacks are built, which signals reveal them early and how to design controls that stop the bill without blocking real customers.

What is SMS pumping, and who profits?

SMS pumping, also called artificially inflated traffic (AIT), is fraud in which an attacker makes your application send SMS to numbers chosen so that someone earns money from each delivered message. MITRE ATT&CK catalogues it as technique T1496.003, describing adversaries who obtain numbers they control and then trigger large volumes of messages to them.

The economics explain the behavior. Every A2P SMS carries a termination fee paid down the delivery chain to the destination network. When a party in that chain, or one controlling a number range, shares that revenue with the attacker, each fake OTP becomes income for them and a cost for you. The attacker does not need your messages to arrive at a real person, or to read them.

How does an SMS pumping attack work?

A typical attack follows five steps, and the attacker adapts if one step is blocked.

1. Find an SMS trigger that works without a logged-in account: sign-up, login OTP, password reset, phone verification, "text me the app link", referral invites or marketing double opt-in.
2. Obtain destination numbers in ranges that earn revenue, often in countries where termination rates are high and where the target business has few real users.
3. Automate requests with scripts or bots, rotating IP addresses, device fingerprints and user agents to dodge simple limits.
4. Spread the load: many numbers within the same prefixes, or sequential numbers, at a rate just under any obvious alert threshold.
5. Scale or switch: if traffic flows, increase volume, often at night or on weekends when monitoring is thin; if blocked, move to another country or another SMS-sending endpoint.

Any SMS-sending endpoint reachable before authentication is a target, not only the OTP screen.

What are the warning signs?

The most reliable signal is that SMS volume grows without a matching growth in completed actions. Track these indicators per country and per number prefix, not just in total.

Set alert thresholds as deviations from your own baseline for each country and endpoint. A normal conversion rate for a mature market will differ from a newly launched one, so fixed global numbers produce false alarms.

How do you prevent SMS pumping?

Use controls in layers, so that bypassing one does not leave you exposed. The goal is that a successful attacker can only generate a small, capped cost before being stopped.

Layer 1: stop bots before an SMS is triggered

• Bot challenge or risk scoring on every SMS-sending form, as MITRE recommends with CAPTCHA protection.
• App integrity checks for mobile apps, such as Google Play Integrity and Apple App Attest, so requests must come from a genuine app install.
• Require prior behavior: the SMS endpoint should only accept requests from a session that loaded the page or app screen, with a valid server-issued token.

Layer 2: control destinations

• Allow-list countries where you have real users. New countries require an explicit business request.
• Block or challenge risky prefixes within allowed countries when they show attack patterns.
• Validate numbers before sending: correct length and format for the country, and, for high-volume flows, line-type or status checks through a number lookup.

Layer 3: rate limits on several dimensions

Limit per phone number, per prefix, per IP address and network, per device and per session, with short and long windows. A limit on phone number alone fails when attackers rotate numbers; a limit on IP alone fails when they rotate proxies.

Layer 4: spend circuit breakers

• Daily and hourly spend caps per country and per endpoint.
• Automatic pause of a destination when volume exceeds a multiple of its normal level, with a person paged to review.

Layer 5: verification design

• One code per session, short validity, single use, as NIST SP 800-63B describes for out-of-band authenticators.
• Progressive resend delays and a hard cap on resends.
• Offer alternatives such as email links or WhatsApp authentication templates where your users have them, so SMS is not the only route.
• Do not send SMS for low-risk actions that do not need phone verification.

Layer 6: monitoring and response

Dashboards of verification conversion, volume and spend per country and prefix, reviewed daily, plus a runbook that names who can block a country or pause an endpoint and how fast.

Worked example: a Dubai marketplace under attack

"Souq Rafiq" (synthetic), a classifieds marketplace, sends SMS OTPs at sign-up. Its users are mostly in the UAE, Saudi Arabia and Egypt, but the sign-up form accepts any country code.

• Detection: on a Friday night, OTP volume to a distant country triples. Verification conversion for that country falls close to zero, while UAE conversion is unchanged. Requests target numbers with a shared prefix.
• Immediate response: the on-call engineer uses the runbook to disable that destination and adds a temporary prefix block.
• Hardening: the team switches to a country allow-list, adds a bot challenge and session token to the sign-up form, introduces limits per number, IP and device, and sets daily spend caps per country.
• Follow-up: a week later the attacker probes the password reset form, which still had no challenge. The spend cap pauses traffic within minutes; the team applies the same controls there and audits every SMS-sending endpoint.

Common mistakes and limits

• Protecting only the OTP screen while password reset, invite and download-link forms stay open.
• Allowing all countries by default because the form library does.
• Relying on one control, such as CAPTCHA, without caps.
• Watching total volume only. Attacks hide inside aggregate numbers.
• Blocking too broadly and locking out genuine travelling or expatriate users. Prefer challenges and tighter limits over blanket bans in markets you serve.
• Limits: no control is complete; attackers adapt. Industry loss estimates vary widely and come mostly from vendors, so measure your own exposure through spend per verified user rather than relying on headline figures.

How OmniChannels.ai helps

OmniChannels.ai supports OTP and transactional notifications over WhatsApp authentication templates, with one-tap, zero-tap and copy-code OTP, over SMS delivered through BroadNet Technologies' operator connectivity, and over voice. HLR and number lookup helps you check numbers before sending, and delivery reports, with summary and advanced views, filters and CSV export, help you review traffic by destination and status. Billing runs on a prepaid wallet. OTP sending and delivery webhooks are documented in the public REST API.