ISO/TS 21193:2024

Technical
Specification
ISO/TS 21193
Second edition
Electronic fee collection —
2024-11
Requirements for EFC application
interfaces on common media
Perception de télépéage — Exigences relatives aux interfaces
d'application de télépéage sur média commun
Reference number
© ISO 2024
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
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Requirements for a common payment medium . 2
5.1 Requirements for EFC architecture .2
5.2 EFC functional requirements .4
6 Application structure in a common payment medium . 8
7 EFC application data in a common payment medium . 8
7.1 General .8
7.2 EFC attribute data for a common payment medium .9
7.3 Additional EFC attribute data .10
7.3.1 Data group RECEIPT .10
7.3.2 Data group PAYMENT .11
Annex A (normative) Data type specifications .12
Annex B (normative) Implementation conformance statement (ICS) pro forma .13
Annex C (informative) Common payment medium concept . 17
Annex D (informative) Application structure examples in common payment medium . 19
Annex E (informative) General information for common payment medium and OBE .21
Annex F (informative) System migration .23
Annex G (informative) Reloading system for pre-payment medium in Korean ETC .26
Annex H (informative) EFC security requirements for common payment medium and EFC
scheme .35
Bibliography .38

iii
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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.
This second edition cancels and replaces the first edition of ISO/TS 21192:2019, which has been technically
revised.
The main changes are as follows:
— Clause 3 has been updated and ISO/TS 17573-2 has been made the primary source for terms and
definitions;
— data definitions have been updated, including referring to ISO 17573-3 as the primary source;
— ISO 21177 is now referenced for inclusion of secure data transfer mechanism in subclause 7.1;
— the data elements that originated from EN 1545-2:2015 are formally defined in the ASN.1 module.
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
Introduction
Transportation network improvement, including road and railway, is essential to drive economic growth.
Integrated transport service has been aimed at topics such as user convenience, transport safety, reliability,
efficiency and availability. For example, a traffic manager can find which kinds of improvements are needed
to relieve traffic bottlenecks by analysing user transport flows in a transport system considered as a whole.
It is usually necessary to use different transport services to transfer people or goods from origin to
destination. Sometimes, using different transport services in the same trip becomes cumbersome when
transport services are operated by different operators, e.g. bad interconnections between different
transport modes due to user needs to search and compare transportation modes, need for separate
charging or payment for the transport services used. The connections between different transport modes
and the means to achieve seamless travel are improving with the use of information and communication
technologies (ICT).
ISO/TR 19639 investigated case studies on the use of a common payment medium when combining public
transport services and road services, based on the use of a common payment schema. This common payment
schema is further categorised into integrated central accounts and integrated on-board accounts.
ISO/TR 19639 concluded by stating the need for new electronic fee collection (EFC) standards to support on-
board integrated accounts, among which is an application interface between the common payment medium
and the common service rights provider (CSRP). The background of on-board accounts in EFC are as follows.
— Operational methods of EFC systems might be different due to regional and local circumstances. EFC
systems can be classified into central accounts and on-board accounts, using a common payment
medium, which are widely adopted in Asian countries.
— On-board account payment media are commonly used for public transport in several countries, e.g.
Singapore, Malaysia and China.
— Central payment accounts are considered one of the common service rights methods explained in
ISO/TR 20526, whereas the EFC standards are currently predominantly based on central accounts.
— A convergence on the usage of on-board account for both EFC systems and public transport should be
considered.
This document describes an EFC application as one type of transport service specific application and the
application interface requirements for a common service rights application. A common service rights
application is explained in informative Annex C of this document for understanding a common payment
scheme based on this concept as shown in Figure 1.

v
NOTE 1 Arrowed lines (4) labelled 'money' and 'e-money' are monetary flows that are outside the scope of this
document.
NOTE 2 Arrowed line (2) labelled 'Transport service' is not an ICT interface but a physical transport service.
NOTE 3 Other arrowed lines are in the scope of ISO/TC 204 (EFC and public transport standards) and the thick
arrow line between common payment medium and OBE is within the scope of this document.
Figure 1 — Common payment medium concept for EFC scheme
This document extends the set of EFC standards to allow provisions for multi-modal transport services by
using a common payment medium.
This document defines, among others, the role and responsibilities of a CSRP. The CSRP provides a common
payment medium for enabling use of EFC, a public transport service and retail shopping service to service
users with one account. CSRP may provide the usage record of user's multi-modal transport trip as a form of
customer service.
This document contains several annexes.
— Data type specifications are given in the Annex A, an implementation conformance statement (ICS)
proforma is given in Annex B.
— The common payment medium concept for any transport service is presented in the Annex C.
— General types of application structures in a medium are presented in the Annex D.
— General requirements from medium relating standards are presented in Annex E.
— A typical system migration method and technical solution supporting medium upgrading are presented
in Annex F. Examples of reloading types and transactions are presented in Annex G.
— The EFC security requirements for a common payment medium are presented in Annex H based on EFC
functional requirements.
The scope of this document includes an EFC application interface for a common payment medium as shown
in Figure 2, as well as the role and responsibilities of a CSRP.
Figure 2 explains the relation of CSRP among related sectors including EFC. E-money is exchanged between
the Transport Service Provider (TSP) in the EFC sector and the CSRP. E-money is exchanged between retail
in the commerce sector and the CSRP.

vi
Figure 2 — Scope within the EFC computational architecture

vii
Technical Specification ISO/TS 21193:2024(en)
Electronic fee collection — Requirements for EFC application
interfaces on common media
1 Scope
This document defines requirements to support information exchanges among related entities of a common
payment scheme. It defines:
a) EFC-related functional requirements for a common payment medium;
b) an application structure in a common payment medium;
c) EFC application data in a common payment medium.
The following is outside the scope of this document:
— requirements and data definitions for any other transport services such as public transport;
— a complete risk assessment for an EFC system using a common payment medium;
— security issues arising from an EFC application among all transport services;
— the technical trust relationship between a CSRP and a service user;
— concrete implementation specifications for implementation of security for an EFC system;
— detailed specifications required for privacy-friendly EFC implementations;
— any financial transactions of the CSRP.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 14906, Electronic fee collection — Application interface definition for dedicated short-range communication
ISO 17573-1, Electronic fee collection — System architecture for vehicle-related tolling — Part 1: Reference model
ISO/TS 17573-2, Electronic fee collection — System architecture for vehicle related tolling — Part 2: Vocabulary
ISO 17573-3, Electronic fee collection — System architecture for vehicle-related tolling — Part 3: Data dictionary
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/TS 17573-2 and the following
term and definition 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 https:// www .electropedia .org/

3.1
common service rights provider
CSRP
entity providing common service rights to the service user
4 Abbreviated terms
CSR Common Service Rights
CSRP Common Service Rights Provider
DSRC Dedicated Short-Range Communications
EFC Electronic Fee Collection
ETC Electronic Toll Collection
ICT Information and Communication Technologies
OBE On-Board Equipment
PCI DSS Payment Card Industry Data Security Standard
PT Public Transport
RSE Roadside Equipment
SAM Secure Application Module
SLA Service Level Agreement
SU Service User
TC Toll Charger
TSP Transport Service Provider
5 Requirements for a common payment medium
5.1 Requirements for EFC architecture
Any EFC architecture using a common payment medium shall conform with the EFC Roles model defined in
ISO 17573-1. The relation of role and responsibility of the "Provision of common service rights" and the EFC
role model described in ISO 17573-1 is shown in Figure 3 when enabling interoperability with any transport
services. The role of CSRP includes a part of EFC function for EFC regime. As an example, the EFC transaction
data described in ISO 14906 and ISO 17575-1 includes account information stored in the common payment
medium. The EFC role model belongs to the tolling domain and the "Provision of the common service rights"
role belongs to another domain, but the two domains are linked together by the use of common service
rights in EFC.
NOTE ISO 17573-1 explains how any EFC-specific common payment medium is used when there is no
interoperability with other transport services.

Figure 3 — EFC role model with provision of common service rights
The role related to CSRP is responsible for providing the basic provision, mechanism, organizational
structure, and information transfer tools needed to integrate an interoperable EFC system into a multi-
modal transport system.
Responsibilities related to this role are only restricted to CSRP and include:
— providing basic provision, including
— providing a common payment medium,
— guaranteeing that the entity performing the charging of the transport service rights role will be
paid for it,
— providing the common service rights to the user or accepting an existing one,
— collecting the money from the signatory of the EFC service contract and performing reloading
transaction for common payment medium,
— collecting all transport service transactions, clearing and distributing the money to the Transport
Service Provider (TSP),
— managing the customer relationships related to the use of the transport service concerning
information, claims, questions and answers, error handling and any contractual or financial matters,
— implementing and adhering to the security and privacy policies for the transport systems, and
— monitoring the actual operational quality relative to agreed service level agreements (SLAs);
— acting as a contract agent, including
— offering contractual relations according to defined conditions to interested users and concluding
contractual agreements,
— The user's needs to contract both use of OBE and use of common payment medium for EFC service.
— providing and managing the transport service contract including the service rights for the toll
service user;
— customizing the common payment medium, including customizing the common payment medium in a
secure way;
— maintaining the common payment medium, including
— maintaining the functionality of the common payment medium,
— maintaining the hot listing of the common payment medium, and

— performing the refund of values stored on the common payment medium.
A CSRP may make requirements to the TSP such as protecting some data, security keys and others.
5.2 EFC functional requirements
While an OBE is generally related to a vehicle, a common payment medium can be carried by the owner or
user also for use outside a vehicle. This means that the common payment medium should be considered
from the following points of view:
— enabling the use in all transaction models, for payment modes (pre-pay or post pay or both modes) and
applying security requirements;
— enabling the use of the EFC service with an OBE;
NOTE Enabling flexible EFC operation both with OBE and without OBE.
— enabling confirmation of account information and usage record of service as basic user services.
Based on these viewpoints, requirements are derived for support of a common payment medium, as shown
in Table 1.
Table 1 — Basic EFC functional requirements
Functional areas EFC function item Functional requirement for a common
payment medium
Transaction types Closed Toll - Entry Transaction — Common payment medium shall be usable for all
transaction types with OBE
Closed Toll - Exit Transaction
Open Toll Transaction
— Common payment medium shall store EFC contract
Transit Transaction
information
Checking Transaction
— Common payment medium shall securely store a
Purse Reloading Transaction
minimum of 3 usage log entries including transaction
type and date and time for use of a service
— Common payment medium shall store the entry data
for closed tolling system with OBE
NOTE 1 This also enables performing flexible EFC operations
both with OBE and without OBE.
Payment types Central Account — Common payment medium shall be usable for all
payment types
On-Board Account
Pre-Payment
— Common payment medium shall be usable for
Post-Payment
common payment among transport services
Electronic Purse Based Payment
— Common payment medium shall be usable for
Token Based Payment
reloading transaction if user signed a contract
'Open'(multiple service) Payment
System
'Closed'(single service) Payment
System
No/Zero Payment
Refunding
Contract types Area Dependent Contract — Common payment medium shall be usable for all
contract types
Time Dependent Contract
Vehicle Dependent Contract
— Common payment medium shall be usable with
Person Dependent Contract
OBE for vehicle dependent contract since vehicle
Group of Persons Dependent
information is stored in OBE. Otherwise RSE shall
Contract
detect vehicle information for this contract when
only common payment medium is used.
Anonymous Contract
Contract Contract Selection — Common payment medium shall be able to store
handling multiple contract information if necessary
Implicit Contract
Explicit Contract
Multiple Simultaneous Contracts
Security One Way Authentication — Common payment medium shall implement the
mechanism required security function(s)
Two Way Authentication
Data Integrity Mechanism
— Common service right provider as a common payment
No Specific Security
medium issuer shall provide secure processing
Segment Integrity Mechanism
environment to toll service provider
Signature Based Mechanism
Time/Event Based Mechanism
Password-based Access Mechanism
Encryption Mechanism
TTabablele 1 1 ((ccoonnttiinnueuedd))
Functional areas EFC function item Functional requirement for a common
payment medium
Operational Different gantries configurations — Operational requirements when a common payment
issues medium is used in EFC shall be considered before
Different lane configurations
implementation
OBE components addressing
Alert/Warning information to the
— Common payment medium shall store Version
customer
Handling Mechanism
Dynamic classification
— Common payment medium shall be able to be used for
Declared classification
Multi-application Handling
OBE Transaction Release
OBE Remote Switch Off NOTE 2 Multiple application access method is defined in
ISO/IEC 7816-4.
Version Handling Mechanism
OBE Capability Handling Mechanism
Multi-application Handling — Common payment medium shall store a minimum of
3 usage log entries including transaction type and
date and time for the use of a service
— Common payment medium shall prevent manipulating
the road usage data by user
Tariffing schemes Distance Dependent — Tariffing schemes shall be considered whenever
a common payment medium stores parameters
Time Dependent
corresponding to the tariff
Vehicle Dependent
Event Dependent
Fixed
Combined tariffing Scheme
The requirements on the common payment medium relating to Payment Card Industry Data Security
[34]
Standard (PCI DSS) should also be considered as a part of EFC functional requirements. PCI DSS is the
security standard of the card industry that was developed for cardholder data protection including technical
requirements. Technical requirements related to the EFC system using a common payment medium are
derived from a part of the 12 categories of requirements in PCI DSS. These are described in Table 2.
Actor in an EFC system can be certified as PCI DSS compliant.

Table 2 — Requirements of PCI DSS for EFC function requirements
[34]
Functional areas PCI DSS requirement Functional requirement for common
payment medium
Data protection — Keep cardholder data storage to a minimum — Primary account number (PAN), shall
by implementing data retention and disposal be secured with strong encryption
policies, procedures and processes
— EFC system shall store necessary and
— Do not store sensitive authentication data after minimalized personal account data for
authorization (even if encrypted) operation, not store it if not used
— Mask primary account number (PAN) when — EFC system shall not store sensitive
displayed (first six and last four digits are the authentication data after used
maximum displayed)
— Render PAN unreadable anywhere it is stored
(including on portable digital medium, backup
medium, and in logs) by using any of the
approaches
Cryptographic key — Document and implement procedures to — Key lifecycle management, type of key
management protect keys used to secure stored cardholder and key generation
data against disclosure and misuse
— Key updating method, on-line and off-
— Fully document and implement all key- line, secure transmission, key switching
management processes and procedures for during operation
cryptographic keys used for encryption of
— Secure key storage in hard and soft
cardholder data, including the following:
— List management, quantity of list,
— Generation of strong cryptographic keys
updating method, ensuring real-time
— Secure cryptographic key distribution
— Secure cryptographic key storage
— Cryptographic key changes for keys
— Retirement or replacement of keys
— If manual key management operations are used,
keys must be managed using split knowledge
and dual control
— Prevention of unauthorized substitution of
cryptographic keys
— Requirement for cryptographic key custodians
Transmission of — Use strong cryptography and security protocols — Sensitive EFC data such as cardholder
sensitive EFC data to safeguard sensitive cardholder data during data and PAN shall be encrypted using
transmission over open, public networks, strong cryptography at air interface
including the following: such as WAN and contactless card
interface
— Ensure wireless networks transmitting
cardholder data or connected to the cardholder
data environment, use industry best practices to
implement strong encryption for authentication
and transmission
— Never send unprotected PANs by end-user
messaging technologies
The following security measures derived from functional requirements listed above shall be implemented in
EFC system. These explanations are described in Annex H and a detail of a security specification is provided
by medium issuer under contract.
— Key management, type of key and key generation.

— Secure key storage in hardware and software.
— Key updating method, on-line and off-line, secure transmission, key switching during operation.
— List management, quantity of list, updating method, ensuring real-time.
— Sensitive EFC data.
— Secure data protection.
The business process requirements, derived from CEN/TR 16092 shown in Table E.1, should be considered
during developing of the specification of and EFC system.
6 Application structure in a common payment medium
This clause explains the application framework including EFC application in a common payment medium.
The common payment medium for usage in several transport services is a portable device such as an IC
card or a mobile device. For common use of a medium, this medium shall store either individual applications
provided by each TSP or an application that enables usage among all TSPs. In this latter case, the issuer of
the medium is required to know all application details to support all service providers.
The common media can support three types of application structures:
— Type 1: Multi application. The common payment medium is configured with individual transport service
applications and an application containing the CSR for use by all other transport service applications.
— Type 2: Shared data. The medium is configured with individual transport service applications and
application with shared data used for CSR by all other transport service applications.
— Type 3: Single application. The medium is configured with one common application that stores all data
for the use of corresponding transport services including CSR.
Further explanations of these types are given in Annex D.
7 EFC application data in a common payment medium
7.1 General
This clause deals with the minimum set of EFC application data in the common payment medium necessary
only to serve the interface data according to ISO 14906 for carrying out all EFC schemes described in 5.2, the
EFC functional requirements.
NOTE 1 According to the additional threats and security measures listed in ISO 19299, some attribute data are
added to those defined in ISO 14906 when a common payment medium is used for a closed toll system to prevent
swapping a common payment medium in a toll road network for abusing and juggling the toll charge.
NOTE 2 Data elements defined in the EN 1545 series can be used when more transport-related data are necessary
to be stored in the medium.
NOTE 3 The mechanism of secure data transfer for use of common media in multi-modal service via ITS station is
described in ISO 21177.
The EFC attribute data defined in 7.2 is required for the integrated use of a common payment medium within
an EFC system. These additional attributes are only stored in the common payment medium. The ASN.1 data
types specifications shall be in accordance with Annex A. Annex B contains an implementation conformance
statement proforma that shall be filled in by a supplier that claims a product to be in conformity with this
document.
7.2 EFC attribute data for a common payment medium
Table 3 shows the storage location of EFC attribute data in the case of a one-piece OBE (OBE built as a single
unit) and two-piece OBE (OBE built as a couple of units, one of which is the common payment medium):
1) A one-piece OBE, shown as case 1, stores all attribute data required to operate EFC service defined in
ISO 14906 and attribute data defined in this document;
2) A two-piece OBE, shown as case 2, stores attribute data for EFC service between an OBE and a medium
defined in ISO 14906 and attribute data defined in this document. OBE stores vehicle related-data and a
medium stores personal-related data.
According to the additional threats and security measures listed in ISO 19299, an additional attribute data
ReceiptEntryVehicle shall be added to those EFC attributes defined in ISO 14906 when a common payment
medium is used for a closed toll system to prevent swapping of a common payment medium in a toll road
network for abusing and juggling the toll charge.
There are selectable implemental options for use of common medium as explained in the following.
— OPTION 1: On a common payment medium for pre-payment service(s), the user can select an option
for reloading stored values when EFC charging is performed at a toll station. An additional attribute
data group named ReloadingParameter is included as a general data group for the reloading function of
stored values on a common payment medium for pre-payment service(s) (see Table 5). This data group
consists of some parameters for on-site reloading such as validity of reloading, threshold value for low
balance and value for reloading.
— OPTION 2: When the common payment medium is present, the stored EFC attribute data from the
common payment medium shall be used.
— OPTION 3: When the common payment medium is not present, the stored EFC attribute data in OBE shall
be used. This is an option for user convenience service as indicated by a single check in Table 3.
— OPTION 4: There are two parameters for ContractAuthenticator, one is stored inside the OBE and
another is stored on the common payment medium, and toll charger and toll service provider can check
whether these are authorised or not.
This document does not inhibit the OBE from storing data stored on the common payment medium.
Table 3 — Additional attribute data for medium
EFC attributes defined in ISO 14906 Data location
Case1 Case 2
Additional
One- OBE Medi-
Data group Attr.ID Attribute attribute for
piece um
medium
OBE
Contract 0 EFC-ContextMark   
1 ContractSerialNumber   
2 ContractValidity   
35 ValidityOfContract   
 
3 ContractVehicle
ContractAuthenticator   
Key
 Requirement for store as mandatory data
 Requirement for store as optional data
Blank Data can be stored.
TTabablele 3 3 ((ccoonnttiinnueuedd))
EFC attributes defined in ISO 14906 Data location
Case1 Case 2
Additional
One- OBE Medi-
Data group Attr.ID Attribute attribute for
piece um
medium
OBE
Receipt 5 ReceiptServicePart   
6 SessionClass   
7 ReceiptServiceSerialNumber   
  
36 ReceiptFinancialPart
ReceiptContract   
10 ReceiptOBEId   
11 ReceiptICC-Id   
12 ReceiptText   
13 ReceiptAuthenticator   
  
14 ReceiptDistance
ReceiptData1   
34 ReceiptData2   
Vehicle 15 VehicleIdentificationNumber  
16 VehicleLicencePlateNumber  
17 VehicleClass  
 
18 VehicleDimensions
VehicleAxles  
20 VehicleWeightLimits  
Equipment 24 EquipmentOBEId  
25 EquipmentICC-Id 
26 EquipmentStatus   
  
Driver 27 DriverCharacteristics
PaymentMeans  
Payment 32
29 PaymentMeansBalance  
30 PaymentMeansUnit  
31 PaymentSecurityData  
Receipt   ReceiptEntry-
Vehicle

Payment  ReloadingPa-
rameter
Key
 Requirement for store as mandatory data
 Requirement for store as optional data
Blank Data can be stored.
7.3 Additional EFC attribute data
7.3.1 Data group RECEIPT
This data group consists of some optional data elements. Typical data elements for a closed EFC system are
shown in Table 4.
Table 4 — Receipt data
EFC attribute Data element Definition Type Informative remarks
ReceiptEntryVehicle VehicleLicencePlateNumber LPN
Vehicle licence plate number EXAMPLE
recognized and stored at entry
Enabling detection of swapping common pay-
toll gate.
ment medium at Service area and/or Parking
area for devious toll payment.
EquipmentOBEId OCTET
OBE ID copied and stored at EXAMPLE
STRING
entry toll gate.
Enabling to detect swapping common payment
medium at Service area and/or Parking area for
devious toll payment.
VehicleClass INT1
Vehicle class classified and
stored at entry toll gate
EntryAuthenticator Authenticator for this attrib- OCTET
STRING
ute.
NOTE Specification of calculation of authenticator is provided by medium issuer.
7.3.2 Data group PAYMENT
This data group consists of some optional data elements. Typical data elements for pre-payment values
stored on a common payment medium is shown in Table 5.
Table 5 — Payment data
EFC attribute Data element Definition Type Informative remarks
Reloading ReloadingValidity DateAndTime
End date and time of the validity of the
Parameter reloading contract option.
ThresholdBalance Threshold value of balance in medium SignedValue,
INT3
for reloading activation at EFC transac-
tion.
ReloadingValue SignedValue,
Value to add balance in medium at re-
INT3
loading transaction.
DepositValue Amount of a deposit for checking when SignedValue, Described in EN 1545-2, as
INT3
auto-reloading transaction is performed. Amount.
Dynamic Flag
Flag for reloading value equal to charg-
Reloading
ing value when insufficient balance.
ValueFlag
Reloading OCTET STRING
Authenticator calculated by the Authenticator of
Authenticator ContractProvider called Common all data element in
Service Right Provider when issuing ReloadingParameter,
the Contract, to prevent tampering with except of this
contract data. ReloadingAuthenticator.
Autoload DateAndTime
Start date and time of the period of the Described in EN 1545-2, as
StartDate reloading option service for checking DateStamp.
when EFC transaction is performed.
AutoloadEndDate DateAndTime
End date and time of the period of the re- Described in EN 1545-2, as
loading option service for checking when DateStamp.
EFC transaction is performed.
AutoRenewFlag Flag
A flag indicating whether auto-renew is Described in EN 1545-2, as
enabled. Valid flag for automatic reload- Flag.
ing at EFC transaction.
NOTE Specification of calculation of authenticator is provided by medium issuer.

Annex A
(normative)
Data type specifications
The EFC data types and associated coding related to the EFC attribute data, described in Clause 7, are defined
using the Abstract Syntax Notation One (ASN.1) technique according to ISO/IEC 8824-1. The unaligned
packed encoding rules according to ISO/IEC 8825-2 are applied.
The actual ASN.1 module is identified by the object identifier {iso(1) standard(0) 21193 version2(2) minor
version(1)}. and is contained in the attached file “ISO21193 EfcCsrv 2.1.asn” which can be directly imported
in an ASN.1 compiler. The file is available for download at https:// standards .iso .org/ iso/ ts/ 21193 .https://
standards .iso .org/ iso/ 12855/ ed -3/ en/
The syntax and semantics of the data types in the ASN.1 types in the above-mentioned file that is imported
shall conform with ISO 17573-3 and ISO 14906, respectively.
Table A.1 provides the SHA-256 cryptographic hash digests for the referenced files, offering a means to
[35]
verify the integrity of the referenced files. The SHA-256 algorithm is specified in NIST 180-4.
Table A.1 — SHA-256 cryptographic hash digests
File name SHA-256 cryptographic hash digest
ISO21193 EfcCsrv 2.1.asn 84862210e09609da0d4be533be7eb8564ca3a78809ee-
f2358a423c3f8826cefa
It is important to be aware that pasting the text of the file into one of the hash digest computation pages
available on the web can result in a non-matching hash digest due to changes in the underlying coding.

Annex B
(normative)
Implementation conformance statement (ICS) pro forma
B.1 General
To evaluate the conformance of a particular implementation, it is necessary to have a statement of those
capabilities and options that have been implemented. This is called an implementation conformance
statement (ICS).
This annex presents the pro forma to be used for the attributes defined in Clause 7 and Annex A, with ICS
templates that are to be filled in by equipment suppliers.
B.2 Purpose and structure
The purpose of this ICS is to provide a mechanism whereby a supplier of an implementation of the attribute in
medium defined in this document can provide information about the implementation in a standardised manner.
The ICS is subdivided as follows corresponding to categories of information:
— identification of the implementation;
— identification of the protocol;
— global statement of conformance;
— ICS tables.
B.3 Instruction for completing ICS
B.3.1 Definition of support
A capability is said to be supported if the implementation under test (IUT) can:
— generate the corresponding operation parameters (either automatically or because the end user requires
that capability explicitly), and
— interpret, handle and, when required, make available to the end user the corresponding error or result.
A protocol element is said to be supported for a sending implementation if it can generate it under certain
circumstances (either automatically or because the end user requires relevant services explicitly).
A protocol element is said to be supported for a receiving implementation if it is correctly interpreted and
handled and also, when appropriate, made available to the end user.
B.3.2 Status column
This column (see Tables B.1 to B.8) indicates the level of support required for conformance. The values are
as follows:
m mandatory support is required;

o optional support is permitted for conformance to this document. If implemented, it shall conform to the
specifications and restrictions contained in the standard. These restrictions may affect the optionality
of other items;
c the item is conditional (support of the capability is subject to a predicate);
c: m the item is mandatory if the predicate is true, optional otherwise;
— the item is not applicable;
— the item is outside the scope of this ICS.
In the ICS tables, every leading item marked “m” shall be supported by the IUT. Sub-items marked “m” shall
be supported if the corresponding leading item is supported by the IUT.
B.3.3 Support column
This column (see Tables B.6 to B.8) shall be completed by the supplier or implementer to indicate the level of
implementation of each item. The proforma has been designed such that values required are the following:
Y Yes, the item has been implemented;
N No, the item has not been implemented;
— the item is not applicable.
All entries within the ICS proforma shall be made in ink. Alterations to such entries shall be made by crossing
out, not by erasing or making the original entry illegible, and by writing the new entry alongside. All such
alterations to records shall be initialised by the person who made them.
B.3.4 Item reference numbers
Each line within the ICS which requires that implementation details be entered is numbered at the left-hand
edge of the line. This numbering is included as a mean of uniquely identifying all possible implementation
details within the ICS. This referencing is used both inside the ICS, and for references from other test
specification documents.
The means of referencing individual responses is done in the following sequence:
a) a reference to the smallest individual response enclosing the relevant item;
b) a solidus character (“/”);
c) the reference number of the row in which the response appears;
d) if, and only if, more than one response occurs in the row identified by the reference number, implicit
labelling of each possible entry as “a”, “b”, “c”, etc., from left to right, with this letter appended to the
sequence.
B.4 ICS for medium
B.4.1 Identification of the implementation
The following pro forma (Table B.1 to Table
...