Competition Law And Public Sector Ecosystem Interoperability .

 

Competition Law and Public Sector Ecosystem Interoperability

1. Introduction

Public-sector ecosystem interoperability refers to the ability of different government-controlled or government-linked systems, infrastructure, databases, platforms, networks and digital services to communicate, exchange data and operate together through common technical or institutional interfaces.

Examples include:

  • interoperability between government payment systems and private payment providers;
  • access to public digital identity infrastructure;
  • interoperability of health, education and social-security databases;
  • access to government-owned telecommunications or transport infrastructure;
  • interoperability of public procurement platforms;
  • open access to electricity grids and transmission networks;
  • interoperability between public APIs and competing private applications;
  • sharing of government-generated datasets;
  • interoperability between public cloud, digital-service and authentication systems.

Competition law becomes relevant when a public authority, state-owned enterprise, concessionaire or publicly controlled infrastructure operator controls an indispensable interface, network, dataset, platform or facility and uses that control to restrict competitors or favour its own downstream activities.

In India, the Competition Act, 2002 particularly makes abuse of dominant position, discriminatory access and exclusionary conduct relevant. The CCI also has mechanisms for coordination with sectoral regulators under Sections 21 and 21A.

2. Meaning of Public-Sector Ecosystem Interoperability

Interoperability has several dimensions.

A. Technical interoperability

Different systems must be technically capable of communicating.

Examples:

  • APIs;
  • common protocols;
  • authentication standards;
  • data formats;
  • identity verification interfaces;
  • payment interfaces.

B. Data interoperability

Systems must permit meaningful exchange of data.

For example, a government health database may need to communicate with hospitals, insurers or authorised healthcare platforms.

C. Functional interoperability

The systems must be capable of performing complementary functions.

For example, a public transport-ticketing system may need to interact with private mobility applications.

D. Institutional interoperability

Different public authorities must coordinate their regulatory and technical frameworks.

This is particularly important where:

  • CCI regulates competition;
  • TRAI regulates telecommunications;
  • RBI regulates payment systems;
  • CERC/SERCs regulate electricity;
  • other sector regulators control infrastructure.

Indian competition scholarship has specifically noted that Sections 21 and 21A provide mechanisms for coordination between CCI and sectoral regulators.

3. Why Interoperability Matters for Competition

A public-sector ecosystem can become a competitive bottleneck where competitors cannot effectively operate without connecting to a government-controlled system.

For example:

Government-controlled platform → mandatory interface → downstream businesses → consumers

If the interface is closed or discriminatory, the public-sector operator can potentially affect downstream competition.

Interoperability can therefore:

  1. reduce switching costs;
  2. facilitate multi-homing;
  3. prevent technological lock-in;
  4. allow new entrants to reach customers;
  5. reduce network effects favouring incumbents;
  6. promote innovation;
  7. prevent discriminatory access;
  8. facilitate portability of data;
  9. reduce duplication of infrastructure; and
  10. improve contestability of markets.

But interoperability should not automatically be imposed merely because access would make competition easier. The strongest competition-law cases generally involve indispensability, dominance, foreclosure effects and lack of objective justification. The European jurisprudence on essential facilities illustrates this distinction.

4. Indian Legal Framework

A. Section 4 — Abuse of Dominant Position

Section 4 of the Competition Act is particularly relevant where a public-sector entity or concessionaire possesses substantial market power.

Potentially problematic conduct includes:

  • denial of access;
  • discriminatory access;
  • unreasonable access conditions;
  • discriminatory pricing;
  • restricting technical information;
  • tying access to unrelated services;
  • self-preferencing;
  • degradation of interoperability;
  • refusal to provide necessary APIs;
  • discriminatory data access.

The key question is not simply whether the entity is government-owned.

Government ownership does not automatically establish dominance, and public ownership does not automatically exempt conduct from competition scrutiny.

B. Section 3 — Anti-competitive Agreements

Interoperability problems may also arise through agreements.

Examples include agreements between:

  • public-sector entities;
  • public authorities and private contractors;
  • concessionaires;
  • technology suppliers;
  • infrastructure operators.

Potential issues include:

  • market allocation;
  • exclusive dealing;
  • discriminatory interoperability standards;
  • restrictions on technology suppliers;
  • coordinated refusal to provide access;
  • standard-setting arrangements that exclude competitors.

C. Sections 21 and 21A — Competition-Regulatory Coordination

Public-sector interoperability frequently crosses regulatory boundaries.

For example:

CCI + sector regulator + public infrastructure operator

may all have different statutory responsibilities.

This creates the possibility of:

  • inconsistent regulatory decisions;
  • jurisdictional overlap;
  • regulatory gaps;
  • delayed access remedies.

The Indian framework provides formal mechanisms for references between CCI and sector regulators, although academic analysis has observed that these coordination mechanisms have historically been underused.

5. Essential Facilities Doctrine

The Essential Facilities Doctrine (EFD) is particularly relevant.

The basic competition concern is:

If a dominant undertaking controls a facility that competitors cannot realistically reproduce and that is necessary for competition downstream, can the controller lawfully deny access?

Traditional factors include:

  1. control by a dominant undertaking;
  2. inability of competitors realistically to duplicate the facility;
  3. necessity of access for effective competition;
  4. technical and economic feasibility of access;
  5. absence of objective justification.

Indian competition jurisprudence has considered essential-facility concepts in infrastructure, telecommunications, airport and other contexts, although the precise contours of a general EFD under Indian law remain fact-dependent.

6. Major Case Laws

1. United States v. Terminal Railroad Association of St. Louis, 224 U.S. 383 (1912)

Facts

A railroad association controlled the terminal facilities through which rail traffic had to pass in St. Louis.

Competitors were effectively unable to compete without access to the terminal system.

Principle

The Supreme Court addressed discriminatory exclusion from an infrastructure bottleneck and required arrangements that would permit meaningful competitive access.

Interoperability relevance

The case provides an early foundation for thinking about network bottlenecks.

Modern public-sector equivalents could include:

  • railway networks;
  • ports;
  • airports;
  • electricity grids;
  • public telecommunications infrastructure.

The broader lesson is that control over a critical network can create competition concerns when exclusion prevents meaningful downstream rivalry.

7. Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985)

Facts

Aspen Skiing operated several ski mountains and had historically participated in a joint ticketing arrangement with a smaller competitor.

The dominant operator eventually withdrew from the arrangement.

Principle

The U.S. Supreme Court treated the termination of cooperation, under the particular circumstances, as potentially exclusionary conduct.

Interoperability relevance

The case is important for understanding withdrawal from interoperability.

A public-sector ecosystem may raise similar questions where an incumbent:

  • previously provided interoperability;
  • suddenly withdraws access;
  • has no obvious efficiency explanation;
  • thereby makes downstream competition materially more difficult.

However, Aspen Skiing is highly fact-specific and does not create a general obligation for every dominant undertaking to cooperate with rivals.

8. MCI Communications Corp. v. AT&T, 708 F.2d 1081 (7th Cir. 1983)

Facts

The dispute concerned access to AT&T's telecommunications network.

Principle

The Seventh Circuit discussed circumstances in which a dominant network operator's refusal to provide access could constitute anticompetitive conduct.

Interoperability significance

The case is especially relevant to public-sector ecosystems because telecommunications networks are classic examples of network infrastructure with interoperability requirements.

It illustrates why access to:

  • communications networks;
  • technical interfaces;
  • network facilities;
  • interconnection arrangements

can become competition-law issues.

9. Oscar Bronner GmbH & Co. KG v. Mediaprint, Case C-7/97

Facts

Bronner sought access to Mediaprint's newspaper-delivery system.

The European Court considered whether the dominant undertaking was required to give a rival access to its infrastructure.

Principle

The Court adopted a demanding approach to compulsory access.

The facility generally needed to be indispensable, meaning that there was no realistic alternative and duplication was not reasonably possible.

Interoperability significance

Bronner is one of the central cases for determining when competition law should transform a private or controlled infrastructure into an access obligation.

For public-sector systems, it suggests that:

Mere usefulness is insufficient; the competitive importance and indispensability of the interface must be established.

The case remains an important reference point in the essential-facilities analysis.

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

Facts

IMS Health controlled a copyrighted pharmaceutical-sales data structure.

A competitor required access to the structure to compete effectively.

Principle

The Court developed the exceptional-circumstances framework for compulsory licensing/access involving intellectual property.

Relevant considerations included:

  • indispensability;
  • elimination of effective competition;
  • prevention of the emergence of a new product;
  • absence of objective justification.

Public-sector interoperability relevance

The case is particularly useful where government ecosystems contain:

  • proprietary databases;
  • protected software;
  • copyrighted interfaces;
  • specialised data structures;
  • technical standards.

It demonstrates the tension between interoperability and intellectual-property protection.

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

Facts

Microsoft controlled the Windows operating-system environment and was found to have withheld interoperability information necessary for rival work-group server operating systems.

Decision

The European Commission and General Court treated Microsoft's refusal to provide interoperability information as abusive in the circumstances.

Importance

This is arguably one of the most directly relevant cases to modern ecosystem interoperability.

The case concerned:

interoperability information → rival products → downstream competition

The Microsoft decision demonstrated that competition law may address not merely physical infrastructure but also technical information necessary for interoperability.

Public-sector application

Comparable questions can arise where a public-sector platform controls:

  • APIs;
  • protocols;
  • authentication systems;
  • data schemas;
  • interoperability specifications.

12. Arshiya Rail Infrastructure Ltd. v. Ministry of Railways / Container Corporation of India

Facts

Private container-train operators complained about access to railway-related terminal infrastructure controlled by public-sector entities.

Competition issue

The dispute raised the question whether particular railway terminals constituted essential facilities for competing container operators.

Significance

The CCI considered factors including:

  • whether access was technically possible;
  • whether competitors could construct alternative facilities;
  • whether denial would substantially harm competition;
  • whether access could be provided on reasonable terms.

The case is particularly significant for public-sector infrastructure competition because it illustrates that government-linked infrastructure can become the focus of an essential-facilities analysis.

13. Shamsher Kataria v. Honda Siel Cars India Ltd. & Ors.

Although this was not a public-sector case, it provides an important Indian illustration of access and interoperability-type concerns.

Facts

The case concerned access to:

  • spare parts;
  • diagnostic equipment;
  • technical information;
  • repair-related resources.

Independent repairers argued that restrictions imposed by automobile manufacturers disadvantaged them.

Competition relevance

The CCI's analysis addressed the competitive significance of access to proprietary technical inputs.

Public-sector analogy

The reasoning can be extended conceptually to public digital ecosystems where downstream competitors require:

  • technical specifications;
  • diagnostic interfaces;
  • APIs;
  • data;
  • authentication access.

The case therefore demonstrates how competition law can examine technical bottlenecks rather than merely physical infrastructure.

14. Competition Issues in Public-Sector Ecosystem Interoperability

A. Refusal to Interoperate

A public platform may refuse to permit private competitors to connect.

Example:

Public identity platform → refuses API access → private authentication providers cannot compete.

Competition questions:

  • Is the platform dominant?
  • Is access indispensable?
  • Can an alternative reasonably be developed?
  • Does refusal eliminate or substantially restrict competition?
  • Is there an objective justification?

B. Discriminatory Interoperability

A public operator may provide:

  • high-quality API access to its affiliate;
  • slower access to rivals;
  • incomplete data to competitors;
  • preferential technical support to its own subsidiary.

This may produce input foreclosure.

C. Self-Preferencing

Suppose a state-controlled digital marketplace permits third-party suppliers but gives its own commercial subsidiary:

  • privileged API access;
  • early data access;
  • superior search visibility;
  • preferential integration.

The competition concern is not government ownership itself but the possibility that control of the platform is being used to advantage an affiliated downstream undertaking.

15. Data Portability and Interoperability

Public-sector ecosystems increasingly depend upon large datasets.

Examples include:

  • health records;
  • transportation data;
  • business registrations;
  • land records;
  • educational records;
  • public procurement information;
  • payment information;
  • energy consumption information.

Where competitors cannot obtain interoperable access to data that is indispensable to competing, competition concerns may arise.

However, unrestricted access can conflict with:

  • privacy;
  • cybersecurity;
  • national security;
  • confidentiality;
  • intellectual property;
  • data-protection legislation.

Therefore, competition law should normally be combined with data governance and sector-specific regulation.

16. APIs as Competitive Infrastructure

APIs can function as modern interfaces equivalent to physical infrastructure.

For example:

Public platform

↓

API

↓

Private applications

↓

Consumers

If the public platform controls the API, it may potentially control access to the downstream ecosystem.

Competition problems can arise through:

  • API refusal;
  • discriminatory API access;
  • excessive fees;
  • rate limiting;
  • delayed technical documentation;
  • selective technical changes;
  • incompatible formats;
  • arbitrary certification requirements.

The Microsoft case is particularly useful by analogy because interoperability information itself was treated as competitively significant.

17. Network Effects

Public-sector digital ecosystems may experience powerful network effects.

For example:

More users
↓
More data
↓
Better services
↓
More users
↓
Greater ecosystem dominance

Interoperability can interrupt this feedback loop by allowing competitors to participate in the ecosystem without reproducing the entire network.

This is especially important for:

  • digital identity;
  • payment systems;
  • public marketplaces;
  • mobility platforms;
  • healthcare platforms;
  • government cloud systems.

18. Switching Costs and Lock-In

Closed public ecosystems may create:

  • technical lock-in;
  • contractual lock-in;
  • data lock-in;
  • authentication lock-in;
  • software lock-in.

A competitor may technically exist but be unable to attract customers because customers cannot transfer their information or maintain interoperability.

Competition authorities therefore increasingly examine contestability, not simply the number of competitors.

19. Public Procurement and Interoperability

Interoperability should ideally be addressed at the procurement stage.

Public procurement contracts can include:

  • open API requirements;
  • data portability;
  • common standards;
  • interoperability testing;
  • non-discriminatory access;
  • source-code escrow where appropriate;
  • technical documentation;
  • exit and migration rights;
  • vendor-neutral data formats.

Otherwise, a government may inadvertently create a private technological bottleneck that later becomes a competition problem.

20. Standard-Setting and Interoperability

Public authorities often establish technical standards.

Standards can promote competition by making systems interoperable.

But standards can also create exclusion if:

  • a particular technology is unnecessarily mandated;
  • competing suppliers cannot participate;
  • proprietary technology becomes compulsory;
  • standards are manipulated to exclude rivals.

Thus:

Open standard → interoperability → lower entry barriers

whereas:

closed/proprietary standard → lock-in → potential foreclosure

21. Public Enterprises and Vertical Foreclosure

A public-sector enterprise may operate at both:

Upstream level

and

Downstream level.

For example:

Government-owned electricity network
↓
transmission access
↓
electricity suppliers

If the network operator also supplies electricity, it could theoretically have an incentive to disadvantage competing suppliers through:

  • delayed connection;
  • inferior technical access;
  • discriminatory charges;
  • preferential network capacity;
  • incompatible technical standards.

This is a classic vertical foreclosure concern.

22. Objective Justification

Not every refusal or restriction is anticompetitive.

A public-sector entity may legitimately restrict interoperability for:

Cybersecurity

Opening an interface could create serious security vulnerabilities.

Privacy

Sensitive personal data may not lawfully be shared.

Technical integrity

Unlimited access could compromise the stability of a critical infrastructure network.

Capacity constraints

Infrastructure may have finite technical capacity.

National security

Certain government systems may legitimately require restricted access.

Intellectual property

Interoperability may require disclosure of protected technical information.

Cost recovery

Reasonable access charges may be justified.

The central competition question is whether the restriction is necessary and proportionate to a legitimate objective, rather than simply protecting the incumbent from competition.

23. Remedies

Competition authorities may consider several remedies.

A. Access remedy

Require access to the relevant infrastructure.

B. Interoperability obligation

Require the dominant operator to provide technical interfaces.

C. Non-discrimination

Require equivalent treatment of:

  • competitors;
  • affiliates;
  • independent providers.

D. Data portability

Require data to be transferred in interoperable formats.

E. API access

Require access to specified APIs.

F. Transparency

Require publication of:

  • technical standards;
  • access conditions;
  • pricing;
  • eligibility criteria.

G. Functional separation

Separate infrastructure operation from downstream commercial activities.

H. Structural separation

In extreme cases, separate ownership or control may be considered under applicable regulatory and competition frameworks.

24. Public-Sector Interoperability: Analytical Test

A useful competition-law framework is:

Step 1 — Identify the ecosystem

What platform, network, database or infrastructure is involved?

Step 2 — Define the relevant market

Identify the upstream and downstream markets.

Step 3 — Determine control

Who controls the interoperability interface?

Step 4 — Examine dominance

Does the entity possess substantial market power?

Step 5 — Examine indispensability

Can competitors realistically reproduce or substitute the facility?

Step 6 — Examine conduct

Is there:

  • refusal;
  • discrimination;
  • degradation;
  • excessive access pricing;
  • self-preferencing;
  • tying;
  • exclusionary standard-setting?

Step 7 — Examine competitive effects

Does the conduct:

  • foreclose competitors;
  • raise entry barriers;
  • increase switching costs;
  • reduce innovation;
  • protect an affiliated downstream business?

Step 8 — Examine justification

Are privacy, security, capacity, intellectual-property or other legitimate considerations involved?

Step 9 — Design proportionate remedy

Possible remedies include:

Access → interoperability → non-discrimination → portability → transparency → structural remedy where necessary.

25. Relationship Between Essential Facilities and Interoperability

Essential Facilities ConceptInteroperability Application
Physical facilityDigital platform/API
Railway networkPublic digital network
Airport infrastructureGovernment service platform
Telecom networkGovernment communications infrastructure
Data facilityPublic database
Access rightAPI/interoperability access
Non-discriminationEqual technical treatment
Duplication analysisAbility to build competing infrastructure
Refusal to dealRefusal to interoperate
Downstream foreclosureExclusion of competing applications

Thus, interoperability can be understood as a modern expression of access and essential-facility problems, although not every interoperability dispute satisfies the strict conditions for compulsory access.

26. Key Principles from the Six-Plus Cases

CaseCore PrinciplePublic-Sector Relevance
Terminal RailroadAccess to critical network infrastructureRailways, ports, public infrastructure
Aspen SkiingWithdrawal from established cooperation can raise exclusion concernsWithdrawal of interoperability
MCI v AT&TNetwork access can be competitively significantTelecommunications
BronnerCompulsory access requires stringent conditionsPublic infrastructure/API access
IMS HealthExceptional circumstances can justify access to protected structuresData/IP interoperability
MicrosoftInteroperability information can be competitively criticalAPIs, protocols, digital government
Arshiya Rail InfrastructureIndian essential-facility analysis in public railway infrastructureState/public infrastructure
Shamsher KatariaAccess to technical inputs can affect downstream competitionTechnical interfaces and repair ecosystems

27. Conclusion

Public-sector ecosystem interoperability is increasingly a competition-law issue because control over a public network, database, API, platform or technical standard can create a bottleneck between competitors and consumers.

The central competition-law concern is not simply that a government entity owns infrastructure. The critical questions are:

  1. Who controls the bottleneck?
  2. Is the controller dominant?
  3. Is interoperability indispensable or merely convenient?
  4. Can competitors realistically replicate the facility?
  5. Is access refused or provided discriminatorily?
  6. Does the conduct foreclose downstream competition?
  7. Is there a legitimate and proportionate justification?
  8. What interoperability remedy would preserve competition without undermining security, privacy or investment incentives?

The progression from Terminal Railroad → MCI → Bronner → IMS Health → Microsoft → Indian infrastructure cases such as Arshiya Rail demonstrates the development of competition-law thinking from physical infrastructure toward technical interfaces, information systems and ecosystem interoperability. The Microsoft jurisprudence is particularly significant because it shows how withholding interoperability information itself can become a competition concern.

LEAVE A COMMENT