DAC8 — the eighth iteration of the EU's Directive on Administrative Cooperation — fundamentally changes the tax reporting landscape for crypto asset service providers operating in Europe. For the first time, EU tax authorities will receive automatic, systematic data on the crypto transactions of their residents, closing a gap that regulators have described as one of the largest sources of unreported income in the bloc.
For crypto exchanges, custodians, and other CASPs, DAC8 isn't just a tax law problem — it's a data architecture, compliance operations, and regulatory monitoring challenge. The reporting obligations begin for the 2026 calendar year, with first reports due to national tax authorities by January 31, 2027. If your systems and processes aren't built to collect, validate, and submit compliant data by then, you will be in breach.
This guide explains what DAC8 requires, who it covers, what data must be collected and reported, and what a compliant DAC8 program looks like in practice.
What Is DAC8?
DAC8 is an amendment to Council Directive 2011/16/EU, the EU's framework for automatic exchange of tax information between member states. The directive was formally adopted in October 2023 and entered into force on November 13, 2023, with member states required to transpose it into national law by December 31, 2025, and reporting obligations starting January 1, 2026.
DAC8 extends the EU's existing automatic information exchange frameworks — which already cover bank accounts, financial instruments, and real estate — to crypto assets. It closely mirrors the OECD's Crypto-Asset Reporting Framework (CARF), which was published in 2022 and has been adopted by over 50 jurisdictions globally, ensuring consistency between the EU approach and the emerging global standard.
The core mechanism: Reporting Crypto-Asset Service Providers (RCASPs) — which broadly corresponds to entities that are CASPs under MiCA — must collect information about their EU-resident users' transactions and report it to the tax authority of the member state where the RCASP is established (or has its EU nexus). That member state's tax authority then automatically exchanges the data with the tax authority of the user's country of residence.
DAC8 and CARF are closely aligned but not identical. DAC8 applies specifically to EU-established RCASPs and EU-resident users, and information is exchanged via the EU's existing administrative cooperation infrastructure. CARF operates through the OECD's Multilateral Competent Authority Agreement framework. If you operate globally, you may face both sets of obligations depending on your jurisdiction footprint.
Who Is a Reporting Crypto-Asset Service Provider?
DAC8 applies to "Reporting Crypto-Asset Service Providers" — entities that provide crypto-asset services in the EU and meet the nexus test. The definition is broad and intentionally aligned with MiCA's concept of a CASP.
You are an RCASP and subject to DAC8 reporting if you:
- Are tax resident in an EU member state, OR
- Are incorporated or organized under the laws of an EU member state, OR
- Have a place of management in an EU member state, OR
- Have a permanent establishment in an EU member state
Non-EU entities without any EU nexus are not directly subject to DAC8 — but they should note that if they onboard EU-resident users, EU tax authorities are still entitled to seek information through other channels, and the absence of DAC8 data on a user may itself flag that user for scrutiny.
The types of services that trigger reporting obligations include:
- Exchange services between crypto assets and fiat currency
- Exchange services between different crypto assets
- Transfer services (moving crypto assets on behalf of users)
- Safekeeping and administration of crypto assets
- Participating or providing services related to offers and sales of crypto assets
Notably, DAC8 does not apply to decentralized protocols where there is no identifiable intermediary — but any centralized front-end that facilitates access to DeFi protocols will need to carefully consider whether it provides a "service" that falls within scope.
Who Must Be Reported? The Reportable Users
Not every user transaction needs to be reported — only those involving "Reportable Users." A reportable user is a customer who is:
- An individual or entity that is tax resident in an EU member state, OR
- An entity incorporated in an EU member state (even if managed elsewhere)
This means you need robust processes for determining the tax residency of your users at onboarding — not just their nationality or address. Tax residency and physical residency are often different, and DAC8 compliance requires accurate determination of which member state(s) each user is tax resident in.
DAC8 requires RCASPs to obtain a self-certification from users confirming their tax residency and tax identification number (TIN). Self-certifications must be obtained from all new users from January 1, 2026, and — critically — from existing users within 12 months of the directive's transposition date in each member state. If you cannot obtain a valid self-certification from a user after reasonable efforts, you may be required to treat them as a reportable person in the most likely jurisdiction.
What Data Must Be Collected and Reported?
The data requirements under DAC8 are extensive. For each reportable user, you must report the following to your national tax authority annually:
User Identification Data
- Full legal name
- Primary address
- Date of birth (for individuals) / date of incorporation (for entities)
- Place of birth (for individuals)
- Tax Identification Number (TIN) for each EU member state where the user is tax resident
- Crypto asset wallet addresses associated with the user
Transaction Data — Per Reportable User, Per Crypto Asset
- Exchanges for fiat currency: the aggregate gross amount in fiat (EUR equivalent), the number of transactions, and the aggregate number of crypto asset units involved
- Exchanges for other crypto assets: the aggregate fair market value in fiat equivalent, the number of transactions, and the aggregate number of units on each side of the exchange
- Transfers out to non-custodial wallets: aggregate fair market value and aggregate number of units transferred
- Transfers in from non-custodial wallets: aggregate fair market value and aggregate number of units received
- The type of crypto asset involved in each category of transaction
| Transaction Type | Data Required | Valuation Basis |
|---|---|---|
| Crypto → Fiat exchange | Aggregate gross fiat proceeds, transaction count, units sold | Actual fiat consideration received |
| Crypto → Crypto exchange | Aggregate FMV, transaction count, units on each side | Fair market value at time of exchange |
| Transfer out (to external wallet) | Aggregate FMV, units transferred | Fair market value at time of transfer |
| Transfer in (from external wallet) | Aggregate FMV, units received | Fair market value at time of receipt |
All fiat values must be reported in euros. If transactions were conducted in another currency, you must apply the relevant EUR exchange rate at the time of the transaction (or using a documented consistent methodology for daily/monthly average rates).
The Fair Market Value Problem
One of the most operationally challenging aspects of DAC8 is the requirement to record fair market value at the time of each transaction for crypto-to-crypto exchanges and transfers. Unlike fiat currency conversions where the actual consideration is known, determining the EUR equivalent value of a crypto-to-crypto swap requires access to reliable price feeds, documented valuation methodologies, and the infrastructure to capture and store price data at transaction time.
DAC8 allows RCASPs to use their own documented methodology, but that methodology must be:
- Based on objective, publicly verifiable price sources
- Applied consistently across all transactions of the same type
- Documented and retained for at least five years
- Capable of producing a EUR-denominated value for any supported crypto asset
For major assets with deep liquid markets (BTC, ETH), this is straightforward. For long-tail assets with thin markets, you will need a documented fallback methodology — typically the last available reliable price from a reference exchange, or a volume-weighted average across exchanges that list the asset.
Don't wait until Q4 2026 to solve the fair market value problem. You need price feed infrastructure capturing spot prices at transaction time for every asset you support, stored with the transaction record, from January 1, 2026. Retroactively reconstructing prices for thousands of transactions across hundreds of assets from late-2026 historical data is far harder than capturing it in real time.
Reporting Format and Submission
DAC8 requires reports to be submitted in XML format, following a schema based on the OECD's CARF XML schema (adapted by the EU Commission). The report must be filed electronically with the tax authority of the member state where the RCASP has its EU nexus.
Key reporting deadlines:
- January 31, 2027: First report due, covering transactions in the 2026 calendar year
- January 31, 2028: Report for 2027 transactions
- Annual thereafter on January 31 of the following year
For RCASPs with EU nexus in multiple member states — for example, a group with licensed entities in Ireland and Luxembourg — the directive provides that you may elect a single member state for reporting purposes, with that state's tax authority responsible for distributing the data to others. However, the election mechanism and specific procedures vary by member state implementation.
Due Diligence Procedures
DAC8 doesn't just require reporting — it mandates specific due diligence procedures that must be in place to support accurate reporting. These are distinct from (though closely related to) your existing KYC/AML due diligence.
New User Onboarding (from January 1, 2026)
For every new user onboarding from January 1, 2026, you must:
- Obtain a completed self-certification form covering tax residency and TIN(s) for all relevant member states
- Verify the self-certification is not unreasonable in light of other information you hold
- Document the self-certification and retain it for at least five years after the last report in which the user appeared
- Obtain a new self-certification if you have reason to believe the user's tax residency has changed
Existing User Remediation
For users who were customers before January 1, 2026, you must obtain valid self-certifications within the time period specified by your member state's implementing legislation (typically 12–18 months from the transposition deadline of December 31, 2025).
In practice, this means a large-scale outreach and remediation programme for your existing user base — one that many platforms are currently designing or executing. The challenge is not just obtaining the certifications, but handling non-responsive users: DAC8 allows you to use other information in your records (address, phone, IP geolocation) to make a reasonable determination of tax residency if a user fails to respond after documented outreach.
Penalties and Enforcement
DAC8 leaves the penalty regime to member states, but requires that penalties be "effective, proportionate and dissuasive." In practice, the penalty frameworks being adopted across the EU are substantial:
- Germany: Fines up to €50,000 per reportable user for whom compliant data is not provided; additional penalties for late or materially incorrect reports
- France: €200 per missing or incorrect user record, up to 1% of unreported transaction value
- Netherlands: Fixed fine of €870 per user record with material errors, plus proportionate fines for systemic failures
- Ireland: Proposed fines of up to €5,000 per user record for deliberate non-reporting
Beyond financial penalties, DAC8 non-compliance can trigger supervisory scrutiny from your MiCA supervisor — since the same operational failures that cause DAC8 failures (inadequate user data collection, insufficient TIN validation) also reflect on your KYC/AML program quality. A DAC8 enforcement action is increasingly likely to draw a parallel look from your financial regulator.
EU tax authorities have been preparing for DAC8 data for over two years. Several member states' tax agencies have published compliance guidance, test XML schemas, and sandbox environments for RCASPs to validate their reporting outputs. The infrastructure for receiving, processing, and cross-referencing DAC8 data is built. The risk for non-compliant CASPs is not that authorities lack capacity to use the data — it's that the data gap from non-reporters will be conspicuous against the background of compliant peers.
Interaction with MiCA and AML Requirements
DAC8 doesn't exist in isolation. For EU-licensed CASPs, it sits alongside MiCA authorization requirements and the EU's 6th Anti-Money Laundering Directive (AMLD6) obligations. Understanding the interactions is important for building a coherent compliance program rather than three separate silos.
MiCA and DAC8 overlap on user identification: MiCA requires CASPs to collect identification information for all clients as part of authorization and ongoing compliance. DAC8's self-certification requirement goes further by requiring explicit tax residency declarations and TIN collection — but both can be handled in a unified onboarding flow if your systems are designed for it.
AML/KYC and DAC8 overlap on due diligence: Your existing EDD procedures for high-risk users should capture the information needed for DAC8 reporting. The gap is usually in retail users at lower transaction volumes who may not have been subject to enhanced due diligence — but who are now reportable under DAC8 regardless of transaction size.
Data retention aligns: Both AML/GDPR frameworks and DAC8 require retention periods of five years from the last transaction — though the specific clock-start events differ slightly. Building a unified data retention policy that satisfies both is more efficient than managing separate timelines.
Building Your DAC8 Compliance Program
A practical DAC8 readiness program has four workstreams running in parallel:
1. Data Infrastructure
Audit your current data capture against DAC8 requirements. The most common gaps are: TIN collection for EU residents, price/valuation capture for crypto-to-crypto transactions, wallet address linkage to user accounts, and structured data on transfer counterparties. Each gap needs a remediation plan with a clear owner and deadline.
2. User Remediation
Design and execute a phased outreach programme for existing users to obtain self-certifications. Segment users by risk of being EU tax residents (using address data, phone country codes, IP geolocation) and prioritize accordingly. Build the workflow for handling non-responsive users — including the documented escalation steps required before making a tax residency determination on incomplete information.
3. Reporting System
Build or procure the system to aggregate transaction data per user per crypto asset per year and generate compliant XML output. Test against the member state's published XML schema before the reporting window. The XML schema requirements are specific enough that manual preparation is not feasible at scale — this needs to be a software-generated output.
4. Regulatory Monitoring
DAC8 implementation guidance is still being issued at the national level. Member states have transposed the directive with variations in penalty structures, self-certification formats, and reporting procedures. A DAC8 compliance program needs a dedicated process for tracking national-level implementing legislation and guidance — not just the base directive.
Stay Current on DAC8 and EU Tax Regulation
RegPulse monitors the European Commission, EU member state tax authorities, and the OECD for DAC8 implementation updates, national transposition notices, and guidance on crypto reporting. Get the changes that matter delivered to your compliance team — before your reporting window.
Start your free trial →The Bigger Picture: Crypto Tax Transparency Is Permanent
DAC8 represents the completion of a regulatory arc that began when regulators recognized the scale of unreported crypto gains. The direction of travel — both in the EU and globally through CARF — is unambiguous: crypto transactions will be as visible to tax authorities as traditional bank account activity, and CASPs will be the mandatory reporters.
For compliance professionals, the important framing is that DAC8 is not a temporary burden that will ease. The reporting obligations begin in 2026 and will continue indefinitely, with scope likely to expand as regulators gain experience with the data and identify new categories of taxable crypto activity (staking rewards, DeFi yields, NFT disposals) that current DAC8 language may not fully address but future amendments will.
Building DAC8 compliance as a permanent operational capability — not a one-time project — is the right frame. That means investing in the data infrastructure, the due diligence processes, and the regulatory monitoring that will allow your program to evolve as the rules continue to develop. The exchanges that approach this strategically will spend less over time than those that scramble for each reporting deadline.