1. Introduction

Trust APIs are application-programming interfaces that allow one platform, institution, government, identity provider, payment network, credit bureau, cybersecurity service, or other intermediary to determine whether a person, business, transaction, credential, device, document, or digital event should be trusted, verified, authenticated, permitted, or rejected.

Examples include APIs for:

• digital identity verification;
• KYC/AML verification;
• age and eligibility verification;
• credit and fraud scoring;
• business verification;
• certificate and credential validation;
• cybersecurity reputation;
• payment authentication;
• domain/device reputation;
• content or account authenticity;
• AI-generated-content provenance;
• employment and professional credentials.

The competition-law problem arises when a small number of firms become the verification layer through which other markets must operate. The API may then move from being an ordinary technical service to a centralized gatekeeping infrastructure.

The central concern is not merely that a company possesses data. It is that it can potentially decide who or what is economically recognized as trustworthy.

2. Meaning of Centralized Verification Power

Centralized verification power exists when an intermediary has substantial control over the process by which other market participants obtain recognition, access, authentication, or eligibility.

A simplified structure is:

Individual/business → Trust API → Verification decision → Platform/market access

For example:

Seller → business-verification API → “verified” status → marketplace access

or:

Consumer → identity API → identity confirmation → bank/fintech access

or:

AI system → provenance API → authenticity certification → distribution/platform access

The competition concern becomes stronger where the verification provider is difficult to bypass.

Three forms of power

A. Infrastructure power

The provider controls technical infrastructure necessary for verification.

B. Information power

The provider possesses datasets unavailable to competitors, allowing it to generate superior verification results.

C. Decision power

The provider determines the rules by which a participant is classified as:

• legitimate;
• fraudulent;
• safe;
• risky;
• compliant;
• verified;
• ineligible.

The third form is particularly important because classification can determine commercial opportunity.

3. Why Trust APIs Can Become Bottlenecks

A conventional API merely performs a technical function.

A trust API can perform something much more consequential:

It determines whether another economic actor is allowed to participate.

If banks, marketplaces, insurers, employers, governments, payment processors, and platforms all rely upon the same verification infrastructure, the API provider may acquire a position resembling a digital certification bottleneck.

This can produce:

1. network effects;
2. data advantages;
3. switching costs;
4. interoperability dependence;
5. reputational advantages;
6. economies of scale;
7. regulatory endorsement effects;
8. default-provider advantages.

4. Relevant Competition-Law Markets

Several relevant markets may exist simultaneously.

4.1 Identity-verification services

Providers compete to verify:

• identity;
• address;
• age;
• nationality;
• corporate status.

4.2 Trust and reputation services

The relevant service may involve determining whether an account, device, transaction, or business is trustworthy.

4.3 Fraud-detection services

Verification APIs may be used to prevent:

• payment fraud;
• account takeover;
• fake accounts;
• synthetic identities;
• transaction manipulation.

4.4 Credential-verification services

Universities, employers and professional platforms may depend upon APIs validating qualifications.

4.5 Digital-authenticity services

Future trust infrastructure may verify whether:

• media is AI-generated;
• content has been altered;
• a document is authentic;
• an AI model generated particular material.

Thus, the market may increasingly become a market for digital trust itself.

5. Dominance Through Verification Infrastructure

A firm does not necessarily become dominant merely because it has a popular API.

Competition authorities would examine factors such as:

• market share;
• number of connected businesses;
• number of verified identities;
• data accumulated;
• technical superiority;
• switching costs;
• interoperability;
• regulatory recognition;
• access to essential datasets;
• exclusivity;
• vertical integration;
• ability of customers to multi-home.

The important question is:

Can customers realistically obtain equivalent verification from another provider?

If not, the API may constitute a significant bottleneck.

6. Network Effects

Trust systems are unusually susceptible to network effects.

Suppose 80% of major platforms recognize a particular verification credential.

A new verification provider may technically offer an equivalent service, but its credential may have little commercial value because marketplaces and banks do not recognize it.

This creates a circular advantage:

More users → more verification data → greater accuracy → more platform adoption → more users

Eventually:

More adoption → industry standard → higher switching costs → stronger market power

The competitive problem is therefore not necessarily price.

It can be control over recognition.

7. Data Advantages

Trust APIs can accumulate extraordinarily valuable datasets.

For example, a provider could observe:

• identity attributes;
• transaction histories;
• fraud attempts;
• account relationships;
• device fingerprints;
• location signals;
• behavioral patterns;
• business ownership;
• credential histories;
• authentication failures.

A dominant provider could potentially use these datasets to improve its own verification product while denying equivalent access to competitors.

This creates a potential data-feedback loop:

Verification activity → data accumulation → better verification → increased adoption → additional data accumulation.

Competition law may therefore need to consider data accumulation as a source of durable infrastructure power.

8. Refusal to Interoperate

One of the most significant risks is refusal to interoperate.

Suppose a dominant platform says:

“Only verification credentials issued through our API will be accepted.”

If competitors cannot obtain equivalent access, the dominant provider may effectively control downstream participation.

Possible theories include:

• refusal to deal;
• denial of interoperability;
• essential-facility-type arguments;
• discriminatory access;
• tying;
• exclusionary conduct;
• leveraging;
• foreclosure of adjacent markets.

However, compulsory-access doctrines generally require careful analysis rather than assuming that every important API is an essential facility.

9. Self-Preferencing

A vertically integrated company creates another concern.

Imagine:

Company A owns the dominant trust API + marketplace + payment platform.

It could potentially:

1. verify third-party sellers;
2. obtain verification information;
3. rank sellers;
4. promote its own verified sellers;
5. restrict competitors;
6. impose more burdensome verification requirements on rivals.

This creates a possible vertical foreclosure mechanism.

The trust API becomes a competitive weapon rather than a neutral infrastructure layer.

10. Discriminatory Verification

A dominant API provider could theoretically apply different standards to different participants.

For example:

Such conduct could produce discrimination that is difficult to detect because the discrimination is hidden inside technical rules, risk models or API-access policies.

11. Algorithmic Verification and Competition

Modern trust APIs increasingly rely on machine learning.

The verification decision may depend on:

• risk scores;
• anomaly detection;
• behavioral models;
• graph analysis;
• biometric matching;
• device intelligence;
• automated fraud classifications.

This creates a special competition problem.

The API may say:

“Rejected.”

But the customer may not know:

• why it was rejected;
• which data caused rejection;
• whether competitors would reach the same conclusion;
• whether the model is biased;
• whether the result can be challenged.

Consequently, algorithmic opacity can reinforce market power.

12. Case Law

The following cases are particularly useful for analyzing centralized verification power, even though several arose in adjacent digital, infrastructure, data, interoperability, or platform contexts rather than directly involving modern “Trust APIs.”

Case 1 — United States v. Microsoft Corp. (2001)

The U.S. Microsoft litigation concerned Microsoft's dominance in operating systems and its conduct affecting competing browser technologies.

Relevance

Microsoft demonstrates how control over an important technological platform can be used to disadvantage complementary or competing products.

For Trust APIs, the analogy is:

dominant infrastructure → control over access/interface → downstream foreclosure

If a dominant trust provider controls an interface through which businesses must authenticate customers, it may possess opportunities to exclude competing verification services.

Principle

Technological integration and control over an important platform can create competition concerns when used to restrict competitive alternatives.

Case 2 — Bronner v. Mediaprint (CJEU, 1998)

This case concerned access to a newspaper distribution system and the strict conditions applicable to refusal-to-deal claims under EU competition law.

Relevance

Trust APIs raise an analogous question:

When does a privately controlled verification infrastructure become sufficiently indispensable that refusal of access can constitute abusive conduct?

Bronner is important because it prevents competition law from automatically transforming every commercially important infrastructure into an essential facility.

Principle

Indispensability and the absence of realistic alternatives are critical considerations in refusal-to-deal analysis.

Case 3 — IMS Health GmbH & Co. OHG v NDC Health GmbH (CJEU, 2004)

IMS Health concerned access to a proprietary data structure used by pharmaceutical companies.

Relevance

The case is highly relevant to Trust APIs because modern verification infrastructure can involve proprietary:

• databases;
• classification structures;
• identity datasets;
• technical standards;
• verification architectures.

A dominant provider may argue that competitors cannot access its system because it is proprietary.

IMS Health demonstrates that intellectual-property protection does not automatically eliminate competition-law scrutiny where exceptional conditions for compulsory access are satisfied.

Principle

Competition law may intervene in exceptional circumstances where control over a protected system becomes indispensable for effective competition.

Case 4 — Slovak Telekom v European Commission (CJEU, 2021)

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

Relevance

The case is useful for understanding how control over infrastructure can affect downstream competitors.

A Trust API can similarly operate as an upstream infrastructure layer.

For example:

Trust API → fintech → consumers

If the API provider restricts access or imposes discriminatory technical conditions, downstream competition may be weakened.

Principle

Dominant control over upstream infrastructure can generate exclusionary effects in downstream markets.

Case 5 — Google Shopping (Google and Alphabet v Commission, CJEU, 2024)

The Google Shopping litigation concerned Google's treatment of competing comparison-shopping services within its search ecosystem.

Relevance

The case is important because it demonstrates the competition significance of self-preferencing within a dominant digital ecosystem.

For Trust APIs, consider:

Dominant verification API + competing downstream verification-dependent services

If the provider gives its own downstream business preferential:

• verification speed;
• ranking;
• access;
• data;
• reliability;
• authentication status,

competition authorities could examine whether the conduct forecloses rivals.

Principle

Control over a major digital intermediation layer can create competition concerns where the dominant firm uses that position to advantage its own downstream service.

Case 6 — Meta Platforms v Bundeskartellamt (CJEU, 2023)

The case concerned Meta's combination and use of personal data across services and the relationship between competition law and data protection rules.

Relevance

Trust APIs can create an even more direct data-competition relationship.

A dominant verification company may possess enormous quantities of:

• identity data;
• authentication data;
• transaction signals;
• fraud information;
• behavioral data.

The competitive advantage generated by these datasets may be reinforced when users cannot realistically avoid the dominant provider.

Principle

Competition authorities may have to consider how data practices contribute to market power, while respecting the separate legal framework governing personal data.

Case 7 — Google Android (European Commission, 2018)

The European Commission's Android decision addressed Google's conduct concerning Android devices, including tying and restrictions affecting competing services.

Relevance

The case illustrates how a dominant technological ecosystem can use contractual and technical relationships to extend power into neighboring markets.

A Trust API could similarly be bundled with:

• cloud services;
• payment services;
• operating systems;
• advertising platforms;
• marketplaces;
• identity systems.

Principle

Dominance in one technological layer can potentially be leveraged into adjacent markets through tying, contractual restrictions, or ecosystem control.

Case 8 — United Brands v Commission (CJEU, 1978)

United Brands is a foundational EU abuse-of-dominance case concerning market power and exclusionary/other abusive conduct.

Relevance

Its broader importance is methodological.

Competition law does not require a firm to possess an absolute monopoly before its conduct becomes problematic.

For Trust APIs, substantial market power could arise where:

• alternatives are weak;
• customers face high switching costs;
• network effects are strong;
• regulatory recognition reinforces the incumbent;
• interoperability is limited.

Principle

Dominance is assessed through economic and structural conditions rather than merely by asking whether competitors formally exist.

13. Lessons From the Case Law

Taken together, these cases suggest several principles relevant to Trust APIs.

14. Trust APIs as “Recognition Infrastructure”

A particularly important theoretical development is the distinction between:

Physical infrastructure

Roads, electricity networks, telecommunications networks.

Digital infrastructure

Cloud systems, operating systems, app stores, payment networks.

Trust infrastructure

Systems determining whether an economic actor, transaction, identity or piece of information is recognized as legitimate.

Trust infrastructure may become more important than traditional infrastructure because participation in the digital economy increasingly depends on authentication.

A future economy could therefore have:

Infrastructure → identity → verification → permission → transaction

The organization controlling verification can occupy a strategic position between identity and economic participation.

15. Regulatory Recognition as a Moat

Government recognition can make centralized verification power particularly durable.

Suppose a government, regulator or major industry association recognizes one credential as the preferred verification standard.

Then:

Regulatory recognition → industry adoption → network effects → commercial dependency

Competitors may technically offer alternatives but still be unable to compete effectively.

This creates a form of institutional network effect.

The competition problem therefore extends beyond private contracts into the interaction between:

• regulators;
• standards organizations;
• dominant platforms;
• financial institutions;
• identity providers.

16. Trust API Tying

A dominant provider might require customers purchasing one service to purchase its verification service as well.

For example:

“To use our payment platform, you must use our identity-verification API.”

This could create a tying theory if the legal and economic conditions are satisfied.

The concern increases where:

• the tying product is dominant;
• the verification product is separately identifiable;
• customers would otherwise use competing verification providers;
• the tie forecloses a substantial portion of the adjacent market.

17. Exclusive Verification Agreements

Another risk is contractual exclusivity.

For example:

A major marketplace agrees to use only Provider X for identity verification.

If Provider X is already dominant, widespread exclusivity could prevent competing Trust APIs from obtaining the scale necessary to compete.

The result can be:

incumbent scale → exclusivity → competitor inability to scale → greater incumbent dominance.

This is particularly significant in markets with strong data-network effects.

18. Switching Costs

Trust systems can produce unusually high switching costs.

A business changing verification providers may have to:

• re-verify millions of customers;
• modify APIs;
• rebuild compliance systems;
• retrain fraud models;
• obtain regulatory approvals;
• migrate historical data;
• renegotiate contracts;
• establish new audit processes.

Consequently, customers may remain with an inferior provider because switching is commercially dangerous.

This can protect dominance even without explicit exclusion.

19. Portability as a Competition Remedy

One possible remedy is verification-data portability.

Customers could move:

• verification records;
• credentials;
• authentication history;
• business verification status;
• fraud indicators;

from one provider to another.

However, portability creates difficult issues involving:

• privacy;
• cybersecurity;
• accuracy;
• liability;
• data minimization;
• consent;
• fraud prevention.

A competition remedy therefore has to balance contestability against security.

20. Interoperability Remedies

Competition authorities may require a dominant provider to permit standardized interoperability.

For example:

Provider A credential ↔ Provider B verification system

rather than:

Provider A credential → Provider A ecosystem only

Interoperability can reduce:

• lock-in;
• switching costs;
• network-effect advantages;
• artificial exclusion.

But mandatory interoperability should generally be carefully designed so that security vulnerabilities are not introduced.

21. Transparency and Explainability

Where automated Trust APIs make economically significant decisions, competition regulation may also intersect with transparency requirements.

A system might provide:

Decision: Reject
Reason: Risk threshold exceeded
Evidence: Device/account mismatch
Review: Human appeal available

Greater transparency can make it easier for customers to compare competing providers.

Thus, explainability can contribute indirectly to market contestability.

22. Standardization and Competition

Open technical standards could prevent Trust APIs from becoming closed ecosystems.

Standards could establish common protocols for:

• credential exchange;
• verification requests;
• authentication;
• portability;
• revocation;
• auditing;
• cybersecurity.

But standardization itself can create competition concerns if dominant firms manipulate standards to exclude rivals.

Therefore:

Open standards can reduce centralized power, but standards governance can itself become a source of power.

23. The Risk of a “Trust Monopoly”

The most serious long-term scenario is not necessarily a conventional monopoly over a product.

It is a monopoly over recognition.

Imagine one provider becoming the principal system through which the global digital economy determines:

• who is a legitimate person;
• who is a legitimate business;
• which credentials are valid;
• which transactions are trustworthy;
• which devices are safe;
• which content is authentic.

The provider would not merely sell verification.

It could become an economic gatekeeper.

That produces a qualitatively different competition concern.

24. Global and Cross-Border Dimension

Trust APIs are inherently capable of operating across jurisdictions.

A multinational platform could use one centralized verification infrastructure for:

• India;
• EU;
• United States;
• United Kingdom;
• Singapore;
• Australia;
• Middle East;
• Africa.

This creates conflicts between different:

• privacy regimes;
• competition laws;
• cybersecurity requirements;
• identity standards;
• financial regulations;
• AI regulations.

A provider may therefore face simultaneous demands for:

centralization for security + decentralization for competition + localization for sovereignty.

25. Geopolitical Dimension

Trust infrastructure can also become strategically important.

Countries may become concerned that critical verification depends upon a foreign company.

This could generate:

• sovereign identity systems;
• domestic verification providers;
• regional trust frameworks;
• government-controlled credentials;
• competing digital-identity standards.

The global market could consequently fragment into competing trust blocs.

26. Competition Risks in AI-Based Trust APIs

AI increases the significance of these issues.

A future Trust API may independently assess:

“Is this person real?”
“Is this document authentic?”
“Is this transaction fraudulent?”
“Was this image AI-generated?”
“Is this business legitimate?”
“Should this account receive financial access?”

If one company controls the model, data and API, competitors may face a triple barrier:

Data barrier + model barrier + distribution barrier.

This could produce extremely durable market power.

27. Possible Abusive Strategies

A dominant Trust API provider could theoretically engage in:

1. discriminatory API access;
2. exclusionary licensing;
3. tying;
4. self-preferencing;
5. exclusive contracts;
6. refusal to interoperate;
7. discriminatory verification standards;
8. degrading competitors' API performance;
9. withholding interoperability information;
10. excessive switching costs;
11. discriminatory data access;
12. leveraging verification dominance into adjacent markets.

Each requires separate legal and economic analysis; dominance alone does not establish an infringement.

28. Possible Remedies

Competition authorities could consider:

Structural remedies

• separation of verification and downstream commercial services;
• divestiture in extreme circumstances.

Behavioral remedies

• nondiscriminatory API access;
• interoperability obligations;
• transparent technical standards;
• prohibition of self-preferencing;
• restrictions on exclusivity.

Data remedies

• portability;
• controlled data access;
• interoperability of verification credentials.

Governance remedies

• independent auditing;
• algorithmic accountability;
• appeal mechanisms;
• technical oversight.

Regulatory remedies

• designation as critical digital infrastructure;
• interoperability standards;
• multi-provider recognition frameworks.

29. Central Legal Question

The central competition-law question can therefore be formulated as:

When does a Trust API cease to be an ordinary technical service and become a commercially indispensable verification infrastructure through which a dominant undertaking can control access to downstream markets?

The answer should depend upon:

1. market definition;
2. dominance;
3. indispensability;
4. availability of alternatives;
5. network effects;
6. switching costs;
7. data advantages;
8. interoperability;
9. foreclosure effects;
10. objective justification;
11. consumer and security benefits.

30. Conclusion

Global Trust APIs represent an emerging form of digital infrastructure power. Their importance arises not simply from processing data but from their capacity to determine whether economic actors, transactions, credentials and digital objects are recognized as legitimate.

The competition-law risks are particularly significant where a provider combines:

identity data + verification algorithms + API infrastructure + network effects + regulatory recognition + downstream businesses.

At that point, the provider can potentially move from being a verification supplier to becoming a gatekeeper of economic participation.

The major case-law lessons from Microsoft, Bronner, IMS Health, Slovak Telekom, Google Shopping, Meta, Google Android and United Brands provide useful analytical foundations for examining this emerging phenomenon.