Summary

  • The RIPE database returns a complete administrative record for the Saudi Arabian Internet Exchange — organisation ORG-SAIE1-RIPE, org-name "Saudi Arabia Internet Exchange", org-type OTHER, address P.O Box 6086, Riyadh 11442 — which is everything a registry needs and nothing a peer can test.
  • The three layers that would let an outsider judge a domestic switching fabric — which networks are members, which buildings host them, and which route-server ASN carries their sessions — were not rendered in this retrieval, and a dated PeeringDB network-name query came back without a matching entry in the version I was shown.
  • For a buyer, a content network or a regulator, that distinction decides whether a sovereignty claim describes infrastructure or a lease on a national narrative.

On 4 November 2026 the RIPE database was queried for the string "SAIX" and returned an organisation object with a primary key of ORG-SAIE1-RIPE. Its org-name field reads "Saudi Arabia Internet Exchange". Its descr field reads "Saudi Arabia Internet Exchange (SAIX)". Its org-type field reads OTHER. Its address field reads "P.O Box 6086, Riyadh 11442", and the object declares its source as ripe with a locator to its own organisation page. That is the record, and it is clean, dated and complete for what it is.

What it is, is an administrative identity. Registry organisation objects exist so that resources, abuse escalation and contractual correspondence have an accountable party. They are the reason a network engineer can find out who to serve papers on at three in the morning. On that job the SAIX row does its work.

It does not do the other job. Four questions decide whether an Internet exchange is a working domestic fabric or a sign over a door. Which autonomous systems are members, and are their sessions up? In which buildings do those members sit, and are the buildings separate failure domains or three cages in one hall? Which route-server ASN do members configure, and do the published routing tables show it carrying anything? And what traffic actually crosses the fabric, measured rather than asserted? The RIPE organisation record answers none of them, and no reasonable person should expect it to.

The immediate check on the directory layer came back thin. A PeeringDB network-object query for "saix", made the same day, is reported as returning general network listings but no entry matching the Saudi Arabian Internet Exchange (the query). Read that at exactly its size: one query, one endpoint, one date, with the result reported rather than displayed to me as a full document. It is not evidence that the exchange has no members, and it is not evidence that the exchange is absent from PeeringDB in every table. It is evidence that this particular look, on this particular day, did not surface a network object carrying the name. Absence claims are the cheapest mistake in infrastructure writing, and this one is not on offer.

Why the gap matters is physical. An exchange sells one thing: a shared switching fabric in a building, reachable by members who each bring a port and a BGP session. Every property a customer actually cares about is a property of that fabric, not of the organisation record. Redundancy depends on whether two ports terminate in different buildings on different power feeds. Route-server hygiene depends on whether the operator's own ASN appears in members' prefix paths or whether everyone still builds a full mesh.

Growth depends on member count, and member count without ASNs is a number you cannot reconcile against the global routing table. A facility count of three has the same arithmetic shape whether the truth is three separate halls or three cages behind one door — which is precisely why the count, on its own, cannot settle a resilience question.

BTW's 30 October article on this exchange took the operator's own published counters and did the arithmetic that the homepage did not: 6.6 Tbps of provisioned capacity set against a historical peak of 1.65 Tbps, with a 1.22 Tbps peak, a 903.08 Gbps average and 642.5 Gbps at the time of reading. That comparison is worth making and it stands on the operator's own numbers. But it is a comparison of self-reported stocks against self-reported flows, with no published definition of "provisioned" and no methodological note attached to the peak. An outsider cannot recompute any of it.

The counters answer the sovereignty question only if you accept that the operator's ledger is the evidence.

This is where the disclosure boundary becomes a commercial fact rather than an editorial complaint. A domestic exchange that publishes totals but not the map leaves every counterparty to price an unpriced risk. A cloud region deciding whether its Saudi traffic stays in the kingdom cannot audit the claim. A content network choosing between a local port and an international path has no way to check which buildings its redundancy actually spans. A regulator asserting a share of domestically exchanged traffic has no denominator it did not receive from the party it is regulating.

What closes the gap is unglamorous and entirely within an operator's control: a member list with ASNs, a facility list with street addresses, the route-server ASN and how sessions are distributed across it, and a machine-readable participant export in the standard interchange format. Any two of those four make the fabric arguable. All four make it auditable. The registry row already exists and is accurate; it simply sits one layer below the question everyone is actually asking.

That the operating layers were not rendered in this retrieval does not mean they are empty. It means they are unexamined here, and an unexamined layer is a different object from an absent one. The registry tells you the exchange exists, in Riyadh, as an organisation of type OTHER. Whether Saudi traffic changes hands inside the kingdom is still, publicly, an open question — and the register is the right place to start Only for Strategic Circle, not the place to stop.