Competition Law And Benchmarking Platforms And Collusion Risk

 

Competition Law and Benchmark Interoperability Frameworks

1. Introduction

Interoperability is the ability of different products, services, platforms, networks, software systems, or technical infrastructures to communicate, exchange data, and function together effectively. A benchmark interoperability framework is a structured set of technical, commercial, and governance criteria used to determine whether competing systems can interoperate on sufficiently equivalent and non-discriminatory terms.

Competition law becomes particularly important where interoperability is controlled by a dominant undertaking. A dominant platform may technically permit interoperability while imposing restrictions on APIs, protocols, access conditions, certification, data formats, authentication, functionality, or performance that make competing products materially less effective.

The central competition-law question is therefore:

When does control over interoperability become a means of excluding competitors rather than legitimate protection of technology, security, quality, or innovation?

The issue is especially significant for operating systems, cloud computing, messaging, payment systems, connected devices, digital advertising, AI services, telecommunications and other network industries.

Recent EU developments illustrate the movement from case-by-case refusal-of-access analysis toward more structured interoperability obligations. Under Article 6(7) of the Digital Markets Act (DMA), designated gatekeepers must provide third parties with effective interoperability with relevant hardware and software features of their operating systems.

2. Meaning of a Benchmark Interoperability Framework

A benchmark interoperability framework can be understood as a reference model against which interoperability conditions are measured.

It may contain the following benchmarks:

BenchmarkCompetition-law relevance
Technical compatibilityCan competing systems technically connect?
Functional equivalenceDo third parties receive sufficiently equivalent functionality?
API accessibilityAre APIs available on reasonable terms?
Data portabilityCan users transfer/use relevant data?
Protocol transparencyAre necessary protocols adequately disclosed?
Non-discriminationAre competitors treated differently from the dominant firm's services?
Performance parityDoes third-party access operate at comparable quality/speed?
SecurityAre restrictions genuinely necessary for security?
CertificationAre certification requirements objective and proportionate?
PricingAre access charges excessive or exclusionary?
GovernanceIs access controlled through transparent procedures?
MonitoringCan compliance be independently verified?

The framework therefore converts the broad concept of "interoperability" into measurable competitive conditions.

3. Why Interoperability Matters for Competition

Interoperability can reduce several structural barriers to competition.

A. Network effects

In digital markets, users often prefer the platform with the largest network.

If Platform A has 90% of users and Platform B has 10%, lack of interoperability may make switching costly because users lose access to contacts, data, functionality or complementary services.

B. Switching costs

Interoperability may allow consumers to change providers without abandoning accumulated data, contacts, applications or connected devices.

C. Multi-homing

Interoperability can allow users or business customers to use multiple competing services simultaneously.

D. Entry barriers

A new entrant may have technically superior technology but remain unable to compete if it cannot interact with an established ecosystem.

E. Innovation

Interoperability may allow complementary innovators to build products around a dominant platform.

4. Competition-Law Theories Relevant to Interoperability

4.1 Refusal to Deal

The classic competition-law problem arises when a dominant undertaking refuses access to an infrastructure, interface, protocol or technical information necessary for competition.

However, competition law generally does not impose an automatic obligation on every firm to assist competitors.

The circumstances surrounding the refusal are therefore critical.

4.2 Essential-Facilities Theory

The traditional European approach asks whether access to an infrastructure is sufficiently indispensable and whether refusal eliminates or seriously restricts effective competition.

Important cases include Bronner, Magill, IMS Health, and Microsoft.

The digital economy has complicated this analysis because platforms may voluntarily open their ecosystems to third-party developers while simultaneously controlling the conditions of interoperability.

4.3 Discriminatory Interoperability

A dominant firm may technically provide interoperability but give its own services:

  • earlier API access;
  • better technical documentation;
  • higher data limits;
  • superior functionality;
  • faster processing;
  • privileged authentication;
  • preferential ranking;
  • lower latency; or
  • access to additional device functions.

This can create a competition problem even where there is no absolute refusal.

5. Six Major Case Laws

Case 1 — Microsoft Corp. v Commission

Case T-201/04, General Court, 17 September 2007

This is one of the most important European interoperability decisions.

Microsoft was found to have abused its dominant position through its refusal to provide competitors with interoperability information necessary for competing work-group server operating systems.

The General Court upheld the Commission's finding concerning Microsoft's refusal to supply interoperability information.

Principle

Interoperability information can constitute an important competitive input where competitors require it to make their products effectively compatible with a dominant platform.

The remedy did not require Microsoft to disclose its entire source code. The relevant information concerned technical specifications necessary for interoperability.

Benchmark implication

A proper interoperability framework should therefore distinguish between:

  1. legitimate protection of proprietary technology; and
  2. disclosure of technical information genuinely necessary for effective interoperability.

Case 2 — Microsoft Corp. v Commission

Case T-167/08, General Court, 27 June 2012

This later Microsoft litigation concerned compliance with the interoperability remedy and the Commission's use of periodic penalty payments.

The Court described the underlying infringement as Microsoft's refusal to supply competitors with interoperability information and authorise its use for developing competing products.

Principle

An interoperability obligation must be effective in practice, rather than merely formal.

A dominant company cannot necessarily satisfy a competition remedy simply by providing information that is technically available but insufficiently complete, accurate or usable.

Benchmark implication

An interoperability benchmark should therefore measure actual usability, not merely whether documentation has been technically supplied.

Case 3 — IMS Health GmbH & Co. OHG v NDC Health GmbH

Case C-418/01, CJEU, 29 April 2004

IMS Health concerned the refusal to license a protected system used for pharmaceutical sales-data analysis.

The Court developed the restrictive conditions under which refusal to license an intellectual-property right could constitute abuse.

Principle

Competition law does not normally require a dominant undertaking to license intellectual property to competitors.

Exceptional intervention requires circumstances such as:

  • indispensability;
  • elimination of effective competition;
  • absence of objective justification; and
  • circumstances involving a new product or comparable competitive requirement.

Benchmark implication

An interoperability framework must avoid treating every proprietary interface or technical standard as automatically subject to compulsory access.

There must be a principled distinction between legitimate intellectual-property protection and exclusionary conduct.

6. Case 4 — Bronner v Mediaprint

Case C-7/97, CJEU, 26 November 1998

The case concerned access to a newspaper home-delivery system.

The Court adopted a demanding approach to compulsory access.

Principle

An infrastructure will not become an obligatory facility merely because access would make competition easier.

The relevant infrastructure must generally be indispensable for competition and not reasonably replicable.

Importance for interoperability

Bronner establishes an important baseline:

Competition law should not automatically transform every commercially useful interoperability arrangement into a mandatory access obligation.

Benchmark implication

A benchmark framework should therefore include an indispensability test.

Possible questions include:

  1. Can the entrant develop an alternative interface?
  2. Can consumers reasonably switch?
  3. Is the infrastructure technically reproducible?
  4. Is there a commercially viable alternative?
  5. Does denial actually eliminate effective competition?

7. Case 5 — Magill

Joined Cases C-241/91 P and C-242/91 P

The Magill litigation concerned refusal to license copyrighted television programme information.

The case is important because it helped establish the exceptional circumstances in which refusal to license intellectual property may constitute an abuse.

Principle

Competition law can intervene where intellectual-property control is used in exceptional circumstances to prevent the emergence of competing products and eliminate effective competition.

Interoperability significance

Although Magill was not a modern API case, its logic is relevant where proprietary technical standards or information are used to prevent competitors from developing interoperable products.

Benchmark implication

The framework should assess whether:

  • the information is genuinely indispensable;
  • competitors can develop alternative technical solutions;
  • access would enable a new or materially improved competitive offering;
  • refusal excludes effective competition; and
  • objective justification exists.

8. Case 6 — Alphabet and Others v European Commission / Android Auto

Case C-233/23, CJEU, 25 February 2025

This is particularly important for modern digital interoperability.

The dispute concerned Google's Android Auto platform and whether Google could refuse interoperability to third-party applications.

The CJEU's judgment clarified that the traditional Bronner criteria do not necessarily apply mechanically where a digital platform has been designed to accommodate third-party applications and the issue concerns interoperability with that platform.

Importance

This represents a significant development in digital-platform competition law.

The legal analysis can be different where:

  • the platform is already designed for third-party participation;
  • interoperability is technically contemplated by the platform;
  • the platform has established procedures for third-party access; and
  • the dispute concerns the conditions under which third parties can obtain interoperability.

Benchmark implication

A modern framework should distinguish between:

closed infrastructure
and
platforms already designed as ecosystems for third-party participation.

That distinction can materially affect the competition-law analysis.

9. Additional Relevant Case — Slovak Telekom

Slovak Telekom a.s. v European Commission, Joined Cases C-152/19 P and C-165/19 P

This litigation concerned access to telecommunications infrastructure and exclusionary conditions imposed by a dominant undertaking.

The case is relevant to interoperability frameworks because it demonstrates that access conditions can become exclusionary where a dominant infrastructure operator controls the ability of competitors to reach customers.

Framework lesson

Interoperability assessment should examine not only whether access exists, but also:

  • technical conditions;
  • contractual conditions;
  • pricing;
  • quality;
  • network architecture; and
  • practical ability of competitors to use the access.

10. From Refusal of Access to Interoperability Benchmarks

Traditional competition law often asks:

"Was access refused?"

Modern digital competition analysis increasingly asks:

"Was interoperability sufficiently effective to permit meaningful competition?"

This is a major conceptual shift.

For example, interoperability may formally exist but nevertheless be ineffective because the dominant undertaking:

  • restricts API functionality;
  • delays approval;
  • imposes excessive certification requirements;
  • limits data fields;
  • reduces third-party performance;
  • prevents access to important device functions;
  • changes technical specifications without adequate notice; or
  • gives its own competing service superior access.

Therefore:

Formal interoperability ≠ effective interoperability.

11. Benchmark Interoperability Matrix

A competition authority or regulator could use the following framework:

BenchmarkQuestion
AvailabilityIs interoperability technically available?
AccessibilityCan competitors actually obtain access?
FunctionalityDoes access provide meaningful functionality?
PerformanceIs third-party performance materially degraded?
EqualityDoes the dominant firm receive preferential treatment?
TransparencyAre technical requirements sufficiently clear?
TimelinessAre access requests handled within reasonable periods?
CostAre charges reasonable and non-exclusionary?
SecurityAre restrictions genuinely required for security?
DataCan relevant data be transferred or accessed?
PortabilityCan users move between competing services?
GovernanceIs there independent oversight?
RemedyCan disputes be resolved quickly?

12. Interoperability and Non-Discrimination

One of the strongest benchmarks is non-discriminatory access.

Suppose a dominant operating-system provider gives:

  • its own AI assistant access to 15 device functions;
  • competing AI assistants access to 5 functions.

Even if competitors technically have interoperability, the competitive conditions may not be equivalent.

This is particularly relevant under the EU's DMA framework. Article 6(7) requires designated gatekeepers to allow third parties access to the same relevant OS hardware and software features available to gatekeeper services or hardware, subject to justified and proportionate protections for system integrity.

In July 2026, the European Commission adopted binding specification measures concerning Google's Android interoperability for AI services. The measures concern access by competing AI services to Android capabilities.

13. Interoperability and APIs

APIs are particularly important because they define how external services communicate with a platform.

Competition concerns may arise where a dominant undertaking:

  1. provides its own services with unrestricted API access;
  2. restricts competitors;
  3. changes APIs selectively;
  4. imposes discriminatory rate limits;
  5. requires burdensome certification;
  6. withholds essential documentation; or
  7. prevents third-party access to commercially important functionality.

A benchmark framework should therefore examine API parity, not merely API existence.

14. Interoperability and Data Portability

Interoperability and portability overlap but are not identical.

Data portability

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

Interoperability

Platform A and Platform B can function together while the user remains connected to both.

For example:

Portability:
User exports contacts from A → imports them into B.

Interoperability:
User on B can communicate with a user on A.

Competition authorities should avoid treating these concepts as interchangeable.

15. Interoperability and Standard-Setting

Industry standards can produce substantial efficiencies.

They can:

  • reduce transaction costs;
  • improve compatibility;
  • reduce duplication;
  • facilitate innovation;
  • increase consumer choice; and
  • allow multiple firms to participate in a technological ecosystem.

But standards can also become anti-competitive when dominant firms use standard-setting processes to:

  • exclude rivals;
  • impose discriminatory technical requirements;
  • prevent competing technologies;
  • manipulate certification;
  • restrict access to essential standards; or
  • coordinate commercially sensitive information.

Consequently, competition law should examine both the standard itself and the governance process through which it is established.

16. Interoperability and FRAND

Where interoperability depends upon patents incorporated into technical standards, FRAND principles may become relevant.

FRAND means:

Fair, Reasonable and Non-Discriminatory.

A competition-law benchmark may therefore consider:

  • royalty levels;
  • licensing transparency;
  • discrimination between licensees;
  • injunction strategies;
  • access to technical specifications; and
  • licensing negotiations.

However, FRAND is not automatically synonymous with competition law. The applicable legal regime depends upon the circumstances and the relevant jurisdiction.

17. Security as a Legitimate Justification

A dominant firm should not necessarily be required to provide unlimited interoperability.

Restrictions may legitimately protect:

  • cybersecurity;
  • privacy;
  • system integrity;
  • fraud prevention;
  • intellectual property;
  • reliability;
  • user safety.

The important competition-law question is whether the restriction is:

  1. genuine;
  2. technically necessary;
  3. proportionate;
  4. objectively justified; and
  5. applied consistently.

The EU's DMA interoperability framework expressly recognises that gatekeepers can take strictly necessary and proportionate measures to protect the integrity of their operating systems, hardware and software.

18. Benchmarking Dominant and Third-Party Access

A useful competition investigation can compare:

Dominant service

  • API access
  • functionality
  • latency
  • data access
  • authentication
  • technical documentation
  • certification

Rival service

  • API access
  • functionality
  • latency
  • data access
  • authentication
  • technical documentation
  • certification

The authority can then identify whether the difference is:

technical → commercial → contractual → discriminatory → exclusionary.

This provides a more objective methodology than simply asking whether interoperability exists.

19. Interoperability Remedies

Competition authorities can potentially use several forms of remedy.

A. Access remedy

Require the dominant undertaking to provide access to necessary interfaces.

B. API remedy

Require equivalent API access.

C. Data remedy

Require data portability or controlled data access.

D. Non-discrimination remedy

Prohibit preferential treatment of the dominant firm's competing service.

E. Transparency remedy

Require technical documentation and advance notice of material changes.

F. Monitoring remedy

Require independent monitoring of compliance.

G. Governance remedy

Create an independent dispute-resolution mechanism for interoperability requests.

20. Indian Competition-Law Perspective

In India, interoperability issues can be analysed principally through Section 4 of the Competition Act, 2002, particularly where a dominant enterprise uses control over a digital ecosystem to impose unfair or discriminatory conditions, deny market access, or leverage dominance into another market.

The CCI's WhatsApp proceedings are relevant because the Commission examined network effects, switching difficulties and restricted interoperability in the OTT messaging market. The Delhi High Court proceedings also discussed how lack or restriction of interoperability could make switching to alternative applications more difficult.

The CCI's 2024 WhatsApp privacy-policy decision further illustrates how control over a major digital ecosystem can produce competition concerns extending beyond traditional price competition. The CCI found WhatsApp dominant in the market for OTT messaging apps through smartphones in India and addressed alleged leveraging into online display advertising.

The later appellate litigation concerning that decision is also significant: the NCLAT's 2025 judgment addressed the CCI's findings under Section 4 concerning unfair/discriminatory conditions and denial of market.

21. Proposed Benchmark Interoperability Framework

A comprehensive competition-law framework can therefore be structured as follows:

Stage 1 — Market definition

Identify:

  • relevant product/service market;
  • geographic market;
  • ecosystem;
  • upstream/downstream markets.

Stage 2 — Market power

Assess:

  • market share;
  • network effects;
  • switching costs;
  • data advantages;
  • entry barriers;
  • ecosystem dependency.

Stage 3 — Interoperability mapping

Identify:

  • APIs;
  • protocols;
  • data formats;
  • authentication;
  • hardware interfaces;
  • software interfaces;
  • certification.

Stage 4 — Benchmark comparison

Compare:

dominant firm's access

against

competitor's access.

Stage 5 — Competitive effect

Determine whether restrictions:

  • foreclose rivals;
  • raise entry costs;
  • reduce innovation;
  • reduce consumer choice;
  • increase switching costs; or
  • protect network effects.

Stage 6 — Objective justification

Examine:

  • security;
  • privacy;
  • system integrity;
  • IP protection;
  • technical necessity;
  • proportionality.

Stage 7 — Remedy

Select the least intrusive remedy capable of restoring effective competition.

22. Key Legal Principles From the Case Law

CaseCentral interoperability lesson
Microsoft v Commission, T-201/04Refusal to provide necessary interoperability information can constitute abuse in exceptional circumstances
Microsoft v Commission, T-167/08Interoperability remedies must be practically effective
IMS Health, C-418/01Compulsory access involving IP requires exceptional circumstances
Bronner, C-7/97Traditional compulsory-access doctrine imposes demanding indispensability conditions
Magill, C-241/91 P & C-242/91 PExceptional refusal-to-license circumstances can justify competition intervention
Android Auto, C-233/23Digital-platform interoperability cannot always be assessed mechanically through the traditional Bronner framework
Slovak Telekom, C-152/19 P & C-165/19 PAccess conditions imposed by dominant infrastructure operators can have exclusionary effects

23. Conclusion

Benchmark interoperability frameworks provide a bridge between abstract competition-law principles and measurable technical conditions.

The development from Bronner → Magill → IMS Health → Microsoft → Android Auto demonstrates an evolution from a highly restrictive compulsory-access doctrine toward a more nuanced analysis of digital ecosystems and platform interoperability.

The central competition-law distinction is between:

legitimate control necessary to protect innovation, security and system integrity

and

strategic control over interoperability that materially prevents effective competition.

For modern digital markets, the relevant benchmark should therefore not simply ask "Is interoperability available?" It should ask whether interoperability is effective, timely, functional, non-discriminatory, technically usable and capable of allowing competitors to compete on meaningful terms.

The EU's current DMA framework illustrates this newer approach particularly clearly: interoperability obligations can be specified in concrete technical terms, including for AI services interacting with dominant operating systems.

LEAVE A COMMENT