Competition Law and Competition Implications of City Operating Systems

1. Introduction

A City Operating System (City OS) is a digital platform or integrated technological architecture through which multiple urban functions—such as transportation, electricity, water, waste management, public safety, parking, payments, healthcare, housing, environmental monitoring and municipal administration—are coordinated through common data, software, sensors, APIs, cloud infrastructure and artificial-intelligence systems.

A City OS may therefore function as a digital infrastructure layer for an entire city. It can connect:

• municipal authorities;
• transport operators;
• utility providers;
• telecommunications companies;
• mobility platforms;
• payment providers;
• smart-building operators;
• cloud providers;
• mapping and navigation services;
• developers and application providers;
• citizens and businesses.

From a competition-law perspective, the principal concern is that control over the City's digital infrastructure can create bottleneck power. A City OS operator may simultaneously control infrastructure, data, interfaces, authentication, applications and access conditions.

The competition question is consequently not simply whether the City OS is a monopoly. It is whether control over a critical urban digital ecosystem enables exclusion, discrimination, tying, self-preferencing, foreclosure, exploitative conduct, collusion or consolidation of adjacent markets.

The discussion below uses established competition-law principles and cases involving digital platforms, essential facilities, interoperability, tying, data and network effects. The cases are particularly relevant because there is still relatively limited reported case law specifically labelled "City OS."

2. Meaning and Characteristics of a City Operating System

A City OS generally contains several interconnected layers.

A. Physical infrastructure

Examples include:

• IoT sensors;
• cameras;
• traffic systems;
• smart meters;
• charging infrastructure;
• telecommunications networks;
• public Wi-Fi;
• municipal data centres.

B. Data layer

The system may aggregate:

• traffic data;
• mobility data;
• energy consumption;
• environmental information;
• geographic data;
• payment data;
• public-service usage;
• building data.

C. Platform layer

This may provide:

• APIs;
• identity and authentication;
• cloud services;
• data exchanges;
• application interfaces;
• interoperability standards.

D. Application layer

Applications may cover:

• parking;
• public transport;
• emergency services;
• waste collection;
• energy management;
• healthcare;
• citizen services;
• payments.

E. Artificial-intelligence layer

AI can be used for:

• traffic prediction;
• congestion management;
• demand forecasting;
• dynamic pricing;
• infrastructure maintenance;
• resource allocation;
• fraud detection.

The integration of these layers creates substantial network effects and economies of scope.

3. Competition-Law Risks Created by City Operating Systems

3.1 Market Definition

The first question is identifying the relevant market.

A City OS can participate simultaneously in multiple markets:

1. urban data infrastructure;
2. cloud computing;
3. smart-city software;
4. transport-management systems;
5. digital payments;
6. mapping;
7. advertising;
8. energy-management software;
9. IoT connectivity;
10. municipal software;
11. application distribution.

The system may therefore have a multi-sided market structure.

For example:

City authority → City OS → developers → service providers → citizens

A competition authority may need to examine each side separately while also considering the relationships between them.

4. Dominance and Bottleneck Control

A City OS can acquire dominance because competitors may find it difficult to replicate the entire urban infrastructure.

Factors relevant to dominance include:

• control of critical infrastructure;
• network effects;
• switching costs;
• data advantages;
• interoperability;
• number of connected users;
• access to municipal contracts;
• technological standards;
• economies of scale;
• ecosystem effects.

The important distinction is between being large and abusing dominance.

A dominant City OS is not necessarily unlawful merely because it is successful. Competition concerns arise where its position is used to restrict competition in connected markets.

5. Essential-Facility Issues

This is one of the most important issues.

Suppose a City OS controls the only practical interface through which mobility companies can access:

• traffic information;
• parking data;
• charging locations;
• public transport information;
• municipal authentication.

If access is denied selectively to competing providers, the system can become an essential digital gateway.

Traditional essential-facilities jurisprudence has imposed demanding conditions for mandatory access. However, modern digital-platform jurisprudence increasingly focuses on interoperability and ecosystem characteristics.

6. Case Law

Case 1: Bronner v Mediaprint

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

The CJEU established the stringent conditions traditionally associated with compulsory access to infrastructure.

The case concerned access to a newspaper distribution system.

The essential-facilities approach requires consideration of whether:

1. the facility is indispensable;
2. there is no realistic alternative;
3. refusal eliminates effective competition; and
4. there is no objective justification.

Relevance to City OS

A City OS operator could argue that its infrastructure was created through substantial investment and that competitors should not automatically receive access.

Conversely, competitors could argue that:

• duplication is economically impractical;
• the infrastructure has become indispensable;
• access is necessary to compete in downstream urban services.

Bronner therefore remains important for determining the limits of compulsory access.

7. Case 2: Magill

RTE and ITP v Commission, Joined Cases C-241/91 P and C-242/91 P

Magill concerned refusal to license television programme information.

The Court recognised circumstances in which refusal to provide access to information could constitute an abuse of dominance.

The traditional exceptional circumstances include:

• indispensability;
• elimination of effective competition;
• prevention of the emergence of a new product for which consumer demand exists;
• absence of objective justification.

City OS significance

A City OS could control unique datasets such as:

• real-time traffic information;
• parking information;
• integrated mobility data;
• infrastructure availability;
• environmental data.

If such information cannot reasonably be replicated, refusal to provide access could generate competition concerns.

8. Case 3: IMS Health

IMS Health GmbH & Co. OHG v NDC Health GmbH & Co. KG, Case C-418/01

The CJEU developed the exceptional-circumstances approach concerning intellectual property and access to infrastructure.

The case involved a pharmaceutical sales-data system.

Relevance

A City OS may have proprietary:

• data formats;
• APIs;
• software;
• databases;
• interoperability protocols;
• digital maps.

The operator cannot automatically be compelled to disclose everything simply because the material is commercially valuable.

However, where exceptional circumstances are established, refusal to provide access may constitute abusive conduct.

9. Case 4: Microsoft

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

Microsoft was found to have abused its dominant position through refusal to provide interoperability information.

The case is particularly important for City OS analysis because interoperability is central to urban digital ecosystems.

The Commission's concerns related to Microsoft's control over interoperability information necessary for competing work-group server products.

City OS application

A City OS could potentially restrict:

• API access;
• technical specifications;
• authentication;
• data portability;
• communication protocols.

For example, if a city platform permits its own parking application to access real-time municipal data but prevents rival parking applications from doing so, competition concerns could arise.

10. Case 5: Google Android

Google Android, Commission Decision AT.40099

The European Commission examined Google's practices involving Android, including restrictions affecting manufacturers and competing mobile services.

The case illustrates how a dominant platform can use:

• contractual restrictions;
• tying;
• default arrangements;
• ecosystem incentives

to strengthen its position across adjacent markets.

City OS significance

A City OS might similarly tie:

City OS + payment system + mapping + identity + mobility application

If municipalities or service providers are effectively required to use the platform operator's related services, competition may be weakened.

11. Case 6: Google Shopping

Google Search (Shopping), Case T-612/17; Google Shopping appeal, Case C-48/22 P

Google Shopping concerned the treatment of Google's comparison-shopping service within general search results.

The case is important for the concept of self-preferencing.

City OS application

Imagine a City OS operates a marketplace through which residents access:

• taxis;
• charging services;
• parking;
• food delivery;
• public transport;
• local commerce.

If the City OS gives its own affiliated services preferential access or ranking while disadvantaging rival providers, competition concerns may arise.

Possible forms include:

• preferential search ranking;
• privileged API access;
• better data access;
• lower transaction fees;
• preferential visibility;
• technical advantages.

12. Case 7: Slovak Telekom

Slovak Telekom a.s. v Commission, Case C-165/19 P

The case concerned access to telecommunications infrastructure and the circumstances in which refusal or restrictive conditions of access can amount to abuse.

The judgment is significant because the Court distinguished between situations involving genuinely proprietary infrastructure and circumstances where the dominant undertaking is already subject to access obligations.

City OS significance

Many City OS systems will operate within highly regulated municipal environments.

For example:

• public transport infrastructure;
• electricity networks;
• telecom infrastructure;
• public charging infrastructure

may already be subject to statutory access obligations.

Competition law can therefore interact with sector-specific regulation.

13. Case 8: Alphabet and Others — Android Auto

Alphabet and Others (Android Auto), Case C-233/23, EU:C:2025:110

This is particularly important for modern City OS analysis.

The CJEU held that refusal by a dominant digital-platform operator to ensure interoperability with a third-party application can constitute abuse even where the platform is not indispensable to the commercial operation of that application, where the platform was not developed solely for the dominant undertaking's own needs.

The case involved Google's Android Auto and Enel X's electric-vehicle charging application.

The Court recognised that the relevant issue could concern the ability of the platform to make the third-party application more attractive to consumers, rather than requiring absolute indispensability.

City OS significance

This has direct conceptual relevance to City OS.

A city platform might not be indispensable to a mobility application, yet interoperability with the City OS could substantially increase the application's attractiveness.

Examples:

• a parking application interoperating with municipal parking systems;
• a charging application appearing in the city's mobility interface;
• a public transport application accessing City OS journey data;
• a waste-management application connecting to municipal scheduling systems.

The judgment also recognises that technical development efforts may be required to achieve interoperability and that security or integrity considerations can provide objective justification in appropriate circumstances.

14. Network Effects

City OS markets can exhibit powerful direct and indirect network effects.

For example:

More citizens → more data → better services → more service providers → more citizens

This can produce a self-reinforcing ecosystem.

The problem is that once the platform becomes sufficiently large, competitors may face substantial barriers to entry.

Competition concerns

Potential effects include:

• tipping toward one platform;
• exclusion of competing platforms;
• reduced innovation;
• increased switching costs;
• dependence on one technical architecture.

15. Data Advantage

Data may constitute one of the most important competitive assets of a City OS.

The operator may possess enormous amounts of:

• mobility data;
• consumer behaviour data;
• energy data;
• geographic data;
• infrastructure data;
• commercial data.

This can generate a data feedback loop:

More users → more data → better algorithms → better services → more users.

Competitors may consequently find it difficult to reproduce the incumbent's capabilities.

However, possession of data alone does not automatically establish an antitrust violation. Competition authorities must examine the data's substitutability, indispensability, access conditions and competitive effects.

16. Data Discrimination

A City OS operator could potentially discriminate between:

Its own applications

and

Independent applications.

For example:

Such differential treatment may raise concerns under abuse-of-dominance rules.

17. Self-Preferencing

Self-preferencing occurs where a platform gives preferential treatment to its own downstream products or services.

A City OS could simultaneously operate:

• infrastructure;
• an application marketplace;
• payment services;
• mobility services.

The platform therefore has an incentive to favour its own downstream businesses.

Potential mechanisms include:

1. preferential ranking;
2. preferential API access;
3. preferential data access;
4. better technical functionality;
5. lower platform fees;
6. default placement.

The Google Shopping litigation provides an important analytical reference point.

18. Tying and Bundling

A City OS can potentially bundle several services:

Operating platform + cloud + identity + payments + mapping + analytics

A dominant provider could make access to one service conditional upon purchasing another.

For example:

Access to municipal traffic data → mandatory use of operator's analytics platform.

Or:

Access to city payment infrastructure → mandatory use of operator's identity system.

Such practices may raise tying or bundling concerns where the legal requirements for an abuse are satisfied.

19. Exclusive Dealing

City authorities may enter long-term contracts with a single City OS provider.

Exclusive arrangements can generate legitimate efficiencies because urban infrastructure requires:

• interoperability;
• security;
• reliability;
• investment certainty.

But lengthy exclusivity can also create foreclosure if competitors are prevented from entering or expanding.

The analysis should consider:

• duration;
• market coverage;
• switching possibilities;
• alternative infrastructure;
• procurement structure;
• investment requirements.

20. Interoperability

Interoperability is arguably the central competition-law issue for City Operating Systems.

A competitive City OS should potentially allow appropriately designed interaction between:

• transport applications;
• utility systems;
• payment systems;
• mobility platforms;
• municipal databases;
• private service providers.

A refusal to interoperate may raise competition concerns particularly where the platform is designed to accommodate third-party participation.

The Android Auto judgment is especially significant because it recognises that interoperability may be competition-relevant even where access is not strictly indispensable.

21. APIs as Competition Infrastructure

APIs can effectively become the digital roads connecting businesses to the city.

Control over APIs allows a City OS operator to determine:

• who can connect;
• what data can be accessed;
• how frequently it can be accessed;
• whether access is paid;
• technical requirements;
• authentication standards.

Therefore, discriminatory API access can become analogous to discriminatory physical infrastructure access.

22. Switching Costs and Lock-In

City governments generally face significant switching costs.

Once a city adopts one City OS, it may become dependent on:

• proprietary databases;
• software architecture;
• trained personnel;
• APIs;
• cloud infrastructure;
• connected sensors;
• technical standards.

A competitor may therefore technically exist but remain commercially unable to enter.

Competition analysis should consider whether the system permits:

• data portability;
• API portability;
• migration;
• interoperability;
• multi-cloud deployment;
• modular procurement.

23. Predatory Pricing and Cross-Subsidisation

A dominant City OS could potentially provide its core platform at very low prices while recovering losses through adjacent markets.

For example:

Free municipal platform → monetisation through advertising, payments and mobility.

Low prices are not automatically anticompetitive.

The relevant question is whether pricing behaviour satisfies the applicable legal tests for predatory conduct or whether cross-subsidisation creates exclusionary effects.

24. Algorithmic Coordination

City OS infrastructure may employ algorithms for:

• congestion pricing;
• parking prices;
• electricity prices;
• public transport pricing;
• ride-hailing;
• charging prices.

Where competing businesses use a common algorithm, the technology could facilitate coordination.

For example:

Multiple competing parking operators → same pricing algorithm → parallel prices.

Competition authorities may therefore need to examine:

• algorithm design;
• input data;
• communications between competitors;
• contractual arrangements;
• common ownership;
• intentional coordination.

The presence of an algorithm alone does not establish a cartel.

25. Dynamic Pricing

City OS systems can make real-time pricing possible.

Examples:

• congestion charges;
• parking charges;
• electricity;
• EV charging;
• public transport;
• tolls.

Dynamic pricing can produce efficiencies but also creates competition risks if a dominant platform uses proprietary information to discriminate against rivals or facilitate coordination.

26. Merger-Control Concerns

City OS ecosystems may create important merger issues.

Potential transactions include:

• City OS provider + mobility company;
• City OS provider + payment provider;
• City OS provider + mapping company;
• City OS provider + energy-management company;
• City OS provider + cloud provider;
• City OS provider + parking platform.

Even where conventional turnover thresholds are not particularly high, authorities may examine whether the acquisition eliminates a potential competitor or strengthens control over an important ecosystem.

27. Vertical Integration

A City OS provider may vertically integrate into downstream services.

For example:

City OS → transport → payments → advertising

Vertical integration can create efficiencies, but it can also give the platform an ability and incentive to disadvantage competitors.

The relevant competition questions include:

1. Does the platform control an important input?
2. Does it compete downstream?
3. Can it discriminate?
4. Would foreclosure be profitable?
5. Are consumers harmed?
6. Are there countervailing efficiencies?

28. Public Procurement and Competition

City OS procurement can itself affect competition.

A municipality may award one enormous contract covering:

• cloud;
• software;
• sensors;
• analytics;
• transport;
• payments;
• cybersecurity.

This can favour large integrated suppliers and exclude smaller specialist firms.

Competition concerns can therefore arise before the City OS becomes dominant, through procurement design.

Competition-friendly procurement can include:

• modular contracts;
• open technical standards;
• interoperable APIs;
• data portability;
• non-discriminatory access;
• reasonable contract durations.

29. City OS and Essential Digital Facilities

The concept of an essential facility becomes particularly interesting where the platform controls infrastructure that competitors cannot economically duplicate.

Examples could include:

Urban mobility gateway

Real-time citywide traffic and transport information.

Municipal identity gateway

Authentication required for access to multiple public services.

City data exchange

Central interface for urban datasets.

Smart-grid interface

Access point for energy-management providers.

Charging network platform

Integrated access to citywide EV charging infrastructure.

The stronger the evidence that alternative access routes are unavailable, the stronger the competition argument may become.

30. Competition Between City OS Providers

Competition should also exist between City OS providers themselves.

If one provider becomes entrenched, it may become difficult for another provider to enter because cities do not repeatedly rebuild their digital infrastructure.

Consequently, the relevant competitive process may occur:

• during procurement;
• during platform selection;
• during contract renewal;
• during technological upgrading.

This makes contestability especially important.

31. Competition Between Applications on a City OS

A City OS may function as a marketplace.

For example:

City OS → mobility apps → consumers

The operator should not necessarily be allowed to manipulate marketplace conditions to eliminate independent applications.

Potential problems include:

• ranking discrimination;
• excessive platform fees;
• discriminatory API access;
• mandatory bundling;
• data restrictions;
• interoperability restrictions.

32. Consumer Harm

Competition harm can ultimately appear as:

• higher prices;
• reduced choice;
• lower quality;
• reduced privacy;
• reduced innovation;
• slower technological development;
• increased switching costs.

In City OS markets, quality and innovation may be particularly important because price may be zero or heavily subsidised.

Traditional price-centred analysis may therefore be insufficient.

33. Innovation Competition

A City OS may determine which technologies become commercially viable.

If the operator restricts access to emerging firms, it may reduce:

• AI innovation;
• mobility innovation;
• energy-management innovation;
• urban sustainability technologies;
• autonomous transport technologies.

Competition authorities should therefore consider innovation foreclosure, not merely current market shares.

34. Privacy and Competition

Data-intensive City OS systems create an intersection between:

• competition law;
• privacy law;
• cybersecurity;
• public procurement.

Privacy deterioration can sometimes be relevant to competition analysis where firms compete on privacy quality or where data accumulation reinforces market power.

However, competition law should not automatically treat every privacy violation as an antitrust violation.

35. Cybersecurity as an Objective Justification

A City OS operator may legitimately refuse interoperability where access would create serious:

• cybersecurity risks;
• authentication vulnerabilities;
• safety risks;
• infrastructure integrity problems.

The Android Auto judgment expressly recognised platform integrity and security as potentially relevant objective justifications for refusal of interoperability.

The justification should nevertheless be genuine, proportionate and supported by evidence rather than being used merely as a pretext for exclusion.

36. City OS and India

For India, the primary framework is the Competition Act, 2002, particularly:

• Section 3 — anti-competitive agreements;
• Section 4 — abuse of dominant position;
• Section 5 — combinations;
• Section 19 — inquiry;
• Section 26 — investigation;
• Section 27 — orders and remedies.

A City OS could raise questions concerning:

Section 4

• denial of market access;
• discriminatory conditions;
• unfair conditions;
• tying;
• leveraging dominance;
• exclusionary conduct.

Section 3

Potential concerns could involve:

• horizontal coordination;
• vertical restraints;
• exclusive arrangements;
• information exchange.

Sections 5 and 6

These become relevant where acquisitions or combinations consolidate control over critical urban digital infrastructure.

37. Potential Remedies

Competition authorities could consider remedies such as:

Structural remedies

• divestiture;
• separation of business units.

Behavioural remedies

• non-discriminatory access;
• interoperability;
• API access;
• data portability;
• prohibition of self-preferencing;
• transparent ranking.

Procurement remedies

• shorter exclusivity periods;
• open standards;
• modular contracts.

Technical remedies

• open APIs;
• interoperability standards;
• data portability;
• multi-provider architecture.

38. Compliance Framework for City OS Operators

A City OS operator should maintain:

1. Non-discrimination policy
2. Transparent API-access rules
3. Objective interoperability criteria
4. Data-access protocols
5. Clear security justifications
6. Internal competition-law audits
7. Separate treatment of affiliated businesses
8. Transparent ranking systems
9. Data-portability mechanisms
10. Documented pricing methodology

Special care should be taken where the operator competes with businesses that depend upon its infrastructure.

39. Six Core Competition-Law Tests for a City OS

A useful analytical framework is:

Test 1 — Market Power

Does the City OS possess substantial market power?

Test 2 — Bottleneck

Does it control an infrastructure that rivals cannot reasonably duplicate?

Test 3 — Discrimination

Does it treat affiliated and independent businesses differently?

Test 4 — Interoperability

Does it restrict technical access to competing applications?

Test 5 — Leveraging

Does it use dominance in one urban market to strengthen another?

Test 6 — Foreclosure

Does the conduct materially restrict competitors' ability to enter, expand or innovate?

40. Summary of the Leading Cases

The most recent Android Auto judgment is particularly valuable for a City OS analysis because the CJEU recognised that interoperability with a digital platform can be competition-relevant even when the platform is not strictly indispensable, where the platform was designed for third-party participation.

41. Conclusion

A City Operating System can become a form of digital urban infrastructure. Its competitive importance comes from the combination of infrastructure, data, interoperability, network effects and access to citizens and businesses.

The principal competition-law risks are:

• essential-facility problems;
• refusal of access;
• API discrimination;
• self-preferencing;
• tying and bundling;
• exclusive dealing;
• data foreclosure;
• leveraging of dominance;
• algorithmic coordination;
• switching-cost exploitation;
• vertical integration;
• anticompetitive acquisitions.

The traditional essential-facilities cases—Bronner, Magill and IMS Health—provide the foundation, while Microsoft, Google Android, Google Shopping, Slovak Telekom and especially Android Auto demonstrate how those principles can be applied to increasingly complex digital ecosystems.

The central competition-law challenge is therefore to ensure that a City OS can obtain the efficiencies of integrated urban infrastructure without becoming a closed digital bottleneck through which competitors must pass on discriminatory or exclusionary terms.