Competition Law and Process Automation Ecosystems and Competition

1. Introduction

Process automation ecosystems are technology environments in which business processes are automated through interconnected software, platforms, APIs, cloud infrastructure, workflow engines, robotic process automation (RPA), enterprise-resource-planning (ERP) systems, artificial intelligence, data analytics, identity systems, and third-party applications.

Examples include ecosystems used for:

• automated procurement and supply-chain management;
• robotic process automation;
• ERP and financial workflows;
• automated customer-service systems;
• cloud-based workflow platforms;
• low-code/no-code application development;
• AI-assisted business-process automation;
• automated compliance and risk management;
• API-based enterprise integration;
• digital payment and invoicing workflows.

Competition law becomes important because the provider controlling the automation layer can potentially control access to customers, data, APIs, applications, complementary services and downstream markets.

The principal competition concern is therefore not automation itself. The concern arises where an undertaking uses market power in one layer of an automation ecosystem to restrict competition in another layer.

2. Meaning of a Process Automation Ecosystem

A process automation ecosystem normally contains several interconnected layers:

Layer 1 – Infrastructure

Cloud computing, servers, storage and networking.

Layer 2 – Enterprise software

ERP, CRM, accounting, procurement and human-resource systems.

Layer 3 – Automation platform

Workflow engines, RPA platforms, orchestration software and low-code platforms.

Layer 4 – Data and APIs

Business data, APIs, connectors, databases and interoperability interfaces.

Layer 5 – Applications

Third-party applications that operate within the ecosystem.

Layer 6 – Users and customers

Businesses, public authorities and consumers relying upon automated processes.

Layer 7 – Complementary services

Consulting, implementation, cybersecurity, analytics, integration and managed services.

The greater the degree of interconnection, the greater the possibility that competition at one level will affect competition throughout the ecosystem.

3. Competition-Law Issues

The major competition questions include:

1. Market definition
2. Dominance
3. Bundling and tying
4. Self-preferencing
5. API restrictions
6. Interoperability restrictions
7. Data access
8. Exclusive dealing
9. Switching costs
10. Predatory pricing
11. Discriminatory access
12. Acquisitions of complementary automation firms
13. Algorithmic coordination
14. Foreclosure of competing automation providers

4. Relevant Markets

A process-automation ecosystem can involve several relevant markets.

For example:

Cloud infrastructure → enterprise software → automation platform → workflow applications → implementation services.

A competition authority may therefore examine whether the relevant market is:

• the entire enterprise-software market;
• RPA software;
• workflow-management software;
• low-code automation;
• cloud automation;
• procurement automation;
• API integration services; or
• a broader ecosystem.

The correct market definition depends upon substitutability, functionality, customer preferences, switching costs, interoperability and competitive constraints.

5. Dominance in Automation Ecosystems

Dominance can arise from:

• large installed customer bases;
• proprietary standards;
• network effects;
• extensive enterprise data;
• high switching costs;
• interoperability advantages;
• control over APIs;
• control over app stores;
• integration with operating systems;
• technological ecosystems;
• long-term enterprise contracts.

An automation provider does not necessarily have to possess an absolute monopoly.

A firm may possess substantial market power because customers are effectively dependent upon its ecosystem.

6. Tying and Bundling

One of the most important issues is tying.

Suppose an enterprise-software provider has a dominant ERP system and requires customers purchasing its ERP system to purchase its own automation software.

The competition question becomes whether the arrangement:

• forecloses competing automation providers;
• raises competitors' costs;
• reduces customer choice;
• increases switching costs; or
• protects the dominant firm's position in the automation market.

Bundling may be commercially efficient, however. Integration between ERP and automation software can reduce costs and improve functionality.

Therefore, competition law must distinguish legitimate product integration from exclusionary tying.

7. Interoperability and API Access

Automation depends heavily on interoperability.

A competing automation provider may require access to:

• APIs;
• authentication systems;
• databases;
• workflow interfaces;
• application connectors;
• metadata;
• event streams.

A dominant platform could potentially restrict such access.

For example:

ERP provider → refuses API access → independent automation provider cannot integrate → customers are encouraged to use the ERP provider's own automation tool.

This may raise an abuse-of-dominance issue where the relevant legal requirements for an access/refusal-to-deal theory are satisfied.

8. Data as a Competitive Advantage

Automation systems generate substantial amounts of:

• transaction data;
• customer data;
• workflow data;
• performance information;
• purchasing data;
• operational information;
• behavioural information.

Control over this information can create competitive advantages.

Competition concerns may arise if a dominant automation platform:

1. prevents customers from exporting data;
2. restricts interoperability;
3. uses customer data to compete against downstream firms;
4. gives its own applications privileged access;
5. combines data from multiple markets to strengthen dominance.

Data portability can consequently become an important competition remedy.

9. Self-Preferencing

A platform controlling an automation ecosystem may operate both:

• the platform itself; and
• competing applications within that platform.

It could potentially favour its own services through:

• search ranking;
• default settings;
• API priority;
• technical integration;
• data access;
• pricing;
• customer recommendations.

This creates a potential conflict between the platform's gatekeeper function and its competitive role.

10. Switching Costs and Lock-In

Automation systems are often deeply embedded in corporate operations.

A company may spend substantial amounts on:

• software implementation;
• employee training;
• workflow configuration;
• API integration;
• data migration;
• customized automation;
• cybersecurity integration.

Consequently, switching providers may be expensive.

A dominant provider could potentially exploit this dependence through:

• restrictive contracts;
• excessive termination fees;
• non-portable data;
• proprietary APIs;
• technical incompatibility;
• mandatory bundles.

Competition authorities therefore increasingly examine ecosystem lock-in rather than simply looking at market share.

11. Six Important Case Laws

Case 1 – United States v. Microsoft Corp., 253 F.3d 34 (D.C. Cir. 2001)

Facts

Microsoft possessed substantial power in the PC operating-system market and engaged in conduct concerning Internet Explorer and competing technologies.

Competition Issue

The case examined whether Microsoft had used its operating-system dominance to disadvantage competing products.

Principle

The case is particularly relevant to process automation ecosystems because it demonstrates how a dominant platform can potentially use control over a foundational technological layer to influence competition in adjacent markets.

Relevance to automation

An ERP, cloud or operating-system provider may similarly possess an important platform position and use technical integration or contractual restrictions affecting complementary automation products.

12. Case 2 – Microsoft Corp. v. Commission, Case T-201/04

Facts

The European Commission found Microsoft liable for abuse of dominance involving, among other things, interoperability information and tying.

Competition Issue

Microsoft had restricted access to interoperability information needed by competing work-group server products.

Principle

The case established important principles concerning:

• interoperability;
• refusal to supply;
• technological ecosystems;
• tying;
• leveraging of dominance.

Relevance

Process automation depends on interoperability between enterprise systems.

A dominant ERP or cloud platform restricting interoperability information could therefore create competition concerns under circumstances comparable to the issues examined in Microsoft.

13. Case 3 – Google Android, Google and Alphabet v Commission, Case T-604/18

Facts

The European Commission examined Google's conduct concerning the Android ecosystem.

The case involved arrangements concerning:

• Google Search;
• Google Chrome;
• Google Play Store;
• Android devices;
• licensing arrangements;
• anti-fragmentation requirements.

Competition Issue

The central issue concerned the use of Google's position in one part of the ecosystem to strengthen its position in related markets.

Principle

The case illustrates the importance of analysing ecosystem leverage rather than examining individual products in isolation.

Relevance to automation

A dominant enterprise platform could potentially leverage its position in:

ERP → workflow → automation → applications

to strengthen its position in adjacent markets.

14. Case 4 – Google Search (Shopping), Case AT.39740

Facts

The European Commission found that Google had favoured its own comparison-shopping service in search results while competing comparison-shopping services were disadvantaged.

Competition Issue

The case concerned preferential treatment of the dominant platform's own downstream service.

Principle

A platform can create competition concerns where it controls an important gateway and uses that position to favour its own downstream offering.

Relevance

The same conceptual problem can arise where an automation platform:

• controls an application marketplace;
• offers its own automation applications; and
• systematically gives those applications preferential visibility or access.

The legal assessment, however, depends on the specific market structure and conduct.

15. Case 5 – FTC v. Qualcomm Inc., 969 F.3d 974 (9th Cir. 2020)

Facts

The case concerned Qualcomm's licensing practices and its position in cellular modem technology.

The Ninth Circuit ultimately reversed the district court's finding of liability under the Sherman Act.

Competition Issue

The case examined the relationship between:

• technological standards;
• licensing;
• intellectual property;
• market power;
• supply relationships.

Principle

Possessing control over an important technological input does not automatically establish an antitrust violation.

The precise legal requirements for an exclusionary-conduct claim must be satisfied.

Relevance

This is important for automation ecosystems because control over APIs, proprietary technology or interoperability interfaces does not automatically make conduct unlawful.

Competition analysis must distinguish legitimate technological design from exclusionary conduct.

16. Case 6 – Aspen Skiing Co. v. Aspen Highlands Skiing Corp., 472 U.S. 585 (1985)

Facts

Four major ski areas historically participated in a joint ticketing arrangement. Aspen Skiing eventually terminated cooperation with Aspen Highlands.

Competition Issue

The Supreme Court examined whether the termination of a previously profitable course of dealing could constitute exclusionary conduct.

Principle

The case is an important U.S. authority concerning refusal to deal and exclusionary conduct.

Relevance

It is potentially relevant to automation ecosystems where a dominant platform:

• previously provided interoperability;
• previously allowed access;
• subsequently withdraws that access; and
• thereby disadvantages competing automation providers.

However, Aspen Skiing is a fact-specific precedent and should not be interpreted as creating a general duty for dominant firms to deal with competitors.

17. Additional Important Authority – Bronner

Oscar Bronner GmbH & Co. KG v. Mediaprint, Case C-7/97

The Court of Justice considered the circumstances in which a dominant undertaking's refusal to provide access to an infrastructure could constitute abuse.

The case is particularly relevant to automation ecosystems because it addresses the difficult distinction between:

competition on the merits

and

exclusion through denial of access to indispensable infrastructure.

The strict conditions associated with the essential-facilities/refusal-to-supply doctrine are important when analysing API or platform-access disputes.

18. Additional Authority – Slovak Telekom

Slovak Telekom a.s. v European Commission, Joined Cases C-165/19 P and C-166/19 P

The case concerned access to telecommunications infrastructure and exclusionary conduct.

It is relevant by analogy because modern automation platforms can similarly become critical technological infrastructure for downstream businesses.

The case illustrates the importance of examining:

• access conditions;
• pricing;
• foreclosure;
• infrastructure control;
• effects on downstream competitors.

19. Competition Problems Specific to RPA Ecosystems

Robotic Process Automation can create particularly interesting competition issues.

A dominant RPA platform might:

• restrict third-party bots;
• charge discriminatory API fees;
• prevent interoperability with competing RPA systems;
• bundle RPA with ERP software;
• acquire competing automation applications;
• restrict portability of automation scripts;
• make workflows dependent on proprietary technologies.

The competition analysis should examine both market power and actual or likely foreclosure effects.

20. Low-Code/No-Code Platforms

Low-code platforms allow businesses to build applications without extensive programming.

Competition concerns may arise where a platform:

• controls the development environment;
• controls application distribution;
• owns the underlying cloud infrastructure;
• operates competing applications;
• controls APIs;
• imposes discriminatory technical conditions.

A particularly important question is whether customers can migrate applications and workflows to competing platforms.

21. Automated Procurement Platforms

Automation platforms can also operate procurement marketplaces.

A platform may simultaneously:

1. operate the procurement infrastructure;
2. collect purchasing data;
3. recommend suppliers;
4. provide automated pricing;
5. operate competing supplier businesses.

This creates potential conflicts of interest.

Competition authorities may examine:

• preferential ranking;
• discriminatory access;
• exclusionary contracts;
• information advantages;
• algorithmic coordination;
• supplier restrictions.

22. Algorithmic Collusion

Automation can facilitate coordination among competitors.

For example, competing firms might use pricing algorithms capable of:

• monitoring competitors;
• responding automatically to price changes;
• maintaining prices above competitive levels.

There are two broad scenarios:

Explicit coordination

Competitors intentionally design algorithms to implement an agreement.

Tacit algorithmic coordination

Algorithms independently respond to market conditions and may produce coordinated outcomes without a conventional explicit agreement.

The second situation presents difficult questions concerning proof of agreement, concerted practices and unilateral algorithmic behaviour.

23. Merger and Acquisition Issues

Process-automation ecosystems are highly susceptible to ecosystem acquisitions.

A large platform could acquire:

• an RPA provider;
• an API-management company;
• a workflow application;
• an integration provider;
• an AI automation startup;
• an enterprise-data company.

Even if the target has relatively low current revenue, the transaction may raise concerns where it eliminates an emerging competitive constraint.

Authorities may therefore consider:

• innovation competition;
• potential competition;
• data advantages;
• interoperability;
• ecosystem foreclosure;
• vertical integration;
• portfolio effects.

24. Vertical Foreclosure

Consider:

Cloud Provider
↓
ERP Platform
↓
Automation Platform
↓
Third-Party Applications

If the same company controls several levels, it could theoretically disadvantage rivals at another level.

Possible methods include:

• discriminatory API access;
• higher access charges;
• technical incompatibility;
• bundling;
• exclusive contracts;
• preferential ranking;
• delayed interoperability;
• restrictions on data portability.

The relevant question is whether such conduct actually or potentially forecloses competition.

25. Network Effects

Automation ecosystems can exhibit strong network effects.

More users may lead to:

• more developers;
• more integrations;
• more applications;
• more data;
• more consultants;
• greater compatibility.

This can create a feedback loop:

More users → more developers → more applications → more functionality → more users.

Once established, such a system can become difficult for new competitors to challenge.

Network effects are therefore relevant to assessing market power and barriers to entry.

26. Competition Between Ecosystems

Competition may occur not merely between individual software products but between entire ecosystems.

For example:

Ecosystem A

ERP + Cloud + RPA + AI + APIs + Marketplace

versus

Ecosystem B

ERP + Cloud + Workflow + AI + Integration tools.

Competition authorities may therefore need to determine whether consumers can realistically switch between ecosystems.

27. Consumer and Business Effects

Competition problems in process automation can produce:

Higher prices

Businesses may pay more for automation software.

Reduced innovation

Competitors may be discouraged from developing complementary products.

Reduced choice

Customers may have fewer automation providers.

Lower interoperability

Customers may be trapped within one ecosystem.

Increased switching costs

Migration to another provider becomes expensive.

Reduced quality

Dominant platforms may face weaker competitive pressure.

Data dependence

Customers may lose practical control over their operational data.

28. Efficiency Defences

Integration is not inherently anti-competitive.

A platform may legitimately argue that integration provides:

• improved security;
• better reliability;
• lower transaction costs;
• faster workflows;
• reduced duplication;
• improved cybersecurity;
• better AI performance;
• enhanced interoperability.

Competition law should therefore distinguish:

pro-competitive integration

from

exclusionary integration.

This distinction is particularly important for automation because integration is often the central source of its economic value.

29. Possible Competition-Law Remedies

Authorities may consider several remedies.

1. Interoperability obligations

Require access to necessary interfaces.

2. API access

Prevent unjustified discrimination in API access.

3. Data portability

Allow customers to export their data and workflows.

4. Non-discrimination

Require equivalent treatment of competing applications.

5. Separation of functions

In exceptional circumstances, structural separation may be considered.

6. Contractual remedies

Restrictions on exclusivity and anti-competitive contractual provisions.

7. Divestiture

Potentially appropriate in merger cases where behavioural remedies are insufficient.

8. Transparency

Require disclosure of relevant ranking or access criteria where legally appropriate.

30. Relationship with Digital Competition Regulation

Traditional competition law is increasingly supplemented by digital-platform regulation.

This is important because some ecosystem practices can be problematic even before conventional antitrust litigation establishes all elements of an abuse or anticompetitive agreement.

Digital regulation may impose obligations concerning:

• interoperability;
• data access;
• portability;
• self-preferencing;
• gatekeeper conduct;
• app distribution;
• switching.

Consequently, process-automation providers operating as major digital platforms may face both competition-law and ex ante regulatory obligations.

31. Six Core Case-Law Principles at a Glance

32. Analytical Framework

A competition authority examining a process-automation ecosystem can follow this sequence:

Step 1 – Identify the ecosystem

↓

Step 2 – Identify the relevant markets

↓

Step 3 – Determine market power

↓

Step 4 – Identify the controlled technological input

APIs / data / cloud / ERP / workflow / marketplace

↓

Step 5 – Identify the conduct

Tying / bundling / exclusion / discrimination / self-preferencing / refusal to supply

↓

Step 6 – Examine foreclosure

Are competing automation providers disadvantaged?

↓

Step 7 – Examine efficiencies

Security / integration / quality / innovation / cost reduction

↓

Step 8 – Assess competitive effects

Price / quality / innovation / choice / entry

↓

Step 9 – Consider remedies

Interoperability / portability / non-discrimination / behavioural or structural remedies.

33. Conclusion

Competition law and process automation ecosystems intersect primarily through the control of technological gateways. An automation provider that controls ERP systems, cloud infrastructure, APIs, workflow platforms, data or application marketplaces may possess significant strategic advantages over downstream competitors.

The principal competition concerns are tying, bundling, self-preferencing, refusal of interoperability, discriminatory API access, data advantages, exclusive dealing, ecosystem lock-in, algorithmic coordination and acquisitions of potential competitors.

The Microsoft, Google Android, Google Shopping, Qualcomm, Aspen Skiing, Bronner and Slovak Telekom authorities demonstrate different aspects of the broader legal problem: competition law must examine whether technological integration and ecosystem control are being used to compete on the merits or to exclude competing products and technologies.