Crypto Tax Records and Reconstruction

Introduction

A tax computation is a function of a record. Change the rules and the answer moves; lose the record and there is no answer to move.

That ordering is worth stating because most crypto tax writing inverts it, treating records as the boring prerequisite to the interesting part. In practice the rules are well documented and largely settled, while the records are where real positions actually break — and the breakage is rarely dramatic. It is a missing acquisition price from four years ago, on a venue that no longer exists, for units still sitting in a holding.

This page covers three things in order: what a record has to contain to support the computations elsewhere in this cluster, how to rebuild one that is incomplete, and what the reporting obligations now falling on providers mean for a holder whose figures will increasingly be checkable against a second source.

Three claims run underneath all of it. The first is about completeness. A record is complete when it answers the same three questions about any unit you hold: where it came from, what it cost, and where it has been since. If one of those cannot be answered for one unit, the record is not complete for the holding that unit sits in, however tidy the rest of it looks.

The second is about which field fails. It is almost always the cost, and specifically its value in your own currency at the time of the event. That is a fact about a moment rather than a fact about a transaction, and exchange exports are built to describe transactions. Nothing in a file of trades records what a token swap was worth in sterling at half past two on a Tuesday afternoon.

The third is about timing. The moment you most need a full history tends to be the moment it is hardest to obtain — a venue withdrawing from your market, an account restricted, an interface taken down. One such withdrawal is worked through below, and its sequence is the part worth learning rather than the name of the company it happened to.

What this page deliberately does not do is rank the software category. Tools matter, and a section below sets out what they fix and what they cannot fix, but a guide that names this year's products is a guide that goes stale on somebody else's schedule. The durable content is the shape of the record, and that has not changed.

The computations themselves live elsewhere — the UK crypto tax reporting rules for pooling and matching, the taxable events guide for which transactions count.

What a Complete Record Contains

"Keep good records" is advice that survives contact with nothing. A useful specification comes from working backwards: what does each computation in this cluster need, and what is the union of those requirements?

Acquisitions

For every acquisition: the date, the quantity, the consideration in your own currency, and the venue or address where it happened. The last of those is the one most often omitted and it is not optional — a per-account system needs it to compute at all, and a pooling system needs it to prove the pool is complete.

Acquisitions also include the ones that were not purchases. Tokens received from a fork, an airdrop, staking, or as payment all enter a holding with a cost, and a record that captures only trades will have units with no origin.

Disposals

For every disposal: the date, the quantity, and the consideration — which for a swap is the value of what you received rather than a cash amount. Where a selection system applies, add the identification made and the time it was made.

Movements that are not either

Transfers between your own addresses are not disposals, but they are events your record must contain, because they move units between accounts and therefore between basis histories. A record that shows only buys and sells cannot answer which account held what at the moment of a sale.

Costs attached to the event they belong to

Fees, commissions and network charges belong to the transaction they were incurred on, not aggregated into an annual total. Aggregation loses the attachment, and the attachment is what makes them deductible against the right disposal.

The test that tells you whether a record is complete

One check is worth applying to any record before relying on it, and it is more reliable than any impression of tidiness. Take every asset you currently hold and ask whether the record explains how each unit arrived and what it cost. Then take every disposal in the record and ask whether the units it consumed were ones the record had previously acquired.

A record that passes both is complete in the only sense that matters, whatever form it is kept in. A record that fails either has a specific, locatable gap — and which of the two tests failed tells you immediately whether the missing events are acquisitions or disposals, which is the first thing any reconstruction needs to establish.

The Field That Goes Missing First

Across every reconstruction problem we have looked at, one field is missing more often than all the others combined: the value in your own currency at the moment of the event.

Why exports omit it

Because the venue had no reason to record it. An exchange matching a token-for-token trade knows the quantities of both assets precisely and has no particular interest in what either was worth in sterling or dollars at that instant. Its export reflects what its systems cared about.

For a fiat-denominated purchase the figure is there, because money moved. For everything else — swaps, rewards, fees paid in tokens — it frequently is not.

Why recovering it later is expensive

Reconstructing a historical value means choosing a price source, choosing a timestamp convention, and applying both consistently across potentially thousands of events. It is possible, and it is the single most laborious part of any reconstruction.

It is also approximate in a way that compounds. Each reconstructed figure lands in two places — as the consideration for one disposal and as the acquisition cost of whatever was received — so an approximation does not stay contained to the transaction it came from.

The cheap alternative

Capturing the figure once, at the time, costs almost nothing. This is the least glamorous recommendation on this page and by some distance the highest-value one: whatever else your record does, make sure it captures the value in your own currency at the moment of every event that is not a fiat purchase.

Exporting While You Still Can

Most venues let you export your trading and transaction history. Most also limit how far back that export reaches, change the format periodically, and — the case that actually hurts — stop offering it entirely when your account or their service ends.

The argument for exporting on a schedule

An export you take today is a record you control. An export you plan to take when you need it depends on the venue still existing, still serving your market, still holding data of that age, and still offering the feature.

None of those is guaranteed, and the correlation is unhelpful: the moment you most need a full history is often the moment something has gone wrong with the venue that holds it.

What to take, and from where

The full transaction record rather than a summary — trades, deposits, withdrawals, fees, rewards and any staking or earn activity, each as its own row. A profit-and-loss summary produced by a venue is that venue's arithmetic over its own partial view, and it is not a substitute for the underlying rows.

Among the venues in general use, Kraken provides a full account-history export covering trades and transfers, which is the shape you want. Note the general point rather than the specific one: what matters is that an export contains individual events with dates, quantities and — where the venue records it — the value at the time.

One market-specific note

Binance stopped accepting new UK users on 16 October 2023, and on 24 June 2026 it withdrew its application for a MiCA licence in the EU — so if your trading history sits there, export the full transaction record rather than assuming the account stays available to you.

Bybit is not authorised, registered or regulated by the Financial Conduct Authority; as at September 2026 its UK service operates under the financial-promotions regime, with promotions approved by Archax Ltd. Cryptoasset services on it are not covered by the Financial Services Compensation Scheme or the Financial Ombudsman Service. The same export advice applies, for the same reason.

When an Exchange Closes or Leaves Your Market

This is the scenario that turns a records problem into a deadline, and a recent example shows the shape of it precisely — including a detail that most summaries of such events get wrong.

What happened with Gemini in the UK, EEA and Australia

Gemini announced that it was closing all customer accounts in the United Kingdom, the European Economic Area and Australia, with an effective date of 6 April 2026. Note "all customer accounts" — the announcement did not narrow it to retail.

The sequence matters more than the end date. Accounts went withdrawal-only from 5 March 2026 for the UK and EU, with deposits stopping the same day. Selling was disabled from that date.

What that sequence actually meant for holders

It means the window to sell closed a month before the window to withdraw did. A holder who wanted fiat had to act before 5 March; after that the only route out was to move the assets elsewhere.

That distinction is routinely lost. It is tempting to describe the period between 5 March and 6 April as a window in which holders were forced to dispose of assets — and that description is wrong, because no disposal was possible on the platform during it. There was no forced sale, because there was no sale available.

Nor did the closure itself crystallise anything. Withdrawing crypto to your own wallet is not a disposal, because beneficial ownership was retained throughout — the test set out on our UK crypto tax reporting rules.

The records lesson from it

A market exit gives you a date by which your history has to be off the platform, and that date is usually earlier than the date the accounts close. Treat any announcement of this kind as a prompt to export immediately rather than to plan an orderly exit, because the features you need may be withdrawn in stages and the export function is not always the last to go.

Rebuilding From What Remains

Suppose the record is already incomplete. A venue is gone, an export stops short, a period is simply missing. Reconstruction is possible, and it is worth approaching in a specific order because doing it in the wrong order wastes most of the effort.

Establish what you are missing, before filling anything

The first task is an inventory of gaps rather than an attempt to close them. Which assets, which periods, which venues — and crucially, which of the missing events are acquisitions, because a missing disposal and a missing acquisition cause very different problems.

A missing acquisition leaves units in your holding with no cost, which understates cost and overstates every subsequent gain. A missing disposal leaves a taxable event unreported. The first is expensive to you; the second is a different kind of problem, and knowing which you have shapes everything after.

Work from the strongest evidence outward

Bank and card statements are frequently the most reliable surviving source for fiat purchases, because your own financial institution retains them independently of any crypto venue. They establish dates and amounts even when the venue record is gone.

Email confirmations are the next layer — many venues sent trade and withdrawal confirmations, and an archived mailbox often contains a more complete history than the venue itself now offers. After that comes chain data, which is covered below and is less useful than people expect.

Record what you could not establish, as its own item

This is the step most often skipped and it is the one that makes the rest defensible. Where a figure could not be recovered, write down what is missing, what you tried, and what assumption you used in its place.

A reconstruction with a documented gap and a stated assumption is a considered position. The same reconstruction with the gap silently filled looks identical in the spreadsheet and is much harder to stand behind, because nobody — including you, later — can tell which figures were recovered and which were estimated.

Two Different Things Called Reconstruction

Search for crypto reconstruction and most of what you find is about something else entirely, which is worth flagging before it wastes your time.

Recovering access

The larger body of writing concerns key recovery: restoring a wallet from a seed phrase, dealing with a damaged backup, reconstructing access to a self-custodied holding. That is a security and operational problem, and the guidance on it is about private keys, passphrases and backup discipline.

It is genuinely important and it is covered separately in our seed phrase backup and recovery guide. It has nothing to do with this page.

Recovering history

This page is about the other one: rebuilding the record of what happened, for a holding you can still access perfectly well. You have the wallet, you have the tokens, you have full control — and you cannot say what you paid for them.

The two problems are unrelated in cause and in remedy. A perfect backup regime protects your access and preserves nothing about your acquisition prices. Conversely, a complete transaction history is of no help whatsoever if the keys are gone.

And they can both bite at once

Worth noting because the combination is common: a holder who moved assets to self-custody early, kept the keys carefully, and never recorded what the tokens cost. Access is secure and the tax position is unknown, which is exactly the shape where people assume the chain will tell them and find that it does not.

Self-Custody Creates Records Nobody Else Keeps

Moving assets out of an exchange and into a wallet you control is good security practice. It also transfers the entire record-keeping burden onto you, and that half of the trade is discussed far less often than the first.

What you stop receiving

A custodial venue maintains a history whether you engage with it or not. Once assets are in self-custody there is no statement, no export, no annual summary and no counterparty with an interest in recording what anything cost.

Blockchain records what moved. It does not record what you paid, which account the units came from, or which address in the transaction is yours — and a hardware wallet manufacturer holds none of that either, by design.

What you have to create instead

At minimum, a note for each movement into or out of self-custody: the date, the quantity, which of your addresses is involved, and where the units came from or went. Without the last of those, a transfer that was not a disposal becomes indistinguishable from one that was.

For a multi-signature or shared-control arrangement, add who else can authorise a movement — because beneficial ownership is the test that decides whether a transfer was a disposal, and a shared-control setup is precisely where that question stops being obvious.

A tension worth naming

Good security practice discourages writing down anything that links your identity to your addresses. Good record-keeping requires exactly that link, because a tax position is a statement about your holdings.

The resolution is not to abandon either. It is to keep the tax record with the same care you apply to any other sensitive financial document — encrypted, backed up, and separate from anything that would let someone move the assets. The record tells someone what you own; it does not let them take it.

It is worth being precise about that last distinction, because conflating the two leads people to keep no record at all. A seed phrase or private key is an instrument of control: whoever holds it can move the assets, which is why the advice around it is so restrictive. A transaction history is an instrument of evidence: it establishes what happened and what it cost, and possessing a copy confers no ability to spend anything. They warrant different handling because they create different risks, and treating a spreadsheet of dates and prices with the paranoia appropriate to a recovery phrase usually ends in there being no spreadsheet.

What Chain Data Can and Cannot Tell You

Public ledgers feel like the obvious answer to a missing history: everything is recorded, permanently, and anyone can read it. In practice chain data answers a narrower set of questions than reconstruction needs.

What it gives you reliably

Quantities, addresses, timestamps and the fact that a transaction occurred. For on-chain activity these are authoritative and complete in a way no venue export is.

What it does not give you

• The value in your own currency. A ledger records that tokens moved, not what they were worth. That figure has to come from a price source applied afterwards, with all the approximation that involves.
• Anything that happened inside a venue. Trades executed on a custodial platform are internal database entries, not chain transactions. A large part of a typical history is simply not on any ledger.
• Whose address it is. A transfer between two addresses you control and a transfer to somebody else look identical on-chain. The distinction decides whether a disposal occurred, and only you can supply it.
• The terms of an arrangement. Whether beneficial ownership passed in a lending or liquidity position is a contractual question, and no amount of chain analysis answers it.

Its actual role in a reconstruction

Chain data is best used as a completeness check rather than as a primary source. It tells you that a movement happened on a date, which lets you find the gap in your other records and ask what that movement was — and it is very good at revealing events you had forgotten entirely.

Used that way it is genuinely valuable, and the value is asymmetric in a helpful direction. Chain data reliably tells you that something happened which your record does not mention, and it almost never tells you that something in your record did not happen. So a discrepancy between the two is nearly always a gap in your record rather than an error in it, which makes the comparison a fast way to find missing events without casting doubt on the ones you already have.

Why Several Venues Make This Harder Than the Sum of Its Parts

A holder using one exchange has a records problem that scales with transaction count. A holder using five has a different problem, and it is not five times the first one.

The difficulty lives at the seams

Each venue produces an internally consistent history of what it saw. Every one of them is complete about its own activity and silent about the transfers in and out that connect it to the others.

So a stack of five exports does not assemble into a history. It assembles into five histories with gaps between them, and the gaps are precisely the movements that decide whether units carried cost from one place to another.

What a merge actually requires

Matching a withdrawal on one venue to a deposit on another, by asset, quantity and time — allowing for the fee deducted in between, which means the quantities will not match exactly. That work has no shortcut and it is where most of the effort in a multi-venue reconstruction goes.

It is also where tooling is most valuable and most likely to be quietly wrong. A tool that fails to match a withdrawal to its corresponding deposit will usually treat one as a disposal and the other as a zero-cost acquisition, which is wrong twice in the same direction.

The check that catches a bad merge

Compare what the merged record says you hold against what you actually hold. They should agree, per asset, and where they do not the discrepancy points straight at an unmatched transfer.

It is a five-minute check that catches the most consequential class of error in any reconstruction, and it works regardless of which tool or method produced the record. Run it after every merge rather than once at the end, because an unmatched transfer discovered immediately is a single correction, while one discovered after several more venues have been folded in is a puzzle.

The Software Category, and What It Does Not Solve

A category of tools exists to import exports, apply a jurisdiction's rules and produce figures. They are genuinely useful and we have no commercial relationship with any of them — no referral arrangements, no tiering, and nothing on this site earns anything from naming one.

We keep a separate overview of the tooling landscape in our crypto tools overview, and this page deliberately does not duplicate it. What belongs here is narrower: what such tools do and do not fix about a records problem.

What they fix

Volume and arithmetic. Applying pooling or selection rules across thousands of events, attaching fees to transactions, and producing a consistent set of figures is exactly the kind of work software is good at and humans are not.

What they cannot fix

Missing data. A tool cannot know what you paid for units it has no acquisition record for, and its output in that situation is not an answer — it is a default, often a zero cost, which silently maximises your reported gain.

They also cannot decide the questions that depend on documents rather than transactions: whether beneficial ownership passed, whether a transfer was between your own addresses, whether a particular arrangement was a disposal. Those are inputs you supply, and a tool that appears to have decided them has guessed.

A note on names, because they change

One product in this category is now called Summ, formerly Crypto Tax Calculator; the rebrand landed in late 2025, the entity and the engine are the same, and the redirects are live, so older references to the former name still resolve. Two others belong in the past tense. Accointing was acquired and its platform shut down in January 2024, absorbed into another product. Taxbit exited the consumer market in 2023 and continues as an enterprise business.

The general lesson matters more than the specific names. Tooling in this category changes hands, rebrands and exits more often than most software, and a tool holding the only copy of your reconstructed history is a single point of failure. Keep your own export of whatever a tool produces for you.

Staking, Yield and the Records They Generate

Rewards arriving from staking or a yield protocol are acquisitions, and they are the acquisitions most likely to be missing from a record entirely — because nobody bought anything and no transaction felt like a decision.

What each receipt needs

A date, a quantity, and a value in your own currency at the moment of receipt. That value does two jobs: it may be relevant to an income question at the point of receipt, and it becomes the acquisition cost of those units for whatever disposal eventually takes them.

Miss it and the units enter your holding with no cost at all, which overstates every subsequent gain they contribute to. The income and capital sides of reward treatment are covered separately in our yield and staking taxation guide.

The frequency problem

A validator or protocol distributing rewards frequently can generate hundreds or thousands of individually tiny acquisitions in a year. Recording each one at its moment of receipt is not realistic by hand, and this is the clearest case where tooling earns its place.

What matters is that the tooling captures value at receipt rather than at year end. A reward stream valued at a single date is a materially different record from one valued event by event, and only the second supports the computations that follow.

Where the record gets genuinely awkward

Some arrangements deliver rewards by increasing a balance rather than sending a transaction, and others by increasing the value of a token whose quantity never changes. Neither produces a discrete receipt to record.

There is no clean general answer, and this page will not invent one. What it can say is that the record should capture what actually happened — quantity changes with dates where balances move, and the entry and exit values where they do not — because a record of the mechanism is recoverable later and a record of an assumption about it is not.

What a DeFi Protocol Does Not Give You

A custodial exchange at least intends to keep a history for you. A smart contract has no such intention, and the gap between what it records and what a computation needs is wider than most holders expect.

There is no statement

A protocol produces state, not statements. Your position exists as balances and token holdings, and the sequence of events that produced them lives in transaction history that is public, unlabelled and not organised around you.

Interfaces frequently display a position summary, but that is the interface's reconstruction rather than a record the protocol maintains — and it typically disappears when the interface changes, which happens often.

The fields most often lost

• Gas paid in tokens. Each is both an allowable cost and a disposal in its own right, and neither is captured by a position summary.
• The value of what was received. A liquidity position returns receipt tokens whose sterling value at the moment of receipt is rarely recorded anywhere.
• The terms. Whether beneficial ownership passed depends on the arrangement's documentation, which is not on-chain and is frequently revised.

What to do about it

Capture the terms at the time you enter a position, not when you exit it. A copy of the documentation as it stood when you committed assets is the only evidence of what you actually agreed to, and it is the field this cluster returns to most often because it decides classification rather than merely valuation.

Beyond that, treat every interaction with a protocol as an event needing its own row, including the ones that produced no visible change in your holdings. Which of them were disposals is a question the taxable events guide answers — but only for events you recorded.

Why This Is Becoming Checkable

Until recently, a crypto tax record was something only its owner could see. That is changing, and the change is the strongest practical argument for the rest of this page.

Who is obliged to do what

The reporting duties under the United Kingdom's cryptoasset reporting framework fall on providers, not on individual holders. You do not register for it and you file nothing under it, and any guidance telling individuals to register for it has misread whose obligation it is.

The regulations behind it are SI 2025/744, which commenced on 1 January 2026. That is the commencement of the instrument itself. It is not the date by which providers must be registered, and the two are routinely conflated in secondary coverage.

What you will encounter is a request for a self-certification. gov.uk lists what it covers: name, date of birth, home address, country of residence and, for UK residents, a National Insurance number or Unique Taxpayer Reference. Regulation 13 makes a user who fails to provide one liable to a penalty not exceeding £300 where the failure is deliberate or due to a failure to take reasonable care — a capped and conditioned penalty rather than an automatic charge.

The dates, and which source each comes from

Two primary sources give different answers here, so it matters which is being quoted. gov.uk's operational guidance for providers says that by 31 January 2027 a provider must register with the online service and tell its users it will be reporting their details. Regulation 10(1) of SI 2025/744 sets the statutory registration deadline as the later of 31 May 2027 and the 31 January following the first calendar year in which the provider came within the definition — which resolves to 31 May 2027 for a provider already in scope during 2026.

This page quotes both rather than picking one, because a reader who sees a single date elsewhere may be seeing the other one.

Neither is a deadline for you. What is relevant to a holder is the notification: Regulation 8 requires a provider to tell each reportable user that their information will be reported to HMRC and may be passed to another jurisdiction's competent authority. The notice is due on or before the 31 January following the first calendar year for which that user must be reported, so a UK user whose 2026 activity is reportable should expect it on or before 31 January 2027. The duty is the provider's, not HMRC's.

What it means for a record

It means the computation you file will increasingly sit alongside data about you from another source. That is not a reason for anxiety — a correct computation supported by records is unaffected by being checkable — but it does change the cost of a reconstruction that cannot be explained.

The practical implication is the same one this page has been building towards. A record assembled as you go can be shown to someone. A record reconstructed afterwards, with gaps filled silently, cannot be distinguished from a guess even when it happens to be right.

Starting From Nothing: a Realistic First Pass

Some readers arrive at this subject with several years of activity and effectively no record. That situation is common enough to deserve a practical answer rather than an admonition.

Do not start at the beginning

The instinct is to begin with the earliest transaction and work forward. It is the wrong order, because the earliest records are the hardest to recover and abandoning the project halfway leaves you with the least useful half.

Start instead with what you hold now and work backwards. Every unit currently in your possession needs a cost; units you disposed of years ago and no longer hold are a separate and often smaller problem.

A staged approach that survives being interrupted

• 1. Inventory current holdings. Every asset, every venue and wallet, current quantities. This is the only stage that is entirely observable and it anchors everything else.
• 2. Pull every export you can still obtain. All venues, longest range available, full transaction history rather than summaries. Do this before anything else, because availability is the thing most likely to change.
• 3. Mine your own sources. Bank and card statements for fiat purchases, archived email for trade confirmations. These are under your control and do not expire with a venue.
• 4. Reconcile against current holdings. If the record explains what you hold, the gaps are in disposals. If it does not, the gaps are in acquisitions — which is the more expensive kind.
• 5. Document what remains unknown. Named gaps with stated assumptions, not silent estimates.

Each stage produces something useful on its own, which matters because a reconstruction that is abandoned at stage three is still worth more than one that never started.

When this stops being a self-service problem

If the inventory at stage one cannot be reconciled with the record at stage four — you hold units your history cannot account for — that is the point to involve a professional rather than to estimate. The same applies where a gap sits on a substantial holding, or where the arrangements involved are the kind whose classification depends on documents you no longer have.

A Minimum Viable Record

If you take one thing from this page and implement nothing else, this is the shape worth having. It is deliberately modest — a spreadsheet satisfies it — and it supports every computation elsewhere in this cluster.

• One row per event, including transfers between your own addresses and events that produced no visible change in a balance.
• Date and time, in a consistent timezone, because tax years and thirty-day windows are decided on dates.
• Quantity and asset, exactly as it moved rather than rounded.
• Value in your own currency at the moment of the event, for everything that is not a fiat purchase. The field exports omit and the one most expensive to recover.
• Venue or address, at both ends where a transfer is involved.
• Fees, attached to the event they belong to, with the asset they were paid in.
• Any identification made, and when — only where a selection system applies to you.
• A note for anything unusual: the terms of an arrangement, why a transfer was made, what a receipt was for.

Why this shape rather than a tidier one

Because it records events rather than conclusions. A record organised around positions, or around annual totals, has already made decisions about classification and valuation — and if any of those decisions turns out to be wrong, the underlying facts needed to redo them are gone.

An event log can always be summarised later. A summary can never be expanded back into the events it came from, which is why the least processed form is the most durable one.

How Long to Keep It

Retention periods for tax records are set by jurisdiction and by circumstance, and this page does not state a figure for yours — that is a question with a specific answer that depends on whether you file a return, what kind, and whether an enquiry is open.

The crypto-specific point that changes the calculation

What is worth saying here is structural, and it is one many readers get wrong. A general retention period is measured from the tax year a transaction was reported in. A cost basis record has to survive until the units it relates to are disposed of — which may be many years later, and may be after any ordinary retention period has expired.

Units bought in 2018 and still held in 2030 need their 2018 acquisition record in 2030, because that is the year the cost will be relieved. A retention policy built around "keep seven years of records" quietly discards exactly the documents a long-term holding depends on.

The rule that actually follows

Keep acquisition records for as long as you hold the asset, and then for whatever period applies after the disposal is reported. Treat the two as additive rather than as alternatives.

For a long-term holder that means an acquisition record is effectively permanent, which is a modest storage cost and a large saving in the reconstruction it prevents.

The same reasoning extends to anything a disposal will eventually depend on, which is a wider set than acquisition prices alone. Documentation establishing that a transfer moved units between addresses you controlled, the terms under which a position was entered, and the apportionment reasoning behind a fork all fall into it — none of them matters until a disposal happens, and all of them become extremely difficult to reproduce once the surrounding context is gone.

Conclusion

Records are the part of crypto tax that everything else rests on, and they fail differently from the way people expect. Not through catastrophe but through absence: a venue that left the market, an export that stopped short, a swap whose sterling value nobody wrote down.

Three habits address most of it. Export full transaction histories on a schedule rather than when you need them, because the moment you need one is often the moment it is hardest to get. Capture the value in your own currency at the time of every event that is not a fiat purchase, because that is the field exports omit and the one most expensive to recover. And keep acquisition records for as long as you hold the asset, not for whatever period a general retention rule suggests.

Where reconstruction is unavoidable, its order matters: inventory the gaps first, work outward from the evidence you control — bank statements, archived confirmations — and write down what you could not establish rather than filling it silently. A documented assumption is a position; an undocumented one is indistinguishable from a guess.

And the context has changed. With providers now obliged to report on the users they serve, the figures you file will increasingly sit beside a second account of the same activity. That makes a record you can explain worth considerably more than one that merely produces a number.

One closing caution about reconstruction itself. The work has a natural stopping point, and it is not the same as being finished: it is the point where the remaining gaps are small enough to describe rather than close. Describing them is a legitimate output. Closing them with a plausible figure and leaving no mark that it was chosen rather than found is not — that turns a known uncertainty into an invisible one, and only the invisible kind is dangerous.

Sources

Cited by identifier and the date read. Where two primary sources give different dates for the same obligation, both are given above with the source of each named.

• Check if you'll need to report cryptoasset data to HMRC — the provider-side operational guidance and its registration date. Read 21 September 2026. gov.uk
• The Cryptoasset Service Providers (Due Diligence and Reporting Requirements) Regulations 2025, SI 2025/744 — regulations 8, 10 and 13, covering user notification, registration and the self-certification penalty. Read 21 September 2026. legislation.gov.uk
• HMRC Cryptoassets Manual, CRYPTO22100 — retained beneficial ownership and movements that are not disposals. Read 21 September 2026. gov.uk
• Gemini's own announcement of account closures in the United Kingdom, the European Economic Area and Australia, and the Financial Conduct Authority's news story on the exit. Read 21 September 2026. fca.org.uk
• Self-custody removes the venue that would otherwise keep your records, which is a security decision before it is a tax one. The security side is covered in our hardware wallet security guide.
• What the records are ultimately for: the same ledger run through four approaches, with the arithmetic shown, in our method comparison.
• Why these records exist and what each computation does with them is set out in our complete crypto tax guide.

Frequently Asked Questions

What does a complete crypto tax record actually need to contain?

For every acquisition: date, quantity, consideration in your own currency, and the venue or address it happened at — including acquisitions that were not purchases, such as forked tokens, airdrops and staking rewards. For every disposal: date, quantity and consideration, which for a swap is the value of what you received. Plus transfers between your own addresses, which are not disposals but move units between basis histories, and fees attached to the individual transaction rather than aggregated annually.

What is the single most common missing field?

The value in your own currency at the moment of the event. Exchange exports record quantities and counterparty assets reliably and the sterling or dollar equivalent inconsistently, because the venue had no reason to capture it. Recovering it later means choosing a price source and a timestamp convention and applying both across every affected event, and each reconstructed figure lands twice — as the consideration for one disposal and as the acquisition cost of whatever was received.

Was there a forced disposal window when Gemini closed UK accounts?

No, and this is the detail most summaries get wrong. Gemini closed all customer accounts in the United Kingdom, the European Economic Area and Australia effective 6 April 2026, but accounts went withdrawal-only from 5 March 2026 with selling disabled from that date. The sell window therefore closed a month before the accounts did, so no disposal was possible on the platform between those dates. Withdrawing crypto to your own wallet is not a disposal, because beneficial ownership is retained.

Can I rebuild a crypto history from blockchain data alone?

Only partially. Public ledgers reliably give quantities, addresses and timestamps for on-chain activity, but they do not give the value in your own currency, they contain nothing that happened inside a custodial venue, they cannot distinguish a transfer between your own addresses from a transfer to somebody else, and they say nothing about the terms of a lending or liquidity arrangement. Chain data works best as a completeness check that reveals events you had forgotten, rather than as a primary source.

Do I have to register for the UK cryptoasset reporting framework?

No. The registration and reporting duties fall on cryptoasset service providers rather than on individual holders, so a UK user registers for nothing and files nothing under it. Your obligation is to give your provider a valid self-certification when asked, covering name, date of birth, home address, country of residence and, for UK residents, a National Insurance number or Unique Taxpayer Reference. Failing to do so can attract a penalty not exceeding £300 where the failure is deliberate or careless.

How long should I keep crypto acquisition records?

Longer than a general retention period suggests, because the two are measured differently. An ordinary retention period runs from the tax year a transaction was reported in, but a cost basis record must survive until the units it relates to are disposed of — which for a long-term holding may be many years later. Units bought in 2018 and still held in 2030 need their 2018 acquisition record in 2030, so treat the holding period and the post-disposal retention period as additive.

Will crypto tax software fix an incomplete history?

No. Software handles volume and arithmetic well — applying pooling or selection rules across thousands of events, attaching fees to the right transactions — but it cannot know what you paid for units it has no acquisition record for. Its output in that situation is a default rather than an answer, often a zero cost, which silently maximises the gain reported. It also cannot decide questions that depend on documents rather than transactions, such as whether beneficial ownership passed in a particular arrangement.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.