EN 18184:2025

SLOVENSKI STANDARD
01-julij-2025
Finančne storitve - Specifikacija kod QR za mobilne (takojšnje) kreditne prenose v
skladu z zahtevami PSD2
Financial services - Specification of QR codes for mobile initiated (instant) credit
transfers under PSD2 requirements
Finanzdienstleistungen - Spezifikation von QR-Codes für mobil initiierte
(Echtzeit-)Überweisungen gemäß PSD2-Anforderungen
Services financiers - Spécification des codes QR pour les virements (instantanés) initiés
par un mobile
Ta slovenski standard je istoveten z: prEN 18184
ICS:
35.240.40 Uporabniške rešitve IT v IT applications in banking
bančništvu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
prEN 18184
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2025
ICS 35.240.40
English Version
Financial services - Specification of QR codes for mobile
initiated (instant) credit transfers under PSD2
requirements
Finanzdienstleistungen - Spezifikation von QR-Codes
für mobil initiierte (Echtzeit-)Überweisungen gemäß
PSD2-Anforderungen
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 225.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

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, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 18184:2025 E
worldwide for CEN national Members.

prEN 18184:2025 (E)
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Abbreviations . 8
5 Interoperability of MCTs. 9
6 Standardization of QR codes for MCTs. 11
6.1 Introduction . 11
6.2 Minimum data set and QR code format for payee-presented QR codes . 11
6.2.1 Introduction . 11
6.2.2 Minimum data sets . 11
6.3 Minimum data set and QR code format for payer-presented QR codes . 12
6.3.1 Introduction . 12
6.3.2 Minimum data sets . 13
6.4 Standardized format of QR codes for MCTs . 14
6.4.1 Introduction . 14
6.4.2 Assumptions for the development of QR codes for MCTs . 14
6.4.3 QR codes for MCTs . 15
6.5 Coding of the QR code data fields . 16
6.5.1 General . 16
6.5.2 Domain name . 16
6.5.3 Version . 16
6.5.4 Type . 16
6.5.5 MCT service provider ID . 17
6.5.6 Payload . 17
6.5.7 Interoperability . 17
7 Security aspects of QR codes and their data . 17
7.1 General . 17
7.2 Payee-presented QR codes . 18
7.3 Payer-presented QR codes . 18
7.4 Additional security measures . 18
Annex A (informative) Examples of payload data in QR codes for MCTs . 19
Annex B (informative) Examples of process flows for interoperability of MCTs based on QR codes
........................................................................................................................................................................... 22
Annex C (normative) QR code properties and quality assessment . 34
Bibliography . 36

prEN 18184:2025 (E)
European foreword
This document (prEN 18184:2025) has been prepared by Technical Committee CEN/TC 225 “AIDC
technologies”, the secretariat of which is held by TSE.
This document is currently submitted to the CEN Enquiry.
The basis for this document was prepared by the Multi-Stakeholder Group on Mobile Initiated SEPA
(Instant) Credit Transfers, established by the European Payments Council (see
https://www.europeanpaymentscouncil.eu/), called Standardization of QR codes for mobile
initiated SEPA (instant) credit transfers (see EPC024-22v2.10, [5]). The present derived document
has been drafted in accordance to the CEN editorial rules.
prEN 18184:2025 (E)
Introduction
QR codes are one of the proximate technologies that may be used for the data exchange between a payer
and a payee to enable the initiation of an (instant) credit transfer.
This document specifies the QR code formats for both a payer-presented and a payee-presented QR
code. This document uses as a basis the revised Payment Services Directive (P2D2) [12]. The QR codes
have been defined to support the initiation of (instant) credit transfers by the payer (so-called push
payments) for various payment contexts, including person-to-person, person-to-business, business-to-
person and business-to-business payments, including public services.
prEN 18184:2025 (E)
1 Scope
This document provides a specification for QR codes for mobile (instant) credit transfers (MCTs)
whereby the payer uses a mobile device to initiate the payment transaction. The QR code is used to
exchange data between the payer and the payee to enable the initiation of the (instant) credit transfer
by the payer.
This document is applicable to both cases where the QR code is presented by the payee or by the payer.
This document excludes the following from its scope:
— The details of technical requirements and the supporting infrastructure to achieve interoperability
amongst mobile (instant) credit transfer (MCT) service providers;
— The detailed implementation specification of the payload included in the QR code.
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/IEC 18004, Information technology — Automatic identification and data capture techniques — QR
code bar code symbology specification
ISO/IEC 15415, Automatic identification and data capture techniques — Bar code symbol print quality
test specification — Two-dimensional symbols
ISO/IEC 16480, Information technology — Automatic identification and data capture techniques.
Reading and display of ORM by mobile devices
ISO/IEC 19762, Information technology — Automatic identification and data capture (AIDC) techniques
— Harmonized vocabulary
ISO 12812-1, Core banking – Mobile financial services – Part 1: General framework
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 12812-1, ISO/IEC 19762 and
the following apply.
3.1
proxy
pseudonym for the payer or payee uniquely linked to the name and account associated to the payment
instrument
[SOURCE: ISO 12812-1 [7]]
3.2
account servicing payment service provider
ASPSP
PSP providing and maintaining a payment account for a PSU
[SOURCE: ISO 23195: 2021, 3.1.6 [9]]
prEN 18184:2025 (E)
3.3
business identifier code
8- or 11-character ISO code assigned by SWIFT and used to identify a financial institution
[SOURCE: ISO 9362 [6]]
3.4
consumer device
internet capable device used by the consumer (payer) to conduct an (instant) payment
EXAMPLE mobile phone, tablet.
3.5
2D barcode
machine-readable optical label that contains digital information
EXAMPLE QR codes, tag barcodes.
3.6
MCT service provider
mobile financial service provider that offers or facilitates a mobile initiated (instant) credit transfer to
a payer and /or a payee
3.7
hub
infrastructure ensuring connectivity between MCT service providers
3.8
instant
at once, without delay
3.9
instant payment
electronic retail payment solutions available 24/7/365 and resulting in the immediate or close-to-
immediate interbank clearing of the transaction and crediting of the payee’s account with confirmation
to the payer (within seconds of payment initiation)
3.10
MCT payment application
set of modules (application software) and/or data (application data) needed to provide functionality for
an MCT as specified by the MCT service provider in accordance with the rules of the (instant) credit
payment scheme
3.11
merchant-presented data
data provided by the merchant’s POI to the consumer to enable the initiation of an MCT
3.12
payee-presented data
data provided by the payee to the payer to enable the initiation of an MCT
3.13
payee reference party
person/entity on behalf of or in connection with whom the payee receives a payment
prEN 18184:2025 (E)
3.14
payer-presented data
data provided by the payer to the payee to enable the initiation of an MCT
3.15
payload issuer
entity responsible for issuing the payload
3.16
payment transaction
act, initiated by the payer or on his/her behalf or by the payee (beneficiary), of placing, transferring or
withdrawing funds, irrespective of any underlying obligations between the payer and the payee
3.17
payment account
account held in the name of one or more PSUs which is used for the execution of payment transactions
3.18
payment account identifier
PA-ID
unique identifier that is assigned by an ASPSP and references a payment account record hold by a PSU
EXAMPLE IBAN, see [8].
3.19
payment initiation service provider
PISP
third party payment service provider that initiates a payment on behalf of the payer with the payer’s
ASPSP holding the payment account
3.20
payment institution
entity authorized to provide payment services under the applicable regulations
3.21
account servicing payment service provider identifier
ASPSP-ID
unique identifier that is assigned to every payment institution
EXAMPLE BIC, see [6].
3.22
payment request
set of rules and technical elements (including messages) that allow a payee to claim an amount of money
from a payer for a specific transaction
3.23
payment service provider
PSP
entity that provides payment services to a payment service user
EXAMPLE ASPSP, PISP.
prEN 18184:2025 (E)
3.24
payment service user
PSU
natural or legal person making use of a payment service in the capacity of payer, payee, or both
3.25
QR code
two-dimensional barcode as defined in ISO/IEC 18004
3.26
dynamic QR code
QR code which changes for every transaction and is intended for a single usage
3.27
static QR code
QR code which remains unchanged and is intended for repetitive usage
3.28
token
surrogate value for PSU identification and/or transaction data
Note 1 to entry:  If the token is included in the payee- presented data it might be referred to as a payee token and
if the token is included in the payer-presented data it might be referred to as a payer token.
3.29
token service
system comprised of the key functions that facilitate generation and issuance of tokens and maintain
the established mapping of tokens to the related data when requested by the token requestor
3.30
token service provider
TSP
entity that provides a token service
4 Abbreviations
an Alphanumeric
API Application programme interface
ASPSP Account servicing payment service provider
ASPSP-ID Account servicing payment service provider identifier
BIC Business identifier code
CDUVM Consumer device user verification method
CT (Instant) credit transfer
SCT SEPA (instant) credit transfer
IBAN International bank account number
IG Interoperability guidance
IPR Instant Payment Regulation
MCT Mobile initiated (instant) credit transfer
prEN 18184:2025 (E)
MSCT Mobile initiated SEPA (instant) credit transfer
PA-ID Payment account identifier
PISP Payment initiation service provider
POI Point of interaction
POS Point of sale
PSD2 Revised Payment Services Directive
PSP Payment service provider
PSU Payment service user
SEPA Single euro payments area
SWIFT Society for Worldwide Interbank Financial Telecommunication
TSP Token service provider
TTP: Trusted third party
5 Interoperability of MCTs
Mobile initiated (instant) credit transfers (MCTs) are initiated directly (by the payer) or indirectly (by
an MCT service provider at the request of the payer) using a mobile device. MCT solutions are offered
by so-called MCT service providers which are service providers that offer or facilitate a payment service
to a payer/a payee based on an (instant) CT. As an example, an MCT service provider could be an ASPSP,
a PISP or a technical service provider supporting a PSP.
NOTE 1 Regarding MCTs, local regulation can apply. The revised Payment Services Directive (PSD2) [12]
contains provisions on payment systems.
MCTs typically use an MCT payment application or a browser on the payer device to initiate or at least
authenticate and authorize the (instant) CT transaction, besides some features of the payer device such
as the support of a CDUVM (e.g. a mobile code or biometrics on the mobile device), the mobile device
screen to display transaction information, etc. MCTs may involve the provision of a dedicated MCT
payment application for download on the payer’s or the payee’s device or the provision of dedicated
software for the payee’s (e.g. merchant’s) POI.
In this document the following generic 4-corner model is used for the technical interoperability of MCTs.
Hereby it is assumed that both payer and payee are customers of different ASPSPs that are (instant) CT
scheme participants, while the entities assuming the role of MCT service provider are depicted as
separate entities that are different for the payer and the payee. Obviously, if the role of MCT service
provider would be assumed by an ASPSP the model below would simplify. Alternatively, multiple PSPs
(such as a PISP or a collecting PSP on behalf of the merchant) could be involved between the
payer/payee and their respective ASPSP.
NOTE 2 Interoperability models involving a PISP or collecting PSP have for instance been studied in the MSCT
IG [4].
prEN 18184:2025 (E)
Figure 1 — Generic 4-corner interoperability model for MCTs
As depicted in Figure 1, the payer’s MCT service provider is linked to the payer’s ASPSP and the payee’s
MCT service provider may be linked to the payee’s ASPSP (this linkage may include both technical and
contractual aspects).
The MCT ecosystem involves some new stakeholders in the payment value chain, including a so-called
token service provider (TSP) who is a TTP which is involved if tokens are used in MCTs as surrogate
values for MCT related data (including for instance the payee/payer identification data, the payee/payer
PA-ID, the ASPSP-ID, transaction amount or merchant transaction identifier). The TSP manages the
generation and issuance of tokens, and maintains the established mapping of tokens to the related
transaction data. For simplification it is assumed in this document that the role of the TSP is assumed or
is under the control of the MCT service provider (and therefore the TSP is not depicted in the figure
above).
To achieve interoperability for the generic basic 4-corner model, the concept of a “hub” to interconnect
the respective MCT service providers is considered as shown in the figure above. Hereby the term “hub”
is used to indicate an “infrastructure” that enables interconnectivity between MCT service providers but
it is meant to be agnostic to the way it might be implemented – different implementation models may
be possible (centralized or de-centralized (e.g. a direct API)).
EXAMPLE The technical interoperability requirements between MCT service providers involving a “hub”
have been analysed and defined in detail in the MSCT IG [4]. Examples of interoperability process flows can also
be found in Annex B.
One of the technical interoperability aspects for MCTs is the exchange of (transaction) data between the
payer and the payee to enable the initiation of an MCT. The usage of QR codes for this data exchange will
be treated in the next clause.
prEN 18184:2025 (E)
6 Standardization of QR codes for MCTs
6.1 Introduction
This chapter is devoted to MCTs whereby a QR code as defined in ISO/IEC 18004 (see also Annex C) is
used as proximate technology for the data exchange between the payer and the payee to enable the
initiation of an MCT. Hereby two modes may be distinguished:
— MCTs based on payee-presented data: in this mode the data presented refers both to payee
identification data and transaction data;
— MCTs based on payer-presented data: in this mode the data presented refers to payer identification
data.
6.2 Minimum data set and QR code format for payee-presented QR codes
6.2.1 Introduction
This clause considers the exchange of data (payee identification data and transaction data) via a QR code
displayed by the payee (e.g. merchant POI or payee’s mobile device) and read by the payer’s mobile
device. For the purpose of this document, the following three cases with respect to the type of payee-
presented data are considered:
— The payee-presented data includes a “(payee) token”. In this case, a de-tokenisation process needs to
take place such that all the data (payee identification and transaction data) can be derived from the
token and provided to the payer via their MCT service provider. This generally requires the support
of the payee’s MCT service provider (see for example the Information Request/Response messages
in Annex B) prior to the initiation of the MCT transaction.
— The payee-presented data contains a “proxy” for the payee identification data. In this case the data
that is not present in clear but corresponds to the proxy, needs to be provided by the payee’s MCT
service provider upon request from the payer’s MCT service provider prior to the initiation of the
MCT transaction.
— The payee-presented data includes all data in “clear” (e.g. the payee’s name, trade name, the payee’s
PA-ID, the payee’s ASPSP-ID, the transaction amount, the transaction identifier). This enables the
immediate initiation of the MCT transaction.
Next to this data exchanges also an identifier of the payee MCT service provider is needed by the hub
for routing purposes for the exchange of messages between the respective MCT service providers.
Note also that in the last two cases described above, appropriate security measures need to be taken to
ensure the integrity of the data and the confidentiality as appropriate (see Clause 7 and [10]).
To achieve interoperability within an (instant) MCT scheme or framework, the payee MCT service
provider should support at least one of the types while the payer’s MCT service provider should be able
to support all types as specified by the MCT interoperability scheme or framework.
6.2.2 Minimum data sets
The minimum data set to be exchanged between the payee and the payer, will rely on the MCT
transaction feature, as described above:
a) If the payee-presented data provided to the payer contains a (payee) token, the minimum data will
consist of at least the routing info and the token as payload. The minimum data will be forwarded in
a transaction information request message through the hub from the payer’s MCT service provider
to the payee’s MCT service provider for de-tokenisation into transaction data (see Annex B.2).
prEN 18184:2025 (E)
b) If the payee-presented data provided to the payer contains only part of the transaction data in clear
but contains a proxy for the payee data, the data related to the proxy will need to be provided by the
payee’s MCT service provider. The minimum data set will consist of both routing info, the proxy and
the available transaction data in clear. The proxy will be forwarded in a transaction information
request message through the hub from the payer’s MCT service provider to the payee’s MCT service
provider for completion of the transaction data.
c) If the payee-presented data provided to the payer contains all transaction data “in clear”, the
minimum data set will consist of both routing info and all necessary payload data in clear.
Therefore, the minimum data sets for the payee-presented QR code, covering the three cases described
above are as follows:
Table 1 — Payee-presented QR code
Payee-presented QR code
Payee-presented QR code includes a token:
[Version]+[Type]+ [Payee MCT Service Provider ID] + [(payee) token] + [a clear-text name/value
string]
Payee-presented QR code contains a proxy for the payee:
[Version]+[Type]+ [Payee MCT Service Provider ID] + [proxy] + [a clear-text name/value string]
Payee-presented QR code includes all transaction data “in clear”:
[Version]+[Type]+ [Payee MCT Service Provider ID] + [a clear-text name/value string]
NOTE 1 The clear-text name/value string in the first QR code format defined above can be void.
NOTE 2 A combination of these different formats can appear in a single QR code to enable the payee (e.g. the
merchant) to support multiple MCT schemes through a single QR code having multiple payloads (see also 6.5.7).
The reader is referred to 6.4 for an explanation of the “Version” and “Type” in the Table 1.
6.3 Minimum data set and QR code format for payer-presented QR codes
6.3.1 Introduction
This clause considers the exchange of data via a QR-code displayed by the payer (e.g. on the payer’s
mobile device) and read by the payee (e.g. merchant POI or payee’s mobile device). For the purpose of
this document, the following three cases with respect to the type of payer-presented (identification)
data are considered:
— The payer-presented data includes a “(payer) token”. In this case, a de-tokenisation process needs to
take place such that all the payer identification data) can be derived from the token and provided
to the payee via their MCT service provider. This generally requires the support of the payer’s MCT
service provider (see for example the payment request messages in Clause B.3) prior to the
initiation of the MCT transaction.
prEN 18184:2025 (E)
— The payer-presented data contains a “proxy” as (part) of the payer identification data. In this case the
data that is not present in clear but corresponds to the proxy, needs to be provided by the payer’s
MCT service provider upon request from the payee’s MCT service provider prior to the initiation of
the MCT transaction (via a payment request sent by the payee’s MCT service provider).
— The payer-presented data includes all data in “clear” (e.g. the payer’s name, the payer’s IBAN, the
payer’s ASPSP-ID). This enables the immediate initiation of the MCT transaction (via a Payment
Request sent by the payee’s MCT service provider).
Next to this data exchanges also an identifier of the payer MCT service provider is needed by the hub for
routing purposes for the exchange of messages between the respective MCT service providers.
Note also that in the last two cases described above, appropriate security measures need to be taken to
ensure the integrity of the data and the confidentiality as appropriate (see Clause 7 and [10]).
To achieve interoperability within an (instant) MCT scheme or framework, the payer MCT service
provider should support at least one of the types while the payee’s MCT service provider should be able
to support all types as specified by the MCT interoperability scheme or framework.
6.3.2 Minimum data sets
The minimum data set to be exchanged between the payer and the payee, will rely on the MCT
transaction feature, as described above:
d) If the payer-presented data provided to the payee contains a (payer) token, the minimum data will
consist of at least the routing info and the token as payload. The minimum data will be forwarded in
a payment request message through the hub from the payee’s MCT service provider to the payer’s
MCT service provider for de-tokenisation into the payer identification data (see Annex B.3).
e) If the payer-presented data provided to the payee contains only part of the payer identification data
in clear but contains a proxy for the payer data, the data related to the proxy will need to be provided
by the payer’s MCT service provider. The minimum data set will consist of the routing info, the proxy
and the available transaction data in clear. The proxy will be forwarded in a payment request
message through the hub from the payee’s MCT service provider to the payer’s MCT service provider
for completion of the payer identification data and the initiation of the MCT transaction.
f) If the payee-presented data provided to the payer contains all transaction data “in clear”, the
minimum data set will consist of both the routing info and all necessary payload data in clear. The
minimum data will be forwarded in a Payment Request message through the hub from the payee’s
MCT service provider to the payer’s MCT service provider for the initiation of the MCT transaction.
Therefore, the minimum data sets for the payer-presented QR code, covering the three cases described
above are as follows:
Table 2 — Payer-presented QR code
Payer-presented QR code
Payer-presented QR code includes a token:
[Version]+[Type]+ [Payer MCT Service Provider ID] + [(payer) token] + [a clear-text name/value
string]
Payer-presented QR code contains a proxy for the payer:
prEN 18184:2025 (E)
Payer-presented QR code
[Version]+[Type]+ [Payer MCT Service Provider ID] + [proxy] + [a clear-text name/value string]
Payer-presented QR code includes all transaction data “in clear”:
[Version]+[Type]+ [Payer MCT Service Provider ID] + [a clear-text name/value string]
NOTE The clear-text name/value string in the in the first QR code format defined above can be void.
The reader is referred to 6.4 for an explanation of the “Version” and “Type” in the Table 2.
6.4 Standardized format of QR codes for MCTs
6.4.1 Introduction
To enable MCT interoperability for the data exchange between the payee and the payer, MCT QR codes
formats need to be standardized based on the minimum data sets defined in the clauses.
The choice of which QR-codes and for each QR-code, which options as defined in 6.2 and 6.3 will be
supported, is left at the discretion of a given MCT interoperability framework or scheme and shall be
based on an appropriate risk and security analysis (see Clause 7).
6.4.2 Assumptions for the development of QR codes for MCTs
For the development of a standardized QR code for MCTs, based on ISO/IEC 18004, the following four
assumptions are followed:
— Mobile wallets will often support multiple payment instruments. The wallet user will often select
or set a default payment instrument;
— Payees (e.g. merchants) may often support multiple payment instruments and brands. The payee
could set a preferred (prioritised) payment brand for MCTs based on a payee-presented QR code;
— Need to avoid any special actions from merchant personnel at P
...