CARF / DAC8: mapping crypto transactions
Once you are in scope, how the filing is actually built.
Read the guide →The definition turns on effecting exchange transactions for or on behalf of customers. Not on holding assets, not on holding a licence, and not on where the software runs.
A reporting crypto-asset service provider is, in substance, any individual or entity that as a business effects exchange transactions in relevant crypto-assets for or on behalf of customers. Three elements do the work: as a business, effects, and for or on behalf of customers.
None of them refers to holding assets, to being licensed, or to operating an order book. A business that stands between a customer and an exchange transaction, in a way that makes the transaction happen, is inside the definition even where the assets never touch its balance sheet.
Custody is the mental model most firms bring, because it is how the financial account standard works — an institution holds something for someone. The crypto framework was drafted knowing that much of the market does not hold anything. Building the perimeter on custody would have exempted a large share of the activity the framework exists to observe.
The framework’s interpretative material has addressed non-custodial providers directly: they can be reporting providers where they exercise sufficient control over the arrangement through which transactions are effected. Control is assessed on the substance of the arrangement rather than on how it is described.
Indicators that weigh towards being inside the perimeter include the ability to influence or set the terms on which transactions occur, the ability to charge for them, the ability to prevent or restrict access, and the maintenance of a customer relationship. A model where none of these is present is a stronger case for being outside — but the assessment has to be made and documented, because the boundary is being interpreted actively and the answer can change without the business changing.
Once a provider is inside the perimeter, nexus decides where it reports. The connecting factors run in a sequence: tax residence; then incorporation or legal personality; then place of management; then regular place of business; and then the jurisdiction from which transactions are effected.
| Situation | Effect |
|---|---|
| One entity, one jurisdiction | Reports there. The straightforward case, and the least common at scale. |
| Group with entities in several jurisdictions | Each entity resolves nexus separately; the group can hold several reporting obligations covering overlapping customers. |
| No residence or incorporation anywhere relevant | The later factors bite, and a provider can be in scope in a jurisdiction where it has no legal presence. |
| Reporting already made elsewhere | Relief can apply where the same information is reported under an equivalent regime, but it is checked per jurisdiction and per customer population. |
Council Directive (EU) 2023/2226 implements the framework inside the Union and aligns its perimeter with the Union’s own crypto-asset regime, so a provider authorised under that regime is inside the reporting population by construction. That removes the perimeter question for authorised providers and leaves it live for everyone else operating into the Union without authorisation.
Primary instruments only. Each is named in full so the reference remains traceable even if a link moves.
Not on that ground alone. The test is whether the business effects exchange transactions in relevant crypto-assets for or on behalf of customers. Non-custodial providers can be reporting providers where they exercise sufficient control over the arrangement through which transactions are effected.
It depends on what the software does and what the business retains. Where the provider can influence the terms on which transactions occur, charge for them, restrict access, or maintains a customer relationship, the case for being outside weakens considerably. Document the assessment against the definition rather than against the business model label.
Yes. The connecting factors run past residence and incorporation to place of management, regular place of business, and the jurisdiction from which transactions are effected. A provider with no legal presence can still resolve nexus somewhere.
Relief can apply where the same information is reported under an equivalent regime and reaches the jurisdiction that would otherwise receive it. It is assessed per jurisdiction and per customer population, so expect a residual group the relief does not cover.
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.
More on this framework, and the module that produces the filing.
Once you are in scope, how the filing is actually built.
Read the guide →The framework page: population, obligations and destination.
Read the requirements →Aggregate, validate and export the exchange file.
See the module →Where you are in scope in several jurisdictions, one aggregation pipeline produces every file. Start with a free test report.