DAC8 explained — the EU crypto-asset reporting obligation for CASPs

DAC8 is the EU’s transposition of the OECD’s Crypto-Asset Reporting Framework — and the first reporting cycle for crypto-asset service providers begins on 1 January 2026. The substance is shared across the bloc; the procedural reality is that each member state has its own portal, its own intake forms and its own implementing law, and the differences between them matter when you operate cross-border. This piece walks through what DAC8 captures, who has to file, the exact deadlines, and how a payments firm builds the pipeline — with worked examples showing how the rules play out.

1. What DAC8 is

DAC8 — Council Directive (EU) 2023/2226 amending Directive 2011/16/EU on administrative cooperation in the field of taxation — extends the EU’s automatic-exchange-of-information regime to crypto-assets. It transposes the OECD’s Crypto-Asset Reporting Framework (CARF) into EU law and aligns it with the wider DAC architecture that already covers financial accounts (DAC2 / CRS), digital platforms (DAC7) and tax rulings.

DAC8 is broader than crypto alone: it also brings e-money and central-bank digital currencies into the CRS scope, and it extends the exchange of advance cross-border rulings to high-net-worth individuals for rulings above EUR 1,500,000. But the part that reshapes a payments or crypto firm’s operations is the crypto-asset reporting obligation, and that is the focus here.

2. The timeline that matters

Three dates anchor the regime, and firms routinely confuse them:

• 31 December 2025 — the deadline for member states to transpose DAC8 into national law.
• 1 January 2026 — the rules apply; the first reportable period is calendar year 2026.
• 1 January to 30 September 2027 — the window in which reporting crypto-asset service providers file the 2026 data with their national authority and the authorities then exchange the non-resident information between member states, within nine months of the reporting year end.

So a firm operating in 2026 does its first live filing in 2027. The trap is treating 2026 as a preparation year — it is the first reportable year, so the data has to be captured from 1 January 2026, not built retrospectively in 2027.

3. Who is in scope

Two categories of “Reporting Crypto-Asset Service Providers” (RCASPs):

• EU-authorised CASPs under MiCA — every CASP licensed under Regulation (EU) 2023/1114. Authorisation triggers RCASP status automatically, with no separate registration.
• Non-EU operators with EU users — operators not established in the EU but providing crypto-asset services to EU-resident users. They must register with a single EU competent authority and report through it.

The scope mirrors CARF: it captures exchanges, brokers, custodians, issuers offering exchange services, and certain crypto-ATM operators. Pure software providers (wallet code, node operators) are out of scope unless they exercise control over user assets. Critically, there is no de-minimis threshold — a single €50 purchase by an EU-resident user in 2026 puts that user in the report.

4. What gets reported

For each EU-resident user, per calendar year:

• Identification — name, address, member state(s) of residence, taxpayer-identification number (TIN), date and place of birth.
• For each “relevant crypto-asset” the user transacted in: the aggregate gross amount paid or received for acquisitions and disposals, against fiat and against other crypto-assets, with the number of units.
• For transfers, the aggregate fair-market value and the number of units, split by the wallet-address category (custodial vs self-hosted) and counterparty class.
• For retail-payment transactions, the aggregate fair-market value where the goods or services exceed USD/EUR 50,000 in a single transaction.

The schema is the OECD CARF XML, with EU-specific extensions maintained by the European Commission’s Directorate-General for Taxation and Customs Union (DG TAXUD).

5. The due-diligence layer

DAC8 introduces customer due-diligence obligations broader than what most CASPs run for AML alone:

• Self-certification at onboarding — the user attests their tax residence(s) and TIN(s), and the certification must be collected before the account is active.
• Reasonableness check — the CASP cross-references the self-certification against KYC data and other reliable indicia, and cannot rely on a certification it has reason to doubt.
• Change-in-circumstance triggers — a material update to the user’s file forces re-certification.
• Record retention — the records and the steps taken must be kept, typically for at least five years from the end of the reportable period.

For CASPs that already run a clean MiCA-aligned KYC programme, the gap to DAC8 is moderate; for those built on a thin onboarding flow, it is a meaningful uplift, because the tax self-certification is a distinct data point from the AML identity check.

6. The six core jurisdictions, where they diverge

The substantive framework is identical EU-wide. The implementation differences are procedural — different receiving authorities and portals:

• 🇪🇸 Spain — transposed through amendments to the General Tax Law; filings go through the AEAT’s electronic portal.
• 🇳🇱 Netherlands — transposed in the international-assistance tax legislation, with filings to the Belastingdienst’s central exchange unit.
• 🇫🇷 France — transposed in the Code général des impôts; the Direction générale des Finances publiques (DGFiP) is the receiving authority.
• 🇮🇹 Italy — transposed by legislative decree amending the fiscal code; the Agenzia delle Entrate receives the data.
• 🇩🇪 Germany — transposed by extending the platform tax-transparency framework; the Bundeszentralamt für Steuern (BZSt) is the receiving authority.
• 🇱🇺 Luxembourg — transposed by amending the Luxembourg DAC implementing law; the Administration des contributions directes (ACD) receives the data.

For a CASP authorised in one member state and serving users across the bloc, the home-state filing is the single point of submission. The forwarding to other member states happens authority-to-authority, not via the CASP.

7. How a firm builds the DAC8 pipeline

The reporting cycle is best treated as four layers, built in order:

• Certification layer — capture tax residence and TIN at onboarding, store the self-certification and the reasonableness evidence, and wire the change-in-circumstance triggers into the KYC-refresh flow.
• Aggregation layer — a year-end batch that groups every transaction by user, then by relevant crypto-asset, then by type (acquisition, disposal, transfer, retail payment), converting to fiat fair-market value.
• Schema layer — map the aggregates onto the CARF XML with the EU extensions, and validate against the schema before submission.
• Portal layer — submit to the home-state authority through its portal, keep the acknowledgement, and reconcile the accepted record count against the internal user base.

8. Three worked examples

The regime is mechanical, so it is clearest through the cases a firm actually meets.

• MiCA CASP already live. An exchange authorised under MiCA in one member state serves users across the EU. Rule: MiCA authorisation makes it an RCASP automatically from 1 January 2026 — no separate registration. Action: it captures tax self-certifications from day one of 2026, runs the year-end aggregation, and files a single CARF XML return with its home authority in 2027. Outcome: home-authority filing discharges the obligation for all member states, which receive their residents’ data by exchange.
• Non-EU exchange with EU customers. An operator established outside the EU has EU-resident users but no EU authorisation. Rule: it is still an RCASP and must register with a single EU competent authority. Action: it picks one member state, registers, and files there. Outcome: one registration and one filing cover all its EU-resident users; the chosen state forwards the data onward.
• Payments firm adding crypto. A firm holding an EMI licence launches a crypto-trading feature under a MiCA CASP authorisation. Rule: its fiat-account activity may fall under DAC2 / CRS and its crypto activity under DAC8 — two parallel regimes. Action: it reuses the CRS tax-residence data it already collects, extends the aggregation to crypto assets, and files two returns to the same authority. Outcome: one shared due-diligence layer feeds both regimes, avoiding a duplicate onboarding flow.

9. How DAC8 differs from the other DACs

A firm that holds both a CASP authorisation and an EMI authorisation can fall under both DAC8 (for crypto activity) and DAC2 / CRS (for fiat-account activity) — see our CESOP overview for the parallel VAT-side regime.

10. FAQ

11. What to do, today

• Treat 2026 as the first reportable year, not a preparation year — the data must be captured from 1 January 2026.
• Map your existing onboarding flow against the DAC8 self-certification requirements and close the tax-residence / TIN gap.
• Build the per-user, per-asset aggregation as a year-end batch, not a real-time feed.
• Identify your home-state competent authority and confirm the portal access and credentials needed for the 2027 window.
• If you also hold an EMI / PI licence, plan DAC8 alongside CRS — the customer-due-diligence layers overlap and should share one pipeline.

Related: MiCA white paper drafting · What is CESOP reporting? · AML representative across the EU · CESOP reporting in Spain (Modelo 379) · DAC7 platform-operator reporting · DAC8 XML reporting — the data build · Spain’s crypto-asset information returns (modelo 172/175) · CARF and how it lines up with DAC8