DAC8 Data Collected

This is the field-by-field reference: exactly which data DAC8 obliges a CASP to collect and report, not how the pipeline that emits it is built (that is the automation pillar) or how the XML is shaped (the reporting-templates article). The schema looks small on paper, roughly thirty fields, but the sources are fragmented across on-chain wallets, exchange APIs, and KYC stacks that were never built to emit tax-residency-tagged aggregates. Below is each field and the operational implication that comes with it.

What a CASP must collect, in short

• 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 a 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.

Implementation Timeline and Entity Obligations

Understanding which entities must collect which data — and when — is the operational prerequisite before any technical build.

The DAC8 Reporting Timeline

The 31 January 2027 national filing deadline applies in several transposing Member States, but some jurisdictions set slightly different dates within the Directive's window — confirm with the home authority.

Reporting Obligations by Entity Type

DAC8 defines "Reporting Crypto-Asset Service Providers" (RCASPs). The scope turns on the Directive's definition of CASP (aligned with MiCA), and the obligation attaches to entities that provide covered services to users with tax residence in an EU Member State.

The most consequential distinction for compliance planning: the obligation follows the services provided, not just the token type. An entity that issues an EMT but also provides custody, exchange, or transfer services for that EMT is a CASP in respect of those services and must report the relevant activity.

Pre-existing User Back-fill in Practice

For most platforms, the back-fill exercise — obtaining valid DAC8-compliant self-certifications from users onboarded before the Directive's requirements existed — is the single largest one-time project. The operational components are:

1. Identify the gap: compare existing KYC records against the DAC8 self-certification requirements (per-jurisdiction TIN, structured tax-residency declaration). Most pre-2024 KYC records will be missing the structured self-certification.
2. Segment users: active users with recent transactions should be prioritized; dormant accounts may require a different process.
3. Communication design: the back-fill requires a customer-facing process, not just a backend change — users must affirmatively provide the self-certification. The communication must explain what is required and the consequences of non-provision.
4. Escalation for non-responders: the Directive's escalation and, depending on national transposition, transaction-restriction provisions apply where a valid self-certification cannot be obtained. Confirm the applicable national rule.
5. Record retention: the self-certification and the due-diligence evidence that supported it must be retained, with documented timestamp and validation logic.

Where Wag3s sits: the transaction and retention fields

Of the three data layers above, Wag3s covers the two that turn on transaction data — the per-asset aggregates and the retained lineage underneath them, not the identity/KYC capture. Wag3s Ledger provides:

• 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 and chain level for the EMT scope distinction (see DAC8 stablecoins)

It produces the data a CASP reports; it does not capture the tax-residency self-certifications or make the reportable-user calls, which stay with the compliance team and its KYC stack. 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