HMRC Crypto Tax Record Keeping: A UK Evidence Checklist for 2026
HMRC crypto tax records are discussed here as general evidence and CARF reporting context, not personalised tax guidance.
Practical guidance on the kinds of records and evidence HMRC will expect you to hold and to be able to show — and how provider reporting under CARF relates to, but does not replace, individual tax records.
Contents
OGM editorial illustration: secure records and reporting context.OGM editorial illustration: secure records and reporting context.
At a glance
CARF requires UK cryptoasset service providers to collect and report user and transaction data; the first UK report covers 2026 activity and is due in the first half of 2027 [3].
Provider reporting is a compliance duty for firms, not a determination of an individual’s tax position; taxpayers remain responsible for their own records and returns [3].
Strong transaction trails typically combine platform statements, transaction IDs or hashes, wallet addresses, timestamps and independent valuation evidence (exchange rates, historical snapshots).
Treat transfers between your own wallets and between platforms as separate events that need documentary context: destination/source addresses, memos/tags, and contemporaneous notes.
FCA rule changes for regulated crypto activities passed Parliament in February 2026 and the regulated scope increases from October 2027; stability and custody rules for authorised firms were finalised in June 2026 [1][2].
Keep an auditable chain of evidence that links inflows and outflows to bank records, invoices, communications and any metadata your platforms provide.
This article is accurate to 17 August 2026.
Introduction: why record quality matters now
HMRC’s move to require cryptoasset service providers to collect and report user and transaction data under the Crypto-Asset Reporting Framework (CARF) creates a new, institutional layer of information flow into tax authorities.
The UK’s first CARF report covering activity from 1 January to 31 December 2026 must be submitted by providers between 1 January and 31 May 2027 [3]. That reporting obligation sits alongside — and does not replace — the longstanding responsibility on taxpayers to maintain sufficient records to support returns and any enquiries. Good records make it possible to answer HMRC questions efficiently, to reconcile what a platform reports with what you believe happened, and to demonstrate how valuations or tax treatments were calculated.
This article focuses on the practical building blocks of reliable evidence: transaction trails, treatment of transfers, platform statements and exports, valuation evidence, and how to think about provider CARF reports in relation to individual tax matters. It does not provide tax, legal or investment advice and does not calculate tax liabilities.
CARF and provider reporting — what changed and what stayed the same
The reporting requirement in outline
The UK implemented reporting obligations for cryptoasset service providers under the Crypto-Asset Reporting Framework. Under that regime, UK cryptoasset service providers must collect specified user and transaction data and submit it to HMRC. The first set of UK provider reports covers the period 1 January to 31 December 2026, with the statutory window for submitting that initial report falling between 1 January and 31 May 2027 [3]. CARF is a provider-level reporting duty; it requires firms to gather and pass information, not to make tax assessments about individual users [3].
What CARF reporting is not
It is important to keep the distinction clear between a provider’s CARF submission and an individual’s tax position. A report submitted by a platform to HMRC under CARF is a record of transactional and user-level data that the provider holds or is required to collect; it does not, by itself, change how any particular transaction should be treated for tax purposes. HMRC guidance on provider reporting explicitly notes that this is a reporting duty for providers and is not a statement that every individual’s tax treatment has changed [3]. Taxpayers remain responsible for the accuracy of their own returns and for retaining evidence to support any position taken.
How CARF interacts with broader regulatory change
Separately from CARF, the UK made changes to the regulated crypto regime under financial services law in 2026.
The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 passed Parliament on 4 February 2026, and the FCA’s policy package expands the scope of regulated activities from 25 October 2027; the rules cover matters such as stablecoin issuance, custody, authorised activities, prudential requirements and market-abuse arrangements for crypto markets [1]. In addition, the FCA issued final rules and guidance on stablecoin issuance and cryptoasset custody on 30 June 2026; those specific rules apply to authorised cryptoasset firms on or after 25 October 2027 [2]. These regulatory developments affect firms’ obligations and the way platforms handle client assets; they do not replace individual tax record-keeping duties.
What HMRC (and investigators) typically look for in crypto tax enquiries
HMRC’s stated CARF role is provider reporting, but in practice HMRC’s ability to query taxpayers will be shaped by the combination of provider reports, bank records, and taxpayer-held documents. When HMRC opens an enquiry into crypto-related tax matters, the kinds of items that help to answer questions and substantiate positions are those that create an auditable trail linking the taxpayer to the economic facts. These include, most importantly:
Transaction-level detail: transaction IDs or hashes for on-chain moves; platform trade and transfer identifiers; timestamps; amounts and asset identifiers (token symbols and contract addresses where applicable).
Platform records: downloadable exports of trading histories, deposit and withdrawal records, realised gains/losses reports, and any tax summaries the platform provides.
Wallet evidence: public addresses used, wallet software exports, multisig sign-off records, or hardware wallet snapshots demonstrating control.
Bank and fiat records: bank transfers into and out of platforms, credit/debit card receipts, and bank statements correlating fiat movements with platform activity.
Contracts, invoices and receipts: sale/purchase invoices, service agreements, receipts from token sales or staking rewards reports.
Valuation evidence: contemporaneous exchange-rate sources, screenshots showing prices at relevant times, or historical API data demonstrating the rate used.
Communications and notes: emails, messages, and contemporaneous notes explaining transfers (for example, “transfer to cold wallet for security”) where the economic rationale is relevant.
These elements together help to establish identities of counterparties, sources and destinations of funds, dates and values, and the economic substance of transactions.
Transaction trails — the backbone of tax evidence
Why a clear chain matters
For crypto transactions, the single most important principle is traceability. On-chain data often provides an immutable ledger entry, but that ledger only shows addresses, timestamps and token movements — it does not show who controlled an address unless there is additional corroboration. A strong evidential chain links on-chain artefacts to platform accounts, bank flows and identity documents or communications that show control and intention.
Elements of a useful transaction trail
A useful trail tends to combine several layers of evidence:
– On‑chain identifiers: the transaction hash, block number, token contract address and token IDs (for NFTs).
These items enable reconstructions of when the token moved and between which addresses.
– Platform transaction IDs and export files: many centralised platforms provide CSV or PDF exports showing trade IDs, internal ledger IDs, and timestamps in the platform’s timezone. Keep those exports with filenames that record the date and platform.
– Timestamps and timezone context: record the timestamp and the timezone or the epoch time. When no timezone is included in an export, a contemporaneous screenshot showing local time can help.
– Address labelling: annotate wallet addresses in your records to show which address is yours, which is a custodian’s, and which belongs to another party. Platforms sometimes include memo or tag fields for transfers — preserve these.
– Bank linkage: keep bank statements or payment receipts showing fiat transfers into and out of the platform or wallet services. Where a bank payment funds a specific buy order, preserve the payment reference.
– Correspondence: emails or messages that confirm trades, withdrawals, staking reward statements, or support tickets are useful to explain the circumstances of unusual transactions.
When on-chain data is insufficient
On-chain evidence proves movement but not ownership or the economic reason for a transfer. Cases commonly arise where tokens move through multiple addresses (mixers, custodial chains, decentralised exchanges) or where internal ledger requests at a centralised exchange have no visible corresponding on-chain transaction. In those cases, platform exports, deposit/withdrawal confirmations, and payment records are crucial. If a platform’s export uses internal identifiers only, preserve copies of the platform interface that show how those internal IDs correspond to public addresses or to your account balance at given times.
Transfers — internal transfers, gifts and exchanges between wallets
Transfers are one of the most confusing areas to document. A single movement might be described variously as an exchange, an internal transfer, a personal transfer, a gift, or a disposal depending on circumstances. Good contemporaneous notes and documentary context reduce ambiguity.
Internal transfers and “wash” movements
Internal transfers are movements of assets within a single platform (for example, between a trading wallet and a custody wallet) that do not leave the provider’s custody. These may not create an on-chain record if they are internal ledger adjustments. If a transfer is internal, preserve the platform export that shows it as such — do not rely on on-chain hashes alone. Where a platform provides a “withdrawal” and a separate “deposit” entry for the same amount, keep both sides of the record to show it was internal.
Transfers between your own wallets
If you move assets between wallets you control (for example, from an exchange to a hardware wallet), gather:
– the source and destination addresses,
– the transaction hash for on-chain transfers,
– the purpose (security, cold storage, staking),
– contemporaneous screenshots or exports from both the sending and receiving interfaces,
– bank records if a fiat transfer was used to fund the position.
A movement from an exchange to your own wallet may still be recorded by the exchange and by on-chain data; retain both to prove the assets were moved to an address you controlled, at a given time.
Gifts and transfers to third parties
If assets are given as a gift or transferred to another person, document the recipient, the nature of the transfer (gift, loan, settlement), and any contemporaneous supporting communications (emails, contracts, receipts). Gifts can have tax consequences beyond capital gains (for example, inheritance tax implications) depending on the facts; provider CARF reporting of the transfer is a statement of activity, not of tax treatment.
Platform statements and exports — what to preserve and how to preserve it
Preserve native exports, not just screenshots
Where a platform offers CSV or other machine-readable exports that contain trade histories, deposit/withdrawal logs, transaction IDs and balance histories, download and store those files. Native exports often contain identifiers not visible on screen and are less vulnerable to later alteration than a screenshot. If a platform invoice or fee statement is available in PDF, keep that too.
Keep a record of what the export does and does not include
Not all exports contain the same fields. When you download a file, annotate a short note explaining what the export covers and its limitations — for example, whether it contains internal transfers, staking rewards, a timestamp with timezone, or only trades. If you create any derived spreadsheets to summarise activity, retain the original exports and preserve the formulas you used (a separate copy of the spreadsheet with formula cells visible is helpful).
Archive platform messages and emails
Platforms commonly send confirmations by email for deposits, withdrawals, identity checks, and policy notices. Archive these messages with the downloads they relate to. If you communicated with platform support to clarify a transaction, keep the full thread.
Document platform closures, freezes and service changes
If a platform closes, freezes withdrawals or changes its records format, capture a contemporaneous copy of its notices and preserve the latest data export you can obtain. CARF requires providers to report what they hold, but if a provider disappears or changes ownership you should keep whatever evidence you safely have to show the state of your account at those times.
Valuation evidence — how to show the value at a point in time
Why valuation evidence matters
Many tax questions depend on the value of an asset at a particular timestamp — the value when a disposal occurred, the value for an income recognition event, or the price at receipt. There is no single mandatory valuation source across all situations; the key is that the value chosen is reasonable, contemporaneous, and supported by evidence you can reproduce.
Common sources of valuation evidence
Useful valuation evidence includes:
– exchange rate snapshots from reputable exchanges at the time of the transaction,
– archived price data from recognised aggregators (where you can show the particular timestamp),
– contemporaneous screenshots showing the price on the exchange you used,
– recorded API outputs or CSV price histories that include the timestamp and currency pair.
If you use a specific exchange’s rate for a trade executed on that exchange, preserve a screenshot or export showing the price and volume at or immediately before the trade.
Dealing with illiquid tokens and non‑standard assets
Tokens with low liquidity or without a clear market price require particular care. For such assets:
– document the attempts made to find a market price,
– preserve order book snapshots if available,
– record evidence of any arranged sales or bilateral price-setting,
– if price discovery took place across multiple venues or through over-the-counter negotiation, keep the communications that show how the price was agreed.
Converting values into sterling
If the underlying market price is quoted in a non‑sterling currency, record the exchange rate used and why that rate was chosen (for example, mid-market rate at the transaction time). Keep the source of the exchange rate (exchange name, aggregator, or API) and a timestamp showing when the rate applied. If a platform provides a sterling equivalent for a transaction, preserve that alongside the raw token price and the exchange-rate source.
Reconciling provider CARF reports with your records
Why differences may arise
Differences between a provider’s CARF report and your own records are possible for many reasons:
– timing mismatches arising from timezone conventions or from the provider using its own reporting period,
– internal transfers that the provider reports in a form that differs from how you recorded them,
– rounding, small fee differences and currency conversions,
– differences in asset identifiers (token symbols can be ambiguous; contract addresses are definitive for tokens on chains that use them).
Because CARF focuses on provider-held data, it may include records of activity that you do not consider taxable disposals, or omit off-chain context you have that explains why a movement should not be treated as a disposal. Remember that a CARF report is a reporting dataset, not a tax calculation.
A method to reconcile defensibly
A defensible reconciliation typically follows these steps:
1. Obtain the provider CARF-style data export (your own platform exports, not the HMRC copy).
2. Map provider transaction IDs and hashes to your internal records using transaction hashes, addresses and timestamps.
3. Flag items that are internal transfers and produce supporting documentation — for example, an internal transfer export or a screenshot from the platform showing the transfer type.
4. Reconcile fiat flows using bank statements and payment receipts.
5. Annotate any discrepancies (timing, price, fee application) and keep a short contemporaneous memo explaining each annotation.
6. Preserve the reconciliation file and the original exports used to compile it.
When you should expect HMRC to use provider data
HMRC may use provider reports to identify taxpayers of interest or to cross‑check information submitted on returns. Provider CARF reports will increase the volume of matched information available to HMRC, but matched data will not automatically equate to a tax assessment. A taxpayer with good records can use reconciliations to respond to HMRC queries more quickly and to demonstrate why a given transaction was treated in a particular way.
Practical record-keeping checklist (descriptive, not prescriptive)
The checklist below lists kinds of evidence that are commonly useful in a tax context. It is descriptive: it states what items typically help to demonstrate the facts of transactions. It is not a legal or tax obligation checklist and should not be treated as personalised advice.
Transaction-level exports showing trade IDs, deposit and withdrawal IDs, timestamps and amounts.
CSV or PDF downloads of account statements and fee schedules from platforms.
Transaction hashes, block numbers and contract addresses for on-chain transfers.
Source and destination wallet addresses, with labels to indicate ownership.
Bank statements and payment receipts corresponding to fiat movements.
Screenshots showing order screens at the time of a transaction where the platform does not provide an export.
Copies of invoices, sales contracts, receipts for token sales, or receipts of crowdfunding contributions.
Records of staking rewards, airdrops, mining receipts and how often they were monetised or reinvested.
Evidence of the exchange-rate source and timestamp used to convert a token value into sterling.
Correspondence with platforms (support tickets, emails) that explain or clarify unusual entries.
Notes explaining the purpose of transfers (for example, “transferred to hardware wallet for cold storage”).
Backup copies of private key storage confirmations (do not store private keys insecurely alongside other records).
Document retention — what we know and what we do not
HMRC’s CARF guidance makes clear the schedule for provider reporting but does not, in the CARF text, create a separate set of documentary-retention rules for individual taxpayers; provider reporting obligations and taxpayer record-keeping obligations are distinct.
CARF increases the amount of third-party data HMRC can access, which may change the practical implications of a records shortfall for a taxpayer, but CARF does not itself state a new individual retention period. Taxpayers should be aware that HMRC’s investigative powers and the overarching statutory time limits for tax enquiries are governed by tax law beyond CARF; those matters are not altered by the fact that providers will be reporting transaction data. If in doubt about retention periods that apply to a specific tax or legal matter, consult HMRC general guidance or seek professional advice.
Common evidence pitfalls and how they complicate enquiries
Relying solely on screenshots
Screenshots are useful as contemporaneous evidence but are more vulnerable to questions about authenticity than native exports. Where possible, pair screenshots with native exports, and preserve metadata (file creation dates, full-resolution copies). If you must rely on screenshots, capture the full screen, include the operating system clock in view and retain the export or source file name shown in the screenshot.
Missing transaction identifiers
A missing transaction hash or internal ID makes linking records harder. If a platform provides only partial information, save any ancillary confirmations (email, phone notes) that show the event occurred. If an on-chain transaction exists but the platform export lacks a hash, record the time and the amount and search for matching on-chain transactions by amount and timestamp if that is feasible.
Not capturing supporting fiat evidence
A ledger showing token amounts without a bank statement or payment trail to explain how fiat was moved into or out of a platform is a gap. Keep the bank receipts and verify that payment references match the deposit references shown by the platform.
Confusing custodial addresses with personal control
A custodial address controlled by an exchange is not the same as a wallet address you personally control. If on-chain movement goes to or from a custodial address, ensure the platform export is preserved to show the relationship to your account. Do not assume an on-chain address is proof of your exclusive control without corroborating documentation.
Hypothetical scenario (illustrative only)
Note: The following scenario is illustrative, simplified and non‑exhaustive. It does not constitute tax advice.
Scenario: Reconciling a 2026 exchange-to-wallet transfer and an internal exchange movement
Facts (simplified):
– On 15 March 2026 at 09:12:03 UTC, an account holder (Taxpayer A) sold 1.5 ETH for GBP on Platform X, a UK-based authorised platform. The platform provides a trade export showing trade ID TX-1001, the token pair ETH/GBP, 1.5 ETH sold, and a realised fiat amount of £2,250, with fees separately listed.
– The platform later records a withdrawal of 0.5 ETH to an external wallet address controlled by Taxpayer A, with an on-chain transaction hash HASH-ABC123 and a timestamp 15 March 2026 09:45:22 UTC.
– Platform X also shows an internal balance transfer that moved 0.25 ETH from the trading wallet to a “staking wallet” within the platform’s custody system, recorded internally as TRANS-INT-222, with no on-chain hash.
– Taxpayer A’s bank statement shows a GBP credit of £2,240 on 15 March 2026 labelled “Platform X settlement” (the £10 difference is the platform fee).
– Taxpayer A has a screenshot from their wallet software showing receipt of 0.5 ETH at address 0xABC… on 15 March 2026, and a CSV export from Platform X that lists the trades, withdrawals and internal transfer IDs.
How the pieces of evidence can be assembled:
– Link the trade TX-1001 to the bank credit using the settlement date and the platform’s settlement reference visible on the bank statement and on the platform export.
– Use the withdrawal record with HASH-ABC123 to show the on-chain movement and preserve the wallet screenshot showing address 0xABC… receiving 0.5 ETH.
– Annotate the internal transfer TRANS-INT-222 as an in-platform movement; preserve the platform’s CSV export showing the internal transfer and any staking reward history related to the staking wallet.
– Preserve the fee breakdown showing £10 in fees and how the platform calculated the sterling amount for the ETH sale.
– Prepare a short contemporaneous memo that maps TX-1001, HASH-ABC123 and TRANS-INT-222 to the bank credit and the wallet receipt, explaining that:
– 1.5 ETH was sold, producing the GBP credit,
– 0.5 ETH was withdrawn on-chain to a personal wallet,
– 0.25 ETH was moved internally to a staking wallet and remained in the provider’s custody until further notice.
Why this matters:
– The on-chain hash plus the wallet screenshot ties the physical transfer to an address controlled by Taxpayer A.
– The bank receipt ties the fiat outcome of the sale to the taxpayer’s banking records, supporting any claim about proceeds.
– The internal transfer’s documentation is necessary to show it was not an on-chain disposal and to explain the token’s subsequent status for any income or capital treatment.
This simplified hypothetical illustrates the kinds of linkages and documents that help create a defensible record. It does not address which tax rules apply or whether any particular entry is taxable.
Questions readers can ask — a due-diligence checklist
The following questions are framed neutrally to help you identify gaps and to prepare materials if HMRC queries transactions. They are not prescriptive advice.
About platform records
– Does the platform offer downloadable CSV/PDF exports of trades, deposits, withdrawals and fees? If so, have you downloaded and archived the relevant files?
– Does each exported record include a transaction ID, platform internal ID, and timestamp? If not, can you preserve supplementary evidence (screenshots or emails) that provides context?
– Does the platform’s export identify internal transfers separately from on-chain withdrawals and deposits?
About on-chain and wallet evidence
– For on-chain transfers, do you have the transaction hashes and destination addresses recorded?
– Can you demonstrate control of an address that received funds (for example, with a wallet software export or hardware wallet confirmation)?
– If tokens moved through intermediaries or decentralised services, do you have supporting records explaining the sequence of events?
About valuation
– For each event where a sterling value is relevant, have you recorded the time and source of the exchange rate used?
– If you used an exchange’s quoted sterling amount, do you retain the platform evidence showing that sterling figure and the underlying token price?
About fiat linkage
– Are bank receipts, payment references and bank statements preserved and linked to platform settlements?
– Do payment references on the bank statement correspond to deposit references shown by the platform?
About transfers and purpose
– Have you annotated transfers to show whether they were internal, withdrawals to a self-controlled wallet, gifts, or transfers to a third party?
– Where transfers had an economic rationale (security, staking, custody), do you have contemporaneous notes or emails that explain the reason?
About preservation and chain of custody
– Where you have edited or compiled summaries, do you retain the original downloads and the derived materials with formula and change histories?
– Have you archived communications with platform support or counterparties that explain unusual transactions?
About reconciling with provider reports
– When CARF or other provider-supplied data becomes available, have you planned a step-by-step reconciliation using transaction hashes and internal IDs?
– If there are unresolved mismatches, have you prepared a concise memo explaining why the mismatch exists and what evidence demonstrates your position?
What this does not mean — correcting common overstatements
CARF reporting by providers does not automatically change the tax status of any transaction. CARF is a data‑collection and reporting framework for providers; it does not itself constitute a tax assessment or alter the rules that determine taxable events [3].
A provider’s report to HMRC is not the same as HMRC having determined your liability. Provider data can prompt enquiries or matches, but the taxpayer remains responsible for supporting their return and for responding to any enquiry [3].
The expansion of regulated activities under the Cryptoassets Regulations and the FCA’s final rules for stablecoin issuance and custody affects firms’ regulatory obligations; it does not, by itself, specify how every individual transaction should be taxed [1][2].
A single export or one-off screenshot is not always sufficient. While a screenshot can be useful as supporting evidence, robust record-keeping typically comprises layered documentation: native exports, bank records, on-chain hashes and contemporaneous notes.
CARF is about provider-to-authority reporting. It does not relieve taxpayers of the obligation to retain records, and it does not remove the need to demonstrate ownership, control and valuation where those facts are contested.
The presence of provider reports does not mean HMRC will automatically open an enquiry in every case. CARF increases the availability of third-party data, and how HMRC uses that data will depend on its internal processes and risk criteria.
How regulatory developments for platforms change the record picture (brief context)
The UK’s financial regulatory framework for cryptoassets changed in 2026 in ways that affect platforms and therefore the records they may hold. The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 passed Parliament on 4 February 2026, and the FCA describes an expanded scope of regulated activities that takes effect from 25 October 2027, covering areas such as custody and market‑abuse arrangements for crypto markets [1]. In parallel, the FCA published final rules and guidance on stablecoin issuance and cryptoasset custody on 30 June 2026; those rules apply to authorised cryptoasset firms from 25 October 2027 onwards [2].
Practical implication (descriptive): as firms become subject to more detailed prudential, custody and disclosure obligations, the record packages they produce for customers may become more comprehensive and standardised. That could make it easier for taxpayers to obtain consistent exports and transaction histories from authorised platforms. However, regulatory changes apply to firms and not to individual taxpayer record-keeping obligations, and the timing of regulatory implementation (from October 2027 for a number of new requirements) is distinct from the immediate CARF reporting timetable [1][2][3].
Responding to an HMRC query — what good evidence enables (descriptive)
If HMRC opens an enquiry, well-maintained records help in several ways:
– Speed: clear exports and reconciliations allow faster responses, which may reduce the duration of an enquiry.
– Focus: a mapped transaction trail narrows the scope of questions to genuine points of disagreement rather than to basic verification of existence.
– Defence: contemporaneous evidence and a documented rationale for valuation or categorisation can strengthen the taxpayer’s position.
– Clarification: where provider CARF data and personal records appear to conflict, a preserved reconciliation and supporting correspondence can show why the taxpayer’s position differs.
These are general outcomes that derive from better documentation; they are not promises of any particular result and do not amount to legal or tax advice.
Conclusion
Good record‑keeping is increasingly important in the UK crypto context because providers will soon be reporting standardised user and transaction data to HMRC under CARF, starting with activity from 1 January to 31 December 2026 and an initial submission window between 1 January and 31 May 2027 [3].
Strong records combine on‑chain identifiers, platform exports, bank and fiat evidence, valuation sources and contemporaneous notes that explain transfers and intentions. Remember that a provider’s CARF report is a reporting duty for firms and is not itself a determination of your tax position [3]. The practical aim of better records is to make it straightforward to reconcile what providers report with what you record, to answer HMRC questions promptly, and to explain the basis for any valuations or classifications you have used.
This article is for general information, not investment, tax or legal advice.
References
FCA, “Overview of our cryptoassets regime policy statements”, 30 June 2026. https://www.fca.org.uk/publications/policy-statements/cryptoasset-regime
FCA, “CP25/14: Stablecoin issuance and cryptoasset custody”, updated 30 June 2026. https://www.fca.org.uk/publications/consultation-papers/cp25-14-stablecoin-issuance-cryptoasset-custody
HMRC, “Reporting cryptoasset user and transaction data”, updated 3 June 2026. https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data
Provider data, provider reports and personal evidence are different records
Provider data, provider reports and personal evidence are different records
This continuation provides editorial context only and is not personalised tax guidance. It summarises distinctions drawn in HMRC’s CARF material between (a) the information cryptoasset service providers are required to collect; (b) the subset of that information which providers report to HMRC under CARF; and (c) the documents a person might retain as a general evidence trail for their own record keeping decisions.
HMRC guidance on what providers must collect and what they must report is explicit in scope. The “Collecting cryptoasset user and transaction data” guidance states that service providers must collect certain user and transaction data under CARF. For individual users, the guidance lists name, date of birth, home address, country of residence, a National Insurance number or UTR for UK residents, and a TIN plus issuing country for non-UK residents where applicable. For each relevant transaction, it lists value, type of cryptoasset, type of transaction and number of units. The guidance also notes that providers need to verify information through due diligence: https://www.gov.uk/guidance/collecting-cryptoasset-user-and-transaction-data.
HMRC’s “Reporting cryptoasset user and transaction data” guidance explains that although providers must collect details of all users, they report only those users who are tax resident in the UK or another CARF jurisdiction. For reported users, providers submit the user details and a summary of transactions. The same guidance sets the first CARF reporting window: the first report is submitted between 1 January 2027 and 31 May 2027, giving details for 1 January–31 December 2026: https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data.
For readers who want a single entry point to HMRC’s public material on cryptoassets, HMRC’s Cryptoassets collection groups official guidance for individuals, employers, service providers and the Cryptoassets Manual: https://www.gov.uk/government/collections/cryptoassets.
No-advice statement
This is editorial context only. It is not tax, legal, financial or investment advice. The material below describes what HMRC’s public CARF guidance says providers must collect and report, and suggests neutral document-management prompts a reader may consider for their own records. It does not prescribe an individual tax position, calculate tax, interpret any particular transaction, or assert that any particular document will satisfy HMRC in an enquiry.
A neutral way to organise an evidence trail
The following is a neutral set of document-management prompts rather than a checklist mandated by HMRC. A reader may use prompts like these to form a personal filing approach. These prompts deliberately avoid specifying which documents to keep or for how long; they are phrased as questions a reader may consider when developing their own file structure.
Scope: Which years or date ranges do you want a single index to cover? A reader may choose to group items by tax year, by calendar year, or by the 2026 activity period referenced in HMRC reporting guidance.
Categories: What top-level folders or labels will you use? Possible labels a reader may consider include communications from providers, account exports, identity-verification proofs, and an index or summary file. A reader may choose a label or index for their own files that makes sense to them.
File naming: What consistent naming convention will you use so similar items sort together? A reader may choose date-first names, short codes for provider names, or numbered tickets for correspondence.
Index file: Will you maintain a single short index (a plain-text or spreadsheet summary) that records where key items are stored? A reader may choose to keep a one-line index entry per item to reduce search time.
Version control: If an item is updated or corrected, how will you store earlier and later copies? A reader may choose to keep both versions with a note of the change in the index.
Retention decisions: What personal retention horizon will you set? HMRC guidance does not prescribe a specific personal checklist beyond the guidance for providers; a reader may choose their own retention periods and archival rules.
What exported platform data can and cannot establish
HMRC CARF guidance separates what providers must collect from what providers report.
Under the collecting guidance, providers must gather user-identifying data and transaction-level data as listed above. Under the reporting guidance, providers report only users tax resident in the UK or another CARF country and provide those users’ details along with a summary of transactions. These are the anchored facts to bear in mind when you assess any platform export or account record: the collecting guidance identifies the data elements that a provider must obtain; the reporting guidance identifies which users and what data are submitted to HMRC: https://www.gov.uk/guidance/collecting-cryptoasset-user-and-transaction-data and https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data.
When considering what an exported file, a screenshot or a provider communication might show, a neutral way to approach the review is to pose document-management questions rather than assert what the export establishes. Examples of neutral questions include:
Does the file contain fields corresponding to the user-identifying data listed in HMRC’s collecting guidance (name; date of birth; home address; country of residence; NI number or UTR for UK residents; TIN plus issuing country for non-UK residents where applicable)?
For transactions, does the file surface the data elements HMRC lists as transaction-level collection requirements (value; type of cryptoasset; type of transaction; number of units)?
Is there an accompanying note or communication that states the provider has undertaken due diligence or identity verification for the account, as the collecting guidance says providers must verify information through due diligence?
If you prepare a personal index or summary, does it reference the source file name and the provider’s name so you can find the original export later?
These prompts let a reader consider whether an export or a message contains the categories of data HMRC says providers must collect and report, without asserting that any given export includes specific fields. They also make clear that providers collect information on all users but report only those who are tax resident in the UK or another CARF jurisdiction, with the first CARF report covering the 2026 calendar year and due in the 2027 window highlighted above: https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data.
A calendar view of 2026 activity and the 2027 provider-reporting window
For editorial clarity, the HMRC reporting timetable that applies to the first CARF submission is straightforward in the guidance: the first report is submitted between 1 January 2027 and 31 May 2027, giving details for 1 January–31 December 2026. The table below presents that single fact in compact form to help a reader frame any file-sorting or calendar notes for the 2026 year.
Item
Relevant date(s)
Activity window covered by first CARF report
1 January–31 December 2026
First CARF reporting submission window
1 January–31 May 2027
If a reader wishes to keep a calendar-based folder for 2026, these are the two anchored dates from HMRC’s reporting guidance to note. For more background on the evolving UK regulatory framework that surrounds these reporting obligations, OGM has explanatory coverage at https://onegenerationnews.com/crypto/uk-crypto-regulation-2026/ and related pieces on custody and stablecoins at https://onegenerationnews.com/crypto/crypto-custody-uk/ and https://onegenerationnews.com/crypto/fca-stablecoin-rules-explained/.
Questions to reserve for official guidance or a qualified adviser
The items below are neutral prompts a reader may keep in mind when deciding what to ask HMRC’s published material or a qualified adviser. They are intentionally broad and framed as questions to pursue with official guidance or a professional, rather than as solutions or recommendations.
Does HMRC’s published CARF material address whether a specific document type is acceptable in my circumstances, or should I consult HMRC’s published collections for more detail? Start at HMRC’s Cryptoassets collection: https://www.gov.uk/government/collections/cryptoassets.
If a provider tells you it has reported certain users or transactions under CARF, where in HMRC’s reporting guidance can you confirm the timing and scope of those reports? The reporting guidance sets out the scope and the first reporting window: https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data.
Are there particular verification or due-diligence statements from a provider that you should request or retain as part of your personal file? The collecting guidance notes providers need to verify information through due diligence: https://www.gov.uk/guidance/collecting-cryptoasset-user-and-transaction-data.
What are the official HMRC routes for clarifying record-keeping questions in relation to CARF or cryptoassets more generally? Consult HMRC’s published guidance linked above and consider whether an adviser with appropriate professional credentials can address your specific facts.
These are suggested question-areas to pursue with HMRC’s material or a qualified adviser if you need tailored input. They are not a substitute for following the official guidance documents themselves or for seeking professional assistance in a particular situation.
End of editorial continuation. For HMRC primary guidance cited above, see the collecting guidance at https://www.gov.uk/guidance/collecting-cryptoasset-user-and-transaction-data, the reporting guidance at https://www.gov.uk/guidance/reporting-cryptoasset-user-and-transaction-data, and the general Cryptoassets collection at https://www.gov.uk/government/collections/cryptoassets.
