Requiring competing services to connect is a recurring regulatory proposal. The difficulty is not the principle but the specification, which must be precise enough to enforce.
Interoperability has several distinct meanings
It can mean exporting your data in a usable format, connecting two services so users on each can interact, or allowing a third party to build on an existing platform.
These impose very different obligations, and a rule written for one produces confusion when applied to another.
Most disputes about whether a company complies turn out to be disagreements about which of these the requirement actually covered.
Interfaces have to be defined by someone
Connection requires an agreed technical interface, and the incumbent generally has both the expertise and the incentive to define it in a way that suits its own architecture.
Regulators rarely have the technical capacity to specify one themselves, so they delegate to standards bodies where the same firms are the dominant participants.
The resulting standard is workable and tends to preserve existing advantages, which is why mandates often deliver less competitive change than expected.
Security and privacy constrain the design
Opening an interface expands the number of parties handling user data, and each additional party is a potential point of failure or misuse.
Requirements therefore need authentication, consent and revocation mechanisms, all of which add complexity that can be used as grounds for restricting access.
Distinguishing a genuine security limitation from a competitive one requires technical judgement that regulators must build or buy.
Maintenance costs fall on the incumbent
A mandated interface must be kept working as the underlying service changes, which is an ongoing engineering obligation rather than a one-time build.
Freezing the interface protects connected parties and slows the incumbent's development, while allowing changes shifts the burden onto everyone connected to it.
Workable regimes usually settle this with notice periods and versioning obligations, requiring old interfaces to keep functioning for a defined time after a replacement appears.
Enforcement needs measurable conditions
An obligation to provide access on reasonable terms is unenforceable without a definition of reasonable, covering latency, feature parity, rate limits and documentation quality.
Rules that specify these become obsolete as technology moves, while rules that do not become litigation about intent.
The regimes that have worked best tend to pair a general obligation with a technical body empowered to update the details, which keeps the standard current without reopening the legislation.