DAC8 and Stablecoins

Most DAC8 scope questions have a boring answer; this one does not. E-money-token stablecoins are in scope under DAC8 even though the OECD's CARF carves out specified e-money products. That single divergence is the whole subject of this spoke: why the EU pulled EMTs back in to match the MiCA perimeter, and what it means for a USDC or EURC rail that "outside tax-authority visibility" is no longer true. The full framework comparison lives in the DAC8 vs CARF hub; the CBDC mirror image of this question is in DAC8 and the digital euro.

The scope call in short

• EMT stablecoins are in DAC8 scope from 1 January 2026, a deliberate alignment with the MiCA-regulated perimeter.
• CARF carves out specified e-money products and CBDCs; DAC8 does not. This is a primary DAC8/CARF divergence.
• A CASP serving EU-tax-resident users reports regulated stablecoin activity under DAC8.
• Tokenized money-market funds (BUIDL, BENJI) are generally not in DAC8 scope. They are MiFID II financial instruments, reported under CRS/DAC2 instead.
• For a stablecoin treasury, the activity is reported via the CASP, so reconcile your books to what the CASP will report.

The scope divergence in one table

The two divergence points that matter for a stablecoin business: EMTs are DAC8-reportable even where CARF would exclude them, and tokenized funds are not DAC8 stablecoins (they are securities).

Why the EU did this

CARF, the OECD model, deliberately keeps its scope narrow: it excludes CBDCs and specified e-money products so the framework focuses on the crypto-asset core.

The EU made a different policy choice. MiCA explicitly regulates e-money tokens (Title IV) and asset-referenced tokens (Title III) — they are inside the EU's regulated perimeter. The EU view is that tax reporting should match that perimeter. So DAC8 brings EMTs and ARTs back into the reportable scope.

The consequence is structural, not incidental: a global CASP running a regulated stablecoin rail has to report that activity under DAC8 for its EU-resident users, even if the same instrument is carved out of CARF reporting in a non-EU jurisdiction it also serves. One instrument, two different reporting answers depending on the framework (see DAC8 vs CARF).

What it means operationally

For stablecoin issuers and CASPs

A CASP that lists or processes regulated stablecoins must treat that activity as reportable. The data pipeline has to tag stablecoin transactions at the issuer + chain level — because the EMT-scope determination depends on what the instrument actually is (a MiCA-regulated EMT vs something else), not just its ticker.

For payment processors

DAC8 includes a €50,000 reference point for certain retail-payment transactions where a CASP acts as a payment processor. CARF leaves that threshold to adopting jurisdictions. A stablecoin invoice-payment rail is exactly the use case this targets — confirm the threshold treatment in each Member State you serve (see DAC8 data collected).

For treasuries

If a treasury holds and moves regulated stablecoins through a CASP that serves it as an EU-tax-resident entity, those flows are inside the CASP's DAC8 report. The treasury is not the reporting entity, but its activity becomes visible to tax authorities. The practical action: reconcile the treasury's own books to what the CASP will report, so there is no divergence to explain later. For the stablecoin selection angle, see USDC vs USDT vs DAI for treasury.

The tokenized-fund boundary

A frequent confusion: if EMT stablecoins are in scope, are tokenized money-market funds (BUIDL, BENJI, OUSG) also in scope?

Generally no. Those are financial instruments under MiFID II, which MiCA carves out, and DAC8 scope follows the MiCA crypto-asset definition. Tokenized funds fall under existing securities-reporting frameworks (CRS/DAC2 at the account level) rather than DAC8. The line is: regulated stablecoins (EMTs) are DAC8; tokenized funds are securities reporting (see tokenized RWA for treasury).

Getting this boundary wrong in either direction is a data-integrity exposure — reporting a tokenized fund as a DAC8 crypto-asset, or failing to report an EMT because it was treated as "just cash."

Where Wag3s sits: tagging the EMT boundary

The EMT scope decision turns on what an instrument legally is, not its ticker, so it needs issuer-and-chain-level tagging. Wag3s Ledger handles that part:

• Per-issuer stablecoin tagging (USDC, USDT, EURC, DAI) at the contract and chain level
• Classification of regulated EMT/ART activity vs tokenized-security activity (the DAC8 vs CRS/DAC2 boundary)
• Multi-chain reconciliation so cross-chain stablecoin movement is captured as one economic flow (see multi-chain reconciliation)
• Treasury-side reconciliation against expected CASP-reported activity

The final legal classification of any given token, and the filing it feeds, remain with the CASP compliance team and qualified counsel; Wag3s gives them a defensible, tagged dataset to work from rather than a guess by denomination. See the Wag3s Ledger product page for module details.

Further reading

• DAC8 Compliance Guide 2026
• DAC8 vs CARF Difference — the framework comparison this divergence sits inside
• DAC8 vs MiCA
• DAC8 Data Collected
• MiCA ART vs EMT Stablecoins
• USDC vs USDT vs DAI for Treasury
• Tokenized RWA for Treasury

Worked example: USDC flows through an EU-based CASP

Consider a protocol that pays service providers in USDC. The USDC issuer has obtained MiCA EMT authorisation — meaning the tokens are a regulated e-money token within the EU. The protocol uses a CASP registered in Germany to distribute these payments.

Under DAC8, the German CASP must report the following for each EU-tax-resident recipient in its first annual return (covering FY 2026, exchanged to authorities by 30 September 2027):

• The recipient's identifying information (name, address, TIN, jurisdiction).
• The total proceeds received during the year in USDC.
• The number of units transferred and the fiat-equivalent value at the time of each transfer.

The protocol itself does not file with German tax authorities — the CASP files on its behalf. However, if the protocol has its own books, it must reconcile what it paid versus what the CASP will report. A discrepancy — for example, a USDC payment that settled across two calendar years — must be resolved before the CASP submits its return, because the reported data will be cross-referenced against the recipient's personal or corporate tax filings.

The key practical discipline for a stablecoin-paying protocol is therefore: maintain a record of every USDC disbursement at the CASP-transaction level, with the date, on-chain hash, recipient, and fiat equivalent. That record is the reconciliation anchor when the CASP report arrives.

Common errors in EMT scope assessment

Three classification mistakes appear repeatedly in practice:

Error 1: treating all stablecoins the same. DAC8 scope depends on the instrument's legal classification under MiCA, not its peg or ticker. A USDC issued by Circle Internet Financial Europe under MiCA Title IV is an EMT and in scope. A synthetic or algorithmic "stable" token that has not obtained MiCA authorisation is a plain crypto-asset — also in scope, but under a different part of DAC8, and with different reporting fields.

Error 2: assuming the CARF carve-out applies in the EU. A CASP operating in both the EU and, say, Switzerland may apply the OECD CARF model to its non-EU users. CARF typically carves out specified e-money products. However, that carve-out does not carry over to DAC8 for EU-resident users. The same instrument is reported under two different standards depending on where the user is resident. Systems that assume one treatment for all users will under-report EU-resident EMT activity.

Error 3: conflating issuer authorisation with instrument classification. An EMT is in DAC8 scope because of what it is — an MiCA-authorised e-money token — not solely because its issuer has a specific registration number. A CASP must know whether each stablecoin it lists has obtained or applied for MiCA EMT authorisation. This is an instrument-by-instrument determination, updated as MiCA authorisations are granted.

Sources

• Council Directive (EU) 2023/2226 (DAC8) — EUR-Lex
• Regulation (EU) 2023/1114 (MiCA) — EUR-Lex
• OECD Crypto-Asset Reporting Framework — model rules and commentary
• EBA — Asset-referenced and e-money tokens (MiCA)