Kraken Tax UK — How to Report Your Kraken Trades to HMRC

Kraken is one of the most widely used centralised exchanges in the UK, and a long-time favourite of investors who want deeper order books, margin trading, and a wider range of fiat pairs than most competitors. It is also one of the trickiest exchanges to file UK tax for — not because the trades themselves are complicated, but because Kraken's ledger format carries quirks from its early years that most tax tools either mishandle or quietly ignore.

The data is all there in your Ledgers CSV. What goes wrong is the translation. Asset names like XXBT and ZEUR need to be normalised to canonical tickers. Staking suffixes (ETH.S, DOT.S) belong in the same Section 104 pool as the underlying token. Trades arrive as paired rows that must be matched on a reference ID. Margin and futures positions sit outside the ordinary CGT framework. And EUR or USD pairs need historical fiat conversion before any cost basis is meaningful.

This guide walks through how Kraken transactions are taxed under HMRC rules, which export to use, what the asset-name quirks actually mean, and what ChainTax does with each row when you import it. It also flags the cases where automation honestly cannot help — and where a manual entry is the right answer.

Does Kraken report to HMRC?

Yes. From 1 January 2026, Kraken — like every other crypto exchange operating in the UK — reports your full transaction history to HMRC under the Crypto-Asset Reporting Framework (CARF). The first automatic data exchange covers calendar year 2026 and is expected to land with HMRC in May 2027. What HMRC receives is transaction-level: every acquisition, disposal, and income event tagged to your name, address, and tax identification number.

Even before CARF, Kraken has responded to HMRC data requests. HMRC has already sent over 100,000 warning letters to UK crypto holders, many seeded from exchange-supplied lists. The practical implication is straightforward: your Self Assessment needs to match what Kraken has already reported. CARF is not a notice that reporting is coming. It is a notice that the cross-reference is already running.

Which Kraken export to use — Ledgers, not Trades or Tax

Kraken offers several different exports, and most users start with the wrong one. The right choice for UK tax is Ledgers, not Trades, and emphatically not the built-in Tax tool.

• Trades CSV. Contains spot fills only. Misses deposits, withdrawals, staking rewards, transfers between Kraken accounts, and fees that are charged outside the trade pair. Useful for active-trader spreadsheets, useless for HMRC.
• Tax tool / Profit & Loss export. Uses FIFO cost basis matching, which is correct under US tax rules but wrong for UK investors. HMRC requires Section 104 pooling. Cost basis figures from this export will not reconcile with your SA108 return.
• Ledgers CSV. The complete record. Every spot trade, deposit, withdrawal, staking reward, Earn allocation, and fee in one file, with reference IDs that link paired rows. This is the file ChainTax expects, and the file HMRC's rules can be applied to.

To export it, log in to Kraken on desktop, go to History → Export, choose Ledgers, set the date range to cover your full Kraken history (do not stop at the current tax year — the pool depends on every prior acquisition), and download the CSV.

Kraken's asset name quirks — XXBT, ZEUR, ETH.S

Kraken uses legacy asset codes inherited from the ISO-4217 convention it adopted in its early years. These codes do not match the tickers anyone trades under today, and if your tax tool does not normalise them, your Section 104 pool will silently split.

The refid pairing — one trade, two ledger rows

Unlike Coinbase (which writes one row per trade), Kraken records every spot trade as two rows in the ledger: one for the asset received (positive amount) and one for the asset sent (negative amount). Both rows share a common refid. A single trade of 5,000 EUR for 0.1 BTC produces:

ChainTax groups rows by refid and rebuilds each trade as a single event with sent / received tokens, fees, and the trade timestamp. Standalone rows that do not pair (occasional Kraken edge cases, manual adjustments) are still treated as buys or sells based on the sign of the amount — nothing is silently dropped.

Kraken transaction types mapped to HMRC

The ledger's type column tells you what each row is. Here is how each type maps to HMRC tax treatment:

Staking, Earn, and Bonded Staking rewards

Kraken's staking products have changed shape over the years — the original Earn programme was paused for UK customers in 2023 in response to FCA rules, and later resumed under the Bonded Staking format. Whatever the product label, the tax treatment is the same:

• Reward receipts are income. The FMV in pounds on the date the reward lands in your account is miscellaneous income for that tax year. It goes on SA100 under "Other income", not on SA108.
• The same FMV becomes cost basis. The reward enters your Section 104 pool at that price. When you eventually sell, that cost basis reduces your CGT gain — so the income tax is partially offset against future capital gains relief.
• Allocation and deallocation are not events. The ledger rows where Kraken moves your balance into a staked or bonded state (subtype: allocation, deallocation) are non-taxable transfers. They are bookkeeping only.

For a deeper treatment of staking across providers, see how to report staking rewards to HMRC.

Margin and futures — where automation honestly stops

Kraken offers margin trading on its spot platform and a separate Kraken Futures platform for perpetuals. Both sit at the edge of what a CSV-based tax tool can do well, and the right answer is different for each.

Spot margin trades appear in the Ledgers CSV with an .M suffix on the asset name (ETH.M, USDT.M). ChainTax strips the suffix and treats the resulting row as an ordinary spot trade — that captures the asset movement in and out of your Kraken spot wallet, which is what HMRC sees as the disposal or acquisition. It does not separately track funding charges or rollover interest as their own line items. For typical retail margin use that approximation is workable, but if you trade margin actively and your funding costs are material, the more accurate treatment under CG56100 is to record each closed position as a single CFD-style realised PnL entry instead. That goes in via a manual entry rather than the CSV path.

Kraken Futures positions do not appear in the Ledgers CSV at all — the Futures platform is a separate product with its own export. There is no row in your Ledgers file that represents a Futures trade. For closed Futures positions, the cleanest answer is to enter realised PnL manually, one entry per closed position, using your Kraken Futures statement.

Fiat conversions for USD and EUR pairs

Kraken is one of the few major exchanges with deep EUR liquidity, and many UK users trade EUR pairs by default. Every disposal and acquisition in the Section 104 pool must be in pounds — HMRC does not accept a pool denominated in euros or dollars.

The conversion needs to use a published spot rate for the day of the transaction, not the day you file. ChainTax uses Frankfurter as the primary feed (which mirrors ECB reference rates) and falls through to ECB's direct XML feed when Frankfurter is unreachable. Both sources are HMRC-acceptable for the "just and reasonable" conversion standard.

Two practical consequences: a EUR-denominated trade in 2021 needs the 2021 EUR/GBP rate, not today's. And if you spread the same trade across two ledger rows on either side of midnight, ChainTax uses each row's own date for its own conversion — the refid pairing rebuilds the trade, but the FX is row-level.

Worked example — EUR pair plus a staking reward

A simplified Kraken history showing the three concepts together: a EUR trade, a staking reward, and a later disposal.

How ChainTax handles Kraken

1. Auto-detect the Ledgers format. Drop the CSV in and ChainTax recognises the Kraken header row (txid, refid, aclass) and routes it to the Kraken parser. If you accidentally upload a Trades or Tax export, the format detector will tell you.
2. Normalise asset names. XXBT, ZEUR, XETH, and the .S / .M suffixes all map to canonical tickers before any pooling. Classified as Acquisition or Disposal at high confidence.
3. Pair trades by refid. Each Kraken trade rebuilt into a single event with sent / received tokens, fees, and the original timestamp.
4. Convert fiat at historical rates. EUR and USD pairs converted to GBP using ECB-published rates for the trade date, not today's rate.
5. Classify rewards as income. Staking rows with subtype reward, plus all earn rows, classified as Income at FMV on receipt — with the same FMV entering the Section 104 pool.
6. Treat spot margin as the underlying disposal. .M-suffixed rows are pooled with the canonical asset — the disposal side captures real asset movement on your spot wallet. Active margin traders should enter realised PnL manually under CG56100; Kraken Futures positions live on a separate platform and require manual entry per closed position.
7. Unified Section 104 across exchanges and DeFi. Combine your Kraken history with Coinbase, Binance, and on-chain wallets. All ETH, all BTC, all USDC sit in one pool per token.
8. SA108 boxes auto-filled. Boxes 13.1–13.8 computed from the unified pool, with every disposal showing its matching rule (same-day, B&B, or S104) and the gain working. Income from rewards is reported separately for SA100.

Kraken alongside other exchanges and DeFi

Single-exchange tax reports fail at the same point regardless of which exchange you use: HMRC requires one Section 104 pool per token across every source you hold it on. ETH on Kraken, ETH on Coinbase, ETH from a Uniswap swap, ETH staked through Lido — all the same pool, weighted average across every acquisition.

The same-day and 30-day Bed & Breakfast rules also apply across sources. Sell ETH on Kraken on Tuesday, buy ETH on Coinbase on Thursday — those events are matched, even though they happened on different platforms. Single-exchange reports cannot see the other side of the trade.

For a fuller comparison of how centralised exchange tax differs from DeFi, see CEX vs DeFi crypto tax in the UK.