CARF in the UAE: What Licensed VASPs Must Have in Place by 1 January 2027

Key Takeaways

• CARF data collection in the UAE starts 1 January 2027, with first exchanges between tax authorities in 2028.
• Any business effecting crypto exchange transactions for customers can be a Reporting Crypto-Asset Service Provider.
• A VARA or CMA licence does not decide where an entity reports. The nexus rules do.
• Every user needs a self-certification of tax residence and TIN, which standard VARA KYC does not capture.
• Retail payments above USD 50,000 and transfers to unhosted wallets are reportable, not only trades.
• Crypto derivatives fall under CARF, CRS 2.0 or both, depending on how they are structured and settled.

CARF in the UAE at a glance

CARF takes effect in the UAE from 1 January 2027, alongside the amended Common Reporting Standard (CRS 2.0), with the first automatic exchanges of 2027 data in 2028. It is a tax information reporting regime, not a new tax: UAE residents still pay no personal income tax on crypto gains, but data on users who are tax resident in other CARF jurisdictions will reach their home tax authorities from 2028.

The framework is administered by the UAE Ministry of Finance (MoF) and applies across the market, whatever the licensing regime. A VARA licensee in Dubai, a CMA-licensed VASP onshore, and FSRA or DFSA firms in ADGM and DIFC all face the same analysis.

The direction is settled. The domestic implementing rules will fix the operational detail: registration, filing dates and penalties. Build your plan on the OECD model now and adjust when the final UAE text lands, because the data you collect from January is the data you report.

Identifying which group entities report

An entity reports under CARF if it is a Reporting Crypto-Asset Service Provider (RCASP) and has a nexus with the UAE. Both tests apply entity by entity, not group by group, so a single licence on the wall answers neither.

The RCASP test. An RCASP is any individual or entity that, as a business, provides a service effecting exchange transactions in relevant crypto-assets for or on behalf of customers. Making a trading platform available counts. In practice this captures:

• Centralized exchanges and multilateral trading platforms
• Brokers and dealers, whether acting as agent or principal
• OTC desks and market makers dealing with clients
• Custodians and wallet providers that execute exchanges for users
• Crypto ATM operators and some decentralized platforms where someone has a control or sufficient influence

The test turns on activity, not licence category. A VARA licence broker-dealer, a CMA Category 2 VASP and an ADGM-authorized custodian can all be RCASPs. A pure advisory or technology entity in the same group may not be.

The nexus test. CARF uses a ranked set of connecting factors to decide which country an RCASP reports to. Under the OECD model, the factors are listed from strongest to weakest. An RCASP linked to more than one jurisdiction reports where its link is strongest, provided that jurisdiction has implemented CARF and the RCASP completes its reporting there:

1. Tax residence
2. Incorporation or organization under local law, with legal personality or a local tax filing obligation
3. Place of management
4. Regular place of business

A separate rule covers branches. This ranking matters for groups with a UAE operating company, an offshore holding company and a global matching engine. Where UAE user orders route to an order book run by a foreign affiliate, the question of which entity effects the exchange decides which entity reports, and to which tax authority.

The output of this step should be a written entity obligations matrix: each group entity, its activities, its RCASP status, its nexus jurisdiction and the reasoning. Every later step depends on it.

Groups with users in the EU should also check DAC8, the EU version of CARF, which applied from 1 January 2026 and reaches certain non-EU operators serving EU residents.

Identifying reportable users

An RCASP reports on customers who are tax resident in a reportable jurisdiction, and on the controlling persons behind certain entity customers. It finds them through a self-certification collected from every user and checked against the KYC file.

Three kinds of self-certification. Platforms need a form for individual users, one for entity users, and one for the controlling persons of entity users. Each captures name, address, jurisdiction or jurisdictions of tax residence, Taxpayer Identification Number (TIN) and, for individuals, date of birth. Place of birth is needed only where domestic law already requires the RCASP to obtain and report it.

The reasonableness check. An RCASP can rely on self-certification only if it has no reason to know it is incorrect or unreliable, judged against what it already holds from AML and KYC onboarding. A user who certifies UAE residence while every login, document and bank account points to Germany is a problem the platform is expected to catch.

Who falls outside. Excluded persons are not reported. These include listed companies and their related entities, governmental entities, international organizations, central banks and most financial institutions. An institutional book can shrink a lot once these are filtered out, but only if the classification is documented.

Pre-existing users. Customers onboarded before go-live still need a self-certification. The OECD model allows 12 months from the effective date. Do not assume those 12 months are a reporting holiday: some implementing jurisdictions, such as South Africa, expect reporting to continue while forms are outstanding, and the UAE has not yet said which approach it will take. The UAE rules will fix the final timetable, but the remediation campaign for your existing book is usually the largest operational task in the whole project.

Changes in circumstances. When an RCASP learns of a change that makes a self-certification unreliable, the OECD model gives it up to 90 days to obtain a new form or confirm the old one. After that it must treat the user as resident in both the original jurisdiction and the newly indicated one.

Users without a TIN, and users who refuse. Some jurisdictions do not issue TINs to everyone, and some users will not respond. Your customer terms, onboarding flow and offboarding policy need a written position on both before January, not after the first reminder goes unanswered.

Classifying reportable transactions

CARF reports exchanges and transfers of relevant crypto-assets, aggregated per user, per asset and per transaction type over the calendar year. Trading is only part of it: payments and wallet transfers are caught too.

Relevant crypto-assets. The default is broad: any digital representation of value relying on a cryptographically secured distributed ledger. Stablecoins are in. Central bank digital currencies and specified electronic money products are carved out to CRS 2.0. Assets the RCASP has adequately determined cannot be used for payment or investment fall outside CARF altogether.

Derivatives need a structural answer. Whether a crypto-referenced derivative sits under CARF or CRS 2.0 depends on how it is issued, held and settled. A platform planning perpetuals or futures should answer that question in the product design, because it decides which reporting pipeline the data goes into.

Fiat ramps change the picture. A platform that adds a fiat on-ramp or off-ramp turns a crypto-only reporting profile into a mixed one, with new valuation points and new counterparties. Build the classification into the product before launch rather than reverse-engineering it from the ledger in December.

Where VARA KYC falls short of CARF

A VARA-compliant onboarding file is a good starting point, but it was built for AML, not tax reporting. Most platforms are missing three data points: tax residence, TIN and a self-certification covering controlling persons.

The fix is usually not a new onboarding journey. It is extra fields, a self-certification step aligned with data you already hold, and a remediation campaign for the existing book.

CARF, CRS 2.0 and the Travel Rule compared

These three regimes overlap in data but differ in purpose, recipient and timing. Compliance teams that treat them as one project end up with gaps in all three.

A 90-day CARF readiness plan

There is enough time to be ready for 1 January 2027 if the legal analysis runs in October and November and the build runs in December. The order matters more than the speed: each step builds on the one before, with some overlap.

1. Weeks 1 to 2: map the entities. Review the group chart, constitutional documents and licences. Decide RCASP status and nexus for each entity and record it in an obligations matrix.
2. Weeks 3 to 5: scope the users. Classify retail, qualified and institutional customers, identify excluded persons, and draft the three self-certification forms against the KYC data you already collect.
3. Weeks 4 to 6: classify the transactions. Run spot, fiat ramp, payment, transfer and derivative flows through the CARF rules, and settle any product questions before launch dates.
4. Weeks 6 to 9: amend the paperwork. Update AML/CFT, onboarding and data policies, customer terms and privacy notices so you can collect the data, report it and act on users who do not respond.
5. Weeks 9 to 12: build and remediate. Add the self-certification step to onboarding, plan the campaign for pre-existing users, map data fields to the OECD CARF XML schema with your reporting provider, and take the package to the board.

Throughout, track the Ministry of Finance for the final domestic rules on registration and filing, and slot them in as they land.

Common CARF mistakes we see

The most expensive CARF mistakes come from doing the right things in the wrong order.

• Buying the reporting tool first. Software formats data. It cannot tell you which entity reports or which users count.
• Assuming the licensed entity is the only reporting entity. The nexus rules and the flow of orders decide, who reports, not the licence.
• Treating every institutional client as excluded. Only specific categories qualify, and the classification must be documented.
• Leaving pre-existing users until 2027. The remediation campaign takes months, and users who do not respond need a policy.
• Forgetting the customer terms. Without contractual rights to collect, report and restrict, the platform carries the risk alone.
• Adding fiat ramps or derivatives after go-live without a classification. New products bring new reporting lines that should be designed in, not patched.

Final thoughts

CARF is a three-question problem: which entities, which users, which transactions. Firms that answer those questions in October can spend December building. Firms that start with the software will spend January rebuilding it. The UAE has positioned itself as a regulated and transparent hub, and CARF readiness is now part of what a credible licence holder looks like to banks, partners and regulators.

Work with the UAE’s first crypto-native law firm

NeosLegal advises licensed VASPs on CARF in fixed-fee scopes your board can approve one at a time: entity mapping, reportable users and self-certification forms, and reportable transactions, or all three as a single CARF compliance assessment with a prioritized roadmap. We can also draft the policy amendments or review your in-house drafts.

About the Author

Zainab Kamran is a crypto and Web3 lawyer and an Associate at NeosLegal, a boutique Web3 law firm based in the UAE, where she advises on the legal and regulatory structuring of crypto and digital asset projects and tokenized business models across multiple jurisdictions.

Her work focuses on bridging legal structure with product reality, helping clients navigate regulatory uncertainty while designing crypto systems that can function in practice. She is regularly involved in matters where legal, technical, and operational considerations intersect, and where early structuring decisions materially affect execution risk.

In addition to client advisory work, Zainab has contributed to policy discussions on tokenization frameworks and has advised government-related stakeholders on the development of regulatory approaches to digital assets.

About NeosLegal

NeosLegal is the UAE’s first crypto-native law firm for founders, operating since 2016. In 2026 it was named Best UAE Crypto Law Firm by the UAE Business Awards Middle East, and in 2025 it won Middle East Technology Legal Team of the Year at The Oath Middle East Legal Awards. Founder Irina Heaver is recommended by Lexology as the UAE’s leading blockchain lawyer, is a contributor to the Chambers and Partners Virtual Assets Practice Guide, and is a Forbes Digital Assets contributor. The firm has structured 300+ projects, advised on $500B+ in deal value and over 20 VASP licence applications, and recorded zero client enforcement actions across ten years and five regulators. neoslegal.co

Reviewed by Irina Heaver, UAE Crypto Lawyer and Founder of NeosLegal.