EU DAC8 Crypto Reporting: What Issuers and Exchanges Must File
EU DAC8 crypto reporting obligations take effect for 2026 data. This guide explains what CASPs, issuers, and operators must file, and how to comply.
EU DAC8 Crypto Reporting: What Issuers and Exchanges Must File
Council Directive 2023/2226 — DAC8 — entered into force on 17 October 2023, with Member States required to transpose it by 31 December 2025 and first reporting due by 31 January 2027 for calendar year 2026 data. That deadline is no longer abstract. If your platform facilitates crypto-asset transactions for EU-resident users, the clock is already running on data collection obligations that began 1 January 2026.
TL;DR
- DAC8 extends the EU's automatic exchange of information (AEOI) framework to crypto-asset service providers (CASPs), e-money token issuers, and certain operators of crypto-asset transfer services.
- Reportable data covers user identity, tax residency, and aggregate transaction values across exchanges, transfers, and certain non-custodial arrangements.
- First reports covering calendar year 2026 must reach competent authorities by 31 January 2027.
- The regime mirrors the OECD's Crypto-Asset Reporting Framework (CARF) but adds EU-specific due diligence and penalty requirements.
- Non-EU platforms serving EU residents are in scope if they lack a physical EU presence — they must register in a designated Member State.
What DAC8 Actually Requires
Scope: Who Is a Reporting Crypto-Asset Operator?
DAC8 defines "Reporting Crypto-Asset Service Providers" (RCASPs) by reference to MiCA's CASP definition, then extends it. Any entity that provides exchange services between crypto-assets and fiat currencies, crypto-to-crypto exchange, transfer services, or custody services — and that has at least one EU-resident user — falls within scope.
E-money token issuers under MiCA Title III are separately covered. So are operators facilitating transfers of crypto-assets on behalf of customers, even where the operator doesn't hold custody. The practical effect: a non-custodial DEX aggregator that routes orders for EU users may be caught, depending on how "facilitating" is interpreted by the transposing Member State.
Non-EU entities without an EU establishment must register with a single Member State under Article 8ad(3). The European Commission maintains a central register of such entities. Failure to register doesn't eliminate the obligation — it just means the entity is non-compliant from day one.
What Must Be Reported
For each Reportable User (an EU tax-resident individual or entity), RCASPs must collect and report:
Identity data
- Full legal name, primary address, date and place of birth (individuals), or registered name and address (entities)
- Tax Identification Number (TIN) for each relevant Member State
- For entities: LEI or equivalent, plus controlling person details where applicable
Transaction data — per crypto-asset type
- Aggregate gross proceeds from sales and exchanges (fiat-denominated)
- Aggregate fair market value of crypto-to-crypto exchanges
- Aggregate value of transfers out to unhosted wallets or third-party addresses
- Number of transactions underlying each aggregate
DAC8 uses a "per-asset" granularity requirement. You can't simply report a single total across BTC, ETH, and stablecoins — each crypto-asset type is reported separately. The Directive's Annex VI, Section IV defines "crypto-asset type" by reference to the underlying distributed ledger or protocol, which creates real classification questions for wrapped tokens and bridged assets.
Due Diligence Obligations
Before reporting, RCASPs must conduct due diligence on users. The framework distinguishes:
Pre-existing users (accounts opened before 1 January 2026): RCASPs have until 31 December 2026 to complete due diligence on these accounts. A self-certification procedure is the primary mechanism — users confirm their tax residency and TIN. Where self-certification is unavailable or implausible, RCASPs fall back on documentary evidence.
New users (accounts opened from 1 January 2026): Self-certification must be obtained at onboarding, before any reportable transaction is executed.
The "reasonableness" standard matters here. RCASPs can't simply accept a self-certification that contradicts other KYC data on file. If a user certifies French tax residency but their onboarding documents show a German address, the RCASP must resolve the inconsistency before relying on the certification.
Penalties and Enforcement
DAC8 requires Member States to impose "effective, proportionate and dissuasive" penalties. The Directive doesn't set a floor, so penalty regimes vary. Germany's transposing legislation, for instance, references existing administrative penalty frameworks under the Abgabenordnung. France's implementation aligns with existing AEOI penalty structures under the Code général des impôts. Expect penalties in the €5,000–€500,000 range per infringement across major Member States, with some jurisdictions applying per-account or per-transaction multipliers.
What This Means for Your Company
The operational lift here is substantial. DAC8 isn't a simple checkbox — it requires integrating tax residency collection into onboarding flows, building or licensing a reporting engine capable of per-asset aggregation, and establishing a legal entity or registration in at least one Member State if you're currently operating without EU presence.
For exchanges and custodians already holding MiCA authorization: your existing KYC infrastructure covers most identity data, but TIN collection is new for many platforms. Most crypto exchanges don't currently ask for TINs at onboarding. That gap needs closing before any new account is opened in 2026.
For e-money token issuers: you're subject to a parallel but distinct reporting track. The aggregate value of e-money token transfers — not just exchanges — is reportable. If your stablecoin is used heavily for peer-to-peer transfers, the volume of reportable events could be significant.
For DeFi protocols and non-custodial operators: the scope question is genuinely unsettled. The Directive's language around "facilitating" transfers is broad, and at least two Member States' transposing legislation has taken an expansive view. If your protocol collects fees, maintains a front-end, or exercises any control over user funds, get a legal opinion before assuming you're out of scope.
For non-EU platforms: the registration requirement is real and enforceable. The Commission's central register is live. Member States are required to share information about non-compliant non-EU operators with each other. Operating without registration while serving EU users is a compliance failure that compounds over time.
How to Operationalize
Step 1 — Classify your entity Determine whether you're an RCASP, an e-money token issuer, or both. If you're non-EU, identify your registration Member State (typically where you have the most EU users or an existing legal relationship).
Step 2 — Audit your onboarding flow Map every point where user data is collected. Identify gaps in TIN collection and tax residency confirmation. Build a self-certification module that captures the required fields and timestamps the certification for audit purposes.
Step 3 — Classify your crypto-asset inventory Work with your product and legal teams to categorize every asset on your platform by DAC8's "crypto-asset type" definition. Flag edge cases: wrapped tokens, bridged assets, synthetic instruments, and staking derivatives all require individual analysis.
Step 4 — Build or procure a reporting engine The report format follows the OECD CARF XML schema, adapted for EU submission. Several third-party tax reporting vendors (Chainalysis Tax, TaxBit, Lukka) have DAC8-compatible modules. Evaluate build vs. buy based on transaction volume and internal engineering capacity.
Step 5 — Establish a data retention policy DAC8 requires retention of due diligence records and supporting documentation for five years after the reporting period. Align this with your existing GDPR retention schedules — there's a tension between GDPR's data minimization principle and DAC8's retention mandate that requires explicit policy treatment.
Step 6 — Complete pre-existing user due diligence Run a TIN collection campaign for all pre-existing users before 31 December 2026. Build in escalation procedures for users who don't respond, and document your reasonable efforts — this matters for penalty mitigation.
Step 7 — File by 31 January 2027 Submit the XML report to your competent authority's designated portal. Test your submission format against the authority's validation schema before the deadline. Several Member States are running sandbox environments for test submissions in Q3–Q4 2026.
Common Mistakes and How to Avoid Them
Assuming MiCA authorization equals DAC8 compliance. MiCA and DAC8 have overlapping but distinct scope. MiCA authorization doesn't automatically satisfy DAC8 registration or reporting obligations. Treat them as separate compliance tracks.
Collecting TINs without validating format. EU Member States use different TIN formats and lengths. Accepting any alphanumeric string as a valid TIN creates data quality problems that will surface at submission. Use the OECD's TIN format database to build validation logic into your onboarding form.
Ignoring the "unhosted wallet" transfer reporting requirement. Many platforms focus on exchange transactions and miss the obligation to report aggregate outbound transfers to unhosted wallets. This is a distinct reportable event under Annex VI, Section II, paragraph C(2).
Treating the 31 January 2027 deadline as the start of data collection. Data collection obligations began 1 January 2026. If you haven't started collecting TINs and self-certifications from new users, you're already behind.
Underestimating the GDPR intersection. You'll need a lawful basis for processing TINs and tax residency data. Legal obligation under Article 6(1)(c) GDPR covers the collection, but your privacy notice must be updated to reflect DAC8 processing purposes before you start collecting.
FAQ
Q: Does DAC8 apply to NFT platforms?
A: It depends on the NFT's classification. DAC8 covers "crypto-assets" as defined in MiCA. NFTs that qualify as unique and non-fungible under MiCA Article 2(5) are generally excluded. But fractionalized NFTs, or NFTs used as financial instruments, may fall back into scope. The European Securities and Markets Authority (ESMA) has flagged this classification question in its MiCA guidance, and DAC8 follows the same definitional framework.
Q: We're a US-based exchange with EU users but no EU entity. Do we need to register?
A: Yes. Article 8ad(3) of DAC8 requires non-EU RCASPs to register with a single Member State. You choose the Member State — most non-EU platforms are registering in Ireland, Luxembourg, or the Netherlands based on existing relationships. Registration doesn't require establishing a legal entity, but it does require a designated contact point and submission of reports through that Member State's portal.
Q: How does DAC8 interact with the OECD CARF for platforms already implementing CARF in other jurisdictions?
A: DAC8 is explicitly designed to be equivalent to CARF, and the EU negotiated this alignment intentionally to avoid double-reporting. Where a Member State has activated the CARF competent authority agreement with a third country, information exchanged under CARF can satisfy DAC8 obligations for users resident in that third country. For EU-resident users, DAC8 governs regardless of CARF implementation elsewhere.
Q: What's the penalty for missing the 31 January 2027 deadline?
A: Penalties are set by each Member State. The Directive requires them to be "effective, proportionate and dissuasive" but sets no EU-wide minimum. Based on transposing legislation published through Q1 2026, penalties range from approximately €5,000 for minor procedural failures to €500,000+ for systematic non-reporting. Some Member States apply per-account multipliers. Late filing with a reasonable explanation typically attracts lower penalties than non-filing.
Q: Are staking rewards reportable under DAC8?
A: Staking rewards received by users are not directly reportable as a transaction type under DAC8's current framework — the Directive focuses on exchanges and transfers, not income events. However, if a user subsequently exchanges or transfers staking rewards, those transactions are reportable. This is a known gap that the Commission has flagged for potential future amendment.
Sources
- Council Directive (EU) 2023/2226 of 17 October 2023 amending Directive 2011/16/EU on administrative cooperation in the field of taxation (DAC8) — Official Journal of the European Union, L 2023/2226
- OECD, Crypto-Asset Reporting Framework and Amendments to the Common Reporting Standard (2022)
- Regulation (EU) 2023/1114 of the European Parliament and of the Council on markets in crypto-assets (MiCA) — Official Journal of the European Union, L 2023/1114
- European Commission, Directorate-General for Taxation and Customs Union — DAC8 Implementation Guidance and Central Register of Non-EU RCASPs
Disclaimer
This article is provided for general informational purposes only and does not constitute legal, tax, or regulatory advice. DAC8 transposition varies by Member State, and the obligations described here reflect the Directive's requirements as published; national implementing legislation may differ. Consult qualified legal counsel in the relevant jurisdiction before making compliance decisions. BizLegal-AI Intelligence Desk and its contributors accept no liability for actions taken or not taken based on this content.