SIST-TP CEN/TR 16092:2011

SLOVENSKI STANDARD
01-maj-2011
(OHNWURQVNRSRELUDQMHSULVWRMELQ=DKWHYH]DSUHGSODþLOQHVLVWHPH
Electronic fee collection - Requirements for pre-payment systems
Elektronische Gebührenerfassung - Anforderungen für Systeme zur Vorauszahlung
Perception de télépéage - Exigences sur les systèmes de pré-paiement
Ta slovenski standard je istoveten z: CEN/TR 16092:2011
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL REPORT
CEN/TR 16092
RAPPORT TECHNIQUE
TECHNISCHER BERICHT
March 2011
ICS 03.220.20; 35.240.60
English Version
Electronic fee collection - Requirements for pre-payment
systems
Perception de télépéage - Exigences relatives aux Elektronische Gebührenerfassung - Anforderungen für
systèmes de pré-paiement Systeme zur Vorauszahlung

This Technical Report was approved by CEN on 16 August 2010. It has been drawn up by the Technical Committee CEN/TC 278.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2011 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 16092:2011: E
worldwide for CEN national Members.

Contents Page
Foreword . 4
Introduction . 5
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 7
4 Abbreviations . 9
5 Interoperability Issues . 10
5.1 Interoperability based on EFC Roles Model . 10
5.2 Interoperability and Payment . 11
6 Classification of Pre-Pay solutions . 11
6.1 Pre-Pay Account held in Central System . 11
6.2 Pre-Pay Account held on OBE . 12
7 Requirements for Pre-Pay account held in Central Systems . 13
7.1 General . 13
7.2 Business Process Requirements . 13
7.2.1 General . 13
7.2.2 Issuing of an EFC contract to the Service User . 13
7.2.3 Personalisation of OBE . 15
7.2.4 Loading of value onto an account . 15
7.2.5 Charging of Toll . 17
7.2.6 Invoicing of the Service User . 17
7.2.7 Refund of residual amount . 17
7.2.8 Clearing of Transactions . 18
7.2.9 Handling of Complaints . 18
7.2.10 Security Considerations . 18
7.3 Technical Requirements . 18
7.3.1 Requirements for OBE . 18
7.3.2 Requirements for POS Networks . 18
7.3.3 Requirements for Information and Payment Flow (Interfaces) . 19
7.4 Legal and Functional Constraints . 19
7.4.1 Legal Considerations . 19
7.4.2 Functional Constraints . 21
8 Requirements for Pre-Pay account held on OBE . 22
8.1 Prerequisites . 22
8.2 Business Process Requirements . 22
8.2.1 Issuing of the Pre-Pay mode . 22
8.2.2 Personalisation of OBE . 22
8.2.3 Loading of stored value onto a VBD . 23
8.2.4 Loading of stored value into the OBE . 23
8.2.5 Charging of the toll . 24
8.2.6 Clearing of transactions . 26
8.2.7 Hotlisting / Enforcement . 27
8.2.8 Invoicing of the Service User . 27
8.2.9 Refund of residual amount . 28
8.2.10 Proof of Transactions . 28
8.2.11 Handling of Complaints . 28
8.2.12 Security Considerations . 28
8.3 Technical Requirements . 29
8.3.1 Requirements for Value Unit bearing User Media . 29
8.3.2 Requirements for OBE . 30
8.3.3 Requirements for POS Networks . 31
8.3.4 Requirements for Information and Payment Flow (Interfaces) . 31
8.4 Legal and Functional Constraints . 31
8.4.1 Legal Considerations . 31
8.4.2 Functional constraints . 33
9 Invoicing of the Service User . 34
9.1 General . 34
9.2 VAT considerations . 34
9.3 Business model considerations . 35
9.4 Invoice considerations . 35
10 Gaps in terms of Standards and recommendations . 37
10.1 Pre-Pay Account held in Central System . 37
10.2 Pre-Pay Account held on OBE . 37
10.3 Recommendation for next steps . 37
Annex A (informative) Examples of implementations . 38
Bibliography . 40

Foreword
This document (CEN/TR 16092:2011) has been prepared by Technical Committee CEN/TC 278 “Road Transport
and Traffic Telematics”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights.
CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document has been prepared under a mandate given to CEN by the European Commission and the
European Free Trade Association.

Introduction
The discussion on payment-modes within the environment of electronic fee collection at present is based on the
existence of a post-payment contract between the Toll Service Provider (TSP) and the Service User (SU).
Pre-conditions of such a contractual agreement are
 sufficient creditworthiness of the SU, and
 existence of a bank account with the SU.
Questions arise in the context of the access to an EFC system for
 SUs not being able to meet the aforementioned pre-conditions;
 SUs with occasional needs to use an EFC system (mainly from the private sector)
 not willing to open a bank account;
 not able to open a bank account (by reasons what so ever) and therefore not allowed to participate;
 from countries with limited access to the card market to participate in an interoperable EFC system, which
may otherwise not be open to them.
To meet the requirements of this clientele, one or more suitable ways of pre-payments have to be established for
EFC to grant interoperability:
 stored value on an electronic medium;
 stored value in a central account.
As far as private users are concerned legislation could ask for anonymous payment modes as nobody can be
forced to open or communicate a bank account. On the other hand such payment modes help Toll Service
Providers to offer an interoperable EFC service to customers with a limited monetary risk.
Before defining necessary standards in that field the requirements of a universal Pre-Payment system able to
communicate with the OBE have to be evaluated, especially with regard to validity and feasibility for private users.

1 Scope
This technical report (TR) analyses requirements for a universal Pre-Pay account system for EFC including the
following issues:
 relations to other existing standards in this domain;
 the core requirements and functionality that must be provided.
This technical report will show an analysis of the requirements for a universal prepay system and categorise
possible different types of pre-pay solutions, in terms of functionality, technical and legal considerations. As far as
legal requirements are concerned it will be clarified whether the pre-payment means fall within the scope of
European Directive 2000/46/EC on the taking up, pursuit of and prudential supervision of the business of
electronic money institutions and whether the medium-issuing organisation has to act as a financial institution and
falls within the scope of the Payment Service Directive 2007/64/EC. The latter applying exactly to payment
activities undertaken by entities but do not require a full bank license.
The technical report will describe the current state-of-affairs of EFC pre-payment systems, including the demand
for standards and inventory of provisions provided by standards. It will identify and prioritize gaps in terms of
standards or other enablers needed in order for the market to provide viable pre-payment solutions in a European
context.
There are two general approaches to represent the content of the TR:
a) allocate each requirement under each pre-pay solution;
b) allocate each pre-pay solution under each requirement.
To achieve a better understanding and readability alternative a) has been decided (this refers to Clause 8 and
Clause 9 only).
The TR does not give any decision on how or whether one of the pre-payment solutions described is commercially
feasible to be considered as an implementable offer to the Service User. The return for invest for any TSP
regarding the system architecture requirements and other obligations (refunding of SU) is questionable.
This TR just gives a summary of the requirements of possible pre-pay solutions. It is up to decision makers to
evaluate the alternatives in the light of their individual preconditions of their tolling regime and of market
acceptance.
2 Normative references
The following referenced documents are indispensable for the application 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.
EN 15509, Road transport and traffic telematics — Electronic fee collection — Interoperability application profile
for DSRC
prEN ISO 12855, Electronic fee collection — Information exchange between service provision and toll charging
(ISO/DIS 12855:2009)
EN ISO 14906, Road transport and traffic telematics — Electronic fee collection — Application interface definition
for dedicated short-range communication (ISO 14906:2004)
prEN ISO 17573, Electronic fee collection — System architecture for vehicle related tolling (ISO/DIS 17573:2009)
CEN ISO/TS 25110, Electronic fee collection — Interface definition for on-board account using integrated circuit
card (ICC) (ISO/TS 25110:2008)
ISO 4217, Codes for the representation of currencies and funds
ISO/IEC 7810, Identification cards — Physical characteristics
ISO/IEC 7816-1, Identification cards — Integrated circuit(s) cards with contacts — Part 1: Physical characteristics
ISO/IEC 7816-2, Identification cards — Integrated circuit cards — Part 2: Cards with contacts — Dimensions and
location of the contacts
ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical
interface and transmission protocols
ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for
interchange
ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Inter-industry data elements for
interchange
ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations
ISO/IEC 14443-1, Identification cards — Contactless integrated circuit cards — Proximity cards —- Part 1:
Physical characteristics
ISO/IEC 14443-2, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 2: Radio
frequency power and signal interface
ISO/IEC 14443-3, Identification cards — Contactless integrated circuit(s) cards — Proximity cards — Part 3:
Initialization and anticollision
ISO/IEC 14443-4, Identification cards — Contactless integrated circuit cards — Proximity cards — Part 4:
Transmission protocol
ISO/IEC 15693-1, Identification cards — Contactless integrated circuit cards — Vicinity cards — Part 1: Physical
characteristics
ISO/IEC 15693-2, Identification cards — Contactless integrated circuit cards — Vicinity cards — Part 2: Air
interface and initialization
ISO/IEC 15693-3, Identification cards — Contactless integrated circuit cards — Vicinity cards — Part 3:
Anticollision and transmission protocol
ISO/IEC 18092, Information technology — Telecommunications and information exchange between systems —
Near Field Communication — Interface and Protocol (NFCIP-1)
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
3.1
Electronic Fee Collection (EFC)
toll charging by electronic means via a wireless interface
3.2
enforcement
process of compelling observance of a law, regulation, etc.
3.3
Interoperability
ability of systems to provide services to and accept services from other systems and to use the services so
exchanged to enable them to operate effectively together
EXAMPLE For tolling interoperability aims at enabling a vehicle to drive through various toll domains while having only
one OBE operating under one contract with a toll service provider.
3.4
Onboard equipment (OBE)
equipment fitted within or on the outside of a vehicle and used for toll purposes
3.5
tariff Scheme
set of rules to determine the fee due for a vehicle in a toll domain for a EFC object at a certain day and time
3.6
toll
charge, a tax, a fee, or a duty in connection with using a vehicle within a toll domain
3.7
toll charger
legal entity charging toll for vehicles in a toll domain
3.8
toll declaration (from OBE)
statement (from the OBE of a vehicle) to a toll charger, not necessarily transmitted via a direct communication
channel, that confirms the presence of a vehicle in a toll domain in a format agreed between the toll service
provider and the toll charger
3.9
toll domain
area or part of a road network where a EFC regime is applied
3.10
EFC point
location within a toll domain where the OBE has to issue a toll declaration
3.11
EFC regime
set of rules, including enforcement rules, governing the collection of toll in a toll domain
3.12
toll schema
generic term used for EFC regime and/or toll domain and/or toll system depending on the context
3.13
toll service
service enabling users having only one contract and one set of OBE to use a vehicle in one or more toll domains
3.14
toll service provider
legal entity providing to his customers toll services on one or more toll domains for one or more classes of vehicles
3.15
toll system
off board equipment and possible other provisions used by a toll charger for the collection of toll for vehicles
3.16
EFC object
distinguished part of a toll domain for which one or more tariff schema applies
EXAMPLE An EFC object may be e.g. an area, all public roads within an area, a bridge, a zone, or a stretch of a road
(network).
3.17
service user
generic term used for the customer of a toll service provider, one liable for toll, the owner of the vehicle, a fleet
operator, a driver etc. depending on the context
3.18
value units bearing device (VBD)
device in the hand of the Service user that contains value units
4 Abbreviations
For the purpose of this document, the following abbreviations apply throughout the document unless otherwise
specified.
CAD Card Accepting Device
DSRC Dedicated Short Range Communication
EETS European Electronic Toll Service
EFC Electronic fee collection
EMD e-Money Directive
GNSS Global Navigation Satellite System
GSM Global System for Mobile communications
IC Integrated Circuit
ID Identification
IPR Intellectual Property Rights
IRPA International Radiation Protection Authority
NFC Near Field Communication
OBE On Board Equipment
PDA Personal Digital Assistant
PMD Payment Services Directive
POS Point Of Sale
PSP Payment Service Provider
RSE Road Side Equipment
SAM Secure Access Module
SP see TSP
SU Service User
TC Toll Charger
TR Technical Report
TS Technical Specification
TSP Toll Service Provider = Service Provider
VAT Value Added Tax
VBD Value Units Bearing Device
5 Interoperability Issues
5.1 Interoperability based on EFC Roles Model
Any universal Pre-Pay system needs to comply with the EFC Roles model defined in prEN ISO 17573. This
standard defines the four main roles shown in Figure 1.

Figure 1 — Roles in the Toll Charging environment
Provision of the Toll Service
The role related to the provision of the Toll service is responsible for providing the basic artefacts, mechanisms,
organization structures, and information transfer tools needed to run an EFC system. Provision of the OBE and the
EFC contract with the Service User are two of the most important responsibilities of the role. An actor covering all
responsibilities of the role is often called a Toll Service Provider or Service Provider.
Use of the services
In this standard a transport service is related to the use of or the presence of a vehicle in an Toll domain. The Toll
domain may be a road network, a specific section of a road (e.g. a bridge, a tunnel or a ferry connection) or a
specific area offering a service (e.g. a country, a region, a parking lot or access to a protected area in a city). This
role is thus identified that it covers all aspects of using the Toll system and the transport service. Implementations
of Toll systems in various domains identify actors in this role that are commonly referred to as, e.g. Driver, Service
User (vehicle) or Customer.
Charging of the toll
The role related to the charging of the toll covers all actors who define the Toll domain, operate the toll system and
may provide transport services. The role includes the related charging infrastructures and who defines the toll and
operates the toll system. Enforcement operators are also part of this role.
Management of the Toll Charging environment
There is also a need for an overall management of the Toll Charging environment defining and organising the
policy that enables the daily operation of the Toll Charging equipment involving several different actors. A specific
role is identified to manage the Toll Charging environment, i.e. defining and maintaining a Set of Rules that, taken
together, defines the policy of a given regime or of the overall Toll Charging environment.
Extension for the purpose of this document
The four roles represent a logical model. This does not prejudice any physical organisation. When coming to real
organisations sub-actors can take over parts of the responsibilities of a role. With respect to pre-payment it is
necessary to introduce the Payment Service Provider (PSP) as sub-actor of the Toll Service Provider.
5.2 Interoperability and Payment
One part of the SU’s contract with the TSP is the definition of the payment mode under which the SU pays the toll
consumed. If the TSP offers different payment modes, the SU has to decide which payment mode he wants to
choose
 central account Post-Pay mode or;
 central account Pre-Pay mode or;
 OBE based Pre-Pay mode.
This can be agreed independently from the toll charger (TC), who has no right to decide on this contractual issue
between TSP and SU.
But, a TC may limit the use of his toll domain to the use of OBEs operated through a central account. This limits
the interoperable use of an OBE based pre-pay mode and has to be clearly communicated to the SU.
6 Classification of Pre-Pay solutions
6.1 Pre-Pay Account held in Central System
The OBE is equipped with a reference to an anonymous account held in the central system of a TSP which
contains a certain amount of value units. This account may be linked to a specific SU, or may be anonymous in the
sense that the stored value units have no link to the person or entity who loaded it into this account.
This account can be credited with value units by the SU in the form of:
 cash paid to a bank account of the TSP;
 cash paid at a point of sale;
 automatic direct debit against the SU’s bank account.
The toll amount due for the usage of a Toll domain is transmitted from the TC to the TSP and there deducted from
the centrally held account. The TSP in turn pays the amount due to the TC.
Advantages:
 the TSP can always see the amount of credit for a given contract/OBE (e.g. not only when the OBE has
contact with the TSP);
 flexibility of operating several OBE from the same central Pre-Pay account;
 easier customer care support by Toll Service Providers in case of low credit (e.g. warning sent to non-
anonymous user), instead of local belated payment procedures or enforcement;
 takes away complexity from the driver;
 loading of credits centrally by money transfer or over the internet possible;
 no extensive international POS-network necessary for Toll Service Providers (no cash handling);
 increases security for the vehicle operator (e.g. no fraud by drivers due to card or cash handling);
 easy handling of differences in case of problems between Toll Service Provider and Toll Charger;
 currency conversion handled between Toll Service Provider and Toll Charger;
 for the Toll Charger the contract presents itself as a Post-Pay contract;
 reduced risk of theft of OBE (no credits on the device).
Disadvantages:
 credits are held centrally and can only be debited at certain intervals (e.g. daily);
 no real time calculation if credit is sufficient for consumption during this intervals;
 negative credit may result out of a propagation delay between transaction and clearing;
 credit not in possession of the SU but stored at Toll Service Provider.
6.2 Pre-Pay Account held on OBE
The OBE is equipped with an anonymous account containing a certain amount of value units (stored value). The
toll amount consumed is calculated and deducted from that on-board account immediately at the time the SU uses
the toll domain(s).
The SU has to care for sufficient value units stored on the OBE before using a toll domain. CEN ISO/TS 25110
describes three technological approaches how to equip an OBE with stored value units and get access to it. The
TR refers to that.
Advantages:
 anonymous solution;
 value units are portable through all systems without communication at borders of toll domains;
 value units are always in the possession of the SU;
 no negative credit needed (unless contractually defined);
 wide variety of payment means acceptable for loading of credits.
Disadvantages:
 amount of credit at a given time is unknown to the Toll Service Provider (e.g. possible problem if OBE fails or
is stolen);
 communication problems may lead to differences between the credit on the OBE and the transactions
registered by the Toll Charger (e.g. not properly terminated transaction which was not registered by the TC as
valid but deducted the amount from the OBE);
 conformity tests for international POS-network needed;
 only one currency on OBE possible, so Toll Charger has to calculate correct fee in target currency of OBE in
real time;
 a real time calculation of the toll amount has to be effected by the TC (e.g. distance based tolling in a complex
layout within a closed system);
 strong requirements on enforcement;
 strong impact of the legislation (e-Money Directive) on the solution;
 accepted payment means may differ at different POS operators.
7 Requirements for Pre-Pay account held in Central Systems
7.1 General
There are different requirements for any universal Pre-Pay system with an account held in the central system of a
Service Provider. The effective credit is always under the control of the TSP and therefore in his safekeeping in the
name of the SU. This leads to several constraints in the view of business process requirements, technical
requirements and functional constraints on how to handle these credits.
7.2 Business Process Requirements
7.2.1 General
The foremost business requirement is that the TSP can comprehensibly prove at any time the current amount of
credit in the central account.
7.2.2 Issuing of an EFC contract to the Service User
Service User considerations
The first act in a universal Pre-Pay system is the issuing of an EFC contract form the Service Provider to the
Service User. In this process the Service User may opt to stay anonymous with the acceptance of all related
disadvantages to him. Some of these disadvantages would be among others:
 no issuing of fiscal invoices to the SU for cash payments to the bank account of the TSP;
 issuing of unnamed invoices to the SU for direct cash payments to the TSP under special conditions with a
limited amount in certain countries;
 limited serviceability of the SU;
 no way of informing the SU about any problems with the account;
 automatic blocking of all associated OBE if the account falls below a certain floor limit;
 enforcement measures by TC(s), if the associated OBE are blocked due to lacking credit;
 return of remaining funds only in conjunction with the return of the associated OBE (no other way of
identification possible).
If the SU opts to be known, the TSP can offer a lot more service to him. Some of these are among others:
 issuing of named invoices to the SU (without limit);
 periodic information on changes of Toll domains the customer is using;
 information of SU in due time before the credit in the account falls below a certain floor limit (thus enabling the
customer to react with a timely payment of additional funds);
 direct debit scheme to automatically hold the account on a certain level (see 7.2.4);
 return of remaining funds to any legitimate representative of the SU.
Distribution channels
The central account has to be endowed with an initial amount at the time of the issuing of the EFC contract,
whether the SU opts to be known or opts to stay anonymous. The initial amount depends mainly on the safety
requirements by the TSP and on the monthly turnover of the SU. It has to be decided between the TSP and SU,
how much the initial endowment has to be.
The issuing of an EFC contract can be done through various channels:
 Point of sale network or central office: The EFC contract can be issued at a point of sale or directly at the
central office of the TSP. After the issuing of the EFC contract the OBE(s) are issued directly to the SU. Either
pre-personalized or personalized OBE(s) can be used. The initial credit has o be paid with any payment
means accepted by the POS operator (e.g. credit card, fleet card, cash …).
 Internet: If the EFC contract is issued through the internet the OBE(s) can be sent physically to the SU or he
receives some kind of registration information (e.g. bar code) to pick the OBE(s) up at a point of sale, an
installation partner or directly at the central office of the TSP. Either pre-personalized or personalized OBEs
can be used through this distribution channel. The initial credit has to be paid with any payment means
accepted by the TSP over the internet (e.g. credit card).
 Reseller: If the EFC contract is issued at a reseller (e.g. super market, fuel station …) only pre-personalized
OBE can be handed out directly by him to the SU. The difference between the reseller and the point of sale is
that he has no equipment for personalisation. In the case of handing out pre-personalized OBE(s) the link
between the OBE(s) and the central account has to be established immediately. Otherwise the issued OBE(s)
may produce toll amounts before sufficient credit is available for the payment.
Otherwise the TSP can also split the process by handling the issuing of the contract at a reseller and
performing the delivery of the OBE(s) himself. The OBE(s) can than be sent to the customer or he receives
some kind of registration information (e.g. bar code) to pick them up at a point of sale, at an installation
partner or at the central office of the TSP. For this option, either pre-personalized or personalized OBEs can
be used.
The initial credit has to be paid with any payment means accepted by the reseller (e.g. cash, bank card, credit
card, fleet card …).
Contractual requirements
Additional corner points of the EFC contract are
 Type of account: Named or anonymous account.
 Number of OBE: The number of OBE to be associated with the central account has to be defined, since it may
have an impact to the associated limits.
 Allowed Toll domains: The SU and the TSP have to agree if the OBE(s) to be issued shall be accepted in all
or, if possible, only in a limited set of Toll domains. This may also have an impact to the associated limits.
 Type of payment: The SU and the TSP have to decide whether the TSP may deduct from the SU’s bank
account or whether the SU takes care of a sufficiently funded account.
 Floor limit: The floor limit is the lowest allowed credit limit on the account. If the credit falls below the floor limit,
the TSP automatically blocks any associated OBE from being accepted in the allowed Toll domains.
 Reload limit: If the credit falls below the reload limit, the TSP automatically triggers a collection from the SU’s
bank account, when they agreed on a direct debit scheme.
 Reload amount: This amount is automatically collected from the SU’s bank account when the credit of a direct
debit enabled account falls below the reload limit. The height of this amount has to be decided between the
SU and the TSP.
 Information limit: If the credit falls below the information limit, the TSP automatically informs the non
anonymous SU to reload his account, when they did not agree on a direct debit scheme.
 Roof limit: If the credit goes above a roof level in a centrally held Pre-Pay account, the surplus amount can be
transferred back to the bank account of the SU. Through this the effects of an erroneous money transfer by
the SU can be limited. The SU and TSP have to agree on the installation of such a roof limit.
7.2.3 Personalisation of OBE
The personalisation of the OBE has to follow the established standards (e.g. EN ISO 14906, EN 15509 …).
Any OBE for a centrally held Pre-Pay account has to be personalized with a Post-Pay contract, because for all Toll
Chargers, this OBE works like having a Post-Pay contract. Since there is no representation of the credit on the
OBE the TC is not required to check against any credit limits.
Apart from the above requirements the personalized OBE has only to fulfil all necessary requirements of the EFC
regimes it is intended for. This may include the personalization of the nationality and license plate of the vehicle
the OBE is intended for, thus limiting the absolute anonymity of the SU.
Pre-personalized OBEs can be used with a centrally held Pre-Pay account, if there is no requirement for the OBE
to contain the nationality and license plate of the vehicle. If this is possible, only the link between the ID of the pre-
personalized OBE and the centrally held account needs to be established before the first use of the OBE.
7.2.4 Loading of value onto an account
7.2.4.1 General
After the initial loading of value units onto a centrally held Pre-Pay account, this has to become a recurrent
process. The periodicity of this depends hugely on the loaded amount and the rate of consumption by the
associated OBE(s). There are several possible solutions to load value units onto the account:
7.2.4.2 Manual cash payment to the account of the TSP:
If the SU opts to stay anonymous or is not in the possession of a bank account, he can make cash payments to a
bank account of the TSP. This typically means a delay of one to three days until the amount is finally credited to
the bank account of the TSP and can be credited to the centrally held Pre-Pay account. For this crediting of the
cash payments it is inevitable, that the SU provides some kind of identification of the centrally held Pre-Pay
account. Some of this identification marks may be:
 account number of the account;
 customer number for the (anonymous) SU;
 OBE ID associated with the account;
 nationality and License plate of one vehicle associated with the account.
If the SU fails to provide a meaningful identification for the payment, the TSP can only store it until the SU
complains the missing credits on his account. The TSP will assume ownership of any unclaimed payments after a
legally acceptable grace period (e.g. 3 years).
In case of a cash payment to the bank account of the TSP, the SU explicitly accepts that the TSP can not issue
any fiscal invoice to him. This may only be a viable solution for the private sector.
7.2.4.3 Manual cash deposit directly to the TSP:
If the SU opts to stay anonymous or is not in the possession of a bank account, he can make cash payments
directly to the TSP. The SU has to be present at a point of sale or at the premises of the TSP to make his cash
deposit. The identification of the central account can be solved directly with the SU present for paying and the
account is credited immediately.
In this case the SU can also collect an unnamed fiscal invoice for his payment. Due to legal constraints in some
countries these unnamed invoices may be limited in their amount and form.
7.2.4.4 Manual money transfer to the account of the TSP:
If the SU does not grant the TSP with a direct debit authorisation for his bank account, he has to manually transfer
any money to a bank account of the TSP. This typically means a delay of one to three days until the amount is
finally credited to the bank account of the TSP and can be credited to the centrally held Pre-Pay account. He may
do this on a regular basis or when he receives any information form the TSP, when his account fell below the
information limit.
For these money transfers it is inevitable, that the SU provides some kind of identification of the centrally held Pre-
Pay account. Some of this identification marks may be:
 account number of the account;
 customer number for the (anonymous) SU;
 OBE ID associated with the account;
 nationality and License plate of one vehicle associated with the account;
 name and contact details of SU.
If the SU fails to provide a meaningful identification for the payment, the TSP can try to transfer the money back to
the sender if he has a valid account number. This may not be the case for every money transfer, since some
payments may be transferred through intermediate banks, which do not include the account details of the original
sender but replace it with their own intermediate account details. If the TSP does not receive a valid account
number of the payer, he may only store the transferred amount until the SU complains the missing credits on his
account. The TSP will assume ownership of any unclaimed payments after a legally acceptable grace period (e.g.
3 years).
7.2.4.5 Automatic direct debit against the SU’s bank account:
If the SU and the TSP decide on a direct debit scheme to load values onto the centrally held Pre-Pay account, the
TSP collects the agreed reload amount after the credit on the account falls below the agreed reload limit. Currently
direct debits are only a national solution. If a TSP wants to use this in a broader sense, he either has to open a
bank account in each country he has customers in or wait for a broad adoption of the SEPA direct debit scheme,
which will start from November 2009.
The result of a collection is immediately seen on the bank account of the TSP and has also to be reflected
immediately on the centrally held Pre-Pay account of the SU. This is the most effective and fastest way to load an
account. If a collection fails out of any reason (e.g. SU’s bank account is not sufficiently credited to allow the
collection of the reload amount, SU’s bank account is closed …), the collected amount will be deducted from the
TSP’s bank account together with some fees typically within one week. The amount of the reload limit has to be
set in a way, that it allows the failing of a collection without leaving the credit on the account below the floor limit. If
this happens, the TSP may even run into a negative credit on his account and thus assuming an unwanted credit
risk for this Pre-Pay account. Even if the account stays positive, it leaves the SU without any possibility to solve
the issue
...