ISO/TR 21724-1:2020

TECHNICAL ISO/TR
REPORT 21724-1
First edition
2020-07
Intelligent transport systems —
Common Transport Service Account
Systems —
Part 1:
Framework and use cases
Partie 1: Cadre et cas d'utilisation
Reference number
©
ISO 2020
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Common Transport Services Account overview . 3
5.1 General . 3
5.2 Common Transport Services Account definition . 3
5.3 Common Transport Service Account concept . 3
5.4 CTSA requirements . 5
5.5 Transport service requirements . 5
6 CTSA system framework model . 6
6.1 General . 6
6.2 Description of actors/entities . 7
6.3 Framework data flows . 9
6.4 Comparison to EFC and IFMS .12
7 Processes and use cases .16
7.1 General .16
7.2 Use case process and methodology.16
7.3 Transport service user use case process descriptions .17
7.3.1 General.17
7.3.2 Transport service user registration . .17
7.3.3 SecureID registration including sharing agreement .18
7.3.4 Multimodal journey services .19
7.3.5 Point of sale .20
7.3.6 Fee/fare calculation and service rights validation for service operator . .21
7.3.7 Service rights validation for interagency acceptance .22
7.4 Authentication of secureIDs .22
7.5 Open payment use case process descriptions.23
7.5.1 General.23
7.5.2 Open payment transaction process .23
7.5.3 Valid and hot list upload process .24
7.6 Multimodal use case process descriptions .24
7.6.1 Transport service usage rule sharing processes .24
7.6.2 Transport service usage rule sharing processes .24
7.6.3 Pricing rule sharing process .25
7.6.4 Commercial rule sharing process .26
7.6.5 Transport service user account information sharing process.27
8 Next steps .27
Annex A Informative Payment categories .29
Bibliography .32
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 21724 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
iv © ISO 2020 – All rights reserved

Introduction
Many transportation services (e.g. public transport, tolled roads, parking, city bike rental etc.) require
payment for use. This has previously caused each service provider (e.g. public transport authorities, toll
authorities, public and private parking providers, etc.) to develop independent, stand-alone payment
systems to enable users to pay for access to their service. Consequently, a traveller who traverses
multiple transport modes had to purchase services at more than one point of sales location. If the
payment systems are integrated, then the transport service user may possess more than one payment/
ticketing media, application, and/or account. However, in public transport there have for many years
been products that enable a traveller to benefit from a seamless journey from A to B using several
transport means, modes and operators. These products have been available through cooperation
between operators and regional and national tariff schemes.
The transportation industry has seen an evolution in the collection of fares and fees throughout its
history. The main drivers of that evolution have been the pursuit of increases in customer convenience
and system efficiencies. Automated Fare Collection has progressed from use of magnetic technology to
contactless smart cards, and recently to open financial payments and mobile payment applications.
Automated Toll Collection began with the use of simple read-only tags and is now looking to new
approaches and technologies for future payment system advancements. Examples are open road tolling,
vehicle miles travelled methods, and technologies such as Dedicated Short Range Communications
(DSRC), Global Navigation Satellite System (GNSS), and Cellular Networks (e.g., GSM). Agencies have
used these high-technology systems not only to enable automated payment and speed throughput, but
to capture data, improve system reliability, and perhaps most important, to improve customer service.
Historically, transportation payment systems have covered only one service provider. Therefore,
public transport ticketing/payment systems have not typically been technically integrated with
charging/payment systems for tolls or parking and vice-versa. The reasons for this isolated nature
are twofold. The first is that the individual service providers had little interest, from a business case
standpoint, in integrating their purpose-built ticketing-, charging- and payment systems. The second
is that technically this is a difficult and costly exercise, owing to the fact that the systems are typically
proprietary and were designed to enable payment for one transportation service. However, in public
transport, more and more electronic ticketing systems are supporting communication in conformance
with ISO/IEC 14443 or ISO/IEC 18092. This implies physical and technical interoperability, but also
that the ticketing applications have to be interoperable as well, as there has to be a contractual
interoperability.
Some integration has occurred, for example between commuter or urban rail and parking. A traveller
can often pay for both parking and their train ride with a common medium. But these examples usually
occur only when there is one transport service provider for both the parking and public transport.
Other examples exist for purpose-built integrations of payment systems across two or more
transportation modes. In some Asian countries like Japan and Korea there are several implementations
of integrated payment systems for public transport and tolling. Examples include the use of a toll
transponder that allows the insertion of a public transport card. The integrated payment systems are
mostly based on a common payment media, i.e., smartcard with stored electronic value on the card.
In the past 5 to 10 years, the public transport industry in particular has embraced the development of
Common Transport Service Account systems. In this approach, transportation products are stored in
a central account rather than on the payment media. This architecture allows the system front end to
be very flexible to enable customers to use contactless credit and debit cards and contactless mobile
payment and ticketing applications alongside transport smart cards.
The subject of this document is to study the convergence of toll fee collection and payment and public
transport fare collection and payment through the integration of the systems’ accounts rather than
their fee/fare payment media. This concept is flexible and can also include payment systems for
other transport services, such as parking, electric charging stations, rideshare, bikeshare, and other
disruptive transportation modes. Using an account-based backoffice architecture (prevalent in the toll
industry), is becoming increasingly common in public transport and other transport service payment
systems in the United States and Europe.
The technical approach is to link accounts used in multiple transportation modes to create a common
transport service user account. For customers, this creates a seamless, end-to-end experience where
they can easily access and pay for all transport modes for which they opt-in: public transport fares,
toll fees, rideshare, etc. For operators, this common or linked account allows for additional customer
benefits such as incentives, discounts or loyalty points strategies, and can add valuable customer usage
data to inform their planning and operations, enhance mobility and reduce congestion in regions.
This document examines the concept, functional requirements, and benefits of converging payment
systems for tolling, public transport and other transport services through a central account linkage.
Readers interested in how this can be achieved by use of a common media are advised to access
ISO/TR 19639.
vi © ISO 2020 – All rights reserved

TECHNICAL REPORT ISO/TR 21724-1:2020(E)
Intelligent transport systems — Common Transport
Service Account Systems —
Part 1:
Framework and use cases
1 Scope
This document describes the characteristics of a Common Transport Service Account System (CTSA).
It presents the common transport service account framework and associated use cases. The objective
of the CTSA role model is to cover relevant transport services, the payment methods, the account
types where the user of the service is charged for the service and that requires a more overall role and
responsibilities model. The model also defines external stakeholders that impact and border the model,
that is, the general financial (banking) system. The framework assumes an account-based system
where charges for services are calculated and charged in the account system. The main idea behind
the CTSA framework is to provide a transport service user with the benefit of seamless acquisition
of access rights to multiple transport services by multiple service / operator managers through a
common transport account. This framework assumes a technology-agnostic front end with respect to
the payment media and reading equipment. The focus of this framework is the back-office / account
management system as a vehicle to integrate multiple transport services and managers.
A new set of terms are introduced in this document to distinguish the convergence of a common approach
for payment for transportation services from more traditional models using “smart cards” or electronic
tickets. The model describes a move towards common or linked mobility accounts for all traveller
payment needs, whether for parking, tolls, public transport and other disruptive mode options (e.g.,
bikeshare, carshare, microtransit, micromobility), inclusive of commercial payment and benefit models.
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 terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
actor
user playing a coherent set of roles when interacting with the system within a particular use case (3.6)
Note 1 to entry: A user can, for instance, be a human, an Organisation or another (sub)system.
3.2
secureID
evidence that a transport service user (customer) is entitled, at the Point of Entry (POE) to the transport
service, to benefit from a transport service provided by a transport service manager
Note 1 to entry: A secureID may consist of a set of data elements defined in a standardized format stored on an
electronic media, e.g. a smartphone, used for a secure storage of the information and a secure communication of
the information to the media accepting devices installed either at the POE or at the Point of Sales (POS). The set of
data elements and their content (values) can vary depending on the type of payment method, type of media and
electronic identification application stored on the media and the type of transport service provided.
Note 2 to entry: A secureID may consist of a simple vehicle ID as given by the vehicle number plate and read by
the roadside equipment (RSE) by means of Automatic Number Plate Recognition (ANPR).
Note 3 to entry: A secureID may also consist of a biometric identification, e.g. finger-print or facial recognition of
the transport service user.
3.3
open interface
public standard (or generally accepted specification) for connecting hardware to hardware and
software to software
[SOURCE: https:// encyclopedia2 .thefreedictionary .com/ open+ interface, 22 March 2016]
3.4
open payment
use of open industry interface standards and specifications for the electronic remuneration and
provision of transport services
Note 1 to entry: See Reference [7] for more information on open payment architecture.
3.5
payment method
timing and location of remuneration for services including whether the payment is required prior to, at
the time of, or post access to transport or related services
3.6
use case
description of typical interactions between the actors (3.1) and the (sub)system itself, capturing the
functional requirements of the (sub)system by defining a sequence of actions performed by one or more
actors and the system
4 Abbreviated terms
ANPR automatic number plate recognition
EFC electronic fee collection
IFMS integrated fare management system
IFMSA integrated fare management system architecture
PAYG pay as you go
POE point of entry
2 © ISO 2020 – All rights reserved

POS point of sale
RSE roadside equipment
TCRP Transit Cooperative Research Program (a program sponsored by the United States National
Academy of Sciences)
5 Common Transport Services Account overview
5.1 General
This clause presents the Common Transport Services Account System framework and architecture.
This clause includes the definition, requirements, role model and role descriptions, modes, and flows of
the system. These components are described in more detail in the following subclauses. The objective
of the CTSA role model is to cover any transport service where the user of the service is charged for the
service and that requires a more overall role and responsibilities model.
5.2 Common Transport Services Account definition
A CTSA system is characterized by the use of open interfaces for validating payment and a transport
account management system (‘back-office’) for processing and managing secureIDs, transport service
user products and value stores for multiple transport service and operator managers. The back-office
processes ensure privacy, security and portability of secureIDs to support current and expanded
integrated services offered by multiple transport service managers.
In general, a Common Transport Service Account system conducts the majority of the validation and
authentication of user payment and access rights to service in the back-office; the secureIDs and media
used by a traveller is typically used for identification purposes only. The value is not typically contained
on the media, and under normal circumstances (when communications is available), the fee or fare
calculations are not calculated in the media reader.
5.3 Common Transport Service Account concept
The concept of a CTSA is for a traveller to seamlessly travel from origin to destination while using the
most convenient means of gaining service access rights. As depicted in Figure 1, a traveller may join one
or more transport service or operation managers and also link the most appropriate secureIDs to gain
access to transport services via their account.
Service access rights processing is performed in the account back-office, which enables systems
to be loosely integrated where they do not need to share the same equipment types, technologies,
applications, or customer media form factors. The flexibility provides customers with choosing their
preferred service modes, payment and secure identification methods, as well as the ability to migrate
to new technologies as they are deployed. They are able to use the most convenient means to access
services, provided their secureID is based on an open interface, and the operations manager is able to
process the link that their secureID provides to the back-office customer account.
EXAMPLE 1 A toll operator can require that a traveller register a licence plate and establish a stored value
purse to pay for travel on toll lanes; a bikeshare service can require a monthly fee and bank card of record for a
guarantee; a parking vendor can provide discounts for rail travellers, and a commuter rail service can require
tickets or passes for travel. With the CTSA, the traveller has a one-stop location to register all the appropriate
secureIDs, create a single travel purse, store a single card for all transactions, and register for benefits or
discounts that are available for using public or active transport alternatives. The customer can better manage
their travel history. Meanwhile, service managers can better manage transportation alternatives for customers,
offer discounts for changing travel choices, and coordinate network management scenarios to more effectively
meet demand.
Figure 1 — Common Transport Service Account concept
Specifically, the idea behind the CTSA is to provide the transport service user with a framework where
the transport service user benefits from many types of transport services without having several
interfaces with different financial service providers, e.g., banks and credit card companies supporting
the different transport service providers. The transport service user is able to receive one invoice with
all the charging transactions for all the transport services used. Every time the transport service user
benefits from a transport service, the validation of his travel service rights (secureIDs) is collected and
transferred to the manager of the Common Transport Service Account. The CTSA manager settles the
transport service user account based on the transport services consumed and the commercial rules
relevant for the services or combination of services consumed. Hence, the whole concept is based on
a transport related central account and an identification of the transport service user and his/her
secureID. The following more complex example may describe the concept of CTSA:
A transport service user benefits every day from three types of transport services. The first one
relates to the use of a tolled highway to a city. The second transport service is the use of parking
services at a Park&Ride terminal and the third service is the use of a bus line from the Park&Ride
terminal to the city centre. The transport service user uses an on-board equipment (electronic
tag) with a post-paid central account for the electronic fee collection (EFC) on the tolled road, a
smartcard with a pre-paid central account for access to the parking lot and a fare medium with
a pre-paid period pass for riding with the bus. Every month, the transport service user receives
an invoice from each of the three different transport service providers. There are no links or
relationships between the three transport service providers enabling the user to benefit from the
combination of transport services or to have one invoice covering all transport services.
The three transport service providers then agree to join forces, making the usage of transport
services more user-friendly concerning charging and invoicing. They establish a joint venture
association and enable the user to have a CTSA managed by the joint venture association. The CTSA
manager (the joint venture association) receives the proof of usage (validation of secureIDs) from
each of the three transport service providers and settles the user's CTSA once a month, enabling
the user to have specific rates for his/her combined usage of transport services. The user then
receives one invoice each month with the documentation of his/her transport service usage and
one amount to be paid.
4 © ISO 2020 – All rights reserved

It should be noted that the CTSA manager does not act as a financial service provider, e.g., a bank or
credit card company. The CTSA manager is primarily a clearing and forwarding entity that belongs to
the transport domain and that clears and settles the CTSAs linked to each of the transport service users
that have a CTSA contract enabling them to have one common account for all their usage of transport
services. The CTSA manager also settles financial accounts between different stakeholders in the
transport domain involved in the CTSA concept. There are only a few disparate systems in place today
that can support a CTSA. This framework will provide a blueprint for others to migrate to an account-
based system that supporst multiple service and operations managers.
5.4 CTSA requirements
The CTSA system is characterized by the following requirements:
1) A CTSA system enables a transport service user to hold one account from which to pay for service
rights to a variety of linked or unlinked transport services from one or more transport operators
including vehicle, public transport, rail, taxi, electric charging, parking, shared use transport and
other mobility providers.
2) A CTSA system enables a registered transport service user to use their most convenient secureID
to pay on entry/exit or to acquire transport service rights from a variety of transport operators.
Examples of a secureID may include licence plate, government identification cards, private label
media that conform to open interface standard formats, bank cards or virtual bank cards stored in
mobile phones, or payment services such as Apple Pay and PayPal, and emerging technologies.
3) A transport service user’s registered secureID may be used on a transport service when a payment
method or transport product is associated with the secureID.
4) A multimodal journey that may include travel across toll roads, public transport, parking, shared
use mobility aids and systems may be linked across different service and operation managers to
provide travel or other benefits or discounts to the transport service user.
5) A CTSA system enables a transport operator to act as a typical payment merchant with respect to a
transport service user, wherein pay as you go (PAYG) for services model is used.
6) In a CTSA system, a payment is made using open interface standards.
7) A CTSA system allows point of entry and point of sales locations to co-exist at the same location.
8) A CTSA system allows information about transport service user accounts to be shared among other
service providers based on a transport service user agreement (opt-in/opt-out) at any time during
membership/registration to the service.
9) A CTSA system allows an entity/actor to extract data appropriate to revenue sharing and statistical
requirements of transport service user usage, transactions and access to services.
10) The CTSA model should be capable of extending the use to different POE and POS technologies,
including passive and active reader methods.
11) The CTSA model should be structured to accommodate current best practices to prevent internal
and external fraud and to safeguard the revenue collection by the appropriate service providers.
12) The CTSA model should protect transport service user privacy.
NOTE Passive and active reader methods are based on whether a customer actively presents a secureID to a
reader (active method) or a “reader” senses its presence (passive method).
5.5 Transport service requirements
This subclause describes the modes and services for which payment is charged for usage. Within the four
basic transport modes, road, rail, sea, and air, we focus on the road, rail or sea. Due to their structure,
these modes have different requirements that drive the secureID technology, media, transaction type,
and transmission performance. In this model, the traveller service discovery, reservations, sales and
provisioning of secureIDs for access is also included in transport service requirements due to the
choices available to travellers. For that reason, transport service requirements also includes a service
called: Information and Reservation Service Provider. The transport modes and their requirements are
listed in Table 1.
Table 1 — Transport mode requirements
Mode/Service Requirements
Road/Tolled infrastructure Need for display/transmission of secureIDs at a distance from POE
while vehicle is moving.
Need to enforce vehicle secureIDs passively from vehicle or transmitted
from vehicle (e.g., licence plate cameras or via transmission to RSE)
Road/Public transport services Need for fast transaction times.
Need to transact micropayments.
Need to operate in a barrier or barrier-free mode.
Rail/Subway and metro services Need for fast transaction times.
Need to transact micropayments.
Need to operate in a barrier or barrier-free mode.
Road/Parking, Shared-use mobile Need for intermodal transfers and sharing secureID/access/benefit
services (bicycle and car-sharing information (e.g., car park, bike sharing, bike storage, car share).
services)
Need to operate using different enforcement provisions such as lock,
gate, or inspection.
Road/Long distance bus Although limited real time need, Need for fast transaction times.
Road/Car sharing Need for estimate of number of travellers/users per “trip”.
Road/Charging station electric (Optional) Need for payment inspection and enforcement.
vehicles
Rail/Train services
Sea/Ferry
Information and Reservation Service Although limited real time need, need for fast transaction times.
Provider
Need for interfaces to product, service fee, fare, and service transfer
rules.
Need for reciprocity and discount/benefit rules.
6 CTSA system framework model
6.1 General
The CTSA system framework model overlaps with the IFMS framework (ISO 24014-1) and EFC models
(ISO 17573 series), although the secureID Registrar role is replaced with a financial service provider.
Details of the relationship between the CTSA and IFMS and CTSA and EFC are described in 6.3.
The framework model is shown in Figure 2. The framework is composed of six main actors or entities,
as described in Table 2. The enumerated data flows (e.g., 1. Display/Actuate), show the major data
exchanges between actors. These flows are described in 6.2.
6 © ISO 2020 – All rights reserved

Figure 2 — Common Transport Services Account framework model
6.2 Description of actors/entities
The critical roles in a CTSA system are listed in Table 2. The model is compatible with the IFMS and EFC
to ensure a seamless integration with legacy tolling and fare collection systems.
Table 2 — Common Transport Services Account framework role descriptions
Actors Description
Transport service user The TSU (user) benefits from a transport service and pays for the service either be-
(TSU) fore, during or after the transport service has been used. A transport service could
for instance be the use of a tolled road, a bus or metro ride or a parking service.
The TSU uses different types of transport services and for some of the services he/
she is charged a fee or fare that covers parts of or the whole cost of the transport
service provided. The TSU is denoted differently when consuming different trans-
port services. In tolling and parking he/she may be called a Vehicle owner or Driver
and in public transport he/she may be called a Customer. For shared bike services
he/she may be called a Cyclist or Bike user and for Transport information services
he/she may be called a Driver, Customer or Traveller.
Any transport service where the user of the service has to pay for the service can
be part of the CTSA concept and any transport service would very often have their
own service specific names for the user of the transport service. The overall name
in the CTSA concept is just TSU.
Table 2 (continued)
Actors Description
Transport Operations The transport service itself is provided to the TSU by the TOM. This means either
Manager (TOM) transporting the user by the transport means operated by the TOM (e.g. bus,
metro, ferry or train) or giving the TSU service rights (access) to the transport
infrastructure operated by the TOM, e.g., a tolled bridge owner and operator.
The transport services provided can include many different types of transport
service, e.g., the use of road infrastructure, the use of a parking lot, the use of pub-
lic transport means (e.g. buses, trams, metros and trains), the use of commercial
vehicles for transporting goods and the use of transport information and individu-
al route guidance. In these cases, the TOM is the road owner/operator, the parking
lot owner/operator, the public transport means owner/operator (Service operator
in the IFMSA role model), the commercial vehicle owner/operator, the transport in-
formation provider and the individual route guidance provider. The TOM requires
that the TSU pays for the transport service that is provided. In the CTSA concept,
the TSU will not pay at the time and place the transport service is used. The TOM
accepts that the TSU has the right to the transport service based on the secureIDs
the TSU is carrying with him/her and that are presented to the TOM whenever the
TSU benefits from the service, e.g. when the customer enters the bus or when the
driver enters the tolled road. The TOM requires some infrastructure for reading
and validating the secureIDs carried by the user. In a tolling environment, this
includes the required EFC physical architecture with OBEs, Roadside and Central
Equipment. Hence, the TOM will also be what is called the Toll Charger in the EFC
role model. In the public transport domain, the infrastructure for reading and
validating the secureIDs will include different types of media readers and valida-
tors and back-office systems usually operated by the IFMSA role model Service
provider.
Transport Service The TSM is the role that acts as the interface to the TSU including amongst others
Manager (TSM) an explicit or implicit contract with the user, charging of the user for the transport
services provided/to be provided and user support. The TSM is also responsible
for paying the TOM for the transport services provided to the user. This is typically
a public entity.
The service rights (the secureIDs) are issued by the TSM. There is an explicit or
implicit contract between the TSU and the TSM depending on the type of transport
service. The contract describes the product (the transport service) and how and how
much the TSU should pay for the product that the contract covers. In public trans-
port the contract will typically include the Usage and Pricing rules as defined in the
IFMSA standards. In a tolling environment, the product description will describe the
road infrastructure the TSU will have access to, how he/she should identify himself
when using the road infrastructure, e.g. by the use of On-Board Equipment (OBE),
and how much the user have to pay for the use of the road infrastructure. The TSM
will be the Toll Service Provider in a tolling environment. In the IFMSA role model
the TSM will be the product retailer on behalf of the product owner.
Mobility Service The MSM role provides bundled or unbundled transport information and reserva-
Manager (MSM) tion services, as well as registration of payment secureIDs to acquire the benefits
of the available transport services.
Common Transport The CTSAM is divided into two major roles: the manager that interacts with the
Service Account TOM or TSM, and the settlement account manager that interacts with the banking
Manager (CTSAM) sector (FSP).
The CTSAM is responsible for the management of the registered CTSA.
Financial Service The role that issues and validates electronic payment media, and
Provider (FSP) authenticates and settles payment transactions.
Each party involved in payment for public transport service may include their FSP
in the process. For example, when a credit card is used for payment, the card may
be issued by one brand, the payment may be authenticated through another mer-
chant acquirer, and the settlement may be executed through a third provider.
8 © ISO 2020 – All rights reserved

6.3 Framework data flows
There are several data flows that are described by the CTSA Framework. They include:
— Validation/Authentication secureIDs flow
— Account and secureID registration and settlement: for TU flow
— Account to account exchanges
Descriptions of the collaboration flows are provided in Table 3, Table 4, and Table 5 below.
Table 3 — Validation / authentication secureIDs flow
Validation and Origin Target Description
authentication
of secureID flow
1. Display/Actuate TSU TOM TSU displays or activates secureID to TOM’s reader or sensor.
2. Actuate SecureID Reader The reader processes the secureID including validating it and
generating a request to the CTSAM to authorize the secureID
holder’s right to access the transport service.
3. Authorization Reader TOM The TOM transmits the request to the CTSAM.
request
4. Authorization re- TOM CTSAM The CTSAM determines access value for use of service and
quest processes the secureID to determine priority product to use
to gain access to service.
See 7.3.6 for use case.
4a. Authorization CTSAM CTSA FSP For open payment (see 7.4, specifically bullet point 1 for use
request case), the CTSAM sends an additional request to its merchant
to authorize the payment.
4b. Authorization and CTSAM TSU FSP The merchant may send a request to the TSU’s bank for au-
payment order FSP thorization.
5. Response TOM Reader When the reader receives the authorization message, it pro-
vides or denies access to the secureID holder.
5a. Response CTSAM TOM CTSAM generates a message to the TOM that authorizes
or denies access to the secureID holder after it enters the
transaction.
5b. Response TSU FSP CTSAM TSU FSP responds to the CTSA FSP request with an approval
FSP or denial of authorization request.
6a. Claims (usage) CTSAM TSM The CTSAM reports to the TSM on the transaction, including
status (approval/denial), value/ product use, and appropriate
TSU information
6b. Response TOM Reader TOM directs reader to provide or deny access to secureID
holder.
7. Grant access to TOM TSU TOM grants or denies access to TSU.
transport service
10 © ISO 2020 – All rights reserved

Table 4 — Account and secureID registration and settlement: for TU
Account and Origin Target Description
secureID flow
A. Product TSU CTSAM For a CTSAM centric account management. The CTSAM
contract provides a customer registration and point of sales process.
See 7.3.2, 7.3.4 and 7.3.5 for use cases. (Separate flows are
identified between the CTSAM and TOM/TSM for acquisition
of access rights.).
B. Registered CTSAM TSU For a CTSAM centric account management. The CTSAM may
secureIDs allow registration secureIDs for a TOM or TSM. See
7.3.3 for detailed use case.
NOTE The CTSAM requires validation by the owner of
the secureIDs; for a bank card, it is the bank merchant and for
transport service or operator manager, by their registrar.
A. Product TSU TSM For a TSM centric account management, the TSM provides a
contract customer registration and point of sales process. See
7.3.2 and 7.3.5 use cases. (Separate flows are identified
between the TSM and TOM/a different TSM for acquisition of
access rights.)
B. Registered TSM TSU For a TSM centric account managem
...