CESOP data and system readiness: the four layers a PSP has to build
“Are we CESOP-ready?” is not one question. It is four, and a payments firm that answers three of them correctly still files a rejected return. Readiness means proving, quarter after quarter, that you know which payments are in scope, which member states you owe a return to, which fields you can populate from your own systems, and what you do when a file comes back negatively validated weeks later. This piece walks each layer in build order, with the counting rules and validation mechanics that decide whether a return lands — and three scenarios where firms get it wrong.
1. The four layers of readiness
The obligation itself is short. Council Directive (EU) 2020/284 inserted Articles 243b to 243d into the VAT Directive (2006/112/EC), requiring PSPs to keep and transmit records of cross-border payments; Council Regulation (EU) 2020/283 amended Regulation (EU) No 904/2010 to build the Central Electronic System of Payment Information; and Commission Implementing Regulation (EU) 2022/1504 fixes the electronic standard form. The rules applied from 1 January 2024.
CESOP is an engineering problem rather than a filing problem because its four layers — scope (are you the PSP that owes the report), threshold (which payees crossed 25 payments), jurisdiction (which member states you file in) and data and validation — depend on each other, and a defect in an early layer surfaces only at the last.
2. Layer one — are you the reporting PSP?
The duty attaches to the payee’s payment service provider where that PSP is located in the EU, and shifts to the payer’s PSP only when the payee’s PSP sits outside the Union — so each cross-border payment is captured once, on the side that can see the merchant. For an EU-licensed institution that means your acquiring, e-money and account-servicing flows on the payee side are the primary reporting population, while outbound customer payments become reportable only where the beneficiary’s institution is outside the EU.
Branch structure changes the answer: where a PSP from an EEA country operates branches in a member state, those branches are themselves subject to the obligation and can be the payee’s PSP for the payments they execute. The established entity, not the group, is the unit of analysis.
3. Layer two — the 25-payment count, correctly
Reporting is triggered where a PSP executes more than 25 cross-border payments to the same payee in a calendar quarter. Three counting rules turn that sentence into real logic:
- Count per payee identifier. The basic rule counts cross-border payments against the payee’s identifier — an IBAN, a merchant identifier, an e-money account reference. Exceed 25 against an identifier and all payments to it that quarter become reportable, with the account-holder details.
- Count per member state, not per group. Where a PSP has establishments in several member states, each performs its own calculation and must not consolidate at group level — as with services provided through agents or directly into another member state.
- Aggregate identifiers belonging to the same payee. A merchant may take credit transfers to an IBAN, cards against a merchant ID and top-ups to an e-money account; a PSP that knows two identifiers belong to the same payee adds them together for the count. Aggregation applies only where the holder is a single natural or legal person, or a branch of the same company — not across franchises or subsidiaries. For a jointly held account the payee is all the holders together, so aggregation with one holder’s separate account does not follow.
4. Layer three — which member states you file in
Article 243b(4)(b) makes the records available to the PSP’s home member state, or to the host member states where it provides payment services outside the home one. The Commission’s guidelines give an unusually concrete instruction: follow your payment licence. You must notify a host authority before providing services in its territory, that notification is documented in the host register of payment service providers, and that register is the evidence of where you file.
| How you reach the market | Where the payments are reported |
|---|---|
| Licensed and operating in one member state only | Home member state |
| Branch in another member state | That host member state, for the payments that branch executes |
| Agent in another member state | That host member state, for the payments executed there |
| Direct cross-border provision under a passport | Each host member state where services are provided |
The guidelines close the obvious escape route: the proxy flexibility for locating a payer or payee under Article 243c cannot be used to avoid filing in a host member state. A passported e-money institution files in every state where it executes the relevant payments — not once at home.
5. Layer four — the data set and its three flavours of “mandatory”
Article 243d splits the record into payee data — the PSP’s BIC or other business identifier, the payee’s name as it appears in your records, any VAT or national tax number if available, the IBAN or another identifier that unambiguously identifies and locates the payee, the payee’s address if available — and payment data: date and time, amount and currency, the member state of origin (or destination for a refund) with the information used to determine it under Article 243c, a payment reference, linked refunds, and where applicable the flag that the payment was initiated at the merchant’s physical premises.
The Annex to Implementing Regulation (EU) 2022/1504 turns this into 15 main data elements, which the Commission guidelines classify in a way that decides how you build validation:
| Classification | What it means operationally |
|---|---|
| Mandatory | Always present. A missing element rejects the form and is non-compliance. |
| Optional mandatory | Must be provided whenever available to you. If genuinely unavailable the form is not rejected and the obligation is met — but withholding data you hold is not. |
| Mandatory when applicable | Required when the stated condition is met — typically a choice between two mutually exclusive options. Missing it when the condition applies rejects the form. |
“Optional mandatory” causes audit findings rather than rejections. A VAT number or payee address sitting in your onboarding records but never wired into the CESOP extract passes technical validation and still breaches the obligation — which is why the mapping must run against the source systems, not against the fields your extract already produces.
6. The validation and resubmission loop
Validation happens at two levels, and which level rejected you determines how much you resend:
- Before you submit, check both the XSD schema and the business rules — the guidelines want errors caught as early as possible, and the Commission publishes the schema definition, an XSD user guide and a validation module for this.
- At national level, the tax administration validates against the XSD schema only, not the business rules. If the schema is not respected the whole file is rejected and you resubmit the entire quarter, because CESOP never received anything. The result lists all technical error codes at once.
- At CESOP level, business rules are checked. A file can pass the member state and fail centrally weeks later — and here member states should let you resubmit only the payees affected.
The guidelines recommend a resubmission window not exceeding 30 calendar days from the date the validation message is sent, a reminder once half of it has elapsed, and national sanctions for failing to resubmit in time. Late data is still loaded once it validates — which does not stop a member state sanctioning the lateness.
Two asymmetries are worth designing for. First, over-reporting is also non-compliance: sending data for payees below the threshold breaches Article 243b, can be sanctioned, and the authority will ask you to delete it from the resubmission. Second, spontaneous correction has no EU deadline — corrected files follow the XSD user guide rules, should arrive before the end of the reporting period concerned, and are impossible once CESOP’s five-year retention has expired and the originals are deleted. Note the two clocks: five years in CESOP, against the three calendar years the PSP itself keeps the records under Article 243b.
7. Three scenarios where readiness fails
Scenario 1 — the passported EMI that files once. An e-money institution licensed in one member state passports into eight others and builds a single quarterly return to its home authority. The file validates; substantively it is wrong, because under Article 243b(4)(b) payments executed in each host member state are reported to that host state. Remediation is architectural, not a data fix: partition the extract by the member state in which the service is provided, using the passport register entries, and onboard eight further submission channels.
Scenario 2 — the merchant with two identifiers. A marketplace seller receives 15 cross-border credit transfers to an IBAN and 14 card settlements against a merchant ID in the same quarter. Counted separately, neither identifier exceeds 25 and the analyst concludes nothing is reportable. Counted correctly, both identifiers belong to the same legal person, the aggregate is 29, and all 29 payments become reportable — reported against their own identifiers, not as a merged 29-payment aggregate. A neighbouring seller with 20 payments across two identifiers stays out, and reporting that seller anyway is itself a breach.
Scenario 3 — the file that fails three weeks late. A firm submits on the deadline, gets a positive national XSD result, and treats the quarter as closed. Nineteen days later the administration forwards a negative CESOP business-rule result affecting 40 payees. Because the rejection came from CESOP rather than the national schema check, only those 40 payees need resubmitting — but it must happen inside the authority’s window, and nobody owns the mailbox the result arrived in. The readiness gap is not data quality; the feedback loop was never staffed.
8. FAQ
Am I subject to CESOP?
If you are an EU-located PSP executing more than 25 cross-border payments to the same payee in a calendar quarter, yes — for those payees. The obligation sits with the payee’s PSP where it is in the EU, and moves to the payer’s PSP only where the payee’s PSP is outside the Union.
Do I have to file if no payee crossed the threshold?
The obligation attaches to payees above the threshold, and sending data on payees below it is itself non-compliant. Whether your member state expects a positive “no data” signal is a national question — confirm it with the administration you file to rather than assuming silence suffices.
Is the threshold per payee or per account?
Per payee. The count starts from the identifier, but identifiers you know belong to the same natural or legal person are added together. Franchises and subsidiaries are separate entities and are not aggregated.
We passport across the EU — can we file everything at home?
No. Payments executed in a host member state are reported to that host member state, and the proxy flexibility for locating payers and payees cannot be used to avoid it. Your licence and the host registers determine where you file.
What happens if the file is rejected?
It depends on the level. A national XSD rejection means the whole file failed and the entire quarter is resubmitted. A CESOP business-rule rejection should allow resubmission of only the affected payees, within a window recommended not to exceed 30 calendar days.
How long can we correct data, and how long do we keep it?
Spontaneous corrections have no EU deadline but should be sent before the end of the reporting period concerned, and are impossible once CESOP’s five-year retention has expired. Separately, Article 243b requires the PSP to keep the records electronically for three calendar years from the end of the calendar year of the payment date.
9. What to do, today
Work the layers in order — each step consumes the previous one’s output:
- Write down, per payment rail, whether you are the payee’s PSP or the payer’s PSP; that answer sets your reporting population before any data work starts.
- Solve payee identity resolution — saying that an IBAN, a merchant ID and an e-money reference belong to one legal person. The hardest step, and it gates the threshold engine.
- Test that engine against a payee with two identifiers and one with 20 payments: the first is reported, the second must not be. Keep its output a list of payees, never a data set.
- Reconcile your submission map against your passport register entries and onboard a channel for each member state.
- Re-run the data mapping for the “optional mandatory” fields, then pre-validate against the schema and business rules before a file leaves your estate.
- Name the owner of the inbound validation-result channel and give them the resubmission clock in writing.
Related: What is CESOP reporting · Mapping your data to the CESOP XML schema · CESOP in Spain — Modelo 379 · CESOP in the Netherlands — Digipoort
