CPB

Corporate PartnershipBoard

Mix and MaaS
Data Architecture for
Mobility as a Service

Corporate Partnership Board
ReportMix and MaaS
Data Architecture for
Mobility as a Service

Corporate Partnership Board
ReportThe International Transport ForumThe International Transport Forum is an intergovernmental organisation with 64 member countries. It acts
as a think tank for transport policy and organises the Annual Summit of transport ministers. ITF is the only
global body that covers all transport modes. The ITF is politically autonomous and administratively
integrated with the OECD.
The ITF works for transport policies that improve peoples' lives. Our mission is to foster a deeper
understanding of the role of transport in economic growth, environmental sustainability and social
inclusion and to raise the public profile of transport policy.
The ITF organises global dialogue for better transport. We act as a platform for discussion and prenegotiation of policy issues across all transport modes. We analyse trends, share knowledge and promoteexchange among transport decision makers and civil society. The ITF's Annual Summit is the world's largest
gathering of transport ministers and the leading global platform for dialogue on transport policy.
The Members of the Forum are: Albania, Armenia, Argentina, Australia, Austria, Azerbaijan, Belarus,
Belgium, Bosnia and Herzegovina, Bulgaria, Cambodia, Canada, Chile, China (People's Republic of),
Colombia, Croatia, Czech Republic, Denmark, Estonia, Finland, France, Georgia, Germany, Greece,
Hungary, Iceland, India, Ireland, Israel, Italy, Japan, Kazakhstan, Korea, Latvia, Liechtenstein, Lithuania,
Luxembourg, Malta, Mexico, Republic of Moldova, Mongolia, Montenegro, Morocco, the Netherlands,
New Zealand, North Macedonia, Norway, Poland, Portugal, Romania, Russian Federation, Serbia,
Slovak Republic, Slovenia, Spain, Sweden, Switzerland, Tunisia, Türkiye, Ukraine, the United Arab Emirates,
the United Kingdom, the United States and Uzbekistan.

About the Corporate Partnership Board
The Corporate Partnership Board (CPB) is the International Transport Forum's platform for engaging withthe private sector and enriching global transport policy discussion with a business perspective. The
members of the ITF Corporate Partnership Board are: Airbus, Allianz Partners, Alstom, Aramco, Autocrypt,
Bolt, Bosch, bp, CEiiA, Cruise, Enel, ExxonMobil, Hyundai, Iberdrola, Kakao Mobility, Michelin,
Mott MacDonald, NXP, PTV Group, RATP Group, Rolls Royce, Shell, Siemens, TotalEnergies, Toyota,
Trucknet, Uber, Valeo, Voi, Volvo Cars.

Disclaimer
Funding for this work has been provided by the ITF Corporate Partnership Board. This report is publishedunder the responsibility of the Secretary-General of the ITF. It has not been subject to the scrutiny of ITF
or OECD member countries, and does not necessarily reflect their official views or those of the membersof the Corporate Partnership Board.
Cite this work as: ITF (2023), “Mix and MaaS: Data Architecture for Mobility as a Service”,
International Transport Forum Policy Papers, No. 113, OECD Publishing, Paris.

Acknowledgements
The principal authors of this report were Camille Combe and Philippe Crist of the International Transport
Forum (ITF).
The report draws on contributions gathered in two virtual workshops, information sharing and discussion
with members of the ITF Corporate Partnership Board and experts. The authors are thankful for
information and insights provided by the workshop participants. Workshop participants are listed in
Annex 1.
Several external experts were also consulted in the preparation of this report. These included Ghislain
Delabie (FabMob), Arturo González Mac Dowell (Tink), Tobias Grosche (Worms University of Applied
Sciences), Christian Schäfer (Deutsche Bank), Tu-Tho Thai (MobilityData).
The authors thank external reviewers Ferdinand Burgersdijk (FRCB - Benelux/NRW Living Laboratory for
MaaS) and Tu-Tho Thai (MobilityData) as well as ITF reviewers Sharon Masterson and Elisabeth Windischfor their comments on the draft. Lauren Chester provided invaluable editorial support.
The work for this report was carried out in the context of a project initiated and funded by the International
Transport Forum's Corporate Partnership Board (CPB). CPB projects are designed to enrich policy
discussion with a business perspective. They are launched in areas where CPB member companies identify
an emerging issue in transport policy or an innovation challenge to the transport system. Led by the ITF,
the project development is carried out collaboratively in working groups consisting of CPB member
companies, external experts and ITF staff.
The authors wish to thank the members of the CPB involved in this project: Alstom, PTV Group, RATP
Group, Siemens, Tier Mobility, TotalEnergies, Toyota, Valeo, and Voi.
Camille Combe coordinated the project. Sharon Masterson manages the CPB and Philippe Crist manages
CPB projects.

TABLE OF CONTENTS

Table of contents

Executive summary ........................................................................................................................... 10
Mobility data infrastructure and MaaS .............................................................................................. 13
Mobility data as foundational infrastructure ................................................................................ 13
Mobility data infrastructure and MaaS ......................................................................................... 19
Data sharing … and sharing data for MaaS......................................................................................... 28
The public and private value of data sharing................................................................................. 28
Sharing data for MaaS ................................................................................................................... 29
Understanding the multiple dimensions of MaaS-relevant data................................................... 29
Why share what data? The economic and social welfare case ..................................................... 33
What data to share for MaaS? ........................................................................................................... 36
The functional blocks that make up MaaS .................................................................................... 36
How to share MaaS-relevant data? ................................................................................................... 43
Technical aspects of integration, compatibility and data sharing ................................................. 43
Data sharing mechanisms for MaaS: The role of APIs ................................................................... 57
Architectural guidelines on APIs as mobility data infrastructure................................................... 59
How to handle and process shared data? .......................................................................................... 62
Data handling protocols and processes......................................................................................... 62
MaaS data sharing: State of play ....................................................................................................... 66
Current efforts to improve data sharing ....................................................................................... 66
MaaS data sharing: A way forward .................................................................................................... 70
Articulate a vision .......................................................................................................................... 70
Address uncertainty and early lock-in ........................................................................................... 70
Leverage “data spaces” to shape data infrastructure around interoperability and trust
mechanisms .................................................................................................................................. 71
Deliver essential public data sharing building blocks .................................................................... 73
Improve public administration capacity ........................................................................................ 73
References ........................................................................................................................................ 75
Annex A. List of workshop participants .............................................................................................. 89

4

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

TABLE OF CONTENTS

FiguresFigure 1. The mobility infrastructure stack and digitalisation............................................................. 14
Figure 2. The three pillars of mobility data architecture .................................................................... 18
Figure 3. MaaS behaviour change – the relationship between MaaS integration levels andcognitive load .................................................................................................................................... 21

Figure 4. The MaaS ecosystem .......................................................................................................... 22
Figure 5. Data sharing for MaaS must address three essential questions .......................................... 29
Figure 6. The different facets of mobility data ................................................................................... 30
Figure 7. From data to knowledge ..................................................................................................... 34
Figure 8. TOMP-API functional blocks for MaaS ................................................................................. 37
Figure 9. Microservices underpinning MaaS and their sequential timing ........................................... 38
Figure 10. Technical aspects of data sharing: Connectivity, interoperability and portability .............. 44
Figure 11. Building blocks of data interoperability: Data semantics, schemas and syntax .................. 46
Figure 12. Establishing minimum interoperability between mobility data syntaxes ........................... 49

Figure 13. Data portability models..................................................................................................... 52
Figure 14. MaaS: Authentication, authorisation and personal data portability .................................. 55
Figure 15. How to share data? Centralised data pooling versus on-demand data exposure .............. 57
Figure 16. Correspondence type when mapping two standards ........................................................ 68
Figure 17. Data space ecosystems and building blocks ...................................................................... 72

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

5

GLOSSARY

Glossary
Application programming interface (API)An API is a set of defined rules and protocols that enables different
software applications to communicate with each other. APIs allow
developers to access the functionality of an existing application orservice, such as retrieving data or performing specific tasks, without
having to know how the application is implemented.

Commercially sensitive data

There is no standard definition of what comprises “commerciallysensitive data”. The commercial sensitivity of data is often describedin reference to trade secrets (ITF, 2021c; 2021d) or as data that, if
disclosed, would harm a party’s commercial interests (Welsh
Government, 2021). However, while all confidential data aresensitive, not all sensitive data are confidential (ITF, 2021c; 2021d).
Therefore, commercially sensitive data may be shared under specificcircumstances and conditions.

Data controller

According to the EU’s General Data Protection Regulation (GDPR), a
data controller “means the natural or legal person, public authority,
agency or other body which, alone or jointly with others, determines
the purposes and means of the processing of personal data; where
the purposes and means of such processing are determined byUnion or Member State law, the controller or the specific criteria for
its nomination may be provided for by Union or Member State law”.
The GDPR distinguishes data controllers from data processors. Yet,in some cases, an organisation may be a data processor andcontroller simultaneously. (European Commission, 2016)

Data mapping

Data mapping is an iterative process to find correspondence
between a source data model and a target model. It can improvedata sharing by allowing the identification of the similarities,
differences and potential overlaps between data models.

Data portability

Data portability refers to the ability, sometimes construed as a right,
for people to either obtain or transfer and delegate the transfer of
their personal data from entities that collect and hold it to otherentities of their choosing (OECD, 2021b). In the context of MaaS,
data portability refers to the ability for travellers to authorise thetransfer of their personal data in support of joined-up trips among
several mobility operators.

Data processing

Data processing relates to operations performed on data or
datasets, regardless of their sensitivity or automation. It comprises
operations such as collecting, recording, organising, storing,
structuring, adapting, altering, transmitting, disseminating,restricting, erasing or destroying. (European Commission, 2016)

6

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

GLOSSARY

Data sharing

Data sharing refers to the distribution process whereby data istransferred from data holders to data receivers; it does notencompass shared material (e.g. data shared). Thus, data sharing
should not be interpreted as “shared data” (Support Centre for Data
Sharing, 2022).

Data spaces

A data space is “a decentralised infrastructure for trustworthy data
sharing and exchange in data ecosystems based on commonly
agreed principles” (Nagel et al., 2021).

Data subject

A data subject refers to a person or an entity that can be identified
directly or indirectly using an identifier. According to the GDPR, an
identifier can be “a name, an identification number, location data,an online identifier or to one or more factors specific to the physical,
physiological, genetic, mental, economic, cultural or social identityof that natural person” (European Commission, 2016).

Deep link pathway

Deep linking is a link in an interface that redirects the user toanother system to complete a purchase or otherwise interact with
their systems (ITF, 2021).

General Transit Feed Specification (GTFS)GTFS is a standardised format describing public transport schedules
and services. GTFS data includes information on transit routes,
stops, schedules, fares, and geographic information such as stop
locations and shapes of transit routes. It allows developers to create
applications such as trip planners, real-time arrival predictions, andmaps that use the transit data.
GTFS has a real-time instance, GTFS-RT, which relates to several
observable, but not necessarily publicly available, data points suchas service alerts, vehicle positions, and trip updates (Barbeau, 2018).

Informational data

Data containing general information on transport services (e.g.
availability, location of stops, schedule, cost, etc.). Informational
data allow MaaS providers to plan, create and communicate
combined-mobility offers. (ITF, 2021).

Interoperability

Interoperability “refers to the ability of different digital services towork together and communicate with one another” (OECD, 2021b).
In the context of MaaS, interoperability constitutes a form of dataand system compatibility that enables different operators to deliver
a combined service to the user (ITF, 2021).

MaaS providers

MaaS providers aggregate different mobility operators’ services intoa single offer through an application (MaaS app) or another digitalinterface (ITF, 2021).

Minimum Interoperability Mechanisms(MIMs)

MIMs “are the minimal but sufficient capabilities needed to achieveinteroperability of data, systems, and services between buyers,
suppliers and regulators across governance levels around the world”(LI.EU, 2021).

Mobility as a Service (MaaS)

MaaS is a distribution model for mobility services that uses shareddata and a digital interface to efficiently source and managetransport-related services into a seamless offer tailored to individual
traveller preferences. MaaS is typically delivered via an app or
another digital interface combining different transport, information

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

7

GLOSSARY

and payment services into a smooth and reliable digital customer
experience.
Mobility operators

Mobility operators provide a physical mobility service. For example,
they could be public transport operators, shared bicycle services,ridesourcing or car-sharing operators.

Operational data

Operational data is data enabling or supporting the operationaldelivery of mobility services – for example, by enabling gate orturnstile access, unlocking or locking a vehicle, terminating a sharedvehicle trip, etc. (ITF, 2021; 2022)

Personal data

Personal data describes any information that can be linked directly
or indirectly to a natural person. Personal data may relate tosensitive information (e.g. racial or ethnic origin, political opinions,religious affiliation, health status, etc.), which requires additional
care.

Personal Information Management
Systems (PIMS)

PIMS are a catch-all term that represents any technical tool thathelps to address the imbalance of power and transparency aboutdata use between individuals, and firms collecting their personal
data. PIMS is provide users with tools to manage their privacy rights.
Thia involves granting and revoking their consent for data processing— at a fine-grained level – with any given data controller, andexercising their legal rights, especially the right to data portability(Art. 20 GDPR) and the right to erasure (Art. 17 GDPR). (Krämer,2021a)

Public service obligation (PSO)

A PSO refers to “specific requirements that are imposed by publicauthorities on the provider of the service in order to ensure thatcertain public interest objectives are met” (European Parliament,
2006). In the context of MaaS, PSO refer to obligations imposed on
mobility operators – in particular those imposed on public transport
operators.

Re-identification

Re-identification is an intentional isolation technique that enables
the identification of an individual in a set of observed or volunteered
data that has been anonymised. Article 29 Data Protection Working
Party (A29WP) distinguishes two re-identification techniques:
linkability and inference (Data Protection Working Party, 2014; Finck
and Pallas, 2020). Data inference refers to the possibility of deducing
a specific insight from data. Finally, linkability refers to the ability tomatch two records of the same data subjects.

Transactional data

Transactional data are data related to things a user purchases.

Transport Operator to MaaS Provider Application Programming Interface(TOMP-API)

The TOMP-API (Transport Operator to MaaS Provider - Application
Programming Interface) is a standardised technical interface
between MaaS providers and transport operators initiated by the
Dutch Ministry of Infrastructure and Water Management in 2018 insupport of seven national MaaS pilots. Since 2020, the Transport
Operator, MaaS Provider - Working Group (TOMP-WG) has been
moved to become an open-source foundation with an international
scope (TOMP-API, 2021).

8

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

GLOSSARY

Zero-knowledge proof-based signature

A zero-knowledge proof-based trust signature is a cryptographic
technique used to verify the authenticity and integrity of data
without revealing any sensitive information about that informationor the parties involved in the verification process. This can help
establish trust in digital transactions, such as online purchases or
identity verification, while protecting the privacy and security of theparties involved.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

9

EXECUTIVE SUMMARY

Executive summary
What we did
Mobility as a Service (MaaS) is a promising, rapidly evolving approach to enabling seamless mobility. MaaS
requires extensive data sharing among the actors of such an ecosystem and hence an appropriately
adapted data governance framework. This report frames the context for data sharing for MaaS andestablishes broad principles for its implementation.

What we found
Data is a form of infrastructure. Although immaterial, it shapes real-world outcomes and can help toachieve public policy objectives or work against them. Unlike material infrastructure, data infrastructure
is poorly understood and rarely regulated. However, some public authorities are adopting an infrastructure
approach to data governance, for instance, in Switzerland or the European Union.
Road, rail, port and airport infrastructure connects places. Mobility data infrastructure integrates services.
MaaS delivers this integration as a user-centric distribution model for mobility services. With MaaS,
travellers mix and match services as required. Data sharing allows mobility operators that deliver transport
services, MaaS providers that integrate offers and data intermediaries to offer the seamless trips thattravellers seek.
Data governance for MaaS must account for multiple data properties: are the data personal? How are thedata sourced? What functionality do they support? Who can access it? Personal data requires special
safeguards, including consent to sharing them within the MaaS ecosystem. Personal data covers data
volunteered by individuals and other data specifically concerning them.
MaaS ecosystems require minimum data sharing obligations for participants. This enables a MaaS
operator, for example, to join information regarding available shared bicycles and real-time train schedules
and provide travellers with a single payment option and a means to access both services. Innovation andcompetition in the MaaS ecosystem should be founded on service offers, not on the ability to collect andhold data about travellers and operations. Nonetheless, data sharing should be limited to minimise risks
associated with mandatory data sharing, especially concerning the onward sharing of data for purposes
not consented to by travellers.
Data in MaaS ecosystems need to be interoperable, meaning that the systems of the different actors canwork together. Interoperability requires a shared understanding of terminology and how terms relate.
MaaS ecosystems also require personal data to be portable from one system to another with traveller
consent. Portability concerns rights and responsibilities about how and under what conditions data istransferred. A functioning and competitive MaaS ecosystem requires continuous data portability to enablereal-time trips – not just ad-hoc data transfers. It is vital for user-centric services and is a precondition ofinteroperability.

10

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

EXECUTIVE SUMMARY

A MaaS ecosystem requires a common data resource for all actors. Centralised data repositories controlled
by one actor have been the norm for establishing this data resource in the past. However, this raises
questions about trust and impartiality. A more effective approach makes the necessary common data
resource accessible on-demand via application programming interfaces (APIs).
APIs enable sharing a subset of mobility operator data to vetted MaaS providers. They also serve to build
seamless on-demand trips within the MaaS ecosystem. Furthermore, an API data sharing approach enables
secondary and tertiary service markets such as payment processing, route calculation or identity
authentication for people and vehicles, which could generate efficiencies and innovation. As that
happens, the role of the MaaS provider shifts from integrating mobility offers to orchestrating
mobility-linked services.
Most actors in the mobility sector already rely on data to build and run their services. However, the future
MaaS ecosystem will require convergence around data standards and new data sharing mechanisms.
There is a structural mismatch regarding data management and governance capacity within the public
sector and the requirements for MaaS to function at scale. Delivering data infrastructure supporting thecommon good will require skills and capacity development across all MaaS ecosystem actors, particularly
the public sector.

What we recommend
Think of mobility data as infrastructure
More and more actors view and treat data as critical infrastructure. Mobility data plays an essential role in
how people live their daily lives, and it should be considered critical transport infrastructure along withroads, rail lines or IT infrastructure. An infrastructure approach to data governance should establish ashared vision of what this infrastructure should deliver and how it should serve societal objectives. This
will guide the development of data-driven markets in line with public policy objectives, rather than only
addressing market failures.
Develop a cross-sectoral vision for data governanceThe challenges regarding data governance are cross-cutting. The finance, health, energy,
telecommunications and transport sectors, among others, are all seeking to address similar issues relating
to the role of data resources and how to manage data sharing. Public authorities should help establish aconsensus-oriented, comprehensive vision for data governance and guiding principles that inform aligned
rule-setting in different sectors.
Establish minimum data sharing requirements for actors in MaaS ecosystems
Minimum mandatory data sharing is required to establish the common data resource necessary to deliversocial welfare-enhancing MaaS. This data should include volunteered and observed personal data withappropriate and clear consent mechanisms. It should also be made accessible at latencies low enough to
support real-time delivery of joined-up trips. Data shared should not include knowledge and inference
derived by actors based on raw data analytics. Data sharing obligations should also cover the use,
specification and structure of data sharing APIs. This will establish a common base while incentivising
appropriate convergence in their design and functionalities.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

11

EXECUTIVE SUMMARY

Link data sharing requirements and incentives to licencing
Licencing terms for mobility operators and MaaS providers should reference basic data sharing
requirements and use open standards. They should also encourage the use of standard terminology,
compatible data schemas and syntaxes. For efficiency, the licencing terms should also promote theadoption of open and open-source APIs among actors in a MaaS ecosystem. Licensing terms could also be
more or less standardised to reduce compliance costs.
Public authorities should provide essential data sharing functionalities
Public authorities are responsible for delivering essential public building blocks to build MaaS data sharing.
For example, specifying standards for APIs enabling identity and authentication fosters trust that actors
are who they say they are. Beyond that, public authorities can deploy API-enabled pathways for otherofficial information relating to the traveller’s status. This enables MaaS actors to establish traveller rights,
such as those concerning fares or disability status.
Improve data skills and digital management capacity within public administration
The skills for managing data infrastructure differ from those needed to govern other infrastructure. Publicauthorities often struggle with digital transformation as they seek to overcome practices inherited fromthe analogue era. Targeting recruitment to acquire new skill sets helps to close this gap. Outsourcing data
management may help where recruitment remains challenging for the public sector. However, evenoutsourcing requires knowledgeable contract managers and competent leadership. A focus on in-house
up-skilling can help foster essential data governance skills.

12

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

Mobility data infrastructure and MaaS
Digitalisation is profoundly impacting how society and markets function. One of these impacts is theshaping of essential infrastructures (Banerjee, Jittrapirom and Dangschat, 2021; Dijck, Poell and Waal,
2018; Kitchin and Dodge, 2011). Physical spaces and networks have become so intertwined with digitalelements that networks have become as significant as their physical counterparts (Banerjee, Jittrapirom
and Dangschat, 2021). Digital “code/spaces” are increasingly indispensable to the functioning of everyday
life. Just as the physical world is increasingly dependent on code, code itself is written (sometimes without
human intervention) to produce material spaces, including infrastructure (Kitchin and Dodge, 2011; Nagelet al., 2021). Data as infrastructure is emerging in many domains, such as health, energy and transport.
Across these domains, public authorities and other stakeholders will need to make conscious decisions
about how to design open and interoperable sector-specific data infrastructures (Dodds and Wells, 2019).

Mobility data as foundational infrastructure
Society depends on infrastructure. It provides essential services that enable society to function. Wheninfrastructure works, people forget about it. When it breaks down, people immediately realise how much
everyday life depends on it. When it is managed as a public good, all benefit. When it is not, inequity
increases. The term “infrastructure” brings to mind roads, rail, pipes and powerlines, but infrastructure is
not only physical. It also comprises non-material but equally essential systems that contribute to generalpublic welfare (Dodds and Wells, 2019).
Digitalisation has given rise to a new set of virtual infrastructure comprised of the architecture – forexample, the structure and linkages – of mobility data (Figure 1). This infrastructure layer and its
architecture shape how and under which conditions data are created, shared, used, maintained anddestroyed. Its real-world impacts are significant – it can help achieve public policy outcomes just as it canwork against them if unguided. Yet, unlike the other material layers, this emerging digital layer is poorly
understood and hardly regulated. This is because its importance is only starting to become evident andbecause regulatory models for digital public spaces and digital infrastructure have not yet emerged(Banerjee, Jittrapirom and Dangschat, 2021; Lehrer, 2021; van der Waal et al., 2020; Waag, 2021). This
report seeks to address these challenges in the context of data governance, in particular data sharing,
relating to Mobility as a Service (MaaS).
The mobility infrastructure stack

Figure 1 illustrates the linkages between the built environment, physical and digital infrastructure layers
and infrastructure-based services in the emerging mobility code/space or infrastructure stack. At the baseis the built environment. Buildings and underlying land-use patterns determine the built environment.
These result from countless decisions by individuals, firms and public authorities, each trying to balance
their interests. This arbitration risks creating asymmetric outcomes favouring the interests of some overthose of others, leaving society worse off. For this reason, authorities typically guide the stock of buildings

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

13

MOBILITY DATA INFRASTRUCTURE AND MAAS

and land use patterns through building and land use zoning regulations. Together, these regulatoryinterventions help determine what gets built where and which activities are permitted in which location.
Figure 1. The mobility infrastructure stack and digitalisation

Infrastructure-based Services
Highly regulated
Good quality public transport ensures equitable andsustainable access, is space efficient and is supported bypublic funds in return for public service obligations. Other
mobility services are regulated to ensure they do not erode
public policy outcomes as they deliver benefits to travelers.

Foundational infrastructure

Mobility data infrastructure
Hardly regulated

Integrative infrastructure
Data, software, code,
algorithms and syntaxes.

The public mobility data architecture is an integrative
infrastructure which improves the efficiency with whichtransport services use transport networks. Rapid
digitilisation has resulted in commercially deployed digitalarchitectures largely absent of public policy guidance.

Transport network infrastructure
Highly regulatedConnective infrastructure
Hardware, concrete, asphalt
and steel.

Transport networks are connective infrastructure joining
spatially distant locations. They provide access toopportunities and reduce travel times. Public authorities
help determine their specification, location and typicallyfund these in the general interest. They have been the
traditional focus of infrastructure policy for transport.

Built environment
Highly regulated
Land use and building regulations help frame what gets built
where and what activities are permitted, encouraged or
discouraged. Access to opportunity is conditioned byproximity or by access to transport networks. Trip origins anddestinations are linked to the built environment.

The next layer – transport network infrastructure – determines how people gain access to spatially distantactivities and opportunities. This infrastructure is connective because it physically enables people andgoods to travel between spatially distant locations. It is also foundational in that it is part of theinfrastructure of everyday life and is a pre-condition for the well-being of every citizen (Foundational
Economy Collective, 2022a).
Like other forms of foundational infrastructure, transport networks typically benefit from a monopoly overany given area and are designed to provide service to society. They may or may not be publicly owned, butthey are managed in the general public interest (Finger and Montero, 2022, Montero and Finger, 2021a;
OECD, 2021a;). The connective and foundational infrastructure that underpins transport comprises roads,
streets, pavements, rail, stations, ports and airports. A key focus for authorities is the efficient and sociallybeneficial use of transport network infrastructure. Accordingly, public authorities are deeply involved in

14

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

the design, specification, siting, funding and financing, regulation and management of these networks andhave built considerable in-house expertise and resources to do so.
Infrastructure-based services deliver value to citizens and society at the top of the mobility infrastructure
stack. These services are heterogeneous and operated under different access and operational models.
They are priced differently, and some must adhere to public service obligations.
A core service derived from foundational transport infrastructure is individual mobility – people walking
or using their vehicles to carry out their daily travel. On unpriced or subsidised infrastructure – as in thecase of roads and streets – inefficient uses may dominate, generating harmful externalities (e.g. traffic
congestion, air pollution, etc.). In these instances, the sum total of individual decision-making generates
unsustainable societal burdens (ITF, 2021d; Mattioli et al., 2020).
Transport network infrastructure also enables the provision of publicly or commercially operated
infrastructure-based services. These include public transport (by bus or rail operators), taxi and ridesourcing services (by individual drivers and commercial platform operators) and shared micromobility or
carshare services (by community-based or platform operators). These services are almost always theobject of specific regulation concerning licensure and other operating permissions. Some of these services
whose public utility is demonstrated and valued, even when they may be uneconomic, are subject to much
more stringent regulations, fare-setting and operational requirements in return for public subsidy. This is
the case for public transport, whose subsidy is conditioned to public service obligations. Transport network
infrastructure also enables other services beyond those directly enabling the movement of people. These
include emergency and health services, waste removal, postal delivery, urban goods distribution andservices linked to construction, plumbing maintenance and other trades.
The mobility infrastructure stack has been characterised by long periods of stability punctuated by shortbursts of change. The digitalisation of transport services and other aspects of daily life has triggered sucha burst. It has resulted in a new layer in the mobility infrastructure stack – mobility data infrastructure.
This data infrastructure comprises four main components:
1. Algorithms: central to data processing. They process inputs into outputs according to their design.
The move towards artificial intelligence and self-writing algorithms makes these increasingly moreopaque to the public, decision makers and even their designers (see also ITF (2019).
2. Infrastructural platforms: the foundational physical and code-based platforms that materiallyenable data collection, transmission, processing and storage. They enable sectoral platforms andecosystems of platforms.
3. Sectoral platforms: platforms that serve specific sectors or markets. They often are connective(two-sided) platforms that bring together supply and demand (e.g. Airbnb, Didi, Uber, Free etc.).
They are generally delivered to people via apps.
4. Ecosystems of platforms: the web of complementary (and sometimes competing) platforms andservices that deliver value to people via the interconnection of systems and the sharing of data
among ecosystem actors. The linkages among platforms and services are enabled by application
programming interfaces (APIs) and the diffusion of Software Development Kits (SDKs). SDKs enablesystem, protocol and data linkage and interoperability. (Banerjee, Jittrapirom and Dangschat,2021; Dijck, Poell and Waal, 2018)
In contrast to the connective nature of the material infrastructure comprising transport network
infrastructure, mobility data infrastructure is integrative. Rather than connecting physically distant

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

15

MOBILITY DATA INFRASTRUCTURE AND MAAS

locations, it digitally integrates the infrastructure-based services that operate on transport network
infrastructure. It could create efficiencies and provide more seamless travel options to people.
Data infrastructure should not be conflated with digital infrastructure comprised of the material
technologies that enable data collection, processing, transmission and storage. Just as the built
environment and transport networks create public spaces essential to the well-being of citizens andsociety, data infrastructure is essential to creating digital public spaces that benefit all (Lehrer, 2021; vander Waal et al., 2020; Waag, 2021).
The linkages between the mobility data infrastructure layer and other layers in the mobility infrastructure
stack are important. Just as roads help people navigate to destinations, mobility data infrastructure helps
people navigate to decisions (Dodds and Wells, 2019). These decisions have real-life repercussions on
people’s mobility, including when, where and how they travel. This layer also influences the provision andviability of different infrastructure-based services and even the physical layout of the underlying transport
network infrastructure and built environment (ITF, 2020).
Regulating mobility data as foundational infrastructure

There is a strong argument that the emerging mobility data layer is not only a new form of infrastructure,
but as with other forms of transport infrastructure, it is foundational. This means it influences fundamental
aspects of everyday life and is a pre-condition for citizens’ well-being (Busch, 2021; DETEC, 2022; Dodds
and Wells, 2019; Ecoplan, 2019; Finger and Montero, 2022).
Considering mobility data as foundational infrastructure mirrors the infrastructural interpretation of data
in other sectors, particularly those displaying similar cyber-physical characteristics as in transport (e.g.
telecommunications and energy) (Hoffmann and Gonzalez Otero, 2020; Janssen, Chun and Gil-Garcia,
2009; Rahman, 2018; Surblyte, 2016). Such an approach links all the different layers to be analysed tounderstand factors such as usage, future requirements or usefulness. Foundational characteristics affecthow authorities frame this infrastructure’s development and regulation. In particular, this framing will
influence how authorities address data governance in transport, specifically for MaaS, especiallyconcerning data sharing among MaaS ecosystem actors.
The rapid rise of platform-based and other digital services is one of digitalisation’s most consequential andfar-reaching results (Dijck, Poell and Waal, 2018; Nash et al., 2017). Digital platforms have emerged inseveral different areas like information search and acquisition (Google, Bing, Baidu), mapping and georeferenced content (Google maps, Bing maps, Baidu maps), social media platforms (Facebook, Twitter,
Instagram, Tik Tok), shopping (Amazon, Alibaba) and navigation and mobility (Google maps, Uber,
Rome2Rio). In all of these areas, digital services and the digital infrastructure on which they depend takeon an important and, in some ways, primordial role in people’s everyday life. They increasingly extend to
fields of activity that are typically managed in the general public interest. They influence consequential
decisions that their users make and, at the same time, gradually exclude non-users from accessing central
economic and societal infrastructures (Busch, 2021; Durand et al., 2022).
In response, public authorities and civil society are starting to scrutinise digital services. Consequently, they
are exploring regulatory frameworks enabling innovative services to develop while guaranteeing that theiractivity does not erode fundamental rights or desirable public policy outcomes (Cremer, de Montjoye andSchweitzer, 2019; Furman et al., 2019; Lancieri and Sakowski, 2021; Marsden and Podszun, 2020). These
efforts focus on addressing the market power of digital platforms and generally propose adjustments tocompetition law. This, however, may be an insufficient approach as it does not address the emerging and

16

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

foundational role that these services currently play across many global regions (Busch, 2021; Finger andMontero, 2022; Montero and Finger, 2021a).
The societal and regulatory challenges posed by increased reliance on digital platforms should not only beviewed in light of market competition dynamics. Busch (2021) highlights that platforms“are extending their reach further and further into areas where social participation and the supply of
essential services to citizens is at stake. In short, digital platforms have developed into infrastructures ofdigital services of general interest”. For this reason, regulation in this area is not just a question ofcompetition policy but also of infrastructure policy. In practice, this suggests that, just as public authorities
regulate other essential public interest infrastructure, authorities must address the “infrastructuralfunction” of digital platforms and ecosystems as part of their responsibilities to citizens (see Box 2) (Busch,
2021; Dijck, Poell and Waal, 2018; Dodds and Wells, 2019; Nash et al., 2017; Soriano et al., 2019).
Similarly, public authorities’ responses to regulating the digital infrastructure layer should not be
motivated solely by seeking to address market failures. Instead, there is a justification for authorities toplay an active role in market creation as with other essential infrastructure investments (Mazzucato, 2015,2016). This means going beyond just fixing markets and systems or simply de-risking private sector
investments but supporting socially beneficial outcomes by creating and shaping entirely new markets thatemerging technologies and practices make possible (Mazzucato, 2016). The EU adopts such an approachby articulating public policy “missions” whose outcomes are aligned with societal objectives andpublic expectations.
Authorities must help shape nascent markets to support these missions (Mazzucato, 2018). This approachseems appropriate to accompany the development of mobility data infrastructure given substantial
market capture and lock-in risks and, more generally, the risk that people will lose their ability to assert
and realise their fundamental rights in digital public spaces. Public authorities intervene and guideoutcomes in the general public interest in all other layers of the mobility infrastructure stack, and so too
should they for mobility data infrastructure. This represents a public policy mission for digital spaces andis increasingly shaping public policy.
Mobility data infrastructure is deployed and managed by public and private mobility ecosystem actors,
each producing digitally-enabled services. There is no single “mobility platform”, but there are emerging
platform-based mobility services and actors who could become dominant players in the ecosystem. For
this reason and those outlined above, public authorities should consider anticipatory actions aiming to
mitigate the risk of market dominance and address the role of mobility data as foundational societal
infrastructure. In particular, there is an emerging need to conceptualise public value-centric design fordata infrastructure and platform markets (Banerjee, Jittrapirom and Dangschat, 2021; Dijck, Poell and
Waal, 2018; UK House of Lords, 2019). In line with that thinking, the 2022 French Presidency of the EU
produced a call for digital and data infrastructures to be managed or created as digital commons (European
Working Team on Digital Commons, 2022). Such digital commons are “information and knowledge
resources that are collectively created and owned or shared between or among a community, and that
tend to be non-exclusive [and] are oriented to favour use and reuse, rather than to exchange as acommodity” (Morell, 2014).
Some public authorities are starting to address the infrastructural nature of mobility data and adopt digitalcommons approaches to this infrastructure. The following address the need to manage and frame mobility
data governance for the common good, with some calling for infrastructure-like functionalities:
France’s Framework Transport Law (Loi d’orientation des mobilitiés [LOM]).

The recent reform of the German Passenger Transport Act (Personenbeförderungsgesetz [PBefG]).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

17

MOBILITY DATA INFRASTRUCTURE AND MAAS

Legislative efforts underway at the level of the European Union (e.g. regarding multimodal digital
mobility services [MDMS] in the context of the revision of Delegated Regulation [EU] 2017/1926
on multimodal travel information services and the ITS Directive 2010/40/EU).

National Access Points (NAPs) for scheduled transport data in the EU.

Switzerland’s draft federal law concerning mobility data infrastructure (Loi fédérale concernant
l’infrastructure de données sur la mobilité [LIDMo]).

Switzerland has explicitly recognised the infrastructural nature of mobility data. The draft law – the LIDMo– recognises mobility data infrastructure (MODI in the law) as a third transport infrastructure alongsideroads and rail and calls for the Federal Office of Transport to manage and regulate it for the public good
(Assemblée fédérale, 2022; DETEC, 2022).
The architecture of mobility data infrastructure

Mobility data infrastructure comprises multiple elements beyond the data (Box 1). It is characterised byan architecture that matters from a conceptual and a regulatory perspective – especially in the context of
MaaS. This architecture is organised along three pillars (Figure 2).
Figure 2. The three pillars of mobility data architecture

1. data sharing

2. data reporting

3. machine-readable
regulation

The first pillar relates to data sharing practices, methods, protocols and syntaxes among public and private
market actors. These transfers enable innovation in new, joined-up offers and services. This pillar creates
the foundation for MaaS, and as such, it is characterised by a many-to-many exchange of data that has
implications for its governance. This first pillar – data sharing among mobility ecosystem actors – is the
subject of this report.
The second pillar relates to the reporting of data by ecosystem actors to public authorities. This enables
authorities to monitor how, to whom and under which conditions ecosystem actors deliver services. It
allows authorities to monitor impacts and understand if, when and how they may need to intervene toensure the public policy outcomes for which they have mandates. Data reporting involves a many-to-one
communication channel, as explored in the ITF report Reporting Mobility Data: Good Governance Principles
and Practices (ITF, 2021c).
The third pillar relates to public authorities issuing machine-readable regulations and laws, which signals
public policy intent to ecosystem actors. This pillar is under development across multiple domains within
and outside of transport. Still, it faces challenges as there is no broadly accepted model (or legal tradition)

18

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

to guide the development of machine-readable and interpretable law. These challenges will likely growwith the uptake of more automated and artificial intelligence-dependent services and technologies. This
pillar is characterised by a one-to-many communication channel (ITF, 2018b; 2018a; 2019).

Mobility data infrastructure and MaaS
MaaS is an emerging and evolving concept that can improve transport efficiency and people’s everyday
mobility (ITF, 2018a; 2021a; 2021b; 2021e;). It promises improvements in the use of transport assets andvehicles and better alignment of transport services with individual desires and needs. Also, it could lead tothe emergence of more sustainable travel behaviours and a reduction of the negative impacts linked tosolo car use (Arias-Molinares and García-Palomares, 2020; Durand et al., 2018; Jittrapirom et al., 2018;
Pangbourne et al., 2018; Lyons, Hammond and Mackay, 2020; Hensher, Ho and Reck, 2021; ITF, 2021e;
Schultz, Meda and de Labaca, 2021).
MaaS combines three fundamental concepts:
1. providing transport “as a service” rather than through vehicle ownership – i.e. access to vehicles
versus ownership of vehicles
2. joining multiple transport services seamlessly to carry out a trip
3. focusing on the customer and demand side.
The first element is not new – transport services have been around for as long as transport technologies.
Modes such as public transport, air, maritime and rail travel are all based on services that allow individuals
to travel without owning a vehicle.
The second component – multi-modality and seamlessness across travel modes – is not new either.
Multimodality is a long-term policy focus, especially where travel demand is high and space or network
capacity is constrained. There are likely some natural limits to multi-modality. Almost all trips are bi-modal,
combining walking (for those who can) and another travel mode. Many trips could become multi-modal indifferent ways in the first, middle and last metres or kilometres. However, it is unclear how much
multi-modality people might want and under what conditions they would accept inter-mode transfers(Pickford and Chung, 2019).
Finally, despite the “customer-centricity” maintained, relatively few people use MaaS offers when they
are available, and even fewer ask for them when they are not (Alyavina, Nikitas and Njoya, 2022; Hensher,
2022; Hensher, Mulley and Nelson, 2021; Hensher and Xi, 2022; Lyons, Hammond and Mackay, 2020). It
is apparent that many people use trip-planning services and combine at least two modes on their own.
MaaS services that offer physical accessibility-centric trips are also used more by travellers with specificmobility needs (e.g. travellers with wheelchairs).
MaaS has yet to achieve widespread uptake via successful and durable business models or use cases. There
are many reasons for this. Some reasons are structural, like the fact that transport networks and the built
environment are not generally created with intermodality in mind. Another reason is that there is no firm
consensus on what MaaS is and even less experience on what it could actually deliver (Alyavina, Nikitas
and Njoya, 2022; Arias-Molinares and García-Palomares, 2020; Calderón and Miller, 2020; Jittrapirom etal., 2017a; Liimatainen and Mladenović, 2018; Lyons, Hammond and Mackay, 2020; Schultz, Meda and deLabaca, 2021).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

19

MOBILITY DATA INFRASTRUCTURE AND MAAS

Often, the definition of MaaS is conflated with specific MaaS use cases. They confuse what is deployed as
MaaS with an overall understanding of what MaaS does. In these cases, MaaS is treated as a product or an
app when in fact, from a delivery-neutral and functional perspective, it is neither.
MaaS is a user-centric distribution model for mobility

From a functional perspective, MaaS is a “distribution model for mobility services that uses shared data
and a digital interface to efficiently source and manage transport-related services into a seamless offer
tailored to individual traveller preferences” (ITF, 2021a; 2021b; 2021e). MaaS is typically delivered via an
app or another digital interface that combines different transport, information and payment services intoa smooth and reliable digital customer experience.
MaaS promises to improve traveller convenience by allowing seamless access to a range of mobility
services across interconnected trip chains. By removing both physical friction and the cognitive load ofswitching from one service to another, MaaS solutions would enable better use of existing capacities andservice offers as travellers go from A to B. This improved ease would enhance the travel experience ofusing MaaS compared to experiences provided by single modes – notably cars (but in reality, bicycles andsome public transport trips).
Proponents of MaaS believe that well-designed offers would unlock efficiencies and increase the adoptionof under-used vehicles. This would result in decreased congestion, improved environmental outcomes anda reduction of other transport externalities. These potential benefits remain untested at scale, andevidence to date has been mixed (Alyavina, Nikitas and Njoya, 2022; Hensher et al., 2020; ITF, 2021e;
Storme et al., 2020).
MaaS responds to two efficiency challenges

MaaS addresses two crucial efficiency challenges. The first is the physical and material friction travellers
face switching from one mode to another. These include inexistent or poorly co-ordinated infrastructurebased mobility services. Frictions also emerge from insufficient or non-existent wayfinding information,
physical distance or barriers between interchange points and lack of harmonised design standards
regarding access to vehicles, stations and interchange points. In addition, the lack of co-ordinated planningaround the configuration of MaaS-relevant parts of the public realm, including kerbside access, sidewalks
and parking, can cause friction. Therefore, necessary pre-conditions for the uptake of MaaS include quality
mobility services and the infrastructure on which they operate.
The second component comprises the digital interconnections among mobility service providers’wayfinding, operating, scheduling, payment, consumer-facing interfaces and customer information
systems. These form part of the data infrastructure that virtually integrates services into a seamless digitaltravel experience.
Increasing levels of digital integration reduces people’s cognitive processing to undertake multi-modal
journeys (Figure 3). The less cognitive processing required for intermodal trips, the more compelling these
become compared to single-mode journeys (Alonso-González et al., 2020; Durand et al., 2018; Lyons,Hammond and Mackay, 2020). This is true for car trips but potentially also for other types of single-mode
travel (e.g. active mobility or public transport). There are limits to how much digital integration can change
behaviour. As noted above, better digital integration will not overcome poor-quality mobility services orpoorly linked infrastructure.
Similarly, travel behaviours that are ingrained and habitual will likely not be changed via digital integration
alone (Alonso-González et al., 2020; Durand et al., 2018). Nonetheless, this layer promises to overcome
20

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

the siloed nature of different mobility services and create efficiencies by improving the matching of travel
demand to the broad range of capacity available to satisfy trip needs. This data infrastructure layer is at
the core of the MaaS value proposition.
Figure 3. MaaS behaviour change – the relationship between MaaS integration levels and cognitive load

highCognitive load

Level 0No
integration

Level 1
Basic
integration

Level 2
Limitedintegration

Level 3
Partialintegration

no operational,
informational orTransactional
integration acrossmodes

informational
integration across(some) modes

no operational,
informational ortransactional
integration acrossmodes

some journeys
offer a fully
integrated
experiencelow

Level 4Full
integration
undercertainconditions
some but not allavailable modal
combinations offer
a fully integrated
experience

Level 5Full
integration
under allconditions
full operational,
informational andtransactional
Integration acrossmodes for all
journeys

Source: adapted from Lyons, Hammond and Mackay, 2020.

MaaS is delivered via an ecosystem

MaaS emerges from the interactions between actors and infrastructures in a loose ecosystem. The core
MaaS ecosystem encompasses four main types of actors operating on one form of infrastructure(Figure 4).
At the centre of the MaaS ecosystem are individual travellers. MaaS offers are meant to cater to travellers’
needs, preferences and budgets and are designed so that they find those offers at least as compelling, if
not more compelling, as travelling by single modes.
Finding a compelling offer for people is not straightforward because there is no single “traveller”. People
travelling display a wide range of characteristics (e.g. needs, preferences and budgets) (Alonso-González
et al., 2020; Durand et al., 2018; Hensher, 2022; Hensher and Xi, 2022). MaaS offers that are compellingenough to switch some travellers’ behaviours may be uneconomic to offer on commercial terms.
Conversely, commercial offers from MaaS providers may be unaffordable for many people.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

21

MOBILITY DATA INFRASTRUCTURE AND MAAS

Figure 4. The MaaS ecosystemP

MaaS requires mobility services
that people can ride on or in.
Mobility operators provide theseeither on commercial or public
terms.

P

MaaS providers create bundledoffers on the basis of themobility operators’ services.
Mobility operators may also be
MaaS providers.

P

At the heart of the MaaS ecosystem is the user –e.g. people with their own characteristics andtravel preferences seeking a convenient,affordable and stress-free travel experience.

`P

Data intermediaries may act as ago-between among mobility
operators and MaaS providers
and help de-risk data-sharing
among potential competitors.

P

Data sharing practices, methods,
protocols and syntaxes enablejoined-up trips to take place. Thisdata sharing infrastructure iscentral to MaaS.

Travel behaviour and travel decisions are rarely straightforward; they result from multiple arbitrations
among several factors and opportunities or constraints (ITF, 2021e). Individuals’ characteristics matter,though they alone do not determine travel choices. How people make decisions also matters. Humandecision-making is complex. A lot of human behaviour involves avoiding choosing, and some widely used
decision-making models – like rational choice models – often fail at the individual level, even if theyfunction at the aggregate level. People also make decisions based on the costs, constraints and inherent
or operational characteristics of different mobility services and modes available to them.
Finally, people make decisions based on what is, what is not or what is only difficultly possible. If the“system of provision” for transport incentivises car use, for example, it will be challenging to get people tochoose MaaS offers (Mattioli et al., 2020) unless the ensemble of norms, built environment and practices
is adjusted. Individual car use must be de-prioritised where it is most problematic and burdensome, andother transport services must be improved so they become intrinsically more attractive. MaaS is not
required for both of these things to happen – indeed, these two strategies have been pursued for decades
in many regions. But unless these two strategies are pursued, the attractiveness of MaaS will always palecompared to other alternatives – foremost with individual car use (Hensher, 2022; ITF, 2021d; 2021f).
MaaS requires the mobility services mobility operators provide. These services are offered on commercial
terms (like many forms of micromobility, ride-sourcing, car-sharing and ride-pooling), as public transport
services where the burden of public service obligations and fare-setting requirements are offset by public

22

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

subsidy or as different hybrid forms of service delivery (as with taxis in some jurisdictions). Mobility
operators must typically obtain a license or permission to operate from local or regional authorities.
MaaS providers – either public or private – create joined-up travel offers based on the services provided
by mobility operators. They must therefore have access to certain types of mobility operator data, enablingthem to plan, book and deliver seamless multi-modal trips to their clients. MaaS providers may be “pureplatform players” in that they only provide MaaS services without direct or exclusive links to the provisionof mobility services. Alternatively, they may operate under a hybrid model providing both vehicle-based
mobility services and digital MaaS offers. Special provisions may be required to ensure that such an
operation does not lead to anti-competitive behaviours or outcomes (ITF, 2021a). MaaS providers should
face comparable licensing requirements such as those faced by mobility operators with respect to data
sharing. However, these should be light-touch at the outset to enable adequate monitoring without stifling
innovation in an untested market where durable business models have yet to emerge (see ITF, 2021a for
ITF’s guiding principles for MaaS regulation).
Data intermediaries, integrators and other third-party service providers also play a role in the MaaS
ecosystem – especially in the absence of compulsory data sharing requirements among ecosystem actors.
Data intermediaries help avoid risks linked to sharing potentially commercially sensitive data among
ecosystem actors. They act as go-betweens among mobility operators and between mobility operatorsand MaaS providers and ensure that data sharing in the ecosystem is not prejudicial to the interests ofindividual ecosystem actors. This de-risking role may become less relevant if, over time, automated,
code-based and transactional data processing and intermediation are built into the MaaS data sharingarchitecture (ITF, 2018a). Data intermediaries might then pivot towards enriching data to the benefit ofstakeholders (e.g., working on data quality so that it is more accurate and meaningful to travellers).
The data infrastructure that enables MaaS is also part of the ecosystem. There is no MaaS without data or,more specifically, without data sharing among all MaaS stakeholders. The ease that MaaS promises fortravellers via a convenient user experience delivered by a customer-facing user interface builds on atremendously complex back-office exchange of sometimes sensitive information amongst different actors.
Data and the knowledge derived from its collection, processing and analysis have been a necessarycomponent of the delivery of any mobility service. The data collected includes data regarding the locationof static and moving assets, the scheduled or real-time operation of services, prices and payment clearing,access rights and customer profiles. What MaaS changes is the need to share this data among other actors
in the broader mobility ecosystem to provide joined-up services for travellers.
MaaS requires appropriate data governance by public authorities

Delivering MaaS will require an appropriate data governance framework that guides data sharing in a waythat enables remunerative business models, provides a compelling experience for travellers and maximisessocial welfare outcomes (ITF, 2021a; Pangbourne et al., 2018). Both commercial operators and publicauthorities are interested in MaaS but do not necessarily share the same motivations for its deployment.
Commercial operators hope to establish successful commercial offers, and public authorities hope toleverage MaaS to improve efficiencies and contribute to better transport outcomes. Both haveconcentrated on what opportunities MaaS represents for them individually. Although MaaS could deliver
on both points, this is not a given without purposive design and guidance. As with other foundational
infrastructures, public authorities have a role in framing, monitoring and, in some fundamental ways,
regulating data sharing for the public good. This report discusses the challenges of doing this and provides
guidance and principles to ensure that data sharing for MaaS benefits societal well-being.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

23

MOBILITY DATA INFRASTRUCTURE AND MAAS

The MaaS ecosystem enables a secondary market for mobility services

Mobility operators produce mobility – that is, they produce a service comprised of access to a vehicle fora set distance or amount of time, which enables a customer to get from one point to another. In return,mobility operators are paid by the customer or receive a public subsidy, or a combination of both.
Producing this service requires a capital outlay for vehicles and supporting hardware (e.g. IT systems) and,in some cases, infrastructure (e.g. stations, bus stops, shared bicycle docks). It also requires outlays forstaff to operate the service and maintain the assets and infrastructure. Combined, all of these enable theprimary market for mobility service provision, in short, the market for rides. It is a market where publicly
subsidised and commercially operated services co-exist in various degrees of government oversightand control.
The integration of rides by MaaS providers can be seen as a complimentary, secondary or aftermarket ofthe primary mobility market for rides. It is a market characterised by multiple scales and geographic
extents. A public transport operator may have a dominant market position for mobility service provision
locally. In contrast, a global search and mapping engine may hold a dominant global position for trip
planning and routing. This market also features traditional network industries that are overlaid and mergedwith emerging features of digital networks. It is also an ecosystem in which third-party service providers
may handle MaaS provider services themselves (e.g. establishing and authenticating identity, payment,
and route-finding). All of this complicates and, in many instances, limits recourse to traditional market
oversight and control mechanisms (Bourreau, Krämer and Buiten, 2022; Cremer, de Montjoye andSchweitzer, 2019; de Streel, Krämer and Senellart, 2021; Montero and Finger, 2021b; OECD, 2021b).
The ongoing effects of digitalisation on primary and secondary mobility markets are still poorly understood– partly because they have not entirely played out as digitalisation continues to generate far-reaching
impacts (Cremer, de Montjoye and Schweitzer, 2019; Montero and Finger, 2021b). This uncertainty calls
for a cautious but outcome-oriented approach that seeks to ensure that the benefits derived fromsecondary markets enabled by digitalisation are delivered without eroding public policy outcomes (ITF,
2021a). In the case of MaaS, such an approach should seek to establish and open the secondary market
for MaaS provision while ensuring that public authorities retain, or even strengthen, their ability to guideand shape the market to support the mandates citizens have given them.
In what way is MaaS similar to other secondary markets?

Secondary markets in sectors like electricity, telecommunications, banking, health and airline reservations
share similarities with MaaS in urban mobility.
Technological and regulatory evolutions
Recent progress in digitalisation across electricity, telecoms, banking, health and other sectors and theavailability of connected devices (e.g. smartphones, smart meters) has given rise to secondary markets for
new products and services in various sectors. For example, in the banking sector, many countries have
implemented reforms and established regulations to limit customer lock-in, actively enhance competition,and develop downstream markets. Open banking reforms (e.g. the Revised Payment Services Directive inEurope, the UK Open Banking framework, the Consumer Data Right regime in Australia and the Dodd-FrankAct in the United States) outline specific and mandatory data sharing and data portability requirementsthat encourage competition and empower consumers (Borgogno and Colangelo, 2019; de Streel, Krämer
and Senellart, 2021; OECD, 2021b).

24

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

Data sharing models
Data sharing strategies are implemented as a way to promote innovation, to cope with sectoral challenges
or as a remedy to restore competition in digital markets. Just as MaaS cannot exist without data sharing
and access between mobility operators and MaaS providers, new payment services cannot exist if banks
do not share their data with third-party providers. The air travel industry was a precursor in that it
implemented data sharing strategies and data specifications in the 1960s to facilitate multi-leg trips
involving other airlines (Teal et al., 2020).
Data sharing and portability regulations
Various regulatory regimes apply for public and private data sharing. In Europe, the Open Data Directive(2019) requires that documents held by public sector bodies that fall under the scope of a public task (e.g.
public service operation) “shall be re-usable for commercial and non-commercial purposes” (European
Commission, 2019). Other sectoral regulations imposed data sharing rules on market actors. For instance,in Europe, the Revised Payment Service Directive (PSD2) in 2015 for the banking sector or the New
Electricity Directive in 2019 introduced provisions to ease access to consumer data (Feasey and de Streel,2020). At the same time, In Europe, the General Data Protection Regulation (GDPR) applies to any
organisation (e.g. public or private) that provides a service or supplies goods to customers or businesses
in the EU.
Open market
New digital actors (e.g. micromobility companies, journey planners, Fintechs) have disrupted incumbent
actors across many sectors (e.g. banks, electricity producers, public transport). The opportunity to accessa service anytime, anywhere, constituted a paradigm shift for once very static and inflexible relationships.
At the same time, mobile technology and progress in payment solutions eased the possibility of accessing
and paying for these services.
Access to assets
Infrastructure managers historically provided the service linked with infrastructure. Transport
infrastructure managers and electricity producers managed the infrastructure (e.g. roads, transport,
power plants) and provided a service simultaneously (e.g. energy supply, loan, bank account,transport service). Now, service providers do not necessarily have to own or manage the infrastructure
to provide a service in these sectors. Like MaaS services providers, who do not have to own theinfrastructure or vehicles, electricity suppliers do not necessarily manage power plants or electricity
distribution infrastructure.
Indirect sales channels/resell services
MaaS providers should be able to resell services, such as public transport tickets, as part of their offer (ITF,
2021h). In this context, the MaaS service provider acts as a middleman between the service operator andthe customer. The same situation exists in the electricity market, where suppliers buy electricity on thewholesale electricity market from producers. Similarly, Online Travel Agencies (OTAs) acting as MaaS
providers allow customers to search for and book various services online in the travel sector. They act as
resellers on behalf of the service provider. To that end, OTAs are integrated into a Global Distribution
System (GDS), which combines multi-modal offers and those relating to other domains (e.g. lodging, tours).
In what ways is MaaS dissimilar to other secondary markets?

Unlike many other network industries, urban transport – and thus MaaS – is characterised by strong public
involvement. This is because poor or lack of access to transport options limits access to amenities such as

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

25

MOBILITY DATA INFRASTRUCTURE AND MAAS

education, jobs and health facilities (ITF, 2017). Also, given that the most prominent infrastructure in cities
is related to transport, a change in transport demand (e.g. number of trips, modal share) will impact theuse and allocation of city space (ITF, 2022).
Many public authorities view public transport as essential to reaching public policy objectives, and thus itis subsidised via public service obligation (PSO) arrangements (see glossary). PSO schemes can take many
forms: public authorities can impose a certain level of service (e.g. essential services, frequency, minimum
hours of service), provide a service in a particular area (e.g. route coverage), introduce special tariffs for
specific users (e.g. lower-income population, elderly, disabled people, children). They can be found inmany regions, such as the United States, Australia and Europe.
MaaS trip offers have been complex, notably due to the prominent role and status of public transport inurban mobility (Valdani Vicari & Associati, 2019). Part of this complexity arises because public authorities
influence the prices of PSO services. In other network industries like electricity or telecoms, the price for aservice typically equals the production cost for a service (e.g. all direct and indirect costs) and a reasonablemargin. The emerging MaaS ecosystem is a hybrid one in that while all market actors compete forpassengers, some of them (e.g. public transport notably) can rely on public support.
The rationale behind the subsidisation of public transport is threefold. First, subsidisation aims to ensure
a certain level of service that would typically not be provided by the private sector. Second, it seeks toincentivise public transport use to encourage modal shifts. Finally, it aims to improve social equity andaccessibility by enabling vulnerable public and lower-income groups to use public transport (ITF, 2013;
O'Callaghan, 2017).
The integration of public and private ticketing services is also complex. Demand-side subsidies (e.g.
concessional fares) allow public transport authorities and operators to reduce the price of the service forthe customer. Public Transport Authorities (PTAs) historically issue “tickets”, i.e. contracts between
passengers and the service provider. Depending on its policy objectives, the PTA applies special tariffs for
specific groups or in particular areas (UITP, 2020a). Non-PSO undertakings have limited access to the public
ticketing market and face difficulty selling public transport tickets. The price structure for the same service
may vary depending on whether the service is subsidised.
A further difference with other “pure player” digital markets is that MaaS (and mobility services moregenerally) combines a digital layer and physical services (mobility) with real-world impacts. This is unlike
many digital platform-based markets where the digital layer is linked to the consumption of digital services(e.g. online posts, likes, streaming content). Arguably, some digital platforms also express such hybrid
cyber-physical architectures. A search engine can influence a travel decision with real-world impacts, justas purchasing goods via a digital market platform results in the movement of vehicles in the real world.
Nonetheless, digital market regulation typically employs a competition policy lens to focus on first-order“virtual” impacts of transactions occurring in the digital layer. However, in some cases, as with MaaS, it
isn't easy to disentangle digital outcomes from those occurring in regulated spaces in the real world. These
outcomes can relate to mobility service provision or address transport efficiency, equity andenvironmental performance.
The coupling of digital and real-world outcomes inherent in MaaS suggests two things. The first is that
MaaS alone cannot deliver integration and interoperability. Data sharing gives rise to MaaS, but if that
integration is not mirrored in the real world – for example, in terms of the physical ease of connection
between different trip leg components – then MaaS will not be adopted by people. The second is that
MaaS may impact multiple desired policy outcomes – particularly regarding accessibility and sustainability.
But, again, these outcomes should be enabled by the broader regulatory context around mobility. For
example, building sustainability nudges into MaaS applications makes little sense if they are not supported
26

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MOBILITY DATA INFRASTRUCTURE AND MAAS

by the physical context in which people travel. An in-app push to choose public transport or cycling-based
options, for example, will not necessarily translate into more public transport or cycling use if these modes
do not match people’s needs, expectations or travel experiences.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

27

DATA SHARING … AND SHARING DATA FOR MAAS

Data sharing … and sharing data for MaaS
Data sharing refers to the distribution of data resources across multiple actors in a market. Without data
sharing, data cannot circulate across market stakeholders. This section discusses why data sharing is crucial
for MaaS and how data sharing governance frameworks may be designed to consider the multiple
dimensions of mobility data.

The public and private value of data sharing
Evidence shows that non-collusive data sharing between market actors and data reuse contributes togrowth opportunities and creates wider societal benefits. Positive impacts of data sharing can be direct(e.g. for those sharing the data), indirect (e.g. for those reusing the information), or induced (e.g. wider
impacts) (OECD 2019a). OECD (2019a; 2020) suggests that sharing data can increase value for data users
from 10 to 20 times and generate more value for the wider economy (20 to 50 times). Data sharing canact as a lever to generate a net increase in gross domestic product (GDP) between 0.1% and 1.5% of GDP
with public-sector data only, between 1% and 2.5%, including private-sector data (OECD, 2019a).
Data sharing enables different types of socio-economic benefits. Among these, data access and sharing
improve transparency and empower market actors. Data sharing can also generate market opportunities
for companies (e.g. data controllers, data processors, data intermediaries), foster co-operation, andstimulate competition between market actors. In London, Transport for London (TfL) open data benefitted
app developers based in London. Annual revenues attributable to TfL open data reuse were estimatedbetween £120 million and £160 million (indirect benefits). At the same time, cost savings (direct benefits)were estimated to be between £0.9 million and £1.725 million per year (Deloitte, 2017). Data sharing
agreements with data companies and service providers brought new insights to TfL and allowed it toimprove its operations (Carey, 2022).
Understanding data sharing value is complex, given the specificity of different data assets. The value ofdata sharing is closely linked with the data itself and its characteristics. Similar shared datasets may havedifferent values. According to the International Association of Public Transport (UITP), the value of data
sharing depends on five main factors: the object of the dataset (i.e. what it describes), its quantity (i.e.
data coverage), quality (i.e. accuracy, validity), granularity (i.e. aggregated or raw), and its access (i.e. open,
restricted, file or API) (UITP, 2020b).
Data sharing valuation methods can provide an appreciation of the different benefits of data sharing.
Reducing the uncertainty around data sharing value is crucial to unlocking data sharing and, thus, its fullpotential. Notably, the value of data sharing will depend on the perspective taken (e.g. from the owner ofthe data or the data user) and the valuation method used (Infocomm Media Development Authority, 2019;
UITP, 2020b).

28

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

DATA SHARING … AND SHARING DATA FOR MAAS

Sharing data for MaaS
Enabling a purposive, actionable, privacy-preserving and commercially relevant data sharing framework
within the MaaS ecosystem requires addressing three key questions (Figure 5):
1. What data to share?
2. How to share that data?
3. How to handle shared data?
Figure 5. Data sharing for MaaS must address three essential questions

What data to share?

How to share that data?

How to handle shared data?

Data heterogeneity
Data relevant for MaaS
Functional categories

Data portability and interoperability
Data pooling/exposure mechanisms
Conditional data access
Shared data “blocks”

Data handling protocols
Data retention, destruction, aggregation
Tokenised/encrypted data handling

Understanding the multiple dimensions of MaaS-relevant data
There are several aspects to consider regarding mobility data when answering these three questions anddesigning data governance frameworks. In the context of MaaS, these relate to how the data is sourced,
the nature of the data, its function or use, who has access to it and under what conditions (Figure 6).
Data sourcing

Data can be sourced from people providing it directly and voluntarily, via observation or as knowledge
obtained by inference via data analytics (Cremer, de Montjoye and Schweitzer, 2019; Krämer, 2021a).
People explicitly volunteer data by directly inputting data pertaining to them into systems. A typicalexample is when people register for a service or to gain access to rights. Volunteered data requires a
specific data capture mechanism (e.g. a form or an interface) and updating from data subjects. Bothrequirements may introduce friction in data collection efforts and barriers to registration and access rights.
Data may no longer be accurate if not updated, and different data controllers may hold other data
regarding the same data subject, some of which may be erroneous.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

29

DATA SHARING … AND SHARING DATA FOR MAAS

Figure 6. The different facets of mobility data
SourceNatureFunction

How is the data sourced?

To who or what does thedata pertain?

What purpose does thedata serve?

Who has access to the data
and under what conditions?

Personal

Informational

ClosedData that can be linked
directly or indirectly tonatural persons –including
direct identifiers, location,or other factors.

Data that supports theplanning, scheduling orcoordination of trips.

Volunteered
Data that is explicitly andintentionally revealed by anatural person (e.g.
identity or contact details).

Observed
Data that is collected frominteraction with a service
or a device (e.g. location
data , trip history, travel
schedule).

Inferred
Knowledge that is derived
from combining
volunteered and observed
data – and other inferreddata – and applying
analytical processing to it.

Non-Personal
Data which is not or cannot
be linked to natural persons–either because there is nolink or because it has been
robustly de-identified.

Commecially sensitive
Data which pertains to theability for economic agentsto compete in markets –e.g.
that is commerciallyvaluable, known to limited
people, and/or subject toconfidentiality agreements.

Operational

AccessData that is only available
to the data controller
parties designated by thedata controller.

Data supporting thefulfillment
of
travelservices (e.g. vehicle or
station access rights,
continuity management
for multi-leg trips, etc).

RestrictedTransactional

Data that is available toparties other than the data
controller under no set
conditions.

Data that enable people
to book and pay forservices and allows
revenues to beredistributed among
service providers.

Data that is available toparties other than the data
controller under specificconditions.

Open

Source: based on Cremer, de Montjoye and Schweitzer (2019); ITF (2019; 2021c); Lyons, Hammond and Mackay(2020); OECD (2019a).

Data can be collected by observation, monitoring or logging. Data may be collected from sensors, including
embarked global positioning chips in mobile handsets or video data, from logging human-machineinteractions or any other observational means. Observed data reveal information about data subjects asthey move and interact in the real or virtual world and is often collected unbeknownst to them. These data
are richer than volunteered data, and their collection favours actors who have invested in widespreadsensing and data-logging networks.
Finally, valuable knowledge can be derived by inference. This knowledge is qualitatively different fromvolunteered and observed data in that it does not exist without active human interpretation or, more
likely, algorithmic and increasingly artificial intelligence-based data analytics and processing.
The nature of mobility data

Data may be personal, non-personal or commercially sensitive (Figure 6). Personal and commerciallysensitive data bear unique risks and require adapted collection, handling, sharing and storage protocols.
Personal (and sensitive) data

MaaS activities involve sharing a wide array of personal data. This data pertains to customers (e.g. identity,
gender, age), travel activity (e.g. geolocation, trip history), and payment details (e.g. information required
to complete a transaction). Basic anonymisation techniques (e.g., generalisation and randomisation) do
not prevent the re-identification of people and thus do not mitigate personal data risks (ITF, 2015; 2016;2019; 2020; 2021c). Article 29 Data Protection Working Party (A29WP) states, “identification not onlymeans the possibility of retrieving a person’s name and/or address, but also includes potential
30

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

DATA SHARING … AND SHARING DATA FOR MAAS

identifiability by singling out, linkability and inference” (Data Protection Working Party, 2014; Finck andPallas, 2020). These re-identification techniques constitute a potential risk for individuals. Singling out is
an isolation technique to identify an individual in a dataset. Data inference refers to the possibility ofdeducing a specific insight from data. Finally, linkability refers to the ability to match two records of thesame data subjects. Re-identification results from the intentional processing of observed or volunteered
data that may relate to an individual or a device they use (ITF, 2021d).
Re-identification represents a significant and consequential risk for personal data, especially in transportwith location-based data sharing. Evidence shows that it may be possible to re-identify individuals’ travel
patterns from anonymised datasets. Thus, there is a need to complement anonymisation with additional
mechanisms to protect de-identified information (ITF, 2016; 2019; OECD, 2019a). Establishing
independent review bodies to evaluate the adequacy of data security, contractual provisions binding data
receivers to security rules and practices, and security audits can constitute strong measures to prevent the
re-identification of data.
Moreover, authorities should adopt a prudent approach regarding what constitutes personal data. Wherea potential re-identification pathway exists, a precautionary approach would require considering such data
as personal, thus requiring extensive privacy protection. Irreversibly de-identified data should not be
regarded as personal (ITF, 2021c) and, therefore, should fall outside of the scope of personal dataprotection regulations (e.g. GDPR) (Recital 26, GDPR) (European Commission, 2016).
Risks associated with breaches of MaaS-related personal data vary in severity and probability. Individuals
could lose control over the data they share (e.g. who uses it, how they use it). This risk increases as data
are shared across multiple third-party data processors and jurisdictions. Loss of control over data may
discourage individuals from sharing their data or using particular digital-related technology (OECD, 2019a).
One way to minimise these risks is by designing privacy-preserving data sharing mechanisms, including
ensuring that de-identified or non-personal data is used by default for all but the particular cases where
personal data is essential. For instance, in response to a data breach of Swiss public transport operator
Postbus’ TicketControl data platform (The Daily Swig, 2022), researchers recommended that data
platforms should, at a minimum, implement authorisation checks and, if necessary, apply a “least-privilege
principle” where the system grants authorised users the minimal required functionality to achieve theirtask (Gegick and Barnum, 2005). Another way is to develop distributed ledger-based approaches to ensurethat personal data, even when shared, is never exposed to non-authorised or vetted actors (ITF, 2018a).
Commercially sensitive data

Sharing commercially sensitive data exposes an organisation to digital security threats similar to personal
data and privacy risks for individuals (OECD, 2019a). The unintended release of data can also be associatedwith reputational damage and financial loss for corporate or institutional data holders. The strategic
importance of transport for the economy and national security makes the sector a target of cyber-attacks.
Evidence suggests that transport organisations are more vulnerable to cyber-security threats as attacks on
databases and IT systems increase (Huber, 2022).
Data holders may also be wary that sharing commercially sensitive data will give a cutting-edge competitive
advantage to potential competitors in the market. This risk is more acute within uneven competition wherecertain market actors have data sharing requirements while others do not. In the short term, the risk isthat the initial data sharer could lose contracts. In the longer term, data holders may be wary of thepotential socio-economic damage data sharing could cause to their business (e.g. fewer contracts and jobloss) (Nielsen et al., 2021).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

31

DATA SHARING … AND SHARING DATA FOR MAAS

Inaccurate or wrong use of data can cause potential reputation damage to the original data holder. The
lack of trust between market actors can exacerbate this type of risk. Data holders can be reluctant to share
their data, fearing they could be held responsible for another market actor’s improper use of the data they
initially shared. Like individuals, market actors can fear losing control over how their data are used once
they are shared. Data sharing agreements constitute a good practice for mitigating potential liability risks.
This type of contractual agreement can include details on the role of each party (e.g. data sharer,
processor, user), the rules associated with data at each stage of the process (e.g. deletion, anonymisation
rules), and the type of standard used (Information Commissioner’s Office, 2022a).
The function of mobility data

In the context of MaaS, data may relate to planning, routing and co-ordinating trips. It may be necessary
for the operational delivery of joined-up trips or be transactional, covering trip booking, payment andrevenue aspects (Figure 6).
Informational data

Informational data relates to the availability of mobility services. It covers asset/vehicle identity, location,
service type, schedule information or latency in the case of non-scheduled services, for instance. It may
also include routing and navigation information for a specific customer-initiated trip request. These data
represent the information necessary to select a trip option and are generally not technically challenging
to provide (though it is not costless). As it comprises largely publicly available data, sharing informational
data is not usually seen as a significant source of commercial risk. However, many mobility operators fearlosing a direct relationship with their clients if a MaaS provider initiates requests for informational data.
Operational data

Operational data relates to the physical joining of different mobility operator services in a single trip. This
may relate to access rights and the seamless integration of access protocols (e.g. vehicle access andunlocking protocols, gate-based station access versus contactless station access). Poor operational
integration leads to greater interchange penalties as travellers must overcome unjoined or poorly linked
legs of multi-modal journeys. Operational integration is more complicated to carry out than informational
integration. This is primarily because of sunk investments in data systems and associated hardware thatmust be retrofitted to ensure seamless interoperability. For this reason, mobility operators are often
unwilling to pursue operational integration unless they feel they would derive clear benefits from doing so
and that these benefits are greater than the investment required. Public authorities have often required
sharing operational data or facilitated operational integration among public transport operators, expecting
these benefits to generate overall improvements in consumer and societal welfare.
Transactional data

Transactional data relates to trip booking, payment and revenue allocation. Mobility operators see thisdata as extremely sensitive from a commercial perspective, not only because it may include priceinformation and be used to derive insights into market activity and turnover but also because it enables
MaaS providers to enter into and maintain direct relationships with their customers. For this reason, manymarket actors have been reticent to share these data or to allow broad transactional integration. These
data could enable a range of transactional integration. It can go from no integration to reciprocal (or not)deep-linking to other mobility operator booking and payment protocols and, finally, to fully integrated
in-app booking and payment for all mobility operator services in MaaS provider interfaces. The current
revision of the EU ITS Directive specifically targets obligations to open and share data enabling
cross-service booking and payment.

32

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

DATA SHARING … AND SHARING DATA FOR MAAS

Access to mobility data

Finally, data access rights differ across the MaaS ecosystem (and elsewhere) (Figure 6). Much of the data
held by mobility operators, MaaS providers and ticketing service providers are “closed” data – that is, only
available to the data controller or parties granted access rights. In some jurisdictions where personal dataprotection rules are in place, data subjects may also have access and control over data concerning them.
This is the case in the European Union, where GDPR defines a data access right for data subjects to theirpersonal data (or a right to designate the transfer of that data to a third party).
Data may be shared under specific restrictions – for example, the data controller will share access to data
if the requesting party meets specific conditions and has legal standing to access that data. Such
conditional data sharing/access seems well-suited to the MaaS ecosystem, where actors seeking data fromother ecosystem participants should have established legal standing to use the data to deliver services.
Finally, data can be open – that is, accessible by all under no or very few conditions. There is a significant
move underway for public authorities to provide data unrestrictedly except in clearly defined cases wheresuch data is personal or meets agreed and defined thresholds for commercial sensitivity. Open data
policies promote transparency, accountability and value creation but may not be suitable for operationalor transactional data sharing and exchange.
“Open” should not be confused with “open source”. The former refers to how data access rights aredefined, and the latter to the accessibility, transparency and editability of software code and algorithms.
The source code of open-source software is public and, depending on its licence, can be freely copied,shared, edited and transformed. Shared data, open data and open source code – especially concerning
data syntaxes – are essential elements of foundational data infrastructure since they help maximise social
welfare outcomes (OECD, 2019b).

Why share what data? The economic and social welfare case
The value of data depends on how it is transformed into meaningful information and knowledge (Figure7). Raw data are purely descriptive. They capture a specific and often context-less state, such as a name, anumber or geographical co-ordinates. That data can have meaning assigned to it. For example, if the nameis associated with access rights or the number is linked to an action or a set of coordinates of a meaningfulplace. Once processed and interpreted, data generate valuable knowledge, like a person’s travel behaviour
and trip history. Combined with other data, this can provide predictive insight into likely future travel
behaviour (de Streel, Krämer and Senellart, 2021).
Volunteered and observed data are raw “inputs” to producing actionable inferred knowledge, which is thesource of competitive advantage and value creation in data-intensive digital markets (de Streel, Krämer
and Senellart, 2021; OECD, 2021b; Tucker, 2019).
What does this mean regarding mobility data, sharing and the governance of MaaS ecosystems?
There are risks that MaaS markets will foreclose if market actors unduly restrict access to raw data inputs.
From an economic perspective, these data are excludable. Data controllers may prevent the sharing ofdata via technical or legal restrictions. Yet, they are generally understood to be non-rival (meaning,
consuming data does not prevent others from consuming the same data). The consumption of non-rival
goods typically increases social welfare, so there is an economic and social argument for shared and open
access to those data (de Streel, Krämer and Senellart, 2021; Jones and Tonetti, 2019; OECD, 2021b).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

33

DATA SHARING … AND SHARING DATA FOR MAAS

Figure 7. From data to knowledge

Data“Hilary G.”“10”“44.40706835, 8.94675415”

Information

Knowledge“Hilary G. is a registered user”“Hilary G. has taken 10 metro trips“10 transport pass swipes”“Brignole Station, Genova, Italy”

in Genova starting at Brignole
Station. Based on her travel history,
the probability of her next trip
starting at Brignole being a leisureversus work trip is 75%”

Source: based on de Streel, Krämer and Senellart (2021).

There are, however, aspects of rivalry relating not to the consumption of data but to its collection– especially for observed (as opposed to volunteered) data (de Streel, Krämer and Senellart, 2021). These
aspects relate to the scale and scope of data collection and favour dominant actors, first movers and thosecollecting data across markets. They arise from fundamental asymmetries in the amount and breadth ofdata collected and processed among ecosystem actors. For example, mobility operators collect data
regarding where, when and how a person travelled. Though it would be theoretically possible for others
to collect that data by observation, doing so would be complicated and costly, especially if the mobility
operator is dominant and does not share that data (i.e. the data is excludable).
Similarly, local market actors may face difficulty duplicating observed data collected by a dominant global
search platform regarding destination search and travel routing. The status quo favours first movers andthose who benefit from substantial network effects within and outside of mobility and beyond local
contexts (Bourreau, Krämer and Buiten, 2022; de Streel, Krämer and Senellart, 2021; Hoffmann and
Gonzalez Otero, 2020; Kerber and Schweitzer, 2017; Krämer, 2021a; OECD, 2021b; Soriano et al., 2019;
Scott Morton et al., 2021).
A fundamental question in the data sharing debate concerning personal data is which of the three sourcesof data – volunteered, observed or inferred – should be shared? This is a simple question with a complex
answer. It relates to how different regulatory regimes interpret what constitutes personal data and what
control should be granted to people regarding data pertaining to them. It is also linked to data portability
requirements (discussed in the next chapter). A restrictive interpretation is that only volunteered data
should be shared (with the data subject’s consent). This approach acknowledges, among other things, thatdata controllers invest in data collection and thus should benefit from their investments. However, if datacollection (especially of observed data) is rival, there is an argument for a more expansive interpretationfrom a social welfare perspective. At the core of a broader interpretation is the recognition that observed
data is still personal data relating to a data subject (de Hert et al., 2018; de Streel, Krämer and Senellart,
2021; Krämer, 2021a; OECD, 2021c). Accordingly, the data subject should have agency to determine towhat purposes that data is put and with whom that data is shared.
This expansive interpretation is articulated in the guidance on personal data portability in the context of
the GDPR issued by the independent European advisory body on data protection and privacy. Article 29
Working Party (Art. 29 WP) states: “[data portability requirements] should also include the personal data

34

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

DATA SHARING … AND SHARING DATA FOR MAAS

that are observed from activities of users such as raw data processed by a smart meter or other types ofconnected objects, activity logs, history of website usage or search activities” (Art. 29 WP, 2016). De Hertet al. (2018) note that volunteered or observed data – including location data – that a data controller has
not processed should be shared (with data subject consent). These views reflect discussions around a
specific form of personal data sharing (i.e. personal data portability under the EU GDPR). Still, they reflect
an increasingly convergent view of what constitutes personal data and how it should be shared with user
consent and agency in digital markets (Krämer, 2021a).
The economic and social welfare case for a more expansive interpretation of which data to share in digitalmarkets, including MaaS, is linked to where value is created for market actors. De Streel, Krämer, andSenellart (2021) note that as raw data (e.g. volunteered but especially observed data) becomes moreshared, “the focus of competition is likely to move more from collection to analytics, which likely stimulates
innovation rather than stifling it. Indeed, as data collection is inherently concentrated and the services
through which (observed) data is collected usually exhibit strong network effects, a stronger competitionat the data analytics level (based on knowledge) seems much more feasible and desirable than competitionat the data collection level.”
Furthermore, fostering greater access to more data (volunteered and observed) improves the quality ofinferred data and, thus, its ability to contribute to value creation (Krämer, 2021a). From an overall welfare
perspective, shifting competition away from data collection and towards data analytics favours
consumer-centred innovation, particularly in the case of platform-mediated markets (de Streel, Krämer
and Senellart, 2021; Florez Ramos and Blind, 2020; Gal and Rubinfeld, 2019; OECD, 2021b). Ensuring broad
access to volunteered and observed data (via open data exposure mechanisms, portability requirements
and converging interoperability) is a cornerstone of foundational mobility data infrastructure.
Mandatory data sharing does incur specific risks. These relate to actors potentially removing incentives tocollect data in the first place and the costs associated with putting data sharing mechanisms in place. Thereis also the challenge for mobility operators, third-party data analytic firms and MaaS providers to develop
viable business models that generate value from data analytics, in contrast to simply extracting rents frommonopolies on data collection (de Streel, Krämer and Senellart, 2021; Florez Ramos and Blind, 2020; Gal
and Rubinfeld, 2019; OECD, 2019b, 2021b).
Another possibility is that data sharing – especially mandatory data sharing – will pose an asymmetric risk
to smaller actors and market entrants as opposed to larger and dominant market actors (de Hert et al.,2018; de Streel, Krämer and Senellart, 2021; Krämer, 2021a). Requiring smaller actors to expose their data
to larger actors may enable large actors to mobilise their greater network effects, resources and dominantmarket position to the detriment of smaller actors. It is this risk that leads regulatory initiatives like theEU’s Digital Markets Act to target dominant market players and market “gatekeepers” with asymmetricdata sharing requirements (EU, 2022b) or to pair mandatory data sharing with regulatory oversightmechanisms as with the EU Payment Services Directive (PSD2).
Data sharing should not be expansive in light of these risks. Rather, it should be limited and purposeful,such as being linked to specific desired and transparently communicated outcomes as specified, forexample, in the EU GDPR. A two-tiered approach to mobility data sharing would help to address theserisks. This means all actors would share a core set of data to enable trip planning and fulfilment. Other
supplementary data that could add value but are not necessary to deliver inter-modal trips would beshared on a negotiated and voluntary basis. Establishing public authority responsibility (either directly ordelegated to a neutral third party) for monitoring and tracking data sharing outcomes in the MaaS market
can also help assess if data sharing requirements deliver on desired policy outcomes.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

35

WHAT DATA TO SHARE FOR MAAS?

What data to share for MaaS?
From a traveller’s perspective, getting from one point to another is straightforward when only considering
walking and one additional transport mode. From a transport service provider or public authority
perspective, the task is more complicated, and decisions must be made over the long-term (investment),
medium-term (schedules and latency) and short-term (vehicle availability and access). This complexity
significantly increases when planning, organising and delivering the multi-leg and multi-modal trips at theheart of the MaaS value proposition. The complexity arises from the need to co-ordinate physical services
in response to travellers’ requests and, especially, to co-ordinate the multi-dimensional data flows
necessary for trip fulfilment. Supporting each phase of the trip cycle and delivering a seamless travel
experience for travellers requires access to a core set of essential data elements (Transportation Research
Board, 2020).
The functional blocks that make up MaaS

Breaking down complex data flows into functional blocks helps understand what data must be shared forwhich purpose and by whom. This approach is necessary to organise the digital interactions that enable
MaaS trips. Such a functional breakdown is inherent in any framework for interactions between mobility
operators and MaaS providers and is at the heart of many public or commercial MaaS platforms.
The MaaS Alliance identifies six core MaaS functionalities: register, plan, book, pay, travel and after sales(MaaS Alliance, 2021). Many operator and mode-specific data schemas and syntaxes exist (e.g. for public
transport, micromobility, carshare, parking), each handling these functionalities in their own ways
– sometimes calling on standardised approaches but often not. For MaaS to function well, a solid casemust be made that such a functional breakdown should be open, aligned and integrated across all MaaS
market actors.
The Transport Operator to MaaS Provider - Application Programming Interface (TOMP-API) (see Glossary
and Figure 8) is an example of a reference architecture that illustrates the types of functional blocks
inherent in the design of any MaaS system. TOMP-API, as its name suggests, is designed principally toenable data sharing between transport operators and MaaS providers to carry out joined-up trips. In thisway, it is different from other syntaxes, which are designed to report data to authorities (e.g. the Mobility
Data Specification) or to share information about the state of services without supporting on-trip
operational linkages between operators and with MaaS providers (e.g. The General Transit Feed
Specification [GTFS]).
Core functional blocks, such as those comprising TOMP-API (e.g. identification/registration, planning, asset
information, booking, trip execution, payment, support, operator information and potential external
modules), are distinct. Each block handles a specific outcome covering necessary sub-routines and dataflows. The architecture is modular, so changes in one block only require minimal, if any, changes in otherblocks. TOMP-API’s architecture provides an example of the type of data exchanges which enable or

36

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

WHAT DATA TO SHARE FOR MAAS?

support MaaS. Such modular architecture enables flexibility and extendibility and, in principle, allows
external (to the MaaS provider or mobility operator) service providers to fulfil these functionalities.
Figure 8. TOMP-API functional blocks for MaaS

MaaS Provider

Identification
Registration& Privacy

Planning

Booking

Trip
execution

Payment

SupportOperator
Information

Asset information

Asset information

Asset information

Mobility Operator A

Mobility Operator B

Mobility Operator C…

Additional
modules

External
modules(e.g. social
tariffs, ID,
Payment
processing)

Source: based on TOMP API (2020).

From functional blocks to microservices

The functional blocks described above encompass specific processes that must be linked to others todeliver MaaS. They describe stand-alone processes that require data inputs from multiple MaaS ecosystem
actors and generate data outputs for their use. There are two broad approaches to structuring
these blocks.
The first is to shape them as part of a unitary code base within a single software environment. The
advantage is that it is less complex to design and does not require a broader regulatory framework
governing market access and participation by various secondary service providers. However, it requires
multiple teams coding across an ever-growing code base that increases in complexity as it grows infunctionality. It also increases the risk of single points of failure due to the sharply intertwined nature of
the monolithic code (Karabey Aksakalli et al., 2021).
The second approach is to leverage functional block architecture to establish a series of “microservices”.
These are self-contained, linked to other microservices and open to being designed, implemented andmanaged by either mobility operators, MaaS providers or third-party service providers. The microservice
architectural approach disintermediates MaaS itself and establishes a series of secondary and tertiary
MaaS-supportive service-based markets that can generate efficiencies and innovation. Under thisapproach, the role of the MaaS provider shifts from the strict integration of mobility offers to theorchestration of MaaS-related microservices, some of which the MaaS provider may offer themselves. Key
to this microservice architectural model are the communication protocols used to communicate the status

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

37

WHAT DATA TO SHARE FOR MAAS?

of processes, transactions and states from one microservice to another (Callegati et al., 2017; ITF, 2019;
Karabey Aksakalli et al., 2021). More fundamentally, the decomposition of MaaS processes into
constitutive microservices helps map out the types of data sharing necessary to enable MaaS.
Microservice-based MaaS

Figure 9 illustrates the breakdown and sequential timing of the microservices that underpin MaaS. It shows
the data types that must be shared among microservices and, potentially, by different MaaS actors. It isagnostic as to who is responsible for implementing and delivering each microservice – a single actor could
manage all or a subset of these microservices. Alternatively, multiple actors could offer these services in a
thriving secondary or tertiary market for MaaS-related services. The functionalities of the microservices
and the kinds of data sharing they require are described below.
Figure 9. Microservices underpinning MaaS and their sequential timing
Pre-booking

Book Pre-trip Trip start On-trip

Trip end Post-trip

Registration services
Identity services
Authentication services
Account services
Planning services
Asset information services

Fare calculation service
Booking services“I wish to
travel from A
to B using a
MaaS app”

Fulfilling thiswish calls on
multiple microservices

D

Trip validation services

D

Wayfinding services
Payment services
Support services

D
D

D

D

…or…

…or…

D

D

Source: based on F. Burgersdijk, 2022, personal communication.

Registration, identification and authentication services

These services establish the identity of users and service providers and authenticate this information
during MaaS transactions. Registration allows users to create and sign in to their MaaS account orauthorise the MaaS provider to access users’ mobility operator accounts on their behalf. It also allows
service providers to establish their legal identity and rights to deliver services. Identity data must beauthenticated and used as the basis for gaining authorisation to access resources or act on behalf of anatural person. Identity, authentication and authorisation are separate but linked processes.
Identification and registration microservices may require other information, including information on a
traveller’s specific needs, characteristics or preferences. Data regarding disabilities and other trip-relevantcharacteristics would be covered here, as well as information relating to travellers’ preferences (e.g.
shared modes, maximum distance by foot, maximum number of transfers).

38

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

WHAT DATA TO SHARE FOR MAAS?

Identity and registration data are personal data, and some potentially included in this block are also
sensitive (data on disabilities or qualification for social fares). Further, linking natural persons to their travel
characteristics and preferences has commercial value. There is a strong imperative, therefore, to sharethese data only with the consent of the data subject (in some contexts, like in the EU under GDPR, this isa legal requirement).
There is also an imperative to ensure that the benefits of sharing commercially sensitive data outweighpotential adverse outcomes. There are technical means to ensure that the outcomes of sharing
identity-related data are met without sharing personal or commercially sensitive data among MaaS
ecosystem actors. These are discussed in the next chapter.
Account services

Account services determine how information for a specific account is updated, stored and shared to reflectchanges in the traveller’s status, their account or activity history and the rights conferred to them. It also
relates to how travellers can see and track their activity history. Because account services may have accessto detailed usage data (including trip histories), they also handle personal data.
Planning and asset information services

Trip-planning microservices enable travellers to explore trip options before they commit to one. It
integrates desired destinations, user characteristics, and preferences from other microservices. Trip
planning information includes estimated travel time, cost, and location of mobility services (e.g. stop,vehicles, infrastructure). This information combines scheduled and estimated service availability withreal-time routing, service schedule and latency data. Trip planning services can be “in-house”, meaning
the MaaS platform provides them, or third-party microservice providers can provide them.
Trip planning differs from booking. Planning refers to rapid search (e.g. when there is no intent yet to booka trip). To that end, it does not require strict accuracy but only suggests options and rapidly estimates
relative travel times, costs and conformity with traveller preferences. This stage does not entail thecreation of a mobility offer, but in some cases, the information returned by a planning query may contain“ready-to-book” options.
Trip planning microservices are linked to asset information microservices that describe the location ofassets (e.g. vehicle, service, infrastructure) and their ability to fulfil a trip at a given instant, for a given
amount of time (e.g. duration of the trip), and under given conditions (e.g. destination, number ofpassengers). Asset availability may refer to the state of a device (e.g. functioning, not functioning, state ofcharge) or the number or type of available seats (e.g. shared taxis, on-demand shuttles, accessibility forthe disabled). This microservice can also provide additional information on the service (e.g. type of vehicle,
equipment, etc.).
Both trip planning and asset information data are essential inputs to the planning and booking phase oftrip lifecycles. Thus, they form part of the core information (either in the form of data or verified status
messages) that all mobility operators should expose.
Fare calculation service

Fare calculation runs alongside the trip planning service and allows the MaaS provider to display the costof travel options offered to travellers. Fare calculation for multi-legged trips requires accessing informationfrom multiple “tariff owners” (those who set the prices for their services) and applying composite farecalculation methods (e.g. based on traveller characteristics such as age or income, subscriptions, rules
based on geography). Some fares are open to the public and are detailed alongside service descriptions,while others must be adjusted for several factors.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

39

WHAT DATA TO SHARE FOR MAAS?

Fare calculation is typically embedded in each mobility operator’s fare collection or ticketing platform.
However, standalone third-party fare calculation services can also deliver this service – perhaps even more
efficiently in multi-operator MaaS trips. Such an approach has been adopted in Switzerland for all public
transport journeys. The NOVA platform acts as a separate fare calculation module servicing all public
transport trips in the country (Eichhorn, 2020; Hansel, 2019).
Booking service

The booking microservice commits travellers to a specific option offered by the MaaS provider. A booking
can flow from the planning microservice or may be initiated directly when the traveller already has apreferred option in mind. Booking is a more complex process than planning a trip and requires greater
accuracy alongside service delivery commitments from mobility operators.
The booking microservice creates a unique booking identifier to be used with mobility operators and to
confirm the real-time availability of assets. If requested assets are available according to trip- and userspecific requirements, the booking service initiates a booking request which temporarily locks in assets
pending confirmation from the mobility operator. Before finalising confirmation, the mobility operator
may require user ID authentication, which, if successful, confirms the booking and commits the mobility
operator to deliver the requested trip leg. This happens under the condition that all other mobility
operators operating other linked trip segments also confirm their specific bookings initiated by the booking
service provider.
Booking requires a commitment by the user or the MaaS provider acting on the user’s behalf to purchasethe trip. Purchasing differs from payment as it does not include any financial transfer but pre-commits theuser to pay.
The flow of data and the processes enabling the booking of trips are essential for MaaS to function, so data
exposure enabling booking and processes guaranteeing bookings form part of the minimal data to beshared by MaaS ecosystem participants.
Validation services

Validation services grant travellers specific vehicle or service access authorisations once a trip commitment
has been made via a booking. Proof of booking (from the booking service) is then used to validate thetraveller as being the rightful user of the committed service.
In practice, a digital token or unique identifier is recognised by the mobility operator, and authorisation is
granted to the traveller to use the mobility service. This interaction is required at the start of the journey.
During the trip, the validation can be checked automatically or manually. At the end of the trip, the specificright to consume the mobility service offer expires and this closure must be validated as authentic.
End-of-trip confirmation is linked to other microservices, including account and payment services.
MaaS offers cannot function without trip status messages; thus, these form part of the information thatmobility operators and MaaS providers must expose. TOMP-API, for example, identifies five linked trip
execution states (TOMP-API, 2022):
1. Trip in preparation: This state refers to a trip that has been booked and committed but where theasset is being prepared for use (e.g. a taxi making its way to a user or while a rental car is being
prepped and cleaned before being released to a user). The trip preparation state is also whenaccess and location data are sent to the user.
2. Trip is underway (in use): The in-use state is triggered when a user has commenced travel.
Acknowledgement of this state can be communicated either by the mobility operator or the MaaS40

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

WHAT DATA TO SHARE FOR MAAS?

provider depending on the kind of booking, type of asset and trip initiation protocol (e.g. getting
on a bus vs unlocking a bicycle and starting to ride).
3. Trip is paused: Users or mobility operators may need to indicate that an ongoing trip has beenpaused. It may be necessary to apply different rates (e.g. for a parked vs a moving car).
4. Trip is finishing: This state reflects when an asset is no longer being used but before final clearance
has been processed. For example, this state would apply as the mobility operator verifies the stateof the vehicle or processes the final payment after the user has indicated the trip is complete. If
the trip execution requires closing an asset (e.g. dock a bike, return a car), the user should indicatethat they are stopping their trip. This message is transmitted directly to the MaaS provider or thetransport operator (with notification to the MaaS provider). In return, the user receives trip end
or lock instructions. Once the asset is closed (e.g. bike docked), the user app generates a trip-end
confirmation message which is transmitted to the MaaS provider and mobility operator.
5. Trip is finished: This state reflects a definitive finding by the mobility operator that the trip leg has
been completed, and no further processing or communication regarding the trip execution isnecessary. The MaaS provider can confirm a multi-leg trip has been completed when all mobility
operators have confirmed that each trip leg for which they had responsibility has been completed.
Once the final clearance process is over, the user should no longer be able to use the asset.
Wayfinding services

These services provide information to accompany travellers on-trip, including how to physically accessdifferent services during the trip. They are typically map-based but may also include specific text or auralcues. They communicate trip progression and trip status messages to travellers and can provide alternative
routing in response to trip disruptions and incidents while it is underway. Sometimes, wayfinding services
serve a secondary function as a conduit for communicating relevant wayposts along a traveller’s journeyback to service providers. Time-stamped location, for instance, can enable a service provider to ensurethat a trip occurs in a specific geographic area or within a determined time window.
Wayfinding services may require input from identification and account data to establish if specific needs
or preferences must be accounted for in the wayfinding cues given to the traveller. These cues may relate,for example, to wheelchair-accessible routes and vehicle access instructions or routes that fit a preference
for cycling on residential streets versus on dedicated infrastructure. Wayfinding services may also be linked
to trip planning, asset availability and booking services. Wayfinding data must be treated as personal datawhen it comprises privacy-sensitive time-stamped location data or traveller characteristics.
Payment services

From a customer perspective, payment should allow one seamless payment for the entire trip, even if it
includes different transport services. The user should be able to use various payment types (e.g.
subscription, pay-as-you-go, deposit). The mode of payment can later serve as means of access (e.g.
payment card) for the different legs of the trip. Payment may occur pre- or post-trip. The MaaS provider,either directly or as an orchestrator of other trip-related microservices, acts as a payment service initiator– the party that notifies when payment should occur.
The payment microservice communicates the status of prepayment for the different portions of the trip
(e.g. deposit, subscription) and the status of post-payments related to the trip (e.g. fines, penalties,
damages, refunds). Some businesses may use both the pre and post-payment model at the same time.
Mobility operators may request a deposit before the user books a valuable asset. In this case, if initially

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

41

WHAT DATA TO SHARE FOR MAAS?

agreed conditions are met (e.g. no damage, full battery or tank), these should be refunded via the MaaS
provider.
Sharing data on payment status is essential to confirm bookings and allow joined-up trips. As such, data
relating to these should be part of the minimal shared data allowing MaaS to function. Payment processing
is a related but separate task. Payment processing data (bank account balance, payment methods, identity,etc.) should not form part of the scope of shared data and should remain with payment processors.
However, it should be noted that payment processors may need, or have a right, to access individuals’
account data from banks and financial institutions (as in the case of EU financial institutions under theSecond Payment Services Directive – PSD2). Though, this falls outside of the scope of MaaS data sharing.
Support services

Support is a transversal function delivering technical assistance to users anytime during a trip, for example,
in response to incidents occurring in other functional blocks. The assistance process starts with the user’s
request for support, or an update is generated regarding the trip. The request may be handled directly by
the MaaS provider or the mobility operator or by an external microservice provider who then manages theincident and ensuing data flow between MaaS provider, mobility operator and traveller.
The issue may imply modifications to the initial trip. To that end, the support microservice may include
links to other microservices (e.g. planning, booking, payment and trip validation). Some support may benecessary after a trip has been completed. After-sales processes may imply refunds from the mobility
operator to the user. In this case, it is linked to the payment and account microservices. After-sales support
may include warranty services (e.g. damage on a shared vehicle), information on how to use a device (e.g.
code of conduct), or surveys. After-sales data reporting requirements may extend beyond trip support,
covering enforcement actions and gathering statistical data as outlined in the French Mobility Bill (French
Government, 2021).
Minimal data sharing

There are few incentives for first movers to provide access to and share their data if other MaaS ecosystem
actors do not do so themselves. This suggests a need to impose minimal data sharing requirements, so allvetted actors have equal access to the data necessary to deliver MaaS offers.
Minimal data sharing requirements should cover the type of travel agreement, including the service
description (type of transport in space and time), asset and service availability, compensation (price)
duration, terms and conditions; and information regarding the status of trips (e.g. booked, confirmed,
validated, concluded, paid).
As noted previously, minimum data sharing obligations also help address the rivalry of data collection (asopposed to data consumption) and have a pro-competitive effect if appropriate safeguards are in place.
Common data sharing requirements generate benefits but impose costs that not all actors can absorb
easily or at all.
In this respect, the design of data sharing mechanisms – particularly interoperability and data portability
requirements – is essential to minimising these costs.

42

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

How to share MaaS-relevant data?
Data sharing enables the MaaS ecosystem to generate value for all actors. Sharing data is both anaspiration – what mobility data governance should enable – and an outcome – what happens when aspecific set of policies, agreements and measures are implemented. From a policy perspective, it isessential to address data access rights and sharing responsibilities and consider how data interoperability
and portability are enacted (Hoffmann and Gonzalez Otero, 2020). The potential for data sharing to deliver
broad benefits is tied to several technical mechanisms that enable essential data to be shared in a
privacy-preserving, pro-competitive and secure way among market actors. This section addresses
these mechanisms.
Ensuring technical interoperability of cross-actor systems is a crucial concern for data sharing in supportof MaaS. This is the focus of this section, but it is not the only interoperability concern. How well actors
work together and the mechanisms they or others establish are also critical enablers of MaaS.

Technical aspects of integration, compatibility and data sharing
The technical mechanisms supporting data sharing relate to connectivity, data interoperability and data
portability (Figure 10).
Connectivity

Data can be shared in many ways. A letter, an email, a PDF file, a book and an API are all mechanisms forsharing data, but they are not equally shareable across multiple media and platforms. In the context of
MaaS, and more broadly with all digital services, data will likely be shared in digital formats. This
presupposes that different MaaS ecosystem actors can physically connect to each other’s systems – thatis, the bits and bytes comprising data and information can flow from one system to another. Thisconnection may be enabled through fibre-optic cables, WiFi or cellular networks. Without this connection,systems are offline and can only asynchronously interact until connectivity is re-established. Connectivity
is generally not a significant concern, especially in urban areas, as cellular and other networks are
ubiquitous and generally reliable. In some rural areas, this may not be the case. Thus, the pre-condition of
network and system connectivity may be a barrier to MaaS in those contexts (Banerjee, Jittrapirom andDangschat, 2021; Durand et al., 2022; Rudolph, 2019).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

43

HOW TO SHARE MAAS-RELEVANT DATA?

Figure 10. Technical aspects of data sharing: Connectivity, interoperability and portability

System connectivity
Are systems materially able to connect with each other?
Does this connectivity ensure low-latency interaction
among systems? Are people able to connect to systems?
Do they face challenges in doing so?

Protocol (schema) interoperability
Are systems able to interact with each other without undue friction
from incompatibilities - are schemas and data structures
mappable between systems?

=

Data (syntaxical) interoperability
Can data generated and used in one system be relatively
frictionlessly ingested and used by another system? Do
systems share common semantical meanings and aresyntaxes shared or compatible amongst systems?

Full (native) interoperability
Do standards, hardware and systems interact “natively”
and seamlessly amongst different systems? Can users of
one system use features of other systems, and vice-versa,
without any additional prompting or learning on their part?

Data portability
Do data controllers allow data subjects to access data
pertaining to them or to designate third parties whoshould have access to this data? Is this data transfer
made on a one-off or continuous basis?
Source: based on Bourreau, Krämer and Buiten (2022); Cremer, de Montjoye and Schweitzer (2019); de Streel,
Krämer and Senellart (2021); ITF (2021c); Krämer (2021a); OECD (2021b).

Interoperability

Interoperability and data portability questions arise once systems physically connect. Interoperability
broadly refers to how well systems can “work together” (Bourreau, Krämer and Buiten, 2022). In digitalmarkets, interoperability allows “system, product or service to function with other, technically different
systems, products or services” (Kerber and Schweitzer, 2017). Interoperability, and the lack of it, is often
at the heart of many competition policy discussions regarding market capture or openness (Borgogno andColangelo, 2019; Bourreau, Krämer and Buiten, 2022; OECD, 2021b; Scott Morton et al., 2021).
Improving interoperability and imposing personal data portability are often offered as solutions to avoid
consumer lock-in or excessive market power. Interoperability and data portability, however, are two
related but distinct mechanisms. Interoperability enables data to flow between and be ingested bydifferent systems to deliver joined outcomes. It is about the ability for data to be shared and systems towork together. Data portability is about what data is carried or allowed to flow from one system to anotherand under what conditions this occurs – it is about rights and responsibilities.
Closed or proprietary mechanisms may ensure interoperability, but this may concentrate power on the“owner” of the interoperability mechanism and may lock users in at the expense of continued innovation.

44

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

In contrast, open interoperability mechanisms, for example, those developed transparently via open
participation and governance frameworks and which produce open source and documented code, counter
these risks (Bourreau, Krämer, and Buiten 2022; Heuser et al. 2017; Hoffmann and Gonzalez Otero 2020;
Kerber and Schweitzer 2017; OECD 2021a; Scott Morton et al. 2021). Social value-maximisinginteroperability leverages open standards, is vendor agnostic, avoids prescriptive solutions or
technologies, is modular, can be developed incrementally and focuses on concrete and identified
outcomes (Heuser et al., 2017; MAAS Alliance, 2021).
Interoperability – and the data sharing it requires – should be equitable, but that does not mean thatsystems should be open to all or that all data should be shared with all. Equitable interoperability in thecontext of MaaS means that actors can join the MaaS ecosystem freely and participate in qualitatively
equivalent terms (Scott Morton et al., 2021). Interoperability, and the data sharing it requires, should notfavour dominant actors over others, especially when that actor deploys services that compete with thoseof other actors. Interoperability may be achieved at different levels, but the choice of where to focus
interoperability efforts will matter regarding how equitable that interoperability is and how well it aligns
with other societal objectives. The choice and design of interoperability and data sharing mechanisms also
matter as these open or constrain data access.
Interoperability can be split into three levels: protocol interoperability, data interoperability andfull interoperability.
Protocol interoperability

Protocol interoperability refers to how systems work together. Are data transfer protocols of one systemcompatible with those of another system? Do the systems operate on the same core software encoding
standards? Are the respective code bases of each system organised along the same schemas andarchitectures? Is the code well-referenced, documented and conforming to open and shared coding
standards? The more the systems can be mapped from one to another and interact without major (andcostly) re-interpretation and adaptation, the more interoperable they are.
Data interoperability

Data interoperability refers to the ability for data generated in one system to be frictionlessly (ideally inreal-time) ingested, processed and used in another system (and vice-versa). Data interoperability is at thecore of MaaS and yet is an area where little convergence has occurred. This is due to several factors,
including the diversity of MaaS ecosystem actors and accompanying data standards, a reluctance amongactors to adopt data standards they feel they have little or no control over, the use of closed data syntaxes
by some market actors to foreclose competition and the costs of re-coding internal systems to data
standards which may not prove durable or aligned with their perceived best interests.
Data interoperability has three core building blocks: semantics, schemas and syntax (Figure 11).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

45

HOW TO SHARE MAAS-RELEVANT DATA?

Figure 11. Building blocks of data interoperability: Data semantics, schemas and syntax

Data interoperability must address semantics, schemas and syntax
so that different systems can function together natively or with minimal “cost/effort” in an operational context“table of contents”“chapters”“paragraphs”“index”“words”“Danish”“Hindi”“Catalan”

Semantics

SchemaSyntax“connecting terms with meanings”
Terms should have agreed, consistentand shared understanding. Common
lexicon.

“consistent structuring across systems”
Data should be organised infunctionally similar ways such thatsimilar data elements can be mapped
to one another across syntaxes.

“common language”
Data encoded in a uniform manner inorder to predictably deliver meaningand outcomes.

Necessary

SharedReference syntax?

Data semantics
Like human language, digital systems build on a shared understanding of the semantical building blocks oflanguage – words and terms. However, unlike human language, which is often open to nuance andinterpretation, digital systems using machine language require clear, consistent and unequivocal
definitions of terms and meanings. The MaaS ecosystem cannot function effectively if mobility operators,
MaaS providers and other MaaS ecosystem actors understand terms like “trip started”, “bus stop” or“vehicle available” in different and sometimes incompatible ways.
Establishing common and documented meanings to terms used in digital exchanges is a prerequisite fordata interoperability. Accepted semantic models exist for established mobility services but are still lacking
for many new ones. Mode-specific semantical models are more likely to exist for public transport and serveas the basis for the data syntaxes used to promote interoperability and reporting within those services. In
contrast, little semantical harmonisation has taken place among new mobility operators. Thus multiple
definitions may exist for such basic information as “is an asset available?” or “has a trip ended?”. Some
progress in remedying this is underway, as in the case of mapping General Bike Feed Specification (GBFS)
to the Network Timetable Exchange technical standard (NeTex) and the Service Interface for Real Time
Information protocol (SIRI) (DATA4PT and MobilityData, 2022).
Common semantical lexicons should be developed at the highest level possible to ensure their widespread
adoption (for examples of MaaS-relevant semantical lexicons, see ITF [2021c] and MaaS Alliance [2021]).
Linking these building blocks to contracts and existing mechanisms or aligning them via canonical mapping
to other current or converging standards will facilitate their uptake.
Deployment should be voluntary and incentivised via traditional standard-setting processes, which willtake time and there is, at present, no well-defined broad initiative to do this. In the meantime, market
actors and authorities can incentivise the adoption of emerging semantical lexicons that provide someform of convergence around the meaning of terms. More importantly, authorities can incentivise or
require (in the terms of the licenses they grant) actors to adopt common semantic operations and logics
when mapping one term to another in different data syntaxes. For example, suppose “unavailable vehicle”
46

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

in one syntax could be interpreted in one of two (or more) ways in another syntax. In that case, authorities
could incentivise one consistent interpretation across all ecosystem actors.
Data models and schemas
Establishing common or broadly compatible data schemas can bridge the gap between a MaaS ecosystemcharacterised by multiple bespoke data syntaxes and one in which a single harmonised data
syntax prevails.
Data schemas are high-level architecture models relating to data structuring within each syntax. A data
schema is roughly analogous to the structure of a book. A book has a cover and a back, it may have a tableof contents and chapters, the text is organised into paragraphs, and each page is assigned a referenceable
number. All of these mean that very different books are useable in the same way despite differences incontent and language. Data should be consistently structured and organised functionally so that similar
data elements can be mapped to one another across otherwise different syntaxes.
A number of mobility data schemas exist or are emerging (see Chevalier et al., 2021; ITF, 2021c; MAAS
Alliance, 2021). A MaaS-supportive data schema should ideally be structured in line with the functional
domains necessary for mobility operators and MaaS providers to deliver co-ordinated and joined-up trips.
In this respect, the functional microservice-oriented breakdown outlined in the previous section serves asa model for structuring a common MaaS data schema. Beyond the data structuring, appropriate meta-data
and built-in model referencing and documentation help describe how the data structure is linked to
specific data elements across different data syntaxes.
Data Syntaxes
If the semantical basis for mobility data is analogous to words in human language, the digital data syntaxes
deployed to support mobility data sharing are akin to grammar rules. They provide the structure in which
the building blocks of language are organised to communicate meaning and generate understanding. As
noted above, there is little room for interpretation in machine language. Therefore, specifying a data
syntax that enables communication, or finding an efficient way to translate meaning from one syntax toanother, is a core concern in deploying digital services.
The strongest level of data interoperability stems from the broad use of accepted (or imposed) data
sharing syntaxes. These may be set by standard-setting bodies or de facto standards established by adominant actor or collaboratively built by consortia of market actors. At present, however, there is nouniversal mobility data sharing syntax. Public transport operators use industry-standard data syntaxes forsharing information (e.g. in Europe, NeTEx and SIRI based on the Transmodel model, DATEX II, or, globally,
the General Transit Feed Specification [GTFS] for static information). Shared bicycle, shared micromobility,
and carsharing operators may use the GBFS to communicate with other systems. Other mobility operatorsor services, like carpooling services or taxis, may use emerging syntaxes like General On-Demand Feed
Specification (GOFS) or their own bespoke standards. Shared micromobility operators can also report datausing the Mobility Data Specification (MDS), which incorporates elements of GBFS (for an overview ofthese syntaxes, see Chevalier et al., 2022; ITF, 2021c; MAAS Alliance, 2021).
Multiple, poorly aligned, or incompatible data syntaxes hamper the uptake of integrated mobility services.
They may also give rise to market power asymmetries if adopted data sharing syntaxes favour certain
operators over others, whether by design or in practice. The deployment and uptake of open andmode-agnostic data syntaxes mitigate this risk. There is also a risk that forcing the MaaS ecosystem toadopt a specific data sharing syntax, even if it is flexible and evolutionary, may foreclose innovation andimpose costs related to complying with the syntax. This especially applies to small- and medium-sized
operators who already have built their data architecture around another syntax.
MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

47

HOW TO SHARE MAAS-RELEVANT DATA?

A less restrictive approach may be to ensure broad functional alignment between the different standards
used by MaaS ecosystem actors. This functional interoperability may be delivered by market actors
agreeing to (or being required to) conform to a common data schema rather than a specific syntax (ITF,
2021a). This path is taken by DATA4PT (Transmodel) and MobilityData (GxFS) based on a canonicalmapping between the standards. The idea is to recognise that different standards meet different needs
and use cases and ensure that a simple conversion tool can be built for better interoperability. Regarding
the book analogy, the mapping would be like bilingual dictionaries.
Another less-restrictive approach to interoperability would be to establish semantically-aligned, validated
and authoritative meta-data statements concerning the status of a transaction or process. Exchanging
commonly understood and trusted status messages such as “confirmed”, “validated”, “concluded”,“paused”, “paid” would serve as a proxy for the kind of outcomes data interoperability seeks to achieve.
Such a trust-based approach would require auditability, control and enforcement mechanisms. It could
leverage zero-knowledge proof-based trust signatures (see glossary) and distributed ledgers.
Full interoperability

Full interoperability refers to systems designed to be fully interoperable from the outset – that is,interoperability is a built-in design feature. Fully interoperable systems are characterised by but go beyond
deep protocol and data interoperability. They allow substitute services, deployed by different MaaS actors,
to interoperate – for example, public transport, taxi and micromobility services, which are natively andinterchangeably bookable, payable and accessible from mobility operator apps. Fully interoperable
services allow competitors to access their rivals’ user base, thus sharing network effects and enabling amore level playing field (Bourreau, Krämer and Buiten, 2022).
Strategies for enhancing interoperability

Interoperability should be understood as a means to an end, not as an end in itself (Hoffmann and Gonzalez
Otero, 2020). In MaaS, interoperability allows people to easily understand and undertake seamless, joinedup trips using different mobility operator services. Achieving that objective will require interoperability,
but that interoperability must be balanced and aligned with other important objectives. These include
minimising the cost associated with enhancing interoperability, addressing potential competition andother market impacts, accounting for the technical feasibility of introducing and maintaining interoperable
systems and ensuring that interoperability contributes to innovation, value creation for users andachieving broader policy objectives.
Those last points underscore a fundamental trade-off: standardising everything forecloses innovation,
whereas standardising nothing results in non-interoperable silos (IES-City, 2018). Neither of these is agood option.
At this early stage in the deployment of MaaS, it makes little sense to lock in a single mobility data sharing
syntax – these are likely to change as MaaS matures and experience grows and needs evolve. There is also
the risk that locking in one solution would also intentionally or unintentionally confer market power to asingle or a small set of actors. In this context, a preferable response would be to seek ways to identify andaccommodate minimum effective interoperability frameworks across the MaaS ecosystem. Pivotal points
of interoperability and minimum interoperability mechanisms are two promising linked strategies to do this(Figure 12) (Heuser et al., 2017; IES-City, 2018; ITF, 2021c; LI.EU, 2021; MaaS Alliance, 2021; OASC, 2021).

48

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

Figure 12. Establishing minimum interoperability between mobility data syntaxes

Multiple, bespoke and unaligned MaaS
actor systems

Pivotal points of interoperability (PPIs)
Similar systems often address similar problems and may
deploy similar, but not aligned, solutions. PPIs capture anddocument these in order to map potential interoperability

Minimum Interoperability Mechanisms (MIMs)
Minimal set of interoperability criteria – e.g. the smallest common denominator that is needed to guarantee interoperability
between MaaS stakeholder systems and data (e.g. context management information, common data models… at theschema level) – work underway at Open and Agile Smart Cities (OASC)
Source: based on MaaS Alliance (2021).

Pivotal Points of Interoperability

Independent teams facing analogous problems often develop similar concepts and approaches regarding
standards, specifications, architectures, frameworks, conceptual models, platforms, protocols, andenvironments (IES-City, 2018). They develop these in response to common concerns and goals. For
example, how can information be shared about available transport assets? How can travellers and assets
be located in a timely and consistent manner? How can travellers book and pay for assets within and acrossmobility operator systems?
These concerns are tied to technical choices, such as communication protocols, data ontologies,
chronological synchronisation, localisation, asset identification and tracking. Identifying the set ofcommon, similar or compatible solutions to these concerns reveals potential Pivotal Points ofInteroperability (PPI). These include features in different systems that are functionally aligned andcompatible and can serve as a basis for interoperability.
PPI is both a process and an outcome that charts a middle way between a single standard or system andmultiple incompatible standards or systems. It seeks to surface common concerns and desired outcomes,
link these to technical design and features in each syntax or system, and map these across systems toidentify where interoperability can naturally emerge. The process has been documented in several
instances, notably by the Internet-of-Things-enabled Smart City Framework working group – an open
international initiative housed by the US National Institute of Standards and Technology (IES-City, 2018)
and by the European Innovation Partnership on Smart Cities and Communities (Heuser et al., 2017). The
difference between those initiatives and the application of PPIs for MaaS is that the former addresses
widely divergent systems in the context of smart city cyber-physical systems. Those Internet-of-Things
systems display fundamentally different designs, functionalities and technical characteristics (e.g. urban
lighting, water management systems, central heating and transport). This is less the case within the MaaS
ecosystem. As noted earlier, the basic micro-service-oriented functionalities outlined in the previous
section will likely be found across most mobility operators’ systems, facilitating the discovery and mappingof PPIs.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

49

HOW TO SHARE MAAS-RELEVANT DATA?

Minimum Interoperability Mechanisms

Once points of interoperability have been identified, specific measures and capabilities must be developedand implemented across systems and syntaxes to render them interoperable. The MinimumInteroperability Mechanism (MIM) framework developed by the Open and Agile Smart Cities network
addresses this challenge (1001 Lakes Oy et al., 2021; LI.EU, 2021; MAAS Alliance, 2021; OASC, 2021). If
PPIs are where interoperability can occur across different syntaxes and systems, MIMs define theinteroperability “hooks” – that is, how interoperability is established.
MIMs are “the minimal but sufficient capabilities needed to achieve interoperability of data, systems, andservices between buyers, suppliers and regulators across governance levels around the world” (LI.EU,
2021). The most current version (v 5.0 – also referred to as MIMs Plus) sets out a comprehensive vision
for an open, technology agnostic and vendor-neutral data schema that, if implemented, would enable allof the stakeholders in the data ecosystem to achieve interoperability, building on existing and bespoke
data syntaxes and standards. In particular, MIMS Plus enables modular, flexible and scalable solutions toallow for bespoke adoption by all kinds of actors and in different contexts, adopting global, standard-based
open application programming interfaces (APIs) to enable broad interoperability and ensure data
harmonisation and global standards based on semantic interoperability through the adoption of common,
linked data models (LI.EU, 2021).
MIMs have the potential to serve as the blueprint for mobility data infrastructure (Figure 1) in that not
only do they open a pathway to link different data syntaxes and systems presently operating in that space,but also they are designed to enable broader societal goals to be built into the technical systems thatcollect and process data. MIMs Plus compliance, for example, would ensure that data-reporting processes
are privacy-preserving by default. The schema also seeks to provide a flexible and scalable framework thatenables data-governance frameworks to account for new forms of data and processing (SynchroniCity,
2020; LI.EU, 2021; OASC, 2021).
The MIMs framework is implemented in several Smart City and data governance initiatives, including the
MyData framework (See Box 8). MyData is a Finnish-initiated, open global personal data management
framework that empowers people to use their personal data according to their preferences and securely
authorise sharing that data on their own terms (MyData, 2018; Poikola et al., 2020). MyData serves as areference architecture for personal data management in MIMS Plus, where it outlines mechanisms giving
people meaningful access and control to data on and produced by them across multiple systems andencoded in various syntaxes (for more information on MyData, see 1001 Lakes Oy et al. 2021; ITF 2021c;
Poikola et al. 2020).
MyData’s API-based architecture establishes data subject agency and assigns data access rights andresponsibilities. As such, it can frame data sharing of personal information within the MaaS ecosystem.
Beyond that, it is an example of how different modular units – “building blocks” – carrying out essential
data sharing functions can serve as a basis for mobility data sharing infrastructure, especially when fulfilling
continuous personal data portability in the MaaS ecosystem (Langford et al., 2022).
Data portability

Data portability refers to individual rights and market actor obligations enabling people to access data
about them or designate to whom and under what conditions market actors should transmit their personal
data. OECD (2021b) defines data portability as “the ability (sometimes described as a right) of a natural or
legal person to request that a data holder transfer to the person, or to a specific third party, data
concerning that person in a structured, commonly used and machine-readable format on an ad-hoc or

50

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

continuous basis” (OECD, 2021c). If interoperability enables data to be shared and used across market
actors and systems, data portability addresses what data should be shared, by whom and underwhat conditions.
Data portability is an essential tool enabling people to control and manage the sharing of their personal
data. Data portability reduces the risk of consumer lock-in by enabling multi-homing (i.e. customers using
multiple platforms to access the same or comparable services) and reducing the friction of moving fromone service provider to another. Data portability, in theory, if not in practice, enables people to share theirpersonal data in real-time to create services that cut across different operators – as in the case of MaaS.
Data portability requirements are enacted in numerous jurisdictions and sectors but vary in their purpose,scope and degree of operational specification. Data portability is almost always motivated by its
pro-competitive effect in data-intensive markets. However, in some jurisdictions – in the European Union,in particular – data portability is also associated with a fundamental right for people to have access to andcontrol the use of their personal data. Despite their diversity, data portability initiatives can be broadly
characterised across five key dimensions (OECD, 2021c) – all relevant to MaaS.
1. Sectoral scope

Some data portability measures are cross-sectoral (e.g. GDPR in Europe, the California Consumer Privacy
Act or the California Privacy Rights Act), while others are sector-specific (e.g. The 2nd EU Payment Services
Directive or The EU Regulation on Motor Vehicles). Sector-specific approaches typically target
infrastructural sectors (e.g. telecommunications, energy, banking and health) (OECD, 2021c). Where data
portability requirements exist on a general level (as in Europe with GDPR), these should be implemented
within the MaaS ecosystem. Where such general frameworks do not exist, sectoral approaches for MaaS
(and for mobility services more generally) would be appropriate.
2. Beneficiaries

People are typically the focus of data portability initiatives, especially when data portability is conferred asa right (e.g. in Europe and California). This reflects the focus of many of these initiatives on enabling people
to better control data pertaining to them. Data portability for MaaS should focus on rights conferred toindividuals since this fosters greater user-centricity in the MaaS ecosystem.
3. Data type

Which data are covered by personal data portability initiatives depends on how different jurisdictions
define “personal data”. As noted previously, there is a case to adopt a more expansive understanding of
personal data covering both volunteered and observed data, but not inferred data. There is growing
regulatory convergence towards this understanding in several jurisdictions, particularly in the EU (deStreel, Krämer and Senellart, 2021; Krämer, 2021a; OECD, 2021c).
4. Legal frameworks, obligations and enforcement

The imposition of data portability obligations may result either from regulation or in response to specificprior adjudication of competition enforcement actions. The difference between the two matters. When it
results from regulation, it establishes and specifies data portability requirements for all market actors. In
contrast, when it comes from prior adjudication, it is only triggered by competition enforcement
proceedings and thus occurs on an ad-hoc basis to address specific harms. Many data portability
frameworks are not backed by strong implementation guidance. Beyond establishing data portability
responsibilities or rights, they typically give little practical guidance on the mechanisms and methods to be
used to carry out portability and rarely link them to broader interoperability frameworks (Article 29 WP,
2016; de Hert et al., 2018; de Streel, Krämer and Senellart, 2021; Krämer, 2021a; OECD, 2021c).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

51

HOW TO SHARE MAAS-RELEVANT DATA?

5. Data portability model

Personal data portability may be enacted in several ways (see Figure 13).
Figure 13. Data portability models
Data download

Delegated data transfer

A person requests their personal data from adata controller who fulfills that request via a
one-off transfer of that data to the requestor.

A person requests that their personal data betransferred from one data controller toanother on a one-off basis. The data controller
complies with a one-off controller-tocontroller data transfer.

one-off data
downloadrequestone-off
datatransferrequest for
one-off
datatransferdelegated
one-offtransfer

Continuous transactional data transfer
A person requests that their personal data be transferred from a data
controller to other data controllers as needed on a transactional basis
for uses authorised by the person. The data controller complies andreleases the data via an adapted data exposure mechanism such as
an Application Programming Interface – API).

authorisations forcontinuous transactionbased data transfers

delegated continuoustransaction-based
data transfers via
APIs

Source: based on de Streel, Krämer and Senellart (2021); OECD (2021c).

Data portability may entail allowing a person to download their personal data on an ad-hoc basis from adata controller in a structured, commonly used, machine-readable format. The data subject can thenaccess or transmit this data to another data controller as they migrate to a new service. Data portability is
typically asynchronous in this model – there is a delay between the request for the data and its transfer(de Streel, Krämer and Senellart, 2021; OECD, 2021c).
Data portability frameworks may also require data controllers to transmit personal data they hold toanother data controller when asked to do so by the data subject. In this instance, the data subject directs
the data controller to initiate the transfer. The delegated transfer may be conditioned by the technicalfeasibility of enacting controller-to-controller transfers, as with GDPR.
Both the direct download and delegated data transfer models comprise a one-off or ad-hoc transfer of
personal data at the data subject’s request. They are meant to reduce switching costs when changing fromone service provider to another and enable multi-homing. The direct download model may involve somedelay (and human intervention from the data controller). On the other hand, delegated data transfers are
typically initiated as an immediate response to a request by the data subject (e.g. on a pull-basis where
the receiving data controller “pulls” the data from the originating data controller).
Because the delegated data transfer entails interoperability between data controllers, the transfer
is generally handled via an Application Programming Interface (API). The receiving data controller is theclient of the originating data controller API to whom they provide valid authorisation for initiating thetransfer (typically a token). API-managed data portability requires mapping the data schema of theoriginating data controller to the receiving data controller (Borgogno and Colangelo, 2019; de Streel,
Krämer and Senellart, 2021)

52

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

A third data portability model seeks the same outcomes but targets very low latency – in some cases
on-demand or real-time – transfers of personal data among market actors with the data subject’s consent.
Such “continuous data portability” enhances interoperability and is triggered as necessary in atransactional context. A requirement to ensure continuous and consent-based personal data portability isexpressly set out in the proposed EU Data Act subject to its “technical feasibility” (EU, 2022a).
Continuous data portability fosters new services and innovations but requires adapted technicalmechanisms – notably APIs that can handle data transfer requests with extremely low latencies or inreal-time. As with delegated ad-hoc controller-to-controller data transfers, the receiving data controller
acts as a client to the originating data controller and must provide valid, token-based authorisation for thetransfer request to the originating data controller. Data schemas of originating data controllers must also
be mapped to receiving data controllers.
Continuous data portability also comes with risks that must be managed (de Hert et al., 2018; de Streel,
Krämer and Senellart, 2021; Krämer, 2021a; OECD, 2021c). One variant of the continuous data portability
model involves the delegated transfer of data from a data controller to a third party, such as a Personal
Information Management System (PIMS), entrusted to handle transfers of personal data on behalf of thedata subject (Krämer, 2021a). This third party then acts as the client of the originating data controller (withpull/read rights) and the receiving data controller (with push/write rights).
Data portability and MaaS

Personal data portability plays three essential roles in MaaS data architecture:
1. it plays a pivotal role in enhancing the user-centricity of MaaS
2. it is a necessary (but insufficient) enabler of interoperability
3. it is required to authenticate the identity of travellers and allows mobility operators, via MaaS
providers, to grant authorisation to access their services, vehicles and fares.
MaaS involves a degree of personalisation and customisation which requires insight into travel choices andpreferences that cannot be derived from volunteered data alone. A broad understanding of whatcomprises “personal data”, including observed data, provides the basis for crafting customised andcompelling MaaS offers. Therefore, user consent-based data portability frameworks covering bothvolunteered and observed data enable greater user-centricity.
Where general personal data portability frameworks exist, their specific application in MaaS should be
addressed by public authorities and supported by MaaS-specific implementation guidelines. Where
cross-sectoral data portability frameworks are absent, there is a case for seeking to implement data
portability commitments or requirements in support of MaaS either through a code of conduct or byconditioning licensure of mobility operators and MaaS providers to adhere to them.
Ad-hoc data transfers may enable people to switch services or multi-home. Still, they are insufficient toallow the type of low latency or real-time transfers of personal data that enable MaaS ecosystem actors
to deliver joined-up, multi-operator trips. Simply specifying data sharing obligations or portability rights
without defining the mechanisms on which they are enacted only partially addresses the core challenge.
Worse still, it increases transaction costs for users and thus erodes the attractiveness of MaaS-based offers
in relation to other travel options. Data portability is thus a necessary but insufficient enabler of the levelof interoperability that MaaS requires (Hoffmann and Gonzalez Otero, 2020).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

53

HOW TO SHARE MAAS-RELEVANT DATA?

In the specific context of MaaS, leveraging data portability to achieve user-centric interoperability suggests
three things.
The first is that personal data portability frameworks should cover not only ad-hoc data transfers but
include a form of continuous and transaction-based personal data transfers. J. Krämer (2021a) notes that“a right to port personal data continuously and in real-time would be necessary to truly empower
consumers in the context of the digital platform economy”, and MaaS is no exception. As noted, thisapproach is adopted by the EU Data Act (passed in May 2022), potentially serving as a precedent for otherEU approaches (EU, 2022a).
The second implication of moving beyond data portability to greater interoperability is that it will requirecommonly accepted interoperability mechanisms and, in some cases, convergence on data standards.
Both continuous and ad-hoc data transfers between two data controllers require both controllers to agree
on a common semantical lexicon (or inter-lexicon translation logic) and adopt broadly aligned data
schemas that enable one controller’s data to be easily onboarded by the other and vice-versa. Ideally, bothwould share a common syntax and a common data exchange API architecture.
The third point is that adopting an expansive view of what constitutes “personal data” and granting people
the ability or right to delegate the transfer of that data from one data controller to another implies a robust
framework for signifying, granting and managing the consent of data subjects regarding the use of theirdata. Consent regarding the sharing and use of personal data is essential not only on a fundamental rights
basis (especially where that right is enshrined in law) but also to increase trust on the part of data subjects
that the use and sharing of their data delivers tangible value to them.
The MaaS data governance framework must balance telling data subjects the potential uses to which theirdata will be put and acquiring their consent, and minimising barriers to adopting innovative services usingthat data. Achieving that balance may mean moving away from transaction-based consent frameworks tohigher-level consent-management frameworks. Transaction-based consent frameworks are based on
gaining consent for every new transfer of personal data. Higher-level consent-management frameworks
focus on providing mechanisms for handling general preferences about the use of personal data andestablishing upstream mechanisms to manage consent. PIMS are one way of establishing such consent
management frameworks, and MyData is a good example of a concrete model and operational means to
do so.
Another strategy to improve the consent framework for MaaS is establishing and adopting common
consent language across the MaaS ecosystem. This could include signifying that “personal data” consistsof both volunteered and observed data, or that consent is being given to initiate continuous – buttime-bound – personal data transfers in the context of delivering a MaaS offer for a trip undertaken by thedata subject). Public authorities could condition licensure of both mobility operators and MaaS providers
to the adoption of agreed consent language or could incentivise the use of such clauses by fast-tracking
the applications of those actors who adopt it (since a more detailed review of their data policies would not
be required). In any case, developing agreed consent terms will require input from, and consideration of
the needs of, all MaaS ecosystem actors. Thus, there is a need to establish an open and transparent processwith which to do so.
A final point to consider regarding personal data portability in the MaaS ecosystem concerns how personal
data is used for two essential MaaS functions: authenticating identity and granting related authorisations.
Authentication and authorisation are two distinct but related processes. Authentication refers toestablishing and validating the identity of a user or a service, whereas authorisation involves verifying
identity and granting related access or usage rights. In the context of MaaS, authenticated identity serves

54

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

as a basis for obtaining access to services offered by mobility operators (e.g. boarding a tram) or MaaS
providers (e.g. accessing a subscription package). How and how frequently users must provide theirpersonal data to establish their identity and access services changes with the introduction of the MaaS
provider. How exactly this will change depends on how personal data portability is managed within the
MaaS ecosystem (Figure 14 provides one example).
Figure 14. MaaS: Authentication, authorisation and personal data portability
Without MaaS or Data Portability

authentication

authorisation &access rights

authentication

authorisation &access rights

authentication

authorisation &access rights

With MaaS-enabled Data Portability
authentication

identification and authentication could be handled
by an external service provider

accessright
confirmation ofauthentication

authorisationdelegatedauthentication

authorisation confirmation ofauthentication

authorisation

Without a MaaS provider (and without personal data portability), a person undertaking a three-segment
trip from home to work (Figure 14) must provide personal data establishing their identity to all threeoperators, who, in turn, must validate that identity. For some forms of travel, validated identity is not reallyan issue – travellers bearing a valid but anonymous ticket can, for example, board a bus, subway or tram.
However, identity authentication (including certain types of personal characteristics, e.g. if the traveller
has a valid license to operate the vehicle they want to access) is necessary where access rights arenominative or account-based. Establishing identity is usually a one-off process that occurs during
onboarding. Authentication of identity, however, occurs for each trip. In the case of a trip without a MaaS
provider or personal data portability, each mobility operator must authenticate the user’s identity (using
their own validation processes) for each trip. Each operator then must communicate to the user accessauthorisations associated with that identity.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

55

HOW TO SHARE MAAS-RELEVANT DATA?

Authentication and authorisation pathways change in the presence of a MaaS provider and with personal
data portability. For example, a user establishes their identity with the MaaS provider – or a third-party
authentication service – who authenticates it. Some mobility operators may accept the MaaS provider’sor the third party’s confirmation of authentication (without seeing the user’s identity or other data). Others
may require personal data to confirm the user’s identity. In the latter case, the user grants the MaaS
provider or the identification/authentication microservice provider delegated authority to provide themobility operator with their personal data. Once the user’s identity is established and authenticated, themobility operator communicates authorisations to the MaaS provider, who, in turn, transmits access rights
to the traveller.
The example above describes one of several possible ways to manage authentication and authorisation.
Still, it highlights what is important from the traveller’s perspective (single sign-on and transacting via asingle or unified interface) and what is important to other MaaS ecosystem actors (robust and persistentidentity authentication and clear mechanisms for associating and granting rights to validated users).
Authentication and authorisation functions can be handled by mobility operators themselves or by third
parties. The MyData framework and principles described earlier set a vision for ensuring that third parties
operate in a way that contributes to improved social welfare and the protection of individual rights. In thelogistics sector, the Dutch iShare scheme seeks to do the same (iSHARE, 2021). Other open identity
management and validation standards such as OpenID, the EU Digital ID framework (eIDAS) or delegatedauthorisation standards like OAuth2 also create harmonised and uniform methods for addressing
authentication and authorisation independent of any actor’s own methods. Beyond improving
interoperability, these approaches underscore that developing a data architecture around trusted
task-based modules helps ensure resilience. If a better, more secure or innovative way of accomplishing atask comes along, the module can be updated or replaced without fundamentally re-coding theentire system.
Some transport fares are conditioned to income, age, employment or other sensitive personal information.
These require travellers to demonstrate to mobility operators, MaaS providers or fare calculation
microservice providers that they qualify for those fares. To do so, they must provide a certificate from anappropriate public authority or the raw data (e.g. an income tax declaration) indicating that they meet therequired threshold. The operators must authenticate these documents before authorising travellers toaccess the reduced fare. In France, the Inter-Ministerial Office for Digital Affairs (DINUM) and the National
Association of Mobility Authorities (GART) have organised a whole-of-government initiative implementing
public service APIs allowing mobility operators to directly authenticate the status of travellers regarding
multiple endpoints like age, income, disability, household characteristics, employment and drivers licenceholding. A user only has to provide their official e-identifier to the mobility operator or MaaS provider, whothen can access relevant APIs and receive confirmation (or not) that the traveller has the right to access aservice or social fare (DINUM, 2022).
Beyond discussions relating to personal data portability, there is the broader issue of non-personal data
portability and reuse among MaaS ecosystem actors. This type of data transfer falls under the scope ofbusiness-to-business data sharing. As discussed earlier, it should be addressed for minimal data sharing,which should be incentivised or required to establish a functioning MaaS ecosystem.

56

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

Data sharing mechanisms for MaaS: The role of APIs
Data sharing mechanisms enable the creation of the shared data resource required to allow for end-to-end
trips across multiple mobility operator services. However, not all data sharing mechanisms equally build
trust in the MaaS ecosystem or foster limited, purposive and efficient data sharing in support of MaaS.
Data sharing mechanisms for MaaS broadly fall into one of two categories. The first is a centralised data
resource under the control of one actor, and the second is an “on-demand” data resource accessed via
limited, real-time and vetted access data exposure mechanisms such as application programming
interfaces (APIs – see Figure 15). This is admittedly a generalisation; access to centralised data resources
can be achieved via APIs. However, it underscores two fundamentally different strategies: centralising dataor creating distributed on-call data exposure mechanisms where the data is housed.
Figure 15. How to share data? Centralised data pooling versus on-demand data exposure

Establishing a common data resource
API

API

API

Centralised data poolingOn demand data exposure“AYNAMW – All you need, and more, whenever”
Data pooled in a central database or “data lake”
controlled by one actor (e.g. stakeholder, third
party, public authority.

“WYNWYNI – What you need, when you need it”
Data exposure initiated by an approved action byvetted actors for purposive data access to deliver
an outcome (e.g. a trip). Credentialed, secured,
token-based APIs – standardised or functionallyaligned.

Much of the “historic” focus on MaaS data sharing mechanisms has centred on centralised data collection
and management by a back-end, data platform-operating entity (Arias-Molinares and García-Palomares,
2020; Audouin and Finger, 2019; Banerjee, Jittrapirom and Dangschat, 2021; Crozet and Coldefy, 2021;
Jittrapirom et al., 2017a; Kamargianni and Matyas, 2017; Longo, Zappatore and Navathe, 2019; Pagoni etal., 2022; Polydoropoulou et al., 2020; van den Berg, Meurs and Verhoef, 2022). This entity could be acommercial, public or mixed-platform operator. But, in all cases, data flows into a centralised entity’s
database or “data lake” under this model. The approach assumes that market actors provide data to theplatform and that the platform operator manages access to the data as necessary and as required to carryout integrated trip offers. This model raises questions regarding trust that the back-end data platform
operator would act in a neutral capacity regarding its gatekeeping and governance functions. There is also
the risk that centralised data collection may lead to data leakages or other unwanted outcomes(ITF, 2021a).
One way to address these risks is to adopt a more agile data sharing mechanism based on permissioned
and conditional data exposure via specific APIs. APIs are code-based and documented sets of rules
establishing an interface that enable two different computer systems, applications or software tocommunicate and transfer data between each other in a way that allows the data to be used without

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

57

HOW TO SHARE MAAS-RELEVANT DATA?

further transformation. Accessing data from one system, or exposing data to another system, does not
require any knowledge of how the API is implemented – all that is needed is to use the interface (IBM,2022). APIs are and will continue to play a pivotal role in ensuring interoperability, not just in the MaaS
ecosystem but more generally across all levels of digital interoperability.
APIs enable two essential MaaS data sharing outcomes. They establish a technical means to expose andmeter a subset of mobility operator data to authenticated and vetted MaaS providers. They also serve as
modular building blocks to build on-demand joined-up trips within the MaaS ecosystem (Borgogno andColangelo, 2019; Hoffmann and Gonzalez Otero, 2020).
In a practical example, when a MaaS provider wishes to create or initiate a trip request on a traveller’sbehalf, APIs are called to establish the traveller’s identity and that of the MaaS provider. Identity
authentication is then linked to authorisation to access specific data held by mobility operators via an API(Figure 14). A token (or another secure and unique identifier) confirming identity and authorisation is thenused to gain access to data via APIs housed by mobility operators. This would, at a minimum, include
informational and operational data and, if contractually agreed by the transacting parties, data and accessto systems enabling booking and payment. Alternatively, the API could provide a deep link pathway (seeglossary) to the mobility operator’s own booking and payment service. Tokens can also be used to deliver
time-bound authorisation for certain actions and transactions via a data sharing API. The validated
authentication and conditional authorisation functions provided by the token-API architecture limit
over-broad data sharing risks and address potential anti-competitive behaviour via auditability andtraceability. They also have the advantage of building on well-known protocols (Borgogno and Colangelo,
2019; ITF, 2021a; MaaS Alliance, 2021).
APIs can be internal or external-facing. Internal-facing APIs are deployed within a firm and support
inter-firm functions. They support internal processes (e.g. micro-services) within a closed environment but
may also be re-purposed to serve external requests. External-facing APIs may be open or restricted. OpenAPIs can be accessed by any entity, under any circumstances, with few, if any, restrictions (which may belimited to data transfer rates, for example). Restricted APIs are accessible only to vetted and authenticatedentities. Authentication and access to restricted APIs are typically managed through trusted tokens.
External-facing APIs (both open and restricted) may be based on proprietary code or open-source
standards. The technical specification and access rules of proprietary APIs remain entirely under thecontrol of the hosting (and data-holding) entity. In contrast, the specification and implementation of APIs
based on open-source standards follow open and consensus-based governance models.
External-facing APIs require accessible and up-to-date documentation allowing those requiring access to
it to invoke API functionalities correctly. Open APIs provide API documentation and metadata by default(via code-hosting sites such as GitHub). This is not necessarily true for proprietary external-facing APIs,
which may condition or restrict access to documentation based on trade secret clauses (Borgogno andColangelo, 2019; Hoffmann and Gonzalez Otero, 2020).
External-facing but proprietary APIs enable the hosting entity to innovate in the extent to which it exposes
its data. There is, however, an inherent risk that unilateral control over the configuration of the API allows
the API host to intentionally or inadvertently degrade or eliminate API functionality for all or a subset of
those accessing it (Hoffmann and Gonzalez Otero, 2020; van Arsdale and Venzke, 2015). The API host may
also intentionally throttle API access to certain actors while retaining or improving data transfer rates toothers. These risks are inherent in deploying external-facing proprietary APIs. Where these APIs contributeto or enable public outcomes in MaaS (and elsewhere), appropriate monitoring and redress mechanisms
must be built into the data governance framework.

58

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

Architectural guidelines on APIs as mobility data infrastructure
APIs play a crucial and fundamental role as the principal enablers of data portability and interoperability
within mobility data infrastructure. As with other types of infrastructure, APIs supporting MaaS will mix
private and public ownership and governance. However, as with other essential foundational
infrastructure, the architecture of that web of data sharing APIs, and in some cases, of the APIs themselves,
should be aligned with public policy outcomes and framed by a consensus-based vision of what and how
they should contribute to mobility generally, and MaaS in particular.
That vision – of what outcomes MaaS ecosystem APIs should support and especially how they should doso – is not settled, given that the concept of MaaS is still maturing. However, a few broad architectural
guidelines can already be outlined based on the previous discussion. These architectural guidelines are inprinciple only. They do not reflect the diversity of specific legal contexts in which they would be
implemented. Still, they sketch an aspirational blueprint of a MaaS data sharing framework that balancesuser-centricity, public value, innovation and commercial opportunity. As such, they outline a possible
end-point and indicate a trajectory towards establishing foundational mobility data infrastructureencompassing MaaS.
Obligation to share data

The MaaS ecosystem requires a shared data resource to function. This common resource should be built
on an obligation to share minimum but sufficient data to create cross-operator MaaS offers. This data
should include non-personal data necessary to support the planning and operational delivery of MaaS
offers. It should also include access to payment mechanisms that, at a minimum, allow MaaS providers toaccess the same booking and payment functionalities available to the individual travellers they represent.
Personal data (including volunteered and observed data) should also be shared with the express consent
of the data subject. Travellers should be able to receive their data or delegate the continuous transfer ofthat data from data controllers who hold their personal data to other data controllers of their choosing in
the context of accessing MaaS services. This transfer should be mandatory if invoked by the data subject.
Such regulatory requirements imply monitoring and enforcement mechanisms. Establishing licensure for
MaaS providers and adapting mobility operator licenses to reflect these obligations accomplishes this.
The obligation to share data should also be linked to quality requirements for that data. Sharing poor orincorrect data limits the value of data sharing and erodes trust in how those data are used. Quality
assurance is a crucial enabler of value. A good example of quality assurance for shared data is the UK
Bus Open Data Services (BODS), which supports trip planning and increases bus patronage. The critical
success factor of BODS was tightly coupling data sharing to data quality standards (UK Department forTransport, 2022).
Obligation to house data sharing APIs open to vetted ecosystem actors

Data sharing should go beyond the definition of rights and responsibilities. Operationalising cost-effective
and welfare-improving data sharing and portability implies outlining the mechanisms to deliver theseoutcomes. MaaS ecosystem stakeholders should be obligated to implement adapted data exposure
pathways via APIs that are open to vetted actors holding valid licenses. This obligation should be includedin the licensure for mobility operators and MaaS providers and should cover exposure of minimum but
sufficient data to enable the creation and sale of joined-up trip offers.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

59

HOW TO SHARE MAAS-RELEVANT DATA?

Free but incentivised choice of APIs

Interoperability is facilitated by: (1) the alignment of different systems or (2) functionally mapping one
system to another. The first option provides the greatest interoperability, especially if it is delivered byadopting a single harmonised set of APIs. However, it potentially imposes high costs for some actors andmay foreclose innovation emerging from competing (but hopefully compatible) API standards. Morefundamentally, the MaaS ecosystem is not yet mature enough to require convergence towards one set ofAPIs. In this context, public authorities and MaaS ecosystem actors could define a “reference” set of APIs
that deliver certain measurable benchmark outcomes. Ecosystem actors can select these reference APIsor adopt another set of APIs. In the second case, those adopting (or those developing) non-reference APIs
should establish that those APIs deliver the target performance outcomes as well or better than reference
APIs. This requires establishing target benchmark outcomes for API-based data sharing.
Adoption of restricted APIs

Access to MaaS APIs should not be open (to all) but limited to vetted (licensed) MaaS ecosystem actors.
Licensure establishes vetting and commits actors to respect data handling and data sharing requirements
and protocols.
Incentivised open-source APIs and their standards

Open-source APIs (e.g. those with open, documented and transparent governance) are preferable toproprietary APIs. Additionally, APIs conforming to open API standards (e.g. OpenAPI architecture) are
preferable to those adopting proprietary architectures. The OpenAPI Specification (OAS) “defines astandard, programming language-agnostic interface description for HTTP APIs, which allows both humans
and computers to discover and understand the capabilities of a service without requiring access to source
code, additional documentation, or inspection of network traffic” (OpenAPI, 2022).
MaaS ecosystem actors adopting both open-source APIs and open API architectures could be granted
fast-track licensure. Actors retaining proprietary APIs or architectures would then be subject to robust andongoing documentation requirements (to mirror the transparency in open-source APIs). As noted above,
authorities or other public-private governance bodies should detail the core functionalities that APIs mustdeliver. Changes in proprietary API architectures that impact the ability of the API to deliver on thosefunctionalities should be logged, documented and notified to actors and authorities. An explanation should
be provided on how those functionalities have been affected. Authorities would reserve the right tore-assess licensure if desired functionalities are degraded or removed.
Incentivised convergence mechanisms

Licensure should reference a common and agreed semantical lexicon (or common logical operations totranslate terms). It should also encourage alignment towards common and compatible data schemas.
Likewise, common consent language should be incentivised. This could include an expansive interpretationof “personal data” (if this is not otherwise established) or the acceptance of continuous, transaction-based
personal data portability. One example of such a principle-based convergence mechanism is the Mobility
Data Interoperable Principles (MDIP) (MDIP, 2022). Adopting vetted or recognised interoperability anddata portability mechanisms could fast-track licensure. Not adopting them would be accompanied by anassessment of how targeted functionalities and outcomes would be impacted.

60

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO SHARE MAAS-RELEVANT DATA?

Public authority oversight and capacity development

Authorities must deploy active oversight mechanisms to ensure the intended function of MaaS dataarchitecture (including APIs). This entails upskilling and acquiring the technical capacity to carry out thesereviewing and monitoring tasks or overseeing third parties to whom public authorities delegate
these tasks.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

61

HOW TO HANDLE AND PROCESS SHARED DATA?

How to handle and process shared data?
Market actors have responsibilities when handling and processing shared mobility data alongside the data
access rights granted to them. These responsibilities may vary depending on the type of data (e.g.
non-personal, personal, and commercially sensitive). This section underlines the role of data-handlingprocesses in creating trust among market actors. Then, it describes effective data handling andprocessing protocols.

Data handling protocols and processes
Adopting adapted data handling protocols can reduce data sharing risks and market actors’ perceptions ofthese risks. These risks are associated with the sensitive or personal nature of some data collected bymarket actors. In democratic societies, open, transparent, and participatory governance processes that
limit public authorities’ potential for overreach and abuse generally mitigate these risks. These powers
may be unchecked in less democratic or authoritarian regimes. Misuse, abuse, or careless handling of
personal or sensitive data shared between stakeholders can result in significant harm in both cases.
Establishing transparent, proportionate, and adequate data handling protocols and processes should
prevent risks related to sharing personal and commercially sensitive data. Personal data handling should
trigger additional protocols to ensure its safe processing. These protocols should be based on guidelines
ensuring data sharing-related risks are identified and mitigated by default. Several data governanceframeworks and principles have been proposed. Some integrate data handling protocols and processes.
ITF (2021c) lists some of the most recent proposed data sharing governance frameworks and principles
from various organisations (i.e. NUMO, 2021; OECD, 2021; SuM4All, 2021; WBCSD, 2020).
Data handling protocols and processes are crucial to building trust among market actors. According to
WBCSD (2020), public authorities can establish governance structures and privacy regulations to reinforce
trust between market actors. Additionally, public authorities can clearly establish roles and responsibilities
for supervising and managing data handling protocols to allow data sharing frameworks to be effective.
SuM4All (2021) notes that establishing an independent function responsible for overseeing data use canensure the ethical handling and processing of data. Emerging tools such as data review boards (DRB) (IAPP,
2020) can help companies make responsible decisions regarding data processing.
MaaS ecosystem stakeholders (e.g. MaaS providers and transport operators) should also establish two
essential functions: data stewardship and custodianship.
Data stewards oversee all institutional data requirements, quality and fitness for data assets. They are
primarily concerned with data content and context. They are responsible for collecting, merging, logging
meta-data and addressing issues and problems with data. They ensure compliance with all applicable legal
and policy obligations and ensure that data collected and processed can meet the defined purposes forwhich they were collected and achieve desired outcomes (Plotkin, 2021).

62

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO HANDLE AND PROCESS SHARED DATA?

Data custodianship functions relate to the handling of data. Data custodians manage how data are stored,
processed and transmitted internally and externally. They are also responsible for deploying physical andtechnical safeguards to protect the integrity, confidentiality, security and availability of data necessary toenable the MaaS market (Carnegie Mellon University, 2021).
Both data stewardship and data custodianship roles should be clearly defined within stakeholders’organisations that process shared mobility data (e.g. service providers and public agencies).
Data retention, destruction and aggregation

Mobility data should circulate between market actors lawfully and appropriately to mitigate risks forindividuals and companies. This requires a coherent and principle-led data sharing framework. The EU’s
GDPR Article 5 outlines three principles that capture the essence of that framework.
1. Transparency and purposive process

Data processing results should be aligned with the purposes for which it was designed. A cornerstone ofmost data-privacy frameworks is the meaningful consent given by data subjects for collecting andprocessing data concerning them. Data subjects should also give their consent to the onward collection
and processing of data by MaaS stakeholders. The notion of consent should be clearly addressed andenacted in data sharing frameworks. As much as legally possible, data subjects should be informed ofonward processing by market actors in clear and easy-to-understand terms and express their consent via
simple and easily actionable consent mechanisms. The outcome of processing should be aligned with the
purposes for which it was collected.
2. Limited data sharing

The sharing of personal and sensitive data (if consented to) should only be done by the necessary parties
to achieve the purpose of its collection. MaaS stakeholders should clearly identify to whom data will betransmitted (if at all). These parties may include other service providers, public agencies and third parties.
In all cases, data transmission should be demonstrably linked to achieving the purpose for which it wascollected. Onward transmission of personal data should be avoided by default and limited to the minimal
number of parties required. Consent for this transmission should be obtained when the data was originallycollected from data subjects.
Data custodians should enact strong and conditional access controls for personal and other sensitive data.
These controls should minimise security risks and prevent unwanted data access and processing.
MaaS ecosystem actors should also develop privacy risk assessments and establish data privacy policies.
Commercial MaaS operator Whim’s privacy policy specifies data sharing limits and the conditions underwhich users’ personal data may be disclosed. For example, personal data might be shared with third-party
service providers: “we could, for example, share your name and contact details with a service provider […]so that the service provider knows you will be using their services and will be able to contact you directly,
for example, in case there is a problem in the service” (Whim, 2021). As privacy risks evolve, privacy risk
assessments should be held frequently.
3. Appropriate data retention and deletion

Clear data retention, transformation and destruction policies build confidence that sensitive data will only
be retained as long as strictly necessary. Data should be retained and stored securely in line with their
sensitivity. Data custodians should ensure that data are protected and secure throughout their lifetime.
This is especially the case for personal and other sensitive data.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

63

HOW TO HANDLE AND PROCESS SHARED DATA?

Data should only be retained for as long as necessary to fulfil the purpose of their collection. Data retention
may be permanent for aggregated and anonymised data collected for planning purposes, as this provides
valuable time-series data. However, retention periods for personal or other sensitive data should be strictly
minimised to the time necessary to carry out the purpose of their collection. Public authorities may require
extended retention of certain types of data. For example, data processors may be required to securely
store payment data for tax purposes. In Vienna, Wiener Linien indicates that “purchase and/or order data
derived in connection with services of Wiener Linien will be deleted at the end of a period of 7 years due
to legal obligations for retaining data for tax purposes” (Wiener Linien, 2021).
The data processor should specify retention rules. Additionally, if a data or dataset is not further processed,
the data processor should indicate the reason for retention. Post-processing protocols will depend on thetype of data (e.g. commercially sensitive, personal or non-personal). Data retention periods may bedifferent depending on existing regulations. For personal data, data processors should open the possibility
for the user to request the immediate deletion of their data. In Paris, RATP (2021) maps different types of
personal data to adapted retention and deletion rules.
Protocols for safe deprecation or irreversible de-identification of personal data should be specified. If
personal data are collected, they should be processed and transformed once the purpose for theircollection is attained so that they no longer represent a privacy risk. Specific and documented protocols
for irreversibly de-identifying personal data should be adopted, communicated and applied. Oncede-identified, original data should be irreversibly destroyed. Before this destruction, data processors may
wish to log and archive meta-data for onward use in planning and evaluation.
In its guidance for private hire operators, TfL follows Information Commissioner’s Office (2022b)
recommendation regarding storage limitation. It indicates that operators “must not keep personal
information for any longer than is ‘necessary’’’. Privacy policies should clarify what “data erasure” means.
Erasure can refer to the permanent and secured deletion of the data or de-identification protocols (e.g.
noise or aggregation). In its privacy and data protection guidance for private hire operators, TfL (2019)states that “deletion” refers “to permanently and securely destroying that information at the end of its
retention period”. TfL further specifies that private hire operators should not “archive or move it so it canbe retrieved in the future”. This type of provision implies the deletion of electronic and any physicalformats where data are stored (e.g. paper, hard drives).
Retention periods and deletion rules may change with the evolution of legal provisions. In France, Article
R1115-16 (2021) requires MaaS providers to implement specific handling and deletion protocols before
transmitting statistical data to MaaS ecosystem stakeholders (e.g. transport operators and publicauthorities). MaaS providers must commit to sharing a minimal amount of data with transport operatorsand the transport authorities to improve the interoperability of transport services.
To that end, MaaS providers must use several protocols:64Before sharing data, MaaS providers must anonymise data. They must use robust protocols thatavoid potential re-identification of users.



Once anonymised, the MaaS provider aggregates the data.



The MaaS provider shares the aggregated data and deletes non-anonymised and non-aggregateddata.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

HOW TO HANDLE AND PROCESS SHARED DATA?

For non-personal data, Article 32 of the Loi d'orientation Des Mobilités (2019) states that relevant datafrom connected vehicles must be aggregated before being shared with infrastructure managers and public
transport authorities. These data are considered necessary to improve traffic, knowledge and emergency
interventions. The only exception is for data when the aggregation makes their use impossible.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

65

MAAS DATA SHARING: STATE OF PLAY

MaaS data sharing: State of play
There is a gap between potential future data sharing models in the MaaS ecosystem and current practice.
While most ecosystem actors rely on data to build and operate their transport services, the circulation ofdata is more complex because of issues related to competition (e.g. perceived risks) and lack of existing
solutions (e.g. low standardisation and lack of guidelines). MaaS data sharing also entails a new relationshipbetween market actors beyond simple competition. It constitutes a fundamental paradigm shift for most
MaaS ecosystem actors.
Efforts to promote more discussion between market actors are underway. Yet, it will take time to reachconsensus on answers to questions like “how and what data to share” or “how to manage data sharing”.
Several initiatives aim to promote more effective data sharing across MaaS market actors. This section
explores current efforts to improve data sharing in the context of a MaaS and identifies what solutions andrisks may emerge in the years to come.

Current efforts to improve data sharing
Mobility is a highly standardised sector where different initiatives have led to the development of multiple
data standards for real-time or static data regarding public transport, micromobility services and roadtraffic management. These mechanisms may share similarities, but their differences make them uniqueand often incompatible. For example, a “stop” is not represented in GTFS as in GBFS based on inherent
differences between public transport and micromobility operations. A public transport stop can be definedin point co-ordinates, whereas free-floating micromobility may reference a “stop” as a geofenced area.
The emergence of new mobility services (e.g. shared mobility services) and regulatory requirements (e.g.
the EU requiring the use of Europe’s Committee for Standardization’s [CEN] transmodel standards for
public transport data reporting) have driven the growth in the number of standardisation initiatives.
Standards may refer to data categories previously not (efficiently) covered by existing standards (e.g. GBFS
as a standard to allow data sharing on shared vehicles between market actors).
Within this complex landscape, data standardisation constitutes a partial answer to enabling data sharing
between the increasing number and types of mobility stakeholders. Yet, standardisation is a challenging
and tedious process that requires identifying the existing data sharing standards (e.g. mapping), promoting
standardisation results and reaching a consensus on the standard to use (MaaS Alliance, 2021)
Mapping data sharing ecology

There is no one-size-fits-all approach when it comes to data sharing. A taxonomy can help assess andunderstand the complex landscape of existing data sharing mechanisms between market actors. In themobility sector, several ongoing projects seek to index standards and APIs to understand the complex
ecology of mobility data sharing.

66

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MAAS DATA SHARING: STATE OF PLAY

For data standards, the Open Data Standards Directory provides an inventory of commonly used standards
in mobility, among other sectors. Chevallier et al. (2021) provided a state-of-the-art review of mobility data
standards as part of the MobiDataLab H2020 project. MobiDataLab taxonomy gathers standards fromvarious mobility domains (e.g. public transport, road traffic, micromobility and infrastructure). It also
considers ticketing and MaaS-related standards.
This work constitutes one stage of a two-part standardisation roadmap that aims to integrate existing data
standards and promote standardisation among data sharing mechanisms. MobiDataLab will provide
guidance and suggestions to improve mobility data sharing in a subsequent publication outlining how
existing standards might evolve and what new standards may be needed (Chevallier et al., 2021).
France-based Fabrique des Mobilités (2021) published a collaborative and open-source inventory of APIs
for mobility services and MaaS. APIs differ depending on the type of transport considered (e.g. carsharing,
public transport or micromobility).
Promoting standardisation results

Data mapping constitutes the first stage for promoting standardisation results. It presents threemain capabilities:
First, a quick mapping can help to establish the boundaries and overlaps between data standards.
Characterising an overlap between two data models requires a precise comparison between two data
models. Data overlapping occurs when models A and B are considered semantically equivalent and whenan attribute in B can replace an attribute in A without losing information. This type of mapping is relevant
when considering using specific data models to represent data elements (e.g. a reference model). If there
is no overlap between data models, A and B have different scopes. Therefore, the target model may not
be a contributing model. These mapping exercises require extensive knowledge of the various data
models. Several initiatives have noted overlaps between data models.
In 2019, a report published by the European Commission’s Joint Research Committee provided
recommendations to address overlaps and gaps existing in the data standards used for data sharing ofmobility information under Commission Delegated Regulation (EU) 2017/1926 concerning the provisionof EU-wide multimodal travel information services (MMTIS) (Bourée et al., 2019). The mapping analysis
showed that NeTEx, SIRI, and INSPIRE standards were sufficient to implement the regulation. The study
defined each data category listed in the Commission Delegated Regulation (EU) 2017/1926's annexe andspecified a reference standard and one or more contributing standards for each category. The study
concluded that several MMTIS data categories lacked a reference standard. There are two main obstacles
explaining this. First, the existence of gaps in standardisation (e.g. when the standard exists but is not yet
published or when there is no standard). Second, the absence of a reference standard (e.g. when two or
more standards efficiently contribute to a data category). The recommendations emphasised the need forfurther developments to address these data interoperability gaps across the different standards.
Second, a more comprehensive data mapping allows for finding correspondences, thus contributing tointegrating different data models.
Since 2020, the DATA4PT project has supported the development of mobility data standards and models
to improve multimodal data sharing. As part of the project, the DATA4PT consortium andMobilityData worked on a canonical mapping between GBFS to NeTEx and SIRI. The mapping aimed toprepare the addition of micromobility modes to NeTEx by finding semantical equivalence between

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

67

MAAS DATA SHARING: STATE OF PLAY

elements and attributes in each standard. The conclusions of this work were published as part of NeTEx
Part 5 specifications.
Mapping two separate models like GBFS, NeTEx and SIRI standards is not straightforward and can becomplex. In most cases, the mapping will require connecting attributes of two standards after ensuring
their definition and semantics (see Figure 16). Correspondences between attributes belonging to different
data models can be one-to-one. This means that for an attribute in the source model, there is one attributewith the same semantics in the target model (e.g. GBFS “System Region” and NeTEx’s “TOPOGRAPHIC
PLACE”). However, in other cases, a group of attributes in the source model may correspond to one
attribute in the target model. Conversely, one attribute in the source model can correspond to several
attributes in the target model. Finally, there may be no corresponding attribute in the target model.
Figure 16. Correspondence type when mapping two standards

Source data standard attributes

correspondence

One to one

One to many

One to (unknown)

Many to one?
Target data standard attributes
Source: based on Bourée (2021).

Third, a fully detailed mapping can create automated data converters – tools that convert data between
two formats automatically (DATA4PT, 2019).
Creating such a complete mapping is a resource-intensive and time-consuming process that requires anextensive understanding of the various data models. Already completed or ongoing mapping initiatives(e.g. DATA4PT) constitute a knowledge base that can be used to build conversion tools – for example,
converting GTFS to NeTEx.
Future data mapping initiatives should use or build upon existing and proven methods. In 2020, DATA4PT
published a stepwise methodology to compare different data standards (DATA4PT, 2020). The first step
consists of mapping at the data category level. This exercise identifies potential overlaps and provides arough correspondence between the main data categories. Equivalences can be recorded in a mappingtable. Linkages can be found by looking at similarities or equivalences between attributes’ terminologies(e.g. fare/price, schedule/timetable). The second step consists of the systematic comparison at the levelof concepts. At this stage, the semantics of the concepts are considered. Additional considerations
regarding the scope of the compared data models also occur at this stage. When comparing GTFS and68

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MAAS DATA SHARING: STATE OF PLAY

NeTEx, this step reveals that NeTEx uses more layers (e.g. reuse of routes, timing patterns and service
patterns) than GTFS. Finally, the third step compares the attribute level and their relationships.
APIs handle data sharing and interoperability in MaaS and elsewhere. APIs are particularly effective atthese tasks for all of the reasons outlined in the previous sections, but they are not the only conceivable
way to accomplish them. Whichever architectures are adopted for MaaS data sharing (or data sharing
more generally), they should anticipate a post-API world – that is, a world in which other data sharing andsystem interfaces emerge. Using APIs to modularise and task out essential functions already goes a long
way to anticipating new ways of establishing linkages between different systems. Beyond that, allecosystem actors should monitor and be aware of new mechanisms that may emerge to handle tasks APIs
handle today. Public authorities should ensure that the regulatory frameworks they develop for data
sharing allow room for adopting new mechanisms by MaaS ecosystem actors.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

69

MAAS DATA SHARING: A WAY FORWARD

MaaS data sharing: A way forward
Facilitating more seamless intermodal travel is a fundamental and long-standing focus of mobility policy– especially where infrastructure is saturated or, conversely, where vehicle capacity is poorly used. MaaS
is one strategy to address this paradox. It is a more recent concept placing the individual in the centre of
the mobility equation and empowering them to mix and match services according to their needs. However,
it is a concept that is still maturing, continuously evolving and seeking to find successful and scalable
implementations. What, then, can be said about charting a way forward so MaaS delivers value to people,
contributes to public policy objectives and ensures commercial opportunities when very little is currently
settled about MaaS?
At the outset, much of what will be required for MaaS to function, let alone scale, concerns data
governance in the MaaS ecosystem (and beyond). This is especially true for data sharing among ecosystem
actors – particularly between mobility operators and MaaS providers. As noted at the outset of this report,
mobility data, the mechanisms that produce and enable it to be shared and how data sharing is governed
constitute a new and evolving layer of foundational infrastructure. The central task – and challenge – forboth public and private sector actors is to think about how to structure and deploy that infrastructure to
improve people’s everyday lives.

Articulate a vision
Describing what mobility data infrastructure should look like at this early stage is perhaps less important
than articulating what that infrastructure should deliver. These outcomes include user-centricity, personalprivacy protection, public services meeting needs, value-creating markets framed by public authority
oversight and alignment with public policy objectives. These constitute a vision framing for what mobility
data infrastructure should enable rather than what it is. In the context of MaaS, this vision should emerge
from consensus-focused discussions among all ecosystem actors. But, in the end, it should be arbitrated
by public authorities who have a responsibility to deliver on their mandates to their constituents.
The vision framing data as infrastructure extends far beyond MaaS and mobility. The financial, health,energy and telecommunications sectors are also seeking to address similar challenges concerning data as
infrastructure, the role of platforms and how to manage data sharing, etc. The vision developed for MaaSand mobility data should adopt the same top-level principles guiding the same discussions in other sectors.
Public authorities should establish these visions at the highest level – sometimes even at the supra-national
level, as in the EU’s Data Strategy (European Commission, 2022).

Address uncertainty and early lock-in
Mobility data infrastructure is dissimilar to physical infrastructure as it is primarily virtual, relates toconcepts, models and code and can change rapidly. In contrast, physical infrastructure is built withconcrete, asphalt and iron, changes slowly (if at all) and lasts decades. The risk for lock-in due to sunken
investment is acute in the case of physical infrastructure but much less for data infrastructure.

70

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MAAS DATA SHARING: A WAY FORWARD

Nonetheless, lock-in risks exist for data infrastructure, especially regarding the adoption of specificsyntaxes, vendor-provided services or restrictive governance rules, which may hamper innovation.
Public authorities are responsible for actively shaping and guiding this infrastructure's development. Still,
given the uncertainties involved, this should occur mainly at the level of specifying key outcomes theinfrastructure should enable and measuring the performance of the MaaS ecosystem in achieving thoseoutcomes. This will require a mix of compulsion (e.g. requiring data sharing by MaaS ecosystem actors andthat it be linked to specific actionable interoperability mechanisms), incentivisation and innovation (e.g.
favouring the adoption of certain solutions while enabling more innovative solutions to emerge). For
example, work to this effect is underway in Europe with the multimodal digital mobility services (MDMS)
initiative. MDMS is defined as services “providing information on traffic and travel data such as location oftransport facilities, schedules, availability or fares for more than one transport mode, which may include
features enabling the making of reservations, bookings or payments or the issuing of tickets” covering bothurban and inter-urban travel. Work is underway to establish a robust legal framework for this initiative (DG
MOVE, 2021; 2022).

Leverage “data spaces” to shape data infrastructure aroundinteroperability and trust mechanisms
One way to incorporate strong interoperability and trust mechanisms by design and by default in mobility
data infrastructure is to establish “data spaces”. These encompass all data-producing and consuming
actors, processes and outcomes under a common set of principles, conditions and interoperability featuresthat deliver social value while balancing private and public interests (Nagel et al., 2021). A data space is “adecentralised infrastructure for trustworthy data sharing and exchange in data ecosystems based oncommonly agreed principles” (Nagel et al., 2021).
By comparison, physical public spaces are operated under principles, common practices and rules thathave emerged over centuries of human interactions in those spaces. These norms determine what can or
cannot happen on streets, pavements and other public spaces. This is also the case for buildings and thebuilt environment where public values shape, guide and sometimes constrain private actions. In contrast
with physical public spaces, digital public spaces have rapidly developed under rules, practices andconditions that favour private outcomes, sometimes at the expense of public outcomes (ITF, 2021c; vander Waal et al., 2020). Data spaces seek to re-balance these interactions and to ensure that a common
approach to data governance built on guiding principles, public value outcomes and interoperability isestablished across all sectors of the economy (Nagel et al., 2021).
The International Data Spaces Association-led OPEN DEI task force notes that “from a technicalperspective, a data space can be seen as a data integration concept which does not require common
database schemas and physical data integration, but is rather based on distributed data stores andintegration on an ‘as needed’ basis on a semantic level” (Nagel et al., 2021). Data spaces build on a core
set of building blocks common to all data spaces but tailored to specific contexts where necessary. Thesebuilding blocks establish for each sector, and across all sectors, common functional, legal, operational andtechnical norms and standards guiding data ecosystem interactions. Data infrastructure comprises thesecomponents, and because they are similarly structured within and across sectors, data interoperability andtrust are maximised (Figure 17).
The concept of multi-sectoral, linked data spaces has progressed most in Europe, forming an integral partof the European Commission’s European Strategy for Data (European Commission, 2020). The Commission

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

71

MAAS DATA SHARING: A WAY FORWARD

has identified nine initial domains to develop these federated data spaces – industry, health, energy,
agriculture, Green Deal, finance, public administration, skills and mobility.
Figure 17. Data space ecosystems and building blocks
Sectoral data spaces`
Data spaces as connected ecosystems

Data spaces based on common design principles enable a dynamic, secure and seamless flowof data/information between parties and domains as well as entirely new services for users,
based on enhanced transparency and data sovereignty. Federated data spaces acrossdifferent sectors enable participants to discover data resources across underlying platforms
and their administrative domains.

Neutral building blocks

INTEROPERABILITY

TRUSTDATA VALUE

GOVERNANCE

Data models andformats

Identity management

Metadata &discovery protocol

Overarching cooperationagreement

Data exchange APIs

Access & usage
control policies

Data usageaccounting

Operational e.g. service
level agreement

Provenance andtraceability

Trusted exchange

Publication andmarketplace services

Continuity model

Neutral building blocks comprise data infrastructure and establishes a level playing field fordata sharing and exchange. These are made up of technology-neutral and sector-agnostic
agreements and standards specifying how organisations and individuals can participate in thedata economy and how they need to act and behave in compliance with commonly agreed rules
and directives.

Assembling building blocks into data spaces

As all participants implement the same minimal set of functional, legal, technical andoperational agreements and standards, they can interact in the same manner , no matter what
data space they are operating in. Key building blocks and roles will form part of every data
space. In some cases, elements of some building blocks will need to be adapted for sectorspecific contexts and conditions.

Source: adapted from Nagel et al. (2021).

72

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

MAAS DATA SHARING: A WAY FORWARD

The European Commission is currently establishing the basis for the EU-wide mobility data space by
convening discussions around its structure, foundational norms and extent (European Commission, 2021a;
2021b). The approach is relevant for many existing data governance initiatives (e.g. the German Mobility
Data Space, the Netherlands-initiated iSHARE, MyData) and will also, when established, encompass the
MaaS ecosystem.

Deliver essential public data sharing building blocks
Public authorities have a role in developing or shaping many of the building blocks that underpin public
value-oriented data spaces – including for MaaS within a broader mobility data space. These building
blocks facilitate data sharing within the MaaS ecosystem and beyond.
First among these facilitators is secure official electronic identifiers for individuals. This, of course, can behandled by other non-public actors but will always reference official identity data. Public authorities canclose the loop by providing official and secure e-identity APIs.
A second facilitator relates to the third pillar of mobility data architecture – crafting machine-readable
regulations and authentication pathways (Figure 2). Examples include the FranceConnect APIs that MaaS
ecosystem actors can access to establish identity and rights.
A third facilitator relates to public guidance on API architecture and functionalities oriented to ensure
strong interoperability and effective, privacy-preserving data portability.

Improve public administration capacity
From a human resources perspective, talents and skills are central to a mature data sharing ecosystem.
For MaaS ecosystem actors, managing external data sources will require additional capacity (e.g. skilledhuman resources, knowledge and data culture). According to the UITP, many public transport operators
have gaps in their data management capacities (UITP, 2020c). Among the most cited gaps was the lack of
dedicated and skilled staff to analyse and manage data sharing initiatives along with difficulty valuing data
sharing and monitoring risks.
Managing mobility data infrastructure

Like other infrastructural layers (e.g. the built environment and transport network), managing mobility
data infrastructure will require skilled and dedicated resources. Currently, there is a structural mismatch
regarding data management capacity within the public sector. This problem is acute within the transport
sector, characterised by low margins, where additional costs related to data management capacity
constitute a barrier for organisations.
The public sector does not govern, value, and manage mobility data infrastructure like other foundational
infrastructure for now (e.g. the built environment and transport network) (OECD, 2019c). Publicorganisations often struggle with digital transformation due to legacy issues caused by approaches andmethods inherited from the analogue era. New challenges have also arisen with the growth in data sharing
and opportunities and require adapted policy actions. Addressing these challenges requires greater
comprehension and organisation.
Conversely, many private sector actors already address this skill capacity issue. New market actors (e.g.
micromobility) place data at the centre of their strategy. From a market-wide perspective, this creates an

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

73

MAAS DATA SHARING: A WAY FORWARD

asymmetric situation where public sector organisations lag behind private market actors in terms ofcomprehension and culture regarding data. Deloitte (2015) indicated that 69% of the public sector
respondents to a survey felt that their digital strategy was lagging behind that of the private sector. This
structural mismatch is simultaneously a cause and a consequence of the public sector’s lack of
attractiveness for data-related jobs compared to the private sector. The public sector lags behind theprivate sector, making it less attractive for talent than the private sector.
Capacity is not only about doing but also about understanding. From a policy perspective, inefficientsituations can arise from a skill mismatch between the public and private sectors. Public sector
organisations lack of comprehension can often hinder their ability to reach policy objectives. The lack ofknowledge and understanding may result in inefficient management of mobility data infrastructure. Thissituation can be witnessed in other foundational infrastructure management. Addressing skills and talent
asymmetry is crucial to overcoming such negative market externalities.
Improving capacity: Recruit, upskill and reskill

Improving capacity is also crucial to cope with the impact of digitalisation on the public sector workforce(OECD, 2021e). As the transport market becomes increasingly digitalised, public organisations canimplement various actions to close the skills gaps. Improvement of recruitment practices can help copewith eventual internal skills shortages. Market actors who cannot internally recruit dedicated and skilledhuman resources can improve their data management capacity by outsourcing data management actions
to the private sector. They can also take advantage of existing tools and solutions developed by othermarket actors that provide access to data management expertise.
Technical assistance centres supported by local, regional or national public authorities could also help close
the skills gap. Such centres could:

provide knowledge to the public sector regarding the use of existing standards



support the drafting of harmonised regulations concerning data

be involved in harmonisation initiatives amongst existing standards

ensure the quality of data shared for MaaS and that it is compliant with local privacy regulations.

Finally, new approaches towards public-private partnerships (PPP) for skills development can address skill
shortages in the public sector. According to European Training Foundation (2020), PPP for skills
development can be a response in markets with a skills mismatch. This form of partnership has a long
history in Europe, where governments, public organisations and businesses often developed PPP for skills.
PPP for skills requires a common understanding of the role of data management skills. It further indicatesthat skill may become a new area for social dialogue between public and private actors (European Training
Foundation, 2020).

74

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

References
1001 Lakes Oy et al. (2021), Personal Data Management Minimum Interoperability Mechanism (MIM) 4
Introduction and Specifications, www.vastuugroup.fi/hubfs/MyData/2021-05-31 MIM4 - Personal DataManagement Specification - Final draft.pdf (accessed 31 August 2022).
Alonso-González, M.J. et al. (2020), “Drivers and barriers in adopting Mobility as a Service (MaaS) – Alatent class cluster analysis of attitudes”, Transportation Research Part A: Policy and Practice, Vol. 132,
pp. 378-401, https://doi.org/10.1016/j.tra.2019.11.022 (accessed 31 August 2022).
Alyavina, E., Nikitas, A. and Njoya, E.T. (2022), “Mobility as a service (MaaS): A thematic map ofchallenges and opportunities”, Research in Transportation Business & Management, Vol. 43, p. 100783,
https://doi.org/10.1016/J.RTBM.2022.100783 (accessed 31 August 2022).
Arias-Molinares, D. and García-Palomares, J.C. (2020), “The Ws of MaaS: Understanding mobility as aservice from a literature review”, IATSS Research, Vol.44/3, pp. 253-263, https://doi.org/10.1016/
J.IATSSR.2020.02.001 (accessed 31 August 2022).
Article 29 Data Protection Working Party (2016), Guidelines on the right to data portability, https://ec.
europa.eu/newsroom/document.cfm?doc_id=44099, (accessed 31 August 2022).
L’Assemblée fédérale de la Confédération suisse (2022), Loi fédérale concernant l’infrastructure dedonnées sur la mobilité (LIDMo) – projet, www.newsd.admin.ch/newsd/message/attachments/70080.pdf(accessed 18 July 2022).
Assemblée Nationale (2019), Article 32 de la Loi d’orientation des mobilités, Assemblée Nationale, Paris,
www.legifrance.gouv.fr/loda/article_lc/LEGIARTI000039668973/2019-12-27 (accessed 1 September2022).
Audouin, M. and Finger, M. (2019), “Empower or Thwart? Insights from Vienna and Helsinki regarding
the role of public authorities in the development of MaaS schemes”, Transportation Research Procedia,
Vol. 41, pp. 6-16, https://doi.org/10.1016/j.trpro.2019.09.003 (accessed 31 August 2022).
Banerjee, I., Jittrapirom, P. and Dangschat, J.S. (2021), “Data-driven urbanism, digital platforms, and theplanning of MaaS in times of deep uncertainty: What does it mean for CAVs?”, AVENUE21. Politische undplanerische Aspekte der automatisierten Mobilität, pp. 441-470, https://doi.org/10.1007/978-3-66263354-0_20 (accessed 31 August 2022).
Basel Committee on Banking Supervision (2019), Report on open banking and application programming
interfaces, Basel, www.bis.org/bcbs/publ/d486.pdf (accessed 7 October 2022).
Billoud, B. (2020), “Gtfs2NetexFr, nouvel outil open source pour produire des données transport, La
Fabrique des Mobilités”, Fabrique des Mobilités blog, https://lafabriquedesmobilites.fr/blog/
gtfs2netexfr-nouvel-outil-open-source-pour-faciliter-la-production-de-donnees-transport-au-formatnetex (accessed 18 July 2022).
Borgogno, O. and Colangelo, G. (2019), “Data sharing and interoperability: Fostering innovation andcompetition through APIs”, Computer Law & Security Review, Vol. 35/5, p. 105314, https://doi.org/
10.1016/j.clsr.2019.03.008 (accessed 7 October 2022).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

75

REFERENCES

Bourreau, M., Krämer, J. and Buiten, M. (2022), Interoperability in Digital Markets, https://cerre.eu/wpcontent/uploads/2022/03/220321_CERRE_Report_Interoperability-in-Digital-Markets_FINAL.pdf(accessed 27 December 2022).
Bourée, K. et al. (2019), INSPIRE-MMTIS: overlap in standards related to the Delegated Regulation (EU)2017/1926, EUR 29975 EN, Publications Office of the European Union, Luxembourg, http://dx.doi.org/10.2760/404745 (accessed 27 March 2023).
Busch, C. (2021), Regulation of Digital Platforms as Infrastructures for Services of General Interest, Bonn,https://library.fes.de/pdf-files/wiso/17836.pdf (accessed 16 July 2022).
Calderón, F. and Miller, E.J. (2020), “A literature review of mobility services: definitions, modelling stateof-the-art, and key considerations for a conceptual modelling framework”, Transport Reviews, Vol. 40/3,
pp. 312-332, https://doi.org/10.1080/01441647.2019.1704916 (accessed 27 December 2022).
Callegati, F. et al. (2017), “I want to ride my bicycle: A microservice-based use case for a MaaSarchitecture”, 2017 IEEE Symposium on Computers and Communications (ISCC), IEEE, pp. 18-22, https://doi.org/10.1109/ISCC.2017.8024498 (accessed 27 December 2022).
Carey, C. (2022), “European cities leverage data for safer and smarter roads, International
Telecommunication Union”, International Telecommunication Union News, www.itu.int/hub/2022/03/
road-safety-data-europe-cities-today/ (accessed 20 June 2022).
Carnegie Mellon University (2021), “Data Custodians - Information Security Office - Computing Services”,
webpage, www.cmu.edu/iso/governance/roles/data-custodian.html (accessed 1 September 2022).
Chevalier, T. et al. (2021), D2.4 State-of-the-art on Mobility Data sharing standards, Brussels,
https://mobidatalab.eu/wp-content/uploads/2022/01/MobiDataLab-D2.4-StateOfTheArtOnMobility
DataSharingStandards-v2.0DRAFT.pdf (accessed 8 October 2022).
Chinn, D. et al. (2020), “The future is now: Closing the skills gap in Europe’s public sector”, McKinsey &Company article, www.mckinsey.com/~/media/McKinsey/Industries/Public%20Sector/Our%20Insights/
The%20future%20is%20now%20Closing%20the%20skills%20gap%20in%20Europes%20public%20sector/
The-future-is-now-Closing-the-skills-gap-in-Europes-public-sector-vF.pdf (accessed 27 December 2022).
Chitkara, A. et al. (2020), Enabling data-sharing: Emerging principles for transforming urban mobility
Enabling data-sharing, World Business Council for Sustainable Development, Geneva, www.wbcsd.org/
contentwbc/download/8198/127647/1 (accessed 12 October 2021).
Code des transports (2021), Article R1115-16, Paris, www.legifrance.gouv.fr/codes/article_lc/
LEGIARTI000044455745/2022-01-01 (accessed 1 September 2022).
Commission for Energy Regulation (2015), Public Service Obligation Levy 2015/2016, Decision Paper,
Dublin, www.cru.ie/wp-content/uploads/2015/07/CER15142-PSO-Levy-2015-16-Decision-Paper.pdf(accessed 16 June 2022).
Cour des Comptes (2013), Les relations entre l’État et les sociétés concessionnaires d’autoroutes, Paris
www.ccomptes.fr/sites/default/files/EzPublish/relations_Etat_societes_concessionnaires_autoroutes.pdf(accessed 27 December 2022).
Cremer, J., de Montjoye, Y.-A. and Schweitzer, H. (2019), Competition Policy for the Digital Era, European
Commission, Directorate-General for Competition, Publications Office, https://doi.org/10.2763/407537(accessed 27 December 2022).

76

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

Crozet, Y. and Coldefy, J. (2021), Mobility as a Service (MaaS): A Digital Roadmap for Public Transport
Authorities, Centre on Regulation in Europe, https://cerre.eu/wp-content/uploads/2021/01/CERRE_EN_
Mobility-as-a-Service-MaaS_A-digital-roadmap-for-organisational-authorities_January2021.pdf (accessed
27 December 2022).
Culnane, C., Rubinstein, B.I.P. and Teague, V. (2019), Stop the Open Data Bus, We Want to Get Off, The
University of Melbourne, https://doi.org/10.48550/arXiv.1908.05004 (accessed 22 June 2022).
DATA4PT (2020), Methodology for comparing data standards, Brussels, https://data4pt-project.eu/wpcontent/uploads/2021/03/Data4PT-Methodology-for-comparing-data-standards.pdf (accessed 27
December 2022).
DATA4PT and MobilityData (2022), GBFS to NeTEx & SIRI v1.0: A canonical mapping produced by
MobilityData and DATA4PT, https://drive.google.com/file/d/1bvxr8s4tOEJigstJUt_qyA2dn29jC84O/view(accessed 16 October 2022).
Data Protection Working Party (2014), Article 29 Data Protection Working Party, Brussels, http://ec.
europa.eu/justice/data-protection/index_en.htm (accessed 23 June 2022).
De Hert, P. et al. (2018), “The right to data portability in the GDPR: Towards user-centric interoperabilityof digital services”, Computer Law & Security Review, Vol. 34/2, pp. 193-203, https://doi.org/10.1016/
J.CLSR.2017.10.003 (accessed 16 June 2022).
Deloitte (2015), “Digital Government Transformation: The Journey to Government’s Digital Future”,
Deloitte Perspectives blog, www.deloitte.com/global/en/Industries/government-public/perspectives/digital-government-transformation.html (accessed 27 December 2022).
Deloitte (2017), Assessing the value of TfL’s open data and digital partnerships, London,
https://content.tfl.gov.uk/deloitte-report-tfl-open-data.pdf (accessed 19 July 2022).
DETEC (2022), Loi fédérale concernant l’infrastructure de données sur la mobilité: Rapport explicatif
relatif à l’ouverture de la procédure de consultation, Département fédéral de l’environnement, destransports, de l’énergie et de la communication de la Confédération suisse, Ittigen, www.newsd.admin.
ch/newsd/message/attachments/70140.pdf (accessed 16 July 2022).
De Streel, A., Krämer, J. and Senellart, P. (2021), Making Data Portability More Effective for the Digital
Economy, Centre on Regulation in Europe, https://cerre.eu/wp-content/uploads/2020/07/cerre_making_data_portability_more_effective_for_the_digital_economy_june2020.pdf (accessed 16 October 2022).
DG MOVE - EU (2021), “Multimodal digital mobility services - Inception Impact Assessment”, Ref.
Ares(2021)6062336-05/10/2021, https://ec.europa.eu/info/law/better-regulation/ (accessed 16 October2022).
DG MOVE - EU (2022), “1st Public Workshop impact assessment for the initiative on Multimodal Digital
Mobility Services”, news article, https://transport.ec.europa.eu/news/1st-public-workshop-impactassessment-initiative-multimodal-digital-mobility-services-2022-03-17_en (accessed 16 October 2022).
DINUM (2022), “Tarification sociale et solidaire des transports”, Direction Interministérielle duNumérique, webpage, https://api.gouv.fr/guides/delivrance-titres-transport (accessed 8 September2022).
Dodds, L. and Wells, P. (2019), “Data Infrastructure”, in Davies T. et al. (eds), The State of Open Data:
Histories and Horizons, African Minds and International Development Research Centre, Cape Town and

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

77

REFERENCES

Ottawa, https://idl-bnc-idrc.dspacedirect.org/bitstream/handle/10625/57585/The%20State%20of%20
Open%20Data.pdf?sequence=2&isAllowed=y (accessed 27 December 2022).
Durand, A. et al. (2018), Mobility-as-a-Service and changes in travel preferences and travel behaviour: aliterature review, https://doi.org/10.13140/RG.2.2.32813.33760 (accessed 27 December 2022).
Durand, A. et al. (2022), “Access denied? Digital inequality in transport services”, Transport Reviews, Vol.
42/1, pp. 32-57, https://doi.org/10.1080/01441647.2021.1923584 (accessed 27 December 2022).
EBA (2016), “Article 23 - Payment Services Directive 2 (PSD2)”, European Banking Authority, webpage,www.eba.europa.eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/5508 (accessed 7
October 2022).
Ecoplan (2019), Daten als Infrastruktur für multimodale Mobilitätsdienstleistungen [Data as
infrastructure for multimodal mobility services], Bern, www.newsd.admin.ch/newsd/message/
attachments/61994.pdf (accessed 16 July 2022).
Eichhorn, H. (2020), “Automatic ticketing: the Swiss way”, Transport Ticketing Global – 2020, Alliance
SwissPass, www.transport-ticketing.com/__media/2020-presentations/D1T2---16-50---HelmutEichhorn.pdf (accessed 9 October 2022).
EU (2022a), Proposal for a REGULATION OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on
harmonised rules on fair access to and use of data (Data Act), https://eur-lex.europa.eu/legalcontent/en/ALL/?uri=COM:2022:68:FIN (accessed 10 October 2022).
EU (2022b), Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September
2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and(EU) 2020/1828 (Digital Markets Act) (Text with EEA relevance), https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A32022R1925 (accessed 16 October 2022).
European Commission (2009), Directive 2009/72/EC of The European Parliament and of the Council of 13
July 2009 concerning common rules for the internal market in electricity and repealing Directive
2003/54/EC, Brussels, https://eurlex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:211:0055:
0093:EN:PDF (accessed 27 March 2023).
European Commission (2011), Commission Recommendation of 18 July 2011 on access to a basic
payment account, Brussels, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32011H0442(accessed 16 June 2022).
European Commission (2014), Directive 2014/92/EU of the European Parliament and of the Council of 23
July 2014 on the comparability of fees related to payment accounts, payment account switching andaccess to payment accounts with basic features, Brussels, https://eur-lex.europa.eu/legal-content/EN/
TXT/PDF/?uri=CELEX:32014L0092&from=en (accessed 16 June 2022).
European Commission (2016), Regulation (EU) 2016/679 of the European Parliament and of the Councilof 27 April 2016 on the protection of natural persons with regard to the processing of personal data andon the free movement of such data, and repealing Directive 95/46/EC (General Data Protection
Regulation), Brussels, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A02016R067920160504&qid=1532348683434 (accessed 22 June 2022).
European Commission (2019), Directive (EU) 2019/1024 of the European Parliament and of the Council of
20 June 2019 on open data and the re-use of public sector information, Brussels, https://eur-lex.europa.
eu/legal-content/EN/TXT/?uri=CELEX%3A32019L1024 (accessed 8 June 2022).

78

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

European Commission (2020), A European strategy for data, Brussels, https://eur-lex.europa.eu/legalcontent/EN/TXT/?uri=CELEX%3A52020DC0066 (accessed 10 October 2022).
European Commission (2021a), ‘Report-Workshop on the common European mobility data space
European Commission, CONNECT E4 (IoT) and MOVE B4 (Sustainable & Intelligent Transport)’,www.opendei.eu/about/ (accessed 11 October 2022).
European Commission (2021b), “Unlocking the potential of mobility data”, webpage, https://digitalstrategy.ec.europa.eu/en/policies/mobility-data (accessed 11 October 2022).
European Commission (2022), European data strategy: Making the EU a role model for a society
empowered by data, webpage, https://ec.europa.eu/info/strategy/priorities-2019-2024/europe-fitdigital-age/european-data-strategy_en (accessed 16 October 2022).
European Parliament (2006), Position of the European Parliament adopted at first reading on 16 February
2006 with a view to the adoption of Directive 2006/.../EC of the European Parliament and of the Council
on services in the internal market, Strasbourg, www.europarl.europa.eu/doceo/document/TA-6-2006-0216_EN.html (accessed 10 October 2022).
European Training Foundation (2020), Public-Private Partnerships for Skills Development: A Governance
Perspective, Volume I, Thematic overview, Publications Office, https://doi.org/10.2816/422369 (accessed
16 June 2022).
European Working Team on Digital Commons (2022), Towards a Sovereign Digital Infrastructure ofCommons, https://openfuture.eu/wp-content/uploads/2022/07/220624digital_commons_report.pdf(accessed 23 August 2022).
Fabrique des Mobilités (2021), “API service mobilité et MaaS”, webpage, https://wiki.
lafabriquedesmobilites.fr/wiki/API_service_mobilit%C3%A9_et_MaaS (accessed 21 July 2022).
Fainsilber, D. (2021), “Velib’: une nouvelle rallonge publique pour maintenir le système à flot”, Les Echos,
18 February, www.lesechos.fr/industrie-services/tourisme-transport/velib-une-nouvelle-rallongepublique-pour-maintenir-le-systeme-a-flot-1291475 (accessed 16 June 2022).
Feasey, R. and de Streel, A. (2020), Data sharing for digital markets contestability: towards a governanceframework, Centre on Regulation in Europe, Brussels, https://cerre.eu/wp-content/uploads/2020/09/
CERRE_Data-sharing-for-digital-markets-contestability-towards-a-governance-framework_September
2020.pdf (accessed 16 June 2022).
Finck, M. and Pallas, F. (2020), “They who must not be identified—distinguishing personal from nonpersonal data under the GDPR”, International Data Privacy Law, Vol. 10/1, pp. 11-36,
https://doi.org/10.1093/idpl/ipz026 (accessed 16 June 2022).
Finger, M. and Montero, J. (2022), “The digitalisation of infrastructure and infrastructure-based (public)
services: what are the problems?”, Network Industries Quarterly, Vol. 24/1, www.network-industries.org/
wp-content/uploads/2022/03/The-digitalisation-of-infrastructure-and-infrastructure-based-publicservices-what-are-the-problems.pdf (accessed 23 March 2023).
Florez Ramos, E. and Blind, K. (2020), “Data portability effects on data-driven innovation of online
platforms: Analyzing Spotify”, Telecommunications Policy, Vol. 44/9, p. 102026, https://doi.org/10.1016/
J.TELPOL.2020.102026 (accessed 16 June 2022).
Foundational Economy Collective (2022), Foundational economy: The infrastructure of everyday life,
Manchester University Press.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

79

REFERENCES

French Government (2021), Décret n° 2021-1595 du 7 décembre 2021 relatif au service numériqued’information et de billettique multimodal – Légifrance, Paris, www.legifrance.gouv.fr/jorf/id/
JORFTEXT000044454451 (accessed 7 October 2022).
Furman, J. et al. (2019), Unlocking digital competition: Report of the Digital Competition Expert Panel, HM
Treasury, https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_
data/file/785547/unlocking_digital_competition_furman_review_web.pdf (accessed 17 July 2022).
Gal, M.S. and Rubinfeld, D.L. (2019), “Data Standardization”, New York University Law Review, Vol. 94/4,
www.nyulawreview.org/issues/volume-94-number-4/data-standardization/ (28 August 2022).
Gegick, M. and Barnum, S. (2005), Least Privilege, Addison-Wesley.
Hansel, S. (2019), “All of Switzerland in one trip”, T-Systems‘ customer magazine, Issue 01, www.tsystems.com/de/en/newsroom/best-practice/01-2019-realtime/all-of-switzerland-in-one-trip (accessed
9 October 2022).
Hensher, D. (2022), “The Reason MaaS is such a Challenge”, The University of Sydney Business School‘Thinking outside the box’ series, www.sydney.edu.au/business/news-and-events/news/2022/07/04/thereason-maas-is-such-a-challenge.html (accessed 21 July 2022).
Hensher, D.A. et al. (2020), “MaaS trials—What have we learnt?”, Understanding Mobility as a Service(MaaS), pp. 59-75, https://doi.org/10.1016/b978-0-12-820044-5.00004-x (accessed 16 October 2022).
Hensher, D.A. et al. (2021), “Mobility as a service and private car use: Evidence from the Sydney MaaS
trial”, Transportation Research Part A: Policy and Practice, Vol. 145, pp. 17-33, https://doi.org/10.1016/j.tra.2020.12.015 (accessed 16 June 2022).
Hensher, D.A., Mulley, C. and Nelson, J.D. (2021), “Mobility as a service (MaaS) – Going somewhere or
nowhere?”, Transport Policy, Vol. 111, pp. 153-156, https://doi.org/10.1016/J.TRANPOL.2021.07.021(accessed 16 June 2022).
Hensher, D.A. and Xi, H. (2022), “Mobility as a service (MaaS): are effort and seamlessness the keys to
MaaS uptake?”, Transport Reviews, Vol. 42/3, pp. 269-272, https://doi.org/10.1080/01441647.2022.
2044590 (accessed 16 June 2022).
Heuser, L. et al. (2017), EIP-SCC Open Urban Platforms Work Stream 2: Reference Architecture & Design
Principles, European Innovation Partnership for Smart Cities & Communities, http://espresso.espressoproject.eu/wp-content/uploads/2018/04/EIP-SCC-OUP-WS2-Reference-Architecture-and-DesignPrinciples-Main.pdf (accessed 29 August 2022).
Hoffmann, J. and Gonzalez Otero, B. (2020), “Demystifying the Role of Data Interoperability in the Accessand Sharing Debate”, SSRN Electronic Journal (preprint), https://doi.org/10.2139/ssrn.3705217 (accessed
16 June 2022).
Huber, N. (2022), “Transport systems give hackers a moving target”, Financial Times, 1 June, www.ft.com/content/dc3cccb0-533c-4c5b-bc20-5ee3d422909f (accessed 21 June 2022).
IAPP (2020), Why data review boards are a promising tool for improving institutional decision-making,International Association of Privacy Professionals, webpage, https://iapp.org/news/a/why-data-reviewboards-are-a-promising-tool-for-improving-institutional-decision-making/ (accessed 31 August 2022).
IBM (2022), “What is an API (application programming interface)?”, webpage, https://www.ibm.com/
cloud/learn/api (accessed 31 August 2022).

80

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

IES-City (2018), A Consensus Framework for Smart City Architectures, Internet-of-Things-Enabled Smart
City Framework, https://s3.amazonaws.com/nist-sgcps/smartcityframework/files/iescity_framework/IES-CityFramework_Version_1_0_20180930.pdf (accessed 29 August 2022).
Infocomm Media Development Authority (2019), Guide to Data Valuation for Data Sharing, Singapore,https://www.imda.gov.sg/-/media/Imda/Files/Programme/AI-Data-Innovation/Guide-to-Data-Valuationfor-Data-Sharing.pdf. (accessed 24 March 2023)
Information Commissioner’s Office (2022a), “Contracts and data sharing”, wepage, https://ico.org.uk/for-organisations/accountability-framework/contracts-and-data-sharing/ (accessed 24 March 2023).
Information Commissioner’s Office (2022b), “Principle (e): Storage limitation”, webpage https://ico.org.
uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulationgdpr/principles/storage-limitation/ (accessed 1 September 2022).
Ireland 2050 (2022), “What is the Public Service Obligation and what does it pay for?”, webpage,https://irelandenergy2050.ie/present/electricity/?q=what-is-the-public-service-obligation-and-whatdoes-it-pay-for (accessed 16 June 2022).
iSHARE (2021), “iSHARE Trust Framework”, webpage, https://ishareworks.atlassian.net/wiki/spaces/
IS/overview?homepageId=70025239 (7 October 2022).
ITF (2013), Funding Urban Public Transport: Case Study Compendium, OECD Publishing, Paris, www.itfoecd.org/sites/default/files/docs/13compendium.pdf (accessed 16 June 2022).
ITF (2015), “Big Data and Transport”, International Transport Forum Policy Papers, OECD Publishing,Paris, www.itf-oecd.org/sites/default/files/docs/15cpb_bigdata_0.pdf (accessed 27 February 2021).
ITF (2016), “Data-Driven Transport Policy”, International Transport Forum Policy Papers, OECD Publishing,Paris, www.itf-oecd.org/sites/default/files/docs/data-driven-transport-policy.pdf (accessed 27 February2021).
ITF (2017), Income Inequality, Social Inclusion and Mobility, ITF Roundtable Reports, OECD Publishing,Paris, www.itf-oecd.org/sites/default/files/docs/income-inequality-social-inclusion-mobility.pdf(accessed 27 December 2022).
ITF (2018a), “Blockchain and Beyond: Encoding 21st Century Transport”, International Transport Forum
Policy Papers, OECD Publishing, Paris, https://www.itf-oecd.org/sites/default/files/docs/blockchain-andbeyond-encoding-21st-century-transport.pdf (accessed 27 December 2022).
ITF (2018b), “The Shared-Use City: Managing the Curb”, International Transport Forum Policy Papers,
OECD Publishing, Paris, www.itf-oecd.org/sites/default/files/docs/shared-use-city-managing-curb_5.pdf(accessed 27 December 2022).
ITF (2019), “Governing Transport in the Algorithmic Age”, International Transport Forum Policy Papers,
OECD Publishing, Paris, www.itf-oecd.org/sites/default/files/docs/governing-transport-algorithmicage.pdf (accessed 27 February 2021).
ITF (2020), Leveraging Digital Technology and Data for Human-Centric Smart Cities: The Case of Smart
Mobility, OECD Publishing, Paris, www.itf-oecd.org/sites/default/files/docs/data-human-centric-citiesmobility-g20.pdf (accessed 16 July 2022).
ITF (2021a), “Developing innovative mobility solutions in the Brussels-Capital Region”, International
Transport Forum Policy Papers, No. 97, OECD Publishing, Paris, https://www.itf-oecd.org/sites/default/
files/docs/innovative-mobility-brussels-captial-region.pdf (accessed 27 December 2022).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

81

REFERENCES

ITF (2021b), Integrating Public Transport into Mobility as a Service: Summary and Conclusions, ITF
Roundtable Reports, No. 184, OECD Publishing, Paris, www.itf-oecd.org/sites/default/files/docs/
integrating-public-transport-maas.pdf (accessed 27 December 2022).
ITF (2021c), “Reporting Mobility Data: Good Governance Principles and Practices”, International
Transport Forum Policy Papers, No. 101, OECD Publishing, Paris, www.itf-oecd.org/sites/default/
files/docs/reporting-mobility-data-governance-principles-practice.pdf (accessed 17 July 2022).
ITF (2021d), Reversing Car Dependency: Summary and Conclusions, ITF Roundtable Reports, No. 181,
OECD Publishing, Paris, www.itf-oecd.org/sites/default/files/docs/reversing-car-dependency.pdf(accessed 27 December 2022).
ITF (2021e), “The Innovative Mobility Landscape: The Case of Mobility as a Service”, International
Transport Forum Policy Papers, No. 92, OECD Publishing, Paris, www.itf-oecd.org/sites/default/
files/docs/innovative-mobility-landscape-maas.pdf (accessed 13 October 2021).
ITF (2021f), Travel Transitions: How Transport Planners and Policy Makers Can Respond to Shifting
Mobility Trends, ITF Research Reports, OECD Publishing, Paris, www.itf-oecd.org/sites/default/
files/docs/travel-transitions-shifting-mobility-trends.pdf (accessed 21 July 2022).
ITF (2022) “Streets That Fit: Re-allocating Space for Better Cities”, International Transport Forum Policy
Papers, No. 100, OECD Publishing, Paris, www.itf-oecd.org/streets-fit-re-allocating-space-cities (accessed
16 June 2022).
Janssen, M., Chun, S.A. and Gil-Garcia, J.R. (2009), “Building the next generation of digital government
infrastructures”, Government Information Quarterly, Vol. 26/2, pp. 233-237, https://doi.org/10.1016/
J.GIQ.2008.12.006 (accessed 13 October 2021).
Jittrapirom, P. et al. (2017a), “Mobility as a service: A critical review of definitions, assessments ofschemes, and key challenges”, Urban Planning, Vol. 2/2, pp. 13-25, https://doi.org/10.17645/UP.V2I2.
931 (accessed 13 October 2021).
Jittrapirom, P. et al. (2018), “Dynamic adaptive policymaking for implementing Mobility as a Service(MaaS)”, Research in Transportation Business and Management, Vol. 27, https://doi.org/10.1016/j.rtbm.
2018.07.001 (accessed 17 October 2022).
Jones, C. and Tonetti, C. (2019), “Nonrivalry and the Economics of Data”, National Bureau Of Economic
Research working paper, Cambridge, https://doi.org/10.3386/w26260 (accessed 17 October 2022).
Kamargianni, M. and Matyas, M. (2017), “The business ecosystem of mobility as a service”, 96th
Transportation Research Board Annual Meeting, Washington DC, 8-12 January, https://discovery.ucl.ac.
uk/id/eprint/10037890/1/a2135d_445259f704474f0f8116ccb625bdf7f8.pdf (accessed 17 July 2022).
Karabey Aksakalli, I. et al. (2021) “Deployment and communication patterns in microservice
architectures: A systematic literature review”, Journal of Systems and Software, Vol. 180, https://doi.org/10.1016/j.jss.2021.111014 (accessed 17 July 2022).
Kerber, W. and Schweitzer, H. (2017), “Interoperability in the Digital Economy”, JIPITEC – Journal ofIntellectual Property, Information Technology and E-Commerce Law (preprint), https://doi.org/10.2139/
ssrn.2922515 (accessed 17 July 2022).
Kitchin, R. and Dodge, M. (2011), Code/Space, The MIT Press, https://doi.org/10.7551/mitpress/978026
2042482.001.0001 (accessed 17 July 2022).

82

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

Krämer, J. (2021a), “Personal Data Portability In The Platform Economy: Economic Implications And
Policy Recommendations”, Journal of Competition Law & Economics, Vol. 17/2, pp. 263-308, https://doi.
org/10.1093/joclec/nhaa030 (accessed 17 July 2022).
Lancieri, F. and Sakowski, P. (2021), Competition in Digital Markets: A Review of Expert Reports.
Rochester, NY. Available at: https://papers.ssrn.com/abstract=3681322 (Accessed: 17 July 2022).
Langford, J. et al. (eds) (2022), Understanding MyData Operators, MyData Global, https://mydata.org/
wp-content/uploads/2022/03/Understanding-MyData-Operators-2022.pdf (accessed 7 September2022).
Lehrer, E. (2021), “Public Spaces in the Digital Age”, National Affairs, Vol. 49, https://www.national
affairs.com/publications/detail/public-spaces-in-the-digital-age (accessed 17 July 2022).
Le Monde (2016), “Citymapper, cette start-up qui agace la RATP”, 9 April, www.lemonde.fr/economie/
article/2016/04/09/citymapper-cette-start-up-qui-agace-la-ratp_4899122_3234.html (accessed 27 June2022).
Les Echos (2016), “Open data : bras de fer entre la RATP et l’appli Citymapper”, 12 April,www.lesechos.fr/2016/04/open-data-bras-de-fer-entre-la-ratp-et-lappli-citymapper-205481 (accessed
27 June 2022).
LI.EU (2021), “MIMs Plus: Living-in.EU Technical Specifications - version 4.0 FINAL”, Living-in.EU,
https://living-in.eu/sites/default/files/files/MIMs-Plus-v4-0-Final.pdf (accessed 17 July 2022).
Liimatainen, H. and Mladenović, M.N. (2018), “Understanding the complexity of mobility as a service”,
Research in Transportation Business and Management (preprint), https://doi.org/10.1016/j.rtbm.2018.
12.004 (accessed 17 July 2022).
Longo, A., Zappatore, M. and Navathe, S.B. (2019), “The unified chart of mobility services: Towards asystemic approach to analyze service quality in smart mobility ecosystem”, Journal of Parallel andDistributed Computing (preprint), https://doi.org/10.1016/j.jpdc.2018.12.009 (accessed 17 July 2022).
Lyons, G., Hammond, P. and Mackay, K. (2020), “Reprint of: The importance of user perspective in theevolution of MaaS”, Transportation Research Part A: Policy and Practice, Vol. 131, pp. 20-34, https://doi.
org/10.1016/j.tra.2019.11.024 (accessed 17 July 2022).
MaaS Alliance (2021), “Interoperability for Mobility, Data Models and API”, MaaS Alliance Working Group
3 - Position paper, https://maas-alliance.eu/wp-content/uploads/2021/11/20211120-Def-VersionInteroperaability-for-Mobility.-Data-Models-and-API-_-FINAL.pdf (accessed 17 July 2022).
Marsden, P. and Podszun, R. (2020), Restoring Balance to Digital Competition-Sensible Rules, Effective
Enforcement, Konrad-Adenauer-Stiftung, Berlin, www.kas.de/documents/252038/7995358/Restoring+
Balance+to+Digital+Competition+%E2%80%93+Sensible+Rules%2C+Effective+Enforcement.pdf/7cb5ab1
a-a5c2-54f0-3dcd-db6ef7fd9c78?version=1.0&t=1601365173489 (accessed 17 July 2022).
Mattioli, G. et al. (2020), “The political economy of car dependence: A systems of provision approach”,
Energy Research and Social Science, Vol. 66, p. 101486, https://doi.org/10.1016/j.erss.2020.101486(accessed 17 July 2022).
Mazzucato, M. (2015), The entrepreneurial state: debunking public vs. private sector myths, Public Affairs,
New York.

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

83

REFERENCES

Mazzucato, M. (2016), “From market fixing to market-creating: a new framework for innovation policy”,
Industry and Innovation, Vol. 23/2, pp. 140-156, https://doi.org/10.1080/13662716.2016.1146124(accessed 10 October 2022).
Mazzucato, M. (2018), Mission-oriented research & innovation in the European Union : a problem-solving
approach to fuel innovation-led growth, European Commission, Directorate-General for Research andInnovation, Publications Office, https://data.europa.eu/doi/10.2777/360325, (accessed 27 December2022).
MDIP (2022), “Mobility Data Interoperability Principles”, Mobility Data Interoperability Principles,
webpage, https://www.interoperablemobility.org/ (accessed 10 October 2022).
Montero, J. and Finger, M. (eds) (2021a), A modern guide to the digitalization of infrastructure, Edward
Elgar Publishing, Cheltenham.
Montero, J. and Finger, M. (2021b), The Rise of the New Network Industries Regulating Digital Platforms,
Taylor & Francis Group, Milton, http://public.eblib.com/choice/PublicFullRecord.aspx?p=6522772(accessed 10 October 2022).
Morell, M.F. (2014), “Governance of Online Creation Communities for the Building of Digital Commons:Viewed through the Framework of Institutional Analysis and Development”, in Frischmann, B.M.,
Madison, M.J. and Strandburg, K.J. (eds), Governing Knowledge Commons, Oxford Academic, New York,https://doi.org/10.1093/acprof:oso/9780199972036.003.0009 (accessed 1 September 2022).
MyData (2018), “Declaration of MyData Principles”, webpage, www.mydata.org/participate/declaration/(accessed 1 September 2022).
Nagel, L. et al. (2021), Design Principles for Data Spaces, position paper, version 1, Berlin,
http://doi.org/10.5281/zenodo.5105744 (accessed 8 October 2022).
National Academies of Sciences, Engineering, and Medicine (2020a), Data Sharing Guidance for Public
Transit Agencies: Now and in the Future, Data Sharing Guidance for Public Transit Agencies – Now and in
the Future, The National Academies Press, Washington, https://doi.org/10.17226/25696 (accessed 16
October 2022).
National Academies of Sciences, Engineering, and Medicine (2020b), Development of Transactional Data
Specifications for Demand-Responsive Transportation, The National Academies Press, Washington,https://doi.org/10.17226/25800 (accessed 16 October 2022).
Narayanan, A. and Shmatikov, V. (2006), How To Break Anonymity of the Netflix Prize Dataset,
https://doi.org/10.48550/arxiv.cs/0610105 (accessed 10 October 2022).
Nash, V. et al. (2017), “Public Policy in the Platform Society: Editorial”, Policy & Internet, Vol. 9/4, pp.
368-373, https://doi.org/10.1002/poi3.165 (accessed 1 September 2022).
NBDC (2022), “Human Data Review Board”, webpage, https://biosciencedbc.jp/en/aboutus/organization/dac/ (accessed 31 August 2022).
Nielsen, A. et al. (2021), D5.3 Impact assessment of Open Science in Transport, European forum andoBsErvatory for OPEN science in transport, https://beopen-project.eu/storage/files/beopen-d53-impactassessment-of-open-science-in-transport.pdf (accessed 10 October 2022).
NUMO (2021), Privacy Principles for Mobility Data, New Urban Mobility alliance, website,www.mobilitydataprivacyprinciples.org/ (accessed 31 August 2022).

84

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCESOASC (2021), “Minimal Interoperability Mechanisms – MIMs”, Open and Agile Smart Cities network,
webpage, https://oascities.org/minimal-interoperability-mechanisms/ (accessed 10 October 2022).
O’Callaghan, D. (2017), Public Service Obligation (PSO) Funding for Public Transport, Department of Public
Expenditure and Reform, Spending Review 2017, Ireland, https://assets.gov.ie/7287/772c34904b8e4cc
8969d3371b770d07d.pdf (accessed 10 October 2022).
OECD (2019a), Enhancing Access to and Sharing of Data: Reconciling Risks and Benefits for Data Re-use
Across Societies, OECD Publishing, Paris, https://doi.org/https://doi.org/10.1787/276aaca8-en (accessed
10 October 2022).
OECD (2019b), Measuring the Digital Transformation, OECD Publishing, Paris, https://doi.org/10.1787/9789264311992-en (accessed 10 October 2022).
OECD (2019c), The Path to Becoming a Data-Driven Public Sector, OECD Digital Government Studies,OECD Publishing, Paris https://doi.org/10.1787/059814A7-EN (accessed 10 October 2022).
OECD (2020), OECD Digital Economy Outlook 2020, OECD Publishing, Paris, https://doi.org/10.1787/
BB167041-EN (accessed 24 March 2023).
OECD (2021a), OECD (2021), “Building resilience: New strategies for strengthening infrastructure
resilience and maintenance”, OECD Public Governance Policy Papers, No. 05, OECD Publishing, Paris,
https://doi.org/10.1787/354aa2aa-en (accessed 10 October 2022).
OECD (2021b), Data Portability, Interoperability and Digital Platform Competition. OECD Publishing, Paris,
www.oecd.org/daf/competition/data-portability-interoperability-and-digital-platform-competition2021.pdf (accessed 10 October 2022).
OECD (2021c), “Mapping data portability initiatives, opportunities and challenges”, OECD Digital
Economy Papers, No. 321, OECD Publishing, Paris, https://doi.org/10.1787/a6edfab2-en (accessed 10
October 2022).
OECD (2021d), Report on the Implementation of the Recommendation of The Council Concerning
Guidelines Governing the Protection of Privacy and Transborder Flows of Personal Data, OECD Publishing,Paris, https://one.oecd.org/document/C(2021)42/en/pdf (accessed 10 October 2022).
OECD (2021e), Public Employment and Management 2021: The Future of the Public Service, OECD
Publishing, Paris, https://doi.org/10.1787/938f0d65-en (accessed 24 January 2023).
OpenAPI (2022), “GitHub - OAI/OpenAPI-Specification”, Repository, https://github.com/OAI/OpenAPISpecification (accessed 8 September 2022).
Pagoni, I. et al. (2022) “Mobility-as-a-service: insights to policymakers and prospective MaaS operators”,
Transportation Letters, Vol. 14/4, pp. 356-364, https://doi.org/10.1080/19427867.2020.1815141(accessed 16 October 2022).
Pangbourne, K. et al. (2018), “The Case of Mobility as a Service: A Critical Reflection on Challenges for
Urban Transport and Mobility Governance”, in Marsden, G. and Reardon, L. (eds), Governance of theSmart Mobility Transition, Emerald Publishing Limited, Bingley, pp. 33-48, pp. 33-48, https://doi.org/10.1108/978-1-78754-317-120181003 (accessed 13 October 2021).
Pickford, A. and Chung, E. (2019), “The shape of MaaS: The potential for MaaS Lite”, IATSS Research, Vol.
43/4, pp. 219-225, https://doi.org/10.1016/j.iatssr.2019.11.006 (accessed 13 October 2021).
Plotkin, D. (2021), Data stewardship: An actionable guide to effective data management and data
governance, 2nd ed, Academic Press.
MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

85

REFERENCES

Poikola, A. et al. (2020), MyData – an introduction to human-centric use of personal data, 3rd revised ed,
Finnish Ministry of Transport and Communications, https://mydata.org/wp-content/uploads/2020/08/
mydata-white-paper-english-2020.pdf (accessed 16 October 2022).
Polydoropoulou, A. et al. (2020), “Prototype business models for Mobility-as-a-Service”, Transportation
Research Part A: Policy and Practice, Vol. 131, pp. 149-162, https://doi.org/10.1016/j.tra.2019.09.035(accessed 16 October 2022).
Rahman, K.S. (2018), “Regulating Informational Infrastructure: Internet Platforms as the New Public
Utilities”, Georgetown Law Technology Review (preprint), Vol. 234, https://georgetownlawtechreview.
org/regulating-informational-infrastructure-internet-platforms-as-the-new-public-utilities/GLTR-072018/ (accessed 5 September 2022).
RATP (2021), “Politique de Données Personnelles”, Régie autonome des transports parisiens, webpage,www.ratp.fr/gestion-de-vos-donnees-personnelles (accessed 1 September 2022).
Rosenblum, P. and Maples, S. (2009), Contracts Confidential: Ending Secret Deals in the Extractive
Industries, Revenue Watch Institute, New York, https://resourcegovernance.org/sites/default/files/RWIContracts-Confidential.pdf (accessed 16 October 2022).
Rudolph, S. (2019), Digitale Medien, Partizipation und Ungleichheit [Digital media, participation andinequality], Springer Fachmedien, Wiesbaden, https://doi.org/10.1007/978-3-658-26943-2 (accessed 5
September 2022).
Schultz, S., Meda, P. and de Labaca, J. (2021), Etude des plateformes de mobilité, Agence de la Transition
Écologique, www.mobiliseyourcity.net/sites/default/files/2021-10/plateforme-des-mobilites-2021rapport.pdf (accessed 16 October 2022).
Scott Morton, F.M. et al. (2021), “Equitable Interoperability: The ‘Super Tool’ of Digital Platform
Governance’, SSRN Electronic Journal (preprint), https://doi.org/10.2139/ssrn.3923602 (accessed 16
October 2022).
Sénat (2020), Rapport fait au nom de la commission d’enquête sur le contrôle, la régulation et l’évolution
des concessions autoroutières, Paris, www.senat.fr/rap/r19-709-1/r19-709-11.pdf (accessed 27 July2022).
Soriano, S. et al. (2019), Big Tech Regulation: Empowering the Many by Regulating A Few, The Digital
New Deal, www.thedigitalnewdeal.org/wp-content/uploads/Big-Tech-Regulation_DigitalNewDeal
Foundation-1.pdf (accessed 1 September 2022).
Storme, T. et al. (2020), “Limitations to the car-substitution effect of MaaS. Findings from a Belgian pilot
study”, Transportation Research Part A: Policy and Practice, Vol. 131, pp. 196-205, https://doi.org/10.
1016/j.tra.2019.09.032 (accessed 16 October 2022).
SuM4All (2021), “Sustainable Mobility: Policy Making for Data Sharing”, website, http://www.sum4all.org(accessed 31 August 2022).
Surblyte, G. (2016), “Data as a Digital Resource”, Max Planck Institute for Innovation and Competition
Research Paper, No. 16-12, Available at: https://doi.org/10.2139/ssrn.2849303 (accessed 16 October2022).
SynchroniCity (2020), “A guide to SynchroniCity: A universal approach to developing, procuring anddeploying IoT- and AI-enabled services”, webpage, https://synchronicity-iot.eu/ (accessed 16 October2022).

86

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

REFERENCES

Teal, R. et al. (2020), “Development of Transactional Data Specifications for Demand-Responsive
Transportation”, Transit Cooperative Research Program, The National Academies Press, Washington,https://doi.org/10.17226/25800 (accessed 16 October 2022).
TfL (2019), Privacy and data protection A guide for private hire operators Introduction and scope, London,
https://content.tfl.gov.uk/2019-05-ph-operator-pdp-guidance.pdf (accessed 23 March 2023).
The Daily Swig (2022), “Vulnerability in PostBus public transport platform exposed customer data”, 31January, https://portswigger.net/daily-swig/vulnerability-in-postbus-public-transport-platform-exposedcustomer-data (accessed 27 June 2022).
The Open Data Institute (2018), “Data Access Archipelago: mapping the myriad ways we share data”,
webpage, https://theodi.org/article/data-access-archipelago-mapping-the-myriad-ways-we-share-data/(accessed 19 July 2022).
The Open Data Institute (2022), “Mapping the wide world of data sharing’, webpage, https://theodi.org/
project/the-data-access-map/ (accessed 19 July 2022).
TOMP-API (2021), “TOMP working group”, webpage, https://tomp-wg.org/ (accessed 27 February 2021).
transport.data.gouv.fr (2020), Gtfs2NetexFr, un outil open source intégré au Point d’Accès National !,transport.data.gouv.fr, blog, https://blog.transport.data.gouv.fr/billets/gtfs2netexfr-un-outil-opensource-int%C3%A9gr%C3%A9-au-point-dacc%C3%A8s-national/ (accessed 18 July 2022).
Tucker, C. (2019), “Digital Data, Platforms and the Usual [Antitrust] Suspects: Network Effects, Switching
Costs, Essential Facility”, Review of Industrial Organization, Vol. 54/4, pp. 683-694, https://doi.org/10.
1007/s11151-019-09693-7 (accessed 16 October 2022).
UITP (2020a), Demystifying Ticketing and Payment in Public Transport, Brussels,
https://cms.uitp.org/wp/wp-content/uploads/2021/03/Report-Ticketing_NOV2020_update.pdf(accessed 16 June 2022).
UITP (2020b), Sharing of Data in Public Transport: Value, Governance and Sustainability, Brussels,
www.uitp.org/publications/sharing-of-data-in-public-transport-value-governance-and-sustainability/(accessed 16 October 2022).
UITP (2020c), Sharing of Data in Public Transport: Value, Governance, and Sustainability – Executive
Sumary, Brussels, https://indd.adobe.com/view/906430f6-703e-4f09-847f-2691fbeeff67 (accessed 27
July 2022).
UK Department for Transport (2022), “Bus Open Data Service”, webpage, www.bus-data.dft.gov.uk/(accessed 10 October 2022).
UK House of Lords (2019), Regulating in a digital world, London, https://publications.parliament.uk/
pa/ld201719/ldselect/ldcomuni/299/299.pdf (accessed 19 August 2022).
Valdani Vicari & Associati (2019), Study on market access and competition issues related to MaaS, Milan,
https://maas-alliance.eu/wp-content/uploads/2019/07/Market-access-and-competition-issues-relatedto-MaaS_final_040719.pdf (accessed 16 October 2022).
Van Arsdale, S. and Venzke, C. (2015), “Predatory Innovation in Software Markets’, Harvard Journal of
Law & Technology, Vol. 29/1, http://jolt.law.harvard.edu/articles/pdf/v29/29HarvJLTech243.pdf(accessed 8 September 2022).

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

87

REFERENCES

Van den Berg, V.A.C., Meurs, H. and Verhoef, E.T. (2022), “Business models for Mobility as an Service(MaaS)”, Transportation Research Part B: Methodological, Vol. 157, pp. 203-229, https://doi.org/10.
1016/J.TRB.2022.02.004 (accessed 7 October 2022).
Van der Waal, S. et al. (2020), Digital European Public Spaces, Waag – Technology and Society,https://culturalfoundation.eu/wp-content/uploads/2021/05/Waag-Report-on-European-Digital-PublicSpaces.pdf (accessed 16 October 2022).
Van Dijck, J., Poell, T. and de Waal, M. (2018), The Platform Society, Oxford University Press, New York.
Waag (2021), “Governance of Digital Public Spaces”, Public Stack, Waag – Technology and Society,webpage, https://publicstack.net/digital-public-spaces/ (accessed 16 October 2022).
Welsh Government (2021), Appendix 2: Agreement relating to Bus Emergency Scheme 2 in respect of theareas of the following [insert all Local authorities in the region], Cardiff, www.democracy.caerphilly.gov.
uk/documents/s500003705/Appendix%202.pdf (accessed 16 October 2022).
Wiener Linien (2021), Data Protection Regulations for the Use of the Digital Services of and Online
Purchases from Wiener Linien, Vienna www.wienerlinien.at/media/files/2018/datenschutzbestimmungen_en_239828.pdf (accessed 18 December 2022).
Whim (2021), “Privacy Policy - Whim Helsinki”, webpage, https://whimapp.com/helsinki/en/privacypolicy/ (accessed 31 August 2022).

88

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

ANNEX A. LIST OF WORKSHOP PARTICIPANTS

Annex A. List of workshop participants
Nathan ASHLEY, Strategic Policy Manager - Equity & Safety, Voi, Sweden
Pauline AYMONIER, Head of Public Policy - Smart & Sustainable City, Tier Mobility, Germany
Laura BABÍO, Project Manager, Polis Network, Belgium
Bon BAKERMANS, Advisor Innovation in Mobility, Ministry of Infrastructure and Water Management,
Netherlands
Joice BAUMANN, MaaS Global, Brazil
Ferdinand BURGERSDIJK, Strategic Advisor, Benelux Union, Netherlands
Jean-Baptiste BURTSCHER, Group External Affairs & Sustainable Development Manager, Valeo, France
Mike CONROY, Advocacy and Representations Manager, Total Energies, France
Ghislain DELABIE, MaaS project Director, FabMob, France
Dominique EICHNER, Director, Siemens, Germany
Ronnie GINAT, International Cooperation, Trucknet, Israel
Arturo GONZÁLEZ MAC DOWELL, Chair, European Retail Payment Board, Belgium
Tobias GROSCHE, Professor, Worms University of Applied Sciences, Germany
Suzanne HOADLEY, Senior Manager – Coordinator, POLIS, Belgium
Paulo HUMANES, Director of Mobility, Automotive and Cities, CEiiA, Portugal
Fabian JOOS, Head of digital solutions and innovations, Siemens, Germany
Takayuki KUSAJIMA, Project General manager, Toyota, Japan
Frederic LAITHIER, Group Product Manager MaaS, Flowbird, France
William LILLEY, Senior Lab Scientist, Aramco, Saudi ArabiaBenoît MARICHAL, Data Strategist, RATP, France
Ruud MOLLEMA, Project Manager MaaS, Ministry of Infrastructure and Water Management, Netherlands
Edouard NAYE, MaaS and New Mobility Services Lead, Systra, France
Jasmin RIMMELE, Transport Partnerships & Policy, Voi, Sweden
Michael SCHNUERLE, Director of Open Source Operations, Open Mobility Foundation, United States
Janine STUCHL, VP Global Marketing, PTV Group, Germany
Tu-Tho THAI, Director Partnerships & Events, MobilityData, Canada

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

89

ANNEX A. LIST OF WORKSHOP PARTICIPANTS

Alexis TRONCHET, Business Strategy Manager Cards & Mobility, Total Energies, France
Edwin VAN DEN BELT, Software architect, Dat.mobility, Netherlands
David VAZQUEZ, Mobility Data Governance and Value Creation, Alstom, France
Mélanie VEISSIER, Standardisation project manager, Ministry of the Ecological Transition, France
Mathieu VOISIN, Technical Director / Department of Development, RATP, France

90

MIX AND MAAS: DATA ARCHITECTURE FOR MOBILITY AS A SERVICE © OECD/ITF 2023

Mix and MaaS
Data Architecture for
Mobility as a Service

International Transport Forum
2 rue André Pascal
F-75775 Paris Cedex 16+33 (0)1 73 31 25 00
contact@itf-oecd.org
www.itf-oecd.org

Published: 04/2023 | Photo credit: Jake Blucker/Unsplash and Maxim Berg\Unsplash

This report develops a framework for data sharing between transport
operators that enables them to better integrate transport services andmove towards the creation of Mobility as a Service (MaaS) platforms.
The report also identifies the risks that come along with data sharing
and how they can be minimised. It complements the ITF Corporate
Partnership Board project “Reporting Mobility Data: Good GovernancePrinciples and Practices”, which focuses on the issues publicauthorities must address when establishing data reporting policies bymobility operators to public authorities.