Most general practices have a handful of clients who mention, usually in January, that they "did a bit of crypto". Until now the practical risk of an incomplete return was low, because HMRC had limited visibility. That is changing.
What CARF is
The Cryptoasset Reporting Framework is an OECD standard for the automatic exchange of tax information on crypto, in the same family as the Common Reporting Standard for bank accounts. The UK applied it from 1 January 2026. UK cryptoasset service providers - exchanges, brokers and similar platforms - must collect identifying details from their users and report their transactions to HMRC. The first reports cover the 2026 calendar year and are due by 31 May 2027.
The EU has implemented the same standard through a directive known as DAC8, on the same timetable, and many other jurisdictions have committed to it. Information will be exchanged between tax authorities, so an overseas platform is not a hiding place.
What it changes in practice
From 2027 HMRC will be able to compare what platforms report with what appears on a Self Assessment return. It is reasonable to expect more of the "nudge" letters HMRC already sends where it holds information suggesting undeclared gains, and more clients arriving with several years to put in order.
For a practice, that means two kinds of work: getting current-year reporting right, and catching up earlier years for clients who never reported.
Why exchange statements are not enough
Platform reports, and the statements clients can download, cover what happened on the platform. A large share of crypto activity does not happen there. Once a client withdraws assets to a wallet they control, everything they do next is recorded on a public blockchain and on no statement at all:
- Trading on decentralised exchanges.
- Staking, lending and other yield.
- Moving assets between networks through bridges.
- Receiving airdrops.
- Moving assets between their own wallets.
Crypto tax software can read a wallet address, but it often cannot interpret what it finds. The typical result is a long list of "unknown" transactions and two specific errors that distort the computation:
- A transfer between the client's own wallets is treated as a disposal on the way out and as an acquisition with no cost on the way in.
- A deposit into a DeFi protocol is treated as a disposal, when the client may simply have received a receipt token in exchange.
Whether some of these events are disposals is a genuine question of tax treatment, and that judgment is yours. But you can only make it once you know what each transaction actually was.
What to ask clients for now
You do not need to understand blockchains to collect the right material. Ask every client with crypto for:
- A list of every exchange or app they have ever used, including ones they have stopped using, with full transaction history downloads. Platforms close and old accounts become inaccessible, so this is worth doing early.
- Every wallet address they control or have controlled. Hardware wallets, browser wallets, mobile wallets. For Bitcoin hardware wallets, the extended public key (xpub) covers all addresses at once.
- What they did, in their own words. "Bought and held", "traded a lot in 2021", "staked my ETH", "used DeFi". It tells you how complex the reconstruction will be.
- Anything received from or sent to other people: gifts, payments, repayments.
- Any wallets they have lost access to, and when.
- Bank statements showing money going to and from exchanges. These anchor the whole history.
Missing wallets are the most common problem. If a client's declared wallets send assets repeatedly to an address that never sends anything back, it is very often another wallet of theirs that they forgot to mention.
What a complete record looks like
For each tax year you want a single ledger covering every wallet and exchange, in which each line has a date, an asset, a quantity, a sterling value at the time, and a category: purchase, sale, trade, own-wallet transfer, bridge, staking reward, interest, airdrop, fee. Transfers between the client's own wallets should be matched to each other so they drop out. Anything that needs your judgment should be listed separately, with the facts.
From that, your usual software can apply the share-pooling rules and produce the computation. Period-end balances and valuations fall out of the same data for clients who hold crypto in a company.
Where a specialist fits
Reconstructing on-chain history is data work, not tax work. Some practices build the skill in-house. Many would rather not, and do not want to refer the client away to a specialist crypto accountant and lose the relationship. The third option is to use a data specialist behind the practice: they prepare the record, and you keep the client, the computation and the advice.