DAC8 and the Digital Euro: Why CBDCs Are Outside Crypto Tax Reporting

Regulation·

DAC8 and the Digital Euro: Why CBDCs Are Outside Crypto Tax Reporting

The digital euro is a central bank digital currency, and CBDCs are excluded from DAC8's reportable crypto-asset scope — unlike regulated e-money-token stablecoins, which are in scope. The distinction that matters for treasuries and payment flows in 2026.
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 Council Directive (EU) 2023/2226, OECD CARF model rules, and Regulation (EU) 2023/1114 (MiCA) · Last reviewed May 2026

DAC8 and the Digital Euro

If a regulated euro stablecoin is reportable under DAC8, surely a digital euro is too? No — and that mismatch is the cleanest illustration of how DAC8 scope actually works. A central bank digital currency is excluded; a MiCA-regulated e-money-token stablecoin is included. Same currency unit, opposite reporting answer, because the legal nature of the instrument decides scope, not its denomination. This spoke is the CBDC mirror image of the stablecoins article: why central-bank money falls out of scope while a private EMT falls in, and why that puts a tagging discipline on any treasury moving both. The full framework comparison stays in the DAC8 vs CARF hub.

The CBDC scope line in short

  • The digital euro is a CBDC. CBDCs are excluded from DAC8's reportable crypto-asset scope, the same exclusion CARF makes.
  • Regulated EMT stablecoins are included in DAC8, a deliberate alignment with the MiCA-regulated perimeter.
  • Same denomination, opposite answer: a euro CBDC is out; a MiCA euro stablecoin is in.
  • A CBDC is not a privacy regime: it has its own central-bank oversight and AML rules, but DAC8 is simply not the instrument that captures it.
  • Treasury takeaway: tag instruments by legal nature at the issuer level, or the DAC8 report is wrong.

CBDC vs regulated stablecoin: the scope line

DAC8's reportable scope follows the MiCA crypto-asset definition and deliberately includes regulated e-money tokens. It excludes central bank digital currencies. The digital euro, as a CBDC issued by the central bank, sits on the excluded side.

InstrumentLegal natureDAC8 scope
Digital euroCentral bank digital currency (CBDC)Excluded
MiCA EMT euro stablecoin (e.g. a regulated EURC-type token)Private e-money token, MiCA-regulatedIncluded
MiCA EMT USD stablecoinPrivate e-money token, MiCA-regulatedIncluded
Plain crypto (BTC, ETH)Crypto-assetIncluded

The line is not the currency. It is whether the instrument is central-bank money (CBDC, excluded) or a MiCA-regulated private token (EMT, included). This is the same distinction CARF draws for CBDCs, with DAC8 additionally pulling regulated EMTs into scope (see DAC8 and stablecoins and DAC8 vs CARF).

Why the EU designed it this way

Two different rationales for two different instruments:

  • CBDC: central-bank money. Its issuance, oversight, and AML framework are set by the central bank and EU law directly. The crypto-asset tax-reporting rationale — bringing privately issued, hard-to-trace instruments into automatic exchange — does not apply to central-bank money in the same way.
  • Regulated EMT stablecoin: a private instrument inside the MiCA-regulated perimeter. The EU's policy choice was to make DAC8's reportable scope match the MiCA perimeter, so regulated private stablecoins are reportable.

The design is coherent once you see it as "match the MiCA-regulated private perimeter, exclude central-bank money," rather than "report anything euro-denominated."

CBDC is not a privacy regime

A frequent misreading: "the digital euro is outside DAC8, so it's the private option." That confuses outside one specific tax-reporting instrument with unmonitored. A CBDC carries its own oversight and AML framework defined by the central bank and EU law. DAC8 simply is not the mechanism that captures CBDC activity — a different regime does.

For a treasury, the correct mental model is: choosing a CBDC for a flow changes which oversight regime applies, not whether one applies.

The practical risk for a treasury or payment operation that moves value across CBDC, regulated stablecoins, and plain crypto is mis-tagging:

  • Tagging a digital-euro flow as a reportable EMT stablecoin → over-reporting, data-integrity error.
  • Tagging a MiCA EMT stablecoin as "just euro / out of scope" → under-reporting, data-integrity error (and the more dangerous direction — see DAC8 penalties).

The control is instrument identification at the issuer and legal-nature level, not by ticker or denomination. A pipeline that treats "anything pegged to EUR" as one bucket will produce a defective DAC8 report. The bucket has to split: CBDC (excluded) vs MiCA EMT (included) vs other.

Practical example: a treasury moving value in three instrument types

Consider a Web3 treasury that in a single month:

  • Receives a USDC payment from a client (MiCA EMT stablecoin → reportable under DAC8).
  • Converts part of its ETH holdings to a regulated EURC-type token (MiCA EMT stablecoin → reportable).
  • In a hypothetical future scenario, receives a digital euro payment from an EU counterparty (CBDC → not reportable under DAC8).
  • Makes an ETH payout to a grant recipient (plain crypto → reportable).

Each instrument in this flow requires a different DAC8 treatment. The treasury's accounting system must be able to assign the correct reporting flag to each instrument at the point of receipt, not retrospectively. A system that defaults all EUR-denominated tokens to "excluded" will mis-report the EURC and USDC flows; a system that defaults everything to "reportable" will over-report the CBDC flow. Neither is compliant.

What to do about it

  1. Classify every euro-denominated instrument you touch by legal nature: CBDC, MiCA EMT stablecoin, other.
  2. Map the DAC8 consequence per class (CBDC out, EMT in).
  3. Encode the classification in the data pipeline at the issuer level, not the ticker level.
  4. Document the classification basis so an excluded CBDC flow is auditable as correctly excluded.
  5. Reconcile the resulting DAC8 figures against expectations (see DAC8 data collected).

Where vendors fit

  • Cryptio normalizes transaction data and supports instrument-level tagging that the CBDC/EMT split requires.
  • TaxBit produces the reporting output once classification is correct.
  • Sumsub handles the user-side due diligence beneath the reporting.

The classification logic (legal nature, not denomination) is the part that must be owned and documented.

The whole control here is identifying an instrument by what it legally is, not by its EUR peg, and doing it at the point of receipt. Wag3s Ledger tags at that level:

  • Per-issuer, per-instrument identification (CBDC vs MiCA EMT vs other), not by ticker
  • A DAC8 scope flag derived from legal nature, not denomination
  • Retained classification basis for audit (see multi-chain reconciliation)

The legal characterization of a borderline instrument remains a call for qualified counsel; Wag3s encodes and audits that call in the data pipeline so a CBDC flow is provably excluded and an EMT flow is provably in. See the Wag3s Ledger product page for module details.


Further reading

Sources

Editorial disclaimer
This article is informational and does not constitute legal or tax-compliance advice. The scope treatment of CBDCs vs regulated stablecoins under DAC8 depends on the Directive and national transposition; confirm with qualified counsel.