DAC8 is no longer mainly a future reporting date. Since 1 January 2026, the important change for in-scope crypto providers is that tax transparency has become an operating data process: identify the user, establish tax residence, classify entities and controlling persons, classify transactions, preserve evidence and remediate missing or unreliable information.
The first exchanges come later. The data architecture has to work now.
Key takeaways
- 2026 is a control year, not a waiting year. DAC8 requires in-scope providers to collect reportable crypto-asset transaction information for EU-resident users from 1 January 2026.
- Existing KYC is useful but not sufficient by itself. Tax-residence self-certification, TINs, controlling-person logic, transaction aggregation and change-of-circumstances controls create a distinct tax-reporting workflow.
- Reporting still does not determine tax. DAC8 makes information exchangeable; residence, taxpayer type, activity and domestic tax law determine the substantive tax result.
What changed on 1 January 2026
The European Commission describes DAC8 as the extension of automatic tax-information exchange to crypto-assets. EU Member States had to transpose the Directive by the end of 2025 and apply it from 1 January 2026.
For Reporting Crypto-Asset Service Providers, or RCASPs, that date matters because it starts the first reporting year.
The simple public timeline—collect in 2026, report and exchange in 2027—is useful. But it hides the real implementation problem.
A report due next year can only be accurate if the provider’s onboarding, transaction systems and evidence controls work throughout this year.
RCASP is not just another name for CASP
MiCA and DAC8 overlap around crypto services, but they are different legal systems.
MiCA asks questions about market authorisation, regulated services, conduct, prudential requirements and product or issuer obligations.
DAC8 asks which operators have tax-information duties, which users are reportable, what due diligence must be performed and which transactions must be reported and exchanged.
A MiCA authorisation does not complete the DAC8 analysis. Conversely, a DAC8 reporting obligation does not by itself authorise a crypto service.
This distinction is central to building the compliance map:
licence → regulated business → operational readiness → bankability → tax position → information reporting are connected, but none is a substitute for the others.
Identity becomes tax identity
Ordinary customer onboarding already captures identity information. DAC8 adds a tax-information purpose.
The Directive’s reporting fields can include the user’s name, address, tax residence, TIN and date of birth. For entities, the provider may also need to identify reportable controlling persons and their tax-residence information.
That means the provider needs more than a document proving that a person exists.
It needs a defensible answer to a different question:
In which jurisdiction or jurisdictions is this user reportable for tax-information purposes?
A passport can help identify a person. It does not, by itself, answer tax residence.
Self-certification needs a lifecycle
Tax-residence self-certification is not a one-time checkbox if later facts make it unreliable.
DAC8 requires providers to confirm the reasonableness of self-certifications using information obtained in customer due diligence. For entity users, the provider must also deal with controlling persons where the rules require it.
If circumstances change so that an earlier self-certification becomes incorrect or unreliable, the provider cannot simply keep the old answer in the database. It needs a valid replacement or an appropriate explanation and supporting evidence under the Directive’s framework.
This turns a static onboarding form into a lifecycle control:
collect → validate → monitor change → remediate → evidence.
Entity users make the data model harder
An entity account cannot be reduced to the company name and registration number.
The RCASP may need to determine the entity’s tax residence, whether it falls within an excluded or active category and whether it has controlling persons who themselves are reportable persons.
AML/KYC information can support that analysis. The Directive allows relevant customer-due-diligence information to be used for identifying controlling persons under the specified conditions.
But the tax-reporting outcome remains a separate legal determination.
This is why a clean beneficial-ownership file and a clean tax-residence file increasingly need to coexist.
Transactions need a reporting taxonomy
The second operational problem is the transaction ledger.
The European Commission explains that DAC8 reporting is subdivided by reportable crypto-asset and includes quantitative information such as aggregate gross amounts for acquisitions or disposals against fiat or other reportable crypto-assets and aggregate fair market value for transfers.
That requires systems to distinguish transaction types consistently.
A provider needs to know, for example, whether an event is an acquisition, disposal, crypto-to-crypto exchange or transfer, which asset is involved, how units and value are captured and how annual aggregates are generated.
An AML transaction log may contain useful data without being designed to produce that taxonomy.
Valuation and reconciliation are where errors compound
A tax-reporting file becomes fragile when values do not reconcile across systems.
The provider may have order data, wallet data, custody records, fiat settlement records and accounting records. If different systems use different timestamps, asset identifiers or valuation conventions, the year-end report can contain internal contradictions even when every individual system appears reasonable.
The practical control is therefore not only data collection. It is data reconciliation.
The firm should be able to explain how a reportable transaction moves from execution to ledger to valuation to annual report.
Missing tax data can become an operational restriction
DAC8 contains a particularly important due-diligence mechanism.
Where a Crypto-Asset User fails to provide required information after two reminders following the initial request, and not before 60 days have elapsed, the RCASP must prevent the user from performing Reportable Transactions.
That rule should not be exaggerated into a universal claim that every missing field immediately freezes every account.
Its significance is more precise: tax-information due diligence can affect the user’s ability to continue reportable activity.
The provider therefore needs reminder logic, case management, escalation and evidence of what happened and when.
The strongest objection: providers already do KYC
Yes—and that gives them a useful foundation.
The mistake is to assume that a financial-crime onboarding file automatically answers every tax-reporting question.
AML/KYC is focused on identity, beneficial ownership, financial-crime risk, source of funds and transaction monitoring under its own legal framework. DAC8 adds tax residence, TINs, reportable-user logic, tax-specific entity/control analysis, transaction categorisation and annual reporting requirements.
The efficient approach is not to build two unrelated customer databases.
It is to reuse reliable data while preserving the separate legal logic, evidence and ownership of the DAC8 control.
Bankability remains separate
A provider’s DAC8 readiness may improve the quality of its records and demonstrate stronger governance to financial counterparties.
It does not guarantee banking.
Banks assess their own AML, sanctions, operational and risk-appetite questions. DAC8 is not a bank-onboarding licence, and a bank’s acceptance of the business does not prove its DAC8 compliance.
The two workstreams can share data without sharing the decision.
Reporting is visibility, not the tax bill
For the user, this is the most important distinction.
A reported disposal, exchange or transfer does not tell the tax authority everything needed to calculate tax. Acquisition basis, taxpayer residence, capacity, exemptions, losses and domestic classification rules may still matter.
But the information becomes easier to compare against tax returns and other records.
That changes the value of good records. A tax position that depends on facts should be supported by those facts before an information mismatch triggers the question.
What an RCASP needs operationally
A credible DAC8 programme should be able to answer seven questions:
- Which entities and services in the group are RCASPs under the applicable implementation?
- Which users are reportable and where are they tax resident?
- Which entity users require controlling-person analysis?
- Are self-certifications valid, reasonable and monitored for changes?
- Can every relevant transaction be mapped to the required reporting category and value?
- Do provider, wallet, settlement and accounting records reconcile?
- Can the firm evidence reminders, remediation, changes and the data used in the final report?
That is what it means for crypto tax transparency to become operational.
Sources
- European Commission — DAC8
- EUR-Lex — Council Directive (EU) 2023/2226
- OECD — Crypto-Asset Reporting Framework and amended CRS
Disclaimer
This article provides general tax-transparency and operational-compliance information. It is not legal, tax, regulatory, AML or accounting advice. DAC8 scope, domestic transposition, filing mechanics, deadlines and penalties must be checked in the relevant Member State and against the provider’s exact activities immediately before implementation or filing.
