Guardivia

Artificially Inflated Traffic

How can mobile operators detect AIT or artificially generated SMS traffic?

Reviewed 2026-09-12 by the Guardivia QoS Engineering Team

In short

Analyse destination behaviour rather than message content. AIT concentrates on narrow MSISDN ranges that receive verification messages but generate no other network activity, produce no subsequent app engagement, and show sharp volume growth confined to specific prefixes — a profile genuine user populations never produce.

Look at the destination, not the message

AIT messages are genuine OTPs from genuine platforms with genuine content. Content analysis finds nothing, because there is nothing wrong with the message — the fraud is in who asked for it.

The detectable anomaly is therefore on the receiving side: the characteristics of the number ranges accumulating this traffic.

The destination profile

Number ranges used for AIT behave unlike any real subscriber population:

  • They receive verification messages but generate almost no outbound activity, calls or data usage
  • Volume growth is concentrated in narrow, contiguous prefix blocks rather than spread across the subscriber base
  • Individual numbers receive verifications from many unrelated platforms in a short period
  • Verification is never followed by the messaging pattern a real new user produces
  • Activity is evenly distributed across hours, without the daily rhythm of a human population
  • Ranges are often recently activated, or belong to blocks with unusual provisioning history

Correlating with the enterprise side

The strongest confirmation comes from the sending platform, which can see what the operator cannot: whether verification actually completed and whether an account was created.

A number range with a near-zero conversion rate — thousands of codes sent, almost none entered — is conclusive. Operators that build a channel for enterprises and aggregators to report conversion anomalies detect AIT considerably faster, and turn a difficult conversation into a collaborative one.

Building the detection

Practically, this means profiling inbound OTP traffic by destination range, maintaining a baseline of normal verification volume per range, and alerting on ranges whose verification volume rises without a corresponding rise in any other network activity.

The baseline requirement is why destination-range distribution belongs in the pre-deployment traffic baseline. An operator that recorded only aggregate volumes has no reference to detect this against.

Discuss this with the engineers who build the platform

Questions about how this applies to your network go straight to the QoS Engineering Team.