ISO/TR 21724-1:2020
(Main)Intelligent transport systems — Common Transport Service Account Systems — Part 1: Framework and use cases
Intelligent transport systems — Common Transport Service Account Systems — Part 1: Framework and use cases
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.
Titre manque — Partie 1: Cadre et cas d'utilisation
General Information
Buy Standard
Standards Content (Sample)
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/TR 21724-1:2020(E)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO/TR 21724-1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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
---------------------- Page: 2 ----------------------
ISO/TR 21724-1:2020(E)
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
© ISO 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/TR 21724-1:2020(E)
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
---------------------- Page: 4 ----------------------
ISO/TR 21724-1:2020(E)
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
© ISO 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/TR 21724-1:2020(E)
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
---------------------- Page: 6 ----------------------
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.
© ISO 2020 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/TR 21724-1:2020(E)
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
---------------------- Page: 8 ----------------------
ISO/TR 21724-1:2020(E)
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.
© ISO 2020 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/TR 21724-1:2020(E)
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
---------------------- Page: 10 ----------------------
ISO/TR 21724-1:2020(E)
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 v
...
TECHNICAL ISO/TR
REPORT 21724-1
First edition
Intelligent transport systems —
Common Transport Service Account
Systems —
Part 1:
Framework and use cases
Partie 1: Cadre et cas d'utilisation
PROOF/ÉPREUVE
Reference number
ISO/TR 21724-1:2020(E)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO/TR 21724-1:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© 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 PROOF/ÉPREUVE © ISO 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/TR 21724-1:2020(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviations. 2
5 Common Transport Services Account overview . 2
5.1 General . 2
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.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 Payment Categories .29
Bibliography .32
© ISO 2020 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/TR 21724-1:2020(E)
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 PROOF/ÉPREUVE © ISO 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/TR 21724-1:2020(E)
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 has 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 compliance
with ISO/IEC 14443 or ISO/IEC 18092. This implies physical and technical interoperability but also 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 development of
Common Transport Services 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 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 increasingly being used in public transport and other transport service payment systems
in the United States and Europe.
© ISO 2020 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
ISO/TR 21724-1:2020(E)
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 PROOF/ÉPREUVE © ISO 2020 – All rights reserved
---------------------- Page: 6 ----------------------
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 service, 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
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
credential
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: The credential or secureID is typically an encrypted token or biometric marker that is uniquely
associated with a user’s identification.
Note 2 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
credential application stored on the media and the type of transport service provided.
© ISO 2020 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 7 ----------------------
ISO/TR 21724-1:2020(E)
Note 3 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 4 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 Abbreviations
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
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
2 PROOF/ÉPREUVE © ISO 2020 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/TR 21724-1:2020(E)
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 credential 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.
© ISO 2020 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 9 ----------------------
ISO/TR 21724-1:2020(E)
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 PROOF/ÉPREUVE © ISO 2020 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/TR 21724-1:2020(E)
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,
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.