🧾 What a payment service provider must report

CESOP: the quarterly record of cross-border payments

A European payment institution files four types of reports, each with its own recipient, its own schedule, and its own unit of measure. The most recent is a tax report known as CESOP. The acronym refers to the central EU system to which national tax authorities send the cross-border payment data they collect from providers. Since January 1, 2024, any provider that executes such payments must keep a record of them and submit it to its tax authority every quarter. CESOP creates no tax and gives no right to reassess. Its purpose is to let tax authorities match a seller's incoming payments against its VAT returns.

Two acts dated February 18, 2020, set up the system. Directive (EU) 2020/284 inserts Articles 243a to 243d into VAT Directive 2006/112/EC and creates the record-keeping obligation for providers. Regulation (EU) 2020/283 amends Regulation 904/2010 and creates CESOP itself, which the European Commission operates. The filing format is set by Implementing Regulation (EU) 2022/1504, which requires a standard XML form. National tax authorities open their own filing channels without redefining that schema. All three acts have applied since January 1, 2024.

The obligation applies to the categories of providers listed in Article 1(1)(a) to (d) of PSD2: credit institutions, e-money institutions (EMIs), post office giro institutions, and payment institutions. Directive 2020/284 adds persons that benefit from the exemption in PSD2 Article 32. France transposed it in Article 286 sexies of the General Tax Code, supplemented by Decree No. 2023-1149 of December 6, 2023. The French text refers to Article L. 521-1(I) of the Monetary and Financial Code and excludes account information service providers. The exclusion follows from what they do: they access accounts on their customers' behalf without executing any payment. The record-keeping obligation falls only on providers that execute payments.

The record covers only cross-border payments. A payment is cross-border when the payer is in one Member State and the payee is in another Member State, a third territory, or a third country. Domestic payments are out of scope, and so are payments where the payer is outside the EU, wherever the payee is located. Of the two providers involved, the obligation falls on the payee's provider. It shifts to the payer's provider when the payee's provider is not located in the EU. The text therefore assigns the reporting obligation in every scenario, without leaving the two institutions to agree on it between themselves.

Article 243c determines where the parties are located based on the account's IBAN, or any other identifier that unambiguously identifies the party and its location. If there is no account identifier, the text uses the BIC or any other identification code of the provider acting on that party's behalf. An address or country of residence in the customer file has no bearing on this. The consequence is for systems: an institution that has never stored the payee's IBAN, or the identifier used instead, does not have the data the record requires.

• The reporting provider, identified by its BIC or another business identifier code.
• The payee, with its name or business name as shown in the provider's records, its VAT number or national tax identification number if available, and its address if available.
• The account identifier: the IBAN, or failing that any other identifier that locates the payee, or the BIC of the provider acting on the payee's behalf when the payee receives funds without holding a payment account.
• Each payment, with its date and time, amount and currency, Member State of origin, and a reference that identifies it unambiguously.
• Each refund identified as relating to one of those payments, with the Member State of destination.
• Whether the payment was initiated at the merchant's physical premises, when the provider has that information.

The provider keeps its record in electronic form for three calendar years from the end of the calendar year of the payment. Tax authorities then send the data to CESOP, which keeps it for no more than five years from the end of the year it was transmitted. The system checks the syntax of BICs, IBANs, currency and country codes, and VAT numbers, removes duplicates, and flags suspicious payees. Access is restricted to Eurofisc liaison officials with a personal user ID, and only to investigate or detect suspected VAT fraud. A malformed file is rejected before it enters the system. These format checks run before tax authorities make any use of the data.

Fraud: a semiannual report that determines the right to apply exemptions

The second report covers payment fraud, and its legal basis predates CESOP. Article 96(6) of PSD2 requires every provider to send its competent authority statistical data on fraud by payment method. Authorities then pass the data on, in aggregate form, to the European Banking Authority and the European Central Bank. The detailed tables come from guidelines EBA/GL/2018/05. Guidelines EBA/GL/2020/01 of January 22, 2020, amended them for transactions initiated and executed from July 1, 2020.

Reports are due every six months. Providers that benefit from the exemption in PSD2 Article 32 file only once a year, with data broken down into two half-years. E-money institutions covered by Article 9 of Directive 2009/110/EC follow the same rule. The guidelines set no common filing date: each competent authority sets its own calendar, exchange format, and secure reporting procedures. A group present in several Member States therefore faces several separate deadlines. Reports go to the authority of the home Member State, except for an established branch, which reports separately to the host country's authority. A provider operating in another Member State without a branch there reports only to its home authority, while opening a branch adds a separate report.

The report rests on two definitions: unauthorized transactions and manipulation of the payer. An unauthorized transaction is executed without the payer's consent, including after the loss, theft, or misappropriation of sensitive payment data. Manipulation of the payer refers to a transaction the payer makes personally, after being deceived by a fraudster, to an account the payer believes in good faith belongs to a legitimate payee. The guidelines exclude fraudulent transactions blocked before execution. An attempt stopped by monitoring systems therefore does not appear anywhere in the regulatory report.

Transactions and fraud are assigned to periods by different dates. A transaction belongs to the period in which it was executed, while fraud is reported as soon as it is detected, without waiting for the case to close. Losses are counted on a cash basis, when they are recorded in the provider's books. Reimbursements from insurers are excluded. A case opened in June on a January transaction therefore corrects the first-half figures. The guidelines require these corrections to be submitted in the next reporting window, covering at least one year of past periods, and authorities go back as far as 13 months after execution.

The same set of fields feeds a second obligation of a different kind. Providers that apply the transaction risk analysis (TRA) exemption monitor their own fraud rate under Delegated Regulation (EU) 2018/389. Article 19 defines that rate as the value of unauthorized or fraudulent remote transactions divided by the value of all remote transactions of the same type, over a rolling 90-day period. The annex sets reference rates by band of exempted amount. The rate is therefore calculated on all of the provider's remote transactions for that payment type, not just those it exempted.

Article 20 sets out what happens when the rate is exceeded. The provider must report it immediately to the competent authority, along with the measures it plans to get back under the threshold. After two consecutive quarters above the reference rate, the provider must stop applying the exemption for the amount band concerned. It can resume only after a full quarter at or below the rate. Article 21 requires the data to be recorded and monitored at least quarterly, by instrument type, with remote transactions kept separate from the rest. The provider tracks fraud value and fraud rate, average transaction value, and the number of transactions for each exemption applied. Applying an exemption therefore requires this monitoring to be in place already, because the right to use it depends on a rate measured over past periods.

Payment statistics for the central bank

The third report goes to the central bank, and its purpose is to measure the payments market statistically. European Central Bank Regulation (EU) No 1409/2013 governs payment statistics. Regulation (EU) 2020/2011 expanded it significantly, with the revised requirements applying from the first quarter of 2022. The reporting population includes payment service providers, e-money issuers among them, and payment system operators. Only entities resident in a euro area Member State are covered. What triggers the obligation is therefore the reporting entity's residence in the euro area.

The ECB regulation applies only within the euro area. Central banks in Member States that have not adopted the euro collect comparable statistics under their national framework or that of the European System of Central Banks, with their own tables and deadlines. A group operating on both sides of that line fills in similar but not identical returns. Reports produced for one country cannot be reused as is in another.

The data collection covers institutions offering payment services, card functions, acceptance devices, and payment transactions. It also covers fraudulent transactions, with their type and the party bearing the loss, as well as transactions by terminal type. Participation in designated payment systems and the payments those systems process complete the list. The tables are not all on the same schedule. The core set is semiannual. A quarterly set of transactions comes on top, and two annual tables broken down by half-year are reserved for reporting agents that benefit from a derogation.

Reporting is counted per reporting entity, never per group. A group that owns both a payment institution and a payment system operator falls into two separate populations, with different tables and frequencies. A branch established in another Member State reports to the central bank of its host country. The scope of accounting consolidation does not determine the scope of statistical reporting, which follows the status and residence of each entity on its own. The two scopes almost always differ.

Fraud shows up in two frameworks at once. The European Banking Authority guidelines and the European Central Bank statistics regulation ask for the same figures over the same half-years, with largely overlapping breakdowns. The two institutions then publish a joint report on payment fraud based on that reported data. An institution that submits two different fraud figures for the same half-year will be asked which one is wrong. Keeping the two reports consistent therefore requires feeding both from a single internal data source.

Incidents: a clock, not a calendar

The fourth report covers major operational or security incidents. It is triggered by an incident, and its deadlines are measured in hours. The regime moved to a new legal basis on January 17, 2025. Until then, a provider reported major operational or security incidents under PSD2 Article 96, following the revised guidelines EBA/GL/2021/03 of June 10, 2021. The European Banking Authority repealed those guidelines on the day the Digital Operational Resilience Act (DORA) became applicable.

Regulation (EU) 2022/2554 (DORA) has absorbed this reporting. Its Article 23 extends the chapter on information and communication technology (ICT) incidents to payment-related operational or security incidents. Credit institutions, payment institutions, account information service providers, and e-money institutions now report through that single channel. PSD2 reporting remains for providers that DORA does not cover, including post office giro institutions and, according to the European Banking Authority, credit unions in some Member States. Their national authority keeps its own process for them. The reporting channel therefore depends on the institution's status: DORA for the entities it covers, PSD2 for the rest.

Under DORA, the clock starts when the incident is classified as major, not when the outage occurs. The initial notification must be sent no later than four hours after classification, with an outer limit of 24 hours from the moment the entity became aware of the incident. The intermediate report follows within 72 hours, and the final report within one month of the intermediate report. The classification criteria and materiality thresholds are set by Delegated Regulation (EU) 2024/1772. The content and deadlines of the three reports are set by Delegated Regulation (EU) 2025/301. The two texts work together: the first determines whether an incident is major, the second what must be reported and when.

The practical difficulty is classifying the incident. The four-hour clock runs while the team is managing the crisis, yet classification requires counting affected customers, the duration of the outage, the volume of affected transactions, and the economic loss. These figures are measured against a normal level, which must exist somewhere as historical data. Showing that a significant share of volume was lost requires that normal volume to have been stored, by hour and by service. Preparing the incident procedure therefore starts with making sure that historical data is available in the data warehouse.

Informing customers is a separate obligation from reporting to the authority, and it cannot wait until the final report. DORA Article 19(3) requires customers to be informed without undue delay as soon as the entity knows that a major incident affects their financial interests. The message must describe the measures taken to limit the impact. PSD2 Article 96(2) framed the obligation differently, requiring the provider to state the measures users can take themselves. In a group subject to both regimes, the two wordings apply together, and customer communications cover both the measures the institution has taken and those users can take themselves.

• A written classification rule, with the thresholds of Delegated Regulation (EU) 2024/1772 translated into queries that run on production data.
• A baseline series of normal transaction volume, by service and by hour, the only way to measure the shortfall during an incident.
• An on-call team authorized to classify, separate from the team fixing the problem. Otherwise, classification waits until the outage is over and the deadline has already passed.
• A proven filing channel with the competent authority, tested outside of any incident, with named user credentials ready.
• A customer communication template approved in advance by legal and compliance, with a version for each payment instrument.
• A line to the data protection officer, since the same outage may fall under GDPR Article 33.

What these obligations require of your systems

All four obligations draw on the same raw material: the record of a payment transaction. None of them can be produced from the data a payment processing system keeps by default. Financial settlement data holds an amount, a value date, and a bank counterparty, which is enough for accounting and reconciliation. The CESOP record needs a payee identity, fraud reporting an exemption reason, statistics a counterparty country, and incident reporting a normal-volume baseline. These four fields are created upstream in the chain and almost always get lost along the way. Losing them triggers no visible error, because accounting and reconciliation run fine without them.

One design rule avoids most rework: any data used to classify a transaction is recorded when the transaction is executed, not rebuilt by a later process. The exemption reason exists in the authentication and authorization messages, at the moment the issuer responds. The acceptance channel exists in the sale message, and financial settlement then erases it. The payee identifier exists in the credit transfer instruction, before clearing replaces it with a net position. Each downstream step replaces these details with aggregated or net data, so the record gets thinner as it moves along.

Four dates coexist on the same transaction, and most data warehouses mix them up. The execution date assigns the transaction to a reporting period. The booking date assigns a loss to a financial year and is used to count losses on a cash basis. The detection date triggers the fraud report without changing the period the transaction belongs to. The case closure date drives no obligation at all, yet it is often wrongly used as the reporting date.

Several retention periods apply to the same data, each set by a different text. The CESOP record is kept for three calendar years from the end of the year of the payment. PSD2 requires payment institutions to keep records relevant to its Title II for at least five years. Directive (EU) 2015/849 also sets five years for due diligence records, counted from the end of the business relationship or the date of the occasional transaction. The 13-month dispute period in PSD2 Article 71 sets the horizon for fraud corrections, since a transaction disputed in the 12th month still changes a period that has already been reported.

An obligation is sometimes discovered after the fact, during an inspection, after a change of status, or when a new cross-border corridor opens. The institution then has to work out what can be rebuilt from the data still available. Raw message archives often contain what the data warehouse discarded. Authorization logs, network clearing files, and ISO 20022 messages kept as evidence contain the acceptance channel, the exemption reason, and the counterparty identifier.

Three things can never be rebuilt. A payee identity that was not stored cannot be derived from an IBAN alone, without the name carried in the original instruction. Classifying a case as manipulation of the payer requires talking to the customer, which is impossible two years later. A normal-volume baseline cannot be created retroactively if the counters did not exist at the time.