AIT pumping: anatomy of a grey-route attack
AIT pumping: anatomy of a grey-route attack
Artificially inflated traffic is an invoice fraud dressed as a messaging fraud. The visible symptom is a spike in one-time-password SMS volume. The underlying transaction is a transfer of money from the application sending the messages to a colluding operator or aggregator that routed them. The messages get delivered. Nothing visible happens on the consumer-facing side. No stolen credentials, no account takeover. The whole point of the attack is to make the invoicing look routine while siphoning interconnect revenue.
This is the fraud that X publicly disclosed was costing Twitter around sixty million US dollars a year before remediation in 2024. Industry-wide, the cost is almost certainly an order of magnitude higher. For an engineering team buying A2P SMS delivery, AIT shows up in the cost line of the unit economics, not in the security incident channel.
The attack in one paragraph
An attacker, typically a bot farm, signs up large numbers of throwaway accounts on an application that sends SMS one-time passwords during onboarding. Each signup triggers an OTP SMS to a phone number the attacker controls, or to a number listed at a destination that shares termination revenue back to the attacker's upstream. The application pays the A2P termination fee. The terminating operator or aggregator keeps an above-normal share of that fee. The attacker takes a cut of the operator's inflated revenue. The application's marginal cost per signup goes up, while the attacker's marginal income scales with how fast they can open accounts.
The fraud needs collusion at the termination side. Without an operator or aggregator who pays the attacker out of the inflated interconnect revenue, there is no attack. The messages themselves are not stolen or diverted. They get delivered to numbers that were never meant to receive real verification codes, and the cost of that delivery is what the fraud harvests.
Why this fraud is hard to catch at the application layer
The first published large-scale characterisation of SMS pumping, based on 9.4 million verification requests across a consumer-facing application, identified three patterns that make application-layer filtering weak.
Attackers use short-lived email services to generate throwaway accounts, so any "suspicious email domain" filter is fighting an endless list of new domains. They concentrate traffic on prefix blocks (phone number ranges where a high share of numbers terminate on the colluding operator), which produces a strong statistical signal but only if the cross-account traffic pattern is visible, not just per-account behaviour. They rotate account, number, and device every few requests, which means per-account thresholds are ineffective against an operation that churns accounts faster than any single threshold can fire.
The three-level feature set described in the paper (per-request features, per-user-history features, and country-wide traffic correlation features) achieved 89.6 percent recall on web-client traffic and 91.1 percent on native-app traffic at a false-positive rate of 0.1 to 0.2 percent. That is commercially viable detection accuracy. But it requires the country-wide correlation data, which is exactly the data an application does not have visibility into when it is buying A2P SMS through a chain of aggregators.
The signal that defines AIT is a cross-operator, cross-country pattern. It is detectable at the carrier-routing layer, and only marginally detectable at the application layer when the application has enough traffic volume and visibility into destination-operator statistics to see prefix concentration.
The economic mechanism in more detail
The traffic-pumping family of telecom frauds has been studied for more than a decade in voice contexts, and the SMS variant inherits most of the same economics. An operator with a small subscriber base but a large interconnect rate has an incentive to inflate incoming traffic volume. Each terminated message is paid for by the originating network at a rate set by interconnect agreements, and any marginal terminated message is pure revenue if it is not matched by real subscriber utility. That operator does not need to do anything illegal at the signalling layer. It needs only to drive traffic to numbers it controls in a way that looks, from the originator's side, like ordinary verification-flow SMS.
The "pump" is the bot farm that manufactures the incoming traffic. The colluding operator is the destination that pays for the pump. The victim is the originating application, whose per-signup cost rises until either the rise is investigated or the fraud reaches a ceiling imposed by application-side rate limits. The longer the fraud runs, the more the unit economics of the application degrade. In a consumer-facing fintech or messaging app, the entire margin on user acquisition can disappear before anyone notices.
Academic work on detection via supervised machine learning, applied to voice-call traffic pumping, has shown that route-level and operator-level features carry the predictive signal, not per-call features. The same logic applies to SMS. An ensemble of features at the route and destination-operator level, updated continuously as new prefix-block anomalies emerge, is what separates a real detection pipeline from a rate-limit-based heuristic. Without route-level visibility, an application-side detection pipeline runs into a hard ceiling on what it can catch.
How a licensed operator changes the picture
As a licensed operator with direct MNO interconnects, Tensormobile sees route-level traffic across its own signalling footprint and across the partner routes it uses to terminate messages outside its home network. That visibility makes cross-operator prefix-concentration detection available as a network-side filter, not an application-side one.
The detection pipeline borrows heavily from the published research. Per-request features (destination prefix, source application, source IP, message payload entropy) get scored against per-route baselines. Per-user-history features, where the user is identified by the application's stable identifier, catch the rotation-evasion pattern. Country-wide and operator-wide correlation features (the share of traffic flowing to a given prefix block, the share of verification-class messages on that prefix, the deviation from the prefix's historical baseline) catch the cross-operator correlation. The threshold decision is made at the route level, which means flagged traffic can be held or rejected before it is accepted for termination.
The consequence for the application buying A2P SMS is that AIT-inflated traffic never reaches the termination invoice. It gets filtered at the point of submission. That is the basis for the "no AIT surcharge" product claim: when the filter is on by default with published parameters, the application does not pay for AIT-inflated traffic as a pass-through cost.
The claim only holds if the filter is actually on by default, its false-positive rate is published, and the parameters that would cause legitimate traffic to be filtered are visible. An opaque filter is worse than no filter, because the application has no way to tell whether real users are being silently dropped.
Tuning recall against precision
A filter tuned for 90 percent recall at 0.1 percent false-positive rate sounds good in a paper. It looks different against the traffic of a fintech onboarding 500,000 users a month. At those volumes, a 0.1 percent false-positive rate is 500 legitimate signups per month being rejected at the SMS delivery step. For some applications that is acceptable, especially if the fraud loss prevented is large. For others, particularly those with a high user-acquisition cost, a 500-per-month false-positive rate at the SMS layer is a business problem that has to be met with a retry path, a fallback channel, or a support escalation.
The published detection approach handles this with threshold tuning. The same feature set can run at 95 percent recall and 0.3 percent false-positive rate, or at 85 percent recall and 0.05 percent false-positive rate, depending on application tolerance. The default tuning reflects a specific tradeoff that the integrator can override if the vertical demands it.
An application with ten thousand signups a month probably wants the tighter filter. A cryptocurrency exchange with a concentrated, high-value customer base probably wants the tightest filter plus manual review on edge cases. A high-volume consumer messaging app probably wants the looser filter with a rate-limiting fallback. Exposing the threshold as a lever, rather than presenting it as a binary on-or-off switch, is part of how the filter integrates into different verticals.
What the defence looks like in practice
A durable AIT defence stacks three layers.
The first layer is the route choice: terminate A2P traffic only through routes where the interconnect economics do not incentivise pump collusion. Direct MNO interconnects, with published termination rates and verified destination numbering, are the stable floor. Grey routes, where aggregator chains terminate A2P as if it were P2P traffic to dodge official termination fees, are where pump economics live.
The second layer is the detection pipeline. Route-level features, cross-operator correlation, per-request scoring, tunable thresholds. Operated as part of the delivery path, not as an after-the-fact audit.
The third layer is invoice transparency. The application sees which routes its traffic was filtered on, the false-positive envelope around the filter, and the cost breakdown between accepted and filtered traffic. Without that transparency, the filter is a black box and the application cannot verify it is not paying for AIT traffic anyway.
How TensorConnect handles AIT
TensorConnect's AIT filter runs on every submitted A2P SMS by default. The feature set covers route-level destination-prefix concentration, country-wide verification-traffic share, per-submitter request-rate anomaly, and submitter-and-destination correlation history. The default threshold reflects 90 percent recall at 0.2 percent false-positive rate on the training corpus, consistent with the published literature. The threshold is exposed to integrators who need tighter or looser tuning. The routes Tensormobile terminates on, and the share of filtered traffic per route, are visible in the integrator's dashboard.
Filtered traffic does not get charged. That follows from running the filter at submission rather than at invoice time. If a message gets filtered, the termination cost is not incurred, and there is no pass-through cost to add to the bill.
For integrators running their own fraud model, TensorShield's SIM Farm Detection signal surfaces the MSC-clustering patterns that correlate with organised AIT campaigns, so the picture can compose with other risk signals the integrator already runs. AIT is most reliably caught at the layer where the economics actually live, before the termination invoice gets generated.
