CESOP: what it means for EU payment service providers
International Tax Review is part of the Delinian Group, Delinian Limited, 4 Bouverie Street, London, EC4Y 8AX, Registered in England & Wales, Company number 00954730
Copyright © Delinian Limited and its affiliated companies 2023

Accessibility | Terms of Use | Privacy Policy | Modern Slavery Statement

CESOP: what it means for EU payment service providers

Sponsored by


Tax specialists from Deloitte Netherlands present an overview of legislation that will have a profound impact on the ever-growing number of organisations that conduct cross-border transactions.

The Central Electronic System of Payment information (CESOP) will enter into force on January 1 2024. From then on, EU payment service providers (PSPs) must provide quarterly transactional information on the cross-border transactions they carry out to the tax authorities in the member states where they offer payment services.

1.1 CESOP at a glance

1.2 The background and scope of the regulations

As a result of the growth of e-commerce, cross-border sales of goods and services have taken off. The CESOP rules are aimed at better detection of VAT fraud and improvement in the collection of tax revenues on these cross-border supplies. To achieve this goal, under the new third-party reporting obligation, EU PSPs will be required to retain and report information about the cross-border payments they process.

CESOP introduces an obligation for EU PSPs to record and report cross-border payments where the payer is in the EU and the payee is in another country (inside or outside the EU) if the payee receives more than 25 cross-border payments in a calendar quarter in a particular EU member state.

1.3 EU legislation and interaction with PSD2

The binding legislation surrounding CESOP consists of:

  • A directive (Directive 2020/284/EU, OJ 2020, L 62/7, or the CESOP Directive), which aims to amend the VAT Directive;

  • A regulation (Regulation 2020/283/EU, OJ 2020, L 62/1);

  • An implementing regulation (Implementing Regulation (EU) 2022/1504, OJ 2022, L 235/19); and

  • A standard form (Article 24c of Regulation (EU) 904/2010, OJ 2010, L 268/1 and Article 4 of the Implementing Regulation (EU) 2022/1504, OJ 2022, L 235/19) (the XML schema).

The conceptual framework of the CESOP Directive differs in important respects from the conceptual framework as it is known for VAT. For most key concepts, such as ‘payment and payment service’, the definitions from the Second Payment Services Directive (Directive (EU) 2015/2366, OJ 2015, L 337/35, or PSD2) are to be used. In addition, there are some concepts that are specifically defined in the context of CESOP itself, such as ‘cross-border payment’.

The European Commission has published the non-binding “Guidelines for the reporting of payment data from payment service providers and transmission to the Central Electronic System of Payment information (CESOP)” (published August 3 2022), which set out in more detail its vision on how to interpret the legislation. In the interests of legal certainty, it is highly desirable that the principles set out in the guidelines should be endorsed by the member states so that PSPs can safely rely on the interpretations where appropriate.

1.4 PSPs and payments in scope of CESOP

The following PSPs as mentioned in PSD2 are in scope of the CESOP regulations:

  • Credit institutions;

  • Electronic money institutions;

  • Postcheque-en-giro services; and

  • Payment institutions.

The definition of a ‘payment’ under CESOP is in line with the definition of a ‘payment transaction’ under PSD2. The exclusions provided for in PSD2 are also not considered as payments within the meaning of CESOP but exempt small payment institutions are covered.

The reporting obligation applies to payments made in the context of the payment services mentioned under items 3 to 6 in Annex I of PSD2, namely:

  • Credit transfers;

  • Direct debits;

  • Card payments;

  • The issuing of payment instruments and acquiring of payment transactions; and

  • Money remittances.

2 The CESOP system in detail

2.1 Payer and payee location

A payment is cross-border if the payer is ‘located’ in one member state and the payee is located in another country. These locations are determined by the International Bank Account Number (IBAN) or another identification code. The directive does not prescribe which code should be used. If more than one is available, the PSP must choose which one best identifies the location of the payer or payee. If nothing else is available, the Business Identifier Code (BIC) of the PSP acting on behalf of the payer or payee shall apply.

The guidelines give more guidance on the European Commission’s view of which identifier should be used for each type of payment. This provides some simplification, but at the same time it is recognised that the identifiers do not necessarily align to the location of the payer or payee and member states might not agree.

In practice there will be many situations when the identification codes mentioned clearly do not match the actual location of the payer or payee. Consider, for example, a German-based online bank that provides German IBANs to account holders in different member states. In many cases, this IBAN will not correspond to the actual place of residence (which the bank knows, based on its administration). It may even be the case that the payments come from the same account holder.

Take, for example, a customer living in the Netherlands who transfers money from their Dutch payment account to their own (German) account with the German online bank. Because CESOP uses PSD2 definitions, it is a payment. Based on the IBANs, it appears to be cross-border, but is it also so if the bank has conflicting data? Can there even be a cross-border situation if the payer and payee are one and the same natural person?

2.2 Threshold of more than 25 cross-border payments per calendar quarter

The obligation for PSPs to keep records only applies if one payee receives more than 25 cross-border payments per calendar quarter in a particular EU member state. If payees hold multiple accounts, payments should be aggregated at payee level. A PSP operating in multiple member states should report this on a member state level. Once the threshold is met, all payments (including the first 25) must be reported.

2.3 Reporting the data to the tax authorities and the CESOP database

The payments are recorded per calendar quarter and must also be reported to the tax authorities every quarter. This must be done within one month of the quarter to which the data relates. Before submission, the PSPs are expected to validate the data to be transmitted by them.

The tax authorities must forward the data to CESOP by the tenth day after the PSP submission deadline. Beforehand, they must validate the completeness of the data (all required data elements are filled in) and whether the technical requirements are met (the XML schema has been correctly applied). If this is not the case, the member state should reject the report.

After receiving the data in CESOP, another validation is performed. The dataset can be refused in whole or in part if it does not meet the minimum requirements. The data in CESOP will be kept for a maximum of five years after the end of the year in which the data was transmitted.

2.4 Exemption from reporting

The regulation provides for an exemption to record and report the data for the PSP of the payer, if the PSP of the payee is in the EU (and therefore has its own obligation to record and report the transaction). However, the payer's PSP still has an obligation to keep track of transactions for the purpose of calculating the threshold of more than 25 cross-border payments in the event that there are reportable payments to that payee, because it uses a second PSP outside the EU that will not report for CESOP.

2.5 Country of reporting

If there is an obligation to report, the PSP files its records to the home or host member state. In many cases, this means that PSPs operating in several member states under their payment service licence will have to report in different member states. In these member states, they then report (only) the transactions that need to be reported in that member state (in principle, a transaction is only reportable in one member state).

Payments to European Economic Area (EEA) countries (Iceland, Liechtenstein and Norway) are considered payments to third countries. Therefore, the PSP of the payer will have to report these in the member state where they provide the payment services. Also, PSPs established in the EEA will have to report payments initiated by a payer within the EU in the member states where they offer payment services.

2.6 Which data does the PSP need to report?

The data to be reported relates primarily to the payee. This concerns data that identifies the payee and their PSP and the data for each payment received by the payee. It concerns a total of 15 data fields that must be reported:

  • The BIC/ID of the reporting PSP;

  • The payee name;

  • The payee VAT ID/taxpayer identification number;

  • The payee account ID;

  • The payee PSP BIC/ID;

  • The payee address;

  • An indication of payment refunds (Y/N);

  • The date/time;

  • The amount;

  • The currency;

  • The member state of payment origin;

  • The member state of refund destination;

  • Payer location information (payment origin);

  • The transaction ID; and

  • Information that verifies that the payment is initiated at the physical premises of the merchant.

The above can be divided into three categories:

  • Mandatory – this data must always be provided. If this is not the case, the reporting is wrong, its delivery will be refused by the tax authorities' system, and the PSP will be in default in respect of fulfilling its obligations.

  • Optional mandatory – according to the explanatory statement, this somewhat vague name means that if these data elements are available, the PSP must include them in the report to the tax authorities. Although reporting will not be refused, failure to provide these data fields if they are available will result in non-compliance with the PSP's compliance obligations.

  • Mandatory if applicable – these are data elements that apply conditionally and therefore depend on the specificities of the payment. If the conditions are met, the data elements must be provided. If the conditions are not met, this obviously does not apply. Failure to provide the data even though the conditions are met will result in refusal of delivery to the tax authorities' system and non-compliance with the PSP's compliance obligations. 

3 Meeting CESOP reporting obligations

3.1 Impact analysis

CESOP is essentially a tax obligation. The obligation follows from tax legislation and serves a tax purpose. However, by now it will be clear that being CESOP compliant is a broader business issue. The interpretation of CESOP relies to a large extent on PSD2 and uses data that is part of the PSP's payment systems. To map the scope of the obligation, a broad working group within the PSP’s organisation should be established.

3.2 Data processing and submission

Compliance with CESOP requires a much larger dataset than just the reportable transactions: all payment transactions must be analysed to determine whether they are cross-border, and aggregated to determine whether an individual recipient has exceeded the threshold of 25 payments. One or more XML files must be generated from the remaining transactions (given the size of the reports, it is foreseeable that splitting into different files will be necessary), which must then be submitted. This submission varies from one member state to another. There is a need to design an end-to-end solution to support this from a data and operational perspective.

3.3 Control and retention obligation

As with any reporting obligation, the PSP will have to incorporate CESOP reporting into the internal control framework. Particular attention should be paid to controls preventing CESOP messages from being refused by the member state or CESOP. In addition, the reports must be kept for three calendar years from the end of the calendar year in which the payment was made. This retention obligation covers the transactions that eventually end up in the CESOP report. For payments that are ultimately not included in the records, existing practice can be maintained.

4 Use of CESOP Data

Payment data contains very sensitive (personal) data. At an EU level, the use of the data collected in CESOP is limited to combating VAT fraud. Access to the data is limited to a number of ‘Eurofisc liaison officers’.

Because the data is first provided by the PSPs to the local tax authorities and the tax authorities pass this data on to CESOP, there is a possibility that individual member states will use the data for other purposes, subject to their own laws and regulations.

5 Consequences of non-compliance

EU legislation does not contain any penalty provision or other sanctions. This has been left to the member states. There are quite a few member states that have already announced hefty penalties for non-compliance, more akin to penalty levels for anti-money laundering (AML) non-compliance than for the average tax non-compliance. Because of the obligation to submit CESOP returns in each member state, non-compliance can quickly become costly. 

Non-compliance with the obligations under CESOP can have other consequences besides just tax penalties. For example, the incorrect reporting of personal data (e.g., by not properly applying the threshold of 25 payments per quarter) can also lead to violation of privacy legislation and may have to be treated as a data breach. On the other hand, a PSP that fails to comply with CESOP may be held accountable by a financial supervisory authority if the breach is deemed to have led to a failure to comply with its legal obligations under AML legislation. 

6 Final thoughts

There are still many open-ended questions concerning the implementation of the CESOP Directive. However, despite this uncertainty, PSPs must set up their systems and processes to comply with the regulations in a timely manner. Failure to do so could lead to tax penalties, but also consequences in the field of privacy/data protection and financial supervision.

more across site & bottom lb ros

More from across our site

ITR highlights the good, the bad and the ugly in tax figures from 2023, profiling politicians, in-house practitioners, public officials and more
Scalia is head of tax at Nestlé Health Science and chair of the Tax Executives Institute’s Student Case Competition
Agergaard is the director of Skatteforvaltningen, the Danish tax authority
Kadiri is tax director for UK & Ireland at L'Oréal and chair of Women in Tax
Stephens is the outgoing CEO of accountancy professional services network RSM
Ward is the principal analyst of CICTAR
Serafi is KPMG’s newly appointed vice chair for tax
Burt is the premier of Bermuda
Modi is Prime Minister of India
Shah is a British hedge fund trader