Competition Concerns in Accounting API Ecosystems

Introduction

An Accounting API ecosystem is a network in which accounting software, banks, payment providers, payroll platforms, tax systems, expense-management applications, auditors, financial-data aggregators, and third-party developers exchange information through application programming interfaces (APIs).

APIs can substantially improve competition by allowing businesses to move accounting data between providers and by enabling third-party applications to build services on top of accounting platforms. However, where one accounting platform controls a large installed customer base, the API may also become a strategic bottleneck. Competition concerns can arise if the platform restricts API access, discriminates between its own services and rivals, degrades interoperability, imposes unreasonable fees, or uses data obtained through API access to disadvantage competing applications.

The principal competition-law issues include:

1. API access discrimination;
2. refusal or restriction of interoperability;
3. self-preferencing;
4. tying and bundling;
5. excessive or discriminatory API fees;
6. data portability restrictions;
7. exclusive API arrangements;
8. use of competitors' commercially sensitive data;
9. interoperability degradation;
10. most-favoured-customer or parity provisions;
11. exclusionary certification or technical standards; and
12. acquisitions of complementary accounting or fintech applications.

I. Nature of an Accounting API Ecosystem

A typical ecosystem may look like:

Accounting Platform → API Layer → Third-Party Applications → Customers

For example, an accounting platform may provide APIs for:

• invoices;
• payroll;
• bank reconciliation;
• expense data;
• tax information;
• customer records;
• inventory;
• payments;
• financial statements;
• authentication;
• transaction categorisation.

The platform may therefore control both the underlying accounting data and the technical gateway through which competitors access that data.

This creates a potential competition problem where the API is indispensable or strategically important for competing downstream services.

II. Relevant Markets

Competition analysis generally begins with market definition.

Possible relevant markets include:

1. Accounting software market

Cloud-based accounting platforms may constitute a distinct market from traditional desktop accounting software where customers consider the products insufficiently substitutable.

2. Accounting API access market

In some circumstances, API access itself may become an economically significant input.

3. Financial-data aggregation

APIs can facilitate access to transaction and financial information for:

• banks;
• lenders;
• payment providers;
• expense platforms;
• financial-management applications.

4. Payroll and tax applications

An accounting platform may operate upstream while independent payroll or tax applications compete downstream.

5. Business-payment services

Accounting APIs increasingly connect:

accounting → invoicing → payment → reconciliation

This creates opportunities for foreclosure between adjacent markets.

III. Dominance and Market Power

Possession of an API does not automatically establish dominance.

Authorities may examine:

• market share;
• customer lock-in;
• switching costs;
• network effects;
• number of developers;
• data advantages;
• interoperability;
• API coverage;
• technical standards;
• barriers to migration;
• availability of alternative APIs;
• multi-homing;
• ecosystem dependence; and
• control over essential data.

An accounting platform can become particularly powerful where customers have accumulated years of financial records and changing providers involves substantial migration costs.

IV. API Access Discrimination

A platform may provide API access to competing applications on different terms.

For example:

The accounting platform gives its own expense application unlimited API access but imposes restrictive rate limits on competing expense applications.

This may constitute discriminatory treatment where the platform has substantial market power and the discrimination has exclusionary effects.

Relevant factors include:

• technical functionality;
• API rate limits;
• authentication requirements;
• approval procedures;
• access fees;
• data fields available;
• update frequency;
• latency;
• suspension policies; and
• certification requirements.

V. Self-Preferencing

A vertically integrated accounting platform may operate both:

• the accounting platform; and
• downstream applications.

It could theoretically use control of the API to favour its own downstream services.

Examples include:

• providing its own application with additional API fields;
• giving its own application earlier access to new functionality;
• ranking its own application more prominently;
• limiting rival applications' API calls;
• imposing higher fees on competitors;
• restricting competitors from accessing particular categories of data.

The competition concern is not simply that the platform competes with its API users. The issue is whether control of the infrastructure is being used to distort downstream competition.

VI. Refusal to Supply API Access

A refusal to provide API access can raise issues analogous to refusal-to-deal cases.

The analysis generally depends on circumstances such as:

1. whether the platform possesses substantial market power;
2. whether access is indispensable;
3. whether effective competition is impossible without access;
4. whether access can technically be supplied;
5. whether the refusal has exclusionary effects;
6. whether legitimate technical or security reasons exist; and
7. whether the platform previously supplied access.

A mere refusal by an ordinary business is generally not automatically unlawful.

VII. Degradation of Interoperability

Instead of completely refusing access, a platform might technically permit access while making it substantially less effective.

Examples include:

• slower API response times;
• incomplete data;
• delayed synchronisation;
• restrictive call quotas;
• frequent authentication resets;
• unexplained API outages;
• removal of previously available data fields.

This can be particularly important because formal API availability does not necessarily mean effective interoperability.

VIII. Data Portability and Switching Costs

Accounting information has substantial commercial value.

A customer may have:

• ten years of invoices;
• transaction histories;
• supplier information;
• tax records;
• payroll data;
• inventory information.

If the platform makes exporting that information difficult, customers may face significant switching costs.

Competition concerns can arise where portability restrictions:

• prevent customers from changing providers;
• inhibit multi-homing;
• increase competitor acquisition costs;
• reduce innovation; or
• reinforce incumbent market power.

IX. Tying and Bundling

An accounting platform could condition API access on purchasing another service.

For example:

Access to the accounting API is available only to customers who also purchase the platform's payment-processing service.

This could raise tying or bundling concerns where:

• two distinct products are involved;
• the undertaking has substantial power in the tying product;
• customers are effectively compelled to obtain the tied product; and
• the practice forecloses competing providers.

X. API Fees

API pricing may create competition concerns when a dominant platform imposes discriminatory or strategically excessive charges.

Possible structures include:

• per-API-call fees;
• per-customer fees;
• premium access charges;
• data-field charges;
• certification fees;
• developer subscription fees.

Particular scrutiny may arise if:

the platform's own downstream service receives API access at zero cost while competing applications pay substantial fees.

The economic effect may be comparable to raising rivals' costs.

XI. Exclusive API Arrangements

An accounting platform might contractually restrict customers or developers from using competing systems.

Examples:

• exclusive integration agreements;
• restrictions on connecting alternative accounting systems;
• exclusivity with payment providers;
• exclusive payroll integrations;
• exclusive banking-data connections.

Such arrangements can be problematic where they prevent competitors from reaching a sufficiently large customer base.

XII. Use of Competitor Data

One particularly important ecosystem concern is the dual role of the platform.

Suppose independent applications connect to an accounting platform through its API. The platform may obtain information about:

• transaction volumes;
• customer preferences;
• pricing;
• product usage;
• invoice patterns;
• industry trends;
• competitors' application performance.

If the platform subsequently uses competitively sensitive information obtained through the ecosystem to compete against those applications, competition concerns may arise.

This issue is closely related to concerns examined in digital-platform competition cases.

XIII. Most-Favoured-Customer / Parity Clauses

Accounting platforms may impose provisions requiring users or integrated applications to provide:

• the same price;
• the same commercial terms;
• the same functionality;

across different distribution channels.

Such clauses can restrict competition by limiting the ability of rival platforms to compete through better commercial terms.

Their effects depend substantially on:

• scope;
• duration;
• market power;
• coverage;
• ability of customers to multi-home; and
• foreclosure effects.

XIV. Certification and Technical Standards

Platforms frequently impose developer certification requirements.

Legitimate certification can protect:

• cybersecurity;
• data integrity;
• privacy;
• reliability.

However, certification can become exclusionary if the platform:

• arbitrarily rejects competitors;
• delays approval;
• applies standards selectively;
• changes requirements without reasonable notice;
• gives its own applications preferential treatment.

Thus, security standards can be legitimate while discriminatory certification can raise competition concerns.

XV. Relevant Case Laws

Because accounting APIs are a relatively modern phenomenon, there are relatively few reported decisions specifically concerning "accounting APIs." The following cases provide important competition-law principles that can be applied by analogy to API ecosystems.

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

Court: U.S. Court of Appeals for the D.C. Circuit.

Microsoft involved the relationship between the Windows operating system and competing applications and browsers.

The court considered Microsoft's use of its control over a platform to restrict competitive threats and its conduct toward software developers.

Relevance to accounting APIs

An accounting platform could similarly occupy an upstream infrastructure position while competing with downstream applications.

The case is particularly relevant to:

• platform power;
• interoperability;
• exclusionary conduct;
• technical restrictions;
• leveraging infrastructure into adjacent markets.

Principle: Control over an important technological platform can become relevant to antitrust analysis when that control is used to disadvantage competing products.

2. Bronner v. Mediaprint (1998)

Court: Court of Justice of the European Union.

The case concerned access to a newspaper home-delivery distribution system.

The CJEU established stringent conditions for treating refusal to provide access to infrastructure as abusive.

Relevance

An accounting API could potentially be characterised as an important infrastructure only in appropriate circumstances.

The case is relevant to:

• refusal to deal;
• indispensable facilities;
• alternative access;
• objective justification.

Principle: A refusal to provide access does not automatically constitute abuse; the stringent conditions applicable to refusal-to-supply cases must be satisfied.

3. IMS Health GmbH & Co. OHG v NDC Health GmbH (2004)

Court: CJEU.

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

The case is particularly significant for technology and data-driven industries.

Relevance to accounting APIs

Accounting ecosystems can involve proprietary:

• data structures;
• databases;
• identifiers;
• software architectures.

The case provides a framework for analysing when refusal to license or provide access to an important technical structure may raise Article 102 concerns.

Principle: Exceptional circumstances may justify compulsory access to protected infrastructure or information where the refusal would eliminate effective competition and other stringent conditions are satisfied.

4. Microsoft Corp. v Commission (2007)

Court: General Court of the European Union.

The European Commission found that Microsoft had abused its dominant position through, among other things, restrictions concerning interoperability information.

The decision is particularly relevant to interoperability.

Relevance to accounting APIs

API ecosystems similarly depend upon competitors being able to interoperate with a dominant platform.

Relevant concerns include:

• withholding interoperability information;
• technical restrictions;
• compatibility;
• downstream foreclosure.

Principle: Interoperability restrictions imposed by a dominant technology platform can constitute an abuse where the applicable legal conditions are established.

5. Google Shopping (Google Search (Shopping)) (2021)

Court: General Court of the European Union.

The case concerned Google's preferential treatment of its comparison-shopping service within general search results.

Relevance to accounting APIs

The underlying concern can arise in an accounting ecosystem when a platform simultaneously:

1. controls an important infrastructure;
2. operates downstream services; and
3. uses that infrastructure to favour its own downstream offering.

Possible analogous conduct includes:

• preferential API access;
• preferential developer placement;
• privileged data fields;
• superior API functionality for the platform's own applications.

Principle: A dominant platform's conduct may be scrutinised where it uses control over a major platform to give preferential treatment to its own downstream service.

6. Slovak Telekom v Commission (2021)

Court: CJEU.

The case concerned access to telecommunications infrastructure and the conditions imposed on alternative operators.

Relevance

Telecommunications networks and accounting APIs are different technologies, but both can involve an upstream infrastructure controlled by an incumbent and downstream competitors requiring access.

The case is useful for analysing:

• access conditions;
• margin/foreclosure issues;
• infrastructure control;
• discriminatory or exclusionary access arrangements.

Principle: A dominant infrastructure operator can face competition-law scrutiny when its access conditions make effective downstream competition more difficult.

7. Deutsche Telekom v Commission (2010)

Court: CJEU.

The case concerned wholesale access to telecommunications infrastructure and the relationship between wholesale and retail pricing.

Relevance to accounting APIs

The economic concept can be relevant where an accounting platform:

• charges third parties for API access;
• competes downstream using the same infrastructure;
• structures access charges in a way that disadvantages equally efficient competitors.

It therefore provides an important framework for considering raising-rivals'-costs and margin-squeeze theories.

8. Servizio Elettrico Nazionale v Autorità Garante della Concorrenza e del Mercato (2022)

Court: CJEU.

The case addressed exclusionary conduct by a dominant undertaking and the assessment of competition on the merits.

Relevance

The decision is useful for distinguishing legitimate competition from conduct that exploits incumbent advantages to exclude competitors.

In an accounting API environment, evidence of:

• legitimate technical requirements;
• security concerns;
• efficiency improvements;

would therefore be relevant alongside evidence of exclusionary effects.

XVI. Indian Competition-Law Relevance

For an Indian accounting API ecosystem, the principal statutory framework is the Competition Act, 2002.

Potential provisions include:

Section 3

Section 3 concerns agreements that cause or are likely to cause an appreciable adverse effect on competition.

Potentially relevant arrangements include:

• API exclusivity;
• discriminatory integration agreements;
• restrictive developer agreements;
• tying arrangements;
• parity clauses.

Section 4

Section 4 concerns abuse of dominant position.

Potential theories may include:

• denial of market access;
• discriminatory conditions;
• discriminatory pricing;
• leveraging dominance into another market;
• tying;
• exclusionary API restrictions.

Section 5

Where acquisitions involve major accounting platforms, fintech applications, payment systems or data businesses, merger-control questions may arise depending upon the applicable thresholds and transaction circumstances.

XVII. Competition Concerns Matrix

XVIII. Objective Justifications

Not every restriction is anticompetitive.

An accounting platform may legitimately restrict API access because of:

• cybersecurity;
• fraud prevention;
• privacy obligations;
• data protection;
• system capacity;
• technical reliability;
• authentication requirements;
• financial regulation;
• prevention of unauthorised access.

The central issue is whether the restriction is genuinely necessary and proportionate to the legitimate objective or is being used as a mechanism to disadvantage competitors.

XIX. Evidence Relevant to an Investigation

Competition authorities may examine:

Technical evidence

• API documentation;
• source-code records;
• API logs;
• rate-limit configurations;
• authentication records;
• error rates;
• uptime statistics.

Commercial evidence

• API pricing schedules;
• developer contracts;
• exclusivity clauses;
• customer agreements;
• internal pricing documents.

Internal communications

Particularly relevant evidence may concern:

• competitor strategy;
• API restrictions;
• product launches;
• access decisions;
• developer certification.

Economic evidence

Authorities may examine:

• customer switching costs;
• foreclosure rates;
• API-dependent customer numbers;
• multi-homing;
• price effects;
• innovation effects;
• entry barriers.

XX. Possible Remedies

Where competition concerns are established, possible remedies may include:

1. non-discriminatory API access;
2. transparent API pricing;
3. interoperability obligations;
4. data-portability mechanisms;
5. prohibition of discriminatory rate limits;
6. fair certification procedures;
7. restrictions on misuse of competitor data;
8. contractual amendments;
9. monitoring obligations;
10. structural remedies in exceptional circumstances.

XXI. Key Legal Issues for Examination

A strong competition-law analysis of an accounting API dispute should ask:

Step 1 — Market:
What product and geographic market is affected?

Step 2 — Power:
Does the accounting platform possess substantial market power or dominance?

Step 3 — Conduct:
What precisely is the API restriction?

Step 4 — Discrimination:
Are similarly situated competitors treated differently?

Step 5 — Foreclosure:
Does the conduct materially restrict competitors' ability to compete?

Step 6 — Effects:
Are prices, quality, innovation, choice or interoperability affected?

Step 7 — Justification:
Is there a legitimate technical, security, privacy or regulatory justification?

Step 8 — Proportionality:
Could the legitimate objective be achieved through a less restrictive mechanism?

Conclusion

Accounting APIs can transform accounting software from a standalone product into a multi-sided ecosystem connecting financial data, banking, payments, payroll, taxation and business applications. This creates substantial efficiency benefits but also gives a powerful platform the ability to influence downstream competition.

The principal competition concerns are API denial, discriminatory access, self-preferencing, interoperability degradation, excessive or discriminatory API charges, tying, exclusivity, data exploitation and restrictive portability.

The leading cases such as Microsoft, Bronner, IMS Health, Microsoft (interoperability), Google Shopping, Slovak Telekom, Deutsche Telekom and Servizio Elettrico Nazionale do not concern an identical accounting-API fact pattern, but collectively provide important legal principles for analysing technology-platform access, interoperability, refusal to deal, discrimination and exclusionary conduct.

For an accounting API ecosystem, the decisive question is generally not simply whether the platform controls the API, but whether that control is being exercised in a manner that unlawfully restricts effective competition while lacking an adequate objective justification.