TAXATION AND CUSTOMS UNION PDF
Content
1
EUROPEAN COMMISSION
DIRECTORATE-GENERAL
TAXATION AND CUSTOMS UNION
Indirect Taxation and Tax Administration
Tax administration and fight against tax fraud
Guidelines for the reporting of payment data from
payment service providers and transmission to the
Central Electronic System of Payment information
(CESOP)
Disclaimer: These guidelines are not legally binding and only contain practical and informal guidance
about how EU law should be applied on the basis of the views of the Commission’s Directorate-General
for Taxation and Customs Union.
2
These Guidelines aim at providing a better understanding of certain parts of the EU VAT
legislation. They have been prepared by the Commission Services in collaboration with Member
States and payment service providers and, as indicated in the disclaimer on the first page, they
are not legally binding.
These Guidelines are not exhaustive. This means that although they provide detailed
information on a number of issues, there might be elements that are not included in this
document.
It is advisable and recommended for any user of the Guidelines, interested in a particular topic,
to read the whole chapter which is dealing with that specific subject.
Please note that this is an explanatory document which is intended only to assist in the
implementation of CESOP by stakeholders. Should there be any conflict or specific ambiguities
between these Guidelines and EU and national legislation, the legislative provisions should be
referred to and will take precedence.
3
Table of Contents
1 Introduction ....................................................................................................................................... 6
2 Scope of the reporting obligation ...................................................................................................... 7
2.1 The entities in scope ...................................................................................................................... 7
2.1.1 Territorial scope – the situation of European Economic Area countries and Northern
Ireland ................................................................................................................................ 9
2.2 Payments in scope ....................................................................................................................... 10
2.2.1 Credit transfer .................................................................................................................. 13
2.2.2 Direct Debit ..................................................................................................................... 14
2.2.3 Money remittance ............................................................................................................ 15
2.2.4 Card Payment .................................................................................................................. 16
2.2.5 Electronic money ............................................................................................................. 21
2.2.6 The case of marketplaces and intermediaries collecting funds in their own name ......... 25
2.3 The payment services in scope .................................................................................................... 27
2.3.1 Payment methods with limited use – vouchers ............................................................... 27
2.3.2 Vouchers and refund ....................................................................................................... 28
2.3.3 The use of vouchers together with in-scope payment methods ....................................... 29
2.4 Practical application per payment method .................................................................................. 31
2.4.1 Credit transfer .................................................................................................................. 31
2.4.2 Direct Debit ..................................................................................................................... 31
2.4.3 Money remittance ............................................................................................................ 32
2.4.4 Card payments ................................................................................................................. 33
2.4.5 E-money .......................................................................................................................... 34
2.4.6 Marketplace ..................................................................................................................... 36
3 Monitoring and triggering of the reporting obligation .................................................................... 37
3.1 Cross-border payments - Location rules of Article 243c ............................................................ 37
3.1.1 Table of identifiers to determine the location of the payer and payee ............................ 38
4
3.1.2 Practical application ........................................................................................................ 39
3.2 Threshold of 25 cross-border payments under Article 243b (2) ................................................. 47
3.2.1 The basic rule – Calculation of cross-border payments per identifier ............................ 48
3.2.2 The additional rule – Aggregation of cross-border payments per payee ........................ 48
3.2.3 Practical application ........................................................................................................ 50
4 Reporting ......................................................................................................................................... 57
4.1 What triggers the reporting obligation? ...................................................................................... 57
4.2 How often shall the data be reported? ......................................................................................... 58
4.3 Who shall report the data under Article 243b(3)? ....................................................................... 59
4.3.1 Practical application ........................................................................................................ 60
4.3.2 The situation of EEA countries ....................................................................................... 63
4.4 Where should the data be reported? ............................................................................................ 64
4.4.1 Direct provision of payment services in the host Member States ................................... 65
4.4.2 The situation of EEA countries (Iceland, Liechtenstein, Norway) ................................. 65
4.5 What data should be reported by payment service providers? .................................................... 66
4.5.1 Overview of data elements .............................................................................................. 67
4.5.2 Data to be reported per payment method ........................................................................ 73
4.5.3 Data quality aspects ......................................................................................................... 83
5 Rules for (re)submission ................................................................................................................. 86
5.1 Validation of the payment information at the national level ....................................................... 86
5.2 Validation of the payment information at the CESOP level ....................................................... 86
5.3 Resubmissions ............................................................................................................................. 87
5.4 Spontaneously correcting mistakes ............................................................................................. 88
6 Reporting same payee with several transactions............................................................................. 88
7 Final remarks................................................................................................................................... 90
5
Version Date Description
1.0 3 August 2022 Version approved for publication
1.1 23 November 2023 Revised version approved for publication
1.2 18 June 2025 Revised version approved for publication
6
1 INTRODUCTION
On 18 February 2020, the Council adopted a legislative package to collect payment data in order to
improve the fight against e-commerce VAT fraud. The package is composed of two legal texts:
- Council Directive (EU) 2020/284 of 18 February 2020 amending Directive 2006/112/EC as
regards introducing certain requirements for payment service providers1 and:
- Council Regulation (EU) 2020/283 of 18 February 2020 amending Regulation (EU) No
904/2010 as regards measures to strengthen administrative cooperation in order to combat VAT
fraud2.
The new rules will enter into force on 1 st January 2024. The amendments to Directive 2006/112/EC 3
(“the VAT Directive”) create a new reporting obligation for payment service providers established in
the European Union (“EU”) to keep records of the payment s they process and their beneficiaries
(“payees”), while the amendments to Regulation (EU) 904/2010 focus on the development of the Central
Electronic System of Payment information (“CESOP”) , where the data collected will be stored and
processed before being put at the disposal of Member States anti-fraud experts to fight VAT fraud.
The use of payment data is driven by the need to improve the fight against e -commerce VAT fraud,
which is made particularly difficult due to the lack of physical presence of sellers in Member States of
consumption. The use of internet and new technologies has allowed companies to sell goods abroad
without the need to set-up any kind of physical presence. This in turn can make it difficult for Member
States to perform controls as they are dependent on the goodwill o f foreign sellers to declare their
transactions in order to know that they are being active in their territory. Even in the cases where a
Member State is aware that sellers on a website are supplying goods or services in their territory, it can
be extremely difficult to identify the actual seller behind the website. This lack of information makes it
extremely difficult for Member States to request or exchange information with each other as they do not
know with who they should share the information, or to who they should ask for it.
As of 2024, the use of payment data and CESOP will provide anti-fraud experts in Member States with
the information needed to identify sellers abroad that supply goods or services on their territory. The
system is designed to limit the administrative burden on payment service pro viders by collecting data
via a harmonised standard form and restricting the data collected to what is necessary to identify the
sellers and combat e-commerce VAT fraud. No data on the buyer (“payer”) shall be collected, apart from
the estimated Member State of origin of the payment, and data on the seller shall only be collected if it
receives a substantial amount of cross-border payments.
The present guidelines have been drafted in collaboration with experts from the payment sector and
Member States and focus on explaining the rules governing the reporting of payment information. They
detail the scope of the reporting obligation, present the main payment methods currently used in the
European Union to pay for goods and service online , explain what the triggers of the reporting
obligations are and attempt to list the data elements used by payment service providers which could be
reported to CESOP. They are addressed to both payment service providers who will have to report data
under the new reporting obligations, and Member States who will have to collect the data and transmit
1 Council Directive (EU) 2020/284 of 18 February 2020 amending Directive 2006/112/EC as regards introducing certain
requirements for payment service providers (OJ L 62, 2.3.2020, p. 7)
2 Council Regulation (EU) 2020/283 of 18 February 2020 amending Regulation (EU) No 904/2010 as regards measures to
strengthen administrative cooperation in order to combat VAT fraud (OJ L 62, 2.3.2020, p. 1)
3 Council Directive 2006/112/EC of 28 November 2006 on the common system of value added tax (OJ L 347, 11.12.2006,
p. 1).
7
it to CESOP. They remain however an explanatory document with no legal value. In the case of any
ambiguity, the legal definitions and principles take precedence.
2 SCOPE OF THE REPORTING OBLIGATION
This section focus es on defining the scope of the reporting obligation laid down in Article 243b of
Directive 2006/112/EC as introduced by Council Directive (EU) 2020/284 (“CESOP reporting”).
Article 243b (1) lays down the rules of the reporting obligation:
Member States shall require payment service providers to keep sufficiently detailed records of payees
and of payments in relation to the payment services they provide for each calendar quarter to enable
the competent authorities of the Member States to carry out controls of the supplies of goods and
services which, in accordance with the provisions of Title V, are deemed to take place in a Member
State, in order to achieve the objective of combating VAT fraud.
The requirement referred to in the first subparagraph shall apply only to payment services provided
as regards cross-border payments. A payment shall be considered a cross -border payment when the
payer is located in a Member State and the payee is located in another Member State, in a third
territory or in a third country.
According to this Article, there are three requirements that must apply to trigger the reporting obligation
of a payment service provider (reporting entity):
1. The reporting entity must be a payment service provider as defined in Article 243a (1) of
Directive 2006/112/EC.
2. The reporting entity must provide payment services as defined in Article 243a (2) of Directive
2006/112/EC.
3. The reporting entity must be involved in processing a payment as defined in Article 243a (3) of
Directive 2006/112/EC, between a payer and a payee, where the payer is located in a Member
State and the payee is located in another Member State, in a third territory or in a third country.
These three conditions form the essence of the scope of the reporting obligation and will be detailed in
this section, each one answering one of the following questions:
2.1. What are the entities in scope?
2.2. What are the payments in scope?
2.3. What are the payment services in scope?
In addition to these three elements, two additional conditions are required to trigger the reporting
obligation, the first of which is laid down in Article 243b (1), 2nd subparagraph and requires that the
payments reported are cross-border, while the second is laid down in Article 243b (2) and requires that
the payment service provider executes more than 25 cross-border payments per quarter to a given payee
before transmitting any information. These two conditions to be monitored are detailed in section 3.
2.1 The entities in scope
The reporting obligation is only applicable to the payment service providers defined in Article 243a and
which provide payment services in the European Union. Payment service providers which do not provide
payment services in the European Union do not have to fulfil any reporting obligation.
8
As regards the definition of what a payment service provider is, Article 243a refers to the definitions
laid down in Directive (EU) 2015/23664 (“PSD2”). However, not all payment service providers covered
by the PSD2 are automatically subject to the CESOP reporting obligation. Indeed, Article 243a limits
the scope of the reporting obligation to the following four categories of payment service providers:
a) Credit institutions , which covers e.g. fully licensed banks established in Europe as well as
European branches of credit institution s that have their head office outside the EU and which
provide payment services.
b) E-money institutions, which cover s all payment service providers providing payment services
via electronic money (“ E-money”) e.g. electronic wallet providers and electronic voucher/card
providers.
c) Payment institutions, which is a residual category that can cover all companies providing
payment services that do not qualify for any of the other categories listed in the PSD2. It can
include companies that provide payment services such as issuing of credit/debit cards, acquiring
of payment transaction, processing of payments, initiation of payments, platforms, which provide
payment services and act on behalf of both the payer and payee, etc.
a) Post-office giro institutions which provide payment services.
The PSD2 adds to this list central banks and public bodies, however those entities are not in scope of the
reporting obligation for CESOP as they typically do not provide the payment services in scope (see
section 2.3.).
N.B.: the exemption for small payment service providers laid down in Article 32 of the PSD2 is not
applicable to the CESOP reporting obligation. As such, even small payment services providers will
have to report data on payments and payees if all other conditions are fulfilled.
Although the definition of payment service provider s is quite broad and cover s most of the payment
market, it must be read in conjunction with the rules applicable to the payment services in scope. Indeed,
not all payment services are in scope of the reporting obligation . As such, it is possible that an entity
qualifies as a payment service provider under the definition of Article 243a (1) of Directive 2006/112/EC
but does not provide any of the payment services referred to in Article 243a (2). If that is the case, this
payment service provider will not be subject to the reporting obligation. A good example of that is the
situation of payment initiators which are payment institution s but do not provide any of the payment
services in scope (see point 2.3.).
Article 3 (b) of the PSD2 also establishes a special rule which excludes from its scope payments done
either via a commercial agent or via commercial agents who acts only on be half of the payer or the
payee. This implies that payments done either via commercial agents who act on behalf of both the payer
and the payee would be in scope of the PSD2. Thi s is confirmed in recital 11 to the PSD2 which states
that commercial agents who act on behalf of both the payer and the payee must be registered as payment
service providers if they hold funds on behalf of both their clients. This rule is especially important in e-
commerce since it implies that online platforms and marketplaces who hold funds on behalf of their
clients must register as payment service providers (either as payment institution or other categories based
on the service they provide) and will be in scope of the reporting obligation. As such, marketplaces
4 Directive (EU) 2015/2366 of the European Parliament and of the Council of 25 November 2015 on payment services in
the internal market, amending Directives 2002/65/EC, 2009/110/EC and 2013/36/EU and Regulation (EU) No
1093/2010, and repealing Directive 2007/64/EC (Text with EEA relevance) (OJ L 337, 23.12.2015, p. 35).
9
which collect funds from the payer, hold them and then distribute them to the payee will have to report
information on the payee to CESOP.
2.1.1 Territorial scope – the situation of Euro pean Economic Area countries
and Northern Ireland
The rules of the PSD2 are applicable to all European Economic Area (“EEA”) countries, which includes
all Member States of the European Union as well as Iceland, Liechtenstein and Norway. This means that
payment service providers wishing to provide payment services in the EEA must obtain a payment
license in their country and respect the other requirements of the Directive if they want to use this license
in another country.
Once a payment service provider from an EEA country has obtained a payment license in its country of
establishment, it will be able to provide payment service in any Member States using the PSD2
passporting rules. These rules allow payment services provider s that have received a payment license
under the PSD2 to supply payment services to any other country of the EEA without the need to request
a new payment license in this country. Instead, the payment service provider will only need to inform
the other countries of its intention to supply payment services on their territory, which can be done either
via a physical presence (for example a branch), the use of a commercial agent, or directly from its country
of establishment via the freedom to provide services.
This means that payment service providers from EEA countries can also be in scope of the reporting
obligation created for CESOP when they provide payment services in a Member State , even without a
physical presence in the European Union.
For more details on how reporting will take place for EEA countries see section 4.4.2
N.B.: although Northern Ireland is part of the EU VAT area as part of the Brexit agreement and its
protocol, the scope of the reporting obligation created by Directive 284/2020 is not subject to any
special arrangements with regard to Northern Ireland and Brexit. As such, payees and payment
service providers established in Northern Ireland must be understood as being established in a third
country (and should be reported as such) for the sake of the CESOP reporting obligation.
10
2.2 Payments in scope
The concept of payment is at the centre of the reporting obligation as it encompass es exactly the
information that payment service providers will have to keep in their records. The concept of payment
is closely linked to the definition of “payment transactions” laid down in Article 4 (5) of the PSD25 but
also covers money remittances as defined in Article 4 (22) of the PSD26.
In simple terms, a payment corresponds to a transfer of funds from a payer (the initiator) to a payee (the
beneficiary). The definition of payer and payee are also laid down in Article 243a which directly
references the definition of the PSD2.
The payer is “a natural or legal person who holds a payment account and allows a payment order from
that payment account, or, where there is no payment account, a natural or legal person who gives a
payment order” . The payer is thus the one whose funds are being transferred in execution of the
payment. Although most of the time the payer will also be the initiator of the payment, in the case of
direct debit the payee will initiate the payment following the authorisation granted by the payer in the
direct debit mandate.
The payee on the other hand is “a natural or legal person who is the intended recipient of funds which
have been the subject of a payment transaction ”. The payee is thus the beneficiary of the funds
transferred in execution of the payment. One of the key elements when it comes to the payee is the idea
of “intended recipient”. Payment processing often involve s a multitude of actors and business model s,
and it is not uncommon that when funds are being transferred, they are first passed among various
payment service providers who can retain these funds for a certain period of time before transferring
them to the payee. These payment service providers must not be confused with the payee as they are not
the intended recipient of the payment from the payer but mere intermediaries. As such, the information
that needs to be reported must regard the payee and not the intermediaries. However, since payment
service providers rely on the information provided in the payment request, there are situations where an
intermediary will appear as the beneficiary of the payment. These situations are detailed further in point
2.2.6.
As such, the payment s to be reported to CESOP correspond to the transfer of funds from a natural or
legal person whose funds are being transferred, to a natural or legal person who is the intended recipient
of these funds.
N.B.: under Article 243b, only payment that are initiated by a payer in the European Union are in
scope of the reporting obligation. The payee on the other hand can be located in another Member
States, a third territory or a third country.
In practice, this means that the payment in scope includes:
- payments from a payer in a Member State to a payee in another Member States (to be reported
by the payee’s payment service provider see section 4.3).
- payments from a payer in a Member State to a payee in a third territory or third country (to
be reported by the payer’s payment service provider see section 4.3).
5 ‘Payment transaction’ means an act, initiated by the payer or on his behalf or by the pay ee, of placing, transferring or
withdrawing funds, irrespective of any underlying obligations between the payer and the payee .
6 ‘Money remittance’ means a payment service where funds are received from a payer, without any payment accounts
being created in the name of the payer or the payee, for the sole purpose of transferring a corresponding amount to a
payee or to another payme nt service provider acting on behalf of the payee, and/or where such funds are received on
behalf of and made available to the payee.
11
On the other hand, payments from a payer which is not in a Member States to a payee in a Member
State are out of scope of the reporting obligation.
Although this definition can seem easy to comprehend, it must be pointed out that a payment between a
buyer (payer) and a seller (payee) of goods or services often involves a multitude of payment services
providers on both sides of the payment chain which all exchange information and transfer funds between
each other in order to execute the payment between the buyer and the seller. The figure below illustrates
this complexity using the example of a credit transfer.
Figure 1 – Overview of a credit transfer payment
The figure highlights four different types of flows in order to execute a single payment between the
buyer (payer) and the seller (payee):
− The service flow correspond s to the various services that are provided by the different actors.
The payer’s and payee’s banks provide payment services to their client while the clearing house
provides clearing services to both payment service providers.
− The money flow corresponds to the movement of funds between the various actors. Indeed, the
transfer of funds between the payer and the payee does not take the form of a single movement
from one to the other, but instead correspond to a series of exchanges where the paye r’s bank
will first take the fund s from the payer’s account before transferring them to the payee’s bank
which will credit the payee’s account.
− The information flow corresponds to the exchange of information between the various actors in
order to authorise, process and execute a payment. The payer will provide its payment service
provider with information on the payee and the amount it wishes to transfer. Its bank will then
use this information to identify the payee’s bank and determine where it must send the funds.
With the use of modern technology, these processes are almost immediate nowadays.
− The settlement information flow corresponds to the exchange of information between payment
service providers and/or clearing house in order to proceed to the clearing and settlement between
the actors. This flow is completely distinct from the payment between the payer and the payee
12
and focuses on allowing the payment service providers involved in the payment to exchange the
information and/or settle the debt created between themselves in execution of the payment.
All these various flow s can cover one or several payment(s), however only the information flow will
provide the relevant information on the payment between the payer and the payee. In that regard, one of
the key stages of the information flow is the so-called “authorisation process” where a payment service
provider will send information on the payment to the other payment service provider for the second to
validate the details of the payment and confirm that the payment can take place. In modern days, this
authorisation process takes place in a matter of seconds after the initiation of the payment and contains
most of the data required under the CESOP reporting.
Even though the information has been recorded already, payment service providers do not transfer funds
between each other at each payment transaction request, as this would imply enormous computing
process between themselves for each of the millions payment transactions that are processed every day.
To facilitate their activities, most payment service provider s consolidate payment transaction s over a
period of time that can be more or less extensive and only transfer the funds between themselves at the
end of this period, taking into consideration the amount they owe to another payment service provider
and the amount this payment service provider owes them. This periodic transfer of funds between
payment service providers is generally referred to as “settlement”.
This is why the reporting obligation for CESOP is based on the information flow and the exchange of
data between payment service providers (which is nearly instantaneous and includes information on the
payer and the payee at transaction level) and not on the actual flow of money between themselves (which
is done periodically using aggregated amounts of all payments authorised for a certain period).
The following sections will detail , for each of the main payment methods currently in scope of the
reporting obligation, how they function, who the actors involved are, and how the information flow takes
place. The examples provided here are not exhaustive as existing payment methods can evolve and vary
and new payment methods could be developed in the future.
13
2.2.1 Credit transfer
Figure 2 – Functioning of a credit transfer payment
Credit transfer forms one of the oldest and most common form of transferring funds. All cross -border
credit transfers in the European Union follow the rules established by the SEPA regulation and the
schemes developed by the European Payment Council.
Credit transfer generally involve 3 different actors to process the payment:
- The payer’s bank which holds the payer’s payment account where the funds will be taken from.
- The payee’s bank which holds the payee’s payment account which will receive the funds.
- The payment system which provides clearing and/or settlement services to the banks in order to
help them clear and/or settle the debt created by the various transfer of funds they execute.
Alternatively, payment service providers might exchange payments and settle the debt directly
or through other intermediaries.
In the figure, the information flow is highlighted by the blue numbers and takes place as follows:
1. The payer will initiate the payment order by providing the payee’s details to its bank and
requesting it to transfer a certain amount of funds to the payee’s bank account.
2. The payer’s bank will use the information provided by the payer to carry out a credit transfer.
The payer’s bank will then provide the information provided by the payer to the payee’s payment
service provider to credit the funds to the bank accounts of the payee.
3. The payee’s bank will verify the information provided by the payer’s bank in the credit transfer
request (e.g. that the bank account exist).
Once these steps are concluded, both the payer’s and payee’s banks have exchanged all the information
necessary to execute the payment and hold almost all the mandatory information required under Article
243d (for details on the information to provide, see section 4.5).
14
It is important to note that while the payment transaction can already be considered completed and
recorded in the payment service providers records at the end of step 3, no actual transfer of funds has
occurred between any of the payment services providers involved. The transfer of funds only occur s at
a later stage which corresponds to the settlement and flow of money between the actors.
This settlement will take place as follows:
4. The payer’s bank will debit the payer’s bank account by the amount that has to be transferred to
the payee.
5. The payee’s bank on the other side will credit the amount of the payment transaction in the
payee’s account immediately after that amount is credited to the payee’s payment service
provider, so that the payee receive s the funds in the required timeline ( typically 1 business day
for EU credit transfers).
While the payment transaction between the payer and the payee requires that the payer transfers funds
to the payee, it is actually possible that when both entities settle their debt at a later stage, the payee’s
bank is the one with a negative balance which will need to be paid to the payer’s bank, if it has executed
more transactions in favour of the payer’s bank than it has received from it. This show s the importance
of differentiating the exchange of data between the payer’s bank and the payee’s bank which relates
directly to the payment transaction between the payer and the payee, from the exchange of funds between
the two payment services providers w hich relates to their own activities and is not in scope of the
reporting (as it is excluded from the definition of payments following Article 3 (m) of the PSD2).
2.2.2 Direct Debit
Direct debits are mainly subject to the SEPA regulation. However, there are no international schemes
currently in place for non-SEPA direct debit. As such, these situation s remain rare in the practice and
payment service providers will generally adopt specific rules between themselves for such transactions,
which are often based on national practices or the SEPA rules themselves.
The presentation of direct debit that is done here is based on the SEPA rules.
Figure 3 – Functioning of a direct debit payment.
15
The actors in direct debits are the exact same as for credit transfers (see point 2.2.1.).
The main difference between direct debits and credit transfers lies in the fact that direct debit s will be
initiated by the payee, on the basis of a mandate granted by the payer . They will not be initiated by the
payer.
In the figure, the information flow takes place as follows:
1. Based on the mandate previously granted by the payer, the payee will initiate a series of direct
debit requests to transfer funds from the payer’s account to its account.
2. The payee’s payment service provider will create the request and send it to the payer’s payment
service provider for execution.
3. The payer’s payment service provider will check that funds are available and that the details of
the request are correct. If so, the payer’s payment service provider will debit the direct debit
transaction at the due date.
These steps already include almost all the mandatory data to be reported to CESOP. They are then
followed by the settlement phase where funds are effectively moved between the payment service
providers (similar to credit transfers):
4. On the due date, the payer’ payment service provider will debit the payer’s account of the funds
to be transferred.
5. The payee’s payment service provider will credit the payee’s account with the amount of the
payment transaction in the payee’s account immediately after that amount is credited to the
payee’s payment service provider, so that the payee receives the funds in the required timeline.
As for credit transfers, the exchanges of funds between payment service providers in execution of the
settlement constitutes a separate operation for their own activities which is out of scope of reporting
obligation.
2.2.3 Money remittance
Money remittance is one of the oldest forms of transferring funds between people. Nowadays, this
payment method has been supplanted by other methods such as credit transfer which offer s similar
functionalities at a reduced cost and faster execution. In the EU, this payment method is mainly used for
so called “friend & family” payments between citizens sending funds abroad. However, it is still used
commercially in other countries and is as such within the scope of the reporting obligation.
One particularity of money remittances compared to other forms of payments is the possibility to transfer
funds without an existing payment account for the payee. Although modern remittances sometimes offer
the possibilities to send funds directly to a bank account, it is still possible to send funds abroad via
money remittance without the need to introduce the payee’s payment account details. This particularity
justifies the introduction of Article 243d (1)(e) in Directive 2006/112/EC, which requires that the BIC
or other unique identifier of the payment service provider acting on behalf of the payee ( the
“disbursement partner”) be transmitted when there is no payment account of the payee. This information
allows the system to identify who is the entity receiving the funds on behalf of the payee.
Money Remittances generally involve two entities:
16
- The money remittance institution which will be used by the payer to transfer funds to the payee.
- The disbursement partner, which is a second money remittance institution who will receive the
funds and make them available to the payee.
Figure 4 – Functioning of a money remittance payment.
In the figure, the information flow is highlighted by the blue numbers and takes place as follows:
1. The payer will initiate a money remittance request by providing its payment service provider
with the details of the payee and the transaction.
2. The payment service provider of the payer (money remittance institution) will create the
transaction and forward it to the disbursement partner in another MS or third country or territory.
3. The disbursement partner ( payment service provider of the payee) will check the data in the
request and validate it if correct.
4. The disbursement partner will put the money at the disposal of the payee.
2.2.4 Card Payment
Card payments are probably the most used form of payment for e-commerce transactions in Europe.
Although they are also subject to legislative oversight, the details of the rules applicable to the exchanges
of data for processing card payments are laid down in the various rulebooks establish ed by the card
scheme providers. Although each scheme provider is free to establish its own rules, the market is still
highly standardised via the use of different standards, such as the “Volume”7, a document drafted by the
European Cards Stakeholder Association , which lays down the rules applicable for the exchange of
7 https://www.e-csg.eu/scs-volume-v9
17
information between the payment service providers involved in card payments within the SEPA area, or
the EMVco standards8.
The processing of card payments generally involves three main actors:
− The card scheme provider establishes the rulebook applicable to the card. The card scheme
provider can be a payment service provider if it distributes the cards itself or provide s other
payment services linked to the card (such as acquiring payment transaction s). This is typically
the case in a 3-party card scheme where the card scheme provider will act as both the card issuer
and the commercial acquirer. On the other hand, 4 -party card schemes typically imply that the
card scheme provider will not provide any payment services and as such will not be a payment
service provider.
− The card issuer is the payment service provider responsible for providing the payment card (debit
or credit card) to the payer and executing payment transactions on his behalf.
− The commercial acquirer is the payment service provider responsible for acquiring the various
payment transaction s on behalf of the payee. A commercial acquirer will aggregate all the
payment transactions executed over a period of time and send the consolidate d amount to the
payee on a regular basis.
Technical service provider s are entities contracted by card acquirer s or merchants to provide services
necessary for the processing of card payments. One of the most important services is the provision of a
terminal or dedicated webpage which can capture the card details and initiate the payment process
(payment initiator). It is important to note that such technical service providers are out of scope of the
PSD2 based on Article 3 (j) as long as they do not enter into possession of the funds to be transferred.
As such, these providers are not considered payment service providers and do not fall within the scope
of the reporting.
N.B.: the number of actors in card transactions can increase based on the number of intermediaries.
It is common for acquirers to use additional intermediaries to process parts of the payment transaction
or to offer multiple payment methods to the merchant. Although the scheme can vary in practice, the
fundamental principles that are highlighted are always applicable and the same data elements must
always be exchanged between the acquirer and the issuer.
Card payments can be sub-divided in two categories: 3-party card schemes and 4-party card schemes. In
the case of 3-party card payments, the card scheme providers act as both the issuer and acquirer and are
directly connected to the payer and the payee. On the other hand, 4-party card payments require that the
functions of card issuer and of card acquirer are separate, with one linked to the payer and the other to
the payee.
The following sub-section will detail each of these two types of card payments.
2.2.4.1 3-party card scheme
In a 3 -party card scheme, the roles of scheme provider, card issuer and commercial acquirer are all
performed by the scheme provider. As such, the scheme provider is central in this configuration as it
will have direct relationship with both the payer and the payee. Henceforth, the scheme provider, as he
8 https://www.emvco.com/document-search/
18
is the card issuer and acquirer, will always be the key reporting entity and report both payments within
the EU and payments outside the EU.
Figure 5 – Functioning of a 3-party card payment.
In the figure, the information flow takes place as follows:
1. The payer will initiate the payment by providing its card details on an online interface which is
linked to the payee’s website.
2. Once the payer has successfully submitted its card information, the payment initiator will transfer
this data to the card scheme provider acting as both acquirer and issuer. Using this information,
the card scheme provider will check the data received and confirm that it is correct and that the
payer has sufficient funds to execute the payment transaction.
3. The card scheme provider will authorise the transaction and send the confirmation to the payee.
After these steps which correspond to the authorisation process, the settlement phase will begin:
4. As the card scheme provider has covered the payer’s expense via a credit line, it will now request
the payer to pay -back the amou nts that have been paid in advance via a statement of all the
transactions executed (generally over a month period).
5. The payer will refund its credit by sending funds to the card scheme provider. This transfer of
funds will generally take the form of a credit transfer from the payer to the card scheme provider,
who acts as the payee for this payment.
6. The card scheme provider will at regular time s credit the payee ’s payment account with the
aggregated amount of all the transactions it has executed over a period of time. This payment
also corresponds to a credit transfer from the card scheme provider to the payee.
19
N.B.: as highlighted in the graph, 3 -party card payments generally involve other payment services
providers (such as banks) to fund the card’s credit line or to receive the funds from the commercial
acquirer. For these payment service providers, the transactions will look as a payment to the card
issuer (for the payer’s payment service provider) or a transaction from the commercial acquirer to
the payee (for the payee’s payment service provider). These transactions, although different from the
one between the payer and the payee, are in scope of the reporting obligation and should be reported
with either the card issuer as the payee, or the commercial acquirer as the payer. Indeed, they do not
fall within the exclusion of Article 3 (m) PSD2 for transaction between payment service providers for
their own activities, since they do not serve the activities of the payment service providers involved
but are part of the agreement between the payer/payee and the card issuer/commercial acquirer.
2.2.4.2 4-party card scheme
Although they follow the same basic principles, 4-party card schemes differ from 3-party card schemes
as the card scheme provider, card issuer and commercial acquirer are all different entities. Because of
this, the card scheme provider generally play s a less active role in the payment transaction and limits
itself to establishing the rules and providing the infrastructure for the acquirer and the issuer to exchange
information. Since it does not issue the card itself no r acquire transactions, the card sche me does not
provide any payment services and is not a payment service provider under the PSD2. It is thus not subject
to the reporting obligation.
The role of card issuer can vary greatly between the different situations, at times it will be the credit
institution of the payer who will also take the role of card issuer and provide the payer with the card. At
other times, it is a dedicated institution whose sole purpose is to provide credit/debit cards.
The same is also applicable to the role of acquirer which can at time s be done directly by the credit
institution of the payee. In most cases, this role is carried out by specialised entities called commercial
acquirers.
The processing of a card payment generally involves three main stages:
1. Authorisation: the authorisation process is there to enhance security, facilitate authentication,
and for the issuer to confirm to the merchant that the card and proposed transaction is valid. The
authorisation process is important for establishing liabilities between the issuer and the acquirer
in accordance with card scheme rules. But not all card transactions need to be preceded by an
online authorisation to the issuer. The authorisation can also take place between the card chip
and the terminal (offline aut horisation), common in e.g. contactless environments, mas s-transit
etc. and in some cases, a transaction is not authorised at all but sent for clearing anyway by the
merchant or acquirer, at the merchant’s own risk/liability.
2. Clearing: at the end of the business day the payee sends a batch file with the final transactions
received in the payee’s terminal/online webpage. The acquirer “re -packs” the information by
card network and sends it together with received transactions from other merchant customers of
the acquirer as large batch files to the respective card networks. The card network “re-packs” the
information and sends it to the different issuers of the cards, which receive daily batch files with
all transactions received through a card network. The clearing is a serial flow, on which the three
settlements are based.
20
3. Settlement: there are three settlements resulting from card -based transactions, which are all
based on the clearing information but are separate and independent from each other, and can
happen in any order of time:
a. Settlement from the acquirer to the merchant.
b. Settlement from the issuer to the acquirer.
c. Settlement from the cardholder to the issuer (charging by the issuer of the cardholder’s
payment account).
Figure 6 – Functioning of a 4-party card payment.
In the figure, the first steps represent the authorisation flow and the response from the card issuer:
1. The payer provides the details of its payment card in an online interface linked to the payee’s
website. This initiates the payment process.
2. Using the card information provided by the payer, the payee’s terminal will transmit the
information to the acquirer.
3. Using the information available on the card, t he commercial acquirer will forward this
information to the card scheme provider.
4. Always using the data transmitted, the card scheme provider will identify the card issuer and
forward the authorisation message to it.
5. The card issuer will receive the authorisation request containing the card and transaction details.
It will check that all elements are correct and that the payer has enough funds available.
6. The card issuer will send back a response message, positive or negative, to validate or negate the
transaction. This response message will follow the same steps as the original request in reverse.
21
Once the transaction has been authorised (or send for clearing if there is no authorisation), the next steps
will cover the clearing process:
7. The terminal of the payee will send, at the end of the business day a batch file with all payment
transactions received by the payee during the day to the commercial acquirer.
8. This information is combined by the commercial acquirer for all payments done via a given card
scheme. The commercial acquirer will then send th ese new batch files to the card scheme
provider.
9. Using the information available in the batch file, the card scheme provider will split the file per
card issuer and send the payment information relating to each card issuer.
10. Receiving this information, the issuer will split it for each card owner and inform them of their
liability.
Finally, once the clearing is over the settlement phase will begin and happen at any order of time.
N.B.: similarly to 3-party card payments, 4-party card payments often involve other payment services
providers (such as banks) to fund the card’s credit line or to receive the funds from the commercial
acquirer. For these payment service providers the transaction s will look as a payment to the card
issuer (for the payer’s payment service provider) or a transaction from the commercial acquirer to
the payee (for the payee’s payment service provider). These transactions, although different from the
one between the payer and the payee, are in scope of the reporting obligation and should be reported
with either the card issuer as the payee, or the commercial acquirer as the payer. Indeed, they do not
fall within the exclusion of Article 3 (m) PSD2 for transaction between payment service providers for
their own activities, since they do not serve the activities of the payment service providers involved
but are part of the agreement between the payer/payee and the card issuer/commercial acquirer.
2.2.5 Electronic money
Electronic money probably constitute s the most recent way of transferring funds between payment
accounts. E-money offers many advantages compared to traditional payment methods such as speed of
transaction, low fees and protection of financial data. The E-money sector is regulated under the
Electronic money Directive (“EMD”) 9 as well as the PSD2 since E-money institution are payment
service providers.
Although the EMD establishes the basic rules applicable to the sector, each E-money provider has
discretion to create its own system and its own way of processing payments. Because of that, there is
little interaction between the different E-money providers. Depending on the business model adopted by
the E-money provider, it can be required that both the payer and the payee subscribe to the same E-
money provider in order to execute payments or that only one of them subscribe to the services provided
by the E-money provider.
9 Directive 2009/110/EC of the European Parliament and of the Council of 16 September 2009 on the taking up, pursuit
and prudential supervision of the business of electronic money institutions amending Directives 2005/60/EC and
2006/48/EC and repealing Directive 2000/46/EC (Text with EEA relevance), (OJ L 267, 10.10.2009, p. 7),
22
This lack of standardisation in the sector’s functioning makes it impossible to cover all existing and
future business models10. However, despite this great variety of services provided, the E-money sector
can be divided into two main business models: the E-wallet and the electronic voucher/card providers.
N.B.: similarly to card payments and marketplaces, E-money payments generally involve other
payment services providers (such as banks) to fund the E-money account or to withdraw funds from
it. For these payment service providers , the transactions will look as a payment to or from the E-
money provider. These transactions, although different from the one between the payer and the payee,
are in scope of the reporting obligation and should be reported with the E-money provider as either
the payer or the payee . Indeed, they do not fall within the exclusion of Article 3 (m) PSD2 for
transaction between payment service providers for their own activities, since they do not serve the
activities of the payment service providers involved but are part of the agreement between the
payer/payee and the E-money provider.
2.2.5.1 E-wallet
In an E-wallet, the payment service provider s offer a form of virtual wallet or E-wallet to the payer,
which can be used to pay for goods or services. It is funded using a variety of payment methods such as
card payments, credit transfers, exactly like a physical wallet would do with physical cards. Funds that
are transferred to the E-wallet can be used to execute payments within the E-money provider’s
infrastructure. Funding the E-wallet can occur either in advance or simultaneously with the E-money
transaction.
In addition to providing payment services to the payer, the E-wallet provider also offers payment services
to the payee who also needs to be registered in the E-wallet provider’s systems in order to receive
payments via E-money. Because of that, the E-wallet provider has a direct relationship wi th both the
payer and the payee and is thus the key actor in the reporting obligation. As already explained, although
other payment service providers are also involved in E-money payment, they only act as funding sources
for the E-wallet or as destination for the withdrawal of funds. They have no implication in the E-money
payment between the payer and the payee which is managed solely by the E-money provider.
10 According to Regulation (EU) 2023/1114 of the European Parliament and of the Council of 31 May 2023 on markets in
crypto-assets, and amending Regulations (EU) No 1093/2010 and (EU) No 1095/2010 and Directives 2013/36/EU and
(EU) 2019/1937 (MICA Regulation), Crypto Asset Service Providers (CASP) that obtain a payment licence under PSD2
as payment service providers can be in the scope of CESOP, in the terms established in that licence to provide payment
services.
23
Figure 7 – Functioning of an E-wallet payment
In the figure, the information flow takes place as follows:
1. The payer will initiate the E-money transaction by providing its e-account details on the payee’s
webpage.
2. The E-wallet provider will receive the details of the transaction and confirm it is valid. If this is
the case, the E-wallet provider will transfer the funds from the payer ’s e-account to the payee’s
e-account.
Once this is done, the transfer of funds within the E-money provider’s systems is completed and no
settlement is needed since the E-money provider is the only actor involve d in the payment transaction.
However, if the payer’s E-money account was not funded, it is necessary for the E-money provider to
request and settle these funds from the funding sources registered by the payer before executing the E-
money payment:
3. The E-money provider will use the data provided by the payer when registering to request a
transfer of funds from the payment service provider responsible for the payer’s funding source
(for example a credit transfer or a card payment). This will create a separate transaction between
the payer and the E-wallet provider as the payee.
4. Similarly, the payee can decide to withdraw the funds from its E-money account to its bank
account or other payment account. As such, this will create another transaction where the E-
wallet provider will be the payer and the merchant the payee. This separate transaction should be
reported by the payment service provider of the payee (i.e. its bank).
24
2.2.5.2 E-voucher/Electronic card providers
Electronic vouchers differ from E-wallet as they do not create an E-wallet but focus on creating a single
electronic form of payment, which often takes the form of electronic pre-paid cards. These cards can be
bought by the payer in selected distributors/retailers and allow the payer to execute payments via the E-
money provider infrastructure without the need to include any financial information. As such in contrast
to the E-wallet, E-vouchers providers do not have a direct relationship with the payer and do not require
him to be registered in their systems to use the services. It is generally enough that the payer uses the E-
voucher that he bought from t he E-money provider’s retailer. In the cases of E-vouchers, the E-money
provider only has a direct relationship with the payee who still needs an e-account to receive payments.
Figure 8 – Functioning of an E-voucher payment.
In the figure, the information flow takes place as follows:
1. The payer will initiate the E-money transaction by introducing the details of its E-voucher on the
merchant’s website.
2. The E-money provider will validate the information introduce d by the payer and confirm the
transaction. The E-money provider will then credit the payee’s e-account with the amount of the
transaction.
Once this is done, the transfer of funds within the E-money provider is completed and no settlement is
needed since the E-money provider is the only actor involve d in the payment transaction. However, a
series of other operations generally occur outside the systems of the E-money provider:
3. The payer will buy an E-voucher from a selected distributor which has been authorised by the E-
money provider to distribute its payment methods. The E-money provider is aware that a voucher
has been sold at a given location. When purchasing the E-voucher, the payer will generally
perform a payment transaction to pay the retailer for the E-voucher. Depending on the business
model used, these funds will be transferred to the retailer or directly to the E-voucher provider.
25
In both situations, there is a different transaction (occurring before the payer uses the E-voucher
to pay for goods or services) where the retailer or the E-voucher provider will be the payee.
4. Similarly, as with E-wallets, the payee can decide to withdraw the funds from its E-money
account. As such, this will create another transaction where the E-money provider will be the
payer and the merchant the payee. This separate transaction should be reported by the payment
service provider of the payee.
Electronic cards differ from Electronic vouchers as they are often associated with an E-wallet. The cards
can be pre -paid virtual or physical cards or can be funded by a credit line. They also differ from a
traditional E-wallet facility as either the payee or payer may not be subscribed to the E-money institution.
In such situations, only the payer may be subscribed to the E-money facility, however, the payee will
have deemed the card to be accepted as a means of payment.
In contrast to the E-wallet and E-vouchers, the E-money card provider process can commence by either
the payee or payer initiating the payment.
There are multiple variations of the E-money card provider schemes and transactional chains. Whilst
such transactions may appear as a card transaction for payee or payer reporting, the location associated
with the payee or payer at onboarding must be used as the identifier in line with Article 243c wherever
possible.
2.2.6 The case of marketplaces and intermediaries collecting funds in their
own name
Although not a payment method in itself, the situation of marketplaces and intermediaries can change
the way data is exchanged within a given payment. This is due to the fact that when they collect and
keep funds in their own name before distributing them to the payee, these entities act as a payment
service provider and must be registered as such. However, this also means that for the other party to the
payment chain, they look like the payee as they hold the funds transferred in their name and will be
reported as such.
For example, most marketplace s use a business model where the payment s are first directed to the
marketplace itself, who will keep these funds for a given period of time, before distributing them to the
payee in a consolidated amount and after application of the marketplace fees. This way of proceeding is
also used by some payment service providers who will have a single contract with the payee where they
offer a variety of payment methods. The advantage for the payee is that it will not need to contract an d
register directly with all the providers of these various payment methods but will be able to offer them
to its clients via the services of the intermediary who has all the contracts. The consequence is that the
intermediary will first consolidate all the transactions received from the various payment methods in
dedicated accounts before distributing the aggregated sums to the merchants.
In both these cases, the presence of an intermediary in the payment chain that will shield the payee’s or
payer’s information from all the other actors creates a discrepancy in the data exchanged , since the
intermediary will appear as the payee for all the actors before it, and as the payer for all those after it.
26
Figure 9 – Functioning of a credit card via marketplace payment.
To detail the functioning of a payment going through an intermediary, we will use the example of a card
payment to a marketplace. In the figure, the information flow is highlighted by the blue number s and
takes place as follows:
1. The payer will provide its card details on the marketplace ’s website in order to initiate the
payment.
2. The marketplace will transfer this information to the commercial acquirer which will use it to
identify the issuer using the card scheme network.
3. The issuer will validate the transaction details and send the confirmation to the acquirer via the
card scheme network.
4. The acquirer will validate the transaction for the marketplace.
The key difference from a standard card payment is that neither the acquirer nor the issuer receive any
information on the merchant (the payee). Instead, they will both see a payment transaction going to the
marketplace itself. This implies that the acquirer and issuer will not be able to report the final payee (the
merchant) of the transaction.
Considering that the details of the payee are not available to them, the card issuer and the acquirer should
thus report the marketplace as the payee. On the other hand, since the marketplace acts for both the payer
and the payee and is in possession of all the data necessary to have a full view of the payment and its
intended beneficiary (the merchant), it must identify the real payee (i.e. the merchant) when reporting
the data.
27
2.3 The payment services in scope
In addition to specifying the four categories of payment service providers in scope presented in section
2.1., Article 243a of Directive 2006/112/EC also limits the reporting obligation to the payment services
laid down in points 3 to 6 of Annex I of the PSD2 . This means that only payment service providers
which provide the following payment services will be in scope of the reporting obligation:
- Executing payment transactions and transfers of funds on payment accounts.
- Executing payment transactions covered by a credit line.
- Issuing of payment instruments and acquiring of payment transactions.
- Money remittance.
This means that payment service providers who provide services linked to operating a payment account,
cash deposit and withdrawal, payment initiation services and account information service provision, are
not in scope of the reporting obligation. The reason behind this exclusion is that these type s of services
either do not refer to the execution of payment transaction s, or they would provide information that is
already provided by the other payment service providers involved in payment transactions.
In addition, Article 3 of PSD2 sets out specific payment service exclusions which further restrict the
scope of reporting. This list of out-of-scope payment services includes, but is not limited to, the
following three examples of payment methods, which therefore do not fall within the scope of reporting:
- Paper based vouchers and payments in cash (Article 3 (g)).
- Cheques (Article 3 (a)).
- Payment methods with limited use (Article 3 (k)).
2.3.1 Payment methods with limited use – vouchers
Payment methods with limited use must be understood as being valid to pay only a strictly limited (and
often pre-established) number of merchants or pay for a limited range of goods and services. Article 3
(k) of the PSD2 defines such payment method as:
(k) services based on specific payment instruments that can be used only in a limited way, that meet
one of the following conditions:
(i) instruments allowing the holder to acquire goods or services only in the premises of the
issuer or within a limited network of service providers under direct commercial agreement
with a professional issuer.
(ii) instruments which can be used only to acquire a very limited range of goods or services.
(iii) instruments valid only in a single Member State provided at the request of an undertaking
or a public sector entity and regulated by a national or regional public authority for specific
social or tax purposes to acquire specific goods or services fro m suppliers having a
commercial agreement with the issuer.
Payment methods with limited use must not be confused with the use of an E-voucher. An E-voucher
(see point 2.2.5.2.) is in scope of the reporting obligation as it is a valid (pre-paid) payment method that
can be used to purchase goods potentially everywhere (as long as the merchant has contracted with the
E-money provider to provide this type of payment). The key aspect to differentiate the two is the limited
usage of the former, either regarding the places where it can be used ( only at the premises of its issuer
28
or in a single Member State), or what it can buy ( limited range of goods or services ). As such, it is
necessary to identify wh ether the payment method can potentially be used by any merchant to buy
anything or is only limited to the different sellers or goods and services offered by a given brand,
network, etc.
The fact that a payment method is only accepted by few merchant s does not mean that it automatically
falls within the category of payment methods with limited use. Indeed, the limited acceptance could be
due to various reasons and increase over time leading to a more widespread adoption. For example, the
same would apply with card payments where merchants will not necessarily accept all the card schemes
in existence but only a number of them. A payment method with limited use, however, will not generally
see a huge increase of its acceptance since it will only be accepted at the premises of its issuer.
Among payment methods with limited use, the most common one s would be “gift vouchers” or “gift
cards”, which are bought for a given amount and then allow the holder of the card or voucher to buy the
goods and services offered by the issuer of the card/voucher or its partners.
The figure below highlights how reporting will take place in a payment done via gift vouchers.
Figure 10 – Reporting of payments via gift vouchers.
The figure clearly highlights that the marketplace will not report the payment from the payer to the payee
made using the voucher. However, the payment made by the payer (or someone else) to buy the voucher
together with the disbursement of funds from the marketplace to the payee bank account would be
reported, as they are payments executed by payment services providers providing the payment services
in scope of the reporting obligation.
2.3.2 Vouchers and refund
If the payer is not satisfied with the goods ordered and wishes to return them , it is not uncommon that
marketplaces and businesses provide the payer with the option to receive a voucher rather than a refund.
This practice offers advantages to the business who does not need to transfer funds back and also to the
payer who is provided with an equally valid payment method to buy similar goods. These vouchers can
29
also be offered as compensation if the goods are damaged, delayed or if any issue occurred during the
delivery.
The figure below illustrates what happens in such situation for the reporting.
Figure 11 – Reporting of refunds and payments via gift vouchers.
The first payment from the payer to the marketplace (using an in-scope payment method) is in scope of
the reporting obligation and will be reported. In the case where a refund is requested by the payer, the
marketplace will also report this refund.
However, all the following payments performed via the gift voucher will not be subject to the reporting
obligation. As highlighted in the figure, this can lead to situations where the payer buys good s from a
first seller, which is reported to CESOP, but then ask for a refund via a gift card. Although the
marketplace reports the refund, it will not report the issuance of the gift card to the payer and will not
report the following transaction done by the payer who, using the gift card, now buys goods from another
seller. However, once the marketplace proceed s to the disbursement of the funds it ow es the second
seller, this disbursement will be subject to a reporting from the second seller’s bank which will report
the consolidated amount.
As such, even though part of the transaction chain will not be visible due to the use of the gift card,
CESOP will still receive information on how much funds were received by the first seller, how much
was refunded on the first transaction, and will have information on the total amount received by the
second seller due to the reporting by its payment service provider.
2.3.3 The use of vouchers together with in-scope payment methods
This final situation focuses on cases where the payer uses a gift card or voucher to buy goods or services,
but the value of the voucher is insufficient to pay for the purchase in full and the balance must be paid
by a regular transfer of funds done via in-scope payment methods.
30
Figure 12 – Reporting of payments via gift vouchers together with in-scope payment methods.
In such a situation and if the rules were applied without considering the monitoring and the limitation of
Article 243b (2), the reporting should happen as follows:
- The payment service provider executing the in-scope payment (card payment, credit transfer, E-
money, etc…) would report that payment with the marketplace as the payee.
- The marketplace would not report the part of the payment made via the voucher as it is out of
scope but would report the payment made using the in-scope payment method with the seller of
the goods as the payee.
- The payment service provider of the payee (seller) w ould report the disbursement from the
marketplace to the payee which w ould include an aggregation of all payments received over a
given period of time.
Although this scheme could be applicable when the seller is a single entity, buying goods on a
marketplace generally implies that a multitude of seller s may be involved in a single transaction, each
one of them providing part of the items that constitute the payer’s total purchase. As a consequence,
marketplaces do not divide the various payments between vouchers and other payments, but rather group
them all in one payment that mix vouchers and in-scope payment methods. Because of that, marketplaces
are often unaware of which part of the amount they attribute to each seller is coming from the voucher
and should be excluded.
As such, given the impossibility for marketplace s to split the value of a voucher between the different
sellers when it is coupled with in -scope payment methods, and considering that exception s should be
interpreted restrictively, which would go contrary with the exclusion of the whole payment transaction,
it is accepted that the marketplaces report the full payment transaction(s), including the amounts covered
by a voucher, when they are not able to identify which exact part of the payment is coming from an out
of scope payment transaction.
In practice, this implies that if the marketplace is not able, for each payment transaction to each payee,
to determine which part of that payment is covered by a voucher, then the marketplace will report all
payment transactions to each payee in full as if there was no voucher used.
31
2.4 Practical application per payment method
The following section will illustrate, for each of the main payment method s mentioned in section 2.2 ,
who are the entities that must report data. The entity circled in red represents the one that will report the
payment between the payer (buyer) and the payee (seller), while those circled in yellow represent
payment service providers who will also report a payment as part of the overall payment chain, but which
does not strictly refer to the payment between the buyer and the seller.
Each example only highlights the entities in scope but does not establish which one will effectively
report the payment data in accordance with the rule of Article 243b (3). For details on this, see section
4.3.
2.4.1 Credit transfer
For credit transfers, the payment service providers in scope of the reporting obligation are the bank of
the payer and the bank of the payee. The clearing house or any other intermediary agent or payment
service provider should not report any data as it is not a payment service provider providing payment
services to the payer or payee.
Figure 13 – In scope entities for credit transfers.
2.4.2 Direct Debit
As they work in a similar way to credit transfer, the exact same rules apply to direct debit s. The payer
and the payee bank are thus in scope of the reporting obligation while the clearing house is not.
32
Figure 14 – In scope entities for direct debits
2.4.3 Money remittance
In money remittance payments, both the money remittance institution and the disbursement partner are
payment service providers in scope of the reporting obligation.
Figure 15 – In scope entities for money remittances.
33
2.4.4 Card payments
2.4.4.1 3-party card scheme
As for all card payment s, the credit card issuer and acquirer are the key entities for the reporting
obligation and are in scope. For 3-party card schemes, since these functions are performed by the card
scheme itself, the card scheme will also be a payment service provider and will be in scope of the
reporting obligation.
When it comes to the payer s’ and payee s’ banks, they will be subject to a reporting obligation as
highlighted by the graph. However, they will not report data on the payment from the payer to the payee
but will report a different transaction, either from the payer to the card scheme provider to settle its card
credit, or from the scheme provider to the payee to transfer the aggregated payments.
Figure 16 – In scope entities for 3-party card schemes.
2.4.4.2 4-party card scheme
The example below uses the situation w here both the credit card issuer and the commercial acquirer
would differ from the payer’s and payee’s banks. In such case, the key reporting entities for the payment
between the payer and the payee will be the card issuer and the acquirer who will have to report the data.
The card network however is not a payment service provider and will not be subject to any reporting
obligation.
Similarly, as with 3-party card scheme s, the payer ’s and payee’s banks will be subject to a repor ting
obligation as they are payment service provider s. However, they will not report data on the payment
34
between the payer and the payee but will report a different transaction, either from the payer to the card
issuer to settle its card credit, or from the acquirer to the payee to transfer the aggregated amounts
(settlement).
Figure 17 – In scope entities for 4-party card schemes.
2.4.5 E-money
2.4.5.1 E-wallet
In the case of E-wallet, the E-money provider is the central reporting entit y and the only one that has
full visibility on the transaction between the payer and the payee. The E-money provider will thus be in
scope of the reporting obligation and always report the data on the payment between the payer and the
payee.
The situation of the payer’s and payee’s banks are similar to card payments. They are payment service
providers in scope of the reporting obligation, however, they are not involved in the transaction between
the payer and the payee. Instead, they will report a payment from the payer to the E-money provider for
the payer’s bank, and from the E-money provider to the payee for the payee’s bank.
35
Figure 18 – In scope entities for E-wallet.
2.4.5.2 E-voucher
The situation of E-vouchers is similar to the E-wallet when it comes to the central role of the E-money
provider for the reporting, therefore the E-money provider will be in scope of the reporting obligation.
The difference lies in the presence of the distributor/retailer of the E-voucher, which is not a payment
service provider and as such will not have any reporting obligation.
The situation of the payer’s and payee’s banks is identical to the one described for the E-wallet.
Figure 19 – In scope entities for E-vouchers.
36
2.4.6 Marketplace
The example below takes the situation of a payment made on a marketplace using a 4 -party card
payment. The conclusions are however perfectly applicable to credit transfers or other means of
payment.
In the situation of the marketplace, the marketplace itself is a payment service provider according to the
rules of the PSD2 if it holds funds on behalf of both the payer and the payee . As such, in the case of a
card payment to a marketplace, the regular actors of card payments will be in scope (and the card network
will not), but the marketplace will also be in scope of the reporting obligation. This involvement of the
marketplace is key to the reporting since the marketplace is the only entity with the full visibility on the
payment between the payer and the payee. Both the issuer and acquirer can only report a payment going
through the marketplace as it collect s the funds in its own name. Only the marketplace can report the
information about the real beneficiary of these funds.
The situation of the payee’s bank on the graph is the same as for regular card payments. The payee’s
bank is not involved in the transaction between the payer and the payee and will only report the
disbursement amount from the marketplace to the payee.
Figure 20 – In scope entities for marketplaces.
37
3 MONITORING AND TRIGGERING OF THE REPORTING OBLIGATION
Once the conditions of Article 243b, as detailed under point 2, are fulfilled, a payment will be in scope
of the reporting obligation. However, it will not be reported unless two additional conditions are met.
This will be determined by a monitoring test performed by the payment service providers.
These two additional conditions are that:
- The payment reported must be a cross-border payment (point 3.1) and
- The payment service provider providing payment services in a Member State must execute more
than 25 cross-border payments in that Member State per quarter to a single payee in order to
trigger the reporting obligation (point 3.2).
It is important to clearly detach monitoring rules from the data to be reported under Article 243d. The
monitoring rules ensure the proportionality of the reporting obligation for subsidiarity and data
protection purposes. Their objective differs from the reporting obligation which purpose is to help the
fight against VAT fraud. As such, the monitoring rules rely on proxies so that they can be easily applied
by all payment service provider s. They should however not influence the data to be transmitted which
needs to be as precise as possible in order to be effective.
In particular, location rules must not impact the location transmitted as the address of the payee . It is
perfectly acceptable that the address transmitted does not correspond to the location of the payee
determined via the rules of Article 243c (see point 3.1 for more details).
Similarly, the threshold aggregation must be distinguished from the actual reporting of data. This means
that payment service providers must not merge the data relating to the owner of two payment accounts
(the data relating to the payee) when reporting a payment even if they have identified that the accounts
are owned by a single payee (see point 3.2 for more details).
Information relating to monitoring rules is to be used exclusively by the payment service providers in
order to help them identify when a payment should be reported. This information is not part of the data
elements required under Article 243d and must not be automatically reported to Member States.
3.1 Cross-border payments - Location rules of Article 243c
The first condition that payment service providers must monitor in order to determine whether a payment
should be reported is whether this payment is a cross -border payment pursuant to the rules of Article
243c of Directive 2006/112/EC.
1. For the application of the second subparagraph of Article 243b(1) and without prejudice to the
provisions of Title V, the location of the payer shall be considered to be in the Member State
corresponding to:
(a) the IBAN of the payer’s payment account or any other identifier which unambiguously identifies,
and gives the location of, the payer, or in the absence of such identifiers,
(b) the BIC or any other business identifier code that unambiguously identifies, and gives the location
of, the payment service provider acting on behalf of the payer.
2. For the application of the second subparagraph of Article 243b(1), the location of the payee shall
be considered to be in the Member State, third territory or third country corresponding to:
38
(a) the IBAN of the payee’s payment account or any other identifier which unambiguously identifies,
and gives the location of, the payee, or in the absence of such identifiers,
(b) the BIC or any other business identifier code that unambiguously identifies, and gives the location
of, the payment service provider acting on behalf of the payee.
Only data on cross-border payments should be transmitted to Member States and to CESOP. No data on
national payments should be collected in accordance with the rules of the Directive.
3.1.1 Table of identifiers to determine the location of the payer and payee
Article 243c lays down the rules applicable to determine when a payment shall be considered as cross -
border. These rules rely on proxies in order to assign a country easily and quickly to the payer and the
payee.
The table below lists the identifiers or data elements from which the location of the payer and the payee
should be retrieved by payment service providers for the main payment methods in use . The table is
however indicative and other elements could be used if deemed more accurate to determine the real
location of the payer or payee.
Table I – Location identifiers per payment methods and reporting entity.
Payment
Method
Payer’s PSP reporting (Extra-EU) Payee’s PSP reporting (Intra-EU)
Payer Location Payee Location Payer Location Payee Location
Credit
transfer
- IBAN
- (BIC of the PSP)
- IBAN
- BIC of the PSP11
- Payment account
number12
- IBAN
- (BIC of the PSP)
- IBAN
- (BIC of the
PSP)
Direct
Debit13 - IBAN - (BIC of the PSP) - IBAN - BIC of the PSP
- Payment account no.
- IBAN
- (BIC of the PSP)
- IBAN
- (BIC of the
PSP)
Card
payments
- BIN - Merchant address
- Card Acceptor
location
- BIN - Merchant
address
E-money - Payer e-account
(location captured
at onboarding)
- IBAN
- E-vouchers: seller
country code
- Payee e-account
(location captured at
onboarding)
- IBAN
- Payer e-account
(location captured
at onboarding)
- IBAN
- E-vouchers: seller
country code
- Payee e-
account
(location
captured at
onboarding)
- IBAN
Money
remittance
- Payer Location
(own records)
- IBAN
- BIC of the
disbursement
partner
- BIC of the
disbursement
partner
- Payee location
(own records)
11 To be used when no IBAN is available
12 This identifier does not necessiraly contain a country code, and will often be linked to the BIC of the payment service provider.
13 There is currently no international scheme applicable to direct debit. As such, the identifiers listed here for the payer’s payment
service provider reporting are mainly theorethical.
39
It is important to note that although Article 243c requires payment service providers to primarily use
identifiers linked to the location of the payer and payee, some of these identifiers will ultimately be
linked to the location of the payment service providers (e.g. IBAN). This can impact the reporting
obligation (see point 3.1.2.).
Contrary to the rule laid down in Article 243d (1)(d), there is no order of preference when it comes to
the identifier to use (apart from the obligation to use the identifier of the payer/payee first). This implies
that if a payment service provider has different identifiers available that provide a different
location, it must choose the identifier that best reflects the location of the payee and of the payer.
As such, if a payment service provider has information or an identifier within its records which confirm
the true location of the payee or payer , this information or identifier must be used to determine the
location of the payee or paye r and take s precedence over other identifier s which would point to a
different location that the payment service provider knows is not the real location of the payer or payee.
The information or identifier on the true location of the payee or payer should then form the basis to
determine the home and host Member States for the purpose of Article 243b (4)(b).
Example: if an E-money provider has an IBAN with a country code that differs from the one of the
address provided by its client during onboarding and which has been confirmed by official documents
(ID cards, passport, driving license, etc.), it must choose the location provided by the client as it better
reflect the location of its client.
Example 2: the BIN range of a credit card can be used to identify where the issuer of the card is
located or where the card has been issued. In application of the above rules, payment service provider
must use the BIN range that indicates where the card has been issued as it is the one that best reflect
the location of the payer.
Example 3: if an E-money provider has issued a card (virtual or physical) with a BIN range that
differs to the country code associated with the address provided by the client at onboarding, the
address details provided must be used to determine the correct location of the client as they better
reflect the true location of the client (payer or payee).
3.1.2 Practical application
3.1.2.1 Credit Transfer/Direct Debit – Payer, payee and payment service providers
in different Member States
In the situation below, the payer and payee are in two different Member States and use payment service
providers established in their Member States to execute a credit transfer/direct debit.
Following the rules of Article 243c, the most relevant identifier for these payment method s will be the
IBAN of the payer’s and payee’s payment accounts. Since both IBAN will refer to two different Member
States, the payment will be considered as cross-border.
40
Figure 21 – identification of cross -border credit transfer s with payer and payee and their payment
service providers in different Member States.
3.1.2.2 Credit Transfer/Direct Debit – Payer and payee in the same Member State
Figure 22 – identification of cross -border credit transfer s with payer and payee in the same Member
States but their payment service providers in different Member States.
41
In the situation above, the payer and the payee are located in the same Member State but the payee uses
the services of a payment service provider from another Member State.
Since the IBAN of the payee ’s payment account will be linked to the location of its payment service
provider and not to the location of the payee itself, the payment between the payer and the payee will
still be considered as a cross-border payment and will have to be reported to CESOP.
N.B.: in the theoretical case where the payee uses a non -EU payment service provider, this payment
would appear as an extra -EU cross-border payment. In this situation, the payer’s payment service
provider would be liable to do the reporting. This case is however unlikely in practice due to the PSD2
requirements for payment service providers to have a payment license in the EU and would only occur
for EEA countries (see section 4.3.2.).
3.1.2.3 Credit Transfer/ Direct Debit – Payer and payee’s payment service providers
in the same Member State
Figure 23 – identification of cross -border credit transfe rs with payer and payee in different Member
States but their payment service providers in the same.
In this situation, the payer and the payee are located in different Member States but the payee uses the
services of a payment service provider located in the same Member State as the payer.
Since the IBAN of the payee ’s payment account will be located where its payment service provider is,
the payment between the payer and the payee will appear as a national payment since both payment
service providers are located in the same Member State. As such, it will not be reported to CESOP. The
fact that the payer and payee are located in two Member State s is irrelevant according to the rules of
Article 243c.
42
3.1.2.4 Card payment – Payer, payee and payment service providers in different
Member States
Figure 24 – identification of cross -border card payment s with payer and payee and their payment
service providers in different Member States.
In this situation the payer and the payee are both located in different Member States and use the services
of payment service providers from their respective Member States to execute a card payment.
For card payments, the most relevant identifier s to use would be the BIN range of the payer ’s card for
the payer’s location, and the address or identifier of the merchant for the payee ’s location. Both these
identifiers will locate the payer and the payee in different Member States. The payment is thus cross -
border and subject to reporting.
N.B.: it should be kept in mind that the BIN is an alphanumeric string where the first part usually
gives the location of the payment service provider that issues the card, while the second part gives the
location where the card is actually issued. For instance, the BIN can indicate that the payment service
provider that issued a card is in IE, while the same payment service provider issued the card in FR
where the payer is located. Both locations can be retrieved by the same BIN. Payment service
providers must use the BIN range that is the closest to the real location of the payer , meaning the
location where the card has been issued and not the one where the issuer is located, as highlighted in
section 3.1.1.
43
3.1.2.5 Card payment – Payer, payee in same Member State
Figure 25 – identification of cross-border card payments with payer and payee in same Member State
and their payment service providers in different Member States.
In this situation the payer and the payee are both located in the same Member State but the payee uses
the services of a payment service provider in another Member State to execute a card payment.
Given that both the BIN range and the merchant identifier or address will refer to the actual position of
respectively the payer and the payee, the payment will be considered as a national payment and will not
be reported.
44
3.1.2.6 Card payment - Issuer and Payer in different Member States
Figure 26 – identification of cross -border card payments with payer and payee in different Member
States but their payment service providers in the same.
In this situation the payer and the payee are located in different Member States while both the payer and
the payee’s payment service providers are located in the same Member State. The payer uses the services
of a card issuer in the Member State of the payee to execute a card payment.
For such cases, the payment service provider must use the data on where the card has been issued and
not the data on where the card issuer is located. As such, the BIN range should indicate that the payer is
located in a different Member State to the payee and the payment should be considered as cross-border
and be reported.
3.1.2.7 E-money/marketplace – Payer and Payee in different Member States
In this case, the payer and the payee are using the service of an E-money institution or marketplace to
execute the payment. In both cases, the payment service provider will likely have a relationship with
both the payee and payer.
E-money institutions and marketplaces can have a multitude of identifiers and data to locate the payer
and payee (IBAN, card BIN, own identifier and address taken during registration). They are free to
choose the identifier that can best locate the payer and paye e based on their real location . It should be
noted that if they decide to use the card BIN, they should refer to the range that reflects the actual location
of a payee or payer . In that regard, the BIN may not be suitable for cards associated with a n e-money
facility when such location differs from the one established by the E-money institution at onboarding.
In many cases, th e best identifier might well be the own identifier of the E-money provider or
marketplace, which can use a variety of information collected during the account creation to effectively
locate the payer and the payee with a high degree of precision.
45
Using this identifier, the E-money provider/marketplace will be able to locate the payer and payee in
two different Member States and determine that the payment is cross-border and should be reported.
N.B.: even though from an external perspective, all payments made through E-money providers or
marketplaces will appear to be located at the E-money provider’s/marketplace’s establishment, both
entities have the information available to determine the actual location of the payer and payee and
must use this information to differentiate cross-border payments from national payments.
Figure 27 – identification of cross -border E-money/marketplaces payments with payer and payee in
different Member States.
46
3.1.2.8 E-money/marketplace – payer and payee in the same Member State
In this case, the payer and the payee are located in the same Member State and are using the service of
an E-money institution or a marketplace to execute their payment. In both cases, the payment service
provider will have a relationship with both the payee and payer.
The payment service provider will locate the payer and the payee using the identifiers at his disposal
which should indicate the real location of the payer and the payee. As such, the payment should be
considered as national and not be reported.
Figure 28 – identification of cross -border E-money/marketplaces payments with payer and payee in
same Member State.
47
3.1.2.9 Money Remittance – Payer and Payee in the same Member State
Figure 29 – identification of cross-border money remittances payments with payer and payee in same
Member State.
In this case, the payer and the payee are located in the same Member State but are using money
remittance institutions in different Member States to perform a money remittance.
As money remittances are performed without the need for payment accounts, the identifiers to use to
locate the payer and the payee will be the BIC of their respective money remittance institution s. Since
both institutions are located in different Member States, this payment should be considered as cross -
border even though the payer and the payee are located in the same Member State.
3.2 Threshold of 25 cross-border payments under Article 243b (2)
The second monitoring to be performed by payment service providers regards the threshold of 25 cross-
border payments laid down in Article 243b (2) of Directive 2006/112/EC.
The requirement to which payment service providers are subject under paragraph 1 shall apply where,
in the course of a calendar quarter, a payment service provider provides payment services
corresponding to more than 25 cross-border payments to the same payee.
The number of cross-border payments referred to in the first subparagraph of this paragraph shall
be calculated by reference to the payment services provided by the payment service provider per
Member State and per identifier as referred to in Article 243c (2). Where the payment service
provider has information that the payee has several identifiers the calculation shall be made per
payee
48
In order to trigger its inclusion in a payment service provider’s quarterly report, this Article requires that
the payee receives more than 25 cross-border payments per quarter. In the case where a payment service
provider did not execute more than 25 cross-border payments to the same payee, it will not have to report
any data on that payee. On the other hand, if the threshold is exceeded, the payment service provider
will have to report all transactions to the payee (and not only the transactions exceeding the threshold.
The second sub-paragraph lays down the details of the threshold calculation. The threshold rule has been
established to ensure that only data on taxable person s is collected and that data on private citizen s
receiving occasional cross-border payments will not be collected or transmitted to CESOP. It also acts
as a simplification measure and a presumption of economic activities, meaning that payment service
providers must report payees that exceed the threshold no matter whether they have information that
they are taxable persons or not.
3.2.1 The basic rule – Calculation of cross-border payments per identifier
The basic rule under Article 243b (2) is that the number of cross-border payments for a payee should be
calculated using the identifier of the payee referred to in Article 243c (2). In that regard, we refer to
section 3.1.1 for the overview of relevant identifiers per payment method. In addition, only cross-border
payments should be used in the calculation (see section 3.1. for the definition of cross-border payments).
In application of this rule, payment service providers of both the payer and the payee will, for example,
have to take into consideration all cross-border payments made to a single IBAN to calculate the total.
If that amount exceeds 25 cross-border payments, then all the payments executed to that IBAN over the
quarter will have to be reported to CESOP along with the details of the account holder (see section 4 for
the full list of data to transmit).
In addition, the calculation has to be done regarding the payment services provided per Member State.
This means that if a payment service provider has establishments in several Member States, each of these
establishments should perform the calculation separately and not consolidate all their transactions at
group level. The same is applicable if the payment service provider provides payment services in
different Member States via commercial agents or directly.
3.2.2 The additional rule – Aggregation of cross-border payments per payee
It is not uncommon that a given payee will have a number of payment methods available for the payer,
which can be linked to different identifiers (for example an IBAN for credit transfer, a merchant ID for
card payment and an E-money account). In order to ensure payments to business es are not reported
because they are split into several payment methods, Article 243b (2) lays down an additional rule which
requires payment service providers to aggregate payments executed to multiple identifiers when they
have the knowledge that these identifiers actually refer to the same payee.
According to this rule, if a payment service provider execute s a series of payments using two different
IBAN, or for example using an IBAN and a merchant ID, and it knows that the same payee owns both
payment accounts, the payment service provider must consider the two payment accounts as one for the
purpose of comparison to the threshold and include all payments to both the accounts in their calculation.
N.B.: the aggregation of payment accounts for the calculation of the threshold must not impact the
reporting of the data itself. The later must be done using transactional data and thus considering both
accounts as different payment accounts. Payment service providers must thus not aggregate the data
transmitted in application of this rule.
49
For example : this implies that if a payment service provider has identified that a payee has two
payment account, it must not include both these accounts as the payee’s account for each transaction.
3.2.2.1 When should payment accounts be aggregated for the calculation
Payment service providers must always try to identify whether two payment accounts are actually linked
to the same payee using the information available to them. However, payment accounts should only be
aggregated when they refer to the same payee. Following the definition of the PSD2, this implies that
the holder of both payment accounts must be a single natural or legal person.
In application of this rule, aggregation is to be performed when the payment accounts are owned by the
same person, company, or a branch of the same company. On the opposite, no aggregation should take
place when the owners of the payment accounts are different entities, even if linked between themselves.
This is for example the case for franchises or subsidiaries which should not be subject to aggregation.
N.B.: in the specific case where an account is held by two or more holders, the payee shall be
considered as being all the holders put together. This implies that if one of the holders also has another
payment account, the aggregation should not take place unless all the holders of both accounts are
the same.
Example: Mr. X and Mr. Y hold a bank account to receive payments for their business activity. Mr.
X also has a bank account with Ms. Z his wife, while Mr. Y has another account alone. In this situation,
none of the account should be aggregated as the owners of the three accounts are not all the same.
3.2.2.2 Data elements to use for aggregation
In order to determine whether a payee behind multiple payment account s is actually a single entity,
payment service providers are free to use any information at their disposal, including information
collected during the creation of the payment account. Indicators with a high degree of fuzziness, such as
names, should only be used when they offer a reasonable degree of uniqueness in the individual case in
order to avoid distorting the reporting (e.g. avoid aggregation of common names).
However, among the data elements to be transmitted to CESOP, there are a number which can also serve
as indicator that the payee is a single entity:
1. VAT/Tax Number: although this data element might not always be available to the payment
service provider, when it is it can be a strong hint that the payees between two payment accounts
are actually a single entity. Indeed, only a single company will be allowed to share the same VAT
or Tax number14. As such, when payment service providers can determine that the payees of two
payment accounts share the same VAT/Tax number, it is very likely that these payees are a single
entity.
2. Name: the name of the payee can also help identify that it is the same entity. Although it can be
subject to mistake, and companies could switch between their legal and business name, it remains
an indicator that two payees might be a single entity. Especially if coupled with t he address or
other information available to the payment service provider.
14 However, there might be use cases where different payees share the same VAT number such as VAT grouping. The VAT
group is however a VAT concept that does not change the legal structure of a company for other purposes. Therefore,
each member of a VAT group should be considered as an individual payee.
50
3. Address: even if their names differ, the fact that two payees share the same address is also an
indicator that they might be the same entity. This should of course be cross -checked with other
information available but can still prove useful in aggregating payment accounts.
4. Other: as said above, payment service providers are free to use any information at their disposal
to aggregate payment accounts. This could include for example business identification number,
IP address, E-mail address, contracts, etc.
3.2.3 Practical application
3.2.3.1 Aggregation of multiple payment methods
Figure 30 – Aggregation of multiple payment methods to a single payee.
In this situation, a multitude of payers, having payment accounts with a single payment service provider
are initiating payments toward a single payee. The payee offers different payment methods, such as
credit transfer, direct debit, and card payments which are all used by the payers and are all managed by
different payment service providers for the payee.
In application of the basic rules, the payment service provider of the payers should normally calculate
the threshold using each identifier separately. As such, only the 30 card payments should be reported to
CESOP.
However, since the payee at the end is a single entity, the payers’ payment service provider must identify
whether all these payment accounts are actually linked to a single entity. If for example, the name and
address of the payee as available for all payment methods is the same, the payers’ payment service
provider could safely consider that the payee behind these payments account is a single entity and as
such aggregate all payments.
51
On the opposite, the aggregation should only be performed on the payments executed by a single
payment service provider per Member States. As such, the payment service providers of the payee must
not aggregate the payments between each other since they cannot know what is done by the others.
N.B.: even though the payer’s payment service provider will not report the transaction as it is intra -
EU, it should still perform the aggregation in application of Article 243b (3), see section 3.2.3.6 and
section 4.3.
3.2.3.2 Aggregation of multiple payee’s account within a single payment service
provider
Figure 31 – Aggregation of multiple payee’s accounts within a single payment service provider.
In this situation, the payment service provider of the payee receives multiple payment to different
payment accounts which are all owned by a single payee. In order to identify whether the payments to
these accounts should be reported the payment service provider will have to use the information it has
available to determine that the accounts refer to the same payee and aggregate all the payments it
executes to these payment accounts.
The payment service provider of the payer on the other hand will not be subject to the reporting
obligation in accordance with Article 243b (3) as there is a payment service provider of the payee in the
European Union. It will however have to take these payment s into consideration for the calculation of
the threshold in case it sho uld also report payments to a non -EU payment account of the same payee
(see section 4.3).
52
3.2.3.3 Payee is a franchise
Figure 32 – Non-aggregation of franchise
In this case, the payees adopt a franchise model where they all share a similar trade name or brand and
distribute the same products, however they are all independent and different legal entities.
As explained previously, aggregation should only take place when the payment accounts are all owned
by the same legal entities. In the case of a franchise, all entities will be different and have different
VAT/Tax numbers. With this information available, the payment service provider of the payee can easily
determine that they are not the same payee despite their close name and will not have to aggregate
payments to the various accounts.
3.2.3.4 Aggregation of “Master” account
In this situation, the payee uses a main account within a single payment service provider to receive funds
and later redistributes the payments to various “sub -accounts” and various payees. This process is
especially common for marketplaces which will tend to centralise payments before redistributing them.
In such case, it is important to keep in mind that Article 243b (2) does not include any form of
disaggregation even if the data suggests that these accounts are used by multiple payees. This means that
multiple payment accounts could be aggregated, but a single payment account should never be divided
even if in practice this payment account will serve multiple payees.
As such, when faced with this situation, the payment service providers will have to calculate the
payments executed to the “master” account and report them, without looking at the sub-accounts.
53
Figure 33 – Calculation of threshold for master accounts
3.2.3.5 Aggregation by E-money providers and marketplaces
Figure 34 – Aggregation by E-money providers and marketplaces
In this case, the payments are centralised by an intermediary (E-money institution or marketplace) which
holds the funds before redistributing them to various payment account s of the payee. Contrary to the
case of the master account, the payee here does not hold a single account but several where it receives
the funds transmitted by the intermediary (e.g. E-money account, bank account, etc.).
For the payment service provider of the payers , all these payments will be sen t to the intermediary
account, meaning there is no need to aggregate (nor disaggregate). The intermediary however will have
to use the information it has available to aggregate all the payments executed to the payee’s various
payment accounts.
54
3.2.3.6 Aggregation per Member State
Figure 35 – Payer’s payment service providers in different MSs and Payee’s payment service providers
in 3rd countries
In this case, the payer’s payment service provider has different branches or subsidiaries in different
Member States, each of them processing 20 payments to the same payee in a third countr y during one
reporting period.
According to Article 243b(2) of the VAT Directive, the aggregation shall be done per Member State
where the payment service provider is providing the payment services. Therefore, each branch of the
payer’s payment service provider provides payment services respectively in Member State 1 and
Member State 2, and thus those branches will not aggregate the payments from each Member State.
The subsidiary of the payer’s payment service provider - on the other hand - is a different legal entity
and therefore should never aggregate its payments with those of the branches since they are not the same
payment service provider. In the situation in figure 35, the branch of the payer’s payment service
provider in Member State 2 and the subsidiary in Member State 3 are processing 20 payments each per
reporting period. Thus, they have no reporting obligation. The branch of the payer’s payment service
provider in Member State 1 is processing 30 payments to the same payee in the third country during the
reporting period and will have to report these 30 payments in Member State 1.
55
Figure 36 – Payer’s payment service provider in different MSs, payee and the payee’s payment service
providers in several third countries
In this case the branches and subsidiaries of the same payer’s payment service provider in the different
Member States will not aggregate the payment s from each branch/subsidiary to the third countr ies, as
seen in the previous case.
However, if the subsidiary of the payer’s payment service provider in M ember State 3 has the
information that the payee in the 3 rd country 1 is the same entity as the payee in the 3 rd country 2, then
it will aggregate these payments for the calculation of the threshold and will report these payments
(20+20) in Member State 3.
56
Figure 37 – Payee’s payment service provider in different MSs – case 1
In this situation the payee’s payment service provider has branches in different Member States and are
receiving payments from payers’ payment service providers located in different Member States.
Based on the experience of the payment service providers consulted for the drafting of these guidelines,
this situation is largely theoretical, because the same payee would not use different branches of the same
payment service provider in different Member States.
However, should this situation happen, the different branches of payee’s payment service provider would
not aggregate the payments received at the other branches of the payee’s payment service provider in
the other Member States for the calculation of the threshold. Each branch of the payee’s payment service
provider will only take into account the payments received by that branch in that Member State only
Article(therefore, the payee’s payment service provider branch in Member State 4 will only take into
account payments received in Member State 4, the branch in Member State 5 only the payments received
in Member State 5, and branch in Member State 6 only the payments received in Member State 6).
In that specific case, because the payee’s payment service provider branches in Member State 4 and
Member State 5 receive only 20 payments each, they will have no reporting obligations . On the other
hand, the branch in Member State 6 is receiving 30 payments during a reporting period and will report
these 30 payments in Member State 6.
N.B.: It is important to note that if the branches of the same payment service provider were located in
the same Member States, they would have constituted the same payment service provider providing
payment services in a single Member States and would therefore need to aggregate their payments
received to the same payee.
57
Figure 38 – Payee’s payment service provider in different Member States - case 2
In this situation, the same payee’s payment service provider has different branches in different Member
States. The branch in Member State 4 is receiving payments from payers in different Member States.
All these payments (20+20+20) will trigger the reporting obligation in Member State 4.
However, as seen in the situation described above under Figure 37, the different branches of the payee’s
payment service provider in Member States 5 and 6 will not aggregate the payments received in the
different Member States. Therefore, only the branch in Member State 4 will report the payments received
by the same payee from Member States 1, 2 and 3.
4 REPORTING
4.1 What triggers the reporting obligation?
Article 243b (1) of Directive 2006/112/EC, added by Directive 284/2020 , establishes all the rules
applicable to the reporting obligation. According to this Article, and as explained in section 2 and 3 of
these guidelines, there are two elements that must be take n into consideration to tr igger the reporting
obligation:
- Whether the conditions to be in scope are fulfilled (see section 2).
- Whether the monitoring conditions are fulfilled (see section 3).
In practice, this implies that only payment service providers who are providing the payment services in
scope of the reporting obligation (as laid down in Article 243a of Directive 2006/112/EC), and which
execute more than 25 cross-border payments per quarter to a given payee should report the data.
58
These two conditions must be checked and fulfilled during each calendar quarter for the reporting
obligation to take place.
For example, if during a calendar quarter a payee fulfil s these conditions with a payment service
provider, the payment service provider must include this payee in its reporting. However, if it happens
that during the following calendar quarter, the same payment service provider does not execute more
than 25 cross-border payments to this payee, then it must not include it in its reporting.
If again the payee was to exceed the threshold in the following quarter, then the payment service
provider must include the payments it has received during that quarter in its quarterly reporting.
4.2 How often shall the data be reported?
Article 243b(1) of Directive 2006/112/EC, added by Directive 284/2020, lays down the rules regarding
the period of reporting.
Member States shall require payment service providers to keep sufficiently detailed records of payees
and of payments in relation to the payment services they provide for each calendar quarter to enable
the competent authorities of the Member States to carry out controls of the supplies of goods and
services which, in accordance with the provisions of Title V, are deemed to take place in a Member
State, in order to achieve the objective of combating VAT fraud.
According to this paragraph, payment service providers are required to keep detailed records of the
payees and the payments they receive each calendar quarter. This constitutes the period over which
information shall be collected and referred to. Following this, Article 24b (1)(a) of Regulation 904/2010,
as added by Regulation 283/2020, indicates the period over which Member States shall collect the data.
Each Member State shall collect the information on the payees and the payments referred to in
Article 243b of Directive 2006/112/EC.
Each Member State shall collect the information referred to in the first subparagraph from payment
service providers:
(a) no later than by the end of the month following the calendar quarter to which the information
relates;
These two articles combined provide the timeline for the reporting of payment data from payment service
providers. This reporting will take place every quarter starting from January 2024 and will require
payment service providers to send the data to the Member States at the latest by the end of the month
following the calendar quarter to which the data relates.
The table below lists the four reporting periods for payment service providers and the respective dat es
by which the data must be submitted to the Member States.
Reporting periods for payment service providers:
• 1st Period (January- March): 30 April
• 2nd Period (April-June): 31 July
• 3rd Period (July-September): 31 October
• 4th Period (October- December): 31 January
59
Once the data has been collected by Member States, they shall transmit it to CESOP by the 10 th day of
the second month following the end of the reporting period, according to Article 24b(3).
The table below sets out the deadlines for the transmission of the data to CESOP by Member States.
Deadlines for the transmission of data to CESOP:
• 1st Period (January- March): 10 May
• 2nd Period (April-June): 10 August
• 3rd Period (July-September): 10 November
• 4th Period (October- December): 10 February
4.3 Who shall report the data under Article 243b(3)?
Notwithstanding that a payment service provider may be in scope of the reporting obligation, Article
243b (3) limits the obligations of the payment service provider of the payer.
The requirement laid down in paragraph 1 shall not apply to payment services provided by the
payment service providers of the payer as regards any payment where at least one of the payment
service providers of the payee is located in a Member State , as shown by that payment service
provider’s BIC or any other business identifier code that unambiguously identifies the payment service
provider and its location. The payment service providers of the payer shall nevertheless include those
payment services in the calculation referred to in paragraph 2.
In practice, the payment service provider of the payer will not have to keep records on the payees where
at least one of the payment service providers of the payee is located in a Member State, as shown by this
payment service provider’s BIC or other business identifier. It is only when there are no payment service
providers of the payee in a Member State that the payment service provider of the payer will have to
keep and report data.
N.B.: the requirement to be located in a Member State shall be understood as a Member States in the
territorial meaning of Article 5(2) of the VAT Directive and should not as such include third territories
as defined in Article 6 of the VAT Directive. As such, if the payment service provider of the payee is
established in a third territory, the reporting shall be done by the payment service provider of the
payer.
This means that when the payment service providers of the payee are in a Member State, the reporting
obligation shall fall exclusively on them. The Article does not create a limit regarding the number of
payment service providers that should report the transaction, meaning that i f, based on their business
model, more than one payment service provider is involved in the payment from the paye e’s side (for
example because of subcontracting), then all payment service providers of the payee shall be responsible
to report data.
In the specific case of payment refunds, the reporting can be performed by the payment service provider
that reported the original transaction as it is the best placed to link both reporting.
Finally, the last sentence of Article 243b(3) establishes a special rule regarding the threshold calculation:
even if a payment shall not be reported by a payment service provider in application of this rule, it shall
still be included in the calculation and aggregation of the 25 cross-border transactions threshold.
60
Example: A payment service provider from Member State 1 (payer’s payment service provider)
executes payment transactions to a payee that has a payment account in Member State 2 and another
in a third country. Over a given quarter, the payment service provider of the payer executes:
− 200 payments to the payment account in Member State 2,
− 20 payments to the payment account in the third country.
In application of the rules of Article 243b, all the conditions to trigger the reporting obligation are
fulfilled, however the payment service provider of the payer will not report the payments to the
payment account in Member State 2, as those will be reported by the payment service provider of the
payee in Member State 2.
It will however have to report the payments to the payment account in the third country, as the
threshold must be calculated inclusive of the payments to the payment account in Member State 2 and
is therefore exceeding 25 cross-border payments.
4.3.1 Practical application
4.3.1.1 Payee’s payment service provider and payee are in another Member State
This example is a clear application of the rules laid down in Article 243b. According to Article 243b(3)
–all other conditions being fulfilled – the payment service provider of the payee, when located in a
Member State, will be solely responsible for the reporting obligation.
Figure 39 – Reporting when payment service provider of the payee is in another Member State
61
4.3.1.2 Payee’s payment service provider and payee are in a third country
This is also a straightforward application of the rules laid down in Article 243b. Since there is no payment
service provider of the payee located in another Member State, the payment service provider of the payer
will be responsible for the reporting obligation.
Figure 40 – Reporting when payment service provider of the payee is in a third country or territory
4.3.1.3 Payee’s payment service provider is in a Member State and payee in a third
country
Figure 41 – Reporting when payment service provider of the payee is in a Member State but payee is in
a third country or territory
62
In this case the payee who is located in a third country, uses a payment service provider that is located
in a Member State. Since Article 243b(3) limits the reporting of the payment service provider of the
payer when the payment service provider of the payee is in a Member State, the payment service provider
of the payee shall be solely responsible for the reporting obligation.
4.3.1.4 Payee in a Member State with multiple payment service providers involved
in the payment transaction
In this situation, the payee uses multiple payment services providers located in different Member States
to process a payment transaction. Given that Article 243b(3) does not include any limitation to the
number of payment service providers of the payee responsible for the reporting, all of them that fulfil
the conditions to be in scope of the reporting obligation shall be responsible to report the payment.
N.B.: an intermediary in the payment transaction shall not be responsible to report any payment if its
activities only cover the provision of technical services which only support the provision of payment
services without it entering into possession of the funds to be transferred at any time, since these
entities do not qualify as payment service providers.
Figure 42 – Reporting when multiple payment service providers of the payee are in Member States
63
4.3.1.5 The payee is in a third country but uses a payment service provider in a
Member State
Figure 43 – Reporting when at least one payment service provider of the payee is in a Member State
In this example, the payee is located in a third country and has a payment account with a non -EU
payment service provider. However, since the payee also uses an intermediary in the European Union,
such as a marketplace or an E-money provider, in order to supply the EU market, that intermediary will
be responsible for the reporting obligation.
The payment service provider of the payer and the payee’s bank located in the third country will not
have to report data.
4.3.2 The situation of EEA countries
EEA countries are included in the territorial scope of the PSD2, and non -Union EEA States can have
payment service providers providing payment services in the EU. The limitation rule of Article 243b
only applies when these payment service providers have a presence in another Member State that can be
verified using the IBAN or other business identifier of the EEA payment service provider.
This means that if the payment service provider of the payee is located in an EEA country, according to
its IBAN or other business identifier, it is the payment service provider of the payer that will have to
report the data. In contrast, if a payment services provider from an EEA country operates branches in a
Member State, these branches will be subject to the reporting obligation and could be considered as
payment service providers of the payee.
64
4.4 Where should the data be reported?
The rules regarding where the data shall be reported are laid down in Article 243b(4)(b) of the amended
VAT directive.
Where the requirement for payment service providers laid down in paragraph 1 applies, the records
shall:
(b) be made available in accordance with Article 24b of Regulation (EU) No 904/2010 to the home
Member State of the payment service provider, or to the host Member States when the payment
service provider provides payment services in Member States other than the home Member State.
According to this Article, payment service providers shall report the payment data to their home Member
State or, when they provide payment services in several Member States, to the host Member State(s).
This applies in all cases where the payment service provider has the reporting obligation as payee’s PSP
or as payer’s PSP or both.
The definition of home and host Member State are included in Article 243a of the Directive, which refers
directly to the relevant Article of the PSD2.
According to the definition of the PSD2, the home Member State will be the Member State where a
payment service provider has requested and obtained its payment license, which should correspond to
the Member State in which it has its registered office or head office.
The host Member State on the other hand will be any Member State other than the home in which the
payment service provider is providing payment services either via an agent, a branch or directly.
It should be noted that the flexibility of using proxies for determining the location of the payer or payee
in line with the cross-border rules of Article 243c cannot be used for the purpose of circumventing the
obligation to report in the host Member State(s) in accordance with Article 243b(4)(b) . As highlighted
in section 3.1.1, payment service providers must use the strongest data available to them to locate their
clients. Payment service provider s must follow their payment licence to determine where they are
providing their payment services and confirm where they must report.
Example: a payment service provider has a payment license from Member State 1 and also supplies
payment services in Member State 2 via a branch, and Member State 3 via an agent.
In application of the rules, this payment service provider will have to report the payments it executes
in Member State 1 to Member State 1, the payments it executes in Member State 2 to Member State
2, and the payments it executes in Member State 3 to Member State 3.
Example 2: an E-money provide has a payment license to provide payment service s from Member
State 1. It then uses passporting rules to provide payment services in all other Member States of the
Union. According to the rule of Article 243b(4), it will report data in all Member States for the
respective payments it executes in each one of them.
65
4.4.1 Direct provision of payment services in the host Member States
Determining the Member States where a payment service provider should report its payments is made
easier when it has a physical presence in these Member States, such as when it does so via a branch or
an agent. Where payment services are provided directly from one Member State to another is slightly
more complex as there is no physical presence which allows a clear differentiation between the activities
in the host Member State and the home Member State.
Payment service providers should follow their payment license to determine where they provide
services. A payment service provider has to inform the authority of the host Member State before it can
provide payment services in its territory, which is then documented in the register of payment service
providers of that Member State 15. Through that register, and using the information available from its
client database, a payment service provider should be able to clearly identify which services are provided
where.
Example: An E-money provider has its payment license in Member State 1 and also provides payment
services in Member State 2 and 3. In order to determine what data should be reported in each Member
State, it will look at its payment license and where its clients are located.
As such, if the E-money provider acts as the payment service provider of the payer for payments going
from Member State 1 to a third country, it will report these payments in Member State 1. If it acts as
payment service provider of the payee for payments going from Member State 3 to Member State 2,
it will report these payments in Member State 2.
4.4.2 The situation of EEA countries (Iceland, Liechtenstein, Norway)
As we explained in session 2.1.1., the PSD2 also applies to countries that are members of the EEA. This
means that these countries can legally obtain a payment license in their home country, and then use
passporting rules to provide payment services all over the European Union, including the direct provision
of payment services without a physical presence.
As we said in section 4.3.2., payments to EEA countries shall be considered as payments to third
countries. In such cases, the payment service provider of the payer established in a Member State will
report the payment in the Member State of the payer (whether it is its host or home Member State).
In contrast, payment service providers established in EEA countries who provide payment services in
the European Union will have to report these payments in their host Member State. However, the rules
of Article 243b still apply, and only payments initiated by a payer (or through a payer’s mandate in the
case of direct debits) in the European Union (according to the location rules of Article 243c) shall be
reported to CESOP. As such, they should not report payments that are initiated from an EEA country.
Example: a payment service provider with a payment license from Norway provides payment services
in Sweden and Iceland. According to the rules of Article 243b, this payment service provider will:
- Report in Sweden all payment that are initiated by payers in Sweden to Norway, Iceland or any
other third country.
- Report in Sweden all payments going to payees in Sweden where the payer is in a Member State
other than Sweden.
15 Information on the home and host Member States of a payment service provider can also be found on the European Bank
Authority website (https://euclid.eba.europa.eu/register/)
66
- Not report any payments between Norway and Iceland or between either Norway or Iceland and
any third country.
- Not report any payments that are initiated by payers in Sweden to payees in another Member State.
4.5 What data should be reported by payment service providers?
The list of data that needs to be reported is laid down in Article 243d of the amended Directive 2006/112
and can be divided into two sets of data: data related to the payee (Article 243d (1)), and data related to
each payment received by the payee (Article 243d(2)).
1. The records to be kept by the payment service providers, pursuant to Article 243b, shall contain
the following information:
(a) the BIC or any other business identifier code that unambiguously identifies the payment service
provider;
(b) the name or business name of the payee, as it appears in the records of the payment services
provider;
(c) if available, any VAT identification number or other national tax number of the payee;
(d) the IBAN or, if the IBAN is not available, any other identifier which unambiguously identifies,
and gives the location of, the payee;
(e) the BIC or any other business identifier code that unambiguously identifies, and gives the
location of, the payment service provider acting on behalf of the payee where the payee receives
funds without having any payment account;
(f) if available, the address of the payee as it appears in the records of the payment services
provider;
(g) the details of any cross-border payment as referred to in Article 243b(1);
(h) the details of any payment refunds identified as relating to the cross-border payments referred to
in point (g).
2. The information referred to in points (g) and (h) of paragraph 1 shall contain the following
details:
(a) the date and time of the payment or of the payment refund;
(b) the amount and the currency of the payment or of the payment refund;
(c) the Member State of origin of the payment received by or on behalf of the payee, the Member
State of destination of the refund, as appropriate, and the information used to determine the
origin or the destination of the payment or of the payment refund in accordance with Article
243c;
(d) any reference which unambiguously identifies the payment;
(e) where applicable, information that the payment is initiated at the physical premises of the
merchant.
67
This data has to be transmitted via a standard XML form which is detailed in the Annex to Implementing
Regulation16. The specification for the form (XML Schema Definition) together with the user guide are
available on the dedicated CESOP page of the Europa website17.
Given the multitude of data elements that can be collected for the different fields, the following section
will focus on detailing what is expected for each data field and try to provide examples of data elements
for each of the main payment methods that could be reported to CESOP. This list is not exhaustive and
other elements could be valid as long as they correspond to the data listed in Article 243d.
4.5.1 Overview of data elements
According to the annex to the Implementing Regulation, there are 15 main data elements to be included
in the electronic form which represents the data requested under Article 243d of the VAT Directive.
These data elements are listed in the table below which also includes a description of what they shall
represent and whether the data is mandatory or not. For the purpose of the table, the following definitions
shall apply:
− Mandatory: this data element shall always be provided and present in the form. Failure to
provide the data element may result in a potential or partial rejection of the form and a non-
compliance with the reporting obligation.
− Optional mandatory: this data element shall always be provided when it is available to the
payment service provider. Failure to provide the data element when it is available will result
in non-compliance with the reporting obligation. However, if the data is not available to the
payment service provider and the field is not completed, the form will not be rejected , and
the reporting obligation will still be considered fulfilled.
− Mandatory when applicable: this data element shall be provided when the specific
conditions for it to be requested are fulfilled. Failure to provide the data element when the
conditions are fulfilled will result in a rejection of the form and non -compliance with the
reporting obligation. If the conditions are not fulfilled, then the data will not have to be
provided. Most of the data elements marked as such regard choices between two possibilities
which are mutually exclusive.
16https://ec.europa.eu/taxation_customs/system/files/2022-
04/C_2022_2043_F1_COMMISSION_IMPLEMENTING_REGULATION_EN_V3_P1_1727569 -1.pdf
68
Table 2 – Overview of data elements to be transmitted
Box
N°
Data Element
Name
Art.
243d
Description Mandatory
1 BIC/ID
reporting PSP
(1),
point (a)
This data element will be used to identify the payment service
provider who has the legal reporting obligation to report the
payment data to the tax authority. In the event that an
intermediary or headquarter is reporting on behalf of the PSP,
they must ensure that the correct PSP ID/ BIC associates with
the PSP who has the legal responsibility to report the data. The
data to be reported should be:
• The Business Identifier Code (BIC) as defined in Article
2, point (16), of Regulation (EU) No 260/2012 of the
European Parliament and of the Council18 of the payment
service provider reporting the data or;
• any other business identifier code that unambiguously
identifies the payment service provider transmitting the
data. This can include national identifiers such as
corporate numbers, national registration numbers, etc.
This box should not be confused with the data element in box
5. Although the identifiers requested are the same, box 1 refers
to the identifier of the payment service provider reporting the
data, while the one in box 5 refers to the identifier of the
payment service provider acting on behalf of the payee, which
can be different from the one reporting the data if the payment
goes outside the EU.
Mandatory
2 Payee name (1),
point (b)
Under this field, all available names of the payee, as available
in the records of the payment servi ce providers, shall be
provided. If the payment service provider has no records for
the payee, the name introduced by the payer shall be
considered as the name in the records. Names can include the
legal name, the “doing business as” (DBA) name , the name
used for registration and contacts, etc.
If the name in the records conflicts with the name introduced
by the payer to initiate the payment transaction, the name in
the records shall take precedence.
Mandatory
3 Payee
VAT/TIN
(1),
point (c)
Under this field, all available tax numbers of the payee shall
be provided. These can include the European VAT
identification number, the national VAT identification
number, the tax identification number (TIN), or any national
number which, although not strictly related to tax purposes or
issued by a tax authority, is used for tax purposes and allows
the unique identification of its holder (e.g. social security
numbers, corporate registration number, etc.).
Optional
Mandatory
18 Regulation (EU) No 260/2012 of the European Parliament and of the Council of 14 March 2012 establishing technical and
business requirements for credit transfers and direct debits in euro and amending Regulation (EC) No 924/2009 (OJ L 94,
30.3.2012, p. 22).
69
4 Payee account
ID
(1),
point (d)
This field aims to precisely identify the payment account of
the payee where the funds are being transferred. As such, it
shall include either:
• the IBAN of the payee’s payment account, as defined in
Article 2, point (15), of Regulation (EU) No 260/2012 or;
• any other identifier, which unambiguously identifies and
gives the location of the payee involved in the transaction.
This can include Merchant ID (MID), E-money accounts,
SWIFT registration numbers, national account numbers,
etc.
Article 243d (1)(d) establishes a priority for the IBAN. It is
only when it is not available that another identifier should be
provided.
Mandatory when
applicable, if
funds are
transferred to a
payment account
of the payee.
5 BIC/ID Payee
PSP
(1),
point (e)
This field aims to identify the payment service provider acting
on behalf of the payee when the payee receives funds without
having a payment account (money remittance). As a payment
account does not exist, an identifier for it under box 4 cannot
be collected. As such, the reporting entity will have to provide
the identifier of the payment service provider acting on behalf
of the payee.
Under this field, the data to be provided is either:
• The Business Identifier Code (BIC) as defined in Article
2, point (16), of Regulation (EU) No 260/2012 of the
European Parliament and of the Council of the payment
service provider acting on behalf of the payee or;
• any other business identifier code that unambiguously
identifies the payment service provider acting on behalf of
the payee . This can include national identifiers such as
corporate numbers, national registration numbers, etc.
This field should not be confused with the data requested under
box 1 (see above). In addition, boxes 4 and 5 are mutually
exclusive and only one of them should be completed.
Mandatory when
applicable, if
funds are
transferred to a
payee without a
payment account.
6 Payee Address (1),
point (f)
Under this field, all available addresses of the payee that are in
the records of the payment service provider, shall be provided.
Addresses can include the legal address, business address,
warehouse address , as well as e -mail addresses , webpages
addresses or IP address.
Based on the data available to the payment service provider,
the address can be more or less detailed, ranging from the
country to the street. In addition, the address reported does not
need to be aligned with the one used under Article 243c to
determine the location of the payee. This means for example
that the address reported can be in a different country than the
one of the payee’s payment accounts (IBAN).
This field shall only be completed if the payment service
provider has at least one address for the payee in its records. If
the payment service provider has no address in its record but
the address can be deduced from the payment account (e.g.
Optional
Mandatory
70
country code of an IBAN) , this field does not need to be
completed.
7 Refund (1),
point (h)
This field is intended to differentiate between payments made
by a payer and refunds made to a payer.
Refunds can include technical refunds as defined in the PSD2
but also commercial refunds, or any other type of refund as
long as the payment service provider is aware of it. If a
payment service provider is not aware that a transaction is a
refund, it is not asked to verify whether any given payment is
a refund or not. It should then consider and report it as a regular
payment (given that all other conditions for the reporting are
fulfilled).
Refunds are allowed to be reported regardless the fact that the
original payment was reported. In case where the original
payment and the refund take place in two different reporting
quarters, the refund should not be reported in its reporting
quarter if the original payment was not reported earlier. Under
this field, payment service providers shall indicate that the
payment is a refund , if this information is available to them .
The refund transaction ID and reference to the original
transaction shall be reported in box 14.
Mandatory (when
the information is
available)
8 Date/time (2),
point (a)
Under this field, the date and time of the payment shall be
reported. Given the multitude of date s available for a single
payment transaction, it is possible for payment service
providers to report multiple dates.
However, in order to facilitate the detection of multiple
reporting and the standardisation of the reporting , the
following sections list, for each payment method, at least one
date that is common between all the payment service providers
involved in a single payment transaction and which should
always be reported.
One of the ‘DateTime’ element in the ‘ReportedTransaction’
element must refer to a date within the period and year
declared in the ‘ReportingPeriod’ element. The
‘DateTime‘ element must contain the specified date as
outlined for ‘2a Date and time‘ as per ‘Table 9 – Overview of
data and expected data quality levels‘.
PSPs may become aware of a transaction that occurred during
a reporting period after the reporting quarter has ended. This
transaction may be reported in line with the XSD User Guide.
If the transaction is reported in the second affected quarter, the
PSP must provide multiple dates for the transaction. One of the
dates provided must be in line with required
‘DateTime‘ element per payment method for ‘2a Data and
time‘ of ‘Table 9 – Overview of data and expected data quality
levels‘.
Mandatory
9 Amount (2),
point (b)
Under this field, the total a mount of the payment transaction
or of the payment refund shall be reported.
Mandatory
10 Currency (2),
point (b)
Under this field, the currency of the payment transaction or of
the refund transaction shall be reported.
Mandatory
71
When there is a change of currency, the amount of the payment
shall be reported in the original currency before booking and
currency conversion by any of the payment service providers.
11 MS origin
payment
(2),
point (c)
Under this field, the country code for the Member State of
origin of the payment received by the payee shall be provided.
Payment service providers must indicate the Member State of
origin resulting from the information indicated in box 13 and
in accordance with Article 243c. In case s where a payment
service provider can identify several Member States for the
origin of the payment, it must use the one that most accurately
corresponds to the location of the payer (see section 3.1.1).
Mandatory when
applicable, if
transaction is a
payment
12 MS
Destination
refund
(2),
point (c)
Under this field, the country code f or the Member State of
destination of the refund received by the payer shall be
provided.
All the rules applicable to box 11 also apply here.
Mandatory when
applicable, if
transaction is a
refund under box
7
13 Payer Location
information
(2),
point (c)
Under this field, the information used to determine the origin
of the payment, or the destination of the refund shall be
provided in accordance with Article 243c.
The information can include any data element available to the
payment service provider, as described in box 11 (IBAN,
address, card number, etc.). It is important to note that this field
shall only indicate what data was used, the data itself must not
be transmitted.
This implies that payment service provider will for example
indicate that the location of the payer was established in a
Member State using the IBAN of the payer’s payment account.
The IBAN of the payer itself , however, shall never be
transmitted.
Mandatory
14 Transaction ID (2),
point (d)
This field aims to allow easy identification of payment
duplicates. As such, any reference which unambiguously
identifies the payment transaction shall be reported under this
field.
When several transaction identifiers are available, priority
should always be given to the one that is pass ed along the
payment chain and is available to other payment service
providers in the payment chain.
In the case of refunds, as detailed in box 7, the transaction
identifier reported for the refund does not have to be different
to the identifier of the initial transaction and shall still be
unique. Payment service providers can decide to use the same
or different identifier for the original payment and refund.
Mandatory
15 Physical
presence
(2),
point (e)
This field aims to allow an easy identification of the physical
payments made by the payer at the premises of the payee, in
opposition to online payments, see Article 243d (2e) :
Information that the payment is initiated at the physical
premises of the merchant.
Mandatory when
applicable
72
Under this field, any reference which indicates the presence of
the payer in the physical premises of the merchant when
initiating the payment shall be reported.
73
4.5.2 Data to be reported per payment method
4.5.2.1 Credit transfer
In a regular credit transfer, the payer will initiate an order for its bank to transfer funds to the bank
account of the payee.
Table 3 – Overview of data elements to be transmitted for credit transfer
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Yes
Yes
BIC (ISO 9362)
2 Payee name
Yes
Yes
3 Payee
VAT/TIN
Not always
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process the payments. They
might be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
As such, payment service providers that do
not collect the VAT number/TIN of their
clients are not obliged to transmit this data.
Payment service providers of the payee are
more likely to have VAT number/TIN or
other identifier based on “know your
customer” (“KYC”) requirements.
4 Payee account
ID
Yes Yes IBAN (ISO 13616)
For payments to a country that does not use
IBAN, national account number s can be
provided instead.
5 BIC/ID Payee
PSP
Yes Yes BIC (ISO 9362) An account number should always be
available in SEPA credit transfer s and
allow for identification of the payee’s bank
account.
For credit transfers outside the SEPA area,
it is possible that the account number alone
is not sufficient to identify the bank
account of the payee. In that case, payment
service providers should also provide the
BIC or other identifier of the payee’s
payment service provider.
6 Payee Address Not always Yes / The address is not mandatory in order to
process payments via credit transfers but
shall be available to payment service
providers of the payee through KYC
obligations.
7 Refund Yes Yes /
74
8 Date/time Yes Yes Settlement date
9 Amount Yes Yes Amount should be
reported with two
decimals
10 Currency Yes Yes ISO 4217
11 MS origin
payment
Yes Yes ISO 3166-1 Alpha 2
12 MS
Destination
refund
Yes Yes ISO 3166-1 Alpha 2
13 Payer Location
information
Yes Yes Not applicable
14 Transaction ID Yes Yes No standard Transaction ID s for credit transfer s are
proprietary to the payment service provider
and are only unique within a payment
service provider’s system.
15 Physical
presence
Not
applicable
Not
applicable
4.5.2.2 Direct debit
As described in section 1, direct debits work mainly like credit transfers with the exception that the
payment is initiated by the payee instead of the payer. It is important to highlight again that there are
currently no existing standards for non-SEPA direct debit. As a consequence, international direct debits
are performed using ad-hoc rules which are either copied from the SEPA rules or from national systems.
Because of this, the figure below focuses on the standards applicable to the payee’s reporting, as no
standards exists for reporting done by the payer in non-EU payments.
Table 4 – Overview of data elements to be transmitted for direct debits
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Not
applicable
Yes
BIC (ISO 9362)
2 Payee name
Not
applicable
Yes
3 Payee
VAT/TIN
Not
applicable
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process payments. They might
be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
As such, payment service providers that do
not collect the VAT number/TIN of their
clients are not obliged to transmit this data.
75
Payment service providers of the payee are
more likely to have a VAT number/TIN or
other identifier s based on “know your
customer” (“KYC”) requirements.
4 Payee account
ID
Not
applicable
Yes IBAN (ISO 13616)
5 BIC/ID Payee
PSP
Not
applicable
Not
applicable
/ An account number should always be
available in direct debits.
6 Payee Address
Not
applicable
Yes / The a ddress is not mandatory to process
payments via direct debit s but shall be
available to payment service providers of
the payee through KYC obligations.
7 Refund
Not
applicable
Yes /
8 Date/time
Not
applicable
Yes Settlement date
9 Amount
Not
applicable
Yes Amount should be
reported with two
decimals
10 Currency
Not
applicable
Yes ISO 4217
11 MS origin
payment
Not
applicable
Yes ISO 3166-1 Alpha 3
12 MS
Destination
refund
Not
applicable
Yes ISO 3166-1 Alpha 3
13 Payer Location
information
Not
applicable
Yes Not applicable
14 Transaction ID
Not
applicable
Yes / Transaction ID s for direct debits are
proprietary to the payment service provider
and are only unique within a payment
service provider’s system.
15 Physical
presence
Not
applicable
Not
applicable
/
4.5.2.3 Money remittance
Money remittances differ from other payment methods by the fact that they do not necessarily require a
payment account to execute the payments. Although it is nowadays possible to include payment accounts
in money remittance orders, it is still possible to transfer funds without these. As such, the main
difference for money remittance institutions will be to provide an identifier in box 5 to identify the
disbursement partner in the absence of a payment account identifier.
Table 5 – Overview of data elements to be transmitted for money remittances
76
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Yes
Yes
BIC (ISO 9362)
2 Payee name
Yes
Yes
3 Payee
VAT/TIN
Not always
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process the payments. They
might be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
As such, payment service providers that do
not collect the VAT number/TIN of their
clients are not obliged to transmit this data.
Payment service providers of the payee are
more likely to have a VAT number/TIN or
other identifiers based on KYC
requirements.
4 Payee account
ID
Not
applicable
Not
applicable
IBAN (ISO 13616)
Traditional money remittances do not
require a payment account to be executed.
It is however possible to provide the
information. If this is the case, then it must
be reported instead of the BIC in box 5.
5 BIC/ID Payee
PSP
Yes Yes BIC (ISO 9362) The BIC or other identifier shall allow the
identification of the payment service
provider where the funds are sent if t he
payee receives funds without having any
payment account.
If no BIC is available, then any national
identification number can be provided as
long as it allows unique identification of
the payment service provider.
6 Payee Address Not always Yes / The address is not mandatory to process
payments via money remittances but shall
be available to payment service providers
of the payee through KYC obligations.
7 Refund Yes Yes /
8 Date/time Yes Yes Execution date
9 Amount Yes Yes Amount should be
reported with two
decimals
10 Currency Yes Yes ISO 4217
11 MS origin
payment
Yes Yes ISO 3166-1 Alpha 3
77
12 MS
Destination
refund
Yes Yes ISO 3166-1 Alpha 3
13 Payer Location
information
Yes Yes Not applicable
14 Transaction ID Yes Yes No standard Transaction IDs for money remittances are
proprietary to the payment service provider
and are only unique within a payment
service provider’s system.
15 Physical
presence
Not
applicable
Not
applicable
4.5.2.4 Card payments
Card payments are initiated by the payer using its credit or debit card details in order to trigger a payment
order that will be processed by its card issuer and the payee’s commercial acquirer. Although card
payments can be divided into three party card payments and four party card payments based on the model
used by the issuer and acquirer, the data to be reported will be nearly identical as both systems function
similarly to process payments.
It is also important to note that card payments are heavily dependent on the scheme used to process the
payments. In this regard, it is impossible to review the data exchanged in every existing card scheme .
The below table focus on the rulebooks issued by the two most popular card scheme s for international
transactions, namely VISA and MasterCard.
Please see section 4.5.2.5 for cards associated with an E-money provider.
Table 6 – Overview of data elements to be transmitted for credit card payments
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Yes
Yes
BIC (ISO 9362)
2 Payee name
Yes
Yes
Card acceptor name
(MC DE043)
Merchant name (VISA
TCR0 pos. 92-116)
3 Payee
VAT/TIN
Not always
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process the payments. They
might be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
As such, payment service providers that do
not collect the VAT number/TIN of their
clients are not obliged to transmit this data.
Payment service providers of the payee are
more likely to have a VAT number/TIN or
78
other identifiers based on KYC
requirements.
4 Payee account
ID
Yes Yes Merchant ID / Card
Acceptor ID ( MC
DE042
Merchant ID and Card acceptor ID must be
combined to identify the merchant selling
the goods behind a given acquirer.
5 BIC/ID Payee
PSP
Not
applicable
Not
applicable
/
6 Payee Address Yes Yes MC DE043
VISA TCR0
7 Refund Yes Yes / If reference to the original payment is
included, it should be reported as a separate
and unique transaction ID in box 14
8 Date/time Yes Yes MC: DE 12 - Date and
Time, local transaction
Visa : TC05 Purchase
date
Date should at least include month and
year of the transaction.
9 Amount Yes Yes Mastercard : DE04/
DE05/DE06
VISA : TC05 Source
Amount & Source
currency code
Amount should be
reported with two
decimals.
10 Currency Yes Yes ISO 4217
11 MS origin
payment
Yes Yes ISO 3166-1 Alpha 2 For the location of the payer, the Bank
Identification Number (“ BIN”) range of
the card number shall be used to determine
where the card has been issued rather than
where the issuer is located.
12 MS
Destination
refund
Yes Yes ISO 3166-1 Alpha 3 For the location of the payer, the BIN range
of the card number shall be used to
determine where the card has been issued
rather than where the issuer is located.
13 Payer Location
information
Yes Yes Card number BIN Payment service providers must use the
BIN range that is the closest to the real
location of the payer, meaning the location
where the card has been issued and not the
one where the issuer is located, as
highlighted in section 3.1.1.
14 Transaction ID Yes Yes MC : DE 31—Acquirer
Reference Data
The transaction ID to be reported shall be
the one provided by the acquirer which is
unique within the card scheme used and
common to all payment service providers
involved in the payment. In case the ID is
the same for the different transactions, the
79
Visa : TC05 - Acquirer
Reference Number
PSP must amend the transaction ID to be
unique.
15 Physical
presence
Yes Yes MC : DE 22 Point of
Service (POS) Entry
Mode
Visa : TC05 POS
Entry Mode
4.5.2.5 E-money
A typical E-money payment is initiated by the payer using the funds on its E-money account to order a
transfer to the payee’s E-money account. The funding of the E-money account can be done using
different payment methods (credit transfer, card payment, etc.) and either before the E-money payment
or simultaneously with it (if the payer had no funds on its E-money account to execute the payment).
These payments to fund or withdraw from the E-money account will appear, to the external payment
service providers involved in the transaction, like a payment from the payer to the E-money institutions
which will be identified as the payee (if the payer funds its E-money account) or as the payer (if the
payee withdraws the funds from its E-money account). The E-money account can also take the form of
a pre-paid card in the case of E-vouchers or a card linked to an E-money account, even if funded by a
credit line
E-money payments have the peculiarities in that there are no existing standards for E-money transaction.
E-money payments are often performed in a close system where both the payer and the payee have
contracted with the E-money provider, but this is not always the case following the diversity of business
models that can exist. They are regulated by the rules established by the E-money provider itself, which
as such is free to adopt the rules it wants. This close system on the other hand , allows the E-money
provider to have full visibility on the payment transaction as well as the payer and payee.
Electronic Cards differ from Electronic vouchers as they are often associated with an E-wallet. The cards
can be pre -paid virtual or physical cards or can be funded by a credit line. They also differ from a
traditional E-wallet facility as either the payee or payer may not be subscribed to the E-money institution.
In such situations, only the payer may be subscribed to the E-money facility, however, the payee will
have deemed the card to be accepted as a means of payment.
In contrast to the E-wallet and E-vouchers, the E-money card provider process can commence by either
the payee or payer initiating the payment.
There are multiple variations of the E-money card provider schemes and transactional chains. Whilst
such transactions may appear as a card transaction for payee or payer reporting, the location associated
with the payee or payer at onboarding to whom the card was issued , as the most accurate information
available, must be used as the identifier in line with Article 243c wherever possible.
The data to be reported for transactions may differ from Table 7 depending on the E-money business
model and transactions provided.
80
Table 7 – Overview of data elements to be transmitted for E-money payments
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Yes
Yes
BIC (ISO 9362)
2 Payee name
Yes
Yes
3 Payee
VAT/TIN
Not always
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process the payments. They
might be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
4 Payee account
ID
Yes Yes IBAN (ISO 13616) If IBAN is not available, the E-money
provider can, for example, provide the E-
money account number as an identifier or
provide another identifier such as the
merchant ID.
5 BIC/ID Payee
PSP
Not
applicable
Not
applicable
/
6 Payee Address Yes Yes E-money providers must establish the
location of the payee using all information
available in their records to determine the
one that best represents the location of the
payee.
7 Refund Yes Yes If reference to the original payment is
included, it should be reported as a separate
and unique transaction ID in box 14.
8 Date/time Yes Yes Execution date
9 Amount Yes Yes Amount should be
reported with two
decimals
10 Currency Yes Yes ISO 4217
11 MS origin
payment
Yes Yes ISO 3166-1 Alpha 2
12 MS
Destination
refund
Yes Yes ISO 3166-1 Alpha 2
13 Payer Location
information
Yes Yes IBAN, e -account
address, card number
BIN, IP address.
E-money providers must establish the
location of the payer using all information
available in their records to determine the
one that best represents the location of the
81
payee. This location should also be used
for E-money card providers whereby the
BIN alone may not provide the correct
location of the payer.
14 Transaction ID Yes Yes Transaction IDs for E-money transactions
are proprietary to the E-money provider
and are only unique within one E-money
provider’s system.
15 Physical
presence
Not
applicable
Not
applicable
4.5.2.6 Marketplaces
Marketplaces do not offer specific payment methods but rather allow their users to use other payment
methods to buy good s or services on their centralised platform. Because of this specificity, the way
marketplaces acting as payment service providers process payments is both similar to the way the related
payment method works, and to the way E-money providers act at the centre of the infrastructure.
As such, the data marketplaces will be able to report can vary based on the payment method used and
offer (e.g. whether payment will be done via credit transfer, card payment, E-money, etc.). However,
being at the centre of the payment processing and holding funds on behalf of both the payer of the payee,
the marketplace will always have full visibility on the payment transaction as well as the payer and
payee.
Table 8 – Overview of data elements to be transmitted by marketplaces
N°
Data Element
Available to payment
service provider
Possible standard
format accepted
Comments
Payer
Payee
1 BIC/ID
reporting PSP
Yes
Yes
BIC (ISO 9362)
2 Payee name
Yes
Yes
(name on selling
account)
3 Payee
VAT/TIN
Not always
Not always
EU VAT number shall
respect the EU
standards.
No standards required
for other identifier.
VAT number/TIN are not mandatory
elements to process the payments. They
might be available, together with other
identifiers, occasionally or following
stricter requirements in national
legislations.
4 Payee account
ID
Yes Yes IBAN (ISO 13616)
Merchant ID (MC DE
042)
If IBAN is not available, the marketplace
can provide other account identifier,
including the marketplace account ID.
5 BIC/ID Payee
PSP
Not
applicable
Not
applicable
/
82
6 Payee Address Yes Yes
7 Refund Yes Yes If reference to the original payment is
included, it should be reported as a separate
and unique transaction ID in box 14.
8 Date/time Yes Yes Execution date
9 Amount Yes Yes
10 Currency Yes Yes ISO 4217
11 MS origin
payment
Yes Yes ISO 3166-1 Alpha 3
12 MS
Destination
refund
Yes Yes ISO 3166-1 Alpha 3
13 Payer Location
information
Yes Yes IBAN (ISO 13616)
Card number BIN
IP address
Marketplaces must establish the location of
the payer using all information available in
their records to determine the one that best
represents the location of the payee.
14 Transaction ID Yes Yes Transaction ID will be attributed by the
marketplace and will not be available to
other payment service providers in the
payment chain.
15 Physical
presence
Not
applicable
Not
applicable
83
4.5.3 Data quality aspects
The data to be transmitted by payment service providers will vary based on the payment method used
and whether the reporting entity is the payment service provider of the payer or the payee. Specifically,
in the latter case, the data transmitted by the payment service provider of the payer may be of lower
quality or impossible for the payment service provider to cross-check as it will lack the contact with the
payee.
Under the reporting obligation, payment service providers are not requested to ask their partners for
more data than the one already available to them or exchange during the payment processing. They are
also not requested to verify the data they used other than what is required in order to process a payment
and comply with KYC and AML obligations. This implies that if a data element cannot be verified by a
payment service provider, for example where it refers to a national system of a third country, the payment
service provider can report this data as it is and does not need to further check its validity.
The data quality might also vary based on the payment service provider’s business models. E-money
providers typically have full vis ibility on the transfer between the payer and the payee which should
allow them to report higher quality data on the payee.
The main data quality issues will occur when the data is reported by the payment service provider of the
payer as it cannot confirm that the data transmitted is correct. This problem is further exacerbated in
payment methods where fields take the form of a free text box completed by the payer, mainly credit
transfer.
The table below provides an overview of the expected quality of the data transmitted by payment service
providers for the main payment methods presented in these guidelines. Elements in yellow are expected
to be either rarely available or of lower quality. Marketplaces are not represented as they use the data
from other payment method which is completed by their own data on both the payer and the payee. As
such, they are not expected to have any difficulties with data availability or quality.
84
Table 9 – Overview of data and expected data quality levels
Data
requirements
(Art. 243d)
Card payments Bank transfers Direct Debits E-money Money Remittance
Linked to the
payee
PSP Payer
(Issuer)
PSP Payee
(Acquirer)
PSP payer
(SEPA- IBAN)
PSP payer
(Swift)
PSP payee
(SEPA)
PSP Payer PSP payee PSP payer PSP payee PSP payer PSP Payee
1a) BIC PSP Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
1b) Name of
payee
Card acceptor
name (MC
DE043)
Merchant name
(VISA TCR0)
Card acceptor
name (MC
DE043)
Merchant
name (VISA
TCR0)
Payee name
(provided by
payer)
Payee
name
(SWIFT
59a)
Creditor
name
(records)
Creditor
name
(records)
Creditor
name
(records)
Payee’s
name
(own
records)
Payee’s
name
(own
records)
Payee’s name Payee’s name
1c) VAT/Tax ID Optional Mandatory in
some MS
Optional Optional Mandatory
in some
MS
Optional Mandatory
in some
MS
Optional Optional Optional Optional
1d) IBAN, ID
payee
Merchant/card
acceptor ID
(MC DE042)
IBAN +
Merchant/card
acceptor ID
(MC DE042)
IBAN SWIFT
field
59/59a
IBAN IBAN (EU) IBAN
(EU)
E-account
identifier
(+ IBAN)
E-account
identifier
(+ IBAN)
IBAN when
available
IBAN when
available
1e) BIC PSP
payee NA NA NA BIC or Other ID NA NA NA NA NA BIC or Other ID BIC or Other ID
1f) Address
payee
Card Acceptor
street (DE043
sub2)
Payee address
(own records)
Payee address
(provided by
payer)
Payee
address
(SWIFT
field 59)
Payee
address
(own
records)
Payee
address
(transmitted
by payee)
Payee
address
(own
records)
Payee
address
(own
records)
Payee
address
(own
records)
Payee
address
(provided by
payer)
Payee
address (own
records)
85
Data
requirements
(Art. 243d)
Card payments Bank transfers Direct Debits E-money Money Remittance
Linked to the
payment
PSP Payer
(Issuer)
PSP Payee
(Acquirer)
PSP payer
(SEPA-
IBAN)
PSP payer
(Swift)
PSP payee
(SEPA)
PSP Payer PSP payee PSP payer PSP payee PSP payer PSP Payee
2a) Date and time Local
Transaction
(MC DE12)
Purchase Date
(TC05)
Local
Transaction
(MC DE12)
Purchase Date
(TC05)
Interbank
settlement
date
Execution
date (Field
32a)
Interbank
settlement
date
Interbank
settlement
date
Interbank
settlement
date
Execution
date
Execution
date
Execution
date
Execution
date
2b) Amount and
currency
Origin
currency
Origin currency Origin
currency
Origin
currency
Origin
currency
Origin
currency
Origin
currency
Origin
currency
Origin
currency
Origin
currency
Origin
currency
2c) MS of origin BIN BIN IBAN IBAN IBAN IBAN IBAN Account
location
Card
issuer
code
Disbursement
Partner
country code
Disbursement
partner
country code
2d) Transaction
ID19
Own ID
Acquirer ID
(MC DE31 –
VISA TC05)
Own ID
Acquirer ID
(MC DE31 –
VISA TC05)
Own ID Own ID Own ID Own ID Own ID Own ID Own ID Own ID Own ID
2e) POS payments
MC DE 22 –
VISA TC05
MC DE 22 –
VISA TC05
NA
NA
NA
NA
NA
NA
NA
NA
NA
19 It must be noted that in accordance with the business rules of the XML Schema Definition, CESOP will reject duplicated transactions ID.
86
5 RULES FOR (RE)SUBMISSION
This section focuses on the rules applicable to the submission or resubmission of data from payment
service providers to Member States, which could impact the transmission of data to CESOP. However,
since the rules applicable to th e collection of payment data at national level are not established in
Directive 284/2020 or in Regulation 283/2020 , apart for the Member States obligation to collect the
payment data using the electronic standard form defined in the Annex to the Implementing Regulation
and within the timeframe laid down in Article 24b introduced by Regulation 283/2020, this section
mainly lists best practices and recommendation s to limit the impact that national resubmissions and
errors during the national collection can have on the transmission to CESOP.
The sections be low give an overview of what payment service provider s can expect from t he
(re)submission process at the national level, i.e. guidelines that individual Member States are
recommended to follow. These rules, however, should be read in conjunction with the relevant national
legislation applicable in each Member State for the collection of payment data which can differ in some
aspects.
5.1 Validation of the payment information at the national level
Payment service providers should validate the payment message prior to submitting it to the national tax
administration in accordance with the Annex to the Implementing Regulation. This includes both a check
of the XML Schema Definition (“XSD Schema”) and a check of the business rules, to ensure that errors
are caught as early as possible in the process.
When receiving the payment message, national tax administrations should validate the received payment
data against the XSD schema. In case the XSD schema is not respected (negative valid ation result), the
whole file will be rejected, and the payment service provider will have to resubmit the whole file. The
validation message sent by th e tax administration to the payment service provider will use the same
XML schema as used by CESOP for the validation message.
In order to avoid impact of errors on the submission to CESOP, it is recommended that:
• The national tax administration immediately validates the received payment message against the
XSD schema.
• The national tax administration immediately informs the payment service provider of the XSD
schema validation result in case of a negative result.
• In case of a positive XSD sch ema validation, the national tax administration immediately
forwards the payment information to CESOP.
• In case of a negative XSD schema validation, the validation result message lists all the technical
error codes, so that the payment service provider can correct them all at once.
• In general, business rules are checked at CESOP level. However, national tax administration can
perform a validation of (certain) business rules.
5.2 Validation of the payment information at the CESOP level
Once it receives the payment message from the national t ax administration, CESOP will validate the
payment data message against the XSD schema and the business rules described in the XSD User Guide.
Normally, the XSD schema check should not show any errors at the CESOP level, since this check was
already done at the national level. On the other hand, t he check of the business rules might lead to a
negative validation. It is thus possible that a payment data message passes validation by the Member
State but is later negatively validated by CESOP. CESOP will send the validation result to the relevant
87
national tax administration, whether the validation result is positive or negative. Under no circumstances
will the national Tax administration change the content of the payment data message.
In order to swiftly react to error in the transmission of data to CESOP, it is recommended that:
• The national tax administration forwards the validation result from CESOP to payment service
providers in case of both positive and negative result.
5.3 Resubmissions
This section focuses on the resubmission of data from payment service providers to Member States.
In case of a negative validation result after submitting payment data, the payment service provider must
resubmit a payment data message with the correct data. More detailed guidance on how re-submissions
and corrections should be done, is given in the XSD User Guide. Still, note that there can be national
procedures on how a Member State will perform validations and there can be national suggestions on
how to correct data. Nevertheless, in any case national procedures and guidance must be in line with the
XSD User Guide.
To limit the impact of resubmissions and corrections on the reporting to CESOP and to ensure
availability of data in the system, it is recommended for PSPs to align with the Member States to which
they submit the data. For Member States, it is recommended that:
• The national tax administration gives the payment service provider a time frame to resubmit the
payment message;
• The time frame should not exceed 30 calendar days, starting from the date the validation message
is sent by the Member State to the payment service provider;
• If the submission is not done before the end of the resubmission period, a notification should be
sent to the payment service provider with a deadline to comply with the resubmission obligation;
• Each Member State should enact legislation that allows for the sanction of payment service
providers who fail to submit or resubmit correct payment data within the given time frame.
These recommendations also apply in case a payment service provider does not submit any payment
message before the submission deadline and in case a payment service provider submits data that is not
in scope (e.g. a payment service provider sends data on domestic payment transactions). In addition, the
submission of data on payees who’s number of transactions do not exceed the threshold shall be
considered as non-compliant with the rules established with article 243b and can be subject to sanctions.
In case of late submission of payment data messages by payment service providers, they should be
transmitted to CESOP as soon as they are received and have successfully passed the validation check.
This, however, does not prevent Member States from applying sanctions for late-submission of the data.
88
5.4 Spontaneously correcting mistakes
Even though the submitted data goes through the XSD check and the business rules check, payment
service provides might realize later that there is missing data or/and they by mistake have sent erroneous
payment data that has passed these checks.
In this case, once payment service providers find out that they have sent erroneous data to CESOP, they
can spontaneously send new files with the corrected data to the Member States in accordance with the
rules laid down in the XSD User Guide.
There is no specific deadline for this in the EU legislation as it always remains important for CESOP to
receive correct data. Nevertheless, there is no use to send them after the end of the retention period for
data in CESOP (5 years). After this period, correction will not be possible as the original data will be
deleted.
6 REPORTING SAME PAYEE WITH SEVERAL TRANSACTIONS
This chapter focuses on reporting the payee’s data in the case funds are transferred to a payment account
of the payee.
The CESOP XSD format calls for the reporting of multiple transactions per account. This underpins the
importance for the PSPs to consolidate all transactions for a single account under the same
Reported Payee.
This ensures that each entity (defined by at least the same name and account identifier) is reported once,
with all related transactions consolidated under the specified payee name/account identifier pair. This
approach helps to avoid duplicate reporting of the same name and account identifier.
Therefore, reporting on a per -transaction basis rather than by payee constitutes an incorrect reporting
method and could lead to an error and the full rejection of the file. When the same payee is listed multiple
times, once for each transaction falling un der the same account, it results in redundant data, larger file
sizes, possible more errors and additional burden for the reporting PSP and CESOP. Payment data files
adopting this approach may trigger an error, preventing CESOP from processing the message effectively.
Starting with the version v4.03 of the XSD, it is possible to report a payee with several account identifiers
as one reported payee. With that version, the PSPs are still obliged to consolidate the information per
account with all the related transactions. This means that if the same payee is associated with Account1
(used for Transaction1, Transaction2) and Account2 (used for Transaction3, Transaction4), the payee
must be reported under 2 distinct reported payees: one per account with all underlying transactions.
For more details when two or more reported payees are considered as being the same payee, we refer to
the XSD User Guide.
We hereby provide some examples for the same payee, two examples where the data is correctly reported
and one where the data is incorrectly reported, potentially leading to an error and the full rejection of the
payment data file.
Example 1: Different account identifiers and split of the reported transactions
In case the payee has two different account identifiers, the reported transactions can and must be split
over two different reported payees, allowing to identify to which account the funds were transferred. In
89
this case we have a situation where dividing the reported transactions amongst various similar reported
payees is valid, because the same payee is reported with a different account identifier.
Figure 44 – Split of the reported transactions in the case of different account identifiers.
1st reported payee 2nd reported payee (with different account than the 1st
one)
Example 2: Same account identifier and consolidation of the reported transactions
In case the payee has only one account identifier, the correct way of reporting is to consolidate the
transactions under a single reported payee, as illustrated below:
Figure 45 – Consolidate the reported transactions in the case of only one account identifier.
1st and only reported payee
90
Example 3: Same account identifier but transactions not consolidated
The incorrect way of reporting is dividing the reported transactions amongst various similar reported
payees. This practice is deemed inappropriate by the CESOP system and could potentially lead to an
error and the full rejection of the payment file by CESOP.
Figure 46 – Incorrect way of reporting in the case of only one account identifier.
1st reported payee 2nd reported payee (with same account as the 1st one)
7 FINAL REMARKS
As already indicated above, these Guidelines aim to provide practical information and explanations on
the reporting of payment data by payment service providers and on their collection by Member States.
They do not have legal value and only serve to explain the legal obligation without going against it.
The Guidelines may be subject to changes and update d in the future following the evolution of the
payment market and the application of the reporting obligation.
Questions or comments about the Guidelines can be sent to TAXUD-CESOP@ec.europa.eu.