Interaction Protocol Control And Ecosystem Lock-In .
Interaction Protocol Control and Ecosystem Lock-In
1. Introduction
Interaction protocol control and ecosystem lock-in describes a competition-law problem in which an undertaking gains substantial market power by controlling the technical, contractual, or governance rules through which other firms, users, devices, applications, or services interact.
The key idea is that modern markets increasingly depend upon protocols and interfaces rather than merely physical products.
Examples include:
APIs;
interoperability protocols;
payment protocols;
communication standards;
operating-system interfaces;
cloud APIs;
identity protocols;
app-store rules;
data-exchange formats;
authentication systems;
machine-to-machine communication protocols.
Control over these interaction mechanisms can produce ecosystem lock-in.
The competitive concern is not simply that users prefer a successful product. It is that:
the dominant undertaking controls the rules necessary for participants to interact, making departure from the ecosystem increasingly costly or technically difficult.
2. Meaning of Interaction Protocol Control
An interaction protocol is a set of technical or institutional rules governing how systems communicate or interact.
A protocol can determine:
who can connect;
what information can be exchanged;
how authentication occurs;
which applications can communicate;
what data format is accepted;
how transactions are validated;
what permissions are available;
how interoperability operates.
The undertaking controlling the protocol can potentially influence the competitive environment surrounding it.
For example:
Operating system → API → applications → users.
If the operating-system owner changes the API, it may affect every application dependent upon it.
3. What Is Ecosystem Lock-In?
Ecosystem lock-in occurs when switching from one technological or commercial ecosystem to another becomes sufficiently costly that users or businesses remain dependent upon the incumbent.
Switching costs may include:
financial costs;
data-transfer costs;
learning costs;
technical incompatibility;
loss of applications;
loss of network connections;
contractual penalties;
loss of accumulated reputation;
loss of interoperability;
loss of historical data.
Lock-in therefore creates a distinction between:
customer preference
and
dependency.
4. Why Protocol Control Creates Competition Concerns
A dominant undertaking controlling a protocol can potentially:
restrict access;
degrade interoperability;
change technical specifications;
discriminate between participants;
favour its own products;
impose licensing conditions;
tie complementary services;
prevent data portability;
exclude rival applications;
increase switching costs.
The central concern is:
Control over interaction rules can become control over market participation itself.
5. Protocol Control as a Bottleneck
Suppose a dominant platform controls an API through which all third-party applications must communicate.
The structure becomes:
Users → Platform → API → Applications
If the platform restricts the API, rival applications may lose access to users.
The API therefore becomes a competitive bottleneck.
This is comparable to infrastructure control.
The difference is that the bottleneck is digital rather than physical.
6. Case Law 1 — United States v. Terminal Railroad Association of St. Louis
224 U.S. 383 (1912)
Terminal Railroad is one of the earliest important authorities concerning control over essential infrastructure.
The defendants controlled terminal facilities necessary for competing railroads to access the St. Louis market.
The Supreme Court considered the exclusionary consequences of that control.
Relevance to protocol control
A digital protocol can function similarly to a physical bottleneck.
For example:
railway terminal → necessary physical access
interaction protocol → necessary digital access.
Where a dominant undertaking controls a genuinely indispensable interaction mechanism, exclusionary access restrictions can potentially raise antitrust concerns.
Principle
Control over a critical bottleneck can create special competition concerns when rivals cannot effectively compete without access.
7. Case Law 2 — MCI Communications Corp. v. AT&T
708 F.2d 1081 (7th Cir. 1983)
MCI v AT&T is a leading U.S. authority concerning access to infrastructure controlled by a dominant undertaking.
The court considered whether AT&T's control over telecommunications infrastructure could be used to exclude a rival.
Relevance
Modern interaction protocols perform a similar function.
Examples include:
telecommunications interfaces;
payment interfaces;
cloud APIs;
authentication protocols;
messaging protocols.
If a dominant firm controls an interface that competitors require to participate, refusal or restriction of access may become an antitrust issue.
8. Case Law 3 — Bronner v Mediaprint
Case C-7/97, CJEU
Bronner is a leading European authority concerning refusal to supply and essential facilities.
The CJEU adopted a restrictive approach to compulsory access.
The facility must generally be indispensable and lack a realistic alternative before an access obligation becomes appropriate.
Relevance to ecosystem lock-in
A competitor cannot simply argue:
"The dominant platform's protocol would make competition easier."
It must demonstrate a much stronger form of dependency.
This protects incentives to develop infrastructure.
Principle
Competition law should not automatically convert successful infrastructure into a compulsory shared resource.
9. Case Law 4 — IMS Health v NDC Health
Joined Cases C-241/91 P and C-242/91 P, CJEU
IMS Health involved proprietary information architecture and access to a system used by competitors.
The case is highly relevant to protocol control because it illustrates the tension between:
intellectual property;
proprietary infrastructure;
interoperability;
competition.
Relevance
A dominant ecosystem may claim:
"Our protocol is proprietary."
But intellectual-property protection does not automatically eliminate competition-law scrutiny.
Where proprietary infrastructure becomes indispensable to competition and exclusionary conduct satisfies the relevant legal requirements, access issues can arise.
10. Case Law 5 — Microsoft Corp. v Commission
Case T-201/04, General Court of the European Union
Microsoft is one of the most important authorities for understanding interoperability and ecosystem control.
The case involved Microsoft's refusal to provide interoperability information necessary for competing work-group server products.
Why it matters
Microsoft's control over technical information affected the ability of rival products to communicate with Windows-based systems.
This created a powerful ecosystem advantage:
Windows dominance → interoperability control → rival disadvantage → stronger Windows ecosystem.
Principle
Technical interoperability can become a competition-law issue where control over interfaces reinforces dominant-market power and excludes competitors.
11. Case Law 6 — Google Shopping
Case T-612/17
The Google Shopping litigation illustrates how control over a dominant platform's interaction architecture can influence downstream competition.
Google controlled the search environment through which users accessed competing services.
The General Court upheld the finding concerning Google's favourable treatment of its own comparison-shopping service.
Relevance to ecosystem lock-in
The same structural concern can arise when a platform controls:
rankings;
APIs;
access permissions;
default settings;
visibility;
technical integration.
The platform may effectively determine which complementary services receive access to the ecosystem.
12. Case Law 7 — Apple Inc. v Pepper
587 U.S. 273 (2019)
Apple v Pepper concerned Apple's App Store and the economic relationship between Apple and consumers.
Although primarily a U.S. standing case, the litigation highlights the significance of platform architecture in determining commercial relationships.
Apple's control over the App Store creates an ecosystem connecting:
developers;
consumers;
payment systems;
applications;
device functionality.
Relevance
The case illustrates why modern platform competition cannot always be analysed by looking at individual products separately.
The competitive unit may be the ecosystem.
13. Case Law 8 — Epic Games, Inc. v Apple Inc.
U.S. District Court for the Northern District of California
The Epic litigation directly concerned Apple's App Store ecosystem and Apple's rules governing interaction between developers and users.
Important issues included:
app distribution;
payment systems;
anti-steering restrictions;
platform rules;
access to consumers.
Relevance
The case demonstrates how platform rules themselves can become the object of competition-law scrutiny.
The platform does not merely sell a product.
It establishes the rules under which other businesses can participate.
14. Case Law 9 — United Brands v Commission
Case 27/76, CJEU
United Brands established the principle that dominant undertakings have a special responsibility not to impair genuine competition.
Relevance
If a dominant ecosystem controls interaction protocols, its ability to change those protocols can become a competition concern.
For example:
"Our protocol is private."
may not be a complete answer where the protocol has become a critical gateway to competition.
15. Case Law 10 — Magill
Joined Cases C-241/91 P and C-242/91 P, CJEU
The Magill litigation concerned refusal to license copyright-protected information.
The case is important for understanding the relationship between:
intellectual property;
interoperability;
access;
dominance.
Relevance
Protocols can themselves be protected through:
copyright;
patents;
trade secrets;
contractual restrictions.
Competition law must therefore determine when proprietary control crosses into exclusionary conduct.
16. Interaction Protocols as "Private Regulation"
A powerful ecosystem platform can effectively create its own regulatory system.
It may determine:
who may participate;
technical requirements;
access conditions;
data formats;
payment rules;
security standards;
ranking rules;
dispute procedures.
The platform therefore begins to resemble a private regulator.
This creates a competition concern because the entity simultaneously:
makes the rules + participates in the market + controls enforcement.
17. Ecosystem Lock-In Through Technical Incompatibility
One of the simplest mechanisms is incompatibility.
Suppose:
Platform A's devices communicate only through Protocol A.
A rival develops:
Protocol B.
If users cannot transfer data or devices between A and B, switching becomes costly.
The incumbent does not necessarily need to prohibit competitors.
It may simply maintain:
closed interoperability.
18. Deliberate Degradation of Interoperability
A more sophisticated concern is degradation.
A dominant platform may technically permit interoperability but make it inferior.
Examples:
slower APIs;
reduced functionality;
delayed updates;
restricted access;
lower data quality;
higher authentication requirements.
This can create the appearance of openness while preserving ecosystem dominance.
19. Strategic Protocol Changes
Protocol control becomes particularly problematic when standards are changed strategically.
Suppose:
rival products depend upon Protocol X;
the incumbent introduces Protocol X+;
the new protocol works perfectly with the incumbent's products;
rivals need substantial investment to adapt;
users migrate toward the incumbent ecosystem.
The protocol change may therefore function as an exclusionary strategy.
20. Versioning as a Lock-In Mechanism
Version control can also create dependency.
For example:
API v1 → v2 → v3 → v4.
If older versions are rapidly deprecated, developers may be forced to repeatedly invest in compatibility.
This increases:
switching costs;
development costs;
dependency on the platform.
21. Data Lock-In
Technical protocols frequently determine how data can be exported.
If an ecosystem stores data in a proprietary format, users may be unable to move:
contacts;
transaction history;
documents;
health information;
business records;
application data.
Data portability therefore becomes an important competition tool.
22. Identity Lock-In
Modern ecosystems increasingly control digital identity.
A user may authenticate through:
Apple ID;
Google account;
Microsoft identity;
enterprise identity provider;
platform-specific credentials.
If identity is tied to the ecosystem, switching becomes more difficult.
Identity can therefore become an interaction bottleneck.
23. Payment Protocol Lock-In
Payment infrastructure provides another example.
A platform may require applications to use:
Platform Payment System.
This can allow the platform to control:
transaction fees;
payment data;
customer relationships;
billing;
subscription management.
The competition issue is not merely the price of payment services.
It is the platform's ability to control access to the customer transaction.
24. Search and Ranking Protocols
Interaction control also includes algorithms determining:
search ranking;
recommendation;
visibility;
default placement.
A dominant ecosystem can therefore control not only whether rivals technically connect but whether users can discover them.
This creates a distinction between:
interoperability
and
effective interoperability.
A rival technically accessible but systematically hidden may not be an effective competitive constraint.
25. Network Effects
Network effects make ecosystem lock-in especially powerful.
The structure is:
more users → more developers → more applications → more users.
A dominant ecosystem therefore becomes increasingly attractive as it grows.
This creates positive feedback.
Once the ecosystem reaches sufficient scale, switching to another system can mean losing access to the network.
26. Indirect Network Effects
Developers may follow users.
Users may follow applications.
Investors may follow liquidity.
Merchants may follow consumers.
Banks may follow payment acceptance.
These are indirect network effects.
Interaction protocols can coordinate all sides of the ecosystem.
Consequently, control over the protocol may create market power across multiple connected markets.
27. Tying Through Protocols
Protocol control can facilitate tying.
For example:
Access to Platform A requires use of Platform A's authentication service.
or:
Hardware functionality requires Platform A's cloud service.
or:
Applications must use Platform A's payment API.
The technical dependency can therefore perform the same economic function as contractual tying.
28. Self-Preferencing Through Protocol Design
A platform can favour its own products through technical architecture.
For example:
its own applications receive privileged API access;
its own devices receive additional functionality;
its own services receive faster authentication;
its own products obtain earlier access to new protocols.
This may be more difficult to detect than conventional discriminatory pricing.
29. Interoperability as a Competition Remedy
Where protocol control produces substantial foreclosure, authorities may consider:
API access obligations;
interoperability mandates;
data portability;
common technical standards;
non-discriminatory access;
interface transparency;
protocol governance requirements.
However, compulsory interoperability can also reduce incentives for innovation.
Therefore, remedies must be carefully designed.
30. The Essential-Facilities Limitation
Not every successful protocol should become a mandatory shared facility.
The reasoning in Bronner and related cases indicates that competition law must avoid creating a general duty to assist competitors.
A strong case for intervention generally requires factors such as:
substantial market power;
indispensability;
lack of realistic alternatives;
exclusionary effect;
inability of rivals to compete effectively;
absence of adequate objective justification.
31. Ecosystem Lock-In and Innovation
Lock-in can have two opposite effects.
Positive
Stable standards may encourage:
investment;
interoperability;
innovation;
security;
reliability.
Negative
Excessive control can discourage:
competing standards;
technological substitution;
disruptive innovation;
new entrants.
Competition law therefore must distinguish:
standardisation that facilitates competition
from
standardisation that suppresses competition.
32. Protocol Governance and Competition
Who controls the protocol is therefore critical.
Possible governance structures include:
Centralised
One firm controls the protocol.
Consortium-based
Several firms jointly control it.
Open standard
Independent participants can develop compatible implementations.
Decentralised
No single undertaking controls the protocol.
Each structure produces different competition risks.
33. Consortium Risks
Open-looking protocols may still produce antitrust concerns.
A consortium can potentially:
exclude rivals;
coordinate standards;
exchange commercially sensitive information;
impose discriminatory technical requirements.
Thus:
"Open standard" does not automatically mean "competitive standard."
34. Protocol Control and Article 101 TFEU
Where several companies jointly establish or control an interaction protocol, Article 101 concerns may arise if the arrangement:
restricts competing technologies;
excludes rival standards;
allocates markets;
coordinates prices;
exchanges sensitive information.
Standard-setting organisations therefore require careful competition-law governance.
35. Protocol Control and Article 102 TFEU
For a dominant undertaking, potential concerns include:
refusal of interoperability;
discriminatory access;
self-preferencing;
tying;
exclusionary technical changes;
degradation of interoperability;
excessive switching costs.
The legal question is whether the conduct constitutes abuse of dominance, not merely whether the firm controls technology.
36. U.S. Antitrust Analysis
Potentially relevant theories include:
Section 1
Agreements concerning:
standards;
protocols;
interoperability;
ecosystem access.
Section 2
Unilateral exclusionary conduct by a dominant platform.
Section 7
Acquisitions that eliminate emerging competitors or consolidate complementary infrastructure.
37. Emerging Concept: Protocol Dominance
A future competition-law concept could be protocol dominance.
This would describe market power arising not simply from selling products but from controlling the rules through which products interact.
Relevant indicators could include:
percentage of transactions using the protocol;
number of dependent firms;
interoperability alternatives;
switching costs;
technical dependence;
network effects;
proprietary data;
governance power.
38. Emerging Concept: Ecosystem Switching Cost
Traditional competition analysis often measures monetary switching costs.
Ecosystem lock-in requires a broader measure:
total economic cost of leaving the ecosystem.
This may include:
Financial cost + data loss + network loss + learning cost + compatibility cost + reputation loss + opportunity cost.
A platform with low monetary prices can therefore possess enormous market power because switching is expensive.
39. Emerging Concept: Interaction-Gateway Monopoly
An especially important future doctrine is the interaction-gateway monopoly.
The concept applies where one undertaking controls the gateway through which multiple independent businesses must interact with consumers or with one another.
Examples include:
app stores;
payment systems;
identity systems;
cloud APIs;
operating-system interfaces;
digital advertising exchanges.
The gateway may become economically more important than the underlying product.
40. Regulatory Safeguards
Effective regulation may require:
1. Interoperability
Rivals should be able to communicate with the ecosystem under reasonable conditions.
2. Data portability
Users should be able to transfer their information.
3. API access
Independent developers should receive non-discriminatory technical access where appropriate.
4. Protocol transparency
Material technical changes should not be used strategically to exclude rivals.
5. Non-discrimination
The platform should not favour its own products without legitimate justification.
6. Switching assistance
Users should have practical mechanisms for migrating.
41. Case-Law Synthesis
| Case | Core principle | Protocol/ecosystem relevance |
|---|---|---|
| Terminal Railroad | Infrastructure bottleneck | Critical digital gateway |
| MCI v AT&T | Access to essential infrastructure | API/interoperability access |
| Bronner | Strict essential-facilities doctrine | Limits compulsory interoperability |
| IMS Health | Proprietary information infrastructure | Proprietary protocols/data |
| Microsoft | Interoperability and exclusion | Technical interface control |
| Google Shopping | Self-preferencing | Ecosystem discrimination |
| Apple v Pepper | Platform architecture | Multi-sided ecosystem |
| Epic Games v Apple | Platform rules and access | App/payment lock-in |
| United Brands | Special responsibility of dominant firms | Protocol governance |
| Magill | IP/access interface | Proprietary technical standards |
42. Conclusion
Interaction protocol control and ecosystem lock-in represent an increasingly important frontier of competition law.
The central transformation is from:
control over products
to:
control over the rules through which products, services and users interact.
The case law—from Terminal Railroad and MCI v AT&T through Bronner, IMS Health, Microsoft, Google Shopping, Apple v Pepper, Epic Games v Apple, United Brands and Magill—provides different pieces of the legal framework for analysing this problem.
The most important distinction is between:
a successful ecosystem that users voluntarily choose
and
an ecosystem whose technical architecture makes meaningful exit or competitive entry increasingly impossible.
Where a dominant undertaking controls an indispensable interaction protocol, uses that control to discriminate against rivals, degrades interoperability, ties complementary services, self-preferences its own products, or deliberately increases switching costs, the protocol itself can become an instrument of exclusion.
The emerging competition-law principle can therefore be stated as:
Control over the rules of interaction can amount to control over the conditions of competition.
As markets become increasingly ecosystem-based, interoperability, protocol governance, data portability and switching costs are likely to become as important to competition analysis as price, market share and output.

comments