ISO 24014-1:2021

Public transport - Interoperable fare management system - Part 1: Architecture

This document gives guidelines for the development of multi-operator/multi-service interoperable public surface (including subways) transport fare management systems (IFMSs) on a national and international level. This document is applicable to bodies in public transport and related services which agree that their systems need to interoperate. This document defines a conceptual framework which is independent of organizational and physical implementation. Any reference within this document to organizational or physical implementation is purely informative. This document defines a reference functional architecture for IFMSs and establishes the requirements that are relevant for ensuring interoperability between several actors in the context of the use of electronic tickets. The IFMS includes all the functions involved in the fare management process, such as: - management of media, - management of applications, - management of products, - security management, and - certification, registration, and identification. This document defines the following main elements: - identification of the different sets of functions in relation to the overall IFMS and services and media from non-transport systems which interact with fare management systems; - a generic model of an IFMS describing the logical and functional architecture and the interfaces within the system, with other IFMSs and with services and media from non-transport systems; - use cases describing the interactions and data flows between the different sets of functions; - security requirements. In its annexes, this document provides a framework for mobility platforms that integrate fare management and travel information for inter- and multimodal travel (see Annex A). It also elaborates on specific subjects covered in document and offers some national examples with regard to IFMS implementations (see Annex B, Annex C, Annex D and Annex E). This document does not define: - the technical aspects of the interface between the medium and the medium access device; - the data exchanges between the medium and the medium access device; NOTE The data exchanges between the medium and the medium access device are proposed by other standardization committees. - the financial aspects of fare management systems (e.g. customer payments, method of payment, settlement, apportionment, reconciliation).

Transport public — Système de gestion tarifaire interopérable — Partie 1: Architecture

Le présent document donne des directives pour développer des systèmes billettiques interopérables (IFMS) multi-opérateurs/multi-services pour le PT (y compris les métros), tant à l’échelle nationale qu’internationale. Le présent document s’applique aux organismes de PT et aux services connexes qui conviennent que leurs systèmes doivent être interopérables. Le présent document défini un cadre conceptuel, qui est indépendante de la mise en œuvre organisationnelle et physique. Toute référence à la mise en œuvre organisationnelle et physique dans le présent document est purement informative. Le présent document définit une architecture fonctionnelle de référence pour les systèmes IFMS et établir les exigences de nature à assurer l’interopérabilité entre plusieurs acteurs dans le contexte de l’utilisation de titres de transport électroniques. Le système IFM comprend l’ensemble des fonctions du processus de gestion des titres de transport, tels que: — gestion des supports, — gestion des applications, — gestion des produits, — gestion de la sécurité, et — certification, enregistrement et identification. Le présent document décrit les principaux éléments suivants: — identification des différents rôles IFM en relation avec le IFMS et services et supports provenant de systèmes autres que les transports qui interagissent avec les systèmes billettiques; — modèle générique de système IFM décrivant l’architecture logique et fonctionnelle ainsi que les interfaces au sein du système, et avec d’autres systèmes IFM ainsi que des services et des supports provenant de systèmes autres que les transports; — cas d'usage décrivant les interactions et les flux de données entre les différents rôles IFM fonctionnels; — exigences relatives à la sécurité. Dans ses annexes, le présent document fournit un cadre pour les plateformes de mobilité qui intègrent la gestion des tarifs et l'information sur les voyages pour les déplacements inter et multimodaux (voir l'Annexe A). Il traite également des sujets spécifiques abordés dans le document et offre quelques exemples nationaux concernant la mise en œuvre des IFMS (voir Annexe B, Annexe C, Annexe D et Annexe E). Le présent document ne définit pas: — les aspects techniques de l’interface entre le support et le terminal billettique; — les échanges de données entre le support et le terminal billettique; NOTE Les échanges de données entre le support et le terminal billettique sont traités par d’autres comités de normalisation. — les aspects financiers des systèmes billettiques (par exemple le paiement par le client, les moyens de paiement, le règlement, l’imputation, le rapprochement).

General Information

• Status: Published
• Publication Date: 14-Jan-2021
• ICS: 03.220.01 - Transport in general
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 8 - Public transport/emergency
• Current Stage: 6060 - International Standard published
• Start Date: 15-Jan-2021
• Due Date: 17-Oct-2020
• Completion Date: 15-Jan-2021

Relations

• Revises: ISO 24014-1:2015 - Public transport - Interoperable fare management system - Part 1: Architecture
• Effective Date: 10-Dec-2016

Overview

ISO 24014-1:2021 - Public transport - Interoperable fare management system - Part 1: Architecture - defines a conceptual, vendor‑neutral architecture for multi‑operator, multi‑service interoperable fare management systems (IFMS). It provides guidance for national and international IFMS designs for surface transport (including subways), focusing on functional roles, logical interfaces, use cases and security requirements while remaining independent of specific physical or organizational implementations.

Key topics and technical requirements

• Reference functional architecture: a generic model describing IFMS logical components, roles and internal/external interfaces.
• Functional domains: management of media, applications, products, security, and certification/registration/identification.
• Use cases and data flows: detailed interaction scenarios between IFMS functions, customer media and third‑party services.
• Security requirements: protection of assets, lifecycle security, key management, monitoring and security lists to ensure trust across actors.
• Identification and numbering: requirements for compact, unique identifiers for systems, applications and products to minimize transaction latency.
• Certification & registration: processes for organizations, components, media, ID and payment services, application and product templates.
• Account and media management: rules for customer accounts, media provisioning/termination, connecting media to accounts and product transfers.
• Clearing and reporting support: requirements for data collection, forwarding and generating clearing reports among actors.
• Annex material: framework examples for mobility platforms (Annex A) and practical PAYG, ID and national implementation examples (Annex B–E).

Note: the standard deliberately does not define the low‑level technical interface or data exchange between a medium and a medium access device (these are covered by other standards) nor the financial settlement mechanics (payments, reconciliation).

Practical applications

• Design and specification of national or cross‑border interoperable ticketing architectures.
• Procurement requirements for vendors and system integrators building IFMS components (account servers, registrars, certification authorities).
• Operational policies for transit authorities to manage media, products and security across multiple operators.
• Foundations for mobility platforms integrating fare management with multimodal travel information.
• Reference for security audits, certification programmes and interoperability testing.

Who should use this standard

• Public transport authorities and operators
• System architects and integrators for fare systems
• Mobility platform designers and aggregators
• Identity and payment service providers involved in transit ecosystems
• Standards bodies and policy makers planning interoperable ticketing deployments

Related standards

The document complements other technical standards that specify the medium–device interface and low‑level data exchanges and should be used together with those technical specifications when implementing a complete interoperable fare management solution.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 24014-1
Third edition
2021-01
Public transport — Interoperable fare
management system —
Part 1:
Architecture
Transport public — Système de gestion tarifaire interopérable —
Partie 1: Architecture
Reference number
©
ISO 2021
© ISO 2021
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents Page
Foreword .vi
Introduction .vii
1 Scope . 1
2 Normative references . 2
3 Terms and definitions . 2
4 Abbreviated terms . 6
5 Requirements . 6
6 System environment for IFMS . 7
6.1 General . 7
6.2 Mobility platforms . 7
7 Conceptual framework for IFMS . 7
7.1 General . 7
7.2 Description of IFM roles and external roles. 8
7.3 Basic framework of the generic IFM functional model .12
8 Use case description for the IFM functional model .13
8.1 Description of IFM-roles and external roles .13
8.2 Define set of rules .14
8.2.1 General.14
8.2.2 Define set of rules for Customer accounts .14
8.2.3 Define set of rules for media .14
8.2.4 Define set of rules for ID services . .15
8.2.5 Define set of rules for payment services .15
8.3 Certification .15
8.3.1 General.15
8.3.2 Certification of organizations .16
8.3.3 Certification of components .16
8.3.4 Certification of media .16
8.3.5 Certification of ID services .16
8.3.6 Certification of payment services .17
8.3.7 Certification of application specifications and templates .17
8.3.8 Certification of product specifications and templates .17
8.4 Interaction with external objects .18
8.4.1 General.18
8.4.2 Interaction with external media .18
8.4.3 Interaction with external applications.19
8.4.4 Interaction with external ID services .20
8.4.5 Interaction with external payment services .21
8.5 Registration .22
8.5.1 General.22
8.5.2 Registration of organizations .22
8.5.3 Registration of components .22
8.5.4 Registration of ID services .22
8.5.5 Registration of customer accounts .23
8.5.6 Registration of payment services .24
8.5.7 Registration of media .24
8.5.8 Registration of customer media .24
8.5.9 Registration of application templates . .25
8.5.10 Registration of applications .25
8.5.11 Registration of product templates .25
8.5.12 Registration of products .25
8.6 Managing ID services .26
8.6.1 General.26
8.6.2 Enrolment and update of Customer ID data via an application form .26
8.6.3 Enrolment and update of Customer ID data via an external ID service .27
8.6.4 Update of Customer ID data via an online account .27
8.6.5 Re-use of incumbent Customer ID data .28
8.6.6 Management and maintenance of Customer ID data .28
8.6.7 Providing the ID service to IFMS internal and external organizations .29
8.7 Management of customer accounts .29
8.7.1 General.29
8.7.2 Secure login to customer online accounts .30
8.7.3 Connect/disconnect customer media to/from the customer online account .30
8.7.4 Transfer of products between connected customer media .31
8.7.5 Connect system generated account with a customer account.32
8.7.6 Termination of customer accounts .32
8.8 Management of customer media .33
8.8.1 General.33
8.8.2 Provisioning of media .33
8.8.3 Termination of customer media .34
8.9 Management of applications .35
8.9.1 General.35
8.9.2 Dissemination of application templates .35
8.9.3 Acquisition of applications .36
8.9.4 Termination of application templates .36
8.9.5 Termination of applications .37
8.10 Management of products .38
8.10.1 Dissemination of product templates .38
8.10.2 Termination of product templates .39
8.10.3 Management of action lists .40
8.10.4 Acquisition of products .40
8.10.5 Modification of product parameters .40
8.10.6 Termination of products.41
8.10.7 Use and inspection of products .41
8.10.8 Collection of data .42
8.10.9 Forwarding data .43
8.10.10 Generation and distribution of clearing reports .43
8.11 Security management .44
8.11.1 General.44
8.11.2 Monitoring of IFM processes and IFM data life cycle .44
8.11.3 Management of IFM security keys .45
8.11.4 Management of security lists .45
8.12 Customer Service management (optional) .48
9 System interface identification .48
10 Identification .48
10.1 General .48
10.2 Numbering scheme .48
10.3 Prerequisites .49
10.3.1 There is one Registrar within the IFMS. .49
10.3.2 All objects, e.g. templates and components, have an owner who is one of
the actors in the IFMS. .49
10.3.3 The identification of the application and product shall be as short and
compact as possible due to the minimization of the transaction time
between the customer medium and the MAD. .49
11 Security in IFMSs .49
11.1 General .49
11.2 Protection of the interests of the public .49
11.3 Assets to be protected .50
11.4 General IFM security requirements .50
iv © ISO 2021 – All rights reserved

Annex A (informative) Mobility Platform – German example .52
Annex B (informative) Pay-As-You-Go (PAYG) roles and relationships in an IFMS.57
Annex C (informative) Mobility ID service example .63
Annex D (informative) Examples of IFMS implementations .73
Annex E (informative) Media centric management and back-office centric management .79
Bibliography .81
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, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC
278, Intelligent transport systems, in accordance with the Agreement on technical cooperation between
ISO and CEN (Vienna Agreement).
This third edition cancels and replaces the second edition (ISO 24014-1:2015), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— in order to prepare compatibility of Interoperable Fare Management (IFM) systems with mobility
platforms encompassing the entire mobility service chain, functions and roles known from IFM are
expanded; and
— new roles are introduced to operate mobility platforms.
A list of all parts in the ISO 24014 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.
vi © ISO 2021 – All rights reserved

Introduction
Fare management (FM) encompasses all the processes designed to manage the distribution and use of
fare products in a public transport environment.
Fare management is called interoperable (IFM) when it enables the customer to use a portable electronic
medium (e.g. a contact/contactless smart card or a Near Field Communications mobile device) with
compatible equipment (e.g. at stops, with retail systems, at platform entry points or on board vehicles).
IFM concepts can also be applied to fare management systems not using electronic media.
Potential benefits for the customer include reductions in queuing, special and combined fares, one
medium for multiple applications, loyalty programmes and seamless journeys.
There are two main changes in this edition of this document compared to the previous edition. Firstly,
in order to prepare compatibility of IFM systems with mobility platforms encompassing the entire
mobility service chain, functions and roles known from IFM are expanded. Secondly, new roles are
introduced to operate mobility platforms. These new roles should act with the roles defined in the IFM
and enter into interface relations.
With the introduction of so-called mobility platforms, which can integrate various IFM systems and
additional modes of transportation and deliver the travel information across these integrated domains,
the customer can benefit from seamless and well-guided multi- or inter-modal travel.
Interoperability of fare management systems also provides benefits to operators and the other parties
involved. However, it requires an overall system architecture that defines the system functionalities,
the actors involved and their roles, the relationships and the interfaces between them.
Interoperability also requires the definition of a security scheme to protect privacy, integrity, and
confidentiality between the actors to ensure fair and secure data flow within the IFM system (IFMS).
The overall architecture is the subject of this document, which recognizes the need for legal and
commercial agreements between members of an IFMS, but does not specify their form. The technical
specifications of the component parts and, particularly, the standards for customer media (e.g. smart
cards) are not included.
Note that there is not one single IFMS. Individual operators, consortia of operators, public authorities,
and private companies can manage and/or participate in IFMSs. An IFMS can span country boundaries
and can be combined with other IFMSs. Implementations of IFMSs require security and registration
functionalities. This document allows for the distribution of these functions to enable the coordination/
convergence of existing IFMSs to work together.
This document intends to provide the following benefits:
a) It defines a common definition of terms and roles that shall constitute the basis for the other parts
of ISO 24014 and technical specifications and technical reports from ISO/TC 204 which address
mobility platforms, fare management and interoperability between IFM and other systems.
b) It provides a framework for an interoperable fare management implementation with minimum
complexity.
c) It provides guidance on how IFM Managers can benefit from external devices and services and how
interoperability and appropriate security level can be established in cooperation with systems
from other markets.
d) It aims to shorten the time and lower the cost of IFMS procurement as both suppliers and purchasers
understand what is being purchased. Procurement against an open standard reduces cost as it
avoids the need for expensive bespoke system development and provides for second sourcing.
e) It aims to simplify interoperability between IFMSs to the benefit of all stakeholders.
In Annex A, this document provides a framework for mobility platforms that integrate fare management
and travel information for inter- and multimodal travel. This document also contains other informative
annexes, which elaborate on some specific subjects of the document and offer some national examples
with regard to IFMS implementations (see Annex B, Annex C, Annex D and Annex E).
viii © ISO 2021 – All rights reserved

INTERNATIONAL STANDARD ISO 24014-1:2021(E)
Public transport — Interoperable fare management
system —
Part 1:
Architecture
1 Scope
This document gives guidelines for the development of multi-operator/multi-service interoperable
public surface (including subways) transport fare management systems (IFMSs) on a national and
international level.
This document is applicable to bodies in public transport and related services which agree that their
systems need to interoperate.
This document defines a conceptual framework which is independent of organizational and physical
implementation. Any reference within this document to organizational or physical implementation is
purely informative.
This document defines a reference functional architecture for IFMSs and establishes the requirements
that are relevant for ensuring interoperability between several actors in the context of the use of
electronic tickets.
The IFMS includes all the functions involved in the fare management process, such as:
— management of media,
— management of applications,
— management of products,
— security management, and
— certification, registration, and identification.
This document defines the following main elements:
— identification of the different sets of functions in relation to the overall IFMS and services and media
from non-transport systems which interact with fare management systems;
— a generic model of an IFMS describing the logical and functional architecture and the interfaces
within the system, with other IFMSs and with services and media from non-transport systems;
— use cases describing the interactions and data flows between the different sets of functions;
— security requirements.
In its annexes, this document provides a framework for mobility platforms that integrate fare
management and travel information for inter- and multimodal travel (see Annex A). It also elaborates
on specific subjects covered in document and offers some national examples with regard to IFMS
implementations (see Annex B, Annex C, Annex D and Annex E).
This document does not define:
— the technical aspects of the interface between the medium and the medium access device;
— the data exchanges between the medium and the medium access device;
NOTE The data exchanges between the medium and the medium access device are proposed by other
standardization committees.
— the financial aspects of fare management systems (e.g. customer payments, method of payment,
settlement, apportionment, reconciliation).
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
account-based ticketing
ABT
architectural approach that stores products (3.30) in the IFM (3.19) system’s back-office (i.e. the
customer’s personal account or a temporary account) and not in the customer medium (3.12)
Note 1 to entry: The customer medium carries authentication credentials and an application (3.7) that contains
references to the account-based products in the back-office.
3.2
action list
list of items related to IFM (3.19) applications (3.7) or products (3.30) downloaded to medium access
devices (3.24) (MADs) processed by the MAD if and when a specific IFM application or product
referenced in the list is encountered by that MAD
3.3
actor
person, organization (3.25), or another (sub)system playing a coherent set of functions when interacting
with the IFM system (3.20) within a particular use case (3.36)
3.4
application rules
specification of rules in the application (3.7) contract for the use of the application with the Customer as
defined by the application owner
3.5
application specification
specification of functions, data elements, and security scheme according to the application rules (3.4)
3.6
application template
executable technical pattern of the application specification (3.5)
2 © ISO 2021 – All rights reserved

3.7
application
implemented and initialized application template (3.6)
Note 1 to entry: The application may host one or more products (3.30) and may support functions which identify
and protect the access to these products. For ABT- and ID-based architectures, the application may reside partly
in the customer medium (3.12) (identification and access control function) and partly in the IFM (3.19) back-office
(products).
Note 2 to entry: The application is identified by a unique identifier.
Note 3 to entry: The application may house products (3.30) and other optional customer information (customer
details, customer preferences).
Note 4 to entry: The application can be fully installed on customer media or distributed on the customer media
and the IFM back-offices.
3.8
commercial rules
rules defining the settlement and commission within the IFMS (3.20)
3.9
component
any piece of hardware and/or software that performs one or more functions in the IFMS (3.20)
3.10
component provider
anyone who wants to bring a component (3.9) to the IFMS (3.20)
3.11
customer account
data space hosted by the IFMS (3.20) (typically the product retailer) that contains all information which
is relevant for the business relationship between the Customer and the IFMS
Note 1 to entry: Accounts are maintained and managed by the responsible stakeholder in the IFMS. Accounts
which are accessible online may also be established and managed by the Customer.
3.12
customer medium
medium (3.22) initialized with an application (3.7) through an application contract
3.13
derived identity
derived ID
electronic identifier generated from another ID (3.15) (primary ID)
Note 1 to entry: Typically, the derived ID is generated by an identity provider in such a way that the authenticity
of the derived ID can be proven but there is no way to conclude from the derived ID back to the primary ID.
The concept of derived ID is typically used when primary ID with high security demand (like driver licence or
governmental eID) shall not be exposed to an environment that doesn't support high assurance levels.
3.14
external
object which does not follow the rules of the IFMS (3.20) and for which special activities are necessary
to implement interoperability and security with the IFMS
3.15
identity
ID
information that describes a specific person or object in a unique and unambiguous way
Note 1 to entry: For instance, a person can be described by the attributes name, birth date, sex, address, etc.
Unambiguous identification of a person typically needs, in addition, a unique identifier which is issued by the
Identity Provider. An object, e.g. a ticketing machine, can be described by owner, type, and software version. A
unique serial number could serve as identifier.
3.16
IFM functional model
model to define functions of IFM roles (3.18) and how they interact
3.17
IFM policy
commercial, technical, security, and privacy objectives of IFM (3.19)
3.18
IFM role
abstract object performing a set of functions in an IFM functional model (3.16)
3.19
interoperable fare management
IFM
all the functions involved in the fare management process such as management of application (3.7),
products (3.30), security and certification, registration, and identification to enable Customers to travel
with participating Service Operators using a single portable electronic medium (3.22)
3.20
interoperable fare management system
IFMS
all technical, commercial, security, and legal elements which enable interoperable fare management (3.19)
3.21
level of assurance
LoA
level of resilience of IFMS (3.20) components (3.9) and processes against a defined attack potential
Note 1 to entry: to entry; Level of assurance is typically defined by the Security Manager for all components of
the IFMS and specified in the set of rules (3.33) for security certification.
3.22
medium
physical carrier of applications (3.7)
3.23
message
set of data elements transferred between two IFM roles (3.18)
3.24
medium access device
MAD
device with the necessary facilities (hardware and software) to communicate with a customer
medium (3.12)
3.25
organization
legal entity covering the functions and implied responsibilities of one or more of the following
operational IFM roles (3.18): Application Owner, Application Retailer, Product Owner, Product Retailer,
Service Operator, Collection and Forwarding, etc.
4 © ISO 2021 – All rights reserved

3.26
pricing rule
rules defining the price and payment/billing relationships to the Customer
3.27
product rule
usage, pricing, and commercial rules (3.8) defined by the Product Owner
3.28
product specification
complete specification of functions, data elements, and security scheme according to the product
rules (3.27)
3.29
product template
technical pattern of the product specification (3.28)
Note 1 to entry: The product template is identified by a unique identifier.
3.30
product
instance of a product template (3.29) stored in an application (3.7)
Note 1 to entry: A product defines a commercial offer to the Customer. By purchasing a product, the Customer is
entitled to obtain specific services which are defined by the Product Owner.
Note 2 to entry: It is identified by a unique identifier and enables the Customer to benefit from a service provided
by a Service Operator.
3.31
role
abstract object performing a set of functions
3.32
security policy
objectives of the IFMS (3.20) to secure the public interests and the assets within the IFMS
3.33
set of rules
regulations for achieving IFM policies (3.17) expressed as technical, commercial, security, and legal
requirements and standards relevant only to the IFMS
3.34
trigger
event that causes the execution of a use case (3.36)
3.35
usage rule
rule defining the usage time, the usage area, the personal status and the type of service
3.36
use case
description of a process by defining a sequence of actions performed by one or more actors (3.3) and by
the system itself
4 Abbreviated terms
KYC know your customer
NFC near field communication
PAYG pay-as-you-go
PT public transport
5 Requirements
The purpose of the ISO 24014 series is to achieve interoperability throughout fare management systems
while making sure that participating companies in PT remain as commercially free as possible to design
their own implementation in pursuing their own business strategies.
In addition, interoperability between individual IFMS, with external systems and services and also the
integration of IFMS by so-called mobility platforms shall be specified.
Specific requirements of the IFMS model are as follows:
— A Customer shall be able to travel with all participating Service Operators (seamless journey) using
a single medium.
— There shall be a capability to extract data appropriate to the revenue-sharing and statistical
requirements of the Service Operators.
— The same medium may carry additional applications in addition to the IFM application. Conversely,
external media may carry the IFM application.
— The methods associated with the application shall offer the opportunity to reduce the current time
taken to enter/exit the PT system and may reduce payment handling costs significantly.
— The IFMS model shall provide the capability to accommodate new product specifications as required
regardless of those already in existence.
— The IFMS model shall recognize and prevent internal or external fraud attacks.
— The IFMS model shall facilitate a balance between measures for security and fraud avoidance
against the need to offer Customer convenience and performance.
— The IFMS model shall have the capability to identify the Customer while protecting their privacy as
appropriate.
— The IFMS model shall ensure the integrity of exchanged data.
— The IFMS model shall enable the implementation of additional services: loyalty programmes, car
sharing, park and ride, bike and ride, etc.
— The IFMS model shall provide interface definitions between identified functions within PT or other
modes of transportation to enable different operator networks to interoperate.
— The IFMS model shall describe interfaces which are essential to enable data-forwarding functions
between different operator networks allowing revenue-sharing agreements to be met.
— The IFMS model shall provide a framework from which commercial agreements may be developed.
— The IFMS model shall be neutral with regard to different technologies which can be deployed [e.g.
contact medium, contactless medium (short range, wide range), external devices, independent of
access technologies, account-, cloud- or ID-based concepts].
— The IFMS model shall be functionally neutral regarding specific transport organization structures.
6 © ISO 2021 – All rights reserved

— The IFMS model shall support the introduction of and migration to new technologies and architecture
concepts and interoperability with media, applications and systems from other market sectors.
6 System environment for IFMS
6.1 General
Previous editions of this document have focused on interoperability between fare management systems.
However, recent trends and market developments require enhancements of the IFMS architecture,
interoperability with other PT systems and also interoperability with systems, customer media and
applications from other market sectors. This system environment for IFMS is illustrated in Figure 1 below.
Figure 1 — System environment for IFMS
6.2 Mobility platforms
The approaches mentioned so far are primarily related to IFMS. However, advanced travel information
systems and complex mobility platforms offer functionalities encompassing the entire service chain,
of which fare management is only a part. For the comprehensive modelling of the roles in the context
of travel information systems and their interdependencies, extensions are needed on the travel
information side.
In order to integrate IFMSs in mobility platforms, functions and roles known from IFM should be
expanded. In addition, new roles are required to operate mobility platforms. These new roles should act
with the roles defined in the IFM and enter into interface relations.
This document defines a possible approach to mobility platforms in Annex A.
7 Conceptual framework for IFMS
7.1 General
The IFMS may be operated by a single transport undertaking, a transport authority, an association of
public and private companies, or other groups.
An IFM Manager establishes and manages the IFM policies on behalf of the IFMS. These policies are
embedded in the set of rules.
To manage the elements of the IFMS dealt with in this document, the IFM Manager shall appoint:
— Security Manager, and
— Registrar.
The functions and the responsibilities of the Security Manager and the Registrar can be distributed to
several organizations within an IFM.
Cooperation between several IFMS requires that the IFM Managers establish a joint set of rules and
synchronize the activities of the IFMS’s Security Managers and Registrars. Alternatively, the roles of
the Security Manager and the Registrar could be merged in order to serve all involved IFMS.
The IFM manager is also in charge if the IFMS wants to establish interoperability with external systems,
components or services. In such a case, the IFM Manager and the managers of the external systems have
to agree on sets of rules that establish and maintain interoperability between the IFMS and external
roles, services or components.
7.2 Description of IFM roles and external roles
IFM roles are identified by capitalized initial letters of each word.
Account Provider The Account Provider supports the following functions:
— provisioning and hosting of Customer accounts;
— creates and validates Customer login credentials for access to a
customer online account.
Application Owner The Application Owner holds the application contract and specifies the
application rules for the use of the application with the Customer.
Application Retailer The Application Retailer sells and terminates applications, collects value,
...

NORME ISO
INTERNATIONALE 24014-1
Troisième édition
2021-01
Transport public — Système de
gestion tarifaire interopérable —
Partie 1:
Architecture
Public transport — Interoperable fare management system —
Part 1: Architecture
Numéro de référence
©
ISO 2021
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2021
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii © ISO 2021 – Tous droits réservés

Sommaire Page
Avant-propos .vi
Introduction .vii
1 Domaine d’application . 1
2 Références normatives . 2
3 Termes et définitions . 2
4 Abréviations . 6
5 Exigences . 6
6 Environnement système pour l’IFMS . 7
6.1 Généralités . 7
6.2 Plateformes de mobilité . 7
7 Cadre conceptuel du système IFM . 8
7.1 Généralités . 8
7.2 Description des rôles IFM et des rôles externes . 8
7.3 Cadre de base du modèle fonctionnel IFM générique .12
8 Description du cas d'utilisation pour le modèle fonctionnel IFM .13
8.1 Description des rôles IFM et des rôles externes .13
8.2 Définition d’une convention d’interopérabilité .14
8.2.1 Généralités .14
8.2.2 Définition d’une convention d’interopérabilité pour les comptes clients .14
8.2.3 Définition d’une convention d’interopérabilité pour le support .14
8.2.4 Définition d’une convention d’interopérabilité pour les services
d’identification.15
8.2.5 Définition d’une convention d’interopérabilité pour les services de paiement .15
8.3 Certification .15
8.3.1 Généralités .15
8.3.2 Certification des entités juridiques .16
8.3.3 Certification des composants .16
8.3.4 Certification des supports.16
8.3.5 Certification des services d’identification .17
8.3.6 Certification des services de paiement .17
8.3.7 Certification de la spécification et du masque d’application .17
8.3.8 Certification de la spécification et de la structure de produit .18
8.4 Interaction avec les objets externes .18
8.4.1 Généralités .18
8.4.2 Interaction avec les supports externes .19
8.4.3 Interaction avec les applications externes.20
8.4.4 Interaction avec les services d’identification externes .21
8.4.5 Interaction avec les services de paiement externes .21
8.5 Enregistrement .22
8.5.1 Généralités .22
8.5.2 Enregistrement des entités juridiques .23
8.5.3 Enregistrement des composants .23
8.5.4 Enregistrement des services d’identification .23
8.5.5 Enregistrement de comptes clients .24
8.5.6 Enregistrement des services de paiement . .25
8.5.7 Enregistrement des supports .25
8.5.8 Enregistrement des supports client .25
8.5.9 Enregistrement des masques d’applications .26
8.5.10 Enregistrement des applications .26
8.5.11 Enregistrement des structures de produits .26
8.5.12 Enregistrement des produits .27
8.6 Gestion des services d’identification .27
8.6.1 Généralités .27
8.6.2 Inscription et mise à jour des données d’identification du Client via le
formulaire de demande .27
8.6.3 Inscription et mise à jour des données d’identification du Client via un
service d’identification externe.28
8.6.4 Mise à jour des données d’identification du Client via un compte en ligne .29
8.6.5 Réutilisation de données d’identification Client existantes .29
8.6.6 Gestion et maintenance des données d’identification du Client .30
8.6.7 Fourniture du service d’identification aux entités juridiques internes et
externes au système IFM .30
8.7 Gestion de comptes clients .31
8.7.1 Généralités .31
8.7.2 Connexion sécurisée au compte Client en ligne .31
8.7.3 Connexion/déconnexion du support client au/du compte client en ligne .32
8.7.4 Transfert de produits entre supports client connectés .32
8.7.5 Connexion de compte généré par le système au compte client .33
8.7.6 Résiliation de comptes clients .34
8.8 Gestion des supports client .34
8.8.1 Généralités .34
8.8.2 Mise à disposition de supports .34
8.8.3 Résiliation de supports client .35
8.9 Gestion des applications .36
8.9.1 Généralités .36
8.9.2 Diffusion de masques d’applications .37
8.9.3 Acquisition d’applications .37
8.9.4 Résiliation des masques d’applications .37
8.9.5 Résiliation d’applications .38
8.10 Gestion des produits .39
8.10.1 Diffusion de structures de produits.40
8.10.2 Résiliation de structures de produits .40
8.10.3 Gestion de listes d’actions .41
8.10.4 Acquisition de produits .41
8.10.5 Modification des paramètres d’un produit .42
8.10.6 Résiliation de produits . .42
8.10.7 Utilisation et contrôle des produits .43
8.10.8 Collecte des données .44
8.10.9 Transfert des données .44
8.10.10 Établissement et diffusion des états de compensation .45
8.11 Gestion de la sécurité .45
8.11.1 Généralités .45
8.11.2 Surveillance des processus et du cycle de vie des données du système IFM .46
8.11.3 Gestion des clés de sécurité IFM .46
8.11.4 Gestion de listes de sécurité .47
8.12 Gestion du Service après-vente (optionnel) .49
9 Identification des interfaces système .50
10 Identification .50
10.1 Généralités .50
10.2 Modèle de numérotation .50
10.3 Prérequis .51
10.3.1 Il existe un seul Office d’enregistrement dans le système IFM. .51
10.3.2 Tous les objets, par exemple les masques et les composants, ont un
propriétaire qui sera l’un des acteurs du système IFM. .51
10.3.3 L’identification de l’application et du produit doit être aussi concise
et compacte que possible afin de réduire au minimum le temps de
transaction entre le support client et le Terminal billettique. .51
11 Sécurité dans les systèmes IFM .51
iv © ISO 2021 – Tous droits réservés

11.1 Généralités .51
11.2 Protection des intérêts du public .51
11.3 Actifs à protéger .52
11.4 Exigences de sécurité IFM générales .52
Annexe A (Informative) Plateforme de mobilité – Exemple en Allemagne .54
Annexe B (informative) Rôles et relations pour le paiement à l’utilisation dans un système IFM .60
Annexe C (informative) Exemple de service d'identification pour la mobilité .66
Annexe D (informative) Exemples de mises en œuvre de systèmes IFM .76
Annexe E (informative) Gestion centrée sur les supports et gestion centrée sur le back-office .83
Bibliographie .85
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est
en général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l'ISO participent également aux travaux.
L'ISO collabore étroitement avec la Commission électrotechnique internationale (CEI) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www
.iso .org/ directives).
L'attention est attirée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l'élaboration du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de
brevets reçues par l'ISO (voir www .iso .org/ brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion
de l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique l’ISO/TC 204, Systèmes de transport
intelligents, en collaboration avec le comité technique CEN/TC 278, Systèmes de transport intelligents, du
Comité européen de normalisation (CEN) conformément à l'accord de coopération technique entre l'ISO
et le CEN (Accord de Vienne).
Cette troisième édition annule et remplace la deuxième édition (ISO 24014-1:2015), qui a été
techniquement révisée.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— afin de préparer la compatibilité des systèmes d'interopérabilité billettique (IFM) avec les
plateformes de mobilité englobant l'ensemble de la chaîne de services de mobilité, les fonctions et
les rôles connus de l'IFM sont étendus; et
— de nouveaux rôles sont introduits pour exploiter les plateformes de mobilité.
Une liste de toutes les parties de la série ISO 24014 se trouve sur le site web de l’ISO.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html
vi © ISO 2021 – Tous droits réservés

Introduction
Le système billettique (FM - Fare Management) englobe tous les processus conçus pour gérer la
distribution et l’utilisation de produits tarifaires dans un environnement de transport public.
Le système billettique est dit interopérable (IFM - Interoperable Fare Management) lorsqu’il permet
au client d’utiliser un support électronique portable (par exemple une carte à puce à contact/sans
contact ou un appareil mobile de communication en champ proche) avec des équipements compatibles
(par exemple aux arrêts, aux équipements de distribution, aux points d’accès aux quais ou à bord des
véhicules). Les concepts IFM peuvent aussi être utilisés dans les systèmes billettiques qui n’utilisent
pas de supports électroniques.
Les avantages potentiels pour le client comprennent la réduction des files d’attente, des tarifs spéciaux
ou combinés, un support unique pour plusieurs applications, des programmes de fidélisation et un
voyage sans couture.
Il y a deux changements principaux dans cette édition de ce document par rapport à l'édition précédente.
Premièrement, afin de préparer la compatibilité des systèmes IFM avec les plates-formes de mobilité
englobant toute la chaîne de services de mobilité, les fonctions et les rôles connus de l'IFM sont étendus.
Deuxièmement, de nouveaux rôles sont introduits pour exploiter les plates-formes de mobilité. Ces
nouveaux rôles doivent agir avec les rôles définis dans l'IFM et entrer dans des relations d'interface.
Avec l’introduction de plateformes dites de mobilité, qui peuvent intégrer divers systèmes IFM et des
modes de transport supplémentaires, en plus d'assurer l’information des usagers sur l’ensemble de
ces domaines intégrés, le client peut bénéficier de déplacements multimodaux ou intermodaux sans
rupture et bien guidés.
L’interopérabilité des systèmes billettiques bénéficie aussi aux opérateurs et autres entités concernées.
Elle nécessite cependant une architecture globale qui définit les fonctionnalités, les acteurs concernés,
leurs rôles, leurs relations et leurs interfaces.
L’interopérabilité exige également la définition de principes de sécurité pour protéger la vie privée,
l’intégrité et la confidentialité des données entre les acteurs pour garantir l’exactitude et la sécurité des
flux de données au sein du système billettique interopérable (IFMS - Interoperable Fare Management
System). L’architecture globale est l’objet de Le présent document dans le document qui reconnaît le
besoin d’accords légaux et commerciaux entre les membres d’un IFMS, mais ne précise pas leur forme.
Les spécifications techniques des Composants et notamment les normes applicables aux Supports client
(par exemple les cartes à puce) ne sont pas couvertes par le présent document.
Il n’existe pas qu’un seul IFMS. Les opérateurs individuellement ou regroupés en consortiums, les
autorités publiques et les entreprises privées peuvent gérer et/ou participer à plusieurs systèmes
billettiques interopérables. Un IFMS peut dépasser les frontières nationales et peut être combiné
à d’autres systèmes. Les mises en œuvre de systèmes billettiques interopérables exigent des
fonctionnalités de sécurité et d’enregistrement. Le présent document prévoit la distribution de ces
fonctions pour permettre la coordination/convergence des systèmes billettiques interopérables
existants afin qu’ils fonctionnent ensemble.
Le présent document entend apporter les avantages suivants:
a) Il établit une définition commune des termes et des rôles qui constitueront la base des autres
parties de l’ISO 24014 et des spécifications techniques et rapports techniques de l’ISO/TC 204 qui
traitent des plateformes de mobilité, du système billettique et de l’interopérabilité entre le système
IFM et les autres systèmes.
b) Il propose un cadre général de mise en œuvre d’un système billettique interopérable avec le
minimum de complexité.
c) Il fournit des directives sur la façon dont les Responsables IFM peuvent bénéficier de dispositifs
et de services externes et sur la manière dont l’interopérabilité et le niveau de sécurité approprié
peuvent être établis en coopération avec les systèmes issus d’autres marchés.
d) Il a pour objectif de raccourcir les délais et de diminuer les coûts d’acquisition d’IFMS en facilitant
la compréhension de l’objet du contrat à la fois pour les fournisseurs et pour les acheteurs. Fonder
les achats sur une norme ouverte réduit les coûts en évitant l’onéreux développement de systèmes
sur mesure et en permettant des sources d’approvisionnement alternatives.
e) Il a pour but de simplifier l’interopérabilité entre les systèmes billettiques dans l’intérêt de toutes
les parties prenantes.
Dans son Annexe A, le présent document propose un cadre pour les plateformes de mobilité qui intègrent
la billettique et l’information des usagers pour les déplacements intermodaux et multimodaux. Le
présent document contient également d'autres annexes informatives, qui développent certains sujets
spécifiques du document et offrent des exemples nationaux en ce qui concerne la mise en œuvre du
SIFM (voir Annexe B, Annexe C, Annexe D et Annexe E).
viii © ISO 2021 – Tous droits réservés

NORME INTERNATIONALE ISO 24014-1:2021(F)
Transport public — Système de gestion tarifaire
interopérable —
Partie 1:
Architecture
1 Domaine d’application
Le présent document donne des directives pour développer des systèmes billettiques interopérables
(IFMS) multi-opérateurs/multi-services pour le PT (y compris les métros), tant à l’échelle nationale
qu’internationale.
Le présent document s’applique aux organismes de PT et aux services connexes qui conviennent que
leurs systèmes doivent être interopérables.
Le présent document défini un cadre conceptuel, qui est indépendante de la mise en œuvre
organisationnelle et physique. Toute référence à la mise en œuvre organisationnelle et physique dans le
présent document est purement informative.
Le présent document définit une architecture fonctionnelle de référence pour les systèmes IFMS et
établir les exigences de nature à assurer l’interopérabilité entre plusieurs acteurs dans le contexte de
l’utilisation de titres de transport électroniques.
Le système IFM comprend l’ensemble des fonctions du processus de gestion des titres de transport, tels
que:
— gestion des supports,
— gestion des applications,
— gestion des produits,
— gestion de la sécurité, et
— certification, enregistrement et identification.
Le présent document décrit les principaux éléments suivants:
— identification des différents rôles IFM en relation avec le IFMS et services et supports provenant de
systèmes autres que les transports qui interagissent avec les systèmes billettiques;
— modèle générique de système IFM décrivant l’architecture logique et fonctionnelle ainsi que les
interfaces au sein du système, et avec d’autres systèmes IFM ainsi que des services et des supports
provenant de systèmes autres que les transports;
— cas d'usage décrivant les interactions et les flux de données entre les différents rôles IFM fonctionnels;
— exigences relatives à la sécurité.
Dans ses annexes, le présent document fournit un cadre pour les plateformes de mobilité qui intègrent
la gestion des tarifs et l'information sur les voyages pour les déplacements inter et multimodaux (voir
l'Annexe A). Il traite également des sujets spécifiques abordés dans le document et offre quelques
exemples nationaux concernant la mise en œuvre des IFMS (voir Annexe B, Annexe C, Annexe D et
Annexe E).
Le présent document ne définit pas:
— les aspects techniques de l’interface entre le support et le terminal billettique;
— les échanges de données entre le support et le terminal billettique;
NOTE Les échanges de données entre le support et le terminal billettique sont traités par d’autres comités
de normalisation.
— les aspects financiers des systèmes billettiques (par exemple le paiement par le client, les moyens de
paiement, le règlement, l’imputation, le rapprochement).
2 Références normatives
Il n'y a pas de références normatives dans ce document.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
billetterie sur compte
ABT [Account-Based Ticketing]
approche architecturale qui enregistre les produits (3.30) dans le back-office du système IFM (3.19) (par
exemple le compte personnel du client ou un compte temporaire) et pas sur le support client (3.12)
Note 1 à l'article: Le support client comporte des informations d’authentification et une application (3.7) qui
contient des références aux produits sur compte dans le back-office.
3.2
liste d’actions
liste d’éléments relatifs à des applications (3.7) ou à des produits (3.30) d'IFM (3.19), téléchargée vers
des terminaux billettiques (3.24) (MAD) et traitée par le terminal billettique si et quand ce dernier
rencontre une application ou un produit IFM référencé(e) dans la liste
3.3
acteur
personne, entité juridique (3.25), ou autre (sous-)système assumant un ensemble cohérent de fonctions
lorsqu’il interagit avec le système IFM (3.20) dans un cas d’utilisation (3.36) particulier
3.4
convention d’application
spécification des règles dans le contrat d'application (3.7) pour l'utilisation de l'application avec le client
tel que défini par le propriétaire de l'application
3.5
spécification d’application
spécification de fonctions, d’éléments de données et d’un plan de sécurité en correspondance avec la
convention d’application (3.4)
3.6
masque d’application
schéma technique exécutable de la spécification d’application (3.5)
2 © ISO 2021 – Tous droits réservés

3.7
application
masque d’application (3.6) mis en œuvre et initialisé
Note 1 à l'article: L’application peut héberger un ou plusieurs produits (3.30) et peut prendre en charge des
fonctions qui identifient et protègent l’accès à ces produits. Pour les architectures basées sur une billetterie
sur compte (ABT) ou sur une identification (ID), l’application peut résider en partie dans le support client (3.12)
(fonction d’identification et de contrôle d’accès) et en partie dans le back office IFM (3.19) (produits).
Note 2 à l'article: L’application possède un identifiant unique.
Note 3 à l'article: L’application peut contenir des produits (3.30) et d’autres informations optionnelles sur le client
(coordonnées, préférences du client).
Note 4 à l'article: L’application peut être entièrement installée sur un support client ou répartie sur le support
client et dans les back-offices du système IFM.
3.8
règles commerciales
règles de partage des recettes et fixation des commissions dans le système IFM (3.20)
3.9
composant
élément matériel et/ou logiciel exécutant une ou plusieurs fonctions dans le système IFM (3.20)
3.10
fournisseur du composant
entité qui veut faire utiliser un composant (3.9) dans le système IFM (3.20)
3.11
compte client
espace de données hébergé par le système IFM (3.20) (généralement le distributeur du produit) qui
contient toutes les informations pertinentes pour la relation commerciale entre le Client et le système
IFM
Note 1 à l'article: Les comptes sont tenus et gérés par la partie prenante responsable du système IFM. Les comptes
accessibles en ligne peuvent également être créés et gérés par le client.
3.12
support client
support (3.22) initialisé à l’aide d’une application (3.7) sur la base d’un contrat d’application
3.13
identité dérivée
ID dérivée
Identifiant électronique généré à partir d’un autre identifiant (3.15) (identifiant principal)
Note 1 à l'article: En règle générale, l’identité dérivée est générée par un fournisseur d’identité de sorte que
l’authenticité de l’identité dérivée puisse être prouvée, mais il n’y a aucun moyen de vérifier l’authenticité de
l’identité principale à partir de l’identité dérivée. Le concept d’identité dérivée est généralement utilisé quand
l’identité principale associée à un impératif de sécurité élevé (comme un permis de conduire ou une identification
électronique gouvernementale) ne doit pas être exposée à un environnement qui ne garantit pas des niveaux
d’assurance élevés.
3.14
externe
L’objet désigné ne suit pas les règles du système IFM (3.20) et que des activités spéciales sont nécessaires
pour mettre en œuvre l’interopérabilité et la sécurité avec le système IFM
3.15
identité
ID
information décrivant une personne ou un objet spécifique de manière unique et sans ambiguïté
Note 1 à l'article: Par exemple pour une personne peut, être décrite par le nom des attributs, la date de naissance,
le sexe, l’adresse, etc. L’identification sans ambiguïté d’une personne nécessite généralement un identifiant
unique en plus, qui est délivré par le Fournisseur d’identité. Un objet, par exemple un guichet automatique, peut
être décrit par son propriétaire, son type et la version de son logiciel. Un numéro de série unique peut servir
d’identifiant.
3.16
modèle fonctionnel IFM
modèle servant à définir les fonctions et interactions des rôles IFM (3.18)
3.17
politiques IFM
objectifs commerciaux, techniques, de sécurité et de confidentialité du système IFM (3.19)
3.18
rôle IFM
concept abstrait réalisant un ensemble de fonctions dans un modèle fonctionnel IFM (3.16)
3.19
interopérabilité billettique
IFM [interoperable fare management]
système englobant toutes les fonctions impliquées dans le processus de gestion tarifaire telles que
la gestion d’application (3.7), de produits (3.30) de sécurité et de certification, d’enregistrement et
d’identification qui permettent aux clients de se déplacer sur les réseaux des Opérateurs de transport
participants avec un seul support (3.22) électronique portable
3.20
système billettique interopérable
IFMS [interoperable fare management system]
système comprenant l’ensemble des éléments techniques, commerciaux, sécuritaires et légaux qui
permettent une gestion tarifaire interopérable (3.19)
3.21
niveau d'assurance
LoA
niveau de résilience des composants (3.9) et processus du système IFM (3.20) contre un risque d’attaque
défini
Note 1 à l'article: Le LoA est typiquement défini par le Responsable Sécurité pour tous les composants du système
IFM et spécifié dans la Convention d’interopérabilité (3.33) pour la certification de sécurité.
3.22
support
support physique des applications (3.7)
3.23
message
ensemble d’éléments de données échangé entre deux rôles IFM (3.18)
3.24
terminal billettique
MAD (Medium Access Device)
appareil équipé des ressources (matérielles et logicielles) nécessaires pour communiquer avec un
support client (3.12)
4 © ISO 2021 – Tous droits réservés

3.25
entité juridique
personne morale assurant les fonctions et les responsabilités correspondantes d’un ou de plusieurs
des rôles IFM (3.18) opérationnels suivants: Propriétaire de l’application, Distributeur de l’application,
Propriétaire du produit, Distributeur du produit, Opérateur de transport et Agent de collecte et de
diffusion, etc
3.26
règles tarifaires
règles définissant les prix et les modes de paiement/facturation avec le Client
3.27
règles relatives à un produit
ensemble de règles tarifaires, commerciales (3.8) et d’utilisation définies par le Propriétaire du produit
3.28
spécification de produit
spécification complète de fonctions, d’éléments de données et d’un plan de sécurité en correspondance
avec les règles relatives au produit (3.27)
3.29
structure de produit
matrice technique de la spécification de produit (3.28)
Note 1 à l'article: La structure de produit possède un identifiant unique.
3.30
produit
instance d’une structure de produit (3.29) stockée dans une application (3.7)
Note 1 à l'article: Un produit définit une offre commerciale au Client. Lorsqu’il achète un produit, le Client obtient
le droit de bénéficier de services spécifiques définis par le Propriétaire du produit.
Note 2 à l'article: Le Produit possède un identifiant unique qui permet au Client de bénéficier d’un service fourni
par un Opérateur de transport.
3.31
rôle
concept abstrait réalisant un ensemble de fonctions
3.32
politique de sécurité
objectifs du système IFM (3.20) pour sécuriser les intérêts publics et les actifs au sein du système IFM
3.33
convention d’interopérabilité
ensemble de règles permettant de réaliser la politique IFM (3.17) exprimée sous la forme d’exigences
techniques, commerciales, sécuritaires et légales et dans des normes exclusivement spécifiques au
système IFM
3.34
déclencheur
événement qui entraîne l’exécution d’un cas d’utilisation (3.36)
3.35
règles d’utilisation
règles relatives à l’utilisation dans le temps, à l’utilisation dans l’espace, à l’état du personnel et au type
de service
3.36
cas d’utilisation
description d’un processus en définissant une séquence d’actions réalisées par un ou plusieurs acteurs
(3.3) et par le système lui-même
4 Abréviations
KYC connaitre le consommateur
NFC (near field communication) communication à champ proche
PAYG (pay-as-you-go) paiement en s’en allant
PT Transport public (TP)
5 Exigences
L’objet de l’ISO 24014 est de parvenir à l’interopérabilité de l’ensemble des systèmes billettiques tout
en garantissant autant que possible la liberté économique des entreprises impliquées dans le PTTP en
matière de mise en œuvre au service de leurs stratégies commerciales.
En outre, l’interopérabilité entre les différents systèmes IFM, avec les systèmes et services externes
ainsi que l’intégration des systèmes IFM par les plateformes dites de mobilité doivent être spécifiées.
Les exigences propres au modèle IFMS sont les suivantes:
— Un Client doit pouvoir se déplacer sur les réseaux de tous les opérateurs de transport avec un seul
Support (voyage sans rupture).
— Il doit exister une fonction permettant d’isoler les données nécessaires au partage des recettes et
aux exigences statistiques de chaque Opérateur de transport.
— Un même support doit pouvoir prendre en charge des applications supplémentaires, en plus de
l’application IFM. Inversement, un support externe doit pouvoir prendre en charge l’application IFM.
— Les méthodes associées à l’application doivent permettre de réduire le temps nécessaire pour entrer/
sortir du système de PTTP et peuvent réduire de manière significative les coûts de traitement de
paiement.
— Le modèle IFMS doit pouvoir prendre en charge de nouvelles Spécifications de produits, si nécessaire,
indépendamment de celles déjà existantes.
— Le modèle IFMS doit détecter et prévenir les actes frauduleux et malveillants internes ou externes.
— Le modèle IFMS doit promouvoir un équilibre entre les mesures de sécurité et de prévention des
fraudes et la nécessité de garantir un service commode et performant pour le Client.
— Le modèle IFMS doit pouvoir identifier le Client tout en protégeant sa vie privée comme approprié.
— Le modèle IFMS doit assurer l’intégrité des données échangées.
— Le modèle IFMS doit permettre l’introduction de prestations additionnelles: programmes de fidélité,
covoiturage, parcs relais, mode combinant vélo et transport en commun, etc.
— Le modèle IFMS doit fournir des définitions d’interfaces entre des fonctions identifiées dans
l’écosystème du PTTP ou d’autres modes de transport permettant l’interopérabilité des réseaux de
différents opérateurs.
— Le modèle IFMS doit décrire les interfaces nécessaires aux fonctions de transfert de données entre
les réseaux de différents opérateurs afin de permettre le respect des accords de partage des recettes.
6 © ISO 2021 – Tous droits réservés

— Le modèle IFMS doit fournir un cadre à partir duquel des accords commerciaux peuvent être
développés.
— Le modèle IFMS doit être neutre vis-à-vis des différentes technologies qui peuvent être déployées
[par exemple, support à contact, support sans contact (courte ou longue portée), dispositifs externes,
indépendamment des technologies d’accès, concepts reposants sur l’utilisation d’un compte, d’un
service Cloud ou d’un identifiant].
— Le modèle IFMS doit être fonctionnellement neutre vis-à-vis de la nature des Entités juridiques de
transport.
— Le mod
...