Guardivia

Grey Routes and Bypass

How are SMS grey routes detected?

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

In short

Grey-route detection combines signaling information, SMPP data, Sender IDs, content characteristics, routing behaviour, test messages, traffic patterns, source intelligence and historical analysis. No single signal is conclusive, so detection scores the correlation across several and confirms candidates with device-based route testing.

The core question

Detection turns on one question: does this traffic behave like what it claims to be? An operator is not looking for a forbidden value in a field. It is looking for commercial traffic wearing the costume of conversational traffic, and the costume is never quite convincing across every dimension at once.

Signals by layer

Each layer contributes evidence that the others cannot see:

  • Signaling — unauthorised or spoofed Global Titles, SRI-SM results inconsistent with the delivery path, home-routing bypass attempts
  • Application — SMPP accounts submitting traffic that does not match their declared profile, or Sender IDs appearing on binds that have never carried them
  • Content — commercial phrasing, OTP structure, branded sender names or URLs in traffic declared as P2P
  • Behaviour — MSISDN ranges with high volume, very high destination diversity, near-zero inbound replies and machine-regular timing
  • Commercial — volumes arriving from a source whose contracted volume is a fraction of what is observed

Correlation, not single indicators

Any one of these has an innocent explanation. A retailer's campaign is commercial content at high volume. A machine-to-machine platform sends with machine regularity. A legitimate aggregator's mix changes when it wins a new customer.

What identifies a grey route is the combination: commercial content, arriving over a P2P-priced path, from a source with no matching agreement, at a volume and destination spread no subscriber would produce, with a Sender ID that does not belong to the account that submitted it.

Confirmation at the handset

Network-side inference identifies candidates. Device-based testing confirms them. A controlled, uniquely identified test message is sent over the route under test to a trap number on a real SIM on the destination network, and the received Sender ID, content, encoding, message-centre information and timing are compared with what was submitted.

When the message arrives from a local mobile number instead of the registered Sender ID, or with modified content, or via a message centre that does not belong to the claimed path, the inference becomes evidence that survives a commercial dispute.

Discuss this with the engineers who build the platform

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