Competition Law and Interoperability-by-Design Obligations

1. Introduction

Interoperability-by-design refers to the obligation or regulatory expectation that digital products, platforms, software systems, networks, or technical infrastructures should be designed from the outset to permit meaningful interaction with competing or complementary products and services.

Traditional interoperability remedies generally intervene after a competition problem has arisen—for example, when a dominant platform refuses access to an API or makes its service technically incompatible with competitors. Interoperability-by-design goes further: it seeks to incorporate technical openness, portability, compatibility, API access, protocol support, and non-discriminatory interfaces into the architecture of the system itself.

From a competition-law perspective, interoperability-by-design can address:

• exclusionary conduct by dominant undertakings;
• switching costs and lock-in;
• network effects;
• foreclosure of competitors;
• self-preferencing;
• tying and bundling;
• refusal to supply or provide technical access;
• discriminatory access to APIs and data;
• restrictions on multi-homing;
• ecosystem leveraging;
• standards-related market power; and
• exploitation of essential digital infrastructure.

The central competition-law question is whether an undertaking is using technical design choices as a mechanism to preserve or extend market power.

2. Meaning of Interoperability-by-Design

Interoperability means that two independently developed systems can communicate, exchange information, or operate together.

Interoperability-by-design means that interoperability is considered during the initial design and development of a product or ecosystem rather than being added only after a regulatory intervention.

It may include:

1. Open APIs
2. Standardised data formats
3. Open communication protocols
4. Data portability
5. Identity interoperability
6. Payment interoperability
7. Messaging interoperability
8. Cross-platform functionality
9. Hardware-software compatibility
10. Third-party developer access
11. Interoperable authentication
12. Common technical standards

For example, a dominant messaging platform could technically design its system so that users can communicate with users of another compatible messaging service without having to abandon the original platform.

3. Competition-Law Rationale

Interoperability can reduce the competitive significance of network effects.

Suppose:

Platform A has 90 million users.

A consumer may prefer Platform A simply because everyone else is already there. A rival with better technology may nevertheless be unable to compete because consumers do not want to leave the established network.

Interoperability changes the competitive dynamics:

Closed ecosystem

Large user base → strong network effects → switching costs → stronger market power → greater user dependence

Interoperable ecosystem

Large user base → compatibility with rivals → reduced switching costs → increased multi-homing → greater competitive pressure

Thus, interoperability can convert a competition problem based upon ecosystem lock-in into a more contestable market.

4. Interoperability as a Competition-Law Remedy

Interoperability can operate in two different ways.

A. Ex-post remedy

The authority first establishes an infringement and subsequently orders interoperability.

Example:

Dominant undertaking → refusal of technical access → foreclosure → infringement → interoperability remedy.

B. Ex-ante obligation

The law imposes interoperability obligations before a particular infringement has been established.

Example:

Designated gatekeeper → statutory interoperability obligation → technical access required from the outset.

The second model is particularly important in modern digital competition regulation.

5. Legal Theories Supporting Interoperability Obligations

A. Abuse of Dominance

A dominant undertaking may abuse its position by deliberately making its ecosystem incompatible with competing products.

Relevant forms of conduct include:

• refusal to provide technical information;
• denial of API access;
• discriminatory interoperability;
• degradation of interoperability;
• deliberate technical incompatibility;
• restrictive licensing;
• exclusionary software architecture.

B. Refusal to Deal / Essential Facilities

Interoperability can become particularly important where the interface or infrastructure controlled by a dominant undertaking is effectively indispensable.

The traditional essential-facilities analysis generally considers:

1. control of an indispensable facility;
2. inability of competitors to reasonably reproduce it;
3. denial of access;
4. elimination or substantial restriction of competition; and
5. absence of objective justification.

In digital markets, the relevant "facility" may be:

• API infrastructure;
• operating-system functionality;
• app-store infrastructure;
• interoperability protocols;
• technical interfaces;
• identity systems; or
• critical data infrastructure.

C. Tying and Bundling

A dominant platform may make one product technically dependent upon another.

For example:

Operating system → mandatory proprietary identity system → restricted competing service.

Interoperability can prevent the technical dependency from becoming an exclusionary tie.

D. Network Effects

Network effects are central to interoperability analysis.

The value of a digital service may increase with the number of users.

Therefore:

More users → greater value → more users → stronger network effects

A dominant undertaking may then have an incentive to prevent competitors from accessing its network.

Interoperability reduces this feedback loop.

6. Interoperability-by-Design and Privacy

Competition law cannot treat interoperability as an absolute obligation.

Technical interoperability may create:

• privacy risks;
• cybersecurity vulnerabilities;
• unauthorised data disclosure;
• identity fraud;
• data leakage;
• malicious third-party access.

Therefore, an interoperability obligation must generally be accompanied by safeguards concerning:

• authentication;
• encryption;
• consent;
• data minimisation;
• access controls;
• cybersecurity;
• auditability;
• liability allocation.

The objective should be competitive interoperability, not indiscriminate technical openness.

7. Interoperability-by-Design and Data Portability

Data portability and interoperability are closely connected but not identical.

Data portability

The user can transfer data from Platform A to Platform B.

Interoperability

Platform A and Platform B can continuously interact or communicate.

For example:

Downloading contacts from Platform A and uploading them into Platform B = portability.

Whereas:

A user on Platform A communicating directly with a user on Platform B = interoperability.

Competition authorities increasingly consider both mechanisms when analysing switching costs.

8. Interoperability-by-Design and APIs

APIs are one of the principal technical mechanisms through which interoperability is achieved.

A dominant platform can potentially use API control to:

• exclude competitors;
• impose discriminatory conditions;
• delay access;
• restrict functionality;
• provide superior access to its own affiliated services;
• impose unreasonable technical requirements.

Competition concerns therefore arise where API access is commercially or technically indispensable.

A regulator may require:

• documented APIs;
• reasonable access terms;
• technical documentation;
• non-discriminatory access;
• functional parity;
• reasonable response times;
• monitoring mechanisms.

9. Important Case Laws

1. Microsoft Corp. v Commission — General Court, European Union

Case: Microsoft Corp. v Commission, Case T-201/04.

This is one of the most important cases concerning interoperability and competition law.

Microsoft's Windows operating system possessed substantial market power. The European Commission found that Microsoft had restricted disclosure of interoperability information necessary for competing work-group server operating systems.

The European courts upheld the essential aspects of the Commission's approach.

Competition principle

A dominant undertaking controlling an important technological interface may, in appropriate circumstances, be required to provide interoperability information where refusal substantially restricts competition.

Importance for interoperability-by-design

The case demonstrates that technical architecture can become a competition-law issue when incompatibility protects a dominant position.

2. IMS Health v NDC Health — Court of Justice of the European Union

Case: IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG, Joined Cases C-418/01.

The dispute concerned access to a particular data structure used within the pharmaceutical-sales information market.

The Court established demanding conditions for compulsory access under the refusal-to-supply doctrine.

Key principle

Compulsory access to intellectual property requires particularly strong justification, including circumstances where refusal would:

• eliminate effective competition;
• prevent the emergence of a new product or service; and
• lack objective justification.

Relevance

Interoperability-by-design cannot automatically convert every proprietary interface into an obligation to share.

The competition authority must carefully establish the circumstances justifying intervention.

3. Bronner v Mediaprint — Court of Justice of the European Union

Case: Oscar Bronner GmbH & Co. KG v Mediaprint Zeitungs und Zeitschriftenverlag GmbH & Co. KG, Case C-7/97.

The Court considered whether a dominant newspaper distributor had to provide access to its newspaper-delivery system.

The Court applied a strict approach to compulsory access.

Principle

A facility must generally be indispensable rather than merely advantageous, and refusal must have sufficiently serious exclusionary consequences.

Relevance

The case establishes an important limitation on interoperability obligations.

Competition law should not normally require a dominant undertaking to redesign its business merely because competitors would benefit from access.

4. Slovak Telekom v Commission

Cases: Joined Cases C-165/19 P and C-166/19 P.

The litigation concerned access to telecommunications infrastructure and the circumstances in which refusal or restriction of access could constitute an abuse of dominance.

The Court addressed the relationship between general abuse-of-dominance principles and the more restrictive conditions associated with refusal-to-supply cases.

Relevance

The case is important for regulated network industries because interoperability frequently involves infrastructure controlled by a dominant undertaking.

It demonstrates the importance of distinguishing between:

• voluntary commercial access;
• regulated access;
• infrastructure obligations; and
• exclusionary conduct.

5. Google Android — European Commission

The European Commission's Android decision concerned Google's contractual and technical practices involving the Android ecosystem.

The Commission examined practices involving:

• Google Search;
• Google Play;
• Android devices;
• licensing arrangements; and
• restrictions affecting competing services.

Competition significance

The case illustrates how control over an operating-system ecosystem can be leveraged into adjacent markets.

Interoperability relevance

Operating-system design and contractual restrictions can affect whether competing applications and services can effectively reach consumers.

The broader lesson is that ecosystem architecture itself may influence market contestability.

6. Google Shopping — European Commission

The Google Shopping proceedings concerned Google's treatment of competing comparison-shopping services in its search ecosystem.

The central competition issue involved the relationship between Google's dominant search infrastructure and its treatment of competing specialised services.

Relevance to interoperability

Although not a classic interoperability case, it is important for understanding platform access and ecosystem discrimination.

A platform controlling a critical gateway can potentially disadvantage competing services through:

• preferential technical treatment;
• discriminatory ranking;
• access restrictions;
• preferential integration.

This provides a conceptual bridge between interoperability and platform neutrality.

7. Android Auto — Google / European Commission

The European Commission investigated Google's refusal to provide interoperability for certain applications with Android Auto.

The case concerned whether Google's restrictions on the ability of competing applications to interact with the Android Auto environment could restrict competition.

Google ultimately made commitments concerning interoperability.

Importance

This is particularly significant because it illustrates a modern digital-market form of interoperability:

Dominant platform ecosystem → third-party application → technical compatibility → consumer access.

The case demonstrates that interoperability can concern functionality and application access, rather than merely physical infrastructure.

8. Facebook / WhatsApp Interoperability Issues

Competition authorities and regulators have examined interoperability and data-access issues involving large social-networking ecosystems.

The significance lies in the possibility that a large platform can make its network difficult for competitors to challenge because:

• users cannot easily migrate;
• contacts are difficult to transfer;
• communication networks are closed;
• switching costs are high.

These concerns have contributed to the broader regulatory movement toward greater interoperability in digital markets.

10. Interoperability-by-Design and Digital Gatekeepers

Modern digital competition regulation increasingly moves from:

"Prove an abuse after it happens"

toward:

"Prevent certain gatekeepers from designing ecosystems in ways that structurally prevent competition."

The European Union's Digital Markets Act is particularly relevant.

Its framework addresses interoperability in several contexts involving designated gatekeepers and core platform services.

The underlying policy logic is:

Persistent gatekeeper power + strong network effects + technical lock-in

may justify predetermined obligations rather than relying exclusively upon lengthy abuse-of-dominance investigations.

11. Types of Interoperability Obligations

A competition regulator can potentially impose several forms of obligation.

1. API interoperability

The undertaking must provide access to specified technical interfaces.

2. Protocol interoperability

The platform must support recognised communication protocols.

3. Functional interoperability

Third-party products must be capable of interacting with core platform functionality.

4. Data interoperability

Users must be able to transfer relevant information.

5. Identity interoperability

Users should be able to use compatible authentication mechanisms.

6. Payment interoperability

Platforms may be required to permit compatible payment mechanisms.

7. Messaging interoperability

Users of competing communication services may communicate across networks.

8. Hardware interoperability

Proprietary software should not unnecessarily prevent competing hardware from functioning with the platform.

12. Interoperability-by-Design vs Interoperability-by-Remedy

13. Possible Competition Benefits

Interoperability can produce several competitive effects.

A. Lower switching costs

Consumers can change providers without losing access to important networks.

B. Greater multi-homing

Users can use multiple platforms simultaneously.

C. Increased entry

New competitors do not necessarily need to recreate the incumbent's entire ecosystem.

D. Reduced network-effect barriers

Entrants can access existing networks.

E. Greater innovation

Competing firms can develop complementary products.

F. Reduced ecosystem dependence

Businesses and consumers become less dependent upon a single technological ecosystem.

14. Potential Risks of Excessive Interoperability

Interoperability is not automatically pro-competitive in every circumstance.

1. Free-riding

Competitors may benefit from investments made by the dominant firm.

2. Reduced innovation incentives

If firms know that successful innovations must immediately be opened to competitors, investment incentives could be affected.

3. Cybersecurity risks

Opening technical interfaces creates additional attack surfaces.

4. Privacy concerns

Interoperability may require data exchange.

5. Quality degradation

Poorly integrated third-party services may reduce the quality of the ecosystem.

6. Standardisation risks

A mandated technical standard may become outdated.

7. Strategic interoperability

Competitors could exploit interoperability for purposes unrelated to legitimate competition.

15. Objective Justifications

A dominant undertaking may argue that restricting interoperability is objectively necessary because of:

• cybersecurity;
• privacy;
• intellectual-property protection;
• system integrity;
• technical limitations;
• consumer safety;
• fraud prevention;
• reliability;
• protection against malicious software.

Competition authorities therefore need to distinguish between:

legitimate technical protection

and

pretextual technical restrictions designed to exclude competitors.

16. Competition-Law Test for Interoperability-by-Design

A useful analytical framework is:

Step 1 — Define the relevant market

Identify:

• product market;
• geographic market;
• ecosystem;
• complementary markets.

Step 2 — Determine market power

Consider:

• market shares;
• network effects;
• switching costs;
• entry barriers;
• user dependence;
• control of data;
• technological advantages.

Step 3 — Identify the interoperability bottleneck

Determine what is controlled by the undertaking:

API / protocol / data / operating system / identity system / infrastructure.

Step 4 — Examine technical exclusion

Ask whether the design:

• blocks competitors;
• degrades interoperability;
• discriminates against rivals;
• increases switching costs;
• prevents multi-homing.

Step 5 — Assess competitive effects

Examine:

• foreclosure;
• innovation;
• prices;
• quality;
• consumer choice;
• entry;
• market contestability.

Step 6 — Consider objective justification

Examine legitimate:

• privacy;
• cybersecurity;
• technical integrity;
• safety;
• intellectual-property concerns.

Step 7 — Design a proportionate remedy

The remedy should specify:

• scope;
• technical standards;
• access conditions;
• security requirements;
• monitoring;
• dispute resolution.

17. Relationship with Standard-Setting

Interoperability often depends on standards.

A standard-setting organisation can promote competition by creating common technical rules.

However, standards can also become instruments of exclusion.

Competition concerns may arise through:

• exclusion of rivals from standard-setting;
• discriminatory licensing;
• refusal to disclose specifications;
• manipulation of technical standards;
• excessive licensing charges;
• discriminatory implementation.

Thus:

Standardisation + interoperability = potentially greater competition

but:

Standardisation + exclusionary control = potential competition concern.

18. Interoperability and Self-Preferencing

A dominant platform may technically permit interoperability while providing its own products with superior access.

For example:

• its own application receives full API functionality;
• rival applications receive limited functionality;
• the platform delays rival API requests;
• its own service receives privileged data access.

Therefore, interoperability-by-design should sometimes incorporate functional equivalence rather than merely nominal access.

19. Remedies

Competition authorities may consider:

Structural measures

• separation of platform functions;
• divestiture in exceptional circumstances.

Behavioural measures

• mandatory API access;
• non-discrimination;
• technical documentation;
• data portability;
• protocol compatibility;
• interoperability testing.

Monitoring

• independent monitoring trustee;
• technical audits;
• compliance reports;
• API-performance monitoring;
• complaints mechanisms.

Governance

• transparent access conditions;
• objective eligibility criteria;
• reasonable security standards;
• dispute-resolution procedures.

20. Six Core Case-Law Principles at a Glance

21. Key Legal Principles Emerging from the Case Law

The principal lessons are:

1. Dominance alone does not automatically create an obligation to interoperate.
2. Technical incompatibility can constitute an exclusionary mechanism.
3. Indispensability remains important in traditional refusal-to-supply cases.
4. Digital ecosystems can create special interoperability concerns because of network effects.
5. API and technical-interface control can become a source of market power.
6. Interoperability remedies must be proportionate.
7. Security and privacy can constitute legitimate considerations.
8. Interoperability should not become a disguised requirement to surrender all intellectual property.
9. Functional interoperability may be more important than merely formal access.
10. Ex-ante digital regulation increasingly supplements traditional ex-post competition enforcement.

22. Conclusion

Interoperability-by-design represents a significant evolution in competition policy for digital and networked markets. Traditional competition law frequently responds to exclusion after it occurs. Interoperability-by-design attempts to prevent technological architecture itself from becoming an instrument of exclusion.

The principal competition concern is not simply whether a platform is technically closed. The crucial questions are whether the undertaking possesses substantial market power, whether interoperability is competitively important, whether technical restrictions foreclose rivals or increase lock-in, whether the restriction has legitimate justification, and whether an interoperability obligation is proportionate.

The case law—from Microsoft and IMS Health to Bronner, Slovak Telekom, Android-related proceedings and modern platform-interoperability cases—shows a continuing tension between two objectives:

preserving incentives to innovate and protect legitimate technology investments

and

preventing dominant technological ecosystems from using incompatibility to suppress effective competition.