Nexus under CARF: which jurisdictions a CASP must report to
CARF nexus follows your establishment, not your users. Here's the residence-to-branch hierarchy, why you report in one jurisdiction, and how it plays out.
Almost every CASP reading CARF for the first time believes the same wrong thing: that you report to each country your users live in. You don't. What settles the question is where your business is established, and your customers' locations don't enter into it. In almost every case that means one jurisdiction. Get it wrong and a team starts bracing for 30 filings when the real answer is one, so it pays to go through this slowly.
Nexus is about you, not your users
CARF borrows this idea from the Common Reporting Standard it's modelled on. It defines when a Reporting Crypto-Asset Service Provider has "nexus" with a jurisdiction. Nexus is what obliges you to report there, and you test it against your own establishment, in a set order:
- You are resident for tax purposes in the jurisdiction; failing that,
- you are incorporated or organised under its laws; failing that,
- your place of effective management sits there, meaning where your senior people actually run the business, your board and key decision-makers; failing that,
- you have a regular place of business there, such as a branch or office.
Work down the list and stop at the first one that applies. Notice what's missing: where your users live. A German-resident exchange reports in Germany. An exchange incorporated and managed in Ireland reports in Ireland. Your office, your management team, a branch, those are the things that pull you into a jurisdiction. The customer map doesn't.
You report once, and only once
Because the tests run in order, a provider that touches several jurisdictions still lands in one reporting jurisdiction, the highest one it hits. Then CARF layers on tie-breaker rules. A provider with nexus in more than one place doesn't file the same data twice: if you're already reporting the information in a jurisdiction with an equivalent framework, you're relieved from reporting it again elsewhere. Everything about the design points toward a single filing.
That single filing is where your users' residence finally counts for something. You report your reportable users to your own authority, and the OECD Common Transmission System exchanges each user's data onward to the jurisdiction where that user lives. So residence decides two things: who's reportable, and who ends up receiving the data. Where you file isn't one of them. We cover who counts as reportable in the self-certification and TIN validation workflow.
The offshore case: register in one place
Every non-EU exchange asks the same question: what happens when you've got no establishment inside a regime but plenty of users there? DAC8 answers it head-on. A crypto-asset service provider that isn't resident, incorporated, managed or branched in the EU, yet has EU-resident users, registers in a single member state of its choosing and reports there for all of them. Pick a member state, file once, and it shares the data with the rest. The wider OECD network handles its participating jurisdictions the same way.
How it looks in practice
A handful of worked examples make the pattern obvious.
- A US-headquartered exchange that reaches European users through an Irish subsidiary, the way Coinbase runs Coinbase Europe, has its EU nexus in Ireland. The Irish entity is the reporting CASP. It files once, in Ireland, and Ireland passes the data onward to every member state where those users live.
- An offshore exchange with no EU establishment but a big European user base, an OKX or a Bybit, say, doesn't file in 27 countries. Under DAC8 it registers in one member state and reports there.
- An exchange that's tax-resident in Germany reports in Germany, whether its users sit in France, Spain or Sweden.
Every time, the count of filing jurisdictions comes out to one. The entity decides it. The user base doesn't.
Resolving it without guesswork
Two jobs, really: pin down your own nexus jurisdiction correctly, and then, inside that one filing, work out which users are reportable and which jurisdictions their data has to reach. Our CARF and DAC8 reporting platform handles the second job. It determines reportability from validated residence data and routes each user to the right destination, so one submission reaches every jurisdiction that should get it. When a user won't certify their residence, the 60-day rule decides what happens next, and the deadlines by jurisdiction tell you when each filing is due. The OECD exchange-of-information hub and the EU tax cooperation pages are the primary sources.
