lmost every enterprise messaging RFP has a clause along the lines of 'all traffic must be sent over direct routes only.' Almost no enterprise messaging RFP defines what that means. The result is a procurement category in which two providers can quote the same word and deliver very different things — and the difference matters for cost, latency, deliverability, fraud exposure, and regulatory standing. This is a field guide to what is actually happening on the wire when you submit an A2P SMS, and how to tell what kind of route you are paying for.
What a direct route actually is
A direct route is a contractually sanctioned SMPP bind from your messaging provider into the destination mobile network operator's own SMSC, under an A2P agreement between the provider and the MNO. The provider authenticates as an ESME with a system-ID and password issued by the operator; submit_sm PDUs are accepted, processed by the operator's SMSC, and delivered to subscribers on the operator's RAN. Delivery receipts come back over the same bind. There is exactly one hop between the provider's edge and the destination operator. Pricing is governed by the A2P agreement; sender-ID enforcement is at the operator boundary; the operator can audit every message it received because its own SMSC processed it.
What a grey route is
A grey route is any path that delivers an A2P message to a subscriber without going through an A2P-sanctioned bind at the destination operator. The category contains several flavours, and they fail in different ways.
Grey flavour 1 — SIM-farm injection
An aggregator buys consumer SIM cards on the destination network, racks them into a GSM gateway (a 'SIM box'), and sends each message as ordinary P2P SMS from a consumer MSISDN. The operator sees consumer P2P traffic, bills the SIM owner at retail rates (often near zero on a bundle), and the aggregator collects A2P-grade revenue from the sender. This is functionally SIM-box fraud — it bypasses the A2P agreement entirely.
Grey flavour 2 — partner re-injection
The provider routes traffic to a partner aggregator in a different country, which onward-routes to a second partner, which onward-routes to a third. One of the partners has a direct bind into the destination operator and injects the traffic there. Each hop adds latency, increases drop probability, obscures the true originator of the message from the operator, and creates plausible deniability for everyone in the chain. The traffic eventually arrives via an authorised path, but the path bears no resemblance to the contractually direct one a customer might assume they bought.
Grey flavour 3 — SS7 MT-ForwardSM injection
At the SS7 MAP layer, an interconnect partner can inject MT-ForwardSM messages into the destination operator's MSC, bypassing the operator's own SMSC entirely. The destination operator sees a roaming-style SMS delivery to its subscriber, often with a spoofed originating address, and has limited visibility into the source. This is the classic SS7 fraud pattern that signalling firewalls are built to stop.
Grey flavour 4 — OTT bypass
Some 'SMS' products silently substitute an OTT messaging channel for SMS without informing the sender, then report the message as delivered. The message arrived on a different channel than the sender paid for; the operator never saw it; the sender's compliance posture is invalidated because the regulator-approved sender ID never appeared.
Side-by-side
| Dimension | Direct route | Grey route |
|---|---|---|
| Connection type | Sanctioned SMPP bind to operator SMSC | SIM-farm, multi-hop partner, SS7 injection, or OTT swap |
| Hops to destination | One | Two to many; not always knowable |
| Latency p95 | Typically 1.5–4 seconds | Highly variable; 5–60 seconds is common, sometimes minutes |
| Delivery rate | 97–99% on healthy routes | 60–90%, drops sharply when operator firewalls upgrade |
| Sender-ID enforcement | At the operator boundary; registered IDs accepted, unregistered blocked | Inconsistent; spoofed or unregistered IDs sometimes arrive, sometimes not |
| Cost per message | Higher (A2P rate card) | Lower, sometimes dramatically so |
| Operator visibility | Full — operator processed every message | Partial to none; operator may not know the message existed |
| Regulatory standing | Compliant; sender of record is identifiable | Often non-compliant; can void enterprise compliance posture |
| Fraud exposure | Low | High — same path used by smishing and OTP-interception campaigns |
| Firewall risk | None | Increases over time as operator firewalls mature |
Why grey routes exist at all
Grey routes exist because they are cheaper and because, for years, they worked. A SIM-farm in a low-margin market can terminate A2P at a fraction of the A2P rate card. A multi-hop partner chain takes advantage of arbitrage between bilateral interconnect agreements. Until destination operators deployed modern firewalls, the deliverability gap between grey and direct was modest. That window is closing — every major MENA, African, and Asian operator has invested in SMS firewall capability in the last five years — but the cost arbitrage is real, and there is a long tail of aggregators that operate in the grey because the per-message margins are still significant.
How to tell what you are actually getting
RFP language is not enough; verifying the route quality is. The signals that distinguish a direct route from a grey one in production:
- Latency p95 — direct routes are tight (single seconds); grey routes show wide variance and long tails.
- DLR fidelity — direct routes return granular operator status codes within seconds; grey routes often return synthetic 'delivered' DLRs that do not correspond to a real delivery event.
- Sender-ID behaviour — submit an unregistered sender ID and see what happens; a direct route will reject it at the operator; a grey route may deliver it anyway.
- Originating address on the handset — for any test send, check the actual originator displayed on the receiving handset; if it differs from what you submitted, you are on a grey path.
- Operator inquiry — for high-volume senders, the destination operator can confirm whether traffic from a specific sender ID is arriving through their A2P channel.
When grey is actually acceptable, and when it is not
There is a defensible argument for grey-route economics on certain non-critical traffic in certain markets — low-value marketing in regions with no enforcement, throwaway notifications that nobody is going to act on. Even then, the long-term cost is rising as firewalls mature. For OTP, banking alerts, government communications, anything time-critical or fraud-sensitive, anything in a regulated market, grey is not acceptable. The unit-price saving is modest; the failure-mode cost — a missed login, an enabled smishing campaign that uses your spoofed sender, a regulator finding — is not.
BroadNet operates direct SMPP binds into the GCC operators (du, e&, STC, Mobily, Zain KSA, Ooredoo, Vodafone, Orange) and across our coverage footprint more broadly. Mixed-quality routing is not part of the product.
The role of the operator firewall
From the operator's perspective, the existence of grey routes is a revenue-assurance problem (A2P monetisation) and a subscriber-protection problem (smishing, sender spoofing, OTP interception). Modern firewalls address both — see the longer piece on SMS firewall and the companion piece on SS7 firewall for how they work. From the enterprise sender's perspective, the practical consequence is that the grey-route deliverability gap is widening, not narrowing — anything you ship on a grey route today is exposed to a deliverability cliff the day the destination operator's firewall reaches a new tier of maturity.
Procurement language that actually works
Replace 'direct routes only' with specific, verifiable commitments. Require the provider to name the destination operators for which they hold a direct SMPP bind. Require monthly latency-distribution and delivery-rate reporting per route. Reserve the right to send synthetic test traffic with unregistered sender IDs and inspect the result. Build a contractual remedy for any traffic found on a grey path. None of this is exotic — it is what the disciplined buyers in the category already do.
Two practical edge cases worth budgeting for
Even a direct-route enterprise contract runs into two recurring edge cases that complicate the simple direct-versus-grey framing.
The first is the long tail of small destinations. A messaging provider may hold direct binds into the 30 operators that account for 90% of the customer's volume, but the remaining 10% includes 200 smaller operators where direct binds are commercially impractical. For that long tail, even a high-quality provider routes via partner aggregators — often via well-vetted ones, but still through a path that is not strictly direct. The honest contract recognises this: direct binds where they exist, vetted indirect routes for the small-volume long tail, transparency about which traffic falls into which bucket.
The second is regulatory carve-outs. A handful of markets require A2P traffic to terminate through a designated national gateway regardless of who is sending — the provider has no choice but to route through that gateway, which may not be 'direct' in the SMPP-bind sense but is the only sanctioned path. The contract should accommodate this with named exceptions rather than pretending the provider can hold a direct bind into every operator on earth.
Related reading
- What is an SMS firewall and why operators need it
- What is an SS7 firewall and how it protects mobile networks
- How to choose an enterprise messaging provider
- Glossary — grey routes explained, what is A2P SMS, what is A2P monetisation
- Product pages — A2P SMS and operator SMS firewall
- Coverage — Saudi Arabia routing and CST sender-ID