Automating DAC8 Reporting

DAC8 reporting is not a form you fill in once a year. It is a recurring data pipeline that has to capture, normalize, and aggregate a full year of activity per reportable user, then emit a schema-valid report. Treating it as a year-end filing task is the most common and most expensive mistake. This article covers what to automate, where human judgement stays, and how to make the build-vs-buy call.

TL;DR

• DAC8 is a pipeline, not a filing. Data collection had to be live from 1 January 2026.
• Three layers: identity/tax-residency (Layer 1), transaction aggregation (Layer 2), output formatting (Layer 3).
• Automatable: Layer 2 and Layer 3 largely. Not fully automatable: Layer 1 verification and discrepancy-investigation judgement.
• Riskiest to get wrong: Layer 2 data integrity — well-formatted but incomplete reports.
• Build vs buy: buy the regulatory-commodity layers, own the part tied to your unique transaction data.

Why "automation" is the wrong frame on its own

The instinct is to ask "which tool generates the DAC8 XML?" That is the last 10% of the problem. The report-generation step is largely deterministic once the inputs are correct. The work — and the risk — is upstream: getting complete, correctly attributed, correctly aggregated data into the generator.

A pipeline that automates output but is fed incomplete transaction data produces a report that passes schema validation, files on time, and is wrong. That is a data-integrity failure, the highest-frequency DAC8 penalty exposure (see DAC8 penalties). Automation that accelerates a defective process just produces defects faster.

The three layers, and what automates

Layer 1 — Identity and tax residency

Collect and verify legal name, date of birth, address, jurisdiction(s) of tax residence, TIN per jurisdiction, and a verified self-certification (see DAC8 data collected).

• Automatable: capture flows, TIN format validation, re-certification reminders, registry lookups where APIs exist.
• Not fully automatable: resolving conflicting residency indicia, judging an ambiguous self-certification, handling refusals. These need a documented human decision.

Layer 1 is the hardest to fully automate because verification is a judgement, and a wrong reportable-user determination propagates into every subsequent layer.

Layer 2 — Transaction aggregation

Normalize all activity across chains and venues, attribute it per user, and produce the annual aggregates (acquired/disposed vs fiat and vs crypto, transfers).

• Automatable: ingestion, normalization, per-user per-asset aggregation, counterparty categorization rules.
• Not fully automatable: classification edge cases (NFT scope — see DAC8 and NFTs; EMT vs CBDC vs tokenized security — see DAC8 and the digital euro) and discrepancy investigation.

This is the layer most tied to your specific data, and the riskiest to get wrong.

Layer 3 — Output formatting

Emit the report in the required XML schema for exchange via the EU Common Communication Network. The EU schema aligns with the OECD's CARF/CRS XML schemas published to support cross-authority transmission.

• Automatable: almost entirely, once Layer 2 outputs are correct and the target schema is fixed.
• Not fully automatable: per-Member-State variations where national transposition adds fields (see DAC8 transposition by country).

Layer 3 is the cheapest to automate and the least risky — precisely because it is downstream of the layers that carry the judgement.

Build vs buy, per layer

The recurring anti-pattern is trying to buy a single end-to-end tool. The three layers need different specialists; one product rarely does all three well. The other anti-pattern is building everything in-house — Layers 1 and 3 are commodity regulatory plumbing where vendors are ahead and staying ahead.

The defensible architecture for most CASPs: a KYC/self-certification vendor (Layer 1), a transaction-data platform that owns your chain/venue normalization (Layer 2), and a reporting-output tool (Layer 3), with documented human checkpoints at the judgement points.

Where vendors fit

• Sumsub — Layer 1: self-certification capture, TIN verification, re-certification flags.
• TaxBit — Layer 3 (and parts of Layer 2 output): generating DAC8/CARF-shaped reports.
• Cryptio — Layer 2: normalizing fragmented on-chain and exchange data with retained lineage.

The mapping is almost one tool per layer, which is why DAC8 automation is a stack-design problem, not a tool-selection problem.

How Wag3s helps

Wag3s Ledger is the Layer 2 foundation — the part tied to your unique transaction data:

• Multi-chain normalization across 20+ chains and exchange APIs (see multi-chain reconciliation)
• Per-user, per-asset annual aggregation matching the DAC8 reportable categories
• Counterparty categorization and instrument-level tagging (EMT vs CBDC vs tokenized security)
• Retained per-transaction lineage so any aggregate is auditable and discrepancies are investigable
• Clean outputs that feed a Layer 3 reporting tool or in-house XML generation

See the Wag3s Ledger product page for module details.

Further reading

• DAC8 Compliance Guide 2026
• DAC8 Data Collected
• DAC8 Reporting Templates & XML Format
• DAC8 CASP Penalties
• DAC8 and NFTs
• DAC8 Transposition by Country
• Multi-Chain Reconciliation

Sources

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