DAC8 Reporting Templates and the XML Schema

"What does the DAC8 report actually look like?" is the first thing most compliance teams want to know and the wrong thing to solve first. This spoke answers it anyway — the report is a schema-defined XML document aligned with the OECD's CARF/CRS schemas, exchanged over the EU Common Communication Network — and then explains why nailing the format is necessary but nowhere near sufficient. It is the format companion to the automation pillar, which covers the pipeline that produces the data this schema carries; the field list those blocks contain is in the data-collected reference. Here the focus is the structure of the submission and the schema-valid-but-wrong trap.

The format in short

• DAC8 data is exchanged as XML over the EU Common Communication Network.
• The EU schema aligns with the OECD CARF/CRS XML schemas, published with guidance in October 2024.
• It is schema-defined, not a fillable form: a reporting-entity block, a per-user identity/residency block, and a per-asset annual-aggregate block.
• National transposition can add or vary fields, so the practical template is the EU/OECD schema plus home-authority extensions.
• The schema is the easy part: schema-valid plus incomplete data still equals a well-formatted wrong filing.

The structure, conceptually

A DAC8 submission is an XML document. Without reproducing the formal schema, its logical blocks are:

This mirrors the OECD CARF data model by design — the EU built DAC8 as its implementation of CARF, so the schemas align to let authorities exchange consistently and to let globally active CASPs avoid two incompatible data models (see DAC8 vs CARF).

Why the schema is the easy part

Emitting schema-valid XML is a solved engineering problem once two conditions hold: the target schema is fixed, and the input data is complete and correctly classified. Both conditions are upstream of the formatting step.

The recurring failure: a team treats DAC8 as "generate the XML," automates that, and ships a file that validates against the schema, files on time, and is substantively wrong because the transaction data feeding it was incomplete or mis-aggregated. Schema validity is not data correctness. A validator checks shape, not truth. This is the highest-frequency DAC8 penalty exposure (see DAC8 penalties) and the reason the data-collected and automation work matters more than the template.

National variation

The EU/OECD-aligned schema is the baseline. Because DAC8 is a Directive transposed nationally, a Member State's transposition can add or vary fields, and the home-authority submission mechanics differ (portal upload, format particulars, deadlines within the exchange window). The practical "template" for a given CASP is therefore the EU/OECD schema plus its home Member State's specifics — not a single pan-EU form (see DAC8 transposition by country).

A submission pipeline hard-coded to one Member State's variant breaks when the CASP onboards users elsewhere. Build to the EU/OECD baseline, parameterize the national extensions.

What to check before building submission tooling

1. Confirm your home Member State's transposed schema/extensions and submission mechanics with the authority.
2. Build to the OECD CARF/CRS-aligned baseline, parameterize national variants.
3. Validate shape and reconcile substance — schema validation is necessary, not sufficient; reconcile aggregates to the underlying ledger.
4. Retain lineage so any element in the XML traces back to specific transactions for audit reconstruction.
5. Treat output as downstream of complete Layer 2 data — do not start at the template.

Implementation Timeline for CASP XML Submission Infrastructure

A CASP building its DAC8 submission pipeline should work backwards from the first authority exchange date, not forwards from the schema publication.

The Q3 2026 schema-confirmation checkpoint is critical because Member State-specific variations on the OECD/EU baseline are published through national authority channels, not the EUR-Lex publication that contains the Directive text. A CASP that waits for the submission deadline to discover its home authority uses a field extension or a different encoding convention for TINs is building under deadline pressure.

Reporting Obligations by Entity Type: XML-Level Implications

The XML schema's message structure encodes several entity-type distinctions that compliance teams must understand before building the generation logic.

Single-Entity vs Multi-Entity CASPs

A CASP filing a single legal entity submits one XML message per reporting period to its home Member State authority. A multi-entity group where several entities are independently authorized CASPs must file separately per authorized entity — the message header identifies the Reporting CASP, and each entity's users and their activity are scoped to that entity's authorization.

Intercompany transactions between entities within the same group are not automatically excluded from DAC8 scope. Where one group entity provides CASP services to another group entity (e.g., a treasury entity using the group's exchange), the activity may still be reportable depending on the service relationship. Group structures require explicit scoping decisions confirmed with counsel.

Reportable Crypto-Asset Scope Within the XML

Not every crypto-asset is reportable. The Directive defines "Reportable Crypto-Assets" as crypto-assets used for payment or investment purposes, excluding:

• Crypto-assets that cannot be converted to fiat or to other crypto-assets (utility tokens with no exchange pathway).
• Central bank digital currencies (CBDCs), which are excluded from the MiCA and DAC8 definitions.
• Specified non-fungible tokens (NFTs) that are unique and not fungible (though the "fungible in practice" analysis is technically required).

In the XML, each per-user per-asset record carries a field that identifies the reportable crypto-asset. The CASP's product taxonomy must therefore distinguish reportable from non-reportable assets, encoded at the transaction level before the aggregation step. A schema-valid XML file that includes non-reportable activity or excludes reportable activity is substantively wrong in ways that schema validation cannot detect.

The Transfer Element: Unhosted Wallets

Transfers to and from addresses the CASP cannot associate with another CASP — effectively unhosted wallet withdrawals and deposits — must be reported separately. These are a distinct element in the XML structure and require a different counterparty-category encoding than CASP-to-CASP transfers. Many platforms have a data gap here: their transaction systems record the on-chain address but do not systematically classify addresses as CASP-associated vs unhosted. Building that classification into the transaction pipeline is a prerequisite for correctly populating the transfer element.

Where vendors fit

• TaxBit — generates DAC8/CARF-shaped output aligned with the published schemas.
• Cryptio — supplies the normalized, lineage-retained data the output is built from.
• Sumsub — supplies the verified per-user identity/residency block.

The output tool is the cheapest, least differentiated part of the stack; its quality is bounded by the data fed to it.

Where Wag3s sits: the substance behind the schema

A schema validator checks shape, not truth, so the value is in getting the figures the XML carries right before formatting. Wag3s Ledger produces that substance:

• Per-user, per-asset annual aggregates structured to the DAC8 reportable categories
• Instrument-level tagging (EMT vs CBDC vs tokenized security) so the right activity lands in the right element
• Retained lineage so every reported figure is reconstructable for audit (see multi-chain reconciliation)
• Clean handoff to a Layer 3 reporting/output tool or in-house XML generation

Generating and submitting the validated XML to the home authority sits with your reporting-output tool and compliance team; Wag3s makes sure what they encode is complete and reconcilable rather than a well-formatted guess. See the Wag3s Ledger product page for module details.

Further reading

• DAC8 Compliance Guide 2026
• DAC8 Data Collected
• Automating DAC8 Reporting
• DAC8 vs CARF Difference
• DAC8 CASP Penalties
• DAC8 Transposition by Country

Sources

• Council Directive (EU) 2023/2226 (DAC8) — EUR-Lex
• OECD — CARF and amended CRS XML schemas and guidance (October 2024)
• European Commission — DAC8 overview