How EU and UK crypto platforms are already building your 2027 tax report
The first recipient depends on your provider’s reporting nexus, while tax residence shapes any onward exchange.
Quick Take
- DAC8 and UK CARF started applying on Jan. 1, 2026, so covered platforms may already be logging reportable activity.
- Those records feed 2027 reports to the provider's reporting authority, and sometimes onward to the user's tax residence.
- The route depends on provider nexus and tax residence, while users still need full records because reports omit complete trade history.
If you use a crypto platform in the European Union or the United Kingdom, some of your 2026 activity may already be being recorded and will be used to feed tax-information reports in 2027.
The EU's DAC8 rules and the UK's Cryptoasset Reporting Framework, known as CARF, both began applying on Jan. 1, 2026. The reporting chain now has three distinct stages: a provider collects information during 2026, sends an annual report to the authority to which it must report, and, in some cases, that authority routes the information to the user's country of tax residence.
Coverage depends on the provider, the user, the activity and the relevant reporting regime.
What providers collect and where it goes
Under DAC8, crypto-asset service providers collect data on reportable transactions involving EU residents, including users living in the provider's own Member State.
UK providers collect identifying details from every user, but only include some overseas customers in their annual reports.
HMRC's collection guidance says covered UK providers collect identifying details for all users and reportable transaction data for users in the UK and other CARF countries. The information may include tax residence and tax identification numbers, as well as reportable transaction data.
The reports received by authorities are more standardized and compressed than the crypto provider's underlying records. HMRC describes its filing as user details plus a summary of transactions. DAC8 specifies annual quantitative information, broken down by reportable cryptoasset and prescribed transaction category.
The provider’s legal entity determines where the account is reported and which authority receives the information first.
For EU providers subject to DAC8, the report is first submitted to the authority in their home country. UK providers send theirs to HMRC.
Where a user lives determines what happens next. Under DAC8, EU countries share reports on residents using providers based elsewhere in the bloc.
UK outward exchange requires that the foreign jurisdiction have an agreement or arrangement in effect with the UK and appear on the applicable UK reportable-jurisdiction list.
| Provider reporting nexus | User tax residence | First recipient | What can happen next |
|---|---|---|---|
| EU Member State under DAC8 | Same Member State | That Member State's tax authority | The residence and reporting states match, so the information remains in the domestic route. |
| EU Member State under DAC8 | Different EU Member State | Provider's reporting-state authority | DAC8 routes the nonresident user's information to the user's residence-state authority. |
| United Kingdom under CARF | United Kingdom | HMRC | The user's information enters the domestic HMRC report for the 2026 period. |
| United Kingdom under CARF | Foreign jurisdiction on the applicable UK list | HMRC | Outward exchange can occur when an agreement or arrangement is in effect, and the jurisdiction remains listed. |
| United Kingdom under CARF | Foreign jurisdiction outside the applicable UK list | None under UK CARF solely because of that unlisted residence | Identity information may still be collected, and a later change to the applicable list can alter the foreign reporting route. |
A user’s country does not tell the whole story. What matters is which crypto provider holds the account, where that provider reports, and the tax residence listed for the user.
OECD implementation commitments and activated international CARF routes are separate records. The OECD's exchange-relationships register records direction, legal basis and applicable dates, and some relationships can be nonreciprocal.
The 2027 calendar and the limits of the report
The UK's domestic provider deadline is fixed. Covered providers must submit their first report to HMRC between Jan. 1 and May 31, 2027, covering activity from Jan. 1 through Dec. 31, 2026, according to HMRC's reporting guidance.
The EU separates when providers file reports from when tax authorities exchange them.
Reports covering 2026 are filed in 2027, while the applicable Member State sets the provider deadline and format.
Sept. 30, 2027 is the common deadline for EU authorities to exchange information for 2026 about nonresident users with their EU country of tax residence. Member State rules set each provider's filing cutoff.
UK international exchange remains conditional after the May 31 filing deadline. HMRC's 2026 reportable-jurisdiction notice requires both an operative agreement or arrangement and inclusion on the UK list.
That list may change if a jurisdiction defers implementation or the UK concludes another arrangement. The domestic filing date and the conditional outward route are the usable calendar markers; outbound timing follows each applicable relationship.
DAC8's statutory reporting framework requires annual amounts or fair market values, and units and counts, by reportable cryptoasset and prescribed transaction category. Those aggregates provide standardized, authority-sanctioned compliance data while stopping short of a complete trade history.
Provider reports do not calculate cost basis, gains, or tax owed, and they may miss activity held on another exchange or in a personal wallet. When assets move between a platform and a wallet, the user's records must connect both sides of the movement and preserve the earlier acquisition information that an annual provider summary may lack.
This 2026 cycle begins DAC8 and UK CARF reporting, expanding existing tax-transparency and tax-compliance channels.
Tax authorities already had other ways to request records or receive crypto-related information. The current change is the standardized reporting period now underway across these EU and UK regimes.
Records users should reconcile before the reports arrive
Providers send the report, but users still need the records to work out what they owe. HMRC's cryptoasset recordkeeping manual tells individuals to retain per-transaction information including the type, transaction date, buy or sell status, units, sterling value at the time, cumulative units held, bank statements and wallet addresses.
Supporting valuation records may also be needed.
Preserve the records that let you reconnect activity across accounts before an exchange removes your export or an account is closed.
At a minimum, keep enough information to trace the full history of each transaction across platforms.
A useful reconciliation set includes:
- full platform exports rather than screenshots of current balances;
- transaction dates and timestamps, including the time zone used;
- asset names, token identifiers and units;
- local-currency values at each transaction date;
- wallet addresses and transaction hashes for transfers;
- trading, network and withdrawal fees;
- bank, card and exchange statements;
- acquisition records and cost information from other venues or earlier years; and
- notes matching transfers between the user's own accounts so the same movement can be traced on both sides.
Users in EU Member States should apply the record rules and tax methods of their own jurisdiction, which may require fields beyond the UK examples.
The provider’s 2027 report may show an authority what was declared, but it will not rebuild the user’s full transaction history.
Affected users are already on the reporting clock.
In 2026, users should find out which provider holds their account, check the tax residence on file, download the full records, and match every transaction against wallets, statements, fees, and acquisition costs. Otherwise, the authority may receive a summary that tells only part of the story.
