DAC8 Data Collected

DAC8 reporting started 1 January 2026. The schema looks small on paper — roughly thirty fields — but the data sources are fragmented across on-chain wallets, exchange APIs, and KYC stacks that were never built to emit tax-residency-tagged aggregates. This article lists exactly what a CASP must collect and report, and the operational implications of each layer.

TL;DR

• Per reportable user: legal name, date of birth, primary address, TIN per jurisdiction of tax residence, all jurisdictions of tax residence, entity identifier where applicable, plus a verified self-certification.
• Per reportable crypto-asset, annual aggregate: gross acquired and gross disposed against fiat and against other crypto, transfer values, retail-payment amounts where applicable.
• Reporting is aggregate, not per-transaction line item — but the underlying per-transaction data must be retained.
• Pre-existing users are in scope: most CASPs run a self-certification back-fill on their existing book.
• Three data layers rarely live in one system: identity/KYC, tax-residency self-certification, and normalized transaction data.

The three data layers

DAC8 data sits in three places that, in most platforms, are three different systems.

Layer 1 — Identity and tax residency (per user)

For each reportable user, the CASP collects and verifies:

• Legal name
• Date of birth (individuals)
• Primary address
• Taxpayer identification number (TIN) for each jurisdiction of tax residence
• All jurisdictions of tax residence
• Entity identifier where the user is an entity
• A self-certification confirming the residency status, which the CASP must verify through due diligence

The hard part is not the field list — it is that legacy KYC records usually captured an address and an ID document, not a structured tax-residency self-certification with per-jurisdiction TINs. Back-filling the existing user book is the single largest one-time DAC8 cost for most platforms.

Layer 2 — Transaction aggregates (per user, per crypto-asset, per year)

Reporting is annual aggregate, not a feed of every trade. For each reportable user and each reportable crypto-asset, the CASP reports:

• Aggregate gross amount acquired in exchange for fiat
• Aggregate gross amount disposed in exchange for fiat
• Aggregate gross amount acquired and disposed in exchange for other crypto-assets
• Transfer values (number of units and fair-market value), including transfers to wallets the CASP cannot associate with a CASP
• Retail-payment transaction amounts where the CASP acts as a payment processor and the relevant conditions apply

The data is subdivided by transaction type and by counterparty category. The CASP does not transmit individual trades — but it must retain the per-transaction data underneath to compute the aggregates and to support audit.

Layer 3 — Retention and audit trail

Even though the report is aggregate, the CASP must keep the granular records:

• The per-transaction data that produced each aggregate
• The self-certification and the due-diligence evidence that verified it
• The reportable-status determination logic per user

An auditor or tax authority reviewing a DAC8 filing will sample an aggregate and ask the CASP to reconstruct it from the underlying transactions. Without a clean transaction ledger, that reconstruction is not possible at scale.

The operational implications

The recurring failure mode is treating DAC8 as a reporting-format problem. It is mostly a data-completeness and data-lineage problem. The format (the XML schema specified by the EU, plus national variants) is the last 10% of the work.

Where vendors fit

• Sumsub addresses Layer 1: capturing and verifying self-certifications, validating TINs against national registries where APIs exist, and flagging users needing re-certification.
• TaxBit addresses the Layer 2 output: generating the aggregate report in DAC8/CARF-shaped format from transaction data.
• Cryptio addresses Layer 2 input and Layer 3: normalizing fragmented on-chain and exchange data into a single ledger with retained lineage.

No single product spans all three layers cleanly, which is why DAC8 programs are usually multi-vendor.

How Wag3s helps

Wag3s Ledger covers Layer 2 and Layer 3:

• Multi-chain reconciliation that produces complete, normalized per-user transaction data (see multi-chain reconciliation)
• Per-user, per-asset annual aggregation matching the DAC8 reportable structure
• Counterparty categorization (consumer / professional / CASP) at the transaction level
• Retained per-transaction lineage to every reported aggregate, for audit reconstruction
• Stablecoin tagging at issuer + chain level for the EMT scope distinction (see DAC8 stablecoins)

See the Wag3s Ledger product page for module details.

Further reading

• DAC8 Compliance Guide 2026
• DAC8 vs CARF Difference
• DAC8 vs MiCA
• DAC8 CASP Penalties
• DAC8 and Stablecoins
• AML & KYC for Crypto Businesses
• Multi-Chain Reconciliation

Sources

• Council Directive (EU) 2023/2226 (DAC8) — EUR-Lex
• European Commission — DAC8 overview
• OECD Crypto-Asset Reporting Framework — model rules and commentary