Competition Law And Interoperability-By-Default Frameworks .

 

Competition Law and Interoperability-by-Default Frameworks

1. Introduction

Interoperability-by-default refers to a regulatory or competition-law framework in which products, platforms, operating systems, networks, or digital services are required to be capable of interacting with competing or complementary products without the user having to overcome artificial technical, contractual, or commercial barriers.

Traditional competition law generally treats interoperability as an issue arising from refusal to supply, denial of access, tying, exclusionary conduct, essential facilities, network effects, or standard-setting. Modern digital regulation goes further by imposing ex ante interoperability obligations on designated gatekeepers.

The European Union's Digital Markets Act (DMA) is the clearest current example. Article 6(7) requires designated gatekeepers to provide effective interoperability with relevant hardware and software features of their operating systems, while Article 7 establishes interoperability obligations for certain messaging services.

Thus, interoperability-by-default represents a movement from:

"A dominant undertaking may have to provide interoperability in exceptional circumstances"

towards:

"Certain strategically important platforms must design and operate their systems so that interoperability is available as a baseline competitive condition."

2. Meaning of Interoperability

Interoperability means the ability of independently supplied products or services to communicate, exchange information, access functionality, or operate together effectively.

Examples include:

  • an alternative AI assistant accessing operating-system functions;
  • a third-party smartwatch communicating with a dominant smartphone OS;
  • competing messaging services communicating with a dominant messaging platform;
  • cloud customers moving workloads between providers;
  • competing software communicating with dominant enterprise software;
  • payment applications accessing relevant device functionality;
  • alternative browsers interacting with operating-system functions;
  • IoT devices communicating through common protocols.

Interoperability can therefore be:

A. Technical interoperability

Systems can technically communicate.

B. Functional interoperability

A competing product can access the functionality necessary to compete effectively.

C. Data interoperability

Relevant data can be exchanged in usable formats.

D. Protocol interoperability

Different systems can use common technical protocols.

E. Commercial interoperability

The dominant undertaking does not impose contractual terms that make technical interoperability commercially ineffective.

F. User-level interoperability

The ordinary user can communicate or transact across competing systems without unreasonable technical barriers.

3. What Does "By Default" Add?

Ordinary interoperability may require a competitor to request access and negotiate with the incumbent.

Interoperability-by-default reverses that starting position.

Traditional modelInteroperability-by-default
Closed system is the starting pointInteroperability is the starting point
Competitor requests accessAccess is presumptively available
Dominant firm controls technical interfaceRegulator establishes minimum access requirements
Negotiation determines functionalityMinimum interoperability is legally protected
Ex post antitrust investigationFrequently ex ante regulatory obligation
Proof of abuse may be requiredDesignated firms may have direct obligations
User may have to change settingsInteroperability should work without artificial friction

This is particularly important where network effects mean that the value of a service increases with the number of users connected to it.

4. Why Interoperability Is a Competition Issue

4.1 Network effects

A dominant platform may become stronger as more users join it.

For example:

More users → greater network value → more users → greater attractiveness → stronger market position.

Interoperability can partially break this cycle because users of different networks can interact.

4.2 Switching costs

Users may remain with a platform because leaving means losing:

  • contacts;
  • messages;
  • data;
  • applications;
  • connected devices;
  • business relationships;
  • workflows;
  • historical records.

Interoperability reduces the competitive significance of these switching costs.

4.3 Lock-in

A platform can use technical architecture to make its ecosystem difficult to leave.

Interoperability can transform:

closed ecosystem → open ecosystem → greater competitive pressure.

4.4 Entry barriers

A new entrant may be technologically capable but unable to compete because it cannot interact with the dominant platform.

This produces a distinction between:

technological entry and commercially viable entry.

A competitor may technically enter the market while remaining commercially ineffective because consumers cannot communicate or exchange data with the incumbent ecosystem.

5. Interoperability and Article 102 TFEU

Under Article 102 TFEU, interoperability disputes may arise through several doctrines.

1. Refusal to supply

A dominant undertaking refuses access to an interface, protocol, infrastructure, or information.

2. Essential facilities

The requested interoperability resource may be sufficiently indispensable to competition.

3. Discriminatory access

The dominant undertaking provides interoperability to its own products but restricts equivalent access for competitors.

4. Degraded interoperability

Access is technically offered but deliberately made inferior.

5. Margin squeeze

Interoperability may be offered at conditions that make downstream competition economically impossible.

6. Tying and bundling

A dominant platform may condition interoperability upon adoption of another product.

7. Self-preferencing

The platform may give its own services privileged access to functionality unavailable to competitors.

6. The Six Major Case Laws

Case 1: Microsoft v Commission — T-201/04

This is the central European competition-law case concerning interoperability.

The European Commission found that Microsoft had abused its dominant position by refusing to provide interoperability information necessary for competitors' work-group server products to interoperate effectively with Windows PCs.

The General Court upheld the central interoperability infringement in 2007.

Importance

The case demonstrated that interoperability information can constitute a competitively significant input.

The Court accepted that Microsoft could not use its control over a dominant operating system to deprive competing server products of effective interoperability.

Principle

Where a dominant undertaking controls an interface necessary for effective competition, withholding interoperability information may constitute abusive exclusionary conduct.

Relevance to interoperability-by-default

Microsoft represents the ex post antitrust model:

dominance + exceptional circumstances + exclusionary refusal → competition-law intervention.

Modern interoperability-by-default frameworks move beyond this model by establishing access obligations before individual competitors have to prove all the traditional refusal-to-supply conditions.

7. Bronner v Mediaprint — C-7/97

In Oscar Bronner GmbH & Co. KG v Mediaprint, the Court considered whether a dominant newspaper undertaking was required to provide a rival with access to its newspaper home-delivery network.

The Court established a demanding test for compulsory access.

The facility generally had to be:

  1. indispensable;
  2. unavailable through realistic alternatives; and
  3. such that refusal could eliminate effective competition, subject to the circumstances identified by the Court.

Competition-law significance

Bronner protects a dominant firm's property and freedom of contract against automatic access obligations.

Interoperability significance

The case demonstrates why traditional Article 102 law does not automatically create interoperability rights.

A rival cannot simply argue:

"Interoperability would make competition easier; therefore the dominant undertaking must provide it."

The legal threshold can be substantially higher.

Significance for interoperability-by-default

This is precisely the gap that ex ante digital regulation attempts to address.

Instead of requiring every challenger to satisfy a stringent essential-facilities analysis, legislation can determine in advance that interoperability is competitively necessary for particular gatekeeper services.

8. IMS Health v NDC Health — C-418/01

In IMS Health GmbH & Co. OHG v NDC Health, the dispute concerned a copyrighted modular structure used for pharmaceutical sales data.

The Court examined when refusal to license intellectual property could amount to abuse of dominance.

The case developed the exceptional-circumstances approach associated with compulsory licensing.

Importance

The Court emphasized circumstances such as:

  • indispensability;
  • prevention of the emergence of a new product or service;
  • lack of objective justification; and
  • potential elimination of competition.

Interoperability relevance

Digital interoperability frequently involves:

  • APIs;
  • protocols;
  • software interfaces;
  • data structures;
  • technical documentation;
  • intellectual property.

IMS Health therefore provides an important legal boundary.

Interoperability regulation must balance competition with intellectual-property protection.

A general interoperability obligation does not necessarily mean that every proprietary technology must automatically be disclosed.

9. Magill — Joined Cases C-241/91 P and C-242/91 P

The Magill cases concerned television programme listings and copyright.

The Court recognized that refusal to license intellectual property could, in exceptional circumstances, constitute abuse of dominance.

The case is important because it helped establish the circumstances in which intellectual-property exclusivity can yield to competition concerns.

Interoperability significance

The analogy with modern digital ecosystems is important.

A dominant platform may control:

  • proprietary APIs;
  • technical interfaces;
  • device functionality;
  • communication protocols;
  • data structures.

Competition law must determine whether proprietary control should remain protected or whether its use has become exclusionary.

Key principle

Intellectual-property rights are not automatically displaced by competition law, but their exercise may become abusive in exceptional circumstances.

10. Slovak Telekom v Commission — C-165/19 P

Slovak Telekom is especially important for understanding the relationship between regulatory access obligations and competition law.

The case concerned access to the incumbent telecommunications operator's local loop and the conditions imposed on competing operators. The Court held that, because the undertaking was already subject to a regulatory obligation to provide access, the stringent Bronner indispensability requirement applicable to an outright refusal did not have to be demonstrated in the same way.

Importance

This creates a critical principle:

When access is already legally required, competition law can scrutinize the conditions under which access is supplied rather than treating the case as an ordinary voluntary refusal of access.

Interoperability application

Suppose a digital regulation requires a platform to provide interoperability.

The platform could potentially comply formally while imposing:

  • excessive technical requirements;
  • discriminatory terms;
  • unreasonable authentication procedures;
  • delayed access;
  • inferior functionality;
  • excessive fees;
  • discriminatory security requirements.

The question therefore becomes not merely:

"Did the platform provide interoperability?"

but:

"Did it provide effective interoperability?"

11. Huawei Technologies v ZTE — C-170/13

In Huawei Technologies v ZTE, the Court examined competition-law issues involving patents essential to a technical standard and FRAND licensing commitments.

Although the case concerned standard-essential patents rather than platform interoperability directly, it is highly relevant to interoperability frameworks.

Why?

Standards create interoperability.

For example:

common technical standard → compatible products → larger market → greater consumer choice.

If a company controls a patent essential to that standard, it may possess substantial leverage over competitors.

FRAND principle

The case established a framework for balancing:

  • intellectual-property rights;
  • standardization;
  • competition;
  • access;
  • licensing negotiations.

Interoperability lesson

A standard cannot easily function as an interoperability mechanism if essential technologies are controlled in a manner that prevents competing products from accessing the standard on appropriate conditions.

12. Google Android — T-604/18 and C-738/22 P

Google Android provides an important ecosystem example.

The European Commission's Android case involved:

  • Android operating systems;
  • Google Search;
  • Chrome;
  • Google Play;
  • agreements with device manufacturers;
  • anti-fragmentation arrangements;
  • pre-installation and exclusivity mechanisms.

The General Court examined Google's conduct under Article 102 TFEU and upheld major elements of the Commission's findings in 2022.

Importantly, the Court of Justice issued a further judgment on the appeal in July 2026, concerning contractual restrictions, tying, exclusivity payments and Android forks.

Interoperability relevance

The Android litigation demonstrates how control over an operating-system ecosystem can affect:

  • alternative operating systems;
  • application distribution;
  • competing search services;
  • device manufacturers;
  • downstream innovation.

Broader lesson

Competition can be harmed not only by an outright refusal to interoperate, but also by ecosystem architecture and contractual restrictions that make alternatives commercially difficult to develop or distribute.

13. From These Cases to Interoperability-by-Default

The cases collectively show an evolution:

First generation

Magill / Bronner / IMS Health

Focus:

When can competition law force a dominant firm to provide access?

Second generation

Microsoft

Focus:

Can a dominant technology platform use control over interoperability information to exclude competitors?

Third generation

Slovak Telekom

Focus:

Where access is already required by regulation, can competition law scrutinize restrictive access conditions?

Fourth generation

Google Android

Focus:

Can ecosystem architecture, defaults, contractual restrictions and platform control reinforce dominance?

Fifth generation

DMA interoperability-by-default

Focus:

Should designated gatekeepers be required proactively to provide effective interoperability so that competition does not depend upon lengthy ex post litigation?

14. EU Digital Markets Act and Interoperability-by-Default

The DMA represents the clearest legislative movement toward an interoperability-by-default framework.

Article 6(7): Operating-system interoperability

Article 6(7) requires designated gatekeepers to provide third parties with effective interoperability with hardware and software features of the gatekeeper's operating system under specified conditions.

The Commission describes the objective as ensuring that third parties can compete on equal terms with the gatekeeper's own services.

Examples

The framework can concern:

  • connected devices;
  • operating-system functionality;
  • AI assistants;
  • hardware features;
  • software features.

In July 2026, the Commission adopted binding specification measures concerning Google's Android interoperability for competing AI services, requiring access to specified Android features so competing AI services could compete with Google's own AI services.

15. Article 7: Messaging Interoperability

Article 7 applies to designated gatekeepers providing certain number-independent interpersonal communication services.

The obligation requires interoperability with other qualifying messaging services.

The implementation is phased.

Initial functionality

The framework covers:

  • one-to-one text messaging;
  • images;
  • voice messages;
  • videos;
  • attached files.

Subsequent functionality

It expands toward:

  • group messaging;
  • additional interoperable functions.

The phased approach recognizes that interoperability is not simply a legal switch; technical implementation, cybersecurity and reliability must also be addressed.

16. Why "Default" Interoperability Is Particularly Important in Digital Markets

Digital markets present characteristics that make traditional ex post intervention difficult.

Network effects

A new entrant may never reach sufficient scale because users cannot communicate with incumbent users.

Data advantages

The incumbent may possess extensive historical and behavioural data.

Ecosystem effects

A platform may control:

OS + app store + payment system + browser + messaging + cloud + AI + hardware.

Switching costs

Users may face substantial costs in leaving an ecosystem.

Multi-homing limitations

Consumers may technically use several services but still depend on the dominant platform because their contacts, applications or business relationships remain there.

Speed of technological change

By the time a conventional Article 102 case is concluded, market conditions may have changed dramatically.

17. Core Elements of an Interoperability-by-Default Framework

A sophisticated framework should contain at least the following components.

17.1 Scope of covered undertakings

The obligation should normally target undertakings possessing substantial ecosystem power rather than every firm.

Possible criteria:

  • market position;
  • number of users;
  • network effects;
  • dependence of business users;
  • vertical integration;
  • control over essential interfaces.

17.2 Scope of covered functionality

The law should specify whether interoperability applies to:

  • data;
  • APIs;
  • messaging;
  • hardware;
  • software;
  • authentication;
  • payments;
  • cloud infrastructure;
  • AI functionality;
  • connected devices.

17.3 Non-discrimination

A platform should not provide:

Gatekeeper service → full functionality

while providing:

Competitor → restricted functionality.

This is especially important where the platform operates its own competing downstream service.

17.4 Effective rather than nominal interoperability

Simply publishing an API may not constitute meaningful interoperability.

The regulator should examine:

  • latency;
  • functionality;
  • reliability;
  • documentation;
  • access procedures;
  • technical restrictions;
  • fees;
  • security requirements.

18. Security and Privacy Exceptions

Interoperability is not absolute.

A platform may legitimately need to protect:

  • cybersecurity;
  • privacy;
  • encryption;
  • authentication;
  • system integrity;
  • fraud prevention;
  • user safety.

The important competition-law question is whether these justifications are genuine, proportionate and technically necessary, rather than being used as pretexts for exclusion.

The FTC has specifically noted the need to balance interoperability benefits with privacy and security concerns.

The DMA similarly permits appropriately justified measures necessary and proportionate to protect the integrity of the operating system, hardware or software features.

19. Competition Risks Created by Poorly Designed Interoperability

Interoperability itself can generate competition problems.

A. Coordinated conduct

Interoperability standards can facilitate information exchange among competitors.

B. Standard-setting collusion

Competitors could manipulate standards to exclude rival technologies.

C. Reduced innovation

A rigid mandatory standard could reduce incentives to develop alternative architectures.

D. Security risks

Opening interfaces can increase attack surfaces.

E. Privacy risks

Cross-platform data exchange can create additional data-processing risks.

F. Strategic interoperability

A dominant platform could technically comply while designing interfaces that are difficult to use.

Thus:

Interoperability must be effective without becoming a mechanism for collusion or unnecessary standardization.

20. Interoperability and Standard-Setting

Standard-setting is closely connected to interoperability.

A technical standard can produce enormous benefits:

common standard → compatibility → economies of scale → lower costs → consumer choice.

But standard-setting can also produce:

competitor coordination → exclusionary standard → foreclosure of alternative technology.

Competition authorities therefore examine:

  • participation rules;
  • transparency;
  • voting procedures;
  • intellectual-property policies;
  • FRAND commitments;
  • exclusion of competing technologies;
  • access to standards;
  • implementation conditions.

The Huawei v ZTE framework illustrates the importance of competition rules where standard-essential intellectual property interacts with interoperability.

21. Interoperability and Cloud Computing

Cloud services illustrate another major application.

Interoperability problems can include:

  • proprietary APIs;
  • data portability restrictions;
  • technical incompatibility;
  • egress charges;
  • licensing restrictions;
  • dependence on proprietary services.

The UK's CMA cloud market investigation concluded in 2025 that limits on customer choice included data egress fees and barriers to interoperability restricting switching and multi-cloud use.

This demonstrates that interoperability can be relevant even when there is no traditional physical infrastructure monopoly.

22. Interoperability and AI

AI creates a newer dimension.

A dominant operating system may control:

  • microphones;
  • cameras;
  • notifications;
  • location services;
  • screen controls;
  • device actions;
  • personal data interfaces;
  • system-level assistants.

If the platform's own AI service can access those functions but competing AI services cannot, interoperability restrictions can become a competitive bottleneck.

The European Commission's July 2026 Android specification decision directly illustrates this issue: competing AI services were given access to specified Android features so that they could compete with Google's AI services.

23. Interoperability and IoT

The Internet of Things creates a particularly strong interoperability problem.

Consider:

smartphone → smart home hub → thermostat → security system → vehicle → wearable.

If every manufacturer creates a closed ecosystem, consumers may be unable to combine products.

Competition concerns include:

  • proprietary protocols;
  • closed APIs;
  • exclusive device certification;
  • discriminatory access;
  • incompatible authentication systems;
  • ecosystem-specific cloud services.

Interoperability can therefore prevent manufacturers from converting technical compatibility into an artificial competitive barrier.

24. Interoperability Remedies

Competition authorities can employ several remedies.

Structural remedies

In exceptional circumstances:

  • separation of business units;
  • divestiture;
  • separation of infrastructure from downstream services.

Behavioural remedies

More common:

  • API access;
  • protocol disclosure;
  • technical documentation;
  • non-discrimination;
  • access obligations;
  • licensing requirements;
  • interoperability testing.

Monitoring remedies

A regulator may appoint:

  • monitoring trustees;
  • technical auditors;
  • independent compliance monitors.

The Microsoft litigation is particularly significant because its remedy framework included independent monitoring arrangements.

25. Interoperability-by-Default vs Essential Facilities

Essential facilities doctrineInteroperability-by-default
Generally ex postPrimarily ex ante
Dominance must be establishedRegulatory designation may suffice
Indispensability may be criticalStatute defines covered obligation
Exceptional remedyBaseline regulatory obligation
Case-by-caseStandardized requirements
Litigation-intensiveAdministrative compliance framework
Bronner-type concernsDMA-type obligations

This distinction is fundamental.

Essential facilities asks:

"Should this dominant firm be compelled to provide access in this particular case?"

Interoperability-by-default asks:

"Should this category of strategically important platform be designed and operated on the assumption that effective interoperability is a competitive requirement?"

26. Competition-Law Test for Interoperability-by-Default

A useful analytical framework is:

Step 1 — Identify the ecosystem

What platform, operating system, network or infrastructure is involved?

Step 2 — Establish market power

Examine:

  • market shares;
  • network effects;
  • switching costs;
  • entry barriers;
  • data advantages;
  • vertical integration.

Step 3 — Identify the interoperability bottleneck

What functionality cannot realistically be replicated?

Step 4 — Identify competitive harm

Does restricted interoperability:

  • exclude rivals?
  • increase switching costs?
  • reinforce network effects?
  • prevent entry?
  • favour the platform's own product?

Step 5 — Assess alternatives

Can competitors obtain equivalent functionality elsewhere?

Step 6 — Examine objective justification

Are restrictions genuinely necessary for:

  • security?
  • privacy?
  • system integrity?
  • technical performance?

Step 7 — Select remedy

Possible solutions:

  • access;
  • API;
  • data portability;
  • non-discrimination;
  • technical standards;
  • interoperability testing;
  • monitoring.

Step 8 — Monitor effectiveness

The regulator should assess whether interoperability is:

available + technically effective + timely + non-discriminatory + commercially usable.

27. Key Case-Law Matrix

CaseMain issueInteroperability lesson
Microsoft v Commission, T-201/04Refusal to provide interoperability informationDominant software platform cannot necessarily use interoperability control to exclude rivals
Bronner, C-7/97Refusal of access to delivery infrastructureTraditional compulsory-access doctrine has a demanding threshold
IMS Health, C-418/01Refusal to license protected structureIP-based interoperability obligations require exceptional circumstances
Magill, C-241/91 P & C-242/91 PCopyright and refusal to licenseIP exclusivity can yield to competition law in exceptional circumstances
Slovak Telekom, C-165/19 PRegulated telecommunications accessOnce access is legally required, restrictive access conditions can be scrutinized without simply applying the Bronner refusal test
Huawei v ZTE, C-170/13Standard-essential patentsInteroperability standards and IP rights require competition-sensitive FRAND mechanisms
Google Android, T-604/18 / C-738/22 PAndroid ecosystem restrictionsPlatform architecture, contractual restrictions and defaults can influence ecosystem competition
EU DMA Articles 6(7) & 7Ex ante interoperabilityMoves from exceptional access remedies toward mandatory interoperability for designated gatekeepers

28. Legal Significance of the Framework

The most important conceptual development is the shift from access as an exception to interoperability as a regulatory design principle.

Traditional competition law asks whether a particular refusal or restriction constitutes an abuse.

Interoperability-by-default frameworks instead recognize that in markets characterized by:

  • powerful network effects;
  • ecosystem dependence;
  • high switching costs;
  • technological lock-in;
  • platform integration;

waiting for conventional antitrust litigation may allow the incumbent ecosystem to become entrenched.

The DMA consequently uses interoperability as one of the instruments intended to increase contestability in digital markets. The Commission expressly describes Article 6(7) as seeking to allow third parties to compete on equal terms with gatekeeper services.

29. Conclusion

Interoperability-by-default frameworks represent an important evolution in competition law.

The classical cases—Magill, Bronner, IMS Health and Microsoft—developed principles for determining when competition law can require or facilitate access to a dominant firm's infrastructure, information or intellectual property.

Slovak Telekom demonstrates how the analysis changes where access is already mandated by regulation. Huawei v ZTE shows how standardization and intellectual property interact with interoperability, while Google Android demonstrates how ecosystem design, defaults, contractual restrictions and platform integration can affect competitive conditions.

The modern approach, particularly under the EU Digital Markets Act, increasingly recognizes that interoperability may need to be established before exclusionary effects become irreversible. Article 6(7) addresses interoperability between third parties and designated operating systems, while Article 7 establishes a specific framework for interoperability between certain messaging services.

The central legal principle can therefore be summarized as:

Interoperability-by-default seeks to ensure that control over a critical digital interface does not become an enduring barrier to entry, switching, innovation and effective competition, while preserving proportionate safeguards for security, privacy, intellectual property and system integrity.

LEAVE A COMMENT