A Guide to DAC8 Readiness for Crypto Firms

DAC8 is not simply another reporting deadline for crypto businesses. It changes the quality, ownership and retrievability of customer and transaction data that EU-facing crypto-asset service providers must maintain. This guide to DAC8 readiness is designed for founders and compliance leaders who need to turn a broad tax transparency obligation into an operational plan before reporting begins.

The Directive on Administrative Cooperation 8 applies across the EU from 1 January 2026. The first reports are expected in January 2027 for the 2026 reporting period. Businesses that wait until late 2026 will face a familiar regulatory problem: incomplete onboarding records, fragmented data across vendors, and no credible method for reconciling reportable activity.

What DAC8 means for crypto businesses

DAC8 expands EU tax authorities' ability to obtain and exchange information on crypto-asset transactions. It implements much of the OECD Crypto-Asset Reporting Framework and targets the opacity that has historically surrounded cross-border crypto activity.

The core obligation falls on reporting crypto-asset service providers. In practice, this can include exchanges, brokers, trading platforms and other businesses that facilitate exchange transactions or transfers for users. Legal labels are not decisive on their own. A company should assess what it actually does, where it serves users, how it controls the service and whether it is established or otherwise has a reporting connection in an EU Member State.

For many firms, the difficult question is not whether DAC8 exists. It is whether their current operating model can identify every reportable user and transaction without relying on manual workarounds. A business may have strong AML controls but still be unprepared if its tax residence data is unverified, transaction classifications are inconsistent, or historical records cannot be linked reliably to a single customer profile.

DAC8 should therefore be treated as a product, data governance and compliance project, not a form to complete at year end.

A guide to DAC8 readiness: start with scope

The first practical step is a documented scope assessment. This should map the group structure, legal entities, licences, customer locations, services, token flows and third-party providers. It should also identify the Member State or states in which reporting may be required.

Do not assume that a non-EU incorporation removes the issue. An offshore group serving EU users through an EU establishment, branch, operator or other relevant nexus may still fall within the rules. Equally, a group with several EU entities must determine which entity has the reporting responsibility and how data will be shared lawfully within the group.

The assessment should distinguish between services that facilitate reportable crypto-asset transactions and activities that sit outside the reporting perimeter. This can be fact-specific. A self-hosted wallet software provider with no control over transactions presents a different profile from a platform that intermediates transfers, manages execution or controls customer access. The answer depends on the operating model, contractual arrangements and actual technical control, not marketing language.

A written position is valuable even where the conclusion is that a business is outside scope. It gives management, investors, banking partners and regulators a reasoned basis for that position and creates a trigger for reassessment when the business model changes.

Build the data set before the reporting year closes

DAC8 reporting will require more than wallet addresses and trade histories. Firms will need reliable customer due diligence information, including identity details, address, tax residence, tax identification number where issued, and date and place of birth for individuals. Entity users require equivalent identification and tax residence information, alongside appropriate treatment of controlling persons where relevant.

The transaction record must then connect the user to reportable activity. Depending on the transaction type, required information may include the type of crypto-asset, gross consideration, number of units, fair market value, transfers and relevant fees or charges. The exact reporting fields and local implementation requirements should be confirmed for each reporting jurisdiction.

This exposes a common weakness in fast-growing platforms: compliance, finance, product and operations often maintain different versions of the same customer and transaction record. A CRM may hold a residential address, the KYC provider may hold a different address, and the trading database may rely on a legacy customer identifier. None of those gaps is harmless when an authority expects a complete, internally consistent report.

A useful readiness exercise is to select a sample of active users and reconstruct their reportable profile from source systems. If the team cannot establish tax residence, verify the identifier, classify transactions and produce an auditable calculation promptly, the reporting process is not ready.

Update onboarding and remediation workflows

New customer onboarding must collect DAC8-relevant information in a clear and usable format. That includes a tax residence self-certification, the appropriate tax identification number, and a declaration process that allows the customer to confirm changes. The information should be validated using a risk-based approach and reconciled with existing KYC evidence.

Existing users are the larger operational challenge. Legacy accounts may have been onboarded before tax residence information was required, or the details may be incomplete, expired or held only in unstructured documents. A remediation campaign should be planned early, with escalation rules for customers who do not respond or provide contradictory information.

The customer journey matters. Requests that are poorly explained can create unnecessary support volume and account abandonment. However, clarity must not become optionality. Where information is required to meet a legal reporting obligation, the terms, notices and account restrictions need to support a defensible enforcement process.

Privacy and tax transparency must also be aligned. DAC8 does not remove data protection obligations. Firms should review privacy notices, retention periods, processor arrangements, cross-border data transfers and access controls so that collection and reporting are lawful, proportionate and documented.

Make reporting an owned control, not an outsourced blind spot

Many firms will use KYC vendors, blockchain analytics providers, custodians, payment providers and tax reporting software. These providers can reduce operational burden, but they do not transfer regulatory accountability. The reporting entity remains responsible for the completeness and accuracy of its submission.

Assign a senior owner for DAC8, supported by a working group across legal, compliance, tax, engineering, finance and customer operations. The owner should have authority to resolve data ownership disputes and prioritise necessary product changes. Without that mandate, reporting preparation often becomes a series of tickets that no team considers urgent.

Your operating model should answer four questions:

• Which system is the authoritative source for each reportable field?

• How are transaction values calculated, converted and reconciled?

• Who reviews exceptions, corrections and customer disputes?

• How will the business evidence the submission and retain supporting records?

Testing should begin before the first reporting deadline. Run a dry report using real, anonymised or controlled data. Reconcile totals against trading and custody records, identify missing fields, inspect unusual transaction patterns and test the approval workflow. This is where firms discover whether a fee has been double-counted, an internal transfer has been misclassified, or a dormant account has no valid tax residence record.

Coordinate DAC8 with MiCA and AML controls

DAC8 readiness should not be built in isolation. MiCA authorisation, AML compliance, sanctions controls, Travel Rule processes and data protection requirements all touch the same customer and transaction architecture. Separate projects can create duplicate data requests, conflicting retention rules and expensive rework.

The commercial benefit of coordination is significant. A well-designed onboarding framework can support AML risk assessment, Travel Rule data capture and DAC8 self-certification without asking customers to repeat the same information in different forms. Likewise, a clear group governance model can support both MiCA operational substance and tax reporting accountability.

There are trade-offs. A highly automated process can improve scale but may mishandle edge cases, such as customers with multiple tax residences, corporate accounts with changing control, or assets that require bespoke valuation logic. A manual review layer adds cost, yet it is often necessary for higher-risk customers and exceptions. The right balance depends on transaction volumes, user profile, jurisdictions and the maturity of your internal systems.

The cost of treating DAC8 as a late-stage task

Late preparation creates avoidable exposure. An incomplete or inaccurate report can lead to penalties under national implementation rules, regulator scrutiny and costly remediation. It can also damage banking and institutional relationships, particularly where a firm is already undergoing MiCA licensing or due diligence from a payment partner.

More immediately, a rushed programme tends to impose the highest cost on product and operations teams. They must retrofit mandatory fields, contact thousands of users, correct historical data and explain account restrictions under deadline pressure. Early work is usually less expensive because it can be incorporated into planned releases and ordinary customer lifecycle communications.

The most useful next step is to commission a focused DAC8 gap assessment covering scope, data, customer remediation, governance and reporting capability. For businesses operating across jurisdictions or preparing for MiCA, NUR Legal can align that assessment with the wider compliance build so that tax transparency does not become the issue that delays a regulated launch.