AIT Fraud Explained: How Attackers Drain Your OTP Budget

Somewhere in your signup funnel is an endpoint that sends a text message to anyone who asks for one — no login required, by design, because the whole point is verifying someone before they have an account. That's also exactly what makes it profitable to attack. The scheme is called Artificially Inflated Traffic (AIT) fraud, sometimes called SMS pumping, and industry estimates put the damage at roughly $1.6 billion a year. Most teams have never heard of it until their SMS bill spikes for no reason.

Here's how it actually works, why it's so hard to catch, and what actually stops it.

What AIT fraud is

AIT fraud doesn't target your users — it targets your OTP endpoint directly. A fraudster controls, or has a revenue-sharing arrangement with, a premium-rate termination route: a phone number range where the local carrier (or a "gray route" reseller sitting between your SMS provider and the carrier) collects a termination fee for every message delivered to it. The fraudster then uses bots or scripts to trigger your "send verification code" endpoint thousands of times against numbers on that route.

Your SMS provider delivers the messages — or reports that it did — and bills you per message. A cut of what you paid flows back to whoever controls the destination route. Nobody ever enters the code. Nobody needed to. The fraud is complete the moment the message is sent.

Why it's so hard to catch

A single fraudulent OTP request looks identical to a real one: one phone number, one API call, no password, no account to flag as compromised. Scaled up across thousands of numbers and spread across many IPs, it blends into normal signup traffic almost perfectly. Basic defenses don't help much either — CAPTCHA slows down naive scripts but not a funded operation running residential proxies, and rate-limiting by IP alone is easy to route around.

The tell is usually in the numbers you'd only notice after the fact: verification-send volume climbing while actual signups stay flat, delivery costs concentrating on a handful of unfamiliar country codes, and completion rates (codes actually entered) collapsing for a subset of traffic. By the time that shows up in a monthly invoice, the damage is already done.

Common attack patterns

• Bot-driven signup abuse — scripts hammer a public registration or password-reset form purely to trigger OTP sends, never completing the flow.
• Route targeting — traffic is disproportionately aimed at premium or unusual destinations, since that's where the termination payout is highest.
• Gray-route exploitation — fraud is easiest where an SMS message passes through multiple resellers before reaching a carrier; more hops mean more opportunities for someone in the chain to profit from inflated volume.
• Low-and-slow campaigns — some operations deliberately stay under obvious rate-limit thresholds, spreading requests across time and IP ranges to avoid detection entirely.

What actually stops it

None of these are exotic — they're the same hygiene most teams under-invest in until it costs them:

• Rate limiting per phone number and device, not just per IP — a real user doesn't request five codes in ten seconds.
• CAPTCHA or proof-of-work before OTP dispatch, specifically on unauthenticated endpoints like signup and password reset.
• Phone number validation before sending — a carrier/HLR lookup catches invalid, unreachable, or known-abusive number ranges before you pay to message them.
• Delivery and cost monitoring with anomaly alerts — flag sudden volume spikes to unfamiliar countries, not just monthly totals after the invoice lands.
• Fewer resellers in the delivery path — every gray-route hop between your provider and the destination carrier is a potential participant in the fraud's payout chain.

That last point is the structural fix, not just a mitigation. It's also where channel choice matters more than most teams realize.

Why Verify Call sidesteps the problem entirely

AIT fraud is fundamentally an SMS termination-fee exploit — it depends on a message being billable and routable through a chain where someone downstream profits from volume. Verify Call doesn't have that economics. There's no SMS text to route through resellable gray routes and no per-message termination fee for a fraudster to skim; the "code" is a caller ID on a direct voice call over carrier infrastructure, not a billable payload traveling through intermediaries. That's why it doesn't just make AIT harder — it removes the attack surface completely.

For SMS traffic you still send — through WhatsApp or Telegram fallback corridors, for instance — routing through fewer intermediaries still matters. Novauth connects directly to tier-1 carrier networks over secured SS7 and SIP rather than reselling through gray-route aggregators, and every send is logged with carrier, duration, and outcome so anomalous volume is visible in your dashboard, not buried in next month's invoice.

The takeaway

AIT fraud thrives on two things: an unauthenticated endpoint that sends something billable, and enough hops in the delivery path for someone to profit from inflated volume. You can't remove the first without breaking your product — verification has to work before login exists. But you can remove the second, either by tightening the SMS path you already have, or by moving your primary verification channel to one where the exploit simply doesn't apply.

Compare channels on pricing, read more on security, or see how Verify Call works end to end.