Competition Law and Governance of Computational Planning Ecosystems

1. Introduction

A computational planning ecosystem is a market environment in which businesses use software, algorithms, artificial intelligence, predictive analytics, optimisation tools, digital twins, automated forecasting, enterprise-resource-planning systems, supply-chain platforms, or shared data infrastructures to plan commercial decisions.

These systems may determine or assist with:

• production quantities;
• inventory levels;
• procurement;
• logistics and routing;
• capacity allocation;
• demand forecasting;
• workforce allocation;
• pricing and discounts;
• supplier selection;
• delivery schedules;
• investment and capacity expansion;
• customer segmentation; and
• responses to competitors.

Computational planning is not inherently anti-competitive. Indeed, it can substantially improve efficiency. The competition-law problem arises where computational planning reduces independent commercial decision-making, facilitates coordination between competitors, creates exclusionary bottlenecks, or enables a dominant undertaking to use data and algorithms to disadvantage rivals.

The central competition-law question is therefore:

When does computational coordination cease to be legitimate independent planning and become a mechanism for restricting competition?

2. Meaning of a Computational Planning Ecosystem

A computational planning ecosystem normally contains five interconnected layers.

A. Data layer

The system collects:

• historical sales data;
• customer information;
• competitor information;
• inventory data;
• capacity data;
• transportation information;
• supplier information;
• market forecasts; and
• real-time demand signals.

B. Computational layer

Algorithms transform data into predictions or recommendations.

Examples include:

• demand forecasting;
• machine-learning prediction;
• optimisation algorithms;
• dynamic pricing;
• capacity optimisation;
• route optimisation; and
• production scheduling.

C. Decision layer

The software recommends or automatically determines:

• what to produce;
• how much to produce;
• where to sell;
• when to replenish;
• what price to charge;
• which suppliers to use; and
• which customers to prioritise.

D. Infrastructure layer

The system may operate through:

• cloud computing;
• ERP systems;
• industry platforms;
• procurement exchanges;
• logistics networks;
• APIs;
• shared databases; and
• industry-wide software.

E. Governance layer

The ecosystem determines:

• who can access the data;
• who controls the algorithm;
• how the algorithm is trained;
• which variables are included;
• whether competitors share information;
• how recommendations are implemented; and
• whether participants can independently modify decisions.

3. Competition-Law Significance

Traditional competition law generally assumes that competitors make independent commercial decisions.

Computational planning can challenge this assumption.

For example:

Competitor A → uploads inventory data
Competitor B → uploads inventory data
Shared platform → predicts market demand
Algorithm → recommends production levels
Participants → follow recommendations

Even if the competitors never directly communicate with one another, the computational architecture may potentially facilitate coordinated behaviour.

The same technology can also create unilateral exclusion.

For example:

Dominant platform → controls planning data
↓
Rivals require access to the data
↓
Dominant platform restricts API access
↓
Rivals cannot compete effectively

Thus, computational planning creates both Article 101/Section 1-type coordination issues and Article 102/Section 2-type unilateral-conduct issues, depending on the jurisdiction.

4. Principal Competition Concerns

A. Algorithmic Collusion

One of the most important concerns is the use of algorithms to facilitate coordination.

Suppose competing manufacturers independently use the same optimisation software.

The software may observe market prices and repeatedly recommend similar prices.

The resulting market may exhibit:

• parallel pricing;
• reduced price competition;
• stable market shares;
• rapid retaliation against deviations; and
• unusually predictable market behaviour.

Parallel outcomes alone do not necessarily establish an infringement. Competition authorities generally need to examine the mechanism producing the coordination.

5. Algorithmic Facilitation of Human Collusion

The problem becomes considerably stronger where human competitors deliberately use computational systems to implement an agreement.

For example:

1. Competitors agree to maintain minimum prices.
2. They appoint a common software provider.
3. The software monitors market prices.
4. The algorithm automatically detects deviations.
5. Prices are adjusted automatically.

The algorithm is then not merely an independent planning instrument.

It is potentially an implementation mechanism for an underlying cartel.

6. Information Exchange

Computational planning systems can transform ordinary business information into a mechanism of coordination.

Sensitive information can include:

• future prices;
• future production;
• capacity utilisation;
• inventory;
• margins;
• customer allocation;
• bidding strategies;
• procurement plans; and
• future investment.

The risk is especially significant where information is:

• commercially sensitive;
• non-public;
• individualised;
• forward-looking;
• frequently updated; and
• accessible to competing firms.

Example

If ten competitors provide future production plans to a common planning platform and the platform returns competitor-specific forecasts, each participant may obtain information that it could not ordinarily obtain from the market.

The system can therefore reduce strategic uncertainty.

7. Coordinated Forecasting

Forecasting itself is normally legitimate.

A problem may arise where competitors jointly develop forecasts that effectively disclose:

"Competitor X intends to produce 100,000 units next quarter."

Such information may influence competitors' own production decisions.

Consequently, competition-law analysis should distinguish between:

Legitimate forecasting

Aggregated, historical and sufficiently anonymised market information.

Potentially problematic forecasting

Individualised, current or future-sensitive information capable of influencing competitors' strategic decisions.

8. Common Algorithm Providers

A particularly important issue is the role of common software providers.

Imagine competing firms A, B and C all use the same algorithm supplied by Provider X.

The algorithm receives:

• prices from A;
• prices from B;
• prices from C;
• inventory information;
• demand information.

If Provider X's algorithm recommends coordinated commercial behaviour, competition authorities may examine:

• the contractual arrangements;
• information flows;
• algorithm design;
• instructions supplied to the provider;
• whether firms knew the system's operation;
• whether firms could independently override recommendations; and
• whether the system was deliberately designed to facilitate coordination.

9. Hub-and-Spoke Computational Planning

Computational ecosystems can create a hub-and-spoke structure.

Structure

Hub

Common platform / software provider

↓

Spoke A
Spoke B
Spoke C

The competitors are the spokes.

The hub receives information from each participant and may transmit information or recommendations affecting the behaviour of the others.

The traditional hub-and-spoke doctrine therefore becomes increasingly relevant to digital planning systems.

10. Dominance and Computational Planning

Computational planning can also generate abuse-of-dominance concerns.

A dominant undertaking may control:

• essential datasets;
• planning software;
• industry APIs;
• cloud infrastructure;
• optimisation technology;
• logistics networks;
• procurement platforms; or
• interoperability standards.

It may then use that control to disadvantage competitors.

Possible conduct includes:

• discriminatory API access;
• refusal to provide interoperability;
• discriminatory data access;
• tying;
• self-preferencing;
• exclusionary licensing;
• predatory access conditions;
• discriminatory algorithms; and
• degradation of rival compatibility.

11. Data as a Competitive Bottleneck

A planning algorithm is only as good as its data.

A dominant undertaking may possess uniquely valuable:

• historical transaction data;
• customer demand data;
• logistics information;
• real-time inventory data;
• supplier performance information; or
• behavioural data.

If rivals cannot realistically reproduce that dataset, the data may become a competitive bottleneck.

Competition authorities may therefore examine whether denial or discriminatory access to the data:

1. excludes competitors;
2. protects the dominant undertaking's downstream business;
3. prevents innovation;
4. raises rivals' costs; or
5. limits interoperability.

12. Self-Preferencing in Computational Planning

Suppose a dominant logistics platform operates both:

• the planning infrastructure; and
• its own logistics business.

Its algorithm might allocate scarce delivery capacity.

If the algorithm systematically gives preferential access to the platform's own logistics division, competing logistics companies may be disadvantaged.

The relevant competition question is not simply:

"Is the algorithm efficient?"

It is:

"Does the algorithm apply objectively determined criteria, or does the dominant undertaking manipulate the computational system to exclude rivals?"

13. Computational Planning and Vertical Restraints

Planning ecosystems may also create vertical competition issues.

For example, a manufacturer may require distributors to use a particular planning platform.

The platform could determine:

• inventory;
• pricing;
• customer allocation;
• promotional strategy; and
• ordering.

If the manufacturer makes access to the product conditional on using its proprietary ecosystem, competition authorities may examine:

• tying;
• exclusive dealing;
• foreclosure;
• interoperability restrictions;
• resale-price effects; and
• switching costs.

14. Interoperability

Interoperability is particularly important.

Suppose a dominant planning system communicates with:

• suppliers;
• distributors;
• logistics providers;
• retailers; and
• payment systems.

If competitors cannot connect to that ecosystem, network effects may reinforce the dominant firm's position.

Competition-law analysis may therefore consider:

• API availability;
• technical standards;
• data portability;
• compatibility;
• switching costs;
• interoperability fees; and
• technical degradation.

15. Six Important Case Laws

1. Eturas v Lietuvos Respublikos Konkurencijos Taryba — CJEU

Principle

The Eturas case is highly relevant to computational coordination.

The case concerned an online travel-booking system through which a common platform operator transmitted a message restricting the maximum discounts that participating travel agencies could provide.

The issue was whether participants could be held responsible where the platform transmitted information capable of coordinating their conduct.

Significance for computational planning

The case demonstrates that a digital platform can become the mechanism through which competitors receive commercially significant information.

Important lessons include:

• electronic communications can facilitate coordination;
• competitors' knowledge of an anticompetitive platform instruction matters;
• participation in a common digital system does not automatically establish liability;
• knowledge and conduct must be assessed carefully; and
• algorithmic/platform architecture can have traditional cartel-law consequences.

Relevance: Particularly important for shared planning, pricing and optimisation platforms.

2. United States v. Topkins

Background

The U.S. Department of Justice prosecuted participants in an online poster-market cartel.

The defendants used algorithms to implement an agreement concerning prices.

Principle

The case illustrates that an algorithm does not immunise conduct from cartel law.

If competitors agree to coordinate prices and use software to implement that agreement, the underlying conduct remains potentially cartel conduct.

Computational significance

The case establishes an important conceptual distinction:

Algorithmic implementation does not transform an unlawful agreement into lawful independent conduct.

Therefore:

Human agreement + algorithmic implementation = potentially conventional cartel liability.

3. In re RealPage, Inc. Rental Software Antitrust Litigation — United States

Background

RealPage-related litigation has raised questions concerning the use of common algorithmic pricing systems by landlords.

The allegations concern landlords supplying information to a common software system and using algorithmically generated rental recommendations.

Competition significance

The dispute illustrates the increasingly important question of whether a common algorithm can facilitate coordination between market participants.

Relevant considerations include:

• common software;
• common data inputs;
• exchange of commercially sensitive information;
• algorithmic recommendations;
• implementation of recommendations; and
• whether participants retain genuine independent decision-making.

Broader principle

The RealPage controversy demonstrates that competition authorities and courts increasingly need to analyse the architecture of algorithmic decision-making, rather than merely looking for traditional face-to-face cartel meetings.

4. FTC v. Amazon.com, Inc. — United States

The FTC's case against Amazon involves broader alleged exclusionary conduct in digital commerce rather than being exclusively a computational-planning case.

Nevertheless, it is relevant to computational ecosystems because modern platforms can combine:

• marketplace data;
• seller information;
• pricing systems;
• inventory information;
• recommendation systems; and
• platform rules.

Significance

The case illustrates how competition analysis increasingly focuses on the interaction between:

• platform governance;
• data;
• algorithms;
• marketplace access; and
• vertical relationships.

It demonstrates that a computational ecosystem may create competition concerns even without an explicit agreement between competitors.

5. Google Shopping — European Commission / General Court

Background

The European Commission found that Google had abused its dominant position by systematically giving prominent placement to its own comparison-shopping service while demoting competing comparison-shopping services.

The EU courts subsequently considered the Commission's findings.

Relevance

Although Google Shopping was not a conventional "planning algorithm" case, it is important for understanding algorithmic governance by a dominant platform.

The central concern was the use of an algorithmic system in a manner that allegedly disadvantaged competing services.

Computational-planning lesson

Where a dominant undertaking controls a computational infrastructure, competition analysis may examine:

• ranking;
• allocation;
• visibility;
• access;
• self-preferencing; and
• discriminatory treatment.

Thus, computational decision-making can become an instrument of exclusion.

6. Microsoft — European Commission / General Court

Microsoft competition proceedings provide important principles concerning:

• interoperability;
• tying;
• technological integration;
• access to information; and
• leveraging of market power.

The interoperability component is particularly relevant to computational planning ecosystems.

Significance

Modern planning ecosystems frequently depend on interoperability between:

• enterprise software;
• operating systems;
• cloud services;
• databases;
• APIs; and
• competing applications.

Control over technical interoperability can therefore become a competition-law issue.

16. Indian Competition-Law Perspective

India's Competition Act, 2002 is particularly relevant to computational planning ecosystems through:

• Section 3 — anti-competitive agreements;
• Section 4 — abuse of dominant position;
• Section 5 — combinations;
• Section 6 — regulation of combinations;
• Section 19 — information and investigation;
• Section 26 — investigation procedure; and
• Sections 27 and 28 — remedial powers.

The CCI can therefore approach computational planning through both agreement-based and dominance-based theories.

17. Samir Agarwal v. Competition Commission of India

The Supreme Court's decision concerning the cab-aggregator ecosystem is particularly relevant to algorithmic markets.

The litigation involved questions concerning pricing and the relationship between platform participants and algorithmically determined fares.

Importance

The case demonstrates the difficulty of applying conventional competition-law concepts to:

• platform workers;
• algorithmic pricing;
• network markets; and
• multi-sided platforms.

For computational planning ecosystems, the case reinforces the importance of determining:

1. who is actually making the commercial decision;
2. whether participants are independent competitors;
3. how the platform's algorithm operates; and
4. whether the algorithm facilitates coordination or simply provides an independent service.

18. Shamsher Kataria v. Honda Siel Cars India Ltd.

The CCI's automobile-sector decision concerned restrictions affecting the aftermarket for automobile repair and spare parts.

Computational relevance

Modern automotive ecosystems increasingly involve:

• diagnostic software;
• proprietary repair information;
• telematics;
• software updates;
• vehicle data;
• digital service platforms.

The broader competition-law principle is that control over a technologically important input can affect downstream competition.

A computational planning ecosystem may therefore raise similar concerns where independent repairers or suppliers cannot obtain necessary digital information.

19. Competition Analysis of Computational Planning: A Framework

Competition authorities should examine the ecosystem in stages.

Stage 1 — Identify the market

Determine:

• product market;
• geographic market;
• upstream/downstream markets;
• platform markets;
• data markets; and
• technology markets.

Stage 2 — Identify computational control

Ask:

Who controls the algorithm?

Possible answers:

• individual undertaking;
• software provider;
• industry consortium;
• platform;
• dominant infrastructure provider.

Stage 3 — Examine data flows

Determine:

• what data enter the system;
• who owns the data;
• who can access the data;
• whether data are aggregated;
• whether data are anonymised;
• whether data are forward-looking; and
• whether competitors receive competitor-specific information.

Stage 4 — Examine outputs

Determine whether the system produces:

• prices;
• production recommendations;
• capacity allocations;
• customer allocation;
• inventory targets;
• bids;
• supplier rankings; or
• market forecasts.

Stage 5 — Examine independence

The crucial question is:

Do firms remain genuinely independent in their commercial decisions?

Factors may include:

• ability to reject recommendations;
• ability to modify algorithmic parameters;
• independent pricing policies;
• separate datasets;
• independent monitoring;
• independent commercial strategy.

20. Algorithmic Transparency

Competition governance does not necessarily require disclosure of the entire source code.

Instead, regulators may need access to:

• decision rules;
• input categories;
• output variables;
• training methodology;
• data flows;
• audit trails;
• override mechanisms;
• update history; and
• governance arrangements.

This is important because source code alone may not explain how an algorithm produces competitive effects.

21. Auditability

A computational planning ecosystem should maintain an algorithmic audit trail.

It should be possible to establish:

Data input → computational process → recommendation → human decision → commercial outcome.

For competition-law purposes, audit trails can help determine:

• whether competitors exchanged information;
• whether an algorithm generated coordinated recommendations;
• whether employees overrode the system;
• whether parameters were deliberately changed;
• whether discriminatory rules existed; and
• whether the system was designed to facilitate exclusion.

22. Compliance-by-Design

Competition compliance should be integrated into the design of the computational system.

Recommended controls

1. Data minimisation

Do not collect unnecessary competitor-sensitive information.

2. Aggregation

Use aggregated rather than firm-specific information wherever possible.

3. Anonymisation

Prevent identification of individual competitors.

4. Forward-looking information controls

Restrict access to future prices, production and strategic plans.

5. Independent parameter setting

Competitors should not jointly determine competitively sensitive algorithmic parameters.

6. Human override

Maintain meaningful independent commercial decision-making.

7. Audit logging

Preserve records of important algorithmic decisions.

8. Competition-law review

Conduct competition review before deploying industry-wide planning systems.

23. Governance of Shared Planning Platforms

Where several competitors use the same planning infrastructure, governance should address:

24. Computational Planning and Merger Control

Computational planning ecosystems can also affect merger analysis.

A merger may combine:

• two large datasets;
• competing optimisation systems;
• complementary AI models;
• logistics platforms;
• supply-chain software;
• customer forecasting data.

Potential concerns include:

Data concentration

The merged undertaking may possess an unusually comprehensive dataset.

Vertical foreclosure

The merged firm may restrict rival access to planning infrastructure.

Ecosystem effects

The merged company may control several interconnected layers.

Innovation effects

Competitors may lose access to data or technology necessary to develop alternative planning systems.

25. Computational Planning and Essential Facilities

Where a planning infrastructure becomes indispensable to competitors, an essential-facility/refusal-to-deal analysis may arise in jurisdictions recognising such doctrines.

Relevant factors may include:

1. indispensability;
2. absence of realistic alternatives;
3. inability to reproduce the infrastructure;
4. foreclosure of effective competition; and
5. objective justification for refusal.

However, mere usefulness or commercial importance does not automatically make a computational system an essential facility.

26. Network Effects

Computational planning systems frequently exhibit network effects.

More participants generate:

more data → better predictions → more users → more data.

This feedback loop can strengthen an incumbent.

The resulting competitive concern is sometimes described as a data-network-effect cycle.

A new competitor may therefore face a structural disadvantage even if it possesses equally sophisticated algorithms.

27. Switching Costs and Lock-In

Businesses may become dependent upon a planning ecosystem because they have invested in:

• employee training;
• APIs;
• databases;
• hardware;
• software integration;
• historical datasets; and
• customised workflows.

High switching costs may make customers reluctant to move to competing systems.

Competition authorities may therefore examine:

• contractual lock-ins;
• data portability;
• interoperability;
• exit fees;
• technical migration barriers; and
• exclusive arrangements.

28. Efficiency Defence

Computational planning frequently produces genuine efficiencies.

Examples include:

• lower transportation costs;
• reduced inventory;
• improved capacity utilisation;
• lower waste;
• better forecasting;
• reduced stock-outs;
• improved supply reliability.

Therefore, competition analysis should distinguish between:

Efficiency-enhancing coordination

and

Competition-restricting coordination.

The existence of sophisticated technology does not itself establish an infringement.

29. Key Distinction: Optimisation vs Coordination

This is perhaps the most important conceptual distinction.

Legitimate optimisation

Each competitor independently uses its own data and algorithm to maximise its own commercial interests.

Example:

Firm A's algorithm predicts demand and independently adjusts production.

Potentially problematic coordination

Competitors feed strategically sensitive information into a shared system that produces coordinated commercial recommendations.

Example:

Firms A, B and C provide future production plans to one platform, which recommends coordinated production levels.

The difference lies not simply in the existence of algorithms, but in the structure of information, governance and decision-making.

30. Emerging Competition-Law Risks

Future enforcement is likely to focus increasingly on:

1. Autonomous pricing

Algorithms independently adjusting prices in response to competitors.

2. Autonomous procurement

Systems identifying and responding to competitor purchasing behaviour.

3. AI forecasting

Competitor-specific predictive information.

4. Digital twins

Virtual representations of markets, factories or supply chains.

5. Industrial metaverse systems

Shared computational environments for production planning.

6. Cloud-based planning

Common infrastructure used by competing undertakings.

7. Foundation-model planning

General AI systems making commercial recommendations for multiple competitors.

8. Algorithmic supply allocation

AI determining scarce capacity among market participants.

31. Six Core Legal Principles Derived from the Case Law

The case law collectively supports several important principles:

1. Digital communications can facilitate traditional cartel conduct.
2. An algorithm cannot legalise an underlying unlawful agreement.
3. Common software can create competition-law risks where it reduces independent decision-making.
4. Dominant digital platforms can potentially abuse computational control to disadvantage competitors.
5. Interoperability and access to technological infrastructure can be competitively significant.
6. Data, algorithms and platform architecture must be assessed together rather than in isolation.

32. Compliance Model for Computational Planning Ecosystems

A robust compliance programme can be structured as follows:

DATA GOVERNANCE
↓
Identify competitively sensitive information
↓
ALGORITHM GOVERNANCE
↓
Review decision rules and parameters
↓
ACCESS GOVERNANCE
↓
Prevent discriminatory competitor access
↓
INDEPENDENCE GOVERNANCE
↓
Preserve independent commercial decisions
↓
AUDIT GOVERNANCE
↓
Maintain algorithmic logs
↓
COMPETITION MONITORING
↓
Detect unusual coordination patterns
↓
REMEDIAL GOVERNANCE
↓
Modify, suspend or redesign problematic mechanisms

33. Conclusion

Computational planning ecosystems represent a major evolution in the application of competition law. The fundamental issue is not whether businesses use algorithms, AI or sophisticated optimisation systems. Such technology can generate substantial efficiencies.

The competition-law concern arises where computational infrastructure:

• facilitates communication between competitors;
• exposes commercially sensitive information;
• replaces independent decision-making;
• enables algorithmic coordination;
• creates discriminatory access;
• strengthens a dominant bottleneck;
• forecloses competitors;
• creates technological lock-in; or
• combines data and infrastructure in ways that substantially reduce competitive constraints.

The emerging legal framework can therefore be understood through three principal questions:

Who controls the data?
Who controls the algorithm?
Do market participants remain independently capable of making competitive decisions?

The cases such as Eturas, Topkins, RealPage-related litigation, Google Shopping, Microsoft and Samir Agarwal demonstrate how traditional competition principles are being adapted to digital and algorithmic environments. The future governance challenge will be to preserve the efficiencies of computational planning while ensuring that computational infrastructure does not become an invisible mechanism for cartelisation, exclusion or concentration of market power.