EU-wide

CESOP data and system readiness: the four layers

Fintech Passport

July 29, 2026 · 12-min read

CESOP data and system readiness: the four layers

CESOP data and system readiness is not one question but four: whether you are the reporting PSP, which payees crossed 25 cross-border payments, which member states you owe a file to, and whether your systems can fill all 15 Annex fields and act on a rejection. The rules have applied since 1 January 2024, PSPs file by the end of the month after each quarter, and the Commission’s current schema is XSD 4.04 with User Guide v7.00. A firm that gets three layers right still files a rejected or non-compliant return. This piece walks the layers in build order.

Last reviewed: 3 November 2026

1. What CESOP readiness means, and the legal frame

Data and system readiness for CESOP means a payment service provider can prove, every quarter, four things: that it identifies which of its payments are cross-border and in scope; that it counts them per payee and per member state against the threshold of more than 25; that it knows every member state it must file in; and that it can populate the electronic form from its own systems and correct what comes back rejected.

The legal frame is three texts. Council Directive (EU) 2020/284 inserted Articles 243a to 243d into the VAT Directive (2006/112/EC): definitions, the record-keeping duty, the location rules and the data list. Council Regulation (EU) 2020/283 added Articles 24a to 24f to Regulation (EU) No 904/2010, creating the Central Electronic System of Payment Information and the timetable: member states collect the data from PSPs by the end of the month following the calendar quarter and pass it to CESOP by the tenth day of the second month. Commission Implementing Regulation (EU) 2022/1504 sets the technical measures for running CESOP and, in Article 4 and its Annex, requires the standard form to be submitted as XML following a 15-box data table. All three apply from 1 January 2024, so the first quarterly files were due by 30 April 2024.

The four layers matter because they depend on each other. A scoping defect becomes a threshold defect, then a filing-location defect, and it surfaces only when a validation result arrives weeks after the deadline. For the rules themselves, start with what CESOP reporting is. This page is about the build.

2. Layer one: are you the reporting PSP?

Article 243a borrows its definitions from PSD2. A “payment service provider” means the categories in points (a) to (d) of Article 1(1) of Directive (EU) 2015/2366: credit institutions, e-money institutions, post-office giro institutions and payment institutions, plus firms benefiting from an Article 32 exemption. Only the services in points 3 to 6 of PSD2 Annex I count: credit transfers, direct debits and card payments (with or without a credit line), issuing and acquiring, and money remittance. Cash deposits and withdrawals, payment initiation and account information fall outside, and the Commission’s Data Quality Checklist (June 2026) asks you to confirm that you exclude them.

A payment is cross-border when the payer is located in one member state and the payee is in another member state, a third territory or a third country. Location follows Article 243c: the IBAN, or another identifier that unambiguously locates the party, and only failing that the BIC of the party’s PSP.

The duty sits with the payee’s PSP. Under Article 243b(3) the payer’s PSP does not report a payment where at least one of the payee’s PSPs is located in a member state. One nuance trips up many builds: the payer’s PSP must still include those payments in its own threshold count. In practice an EU institution’s acquiring, e-money and incoming account flows make up the main reporting population. Outbound customer payments become reportable when the beneficiary’s PSP is outside the Union. The Checklist asks firms to tag each account movement as received-as-payee or sent-as-payer for exactly this reason.

Branches change the answer. The Commission’s Guidelines (v1.2, June 2025) treat branches of an EEA PSP operating in a member state as subject to the obligation in their own right, so the legal entity is not automatically the unit of analysis.

3. Layer two: counting to 25 correctly

Article 243b(2) triggers the duty when, in a calendar quarter, a PSP provides payment services for more than 25 cross-border payments to the same payee. Three counting rules turn that sentence into code:

Count per identifier. The basic count runs against the payee identifier from Article 243c(2): an IBAN, a merchant ID or an e-money account reference. Go past 25 and every cross-border payment to that identifier in the quarter becomes reportable.
Count per member state. The count is made per member state in which the services are provided. Establishments in several member states each calculate separately and do not consolidate at group level. The same applies to services provided through agents or directly.
Aggregate identifiers of one payee. Where the PSP knows that several identifiers belong to the same payee, it counts per payee. Under the Guidelines, aggregation applies only where the holder is the same natural or legal person, or a branch of the same company. Franchises and subsidiaries are not aggregated. For a joint account the payee is all holders together, so you aggregate only where every holder of both accounts is the same.

Two further rules affect the output. The XSD User Guide requires all transactions to one account to sit under a single Reported Payee: listing the same payee twice in one message (same name and account) breaks business rule CM-BR-0150 and rejects the whole message. And because reporting payees at or below the threshold is itself non-compliant, the engine’s output should be a list of qualifying payees that the data layer then filters on, never a data set of its own.

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 state. The Guidelines turn this into a practical rule: follow your payment licence. Home is where the licence was granted. Host is any other member state where you provide services through a branch, an agent or directly.

How you reach the market	Where those payments are reported
Licensed and active in one member state only	Home member state
Branch in another member state	That host state, for the payments executed there
Agent in another member state	That host state, for the payments executed there
Free provision of services under a passport	Each host state where services are provided

The Guidelines also close the obvious escape route: the proxy flexibility for locating payers and payees under Article 243c cannot be used to avoid filing in a host state. In practice each state runs its own portal, registration and file conventions; see CESOP reporting compared across the EU.

Change may be coming but is not law. In August 2025 the Commission surveyed tax administrations and PSPs about letting PSPs report only to their home member state. Its February 2026 summary counts about 1,700 PSPs reporting, roughly 350 of them in two or more member states, and records that payment and e-money institutions largely favoured the idea while credit institutions preferred the status quo. Until a legal change is adopted, plan for one channel per state.

5. Layer four: the 15 boxes and three meanings of “mandatory”

Article 243d lists the record. The Annex to Implementing Regulation 2022/1504 turns it into 15 boxes, each with its own mandatory status:

Boxes	Elements	Status in the Annex
1, 2	BIC/ID of the reporting PSP; payee name (all names held, legal and business)	Mandatory
3, 6	Payee VAT/TIN; payee address (all addresses held)	Optional mandatory
4	Payee account ID (IBAN, or merchant/card-acceptor/e-account ID)	Mandatory when funds go to a payment account of the payee
5	BIC/ID of the PSP acting for a payee without a payment account	Only in that case
8, 9, 10, 14	Date/time; amount; currency; transaction ID	Mandatory
11, 12	Member state of origin of a payment; of destination of a refund	Depending on payment or refund
13	Source used to locate the payer (payer IBAN, card BIN range, other)	Mandatory, but the identifier itself is never sent
7, 15	Refund link; payer physically present at the merchant	If applicable

Two design consequences follow. First, boxes 4 and 5 are mutually exclusive: business rule RP-BR-0080 requires either the account identifier or the representative, never both and never neither. Second, “optional mandatory” means mandatory if available. A VAT number or address held in onboarding records but never wired into the extract passes validation yet still breaches the duty. Map the fields from your source systems, not from what your extract happens to produce. Field-level mapping is covered in building the CESOP quarterly file.

6. Schema versions and pre-validation

The Commission’s XSD package (User Guide v7.00, published April 2026) introduces XSD 4.04 with CESOP release 1.8.2. That release accepts files in versions 4.02, 4.03 and 4.04. Versions 4.00 and 4.01 have not been accepted since release 1.7.0, and a file with a missing or unsupported version is fully rejected. Version 4.04 adds warnings to validation results, for example an account that passes the IBAN check but is reported under another account type. Warnings do not change the outcome, but they are stored centrally, and administrations can follow them up with PSPs filing older versions. The Commission also notes that national implementation calendars can lag the central system, so confirm the accepted version with each administration you file to.

The Guidelines expect PSPs to check both the schema and the business rules before submitting. The Commission publishes a Validation Module for this (v1.7.1 with User Manual v6.00, October 2025) and the June 2026 Data Quality Checklist, a self-review list that covers filing locations, scope, PSP identifiers and location logic.

7. The rejection and correction loop

A file can have three outcomes, and each one leads to different work:

Fully rejected. The message is void and you resubmit it in full. A national administration validates the XSD on receipt and can issue a full rejection itself. It reports all technical errors at once.
Partially rejected. Only CESOP can issue this, because some business rules need historical data. Business rules are generally checked centrally, although administrations may check some. You answer with a correction message (MessageTypeIndic CESOP101) that carries only the payees in error, each linked to the original through CorrDocRefId. To fix individual transactions, you delete the reported payee and send it again with the correct transactions.
Validated, possibly with warnings.

For resubmissions the Guidelines recommend a window of no more than 30 calendar days from the date the member state sends the validation message. If you miss it, a notification with a compliance deadline follows, and national sanctions apply. Data that arrives late is still forwarded once it validates, but that does not prevent a penalty for lateness. Over-reporting is also non-compliance: domestic payments or payees at or below the threshold fall under the same treatment.

Spontaneous corrections have no EU deadline. They follow the User Guide correction rules and become impossible once CESOP deletes the original, which it keeps for a maximum of five years from the end of the year of transmission. Run that clock separately from your own retention duty under Article 243b(4)(a): three calendar years from the end of the year of the payment.

8. Three scenarios where readiness fails

Facts: an e-money institution licensed in one member state passports into eight others and sends one quarterly file to its home administration. Analysis: the file validates but is substantively wrong. Under Article 243b(4)(b), payments executed in each host state go to that state. The fix is architectural: partition the extract by the state where the service is provided, reconcile the partitions against the passport notifications, and set up eight more submission channels.

Facts: a marketplace seller receives 15 cross-border credit transfers to an IBAN and 14 card settlements against a merchant ID in one quarter, and the PSP knows both identifiers belong to the same company. Analysis: the aggregate is 29, so all 29 payments are reportable, each under its own account identifier and not as one merged account. A neighbouring seller with 20 payments over two identifiers stays out, and reporting it anyway is a breach.

Facts: a firm files on the deadline, receives a positive national XSD check, and closes the quarter. Nineteen days later CESOP issues a partial rejection naming 40 payees with invalid IBANs. Analysis: a correction message for those 40 payees, correlated by CorrDocRefId, must go out within the window the administration sets. Nobody owns the mailbox where the result arrived. The gap is not data quality: the feedback loop was never staffed.

9. FAQ

Am I subject to CESOP?

If you are a PSP under Article 243a that provides payment services for more than 25 cross-border payments to the same payee in a quarter, yes, for those payees. The duty sits with the payee’s PSP and moves to the payer’s PSP only when no PSP of the payee is located in a member state.

Do I have to file if no payee crossed the threshold?

EU law does not require it. The XSD User Guide offers a voluntary “No Payment Data” message (CESOP102) that contains only the reporting PSP. Whether an administration expects it is a national question; the logic is covered in what a nil return is.

Is the threshold per payee or per account?

Per identifier as a starting point, and per payee where you know that several identifiers belong to the same natural or legal person. Franchises and subsidiaries are separate payees.

We passport across the EU. Can we file everything at home?

Not under current law. Payments executed in a host state are reported there. A home-state-only model was surveyed in 2025, but nothing has changed until it is adopted.

Which XSD version should we build to?

The Commission’s current package is XSD 4.04 (User Guide v7.00). CESOP release 1.8.2 still accepts 4.02 and 4.03, but warnings are returned only for 4.04 files. Confirm each administration’s accepted versions before switching.

How long do we keep the data?

Three calendar years from the end of the year of the payment, in electronic form, under Article 243b(4)(a). CESOP itself keeps data for a maximum of five years.

10. What to do, today

For each payment rail, record whether you act as payee’s PSP or payer’s PSP, and include payer-side payments in the threshold count even where you do not report them.
Build payee identity resolution: the rule that says an IBAN, a merchant ID and an e-money reference belong to one legal person. It gates everything downstream.
Test the threshold engine with a 29-payment two-identifier payee (reported) and a 20-payment one (not reported).
Reconcile your filing map against your passport notifications and confirm one channel per member state.
Re-map the optional-mandatory fields (VAT/TIN, all addresses) from source systems, then pre-validate with the Commission module.
Check which XSD version each administration accepts, and plan the move to 4.04.
Name an owner for inbound validation results and give them the 30-day clock in writing.

11. Sources

Official texts and Commission material checked for this review:

Council Directive (EU) 2020/284: Articles 243a to 243d of the VAT Directive
Council Regulation (EU) 2020/283: Articles 24a to 24f of Regulation (EU) No 904/2010
Commission Implementing Regulation (EU) 2022/1504 and its Annex (the 15-box form)
European Commission CESOP page: Guidelines v1.2, XSD 4.04 and User Guide v7.00, Validation Module v1.7.1, Data Quality Checklist, simplification survey summary