What Crypto Operators and Platforms Need to Do — UK, EU, and UAE

The Crypto-Asset Reporting Framework is not a distant compliance project. It is live. In the UK and across the EU, crypto-asset service providers have been collecting reportable user data since 1 January 2026. The first reports reach HMRC and EU tax authorities in 2027. The UAE joins the same system from 1 January 2027, with first exchanges in 2028. For platforms, exchanges, custodians, and brokers with users in any of these jurisdictions, CARF creates immediate operational obligations that do not wait for the first filing deadline.

1. What Is CARF?

The Crypto-Asset Reporting Framework (CARF) is the OECD’s global standard for the automatic exchange of tax-relevant information on crypto-asset transactions. It was developed alongside amendments to the Common Reporting Standard (CRS 2.0) and published in 2023. Its purpose is direct: to close the gap that allowed crypto-asset activity to fall outside the automatic exchange of information (AEOI) infrastructure that already covers bank accounts, investment funds, and insurance contracts under CRS and FATCA.

CARF works the same way CRS works. The obligation falls on the intermediary — the platform, the exchange, the custodian — not on the user. The intermediary collects, verifies, and reports data on every user to the tax authority of the jurisdiction in which the intermediary operates. The tax authority then exchanges that data automatically with the tax authorities of each user’s country of tax residence. No court order, no information request, no taxpayer action required.

THE DESIGN PRINCIPLE

CARF is modelled on CRS, which has been highly effective at surfacing undisclosed offshore bank accounts. The OECD’s explicit intention is to replicate that infrastructure for crypto. A user who holds crypto on a regulated platform in the UK, the EU, or the UAE should expect that their home tax authority will receive their transaction data — automatically, without any action on their part — within 12–18 months of the reporting period closing.

1.1 What CARF Covers

CARF applies to Relevant Crypto-Assets — defined broadly as any digital representation of value that relies on a cryptographically secured distributed ledger. This includes cryptocurrencies (BTC, ETH), stablecoins, NFTs where they can be used for payment or investment purposes, and utility tokens where they can be exchanged. The definition is intentionally broad and is designed to avoid loopholes created by technical distinctions between asset types.

What CARF requires to be reported, per user, per reportable jurisdiction, per year:

• Aggregate amounts (in fiat currency equivalent) of: crypto-to-fiat exchanges; crypto-to-crypto exchanges; transfers of crypto-assets (including payments for goods and services above applicable thresholds)
• Number of units and aggregate fair market value of each type of crypto-asset transferred
• Transaction counts per asset type
• User identity: full legal name, address, date and place of birth (individuals), or legal name and registration address (entities), plus tax identification numbers (TINs) for each jurisdiction of tax residence
• Self-certification of tax residency — a signed declaration by the user confirming their tax residence, which the platform must collect, verify, and retain

1.2 Who Must Report (RCASPs)

CARF reporting obligations fall on Reporting Crypto-Asset Service Providers (RCASPs). The definition is broad and functional — it covers any entity or individual that, as a business, provides services effecting exchange transactions in crypto-assets on behalf of or for the account of customers.

• Centralised exchange (CEX): Yes. Core target of CARF. Collects and reports on all users.
• Custodial wallet provider: Yes. Holds assets on behalf of users — triggers RCASP status.
• Crypto broker / OTC desk: Yes. Facilitates transactions as counterparty or agent.
• NFT marketplace: Conditional. Only where NFTs are used for payment or investment purposes; pure collectible platforms may be excluded depending on jurisdiction-specific rules.
• DeFi protocol: Conditional. Non-custodial, fully automated protocols without an operator who can identify users are generally outside CARF scope. Protocols with identifiable operators may be in scope depending on jurisdiction.
• Payment processor (crypto): Yes. Where the processor can identify users and effect transactions.
• Tokenisation platform: Conditional. In scope where the platform facilitates exchange transactions. Out of scope for pure issuance where no ongoing exchange function exists.

THE PLATFORM NEXUS TEST

A platform does not need to be incorporated in the UK, EU, or UAE to have CARF reporting obligations there. DAC8 in particular has global reach: any platform serving EU-resident users — wherever the platform is based — is required to register with an EU member state regulator and report EU-resident user data. The same nexus-based approach applies under the UK framework. A UAE platform with EU or UK users is within scope of DAC8 and UK CARF from 1 January 2026.

2. Jurisdiction-by-Jurisdiction Obligations

CARF is implemented through domestic legislation in each participating jurisdiction. The OECD standard sets the floor; jurisdictions may add requirements above it. For operators with a multi-jurisdiction presence or a user base spanning multiple countries, the obligations stack.

2.1 United Kingdom

Live from 1 January 2026

The UK implemented CARF through regulations made in June 2025, effective from 1 January 2026. The UK framework closely follows the OECD standard with one material addition: UK-based reporting providers must report not only on users resident in other CARF jurisdictions, but also on UK-resident users — covering domestic crypto activity, not just cross-border holdings. This means HMRC receives data on UK-resident users of UK platforms regardless of whether those users have any international dimension.

• Data collection start: 1 January 2026 — all reportable transactions from this date
• First reporting period: Calendar year 2026
• Registration deadline: 31 January 2027 — platforms must register with HMRC
• First report due: 31 May 2027 — covering the full 2026 calendar year
• First exchange with partner jurisdictions: By 30 September 2027
• Scope of users: All users resident in the UK or any other CARF-participating jurisdiction
• Domestic users: Included — UK-resident users of UK platforms are reported to HMRC
• Self-certification: Required from every user — platforms must obtain, verify, and retain
• Format: XML file aligned to OECD CARF schema — structured data from day one

WHAT THIS MEANS FOR UK-NEXUS PLATFORMS

A UK-incorporated or UK-FCA-authorised platform must register with HMRC by 31 January 2027 and file its first CARF report by 31 May 2027 covering all of 2026. The practical implication: the data collection, self-certification, and KYC enhancement processes must have been in place since 1 January 2026. Platforms that have not yet built these systems are already collecting incomplete data for the first reportable period. The report cannot be reconstructed retrospectively from inadequate records.

2.2 European Union — DAC8

Live from 1 January 2026

The EU implemented CARF through the Eighth Directive on Administrative Cooperation (DAC8), adopted on 17 October 2023 and required to be transposed into national law by 31 December 2025, with application from 1 January 2026. DAC8 borrows its definitions of crypto-assets and service providers from MiCA, creating a degree of alignment between the regulatory and reporting regimes — but they are not identical, and MiCA authorisation does not automatically satisfy DAC8 reporting obligations.

DAC8’s reach is explicitly global. Any RCASP with EU-resident users — wherever the platform is incorporated — must register with one EU member state and report EU-resident user data to that member state’s tax authority, which then exchanges it across the EU. A UAE platform, a Singapore exchange, or a Cayman-incorporated broker serving EU users is within DAC8 scope.

• Data collection start: 1 January 2026
• First reporting period: Calendar year 2026
• First reports due: Within 9 months of year-end — approximately September/October 2027, varying by member state
• First exchange between EU member states: By 31 December 2027
• Scope of users: All EU-resident users, including residents of the member state where the platform is registered
• Non-EU platforms: Must register in one EU member state if they have EU-resident users — single registration covers all member states
• Transposition status: ~12 member states missed the 31 December 2025 deadline; most passed legislation during 2026 with retroactive effect to 1 January 2026. Late national law does not defer the obligation to collect 2026 data.
• Interaction with MiCA: MiCA authorisation does not replace DAC8 registration. Separate registration with the competent authority in the chosen member state is required.

THE RETROACTIVE EFFECT OF LATE TRANSPOSITION

Several EU member states transposed DAC8 into national law during 2026 rather than by the required 31 December 2025 deadline. The legislation in these jurisdictions typically has retroactive effect back to 1 January 2026. This means platforms operating in those member states cannot argue that the late national law delays their data collection obligations — the EU Commission’s position, and the consistent interpretation of DAC8, is that the obligation to collect 2026 data existed from 1 January 2026 regardless of when the domestic implementing legislation was passed.

2.3 United Arab Emirates

Collection from 1 January 2027 — Exchanges from 2028

The UAE signed the CARF Multilateral Competent Authority Agreement (MCAA) on 21 July 2025, committing to commence automatic exchanges of information under CARF by 2028 in respect of the 2027 calendar year. This makes the UAE a second-wave jurisdiction — data collection begins 1 January 2027, first reports and exchanges in 2028.

The UAE Ministry of Finance ran a public consultation on implementation from 15 September to 8 November 2025. Final regulations are expected during 2026, with compliance obligations crystallising from 1 January 2027. The 2025–2026 period is the preparation window for UAE platforms, exchanges, and custodians: systems, processes, and user self-certification frameworks must be ready by the start of 2027.

• MCAA signed: 21 July 2025
• Public consultation: 15 September – 8 November 2025
• Final regulations expected: 2026
• Data collection start: 1 January 2027
• First reporting period: Calendar year 2027
• First exchanges with partner jurisdictions: 2028
• Platforms in scope: UAE-nexus RCASPs: exchanges, custodians, brokers, payment processors with UAE connection
• Users in scope: Users of UAE platforms resident in any CARF-participating jurisdiction (70+ countries)
• Interaction with VARA/FSRA licensing: CARF reporting obligations are additive to VARA and FSRA licensing requirements — they do not replace KYC/AML obligations but extend the data collection and reporting duty

WHY UAE PLATFORMS CANNOT WAIT UNTIL 2027

A UAE platform serving UK-resident or EU-resident users is already in scope of UK CARF and DAC8 from 1 January 2026 — irrespective of the UAE’s own 2027 implementation date. If a UAE exchange has UK users, it must register with HMRC and report those users’ 2026 data by 31 May 2027. If it has EU users, it must register in an EU member state and collect EU-resident user data from 1 January 2026. The UAE’s domestic CARF implementation date is irrelevant to these obligations. The platform’s nexus to the user’s jurisdiction of residence determines which reporting regime applies.

3. Operational Obligations for Platforms

For a crypto-asset service provider, CARF is primarily an operational challenge before it is a reporting challenge. The data that must appear in the annual CARF report can only be produced if the platform has built — and maintained — the right data infrastructure from the first day of the reportable period. For UK and EU platforms, that was 1 January 2026. For UAE platforms, it is 1 January 2027.

3.1 User Due Diligence and Self-Certification

CARF requires every RCASP to obtain a self-certification from each user — a signed declaration confirming the user’s jurisdiction(s) of tax residence and their tax identification number (TIN) in each jurisdiction. This is not a one-off exercise: the self-certification must be obtained at onboarding for new users, and from existing users within a reasonable period of the CARF compliance date. Platforms must also review the self-certification periodically and whenever they have reason to believe the information may have changed (e.g. a change of address, a new jurisdiction indicator from the user’s transaction patterns).

• New users: self-certification must be obtained and verified before any reportable transaction is processed.
• Existing users: self-certification must be obtained within the transition period — typically by the end of the first reportable year, though jurisdictions may apply shorter deadlines.
• Plausibility review: the platform must apply the same reasonableness check used under CRS — if the self-certification is inconsistent with other information the platform holds (address, phone number, payment method, IP address), the inconsistency must be resolved before the certification is treated as valid.
• Retention: self-certifications and supporting documentation must be retained for at least 5 years from the end of the reporting period to which they relate.

3.2 Transaction Data Capture

The CARF report requires aggregate transaction data by asset type and by transaction category. The three categories are: exchanges (crypto to fiat), swaps (crypto to crypto), and transfers (movements of crypto between wallets, including payments). For each, the report requires the fiat equivalent value at the date of the transaction, the number of units, and the transaction count. This level of granularity requires the platform to capture and store accurate, timestamped, attributable transaction records for every user, from the first day of the reportable period.

DATA QUALITY IS THE CONSTRAINT

The most common compliance failure in CRS implementation was not the filing itself — it was the quality of the underlying data. Platforms that had not collected TINs, had incomplete address records, or had not applied plausibility checks found that they could not produce accurate reports regardless of how good their filing systems were. CARF has the same vulnerability. The time to fix data quality is before the reportable period begins, not when the filing deadline arrives.

3.3 Registration Requirements

UK platforms must register with HMRC by 31 January 2027. Non-UK platforms with UK-resident users must also register with HMRC if they are not already registered in another jurisdiction that has a bilateral agreement with the UK under CARF.

EU: non-EU platforms with EU-resident users must register with the competent authority in one EU member state of their choice. The single registration covers reporting obligations across all member states. Platforms with MiCA authorisation in one member state may be able to use that registration as the basis for their DAC8 registration in the same member state — but this must be confirmed with the relevant national authority, as the two regimes are separate.

UAE: registration requirements for domestic platforms will be specified in the final regulations expected in 2026. Platforms should monitor the UAE Ministry of Finance’s guidance closely and build their registration process into their 2026 preparation timeline.

3.4 Systems and Technology

CARF reports are filed in XML format aligned to the OECD’s CARF XML schema. This is the same technical infrastructure used for CRS reporting. For platforms that already report under CRS — typically those serving institutional clients or operating in multiple jurisdictions — the extension to CARF requires adaptation of existing systems. For platforms that have not previously reported under CRS, building the XML reporting infrastructure from scratch is a material project that should not be underestimated.

• Data model: the platform’s transaction database must be able to produce, per user, per reportable jurisdiction, per asset type, per transaction category: aggregate amount (in fiat), number of units, transaction count.
• TIN management: the platform must store and validate TINs for each user’s reported jurisdictions. TIN formats vary by jurisdiction — the platform needs a validation engine or a reference dataset.
• Plausibility engine: the platform needs a process for identifying and resolving inconsistencies between self-certifications and other user data.
• Audit trail: every step of the due diligence, self-certification, and data collection process must be logged and retainable for at least 5 years.

3.5 Penalties

Penalty regimes vary by jurisdiction, but the pattern is consistent: penalties apply per failure, not per report, and the amounts are designed to be material relative to the cost of compliance. In the UK, HMRC’s penalty framework for CARF follows the same structure as CRS penalties: up to £300 per user for failure to collect required information, with additional penalties for deliberate non-compliance and for inaccurate reports filed without reasonable care. EU member states are required to provide effective, proportionate, and dissuasive penalties under DAC8 — most have implemented penalty regimes in the range of €1,000–€10,000 per reportable user for systematic failures.

4. What CARF Means for Your Users

For platforms, CARF is a compliance obligation. For users, it is a transparency event. The data that a CARF report contains — aggregate transaction amounts, asset types, user identity and tax residence — is exactly the data a tax authority needs to identify unreported gains, undisclosed income, and mismatches between the user’s self-assessment and the platform data.

4.1 The Information Asymmetry Closes

Until CARF, there was a structural gap in tax authority visibility: bank accounts, investment funds, and insurance policies were reported under CRS and FATCA; crypto activity was not. A UK resident who held crypto on an offshore exchange, realised significant gains, and failed to disclose them on their self-assessment return was, in practice, unlikely to be detected unless HMRC had specific intelligence. CARF closes that gap. From 2027, HMRC will receive automatic reports of UK-resident users’ activity on every UK and EU platform. From 2028, UAE platform data joins the same flow.

THE PAPER RESIDENT PROBLEM

The most acute exposure identified by practitioners is what WTP has called the ‘paper resident’ — the individual who has relocated to Dubai but never formally severed UK tax residence. UK statutory residence test (SRT) analysis is required; the move to Dubai does not automatically trigger UK non-residence. If HMRC receives a CARF report showing large crypto transactions on a UAE platform attributed to a user whose TIN is UK-resident, and the user has not filed a UK self-assessment return for those transactions, the mismatch triggers an enquiry. The platform’s obligation is to report accurately based on the self-certification it holds — but the user’s tax position depends on whether the self-certification is itself accurate.

4.2 The Self-Certification Is Not a Safe Harbour

A user who provides a UAE tax residency self-certification to a Dubai exchange — without having genuinely severed UK tax residence — has provided an inaccurate self-certification. The platform’s obligation is satisfied by collecting and plausibility-checking the certification; the platform is not responsible for its accuracy beyond that check. But the inaccurate certification does not protect the user from HMRC. If HMRC receives CRS or CARF data from the UAE that identifies the user as a UAE resident, while also receiving data from UK platforms that shows UK-resident behaviour, the mismatch will surface. The user’s tax liability is determined by the actual facts — where they are resident under the SRT — not by what they told the exchange.

4.3 What Platforms Should Communicate to Users

Platforms are not tax advisers, and their CARF communications to users should not cross into tax advice. However, providing users with clear factual information about CARF — what data is being collected, which tax authorities will receive it, and when — is good practice and reduces the risk of user complaints when data is exchanged. A CARF disclosure notice, incorporated into the platform’s terms of service and served at the point of self-certification, should cover:

• The platform’s reporting obligations under CARF, UK CARF, and/or DAC8
• The data that will be reported (identity, tax residence, transaction aggregates)
• The jurisdictions to which data will be reported
• The consequences of providing an inaccurate self-certification (the platform may be required to report to HMRC or the relevant EU authority regardless)
• A recommendation to seek independent tax advice on their tax residence position and filing obligations

5. Interaction with UAE Corporate Tax and VARA

For UAE-based platforms, CARF sits alongside — and interacts with — two other significant regulatory developments: the UAE Corporate Tax Law (effective June 2023) and the VARA licensing regime (Dubai, operational from 2023). These three frameworks together define the compliance landscape for a crypto-asset service provider operating in Dubai.

5.1 CARF and UAE Corporate Tax

UAE Corporate Tax at 9% applies to taxable income above AED 375,000 earned by UAE entities. For a UAE platform, this means the platform’s own income — trading fees, custody fees, transaction revenue — is subject to UAE CT. CARF does not impose a separate tax obligation, but the data collected for CARF purposes — detailed transaction records, user identity, fiat values — overlaps materially with the records required for UAE CT compliance. An integrated data infrastructure that serves both purposes is more efficient and less error-prone than two separate systems.

Transfer pricing documentation requirements apply where the platform has intra-group transactions with related entities — a common structure where a UAE entity provides services to a UK or EU parent or subsidiary. The UAE CT law’s transfer pricing chapter closely mirrors the OECD Guidelines, and CARF data on cross-entity transactions may be relevant to both the CT computation and the TP documentation.

5.2 CARF and VARA Licensing

VARA licensing in Dubai requires, among other things, robust KYC/AML infrastructure. The KYC data collected to satisfy VARA requirements — user identity, beneficial ownership, source of funds — overlaps significantly with the data required for CARF self-certification. However, the two frameworks serve different purposes and the data standards are not identical: VARA KYC is primarily AML-focused; CARF due diligence is tax-transparency-focused. TINs, for example, are not typically collected as part of AML KYC — platforms need to add TIN collection and self-certification to their onboarding process on top of the existing VARA KYC.

AN INTEGRATED COMPLIANCE SYSTEM

The most efficient approach for a UAE platform is a single onboarding and data management system that collects, stores, and processes the data required for VARA KYC, CARF due diligence (including TINs and self-certifications), and UAE CT record-keeping in one place. Building separate systems for each regulatory obligation is operationally costly and creates the risk of inconsistencies between the records held for different purposes — which is itself a compliance risk under each regime.

6. What to Do Now

The preparation window differs by jurisdiction. For UK and EU platforms, the data collection period has been running since 1 January 2026 — the question now is whether the systems are fit for purpose before the May 2027 filing deadline. For UAE platforms, the preparation window closes at the end of 2026. The eight steps below apply to any platform within scope.

Step 1 — Determine Scope

Confirm whether the platform is an RCASP under each applicable jurisdiction — UK CARF, DAC8, and (from 2027) UAE CARF. The answer depends on the platform’s activities, its jurisdiction of incorporation, and the residency profile of its user base. A platform with no EU users is not in DAC8 scope. A platform with any UK users is in UK CARF scope regardless of where it is incorporated.

Step 2 — Review Existing KYC and Onboarding

Assess whether the existing KYC process collects, verifies, and retains: full legal name and address; date and place of birth (individuals); tax residence jurisdiction(s); TIN for each tax residence jurisdiction; and self-certification. Most KYC processes designed for AML purposes do not collect TINs or formal tax residency self-certifications — these need to be added.

Step 3 — Build or Update Self-Certification Processes

Design and implement a self-certification form aligned to the OECD CARF template. Build the plausibility review process — the check that cross-references the self-certification against other user data. Determine how to handle users who refuse to self-certify (in most jurisdictions: report them to the tax authority with a notification that the self-certification was refused).

Step 4 — Enhance Transaction Data Infrastructure

Verify that the transaction database captures, per transaction, per user: timestamp, asset type, transaction category (exchange / swap / transfer), fiat equivalent value at transaction date, number of units. If not, the gap must be closed from the first day of the reportable period — data cannot be reconstructed after the fact.

Step 5 — Register with the Relevant Authority

UK platforms: register with HMRC by 31 January 2027. Non-UK platforms with UK users: also register with HMRC. EU: register in one member state. UAE: monitor the final regulations and build registration into the 2026 preparation plan.

Step 6 — Build the XML Reporting Infrastructure

Engage a technology provider or build in-house the XML reporting pipeline aligned to the OECD CARF schema. Test the output against the schema validation rules. If using a third-party vendor, confirm the vendor’s timeline, their familiarity with the specific jurisdiction’s filing portal, and their data handling arrangements.

Step 7 — Update User-Facing Documentation

Update terms of service, privacy policy, and onboarding communications to reflect CARF data collection and reporting. Serve a CARF disclosure notice at the point of self-certification. Do not provide tax advice — direct users to seek independent advice on their own position.

Step 8 — Legal and Accounting Review

Commission a review of the platform’s CARF classification, the completeness of its due diligence processes, and the interaction of CARF obligations with its regulatory licensing, corporate tax position, and transfer pricing arrangements. For platforms with a multi-jurisdiction structure, this review needs to address each jurisdiction separately and identify any conflicts or gaps in the combined compliance framework.

SGS & Partners advises crypto-asset service providers on CARF and DAC8 compliance, UAE Corporate Tax, VARA operational requirements, and transfer pricing. To discuss your platform’s obligations under UK CARF, DAC8, or the UAE implementation — book a free 30-minute discovery call with a partner at sgs-partners.com