CESOP — the Central Electronic System of Payment information — is the EU's most significant cross-border payment transparency initiative to date. Established by Directive 2020/284 and operational from 1 January 2024, it places systematic data reporting obligations on payment service providers processing cross-border payments above a defined volume threshold. Understanding its scope, mechanics, and compliance requirements is essential for any PSP, merchant platform, or payment orchestration layer operating in the European market.
How CESOP Works
CESOP operates as a centralised EU-level database fed by data collected first at the national level. Each PSP submits quarterly reports to the tax authority in each member state where it provides services, and those national authorities then upload the consolidated data to the CESOP central system managed by the European Commission. The Eurofisc network of tax officials can then cross-reference datasets across member states to identify undeclared taxable activity.
Determine scope
For each calendar quarter, the PSP identifies every payee who received more than 25 cross-border payments originating from EU payers. Payments between PSPs in the same member state are out of scope; only cross-border flows count toward the threshold.
Collect payee data
For each in-scope payee, the PSP gathers: full name or business name, IBAN or BIC, VAT identification number where available, and registered address. This data is sourced from onboarding records and transaction metadata.
Aggregate transaction records
For every qualifying payment made to that payee during the quarter, the PSP records the payment date, amount, currency, originating member state, and whether the transaction is a refund. Refunds are reported separately and offset against the payment count.
Generate XML report
The compiled dataset is formatted into the standardised XML schema specified by the European Commission. Each member state may have additional submission portal requirements layered on top of the common schema, so PSPs operating across multiple countries must manage per-jurisdiction delivery.
Submit to national authority
Reports are submitted within one calendar month of the quarter end — so Q1 data is due by 30 April, Q2 by 31 July, and so on. The national tax authority validates the file and, once accepted, uploads it to the central CESOP database.
Retain records for three years
PSPs must keep all underlying payment records used to produce CESOP reports for a minimum of three full calendar years from the year of the relevant payment. This allows tax authorities to audit the reporting methodology, not just the outputs.
Why CESOP Matters
CESOP was not created in a regulatory vacuum — it was a direct policy response to the explosion of e-commerce and the VAT fraud patterns that accompanied it. The European Commission estimated the EU VAT gap at approximately €93 billion in 2020, with a significant share attributable to under-declared cross-border digital sales. By mandating that PSPs — rather than merchants — report payment flows, the regulation sidesteps the weakest link in self-declaration models.
The 25-transaction threshold is deliberately calibrated. Analysis by the Commission found that setting the trigger at 25 payments per quarter captures the vast majority of commercially active online sellers while excluding occasional private transactions. In practice, this means any seller generating meaningful B2C volume across EU borders falls within scope, and their PSPs are legally obligated to report regardless of whether the seller has registered for VAT.
Reporting scale
The European Commission projects that CESOP will generate hundreds of millions of payment records annually across the EU, making it one of the largest structured financial datasets available to tax authorities worldwide.
For PSPs, the compliance burden is substantial. A mid-size payment processor serving merchants across five EU countries may need to submit up to five separate national filings per quarter, each in the correct local format. For platforms routing payments on behalf of marketplaces, determining which entity holds the CESOP reporting obligation — the platform, the acquiring bank, or the e-money institution — requires careful contractual and regulatory analysis under the applicable European regulation.
CESOP vs. DAC7
Both CESOP and DAC7 are EU frameworks introduced to improve tax transparency in the digital economy, but they target different intermediaries and serve different tax collection goals. Understanding the distinction matters for any platform that could fall under both regimes simultaneously.
| Dimension | CESOP | DAC7 |
|---|---|---|
| Legal basis | Directive 2020/284 (VAT Directive amendment) | Directive 2021/514 (DAC7) |
| Obligated entity | Payment service providers | Digital platform operators |
| Data reported | Payment transaction flows | Seller income, activity, and identity |
| Tax purpose | VAT fraud detection | Income tax and VAT transparency |
| Effective date | 1 January 2024 | 1 January 2023 |
| Threshold | >25 cross-border payments/quarter per payee | Per-seller (de minimis exclusions apply) |
| Report recipient | National tax authority → CESOP central DB | National tax authority → cross-border exchange |
| Scope | EU-operating PSPs | EU-registered or EU-resident sellers on platforms |
| Refund handling | Refunds reported separately and offset | Not directly applicable |
A marketplace that also processes its own payments — common among large e-commerce platforms — may simultaneously be a DAC7-obligated platform operator and a CESOP-obligated PSP, requiring parallel compliance programmes with overlapping but non-identical data sets.
Types of CESOP Reporting Obligations
CESOP imposes obligations on different categories of PSP depending on their role in a transaction. Not all PSPs face identical reporting requirements; the framework distinguishes between the payer's PSP and the payee's PSP.
Payee's PSP (primary obligation): The PSP holding the payee's account — typically the acquiring bank or e-money institution — carries the primary CESOP reporting obligation. This entity has the most complete view of the payee's identity and the payments received.
Payer's PSP (secondary obligation): Where the payee does not have an EU-based PSP — common when funds flow to a non-EU merchant — the payer's PSP becomes responsible for reporting. This prevents cross-border transactions from escaping the framework simply because the recipient bank sits outside the EU.
Pass-through and intermediary PSPs: Technical service providers and payment facilitators that do not hold accounts but route transactions must assess whether they meet the legal definition of a PSP under PSD2. If they do, they are in scope. Pure technical intermediaries without PSP authorisation typically fall outside the reporting obligation, but legal analysis per country is required.
Multi-PSP transactions: When a single payment involves multiple PSPs (for example, a card scheme, an issuing bank, and an acquiring processor), only the PSP with the direct relationship to the payee's account reports. Duplicate filing is explicitly prohibited and must be avoided through inter-PSP coordination agreements.
Best Practices
Achieving reliable CESOP compliance requires different disciplines from merchant-facing teams and the engineers building the underlying infrastructure.
For Merchants
Ensure your VAT identification numbers are accurately recorded with every PSP you use for accepting payments. CESOP requires PSPs to include your VAT number in filings, and gaps in that data can trigger enquiries from tax authorities even when your VAT filings are correct. Cross-check that the legal entity name and address held by your acquiring bank matches your VAT registration exactly — mismatches are a common source of reconciliation errors in CESOP reports. If you operate across multiple EU markets through separate legal entities, confirm with your PSP which entity's data is being reported in which member state, to avoid double-counting or missed filings. Maintaining robust VAT compliance records aligned with your payment data simplifies any subsequent tax authority audit.
For Developers
Build a dedicated CESOP data pipeline early — retrofitting transaction systems to produce quarterly XML exports is costly. The schema requires granular per-transaction records including the originating country of the payer, which is not always captured by default in payment gateway integrations. Implement country-of-origin enrichment at the point of transaction creation, not as a post-processing step. Use a dedicated CESOP compliance module that maintains the three-year retention window and supports file versioning, since amended filings are allowed and sometimes necessary. Automate threshold monitoring per payee per quarter so the system flags in-scope payees in near-real time rather than during end-of-quarter batch processing. Ensure your AML data store and your CESOP data store share a common payee identifier to avoid identity resolution overhead at filing time.
Common Mistakes
Misidentifying the reporting entity. In complex payment chains involving payment facilitators, marketplaces, and acquiring banks, teams frequently assume another party is handling the CESOP obligation. Without a documented inter-party agreement specifying who files for each transaction type, gaps emerge. Every PSP in a chain must independently confirm its filing obligations rather than relying on assumptions about what another party is doing.
Applying the threshold at the account level instead of the payee level. CESOP counts payments per payee across all accounts and instruments. A merchant with multiple IBANs at the same PSP, or payments arriving via both card and bank transfer, must have all flows aggregated against a single payee identity before applying the 25-payment threshold.
Ignoring refunds. Refunds do not cancel out corresponding payments for threshold counting purposes — they are reported separately. Teams that strip refunds from their transaction extract before threshold calculation produce inaccurate scope assessments and, consequently, under-inclusive reports.
Submitting a single consolidated EU report. CESOP requires member-state-level reporting. A single consolidated EU filing does not satisfy the obligation. PSPs with operations in multiple EU countries must produce and submit individual reports to each relevant national tax authority.
Treating CESOP data as an IT task only. CESOP reports contain legally sensitive payee identification data. Storing that data without appropriate access controls, encryption at rest, and data retention policies creates both regulatory compliance risk and GDPR exposure. Data governance must be involved from day one of implementation.
CESOP and Tagada
Tagada operates as a payment orchestration layer, routing transactions across multiple PSPs and acquirers on behalf of merchants. This architecture has direct CESOP implications: when Tagada routes a cross-border payment through an acquiring PSP, that PSP holds the primary CESOP reporting obligation — but Tagada's transaction metadata enrichment directly determines the quality of what the PSP can report.
How Tagada helps with CESOP compliance
Tagada captures and normalises payer country-of-origin data at the point of transaction authorisation across all connected PSPs. This means merchants using Tagada have a single, consistent source of the cross-border payment metadata their PSPs need to file accurate CESOP reports — avoiding the data gaps that arise when each PSP holds only a partial view of the transaction.
For merchants managing multiple acquiring relationships through Tagada, the platform provides unified transaction exports that can be reconciled against CESOP filings from each PSP, making it straightforward to audit whether every qualifying transaction has been captured and correctly attributed to the right reporting entity in the right member state.