The problem with central hubs
When several organisations need to share data, the instinctive design is a central integration hub. Everyone connects to it, it transforms and routes messages, and it becomes the place where all the data passes through. That is convenient at first. Over time it becomes a single point of failure, a single point of compromise, and a single place where someone could, in principle, read everything.
There is also a governance problem. The hub's operator ends up making decisions that belong to the data owners: who may call which service, how long logs are kept, which versions are supported. Responsibility drifts to the middle, where it is least accountable.
The X-Road idea
X-Road, the open-source data exchange layer that has underpinned Estonian digital services for many years, takes a different approach. Data moves directly from member to member. Each participating organisation runs its own security server, and every request travels from the consumer's security server to the provider's, signed, encrypted and time-stamped along the way.
There is a central component, but its role is narrow. It maintains the register of members, their subsystems and the trust configuration: which certificate authorities and time-stamping services are recognised, and who belongs to the ecosystem. It does not see the payloads. That separation, between governing the trust and carrying the data, is the heart of the model.
The building blocks
For a technical team planning an exchange on this model, the main components are worth naming plainly:
- A central governance service holding the member register and global configuration.
- A security server at each member, terminating mutually authenticated TLS and handling signing and logging.
- Members and subsystems with clear identifiers, so access is granted to a specific system rather than a whole organisation.
- Trust services: a certificate authority, certificate status checking and time-stamping.
- Message logs at each end, so both parties hold a signed record of every exchange.
Sovereignty in practice
Sovereignty is an overused word, but here it has concrete meaning. Each provider decides which consumers may call each of its services, and that decision is enforced at the provider's own security server. Each member keeps its own logs. No third party can quietly read, copy or alter what passes between two members, because there is no third party on the path.
This matters in Europe and in the Gulf alike, where data residency and accountability expectations are high. An exchange built this way can sit entirely within national or organisational boundaries, using open-source software the operator can inspect, run and change without asking a vendor for permission.
What to get right
The software is the easy part. Success depends on the decisions around it. Naming conventions for members and subsystems should be settled before the first connection, because they become hard to change. Onboarding should be a documented, repeatable process rather than a series of favours. Service descriptions should use open standards such as OpenAPI so consumers can build against them without meetings.
API management still has a role. A gateway such as WSO2 can sit behind a member's security server to handle versioning, throttling and developer documentation for that member's own services. The two layers complement each other: the exchange governs trust between organisations, the gateway governs the life of each API.
Finally, plan for operations from the start. Certificate renewal, time-stamping availability and log retention are the things that cause outages in year two. Write the runbooks while the design is fresh, and hand them to the team that will run the exchange.
Starting small
An exchange does not need to launch with every organisation at once. A pilot with two or three members and a handful of services proves the trust chain, the onboarding process and the operational model. From there, growth is mostly administrative, which is exactly what you want from infrastructure.