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

Status
Published
Publication Date
20-Jul-2020
Current Stage
6060 - International Standard published
Start Date
21-Jul-2020
Completion Date
21-Jul-2020
Ref Project

Buy Standard

Technical report
ISO/TR 21724-1:2020 - Intelligent transport systems -- Common Transport Service Account Systems
English language
32 pages
sale 15% off
Preview
sale 15% off
Preview
Draft
ISO/PRF TR 21724-1 - Intelligent transport systems -- Common Transport Service Account Systems
English language
32 pages
sale 15% off
Preview
sale 15% off
Preview

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.