SIST-TP CEN/TR 17949:2023
(Main)Public transport - Distribution APIs for MaaS
Public transport - Distribution APIs for MaaS
Existing public and private distribution API specifications will be identified, where practicable, and summarised in a number of ways, including: ownership of specification, scope of API functionality, basis of data model and data categorisation used, management of reference data, commercial access rules to the specification, governance of the specification, existing examples of use for MaaS booking, coherence with existing CEN standards, potential for becoming a new CEN standard.
Öffentlicher Verkehr - Verteilte Programmierschnittstellen (APIs) für Mobility as a Service (MaaS)
Transport public - API de distribution pour les plateformes de mobilités
Javni prevoz - Distribucijski aplikacijski programski vmesniki (API) za mobilnost kot storitev (MaaS)
Kjer je to izvedljivo, bodo določene in na več načinov povzete specifikacije obstoječih javnih in zasebnih distribucijskih aplikacijskih programskih vmesnikov (API), vključno z lastništvom specifikacije, obsegom funkcionalnosti aplikacijskih programskih vmesnikov, osnovo podatkovnega modela in kategorizacije podatkov, ki se uporabljata, upravljanjem referenčnih podatkov, komercialnimi pravili za dostop do specifikacije, upravljanjem specifikacije, obstoječimi primeri uporabe rezervacije mobilnosti kot storitve (MaaS), skladnostjo z obstoječimi standardi CEN ter potencialom za oblikovanje novega standarda CEN.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
SIST-TP CEN/TR 17949:2023
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
SIST-TP CEN/TR 17949:2023 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-TP CEN/TR 17949:2023
---------------------- Page: 2 ----------------------
SIST-TP CEN/TR 17949:2023
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.
---------------------- Page: 3 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
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
2
---------------------- Page: 4 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
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.
3
---------------------- Page: 5 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
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.
4
---------------------- Page: 6 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
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
1
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
1
Definitions based upon MaaS Alliance White Paper and on Transmodel/NeTEx.
5
---------------------- Page: 7 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
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
6
---------------------- Page: 8 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
1.3 Transport distribution architecture
The distribution architecture is shown in Figure 1.
Keys
Defined interfaces
Figure 1 — Distribution architecture
This architecture has been drawn from a number of reference sources covering urban transport, rail
transport, financial services, transport regulation and transport standards.
There are the two main entities quoted conventionally in MaaS: the MaaS provider and the transport
service provider.
In addition, and particularly relevant in the EU, is the National Access Point to the transport data portal.
In some cases, the transport service provider delegates the distribution of their services to an
intermediary or aggregator, including GDSs.
Other IFMS roles include media and identify providers, ticket controllers, security managers, registries
and IFMS scheme managers.
MaaS providers receive payment related to their customer’s travel both from banks, but also from
transport authorities and other entities holding travel purses and travel subscriptions.
The service booking interconnection uses the distribution APIs covered by this Technical Report.
The service data interconnection uses a range of APIs and message formats. In the EU these are
predominantly harmonized standards.
7
---------------------- Page: 9 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
1.4 Use of distribution APIs
Most distribution use cases can be categorized in three main ones:
— purchase of a trip offer (access right) for a set price that is valid for a defined set of services
— reservation and a commitment to pay once the price is known after travel
— implicit purchase of a trip offer that uses payment cards for pay-as-you-go (PAYG).
In the first case, a substantial set of distribution API functionalities is needed, including pricing for the
journey (the whole set is summarized in the survey questions in section 4.3). The customer explicitly
enters into a contract with the MaaS Provider.
In the second case, the price of travel is not known in advance and so distribution API functionality is
needed that can explicitly commit a customer to pay the MaaS Provider for their journey after travel and
provide a later justification for the charge.
In the third PAYG case, there is no registration or ticketing or pricing in advance and so there is no MaaS
Provider in its original conception. The obligation to pay is implicit in entering the system, so the only
distribution API functions needed are related to journey planning, plus the ability to demonstrate what
journeys were made and how the charges were calculated.
To be noted that in all three cases, there is no requirement that the passenger and the customer are the
same person.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1
aggregator
entity that provides technical and other services to several transport service providers to enable retailers
and other parties to book tickets on services provided by each service provider
3.2
canonical mapping
use of a data model which is a superset of all the others (“canonical”), and creation of a “translator” layer
to/from which all existing modules exchange data with other modules
3.3
distribution APIs
APIs that provide 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
8
---------------------- Page: 10 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
3.4
harmonised standard
European standard developed by a recognised European Standards Organization whose use is referenced
in European legislation
3.5
Identity Provider
provider of a trustworthy scheme for creating, managing and providing customer and media ID and
related attributes
3.6
Interoperable Fare Management System
IFMS
all technical, commercial, security, and legal elements which enable interoperable fare management
3.7
IFMS scheme manager
legal person responsible for the operation of an IFMS
3.8
MaaS Provider
provider of an application that provides access to mobility with a single payment channel
3.9
Media Provider
provider of the media for use with one or more ticketing applications used in an IFMS
3.10
Mobility as a Service
MaaS
integration of various forms of transport services into a single mobility service accessible on demand
3.11
NeTEx profile
subset of NeTEx elements that must be present in an API or message, as well as the code sets to be used
to identify them
Note 1 to entry: A machine-readable form of this profile may be created using the NeTEx TYPE OF FRAME element,
specifying which elements must be present; this can be used to enable automatic validators for local profiles
3.12
security manager
responsible for establishing and coordinating the security policy of an IFMS
3.13
ticket control
verification by manual or automatic means of the right to travel together with the control of access to
transport services
3.14
transport service provider
all the means to enable the passenger to complete their journey as defined in their transport contract
9
---------------------- Page: 11 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
4 The survey
4.1 Development of the survey
The project team was recruited initially from members of CEN/TC 278/WG 3. Other people joined during
the project, either because they had an API that could be included in the survey, or because they had a
professional interest in the subject. The project team included representatives from the European
Commission and the European Union Agency of Railways. In the end the team included over 60 people.
A series of meetings took place in middle and late 2021 in which the survey questions were agreed and
the draft report reviewed.
During execution of the work, related activities were taking place. An important example is the work to
compare the UIC Open Sales and Distribution Model (OSDM) against the harmonized standards
Transmodel and NeTEx. This work is particularly relevant to the topic of distribution APIs as OSDM is
proposed as an addition to the set of regulatory standards in the 2022 version of the TAP-TSI. The work
was still underway when this Technical Report was completed.
4.2 Identification of API Sets
Identification of API sets came largely from suggestions by project team members. News of the survey
spread and this led to additional APIs being added. Large number of APIs were provided by French project
team members, based on a similar national exercise.
4.3 Survey scope and questions
The survey questions were developed by the project team. They were designed to avoid giving
respondents an excessive workload, while still covering a wide range of characteristics of API sets.
— What is the name of the API that is covered in this survey?
— Who owns the API Intellectual Property Rights (IPR)?
— Is the owner legally constituted?
— Is the management of the APIs delegated to another organization?
— Are the organization(s) for profit or not?
— Are there existing examples where the API is used in MaaS or similar apps or booking sites?
— Must users sign a licence or is there an implicit licence?
— Must an NDA be signed?
— Are fees payable?
— Where is the API documentation available?
— Is there a dedicated governance organization?
— Are there fees to participate?
— Must users/can users join the governance?
— What is the change management process?
10
---------------------- Page: 12 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
— Are new versions of the API always backward compatible?
— How does the cost of changes fall on the users?
— Can some users insist on changes?
— What functions are supported by the API?
— Management of customer accounts including for example customer preferences, data and
entitlements, the products used and journeys made
— Passenger trip itinerary for a single transport operator or multiple transport operators
— Personalisation of itineraries based on individual travel preferences, data and entitlements
— Personalisation of itineraries based on special needs during booking and travel for example
relating to reduced mental or physical ability
— Service availability with fixed or yield-managed prices
— Itinerary tariff rules including rules on refund and change
— Reservation of vehicles, seats, sleepers, etc
— Payment, including through a merchant acquirer, directly from a bank, or from a funds account
held by a transport authority or operator
— Management of earnings apportionment between multiple transport operators
— Settlement and clearing of earnings with one or more transport operators
— Providing passengers with tickets, for example by NFC or barcode access token
— Management of events during the journey, for example schedule disruption, reporting of journey
and ticket control data
— Calculation of journey price for usage-based tariffs such as pay-as-you-go
— Cancellation and/or change to reservations
— Provision of feedback or complaints
— Provision of management information for MaaS Operators and/or statistics for government
— Other - please describe
— What payment methods are supported?
— merchant acquirer
— directly from bank
— funds account held by a transport authority
— funds account held by an operator
11
---------------------- Page: 13 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
— other
— Which of the following transport services are supported by your API?
— urban bus
— rural bus
— tram
— metro
— light rail
— conventional rail
— high speed rail
— intercity coach
— taxi
— car rental
— car ride-sharing/on-demand
— bike rental
— scooter rental
— parking
— EV charging point
— ferry
— cable car
— other - please describe
— What is the communications method for implementing the APIs, eg?
— REST JSON or xml, possibly with a Swagger / OpenAPI description
— xml API, possibly with a SOAP description
— Protocol buffer
— Other - please describe
— What is the encoding method?
— XML
— JSON
12
---------------------- Page: 14 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
— GraphQL
— Other - please describe
— How does the interaction work?
— asynchronous (call-back)
— synchronous (atomistic)
— both asynchronous and synchronous
— simple file exchange
— What architecture is supported?
— retailer – transport service provider
— retailer – aggregator – transport service provider
— both
— What method provides access control for client's apps interfacing with the API?
— static authentication (username/password)
— certificates
— static token-based authentication
— dynamic token-based authentication (eg OAuth 2.0)
— other - please describe
— Type of access?
— request/response
— subscription
— data flow
— other - please describe
— Is there a published data model?
— What is its relation to Transmodel or other regulatory standards?
— Is there an organization that manages the reference data?
— Are there fees to provide or use reference data?
— Are there rules controlling reference data?
— Is the data checked by the organization?
13
---------------------- Page: 15 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
— How do developers get trained to use the APIs?
— Is there a support group?
5 The survey results
5.1 Survey responses
Survey invitation sent to 65 organisations and valid responses were received from 35.
5.2 Analysis
It is important to reiterate that the responses are self-electing and not representative. However, in the
view of the project team, it would be fair to say that the important ones from a European standardization
perspective are all included.
85 % API sets are run by an organization that is legally constituted. Others are self-organizing, for
example relating to open-source APIs.
36 % are run for profit. There does appear to be systematic differences between those that are run for
profit (eg booking software as a service) and those not (eg open-source specification) in terms of change
management, paying for changes and governance. This is what might be expected where the API forms
part of a contracted service with key performance indicators.
A few of the APIs are used in a single country though many suggest they are used in Europe and North
America. A limited number of APIs are from organizations based outside Europe or North America. APIs
may be restricted to a single region or country because of questions of language. It may also be that
different regions have different regulatory settings (such as GDPR in Europe) and this is a real or
perceived constraint.
Figure 2 shows the API functions as shorthand titles.
Key
A Customer accounts H Apportionment
B Itinerary I Settlement
C Personalised itinerary J Ticketing
D PRM itinerary K Journey pricing
E Price enquiry L Complaints
F Reservation M Stats
G Payment
Figure 2 — API functions
14
---------------------- Page: 16 ----------------------
SIST-TP CEN/TR 17949:2023
CEN/TR 17949:2023 (E)
Figure 3 shows the modes supported.
Key
A Bus G Ride sharing
B Metro H Bike rental
C Rail I Parking
D Coach J EV charging
E Taxi K Ferry
F Car rental
Figure 3 — Modes supported
What is clear is that many API sets only support a single mode so are specialized to it, whereas others
cover a much wider multi-modal range. It was not possible from the responses to distinguish between
APIs that can provide access to services on multiple modes using combined tariffs and a single contract,
compared to those that can provide multi-model services but using one contract per segment.
5.3 Compatibility with Transmodel and GTFS
39 % mention some relationship to Transmodel and 15 % mention some relationship to GTFS. Some data
models are proprietary.
For CEN the compatibility with Transmodel is an important feature. The survey contained a question on
this subject. Within those who reported a relationship with Transmodel, there were different levels of
quality to the relationship:
— Designed in the Transmodel environment
— Conform with canonical mapping
— Supposedly conform with mapping
— Unclear/further investigation needed
— No answer or negative answer
The headline replies on that question need to be read together with the commentary.
15
---------------------- Page: 17 ----------------------
SIST-TP CEN/TR 17949:2
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.