DAC8’s First Reporting Cycle: What Should Businesses Check Now for Their 2026 Data?

Key Takeaways

• DAC8’s crypto-asset reporting provisions apply from 1 January 2026, making 2026 the first reporting year.
• Existing KYC information can support the reasonableness assessment of a tax residence self-certification, but does not automatically replace it.
• Reviewing transaction coverage requires mapping assets, transaction types and data sources to reporting fields, with traceability back to the underlying records.
• Gaps in pre-existing users’documentation and gaps in 2026 transaction records should be recorded and remediated separately.
• Service providers’reporting deadlines are determined under Member States’rules. 30 September 2027 is the deadline for tax authorities to exchange information for the first reporting year.

Introduction

The crypto-asset reporting provisions of Council Directive (EU) 2023/2226, commonly known as DAC8, apply from 1 January 2026. For crypto-asset service providers within scope, 2026 is the first reporting year. Customer tax residence information and relevant transaction data must therefore be collected and retained on an ongoing basis in accordance with the applicable rules. Businesses that wait until the middle or end of the year to review their data may discover issues that cannot be resolved simply by exporting a transaction history.

Consider a trading platform operating across several EU markets. Its users can trade spot crypto-assets and exchange stablecoins, some assets are held in custody, and customer identification records are spread across regional KYC systems. The compliance team holds customers’tax residence information, the finance team can export transaction records, and the engineering team maintains wallet records. However, these datasets may use different customer identifiers, asset codes and transaction classifications. When preparing its reporting, the platform discovers that some users have not provided tax residence self-certifications, certain transfers cannot be linked to account records, and other transactions cannot be mapped directly to the required reporting fields.

Platforms need to assess in advance whether their customer information and transaction records can support DAC8 reporting. This article examines four areas: users’tax residence status, transaction coverage, data gaps and allocation of responsibilities. It also distinguishes the timelines for collecting 2026 data, reporting by service providers, and information exchange between tax authorities, helping exchanges assess their readiness.

1. Key Dates

DAC8’s first reporting cycle involves three activities that are easily confused: when businesses must begin collecting data, when they must report to the competent tax authority, and when tax authorities must exchange that information. Cross-border platforms that record only “30 September 2027” in their compliance calendars may overlook an earlier domestic reporting deadline.Key DatesBusinesses should work backwards from their actual reporting deadline.

Businesses should work backwards from their actual reporting deadline.

First, identify the applicable jurisdiction and reporting entity. Then set dates for the data freeze, reconciliation of discrepancies, file generation, internal approval and final submission. The EU-level timetable provides an overall framework, but does not replace Member States’ legislation or tax authority guidance.

2. Can Existing KYC Information Support Tax Due Diligence?

Assume the platform has already collected identity documents, residential addresses and company registration documents for most customers. These records support anti-money laundering and know-your-customer (AML/KYC) compliance. DAC8 also requires the platform to establish users’ jurisdictions of tax residence and obtain and validate the required tax residence self-certifications.

For individual users, businesses need to check names, residence addresses, jurisdictions of tax residence, taxpayer identification numbers (TINs) and dates of birth. Place of birth is reportable only where domestic law otherwise requires the provider to obtain and report it.

For entity users, the relevant information also includes the entity’s legal name, address, jurisdictions of tax residence, TINs and entity classification. Where an entity is neither an Active Entity nor an Excluded Person, its Controlling Persons must also be identified, and the provider must determine whether any of them are Reportable Persons. Self-certifications must be signed or otherwise positively affirmed by the user or relevant Controlling Person, as applicable, and dated. Systems must also be capable of retaining information on multiple jurisdictions of tax residence.

Existing KYC information can help establish whether a self-certification is reasonable, but generally cannot replace a tax residence self-certification. A self-certification obtained for other tax purposes may be reused if it meets DAC8’s validity requirements. For example, where a customer’s registered address differs from the jurisdiction of tax residence stated in the self-certification, the business needs to investigate the discrepancy. If the provider knows, or has reason to know, that the original self-certification is inaccurate or unreliable, it must obtain a valid new self-certification or a reasonable explanation supported by the necessary documentation.

For pre-existing individual and entity users whose business relationships were established as of 31 December 2025, DAC8 requires the relevant self-certifications to be obtained and their reasonableness confirmed by 1 January 2027. For new users whose relationships begin from 2026 onwards, self-certifications must be obtained and validated when the relationship is established. The transitional arrangements for pre-existing users do not apply to these new relationships. Operational procedures must also reflect the relevant Member State’s implementing rules.

For users with incomplete information, businesses should record the missing fields, follow-up status, reasons for exceptions and the person responsible for further action. This allows compliance teams to distinguish accounts awaiting documentation, accounts with unresolved tax residence status, and accounts requiring escalation.

Under DAC8, where a user has not provided the required information after the initial request and two subsequent reminders, the Reporting Crypto-Asset Service Provider must prevent the user from carrying out Reportable Transactions. This restriction must not be imposed before 60 days have elapsed following the initial request. Platforms should implement reminders, timing controls and transaction restrictions in accordance with Member States’ implementing rules, and retain the relevant records.

3. Do System Transaction Records Constitute Reportable Data?

Customer information and transaction data need to be reviewed separately. For a platform offering spot trading, stablecoin exchange and custody services, transaction records may originate from the matching engine, account system, wallet system, fiat payment modules and other product systems. Each system may use its own asset codes and transaction classifications. Without consistent mapping, some activities may be omitted from the reporting process, while others may be aggregated more than once.

Businesses need to determine which assets and transactions fall within DAC8’s definitions, then map their products, asset types, transaction types and data sources to the required reporting fields. Relevant activities include acquisitions and disposals of Reportable Crypto-Assets in exchange for Fiat Currency, crypto-to-crypto exchanges, and Reportable Retail Payment Transactions and other inbound and outbound Transfers that meet the applicable definitions.

The treatment of stablecoins, certain non-fungible tokens (NFTs) and tokenised assets depends on the specific definitions; product names alone are insufficient for classification. Central Bank Digital Currencies and Electronic Money meeting DAC8’s definitions are excluded from the scope of Reportable Crypto-Assets under Annex VI. Other applicable requirements, including financial account reporting rules, must still be assessed separately.

Businesses should aggregate the relevant amounts or fair market values, numbers of units and, where applicable, transaction counts separately by asset and transaction type. Where amounts are paid or received in multiple fiat currencies, they must be converted into a single reporting currency using the applicable transaction-time conversion methodology. Where fair market value is required, it must likewise be determined at the time of each Reportable Transaction and reported in a single currency, in accordance with the rules.

Crypto-to-crypto exchanges must reflect acquisitions and disposals separately; retaining only a net amount after offsetting is insufficient. The treatment of transaction fees within the reported amounts should be confirmed against the applicable rules and technical guidance, with the calculation basis retained.

The purpose of a transaction coverage review is to confirm that all applicable activities are included in the reporting process and that aggregated results can be traced back to their original records. If teams can export reports from several systems but cannot explain the differences between them, data linkage and reconciliation issues need to be resolved before reporting.

4. Which Issues Could Affect the 2026 Reporting Data?

Historical data gaps need to be distinguished by type. Incomplete documentation for pre-existing users generally affects due diligence and the identification of Reportable Users. Missing transaction records within the 2026 reporting period may directly affect transaction coverage, aggregated amounts or valuations. Both issues may arise in the same account, but they require different remediation measures.

For example, suppose a platform migrates its account system at the beginning of the year, changing user identifiers, while its wallet system continues to use the old identifiers. During reconciliation, the finance team discovers that some outbound transfers cannot be linked to current accounts. Obtaining the missing tax residence self-certifications will not resolve this transaction linkage problem. The team must also retain a mapping between old and new identifiers, compare record counts before and after migration, and confirm that the relevant transfers have been correctly included in the reporting data.

Businesses should maintain a central register of data gaps. At a minimum, it should record the issue type, affected scope, discovery date, cause, remediation method, responsible owner, target completion date and review status. Where records cannot be completed directly, retain the original data, an explanation of the discrepancy, the treatment adopted and the basis for approval. If a gap could affect the identification of Reportable Users or the reporting outcome, establish an escalation process and promptly assess whether corrections or other measures are required.

Transactions occurring before 2026 do not automatically fall within DAC8’s first reporting year merely because the customer is a pre-existing user. Businesses should separately determine the scope of transactions within the reporting period, when a user was identified as a Reportable User, and the applicable due diligence arrangements for pre-existing users. Relevant records must also be retained in accordance with Member States’ requirements.

5. Who Is Responsible for Resolving Identified Issues?

Assume that a cross-border platform’s compliance or customer operations team maintains customer identification information, its finance or data team processes transaction records, and its engineering team generates reporting files. Without clearly assigned ownership and review procedures, missing customer information identified by compliance may receive no follow-up. Finance may also be unable to determine whether business or engineering teams should resolve transaction discrepancies. The platform must additionally designate responsibility for final approval and submission.

Businesses can establish a responsibility matrix suited to their organisational structure, assigning owners for regulatory interpretation, customer information validation, transaction coverage reviews, field mapping, amount verification, final reporting and retention of submission acknowledgements.

The table below is an illustration of internal governance arrangements. Actual responsibilities should reflect the company’s structure and applicable law.

Conclusion

Preparing for DAC8’s first reporting cycle requires practical checks of customer information, transaction records and reporting processes. Exchanges should confirm whether tax residence information is sufficient to identify Reportable Users, whether all applicable transactions are included in the aggregated data, and whether identified gaps have assigned owners for remediation and review. Cross-border platforms must also verify the reporting deadlines and technical requirements in each applicable Member State.

A useful next step is for the reporting owner to coordinate a sample-based, end-to-end review linking customer tax residence self-certifications and original transaction records to reporting fields. Any gaps identified, their remediation owners and completion dates should be recorded in a single action list.

Frequently Asked Questions

• Is 30 September 2027 a common reporting deadline for all businesses?

No. It is the deadline for tax authorities to exchange information for the first reporting year. Businesses must report under the applicable Member State’s rules. For example, the Netherlands has announced a first reporting deadline of 31 January 2027, while Germany requires annual information to be submitted by 31 July of the following year.

• Do we still need tax residence self-certifications if KYC has already been completed?

Generally, a self-certification meeting DAC8’s requirements is still needed. Existing KYC information can support the reasonableness assessment. A self-certification obtained for other tax purposes may be reused if it meets DAC8’s validity requirements.

• Do the transitional arrangements for pre-existing users allow businesses to delay collecting 2026 transaction data?

The transitional deadline should not be treated as a basis for postponing the collection of 2026 transaction records. The relevant self-certifications for pre-existing users must be obtained and validated by 1 January 2027. Transaction records must still be retained on an ongoing basis in accordance with the rules applicable to the first reporting year.

• Can crypto-to-crypto exchanges be aggregated on a net basis only?

No. Retaining only a net amount after offsetting is insufficient. The applicable fair market values, numbers of units and transaction counts must be aggregated separately by Reportable Crypto-Asset and transaction type, including acquisitions and disposals.