CARF / DAC8: mapping crypto transactions to the schema.

Who is a reporting service provider

The Crypto-Asset Reporting Framework attaches the obligation to a reporting crypto-asset service provider — broadly, an entity or individual that as a business effects exchange transactions in relevant crypto-assets for or on behalf of customers. Custody is not the test. The OECD has been explicit that non-custodial providers can fall inside the definition where they exercise sufficient control over the arrangement through which transactions are effected, which pulls in service models that assume they are outside a reporting perimeter.

Nexus rules then decide which jurisdiction a provider reports to, based on residence, incorporation, management, place of business or the jurisdiction from which transactions are effected. A provider with a presence in several jurisdictions resolves nexus first; everything else depends on it.

The transaction categories

Relevant transactions fall into three groups, and the schema keeps them separate throughout.

A single user action can produce entries in more than one category — a purchase funded from a deposit that arrived on-chain produces a transfer in and an exchange. Source systems that record one event per user action have to be decomposed before mapping.

From ledger rows to reported amounts

This is the step that breaks most implementations. Exchange systems store transactions; the schema stores aggregates. The reported unit is the combination of user, reporting period, crypto-asset type and transaction category, with an amount, a number of units and a number of transactions attached to each.

Building that aggregate reliably needs four things settled in advance:

• A stable asset identity. The same asset appears under different tickers, on different chains and in wrapped or bridged forms. Whether those are one reportable asset or several is a policy decision that must be applied consistently across periods, and documented.
• A user identity that survives account changes. Aggregation is per user, not per account, so merged accounts, sub-accounts and corporate hierarchies have to resolve to one reportable person.
• A period boundary that matches the ledger’s timezone. Transactions near midnight at period end move between periods if the ledger and the reporting calendar disagree.
• An unwind policy for reversals. Cancelled, reversed and internally corrected transactions have to be excluded consistently rather than netted arbitrarily.

Valuation and units

Crypto-to-crypto exchanges are reported at value, which means every leg needs a valuation at the time of the transaction rather than at period end. Three rules keep this defensible: use one valuation source per asset and record it; apply the same method to acquisitions and disposals; and retain the rate used against each aggregate so a figure can be reproduced later. Unit counts are reported alongside the values, so precision and rounding policy for fractional units matter as much as the fiat figure.

Transfers, and the awkward cases

Transfers are reported by direction and by type, and the framework treats retail payment transactions over a defined value as a distinct case. Two situations recur:

• Transfers to addresses not associated with a known provider. These are reported separately from provider-to-provider movements, so the provider needs a defensible classification of destination addresses.
• Internal movements. Movements between a user’s own accounts at the same provider are not the same event as a transfer out, and treating them alike inflates the reported population.

What DAC8 adds

Council Directive (EU) 2023/2226 implements the framework inside the Union and does three further things that matter operationally. It plugs crypto-asset reporting into the existing administrative cooperation machinery, so exchange runs through the same channels as other automatic exchange. It aligns the reporting perimeter with the Union’s own crypto-asset regime, so a provider authorised there is inside the reporting population by construction. And it carries the amendments to the Common Reporting Standard, which extend that standard to electronic money products and central bank digital currencies.

Schema mechanics

The XML schema follows the pattern used across automatic exchange. A message header identifies the transmitting and receiving jurisdictions with two-character country codes, carries a unique message reference beginning with the sending country code, states the message type — new information, corrections and deletions, or no data to report — and gives the reporting period end date. Each record then carries a document specification block whose type indicator marks it as new data, a correction, a deletion or a resent record, with the references of the record being changed where applicable.

The same discipline applies as elsewhere: message and document references must be unique and permanent, corrections point at the original record rather than replacing the file, and a no-data message is used where the receiving jurisdiction expects one.

REGREP is an independent software provider. This record explains a reporting framework in plain language and is not legal, tax or regulatory advice. Confirm scope, thresholds and submission dates with your competent authority before you file.