CEN/TR 17949:2023

SLOVENSKI STANDARD
01-julij-2023
Javni prevoz - Distribucijski aplikacijski programski vmesniki (API) za mobilnost
kot storitev (MaaS)
Public transport - Distribution APIs for MaaS
Öffentlicher Verkehr - Verteilte Programmierschnittstellen (APIs) für Mobility as a Service
(MaaS)
Transport public - API de distribution pour les plateformes de mobilités
Ta slovenski standard je istoveten z: CEN/TR 17949:2023
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

CEN/TR 17949
TECHNICAL REPORT
RAPPORT TECHNIQUE
April 2023
TECHNISCHER REPORT
ICS 35.240.60
English Version
Public transport - Distribution APIs for MaaS
Transport public - API de distribution pour les Öffentlicher Verkehr - Verteilte
plateformes de mobilités Programmierschnittstellen (APIs) für Mobility as a
Service (MaaS)
This Technical Report was approved by CEN on 24 March 2023. It has been drawn up by the Technical Committee CEN/TC 278.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17949:2023 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
1.1 MaaS distribution API survey . 5
1.2 Transport distribution functions . 5
1.3 Transport distribution architecture . 7
1.4 Use of distribution APIs . 8
2 Normative references . 8
3 Terms and definitions . 8
4 The survey . 10
4.1 Development of the survey . 10
4.2 Identification of API Sets . 10
4.3 Survey scope and questions . 10
5 The survey results . 14
5.1 Survey responses . 14
5.2 Analysis . 14
5.3 Compatibility with Transmodel and GTFS . 15
5.4 Conclusions . 16
6 Implications for standardization and regulation . 16
6.1 European Standardization . 16
6.2 European Regulation . 17
7 Survey responses . 17
Annex A (informative) Survey responses . 18
Bibliography . 30

European foreword
This document (CEN/TR 17949:2023) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
Mobility-as-a-Service (MaaS) is a concept that was created in the Nordics and in Austria several years
ago. The original idea was quite straightforward: allow any traveller to go seamlessly from A to B using
only one single mobile application and based on his/her personal preferences. As technology has evolved
and as travellers were experimenting with new types of services (eg, free-floating shared scooters), it
seemed that the term MaaS was used to cover a very wide range of realities. To make this document
clearer, here MaaS will be considered in its original definition and parameters: one single mobile
application that allows any traveller to search, plan, book, pay, and travel (with support when needed)
from A to B using at least one modality with the operations side invisible to the eye; the above-mentioned
actions not being necessarily logically linear nor unique.
MaaS operations, based on MaaS apps, conventionally start with journey planning systems that use
timetables (eg CEN OJP). Sometimes fares are used as well. There are well-established standards for the
exchange of this data, such as GTFS and Transmodel/NeTEx for Public Transit. In the EU, there are legal
obligations on many transport operators to make such data available using the Transmodel/NeTEx
standards. These standards are managed by a CEN (the European Standards body) working group (TC
CEN/278/WG 3 Public Transport).
The next stage in full MaaS development is the ability to check availability, to make bookings, to take
payment, to get tickets for travel, etc, for both conventional public transport modes and newer forms of
mobility services. A key aspect is the separation of task and responsibilities of the MaaS Provider in
arranging the trip and transport service operators to execute the trip. MaaS Providers will normally use
APIs to access transport operator booking systems and carry out these functions. In this work, these
transactional APIs are referred to as distribution APIs. The term is taken from the Global Distribution
Systems that distribute the sale of multi-modal transport products from a wide range of transport
operators directly to the customer. APIs for air and rail have existed for years, but have more recently
been extended for shared mobility and urban modes such as metro and bus.
Standardization of these distribution APIs is helpful to be able to integrate different types of transport
operators into one single mobile application. Therefore, in Europe, as part of the Multimodal Digital
Mobile Services (MDMS) project, the European Commission is considering whether to choose one or
more sets of distribution APIs to add to its regulatory regime. An impact assessment will start Q1 of 2022
with regulatory proposals expected in Q4 2022. If there are to be more harmonized standards, it is likely
that these will be managed by the same CEN working group that manages Transmodel/NeTEx. In order
to provide an up-to-date view on what already exists worldwide in terms of distribution APIs, a CEN
project team has undertaken a survey. From the responses received, it has prepared this state-of-the-art
technical report that lists API sets and provides some basic information about each of them.
Policy in relation to distribution APIs for MaaS is clearly topical and during the work of the project several
other European and national initiatives on the same topic came to light.
1 Scope
1.1 MaaS distribution API survey
This document describes the execution and results of a survey into distribution APIs for MaaS. API
owners have been encouraged to participate if they offer APIs that support the functions or if they were
expecting to do so within a reasonable timeframe. Although there seems to be good coverage of European
examples, survey responses cannot be treated as representative of the complete worldwide set of APIs,
but provide strong indications of the totality of what exists, and the issues raised in terms of
standardization and regulation.
The survey has been carried out without any pre-determined agenda in terms of API policy or strategy.
It has not been assumed a priori that a single API set could or should meet all multi-modal business needs.
Comments are provided in respect of the impacts in standardization, but it was not considered
appropriate to make any comments on regulatory implications, as this is not the area of competence for
the CEN working group.
1.2 Transport distribution functions
Distribution APIs may be related to one or to a combination of the functionality/ies (processes)
described in Table 1.
Table 1 — Functionalities
Functionalities based on the MaaS Functionalities described in the survey
Alliance White paper and
Transmodel/NeTEx
User registration: registration of detailed Management of customer accounts including
information related to the travelling entity for example customer preferences, data and
(user, group of passengers, etc) such as entitlements, the products used, and journeys
payment cards, specific needs and made
preferences, data consent, etc.
Trip planning: provision of particular trip Passenger trip itinerary for a single transport
options taking into account parameters operator or multiple transport operators
provided by the user (eg, location, time,
Personalisation of itineraries based on
budget and other preferences)
individual travel needs and preferences, data
and entitlements
Personalisation of itineraries based on
special needs during booking and travel
for example relating to reduced mental or
physical ability
Purchasing: commitment to pay a chosen Implicit
offer
After sales: refund/exchange of a booked Cancellation and/or change to reservations
offer, complaints, etc
Provision of feedback or complaints
Booking: reservation of the chosen trip Reservation of vehicles, seats, sleepers, etc
options
Service availability with fixed or yield-
managed prices
Fulfilment: provision of proofs of the sale Providing passengers with tickets, for
and/or booking to the customer example by NFC or barcode access token

Definitions based upon MaaS Alliance White Paper and on Transmodel/NeTEx.
Functionalities based on the MaaS Functionalities described in the survey
Alliance White paper and
Transmodel/NeTEx
Pricing: calculation of the price of the trip Calculation of journey price for usage-based
option according to the pricing rules, such as tariffs such as pay-as-you-go
pay-as-you-go
Payment: payment of the actual price Payment, particularly from a funds account
corresponding to the chosen trip option and held by a transport authority or other entity
to the related pricing rules
Support: providing help to user during Management of unforeseen events during the
travelling by different means journey, for example schedule disruption,
reporting of journey and ticket control data
Provision of information on sales conditions:
information on sales rules (sales network,
distribution channels, the purchase window
etc) and on after sales conditions (eg is the
access right refundable, etc)
Provision of information on booking
conditions: information on how to book,
when, what parts of the trip option are
submitted to reservation, etc
Provision of information on pricing rules: Itinerary tariff rules including rules on refund
information on price calculation rules, and change
discounts, capping rules, etc
Provision of information on payment
methods: information on how/when the
payment takes place (pre-payment, post-
payment, pay-as-you go, etc)
Consumption control: Access right validation
and control
Consumption Control: Fraud management
and revenue protection measures
Consumption Control: Collection and Provision of management information for
aggregation of consumption data MaaS Operators and/or statistics for
government
Settlement: management of revenue sharing Management of earnings apportionment
and clearing house activities between multiple transport operators
Settlement and clearing of earnings with one
or more transport operators
...