If an exchange says I own BTC, is it definitely native BTC on my books?

Not necessarily. It turns on the custody terms, beneficial ownership, reuse rights and legal position: a displayed BTC balance can represent native BTC held for the customer or a contractual claim against the exchange, and SAB 122's rescission of SAB 121 did not decide that for either party.

If I hold the private key, do I automatically own the Bitcoin legally?

The key gives technical spending ability. Legal ownership can turn on agency, employment, trust or theft, so protocol control is evidence, not the conclusion.

Is a right to receive Bitcoin the same asset as Bitcoin?

No. A contractual right to receive equivalent BTC carries credit and insolvency risk that native BTC does not, and under IFRS it is very likely not a financial asset, because IAS 32.11 reaches only cash, an equity instrument of another entity and a right to receive cash or another financial asset. IFRS 9 is probably the wrong home for it, and the IAS 8.10-12 hierarchy applies.

What Do You Own When You Hold Bitcoin? Ownership and Custody

Bitcoin ownership is not settled by the quantity on the screen. Open a portfolio application and it can show five rows that all read BTC, the ticker for the bitcoin unit: self-custody, an exchange-credited balance, a multisignature arrangement, collateral pledged to a lender, and a contractual right to receive 1 BTC back from a borrower.

The quantity is identical in every row. The asset is not, and in an insolvency four of the five behave in ways the screen gives no hint of.

That gap is the substance of Bitcoin ownership and custody analysis, and the first thing an accountant has to settle. Not "how many BTC does the app show?" but:

What asset, right or obligation does the entity actually control under this arrangement?

This article stays on that boundary. Measurement under IFRS and US GAAP is covered separately in this series, but that division of labour is not a sign that recognition is the settled half. It is the other way round. ASC 350-60-05-2 states that the Subtopic "does not address the initial measurement, recognition, and derecognition of crypto assets," which follow other generally accepted accounting principles (FASB ASU 2023-08). IFRS has no cryptoasset standard at all: the IFRS Interpretations Committee routed qualifying holdings to IAS 2 or IAS 38 in June 2019 (IFRIC agenda decision) and went no further. Custody, lending, escrow and collateral sit in that gap, where the boundary is set by the derecognition and control requirements of the applicable asset model, read against the contract and the governing insolvency law.

No standard names a custody arrangement for BTC.

Three screens can all say “BTC” and mean different assets

Asset identification comes before measurement. Ask who can sign, and what the contract actually promises.

Start from the position, not the labelA balance displayed in software tells you nothing about legal rights.
Who controls the private keys?Control of keys is not the same as legal title, and title is jurisdiction-dependent.
What does the contract say?Segregation, insolvency treatment, rehypothecation and return obligations all change the answer.

What the same balance can actually be

Native BTCSelf-custodied. The entity holds the keys.
Claim on a custodianA contractual right, not the asset itself.
Loan receivable in BTCA right to receive a nonfinancial asset.
Pledged or collateralisedControl may be constrained without derecognition.

These conclusions depend on the actual contract and the applicable law. The same software balance can sit in any of these boxes.

Native BTC has no issuer and no redemption claim

Native Bitcoin, the asset recorded on the Bitcoin network itself, is not a share, a bank deposit, a stablecoin redeemable for dollars or a claim on a reserve account. The protocol's founding design document defines a coin as "a chain of digital signatures," passed from owner to owner by signature alone, with no issuer anywhere in the chain (Bitcoin white paper). A holder controlling native BTC directly is owed nothing by anyone.

That drives the classification. The IFRS Interpretations Committee said so in June 2019: a cryptocurrency holding is not cash, because it is not used as a medium of exchange and monetary unit broadly enough for that classification, and it is not a financial asset, because it is neither cash, an equity instrument of another entity, nor a contractual right to receive cash or another financial asset (IFRIC, Holdings of Cryptocurrencies). The financial-asset test is the IAS 32.11 definition, reinforced by IAS 32.AG10: intangible assets "are not financial assets," because control of one "does not give rise to a present right to receive cash or another financial asset" (IAS 32). US GAAP reaches the same place from the scope side: one of the six criteria in ASC 350-60-15-1 is that the asset "do not provide the asset holder with enforceable rights to or claims on underlying goods, services, or other assets," and native BTC satisfies it (FASB ASU 2023-08).

The absence of an issuer removes one kind of risk without making the asset risk free. Market-price risk, key loss, theft, operational failure, title disputes and protocol governance risk all remain, and no counterparty exists to make the holder whole.

Self-custody: keys are evidence of Bitcoin ownership, not the conclusion

In self-custody the holder, or its authorised signing structure, controls the keys needed to spend the relevant outputs. A wallet holds no coins in an account: "Wallet programs create public keys to receive satoshis and use the corresponding private keys to spend those satoshis" (Bitcoin Developer Guide, Wallets). What the holder controls is a set of unspent transaction outputs, or UTXOs, discrete parcels of spendable value each created by an earlier transaction and each spent whole (Bitcoin Developer Guide, Transactions). The entity therefore owns no claim against anyone, unlike a bank deposit: no developer, miner, node or company balance sheet stands behind the position.

Control over those keys and outputs has to be evidenced: wallet descriptors (machine-readable statements of the rules by which a wallet derives its addresses), wallet exports and controlled-address records, key-management documentation, raw transaction history, and governance records showing who can authorise a spend. A block-explorer screenshot is not part of it: that proves an output exists at an address, not that the reporting entity controls it, and Bitcoin Core makes the point from the other direction, since getaddressinfo warns that "some of the information will only be present if the address is in the active wallet" (Bitcoin Core RPC).

Ownership is local knowledge, not chain data.

Nor does holding a key settle the legal question. The protocol asks only whether a transaction carries a valid signature satisfying the output's spending conditions. An employee may possess a company key without owning the BTC, a custodian may hold every signing key while the customer retains beneficial ownership under the contract and applicable law, and a thief may acquire spending power without acquiring title. Technical control and legal ownership must be connected, not conflated. The chain establishes which spending conditions were satisfied, and a node can confirm whether the spending transaction sits in the active chain (Bitcoin Core RPC, getrawtransaction). It cannot adjudicate agency, trust, insolvency rights or corporate authorisation, and holds no registry of legal owners.

Custody can preserve the Bitcoin asset or replace it with a claim

The analysis gets harder the moment BTC is transferred to an exchange or custodian. On-chain, the customer's output is spent and a new output appears under the intermediary's control, which tells you where protocol control moved and nothing about what the customer now owns. Depending on the agreement and the governing law, the customer might retain beneficial ownership of identifiable or segregated BTC, or might hold only a contractual claim for equivalent BTC. Those positions behave very differently in insolvency, usually the only moment anyone finds out which was signed. The deciding questions are contractual, not technical:

Are customer assets segregated, or does the intermediary pool them?
Can the intermediary lend, pledge or reuse the BTC, and does the customer bear market gains and losses?
Can the customer demand specific property back, or only equivalent units, and what does it recover if the custodian fails?

"I have 2 BTC on an exchange" is convenient shorthand and an incomplete accounting statement: the application prints "BTC balance" over safeguarded customer property, an omnibus pool, an internal ledger claim, a margin account, a lending product and a derivative exposure alike.

The first accounting step is therefore asset identification, not valuation. Before asking "what is the fair value of my BTC?" ask "do I still recognise native BTC at all?" A claim on an intermediary does not become an in-scope crypto asset under ASC 350-60-15-1 just because it is denominated in BTC (FASB ASU 2023-08), so measuring it as native BTC applies the wrong model to the wrong asset.

SAB 122 did not make custody analysis disappear

In the United States, SEC Staff Accounting Bulletin 122 rescinded the safeguarding guidance previously in SAB 121, effective January 30, 2025. The bulletin "rescinds the interpretive guidance included in Topic 5.FF" (SEC SAB 122).

That matters for safeguarding entities, but it does not make every customer balance the customer's asset or every custodian balance the custodian's. A safeguarding entity now applies the otherwise applicable contingency and disclosure guidance, and each party still analyses control and contractual rights for itself. Rescinding SAB 121 removed a recognition and measurement requirement, not a presentation one: Topic 5.FF had required a safeguarding entity to recognise a liability for its obligation to safeguard the crypto-assets held for its users, measured at fair value, together with a corresponding safeguarding asset also measured at fair value. Both came off the balance sheet.

It did not answer an ownership question, which is why guidance aimed at custodians should never become a shortcut for customer asset recognition.

Multisig, escrow and collateral: restriction is not derecognition

Bitcoin outputs can require several valid signatures before they can be spent. These m-of-n scripts, commonly two signatures from three possible keys, are multisignature outputs, usually shortened to multisig (Bitcoin Developer Guide, Transactions). One design supports completely different relationships: three directors holding one key each, the company holding two keys and a recovery provider the third, a lender holding a collateral key, or an escrow agent participating in release conditions. The script tells you the spending rule, not the accounting relationship. Only the contract and the governance arrangement decide whether that output is an internal control over an asset one entity owns outright, a substantive restriction, joint control, escrow, collateral or custody.

Escrow makes the same point across time. The distinction that matters is between restriction and derecognition. If the entity still holds the relevant rights but cannot move the asset unilaterally until contractual conditions are met, it may stay recognised with restriction or disclosure. If it instead transfers control or substitutes another enforceable right, a different conclusion follows. That the holder cannot sign alone does not prove disposal: ordinary internal controls have that effect on purpose.

Pledged BTC is the same question with more money attached. What decides it is whether title transfers, whether the lender can reuse or sell the collateral before default, whether the pledgor still bears market gains and losses, what triggers enforcement, and what recovery rights survive liquidation. One arrangement leaves the BTC as the pledgor's asset subject to an encumbrance, disclosed as pledged. Another transfers control and leaves the pledgor with a different contractual right. The security agreement settles it, not the wallet transfer to a lender-controlled address.

Lending Bitcoin: what replaces the BTC is probably not a financial asset

This is the article's most consequential boundary, and the most commonly mislabelled. Suppose Entity A transfers 10 BTC to Entity B, and Entity B may sell the units, rehypothecate them (reuse them for its own account) or otherwise deal with them, obliged only to return 10 equivalent BTC later plus a fee. Entity A may therefore no longer control the transferred native BTC, and what it holds instead is a contractual right against Entity B. Naming that right is where the analysis turns delicate. "Loan receivable denominated in BTC," used unqualified, sends an accountant straight to the financial-instruments literature: IFRS 9 under IFRS, ASC 326 under US GAAP. Whether that is the right destination differs by framework.

Under IFRS that is very likely the wrong destination. A right to receive a fixed number of BTC is a right to receive a nonfinancial asset, and the IAS 32.11 definition reaches only cash, an equity instrument of another entity and a right to receive cash or another financial asset (IAS 32). That is the reasoning behind the IFRS Interpretations Committee's own conclusion on cryptocurrency holdings (IFRIC), and a right to receive a nonfinancial asset does not become a financial asset because the agreement is titled a loan. IFRS has no Bitcoin-loan model, so the lender works the IAS 8.10-12 hierarchy: first whether the contract transferred control of the native BTC, then a relevant and reliable recognition, measurement, remeasurement and impairment policy developed from analogous IFRS requirements and the Conceptual Framework, and only then from other standard-setters' pronouncements and industry practice that do not conflict (IAS 8). Reuse rights, collateral, recall rights, default remedies and who bears loss decide it.

One scope provision is worth reading before concluding. IAS 32.8 applies the Standard to contracts to buy or sell a non-financial item that can be settled net in cash, "as if the contracts were financial instruments". It expressly excepts contracts "entered into and continue to be held for the purpose of the receipt or delivery of a non-financial item in accordance with the entity's expected purchase, sale or usage requirements". IAS 32.9 then lists the ways net settlement can arise, and only contracts falling under (b) or (c) are automatically in scope; a contract caught by (a) or by (d), the item being "readily convertible to cash", is still evaluated against that own-use purpose. So this is a provision about forward and similar contracts over BTC, not a route that turns a plain obligation to return borrowed coins into a financial instrument.

Under US GAAP the answer differs, and it is not in the Codification either. A January 2023 KPMG summary of SEC staff views, nonauthoritative but the most widely used current interpretation, has the lender derecognising the loaned BTC when the borrower can direct its use and bears loss or theft risk, recognising a crypto-asset loan receivable measured initially and subsequently at the fair value of the loaned units through earnings, and separately applying ASC 326 to credit loss (KPMG US, lenders' accounting for crypto intangible asset loans). ASC 326 therefore does have a role for a US filer, by interpretation rather than because a Bitcoin-lending model exists. Do not flatten the two frameworks: on identical facts an IFRS preparer documents an IAS 8 policy for a nonfinancial right, while a US GAAP preparer may carry a fair-valued receivable with an ASC 326 allowance.

Two points survive either way. The right is not native BTC merely because repayment is denominated in BTC, and repayment now depends on a counterparty: if Entity B fails, Entity A cannot sign a transaction and recover the original outputs, because it no longer has any.

The ticker stayed BTC while the risk turned into counterparty and contract risk.

One more trap sits on the same contract. If the lender is owed 10 BTC of principal plus 0.2 BTC of interest, the later 10.2 BTC receipt is not 10.2 BTC of income: principal settles the lender's contractual right, the 0.2 BTC is the financing return, and the received units then need their own carrying history. Collapsing the two overstates income by the whole of the principal, for the reason that also catches mining pools: an on-chain receipt is not necessarily the economic recognition event.

Borrowing Bitcoin can create an asset and a liability at the same time

From the borrower's side: if Entity B receives BTC and gains control over it, it may recognise both the BTC as an asset and a separate obligation to return equivalent BTC. A portfolio application shows a positive 10 BTC balance while the entity owes 10 BTC plus interest. They should not be netted merely because they share a unit. Portfolio systems report "net exposure," but IAS 1.32 requires that an entity "shall not offset assets and liabilities or income and expenses, unless required or permitted by an IFRS" (IAS 1). That regime is changing: IFRS 18 replaces IAS 1 for annual reporting periods beginning on or after 1 January 2027 and applies retrospectively, so a calendar-year entity restates its FY2026 comparatives. Under US GAAP, offsetting instead requires a right of setoff under ASC 210-20 between two parties who owe each other determinable amounts. Native BTC is not an amount owed by the lender, so a BTC holding and a BTC return obligation cannot be offset, and that holds even where the lender and the source of the units are the same party.

The obligation itself is unsettled. Under IFRS the borrower applies the same IAS 8.10-12 hierarchy to that noncash obligation, measures interest or yield separately from principal, and does not net the liability against the BTC or the collateral (IAS 8). Under US GAAP, current KPMG interpretation recognises controlled borrowed BTC at fair value with a separate return obligation, and treats that obligation under ASC 815 as a hybrid instrument, a debt host with an embedded derivative indexed to BTC, to be assessed for bifurcation and subsequent measurement (KPMG US, Crypto Assets Handbook, Q8.3.80). That is interpretation of existing Topics, not Bitcoin-loan guidance, and an entity adopting it should say so in its policy note.

Lost keys, custodian failure and borrower default are three different failures

All three leave a holder unable to access "1 BTC," and all three look alike on a screen. The asset problem differs in each.

Lost private key. The issue is access to self-custodied native BTC: whether recovery is possible, whether a backup key exists, and whether future economic benefits are still expected. The last is what IFRS derecognition turns on, because under IAS 38.112 an intangible asset is derecognised "on disposal" or "when no future economic benefits are expected from its use or disposal" (IAS 38), with IAS 37 and IAS 36 governing any recovery asset. Under US GAAP the same event runs through ASC 350-10-40-1 (FASB Codification) alongside ASC 450. Tax can differ again: for a UK individual, HMRC's published position is that misplacing a key "does not count as a disposal for Capital Gains Tax purposes," though a negligible-value claim may be available where it can be shown there is no prospect of recovering the private key or accessing the tokens (HMRC CRYPTO22400).

Custodian failure. The issue is legal ownership, segregation, insolvency rights and credit exposure: the customer might still own identifiable BTC or might hold an impaired contractual claim, and the chain balance cannot decide which.

Borrower default. If control passed under the loan, the lender already holds a contractual right, not native BTC, so this is a credit and recovery problem, not a lost-asset problem.

These should not be collapsed into a generic "crypto loss" bucket: they have different recognition dates, different measurement bases and, for a UK individual, different tax treatment. Theft is not a disposal for HMRC purposes because "the individual still owns the stolen asset and has a right to recover it" (HMRC CRYPTO22450). HMRC draws the consequence in the same paragraph, and it is adverse: because the individual still owns the asset, victims of theft cannot claim a loss for Capital Gains Tax. Theft therefore does not open the negligible-value route described above for a lost key.

A practical Bitcoin ownership classification table

Position shown as "BTC"	What it may actually represent	Evidence needed beyond the chain
Self-custody wallet	Native BTC controlled directly	Key governance, descriptors, wallet records
Segregated custody	Customer-owned BTC held by custodian	Custody terms, segregation, legal rights
Omnibus exchange balance	Native BTC interest or contractual claim	Exchange terms, reuse rights, insolvency treatment
BTC lent to a borrower	Right to receive BTC, probably not a financial asset under IFRS	Loan agreement, control transfer, repayment rights
Borrowed BTC	BTC asset plus return obligation	Borrowing agreement, collateral and settlement terms
Pledged BTC	BTC subject to restriction, or transferred control	Security agreement, lender rights, enforcement terms
Multisig	Internal control, joint control, escrow or collateral	Keyholder roles and governing agreement

Classification is facts-specific, and every entry in the third column lives in a contract rather than on the chain. This is a decision map, not a legal conclusion.

Never trust the ticker alone

A robust crypto subledger should identify the asset type, network, custody arrangement, beneficial-ownership conclusion, counterparty, restrictions and collateral status, associated liabilities, and contract reference. "BTC" alone names a unit of account while concealing the structure underneath it, and every failure mode above begins with someone treating that label as an answer. For each position, ask:

Is this native BTC, or a representation or claim?
Who has protocol signing control?
Who has the economic rights and bears gains and losses?
Can an intermediary reuse the asset?
What does the holder recover if the intermediary fails?
Is the position restricted, pledged, lent or borrowed?
Is there a separate liability that should be recognised gross?

Only after those seven answers exist, and Bitcoin ownership is settled, does measurement become the main issue.

Sources and further reading

Bitcoin white paper (a coin as "a chain of digital signatures")
Bitcoin Developer Guide, Transactions (unspent transaction outputs) and Wallets (keys, not accounts). Note: the Developer Guide is a frozen 2020 snapshot and is unmaintained.
Bitcoin Core 31.0 RPC, getaddressinfo and getrawtransaction
Bitcoin Core 31.0 RPC documentation
SEC Staff Accounting Bulletin No. 122
IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019
IAS 32, Financial Instruments: Presentation (paragraph 11 definition, application guidance AG10)
IAS 8, Accounting Policies, Changes in Accounting Estimates and Errors (paragraphs 10-12)
IAS 38, Intangible Assets (paragraph 112 derecognition)
IAS 36, Impairment of Assets
IAS 1, Presentation of Financial Statements (paragraph 32 offsetting), replaced by IFRS 18 for annual reporting periods beginning on or after 1 January 2027, applied retrospectively
FASB ASU 2023-08, Accounting for and Disclosure of Crypto Assets (ASC 350-60)
FASB ASC 350-10-40-1, derecognition
KPMG US, Lenders' accounting for crypto intangible asset loans, January 2023
KPMG US, Crypto Assets Handbook, April 2026
HMRC Cryptoassets Manual, CRYPTO22400 (lost keys)
HMRC Cryptoassets Manual, CRYPTO22450 (theft)

The KPMG lending and borrowing positions cited above are secondary interpretive sources, not authoritative guidance. Neither IFRS nor the FASB Codification contains a Bitcoin-lending model. The ASC 210-20 setoff reference is named without a pinpoint because the FASB Codification is behind a registration wall and its wording could not be independently retrieved.

Educational research, not accounting, tax, legal, valuation or investment advice. Custody, title and insolvency conclusions require the actual contract and applicable law.