DAC8 crypto-asset reporting

Determine the reporting provider, user and asset

Directive 2023/2226 inserts crypto-asset reporting into the Directive on Administrative Cooperation. Annex VI defines the reporting provider and due-diligence process. It includes relevant crypto-asset operators as well as MiCA service providers. A firm should not assume that lack of MiCA authorization removes tax-reporting duties.

Annex VI Section IV defines a reporting provider by reference to services effectuating exchange transactions for or on behalf of a reportable user. Its definitions also address staking and lending. Establish the entity's role and the jurisdictional conditions in Section I before deciding where it must report or register.

Asset scope needs a separate assessment. The Annex VI definition excludes central bank digital currency, qualifying electronic money and assets adequately determined to be unusable for payment or investment purposes from its reportable-crypto-asset category. DAC8 also amends other financial-account reporting rules. Therefore, an asset outside this particular category is not automatically outside every reporting regime.

Use three dates in the reporting calendar

The Commission's DAC8 explanation distinguishes the first reporting year from the subsequent filing and exchange. This distinction matters when setting engineering milestones.

Do not use 30 September 2027 as a universal provider filing deadline. Obtain the national portal instructions, schema version, registration route and correction procedure. Record those details in the release checklist for the actual reporting jurisdiction.

Annex VI Section III requires tax-residence self-certification and a reasonableness check, with provisions for pre-existing users by 1 January 2027 and changes in circumstances. An existing identity-verification result can inform the process, but it is not itself a tax-residence self-certification.

Map legal fields to reproducible data

Article 8ad and Annex VI Section II specify identifying information and transaction aggregates. The report is not simply a wallet balance or a dump of transaction hashes. The worksheet below is a DeFiSec data-design aid. Confirm the final field names and schema against the relevant authority's instructions.

Keep the method that produced each aggregate. A correction to a customer's residence or transaction classification should result in a traceable new output, with a reason for the change. A successful file upload establishes transmission, not the accuracy of every reported field.

Reuse identity infrastructure with a separate tax decision

Pharos Production's article on integrating CASP onboarding and identity records is useful when connecting customer evidence to operational systems. For DAC8, extend that workflow with the required tax self-certifications and reporting classifications. The Pharos article addresses onboarding and AML/Travel Rule engineering. It does not establish DAC8 deadlines or replace the directive.

Run a reconciliation before the first export: select a user's source activity, reproduce its classification and aggregate it independently. Check changed residency, corrected transactions, multiple asset identifiers and absent valuation inputs. This is a preparation technique, not an officially prescribed sample size.

A tax report does not determine the tax due from the customer, and it does not authorize the provider's services. Keep the Travel Rule transfer workflow and token classification analysis connected to the reporting system through explicit data definitions.