DAC8 Crypto-Asset Reporting for CASPs — 2026 Compliance

Why DAC8 matters beyond the tax team

DAC8 is the EU’s response to a regulatory blind spot. Crypto-asset transactions cross borders by default. Tax authorities had no automatic-exchange mechanism for them. The OECD developed the Crypto-Asset Reporting Framework (CARF) in 2022, and the EU transposed it via Council Directive (EU) 2023/2226 (DAC8) in October 2023. Member states had until 31 December 2025 to transpose; the substantive reporting obligations apply from 1 January 2026.

The operational consequence for CASPs and the broader RCASP universe is significant. DAC8 requires:

• Customer self-certification of tax-residence jurisdiction and Tax Identification Number (TIN)
• Annual reporting of transaction-level data by reportable crypto-asset
• A separate reporting flag for retail-payment transactions above EUR 50,000
• Internal data-retention for the reportable transactions

For CASPs that built their AML/KYC stack to the 5AMLD baseline, none of this data is collected today. The DAC8 build is a parallel data-collection workstream layered onto an existing KYC infrastructure, not a small addition.

What a RCASP is — and is not

The Reporting Crypto-Asset Service Provider (RCASP) definition in DAC8 is broader than the MiCA CASP definition. The MiCA CASP definition captures eight enumerated services and is anchored in the EU regulatory perimeter. The RCASP definition is anchored in the DAC tax-cooperation perimeter and captures:

• Any entity that effectuates exchange transactions involving Reportable Crypto-Assets on behalf of customers
• Any entity that operates a platform on which exchange transactions occur

The substantive overlap with MiCA CASP is large. Most authorised CASPs will also be RCASPs. But there are edge cases — for example, a non-EU centralised exchange that has EU tax-resident customers but no MiCA authorisation is a RCASP and must report under DAC8 even though it is not a MiCA CASP. The scoping question is separate.

The data fields

DAC8 specifies the data each RCASP must collect and report. For each reportable customer:

• Name, address, jurisdiction(s) of tax residence
• Tax Identification Number (TIN) in each jurisdiction of tax residence
• Date of birth (for individuals)
• Place of birth (where the jurisdiction of tax residence does not issue TINs)

For each reportable transaction during the calendar year, aggregated by Reportable Crypto-Asset:

• Number of units of the crypto-asset received and disposed of
• Total fair-market value received and disposed of
• Number of transactions
• For retail-payment transactions above EUR 50,000: separate identification of the merchant counterparty

The fair-market value calculation methodology is specified in the OECD CARF commentary — typically the price at which the transaction was actually executed, with documented fallback methodology for off-exchange transactions.

The remediation effort

Most CASPs operating before 1 January 2026 have customers in their database for whom they do not have DAC8-compliant data. The remediation effort breaks down:

New onboarding flow. Update the KYC onboarding flow to collect TIN and jurisdiction-of-tax-residence self-certification from the customer’s first interaction. This is the easy part — typically a sprint or two of engineering work.

Existing-customer remediation. Contact every existing customer with a request for the new data. Plan for a multi-stage outreach — email, in-app prompt, account-action gate. Customer-response rates of 60-70% in the first round are typical; the residual requires escalation through account-restriction mechanisms.

Data quality and verification. TIN format validation per jurisdiction. Cross-check against sanction lists. Documented retention of self-certification including the date and method of collection.

Reporting system build. Annual aggregation of transaction data by customer and Reportable Crypto-Asset, fair-market value calculation, XML/JSON output in the format the home tax administration accepts, electronic submission infrastructure.

For a platform with one million EU customers and a few thousand reportable assets, the build is a six-to-twelve-month project starting from a typical 5AMLD-baseline KYC infrastructure.

The retail-payment EUR 50,000 trigger

DAC8 has a separate reporting flag for retail crypto-asset payment transactions above EUR 50,000 to a merchant. The trigger is per transaction, not aggregated. The data point captured includes the merchant’s identification.

This matters operationally because the trigger sits outside the normal trading-flow reporting. A CASP that operates both a trading service and a merchant-payment service for retail customers needs to classify each flow separately and apply the trigger only to the merchant-payment side. CASPs that lump all customer outflows into a single reporting bucket miss the trigger and underreport.

Interface with the AMLR

DAC8 and AMLR have parallel but not identical data requirements. AMLR (Regulation (EU) 2024/1624, applying 10 July 2027) requires beneficial-ownership verification, PEP screening, customer due diligence with a different focus on transaction monitoring. DAC8 wants tax-residence determination, TIN collection, and transaction-level reporting for tax-exchange purposes.

The intersection is the customer onboarding flow. Both regimes require self-certification, both require ongoing data-quality maintenance, both require integration with national authority reporting systems. Building the two as separate projects produces duplicate customer touchpoints and duplicate compliance overhead. Coordinated data-architecture work — typically led by the data and compliance functions jointly — produces materially cheaper steady-state operations.

The buyer’s view

For a CASP scoping the DAC8 compliance lift in 2026, three priorities:

1. Treat it as an operations project, not a tax project. The tax team owns the regulatory interpretation; operations and engineering own the build.
2. Plan the existing-customer remediation early. Six months is tight; nine is realistic; twelve is comfortable.
3. Align with AMLR architecture. The 18-month gap between DAC8 (Jan 2026) and AMLR (July 2027) is the window to build a coordinated data layer rather than two parallel systems.

DAC8 is the EU framework. CARF — the OECD instrument — extends the reporting standard internationally as more jurisdictions sign on. CASPs operating in non-EU jurisdictions will face equivalent reporting under national CARF transpositions; designing the EU build to handle CARF data fields more broadly extends its life and avoids rework when other jurisdictions activate.