Folio v0.9 — CEX + On-chain Consolidation is liveSee what's new →

DAC8 vs CARF: How the EU and OECD Crypto Reporting Rules Differ in 2026

Regulation·

DAC8 vs CARF: How the EU and OECD Crypto Reporting Rules Differ in 2026

DAC8 took effect 1 January 2026 across the EU. CARF is the OECD framework it implements. Here's what differs in scope, data fields and deadlines, and what cross-border CASPs need to file twice.
Author avatar Wag3s TeamEditorial team specializing in Web3 finance, crypto tax, and DAO operations. Based in Zurich, Switzerland.

Reviewed by Wag3s Editorial Team — verified against EU Council Directive 2023/2226 and OECD CARF model rules (June 2023, MCAA-CARF amendments through November 2024) · Last reviewed May 2026

DAC8 vs CARF: How the EU and OECD Crypto Reporting Rules Differ in 2026

Two crypto reporting frameworks went live on 1 January 2026. They look the same on the surface — both require crypto-asset service providers to identify users, collect tax residency, and report transactions to tax authorities annually. They are not the same in practice. A platform operating in three EU Member States and four CARF-adopting jurisdictions outside the EU will file in seven places, against two slightly different rulebooks, with overlapping but non-identical data fields.

This guide unpacks where DAC8 (EU) and CARF (OECD) diverge, and what that means for CASPs designing reporting workflows in 2026.

TL;DR

  • DAC8 is the eighth amendment to the EU Directive on Administrative Cooperation. It transposes the OECD's Crypto-Asset Reporting Framework into binding EU law and adds EU-specific layers (MiCA alignment, e-money token coverage, retail-payment thresholds). Applies to MiCA-authorized CASPs from 1 January 2026.
  • CARF is the OECD's model framework, adopted via the Multilateral Competent Authority Agreement (MCAA-CARF). It applies in committed jurisdictions outside the EU as each one transposes it into national law — currently around 50 jurisdictions, with most going live on 1 January 2026 and a smaller group on 1 January 2027.
  • Most data fields overlap (illustratively, the large majority). What diverges is what matters operationally: e-money tokens, NFT scope, retail-payment thresholds, and reportable-user due-diligence procedures.
  • First reporting period: calendar year 2026 for both. DAC8 requires Member-State-to-Member-State exchange within 9 months of year-end (by 30 September 2027); national CASP filing deadlines vary within that window. CARF deadlines are set per adopting jurisdiction.
  • Cross-border CASPs build one data model and run two outputs, so the choice of accounting infrastructure matters more than picking sides.

What DAC8 and CARF actually are

CARF came first. The OECD published it in June 2023 in response to a request from the G20, then opened the MCAA-CARF for signature in November 2023. The model has three components: a tax-information collection standard for CASPs, a due-diligence regime for identifying reportable users, and a multilateral exchange mechanism between adopting tax authorities. It is a model — countries decide whether to adopt, and what amendments to layer on.

DAC8 is the EU's adoption mechanism. The European Council approved it on 17 October 2023 as Directive (EU) 2023/2226, amending the existing Directive on Administrative Cooperation. By making it a directive rather than a regulation, the EU left transposition to each Member State, which is why national rules are technically not identical even though they all implement the same baseline.

The two frameworks share core architecture: CASPs in scope identify their users, collect tax residency and TIN data, perform due diligence to confirm the certification, then aggregate transaction data per user per year and report it to their home tax authority. Authorities then exchange the data with each other.

What differs is what gets reported, by whom, under what definitions, and with what deadlines.

Where they actually diverge

Scope of in-scope assets

CARF defines a "Relevant Crypto-Asset" as any digital representation of value relying on cryptographically secured distributed ledger technology, with two carve-outs: (a) central bank digital currencies (CBDCs), and (b) specified electronic money products that meet narrow criteria.

DAC8 starts from the same definition but pulls e-money tokens (EMTs) and asset-referenced tokens (ARTs) back into scope. The reason is MiCA: EMTs and ARTs are explicitly regulated under MiCA Title III and IV, and the EU policy view is that reporting must cover the regulated perimeter. A CASP listing EURC, USDC EU, or a MiCA-authorized stablecoin must include those positions in its DAC8 report. Outside the EU, the same instrument may be carved out of CARF reporting.

Practical impact: a payment processor running a USDC EU rail for B2B settlements is fully reportable under DAC8 from euro one, and partially or not reportable under CARF in another adopting jurisdiction.

NFTs

DAC8 follows the MiCA fungibility test. Pure, unique NFTs are out of scope. Fractionalized NFTs, series with identical or near-identical pieces (large PFP collections), and NFTs used as a payment medium come back into scope. The assessment is per-collection, which adds operational overhead for marketplaces.

CARF is closer to a bright-line exclusion: NFTs that are truly unique and not used as payment are not relevant crypto-assets. There's no MiCA-style fungibility test layered on top.

A marketplace dealing exclusively in 1/1 generative art has nothing to file under either framework. A marketplace dealing in mixed collections (10,000-piece PFPs alongside 1/1s) has filing obligations under DAC8 that don't exist under CARF.

Retail-payment transactions

DAC8 has an explicit €50,000 threshold for retail-payment transactions processed by a CASP. Above the threshold, the transaction is in scope even if the recipient is not otherwise a reportable user.

CARF handles payment-processor transactions through its own due-diligence rules but without that single hard threshold in the model text. Each adopting jurisdiction sets its own approach. Confirm the threshold treatment in each jurisdiction you serve rather than assuming a uniform figure.

For invoicing platforms and crypto B2B payment processors, this is the single biggest implementation headache. The same transaction may be reportable in one filing and not in another.

Data fields per reportable user

The two frameworks share a near-identical baseline: name, address, tax residency, TIN, date of birth (individuals), legal entity identifier (entities), and an annual aggregate of fair-market value and units acquired or disposed of for each Relevant Crypto-Asset.

DAC8 adds three EU-specific items:

  1. Self-certification reference and refresh date — Member States may require records of when the user last re-confirmed residency
  2. MiCA whitepaper identifier for the asset, when one exists
  3. A distinction between transactions executed against fiat versus crypto-to-crypto, with the counterparty category tagged (consumer, professional, CASP)

CARF requires (1) implicitly through due-diligence rules, but not the explicit reference field. CARF doesn't have (2) at all. CARF has (3) but with a coarser counterparty tag.

Due diligence rules

Both frameworks require self-certification at onboarding and refresh when circumstances change. The procedures for verifying the certification differ in detail.

CARF Section IV gives CASPs an electronic search route (databases, KYC providers, etc.) and a paper-based route. DAC8 mostly mirrors this but requires Member States to specify which providers count for the electronic route, which has produced uneven landscapes — Germany's BMF has published a list, France's DGFIP has not yet.

The operational consequence is that a pan-European CASP runs slightly different verification flows per country, even though it files one DAC8 report at the home-state level.

Reporting deadlines

FilingDeadlineApplies to
DAC8 CASP report to home Member StateSet by each Member State, within the window that allows the exchange belowEU-authorized CASPs serving EU users
DAC8 exchange between Member State authorities (and CARF partners)Within 9 months of year-end — by 30 September following the reporting yearTax authorities
CARF reportSet per adopting jurisdictionCASPs in adopting jurisdictions
CARF exchange between adopting jurisdictionsWithin 9 months of year-end (typically by 30 September)Tax authorities

The Directive fixes the authority-to-authority exchange deadline (30 September following the reporting year). It does not impose a single harmonized CASP filing date — each Member State sets its own within that window. A CASP with users in Germany (DAC8) and Singapore (CARF) reports to the German authority by the German national deadline and to Singapore by the IRAS deadline, both for fiscal year 2026, with the FY 2026 exchange completing by 30 September 2027.

Penalties

Penalties are set nationally under both frameworks. DAC8 requires Member States to impose sanctions that are "effective, proportionate and dissuasive" but doesn't prescribe amounts.

Because penalties are set in each Member State's transposition law, amounts and structures vary widely — from fixed administrative fines per failure to revenue-based or turnover-capped penalties, with operating-licence consequences for repeated failures in some jurisdictions. Do not assume a uniform figure: check the specific transposition statute in each Member State you serve, as published amounts continued to be finalized through 2026.

CARF penalties under national transpositions follow each adopting jurisdiction's existing financial-information reporting penalty regime. Confirm the applicable regime per jurisdiction rather than relying on a generic figure.

For a CASP, the bigger risk under DAC8 is the MiCA license itself. Serial non-compliance with DAC8 is a basis for licence revocation under the MiCA framework. That makes DAC8 a more pointed regulatory tool than CARF outside the EU.

Who has to file what — decision matrix

Your CASP situationDAC8 filingCARF filing
MiCA-authorized, only EU usersYes, home stateNo
MiCA-authorized, EU users + users in CARF countryYes, home stateYes, each CARF country if MCAA-CARF exchange not yet active
Non-EU, no MiCA passport, EU usersNo (no MiCA) — but the EU user obligation may shift to the user's home-state CASP via DAC8 referralsYes, your home CARF jurisdiction
Non-EU, CARF country, no EU usersNoYes, your home CARF jurisdiction
Switzerland, Swiss + EU usersNo (Switzerland not in EU)Yes, Switzerland (CARF adoption confirmed for 2026 fiscal year) — for EU users, the EU CASP that holds the platform license files DAC8

The boundary case is the platform that operates a non-EU entity for EU users without an EU subsidiary. Pre-DAC8, this was a common structure for non-EU exchanges serving EU retail. Post-MiCA, that structure no longer works for ongoing operations because the MiCA passport requirement traps EU service provision. The DAC8 question only arises for entities that have a passport.

The practical compliance burden in 2026

For a mid-size CASP (5–50 staff, single-jurisdiction filing), the operational lift is:

  1. Data model alignment — your transaction database needs to emit DAC8 / CARF reportable records. This is the largest one-time cost. Most teams underestimate it because the schema looks small (~30 fields per transaction) but the data sources are fragmented across on-chain wallets, exchange APIs, and bridge connectors.
  2. Due-diligence backlog — KYC files from 2021–2024 typically don't have the granular tax-residency self-certification the frameworks require. Backfilling is a customer-communications project as much as a compliance one.
  3. Reportable-user identification — distinguishing reportable from non-reportable users (e.g. excluded entity types, government bodies) requires logic that most KYC stacks don't run today.
  4. Output format generation — the EU specifies an XML schema for DAC8. Each CARF jurisdiction is publishing its own. Some are XML, some are JSON, some require their own portal upload.

The compliance vendors are responding differently:

  • Sumsub focuses on the KYC + due-diligence layer. It can ingest self-certifications, verify TINs against national registries (where APIs exist), and flag users that need re-certification. It does not generate the XML reports itself.
  • TaxBit generates reportable forms from transaction data and supports US-focused 1099 generation plus DAC8-shaped output for EU clients. It assumes you bring your own KYC.
  • Cryptio is a transaction-data and accounting platform — it sits below the reporting layer, normalizing on-chain and CEX data into a single ledger that a CASP can then feed into a reporting vendor. It does not generate DAC8 XML by itself.

The split between data layer, KYC layer, and reporting-output layer means most CASPs end up with two or three vendors rather than one.

How Wag3s helps

Wag3s Ledger normalizes on-chain and off-chain transaction data into a unified, audit-ready ledger. For CASPs in scope, it provides:

  • Multi-chain reconciliation across 20+ blockchains and exchange APIs, so the transaction data flowing into your DAC8 / CARF output is complete and accurate (see multi-chain reconciliation)
  • Per-user transaction aggregation with FIFO, LIFO, HIFO and PMP cost basis support — directly producible into the DAC8 / CARF data fields
  • Stablecoin tagging at the issuer + chain level, which DAC8 requires for the e-money token scope distinction
  • Counterparty categorization (consumer / professional / CASP) at the transaction level
  • Export pipelines aligned with the OECD CARF XML schema and the EU DAC8 schema

For comparison, Wag3s vs Cryptio and Wag3s vs TaxBit cover where each tool fits in a typical compliance stack.

What to do this quarter

If you're a CASP affected by DAC8 or CARF and you haven't started yet, the prioritized order in May 2026 is:

  1. Map your users by tax residency. You can't size the problem without knowing which jurisdictions are in scope for you.
  2. Run a gap analysis on your existing KYC data against the DAC8 / CARF self-certification requirements. If you don't have self-certification stored, you have a customer-communications project, not just an engineering one.
  3. Decide your data model. Build one structure that can emit both DAC8 and CARF outputs, rather than two separate pipelines.
  4. Pick the vendor mix. Most teams end up with one data-layer tool (Wag3s, Cryptio), one KYC layer (Sumsub or equivalent), and one reporting-output tool (TaxBit or in-house XML generation).
  5. Confirm transposition rules in each Member State or CARF jurisdiction you serve. The national details matter for penalties, deadlines, and electronic search providers.

The FY 2026 data must be exchanged between authorities by 30 September 2027, with national CASP filing deadlines falling earlier in that window. That sounds far. It isn't — the first complete reporting year is already underway.


Further reading

Sources

Editorial disclaimer
This article is informational and does not constitute legal or tax-compliance advice. National transposition of DAC8 and bilateral adoption of CARF are not uniform across jurisdictions; reportable categories, due diligence rules, and deadlines may vary in practice. Validate scope and reporting fields with qualified counsel in each jurisdiction where you operate before designing reporting infrastructure.