Identity Verification Apis As Essential Facilities .
Identity Verification APIs as Essential Facilities
1. Introduction
Identity Verification APIs are application-programming interfaces that allow a platform, bank, marketplace, government service, fintech company, employer, or other digital service to verify that a person is who they claim to be. They may connect to government identity databases, biometric systems, credit-information databases, mobile-network records, document-verification services, fraud databases, or proprietary identity graphs.
The competition-law question arises when a dominant undertaking controls an identity-verification API that rivals cannot reasonably replicate or replace, and access to that API becomes necessary to compete in a downstream market.
The essential-facilities doctrine provides a framework for determining when a refusal to provide access to a controlled input can constitute an abuse of dominance. In digital markets, however, the analysis becomes more complicated because an identity API may combine technical infrastructure, data, authentication standards, network effects, reputation, and regulatory permissions.
The central question is:
When does an identity-verification API cease to be merely a commercial service and become an indispensable digital infrastructure that a dominant undertaking may be required to make available on fair and non-discriminatory terms?
2. Meaning of an Identity Verification API
An identity-verification API is an interface through which one digital service can request another system to authenticate or verify identity-related information.
Typical functions include:
- government-ID verification;
- passport or driver's-license verification;
- biometric matching;
- facial recognition;
- age verification;
- address verification;
- bank-account ownership verification;
- mobile-number verification;
- fraud and synthetic-identity detection;
- KYC verification;
- AML screening;
- sanctions screening;
- authentication-token issuance;
- account-recovery verification.
For example:
Consumer → Fintech App → Identity API → Identity Database → Verification Result → Fintech App
The API therefore operates as an intermediary between identity information and downstream digital services.
3. Why Identity APIs Can Become Essential Facilities
An identity API can acquire infrastructure-like characteristics when several conditions exist simultaneously.
A. Unique identity data
The operator may possess data that competitors cannot reproduce, such as:
- historical verification records;
- government-authorised credentials;
- biometric templates;
- extensive fraud databases;
- cross-platform identity histories;
- device-identity information.
B. Network effects
The value of the identity system increases as more institutions use it.
More participants generate:
more identity signals → better fraud detection → higher reliability → more adoption → more data → stronger verification capability.
This creates a self-reinforcing competitive advantage.
C. Regulatory dependency
Certain industries may legally require reliable identity verification.
For example:
- financial services;
- telecommunications;
- online gambling;
- healthcare;
- employment platforms;
- digital payments;
- cryptocurrency services.
If the dominant API becomes the practically accepted mechanism for satisfying these requirements, exclusion can have significant competitive consequences.
D. High replication costs
A rival may technically be able to build an API, but still be unable to reproduce:
- the underlying database;
- government connections;
- historical data;
- biometric coverage;
- authentication reputation;
- accumulated fraud intelligence.
The relevant issue is therefore not merely technical replicability, but commercial and regulatory replicability.
4. Essential-Facilities Doctrine
The doctrine generally addresses circumstances in which a dominant undertaking controls an input or infrastructure that is indispensable for effective competition.
Classic elements include:
- control of an essential facility;
- indispensability;
- inability to reasonably duplicate the facility;
- refusal or restricted access;
- elimination or substantial weakening of downstream competition;
- absence of adequate objective justification.
The doctrine is applied cautiously because compulsory access can interfere with:
- property rights;
- investment incentives;
- innovation;
- security;
- privacy;
- commercial freedom.
Consequently, dominance alone does not automatically create an obligation to share an API.
5. Identity Verification APIs and Indispensability
Indispensability should be analysed at the level of the actual competitive process, rather than simply asking whether another verification provider exists.
Example
Suppose Platform A controls the largest identity-verification API.
Platform B can theoretically build its own API.
However, Platform B cannot obtain:
- the same government verification connection;
- the same biometric coverage;
- the same historical fraud information;
- the same accuracy;
- the same acceptance by banks;
- the same regulatory certification.
If customers consequently refuse to use Platform B unless it supports Platform A's identity system, the API may become an indispensable gateway.
The critical question is therefore:
Could an equally efficient competitor realistically compete without access to the dominant identity-verification infrastructure?
6. Data as the Essential Facility
Identity APIs raise an important variation of the essential-facilities doctrine: the facility may consist not merely of software but of data.
Consider a proprietary identity graph containing:
- billions of identity-device relationships;
- historical verification outcomes;
- fraud patterns;
- account associations;
- behavioural signals;
- biometric matches.
The API may technically be replaceable, but the underlying dataset may not be.
Thus:
API + unique dataset + authentication network = potentially indispensable infrastructure.
This shifts competition analysis toward the interaction between data access and infrastructure access.
7. Refusal to Supply
A dominant identity provider could potentially engage in exclusionary conduct by:
- completely refusing API access;
- terminating existing access;
- imposing discriminatory verification requirements;
- providing inferior API functionality to competitors;
- imposing excessive access fees;
- restricting API rate limits;
- withholding important verification fields;
- delaying verification for competing platforms;
- requiring exclusivity;
- prohibiting interoperability;
- refusing technical integration;
- selectively degrading API performance.
The strongest case arises where access is indispensable and refusal effectively prevents rivals from competing.
8. Discriminatory API Access
A particularly important concern is self-preferencing through API quality.
Suppose the dominant identity provider operates its own downstream financial platform.
It provides:
- 99.9% verification availability to its own platform;
- instant verification;
- richer identity attributes;
while competitors receive:
- slower verification;
- lower API limits;
- incomplete identity fields;
- higher prices.
This could transform an apparently neutral infrastructure into an exclusionary bottleneck.
The competition concern is stronger where the provider's downstream affiliate competes directly with API customers.
9. API Pricing and Margin Squeeze
Essential-facility problems can also arise through pricing.
Assume:
- wholesale API verification cost = ₹1;
- dominant provider charges rivals = ₹8;
- its own downstream service effectively receives the same service for ₹1;
- downstream competitors cannot profitably compete at ₹8.
The conduct could raise a margin-squeeze concern.
The relevant question becomes whether the dominant undertaking has structured access prices so that equally efficient downstream competitors cannot viably operate.
10. Interoperability as an Essential-Facility Remedy
A competition authority may not necessarily need to require unrestricted data disclosure.
Less intrusive remedies may include:
API interoperability
The dominant identity provider must permit rival platforms to connect to the verification system.
Standardised access
Technical standards could prevent discriminatory treatment.
Functional equivalence
Competitors receive substantially equivalent API functionality.
Data portability
Users may transfer relevant identity credentials between competing services.
Non-discrimination
The provider cannot give its own downstream business preferential API treatment.
Auditing
Independent technical auditing can detect:
- latency discrimination;
- throttling;
- selective outages;
- verification failures.
11. Security and Privacy as Objective Justifications
Identity infrastructure presents unusually strong legitimate justifications for restricting access.
A provider might legitimately refuse access where the applicant:
- cannot satisfy cybersecurity requirements;
- lacks regulatory authorisation;
- presents unacceptable fraud risks;
- seeks sensitive biometric information unnecessarily;
- cannot comply with privacy requirements;
- cannot guarantee secure handling of credentials.
Therefore, essential-facility analysis cannot simply equate refusal with abuse.
A proportionate system should distinguish between:
legitimate security restrictions
and
strategic restrictions designed to exclude competitors.
12. Six Important Case Laws
1. United Brands v Commission
United Brands Company v Commission, Case 27/76
The European Court of Justice examined abusive conduct by a dominant undertaking and established important principles concerning dominance and exclusionary behaviour.
Relevance
The case is useful for identity APIs because a dominant provider cannot use its market position to impose conditions that distort competitive opportunities.
For an identity API, the relevant question would be whether contractual or technical conditions imposed by the dominant provider exploit its control over an indispensable gateway.
2. Commercial Solvents v Commission
Commercial Solvents Corp. v Commission, Joined Cases 6/73 and 7/73
This is one of the foundational cases concerning refusal to supply.
A dominant undertaking controlling an upstream input could not simply withdraw supply where the refusal threatened to eliminate competition in a downstream market.
Relevance to identity APIs
The analogy is particularly strong where:
upstream identity verification → downstream digital service
The API operator controls the upstream verification input while competing with the customers to whom the API is supplied.
A refusal designed to protect its downstream business can therefore raise Article 102 concerns.
3. Bronner v Mediaprint
Oscar Bronner GmbH & Co. KG v Mediaprint, Case C-7/97
This is one of the most important modern essential-facilities decisions.
The Court adopted a stringent approach to compulsory access and emphasised the importance of demonstrating indispensability.
Relevance
For identity-verification APIs, merely showing that the dominant API is:
- cheaper;
- better;
- faster;
- more widely used;
would not necessarily be sufficient.
The competitor must demonstrate that there is no realistic alternative.
Thus:
“Best identity API” is not automatically equivalent to “essential identity API.”
4. IMS Health v Commission
IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG, Joined Cases C-418/01 P and C-7/97
The Court dealt with access to an information structure protected by intellectual-property rights and developed important principles concerning indispensability and elimination of competition.
Relevance
Identity systems frequently combine:
- proprietary databases;
- software;
- data structures;
- authentication architecture;
- intellectual-property rights.
IMS Health is therefore particularly relevant where an identity provider argues that compulsory API access would interfere with proprietary technology.
The case demonstrates that intellectual-property protection does not automatically immunise exclusionary conduct, although the threshold for compulsory access remains high.
5. Microsoft v Commission
Microsoft Corp. v Commission, Case T-201/04
The General Court upheld findings concerning Microsoft's refusal to provide interoperability information to competitors.
Relevance to identity APIs
This is highly significant for digital identity infrastructure.
Interoperability may itself constitute a competitive parameter.
A dominant identity platform could potentially restrict competition by withholding:
- authentication protocols;
- interoperability specifications;
- technical documentation;
- identity-token compatibility;
- API functionality.
The Microsoft case demonstrates that technological interoperability can be central to competition where control over interoperability prevents effective rivalry.
6. Slovak Telekom v Commission
Slovak Telekom a.s. v European Commission, Joined Cases C-152/19 P and C-165/19 P
The case concerned access to telecommunications infrastructure and the relationship between refusal-to-deal theories and margin-squeeze analysis.
Relevance
Identity-verification APIs can similarly operate as infrastructure between upstream and downstream markets.
The case is particularly useful for analysing situations in which the dominant undertaking:
- controls an essential input;
- supplies that input to rivals;
- competes downstream;
- sets access conditions affecting downstream competition.
It therefore helps distinguish simple refusal to supply from broader exclusionary pricing strategies.
13. Additional Relevant Case: Google Shopping
Google Search (Shopping)
Google Search (Shopping), Case AT.39740
The European Commission found Google liable for favouring its own comparison-shopping service in search results.
Relevance
Although this was not an essential-facilities case in the strict sense, it is highly relevant to identity APIs because it illustrates leveraging from an upstream digital gateway into a downstream market.
A dominant identity provider that controls verification infrastructure could potentially favour:
- its own fintech platform;
- its own marketplace;
- its own advertising service;
- its own employment platform;
through preferential identity access.
Thus the competition issue may involve both essential-facility access and self-preferencing.
14. Competition Analysis Under Article 102 TFEU
An identity API case could potentially be analysed under several Article 102 theories.
Article 102(b)
Limiting production, markets or technical development.
Article 102(c)
Applying discriminatory conditions to equivalent transactions.
Article 102(a)
Imposing unfair trading conditions or excessive access prices.
Refusal-to-supply doctrine
Where access to the API is indispensable.
Margin squeeze
Where access pricing prevents downstream competitors from operating profitably.
15. UK Competition Law
In the United Kingdom, the principal framework would be Chapter II of the Competition Act 1998, concerning abuse of a dominant position.
A dominant identity-verification provider could potentially face scrutiny where it:
- refuses access to indispensable identity infrastructure;
- discriminates against competing platforms;
- degrades API functionality;
- imposes exclusionary prices;
- leverages identity infrastructure into adjacent markets;
- engages in self-preferencing.
The Microsoft interoperability principles and European refusal-to-supply jurisprudence remain highly relevant as persuasive analytical background, although UK authorities apply the domestic statutory framework.
16. Digital Markets, Competition and Consumer Data
Identity APIs create a particularly important interaction between competition law and data governance.
An identity provider may simultaneously control:
- authentication infrastructure;
- identity data;
- fraud data;
- digital credentials;
- interoperability standards;
- user relationships;
- downstream platforms.
This creates a potentially powerful identity bottleneck.
The resulting structure can be represented as:
Identity Data
↓
Identity Graph
↓
Verification API
↓
Authentication Gateway
↓
Multiple Downstream Markets
Control at the API layer may therefore allow the undertaking to influence several markets simultaneously.
17. Identity APIs and Network Effects
Network effects can make an identity API increasingly difficult to challenge.
For example:
More users
↓
More verified identities
↓
More fraud intelligence
↓
Higher verification accuracy
↓
More merchants and platforms adopt API
↓
More users become dependent on the identity ecosystem
This can create identity-network lock-in.
Eventually, competitors may technically offer alternative verification services but lack sufficient scale to become viable substitutes.
18. Essential Facility or Data Monopolisation?
The distinction is important.
A competition authority should determine whether the problem concerns:
Infrastructure
The API itself is indispensable.
Data
The underlying identity dataset is indispensable.
Network
The verification ecosystem is indispensable because users and businesses are already connected to it.
Regulatory access
The dominant provider has unique regulatory or governmental integration.
Combination
The strongest cases may involve all four.
Thus, the facility may be better described as an identity-verification ecosystem rather than merely an API.
19. Possible Remedies
A competition authority could consider several remedies.
1. Mandatory API access
Require the dominant provider to provide access to qualifying competitors.
2. FRAND-style access
Access must be:
- fair;
- reasonable;
- non-discriminatory.
3. API neutrality
The dominant provider must offer equivalent functionality to its own downstream business and rivals.
4. Data portability
Allow users to transfer verified identity credentials.
5. Interoperability standards
Require common authentication protocols.
6. Technical non-discrimination
Prohibit:
- artificial latency;
- throttling;
- discriminatory uptime;
- selective API failures.
7. Independent monitoring
A regulator or auditor could monitor API performance.
20. Limits of the Essential-Facilities Doctrine
Compulsory access should not become automatic whenever a digital platform becomes popular.
There are several reasons.
Innovation incentives
Companies may reduce investment in identity technology if competitors can freely appropriate the resulting infrastructure.
Security
Identity systems involve extremely sensitive authentication mechanisms.
Privacy
Opening identity databases can increase privacy and cybersecurity risks.
Fraud
Poorly controlled access may facilitate synthetic identities and identity theft.
Regulatory obligations
The API operator may itself be legally prohibited from disclosing certain identity information.
Therefore, the doctrine should remain exceptional and proportionate.
21. A Useful Legal Test
A competition authority assessing an identity-verification API could apply the following sequence:
Step 1 — Define the market
Possible markets include:
- identity verification;
- digital authentication;
- KYC services;
- biometric verification;
- fraud prevention;
- downstream digital services.
Step 2 — Establish dominance
Examine:
- market share;
- network effects;
- switching costs;
- data advantages;
- regulatory barriers;
- interoperability;
- customer dependence.
Step 3 — Identify the facility
Determine whether the relevant facility is:
- API;
- database;
- identity graph;
- authentication network;
- regulatory connection;
- combined ecosystem.
Step 4 — Test indispensability
Ask:
Can an equally efficient competitor realistically reproduce the required verification capability?
Step 5 — Examine refusal
Was access:
- completely denied;
- technically restricted;
- delayed;
- priced excessively;
- selectively degraded?
Step 6 — Examine competitive harm
Does the conduct:
- exclude rivals;
- protect the dominant firm's downstream business;
- increase switching costs;
- foreclose innovation;
- reduce interoperability?
Step 7 — Consider objective justification
Consider:
- privacy;
- cybersecurity;
- fraud prevention;
- regulatory requirements;
- legitimate technical constraints.
Step 8 — Select proportionate remedies
Prefer the least intrusive remedy capable of restoring competition.
22. Hypothetical Example
Assume IdentityHub controls 85% of the identity-verification market.
It has:
- government verification connections;
- biometric databases;
- 500 million identity records;
- extensive fraud intelligence.
IdentityHub also owns PayHub, a competing digital-payment platform.
It provides its own payment service with instant verification but requires rival payment platforms to:
- pay five times more;
- accept lower API limits;
- wait several seconds longer for verification;
- receive fewer identity attributes.
Eventually merchants begin preferring PayHub because customers can complete onboarding much faster.
The conduct could raise several competition-law concerns:
Essential facility: identity verification may be indispensable.
Discrimination: rival payment platforms receive inferior access.
Self-preferencing: IdentityHub benefits its own downstream business.
Margin squeeze: API prices may make rival payment platforms commercially unviable.
Leveraging: identity dominance is extended into payments.
The case would therefore be substantially stronger than a simple commercial dispute over API access.
23. Key Case-Law Principles
| Case | Principal principle | Identity API relevance |
|---|---|---|
| Commercial Solvents v Commission | Refusal to supply an important upstream input can be abusive | Identity API as upstream verification input |
| Bronner v Mediaprint | Strict indispensability requirement | Alternative identity providers must be genuinely inadequate |
| IMS Health v NDC Health | Exceptional compulsory access involving proprietary information | Proprietary identity databases and API structures |
| Microsoft v Commission | Interoperability can be competitively essential | Authentication/API interoperability |
| Slovak Telekom v Commission | Infrastructure access and exclusionary pricing | API access and margin squeeze |
| United Brands v Commission | Dominant firms have special competitive responsibilities | Discriminatory/exclusionary API conditions |
| Google Shopping | Leveraging and self-preferencing through a digital gateway | Identity provider favouring its own downstream service |
24. Conclusion
Identity Verification APIs can potentially constitute essential facilities where they become indispensable gateways to downstream digital markets. The strongest cases arise when a dominant undertaking controls not simply software, but a combination of unique identity data, authentication infrastructure, regulatory connectivity, network effects and interoperability standards.
The decisive legal issue is not whether an API is technologically important. It is whether effective competition is realistically impossible without access to it, and whether the dominant undertaking's refusal or discriminatory access conditions unjustifiably foreclose competition.
The essential-facilities doctrine therefore provides a potentially powerful framework for addressing identity infrastructure bottlenecks, but it must be applied cautiously because identity systems involve unusually serious concerns involving privacy, cybersecurity, fraud prevention and investment incentives.
The emerging competition-law principle can be expressed as:
Control over identity verification can become control over market entry when access to the identity layer is indispensable for participation in downstream digital markets.
Thus, future competition cases involving digital identity are likely to move beyond the traditional question of “Who owns the infrastructure?” toward the broader question of “Who controls the identity gateway through which competing digital services must pass?”

comments