Skip to main content
Back to blog

What SMS Aggregators Publicly Disclose About Gray Routes — and the GDPR Basis for Sharing Path Data

Path disclosure is the one honest answer an SMS aggregator can give about where your traffic terminates. This explainer reads what aggregators publish about gray routes and SIM-pumping risk, maps the EU GDPR Article 6 basis for sharing per-route path data, and shows how a tenant reads a route-quality report to test the disclosure.

Orbit Editorial Team

Quick answer: Path disclosure is the answer an SMS aggregator gives when a buyer asks where its traffic actually terminates. Publicly, aggregation-layer disclosure comes in three shapes — a named upstream-route inventory, a per-destination failover statement, or a silence that is itself a finding. EU GDPR Article 6 supplies the basis under which per-route path data may be shared between parties on the chain: a legitimate-interest read (Article 6(1)(f)) on network-operations telemetry, or the sender's consent (Article 6(1)(a)) where the recipient would be identified. Devotel Orbit's posture is one answerable hop — outbound SMS terminates over Devotel's own wholesale softswitch with direct interconnects to 500+ carriers — and the tenant-owned read of any provider's disclosure is your own route-quality report. This explainer covers what aggregators publish, what the GDPR basis means for the data you can ask for, and how the sender-island route-quality alerts surface a disclosure gap without duplicating the gray-route fraud explainer.

The three shapes of aggregator path disclosure

Every SMS aggregator can, in principle, answer the same question: which party terminates the traffic it buys from you, per destination country. Publicly, the answer arrives in one of three shapes, ordered by how much of the route the buyer can verify:

  1. A named upstream inventory. The aggregator publishes the parties its destinations terminate on, usually as a coverage map or an integration list. This is the readable disclosure: a buyer running the carrier-of-record self-checks can HLR-dip each destination, compare the terminating network against the published inventory, and read the gap. Gaps are rare at disclosure time; they accumulate as the upstream inventory drifts.
  2. A failover statement without the failover routing. The aggregator names the tiers it fails over between ("gold/silver/bronze" or a primary/secondary split) without saying which destinations currently route over which tier. The route-tier label is the part of this disclosure a buyer can verify against a per-route DLR-drop detector — the label holds if every route reports healthy on the primary tier.
  3. A failover stance that is not a route inventory. An aggregator says it "maintains direct carrier relationships" or "operates an owned network," and does not enumerate upstream parties. This is the silence a carrier-of-record posture publishes against: the buyer-side check is not what the aggregator says but what the delivery records say back.

None of these is inherently false; each is a different level of verifiable disclosure. The buyer-side read of the route-quality report tests which shape actually ships, and the gray-route and SIM-pumping explainer catalogs what an undisclosed path can hide.

The EU GDPR Article 6 basis for sharing path data

GDPR Article 6 lists six lawful bases for processing personal data; for a per-route path record (whose recipient the route report names, and where the path record contains network-operations metadata about who terminates what), two matter:

  • Legitimate interest (Article 6(1)(f)) — the operating basis. Route-quality telemetry — which route a destination terminates on, with what delivery and latency read — is network-operations data, and the legitimate-interest basis covers it when the operation is necessary for the controller's functioning and does not override the recipient's rights. The aggregation chain's per-hop route-quality report and the route-level delivery divergence detector both run on this basis: they are the telemetry the chain's parties need to operate.
  • Consent (Article 6(1)(a)) — the recipient-identifiable basis. Where the path record identifies a specific recipient (a delivery report that names the destination MSISDN against the route), the recipient's consent is the basis — typically gathered at the sender's own opt-in step, and applied per the tenant's own consent posture. The GDPR audit-evidence checklist walks the consent-evidence record the basis requires.

Both bases run as tenant-owned postures on Devotel Orbit: the platform's route-quality report ships because it is necessary network-operations telemetry; the consent-record discipline that attaches a recipient-identifiable path to an opt-in is yours, and the consent-proof-first-messaging post names it. The disclosure question is not "is Article 6 satisfied" — it is read, per route, against the buyer's own report.

Reading the route-quality report against the disclosure

A tenant's route-quality report on Devotel Orbit exposes, per route × destination country, the delivery and the divergence detector's read against its learned baseline. That is the buyer-side test of a provider's disclosure: the aggregator-published route inventory either matches the HLR/read records you can slice, or it does not. The anomaly-detection module walkthrough groups the route-DLR detector with the usage-alert rules so a disclosure gap reads on one lens.

The two lenses the tenant owns:

  1. Divergence detection (the DLR-drop detector against the baseline). A destination's route report names a route green on the published inventory, while the detector reads a divergence against its baseline — the disclosure is only as good as the inventory the provider publishes. On a deliverability surface with the route-DLR detector grouped in, the disclosure test runs per route, per destination country.
  2. Sender audit (registered versus unregistered sender file). The route-quality band shifts on a destination read against the destination regime's registration file — the sender-island route-quality alerts walk the audit and the weekly remediation loop that closes the disclosure gap.

Neither duplicates the gray-route pattern catalog — the SMS pumping and gray-route fraud explainer names the fraud shapes; this explainer names the disclosure shapes and the GDPR basis the data-sharing posture sits on.

Frequently asked questions

What does an SMS aggregator publicly disclose about route paths?

The inventory of upstream parties it terminates on, per destination — when it publishes anything at all. Three shapes hold: a named upstream inventory, a tier failover statement, or a silence that names the question a buyer's own route-quality report answers. The testable answer shows up in delivery records, not in the disclosure itself.

What is the GDPR basis for sharing path data between parties?

Article 6(1)(f) legitimate interest for network-operations telemetry (route-quality and divergence reads), and Article 6(1)(a) consent where the path record identifies a recipient. Both run as tenant-owned postures on Devotel Orbit; the GDPR audit-evidence checklist records the consent-evidence trail a consent basis requires.

Does path disclosure cover gray routes?

A gray route is an undisclosed path — a route that terminates over parties the disclosure does not name. The gray-route and SIM-pumping explainer catalogs the fraud shapes a gray route can hide; the disclosure question is whether the inventory the provider ships answers them.

How do I test a provider's disclosure?

Run the route-quality report on your own traffic: per route × destination country divergence against the baseline (the DLR-drop detector), plus the per-destination sender-registration audit. The disclosure holds where the inventory and your own records agree.

Further reading

What SMS Aggregators Publicly Disclose About Gray Routes — and the GDPR Basis for Sharing Path Data — Orbit by Devotel