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:

  1. control of an essential facility;
  2. indispensability;
  3. inability to reasonably duplicate the facility;
  4. refusal or restricted access;
  5. elimination or substantial weakening of downstream competition;
  6. 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:

  1. authentication infrastructure;
  2. identity data;
  3. fraud data;
  4. digital credentials;
  5. interoperability standards;
  6. user relationships;
  7. 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

CasePrincipal principleIdentity API relevance
Commercial Solvents v CommissionRefusal to supply an important upstream input can be abusiveIdentity API as upstream verification input
Bronner v MediaprintStrict indispensability requirementAlternative identity providers must be genuinely inadequate
IMS Health v NDC HealthExceptional compulsory access involving proprietary informationProprietary identity databases and API structures
Microsoft v CommissionInteroperability can be competitively essentialAuthentication/API interoperability
Slovak Telekom v CommissionInfrastructure access and exclusionary pricingAPI access and margin squeeze
United Brands v CommissionDominant firms have special competitive responsibilitiesDiscriminatory/exclusionary API conditions
Google ShoppingLeveraging and self-preferencing through a digital gatewayIdentity 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?”

 

 

LEAVE A COMMENT