Audit Considerations for Crypto Assets

Why crypto audits are different from investment audits

A traditional investment audit relies on a custodian confirmation. You send ISA 505 confirmations to the bank or broker, they confirm the holdings, and existence is largely resolved. Crypto assets break this model entirely.

Self-custodied crypto (held in a wallet controlled by the client’s private key) has no third-party custodian to confirm with. Exchange-held crypto introduces a different problem: the exchange is the custodian, but many exchanges are unregulated, domiciled in jurisdictions with minimal oversight, and have a documented history of insolvency. The FTX collapse in November 2022 demonstrated that exchange-held balances could vanish overnight, turning a confirmed existence assertion into a going concern event.

ISA 500.A1 states that audit evidence is information used by the auditor in arriving at the conclusions on which the audit opinion is based. For crypto assets, the nature of sufficient appropriate evidence is fundamentally different from traditional financial instruments. Blockchain records provide a publicly verifiable transaction history (immutable, timestamped, independently verifiable), which is stronger than a bank statement in some respects and weaker in others. A wallet address doesn’t identify the owner.

The audit challenge isn’t that evidence doesn’t exist. It’s that the evidence is unfamiliar, the accounting standards weren’t designed for these assets, and internal controls around custody are often immature at clients who adopted crypto recently. Your approach needs to address existence, ownership, classification, and valuation as distinct workstreams. Each has specific pitfalls that don’t appear in a conventional investment or intangible asset file.

Classification: which standard applies

The IFRS Interpretations Committee addressed crypto asset classification in June 2019. Their agenda decision confirmed that cryptocurrency holdings meet the definition of an intangible asset under IAS 38 when the holder doesn’t have the power to govern the financial policies of the issuer and the asset is not a financial instrument under IFRS 9.

That means the default treatment for a client holding Bitcoin or Ethereum as an investment is IAS 38. The client can choose between the cost model (IAS 38.74) and the revaluation model (IAS 38.75–87). Under the cost model, write-downs for impairment follow IAS 36, but no upward revaluation is permitted. Under the revaluation model, the asset needs an active market (which most major cryptocurrencies satisfy), and gains flow to OCI unless reversing a previous loss.

Two exceptions to the IAS 38 default exist, and both change the measurement basis materially.

If the client is a broker-trader in crypto assets (buying and selling in the ordinary course of business with the intention of generating profit from price fluctuations), the holdings fall under IAS 2 as inventory. IAS 2.3(b) specifically addresses commodity broker-traders who measure inventories at fair value less costs to sell, with changes flowing through profit or loss. This treatment is significantly different from IAS 38. The client recognises unrealised gains in the income statement rather than in OCI or not at all.

Some tokens may qualify as financial instruments under IFRS 9 if they represent a contractual right to receive cash or another financial asset. Stablecoins pegged to fiat currency are the most common example. A USDC token that gives the holder a contractual right to redeem for one US dollar has characteristics closer to a financial asset than an intangible.

Existence and rights: proving the client owns what they claim

Existence testing for crypto assets splits into two questions. Does the asset exist on the blockchain? And does the client control it?

For the first question, blockchain explorers (Etherscan for Ethereum, Blockchain.com for Bitcoin, or multi-chain tools like Blockchair) allow you to independently verify that a wallet address holds the reported balance at a given date. This is public information. You don’t need the client’s permission to look it up. Under ISA 500.A31, external information sources that the auditor can access independently provide stronger evidence than client-prepared records.

The second question (does the client actually control the wallet) depends on the custody arrangement. This is where the audit gets harder.

Self-custodied assets require the client to demonstrate control of the private key. The standard approach is a signed message test: the client signs a predetermined message using the private key, and you verify the signature against the public key of the wallet. This proves the private key holder is cooperating with the audit. It doesn’t prove that no one else also holds a copy of the key. Document this limitation.

Exchange-held assets require a confirmation from the exchange, similar to a bank confirmation under ISA 505. The reliability of this confirmation depends on the exchange itself. A confirmation from a regulated exchange (Coinbase in the US, Bitvavo in the Netherlands) carries more weight under ISA 500.A31 than one from an unregulated offshore platform. If the client holds material balances on an unregulated exchange, document the risk and consider whether additional procedures (such as test withdrawals before year-end) are needed.

One practical complication: some exchanges don’t respond to audit confirmation requests in the format you’re used to sending. Smaller exchanges may not have a process for handling ISA 505-style requests at all. In that case, consider alternative evidence: screenshots of the account balance at year-end (weaker evidence, but combined with subsequent transaction history showing the balance was real, it may be sufficient), or API-generated account statements that include transaction identifiers verifiable against the blockchain.

Rights and obligations require you to go further still. You need to confirm that the assets aren’t pledged, staked, lent, or locked in a liquidity pool. Staking locks tokens for a period and may alter the economic substance of the holding. Lending protocols transfer custody to a smart contract, which changes who bears the credit risk. Ask the client specifically about staking, lending, yield farming, and liquidity pool participation. If any of these apply, the rights assertion changes and may affect both classification and measurement.

Valuation: which price is the right price

Crypto assets trade on dozens of exchanges simultaneously, and prices vary between them. IFRS 13.72 requires fair value measurement to maximise the use of relevant observable inputs. For assets with multiple active markets, IFRS 13.16 directs the entity to determine the principal market (the market with the greatest volume and level of activity) and use the price in that market.

In practice, this means the client needs to identify which exchange represents the principal market for each token and document why. The audit team verifies that the selected exchange is indeed the most active by volume and that the price used matches the closing price on that exchange at the reporting date. Aggregator sites like CoinMarketCap and CoinGecko can serve as corroborating evidence, though they aren’t primary sources under IFRS 13.

If no principal market can be identified, IFRS 13.18 permits the most advantageous market. This is less conservative and requires stronger documentation.

For tokens with low liquidity (fewer than €100K daily volume), consider whether an active market exists at all. If it doesn’t, the fair value measurement moves to Level 2 or Level 3 in the IFRS 13 hierarchy, and the disclosure requirements under IFRS 13.93 expand significantly. Small clients often hold obscure tokens without realising the measurement and disclosure consequences.

Internal controls and IT considerations

Crypto custody introduces IT risks that don’t exist in traditional treasury environments. ISA 315.21 requires the auditor to obtain an understanding of the information system and related business processes relevant to financial reporting, including the IT environment.

For self-custodied assets, the controls that matter are around private key management. Where is the private key stored? Who has access? Is there a backup, and is that backup stored securely in a separate location? A hardware wallet in the CFO’s desk drawer is a single point of failure. If the device is lost, damaged, stolen, or corrupted, the assets are irrecoverable. Most mature crypto holders use multi-signature wallets (requiring two or more key holders to authorise a transaction) or hardware security modules. If the client uses a single-signature wallet with no documented backup procedure, document this as a control deficiency and consider the implications for the rights assertion.

For exchange-held assets, the relevant controls are around account access and withdrawal limits. Who has credentials to the exchange account? Is two-factor authentication enabled? Are there withdrawal address whitelists that prevent transfers to unknown wallets? The exchange’s own controls matter less to your assessment than the client’s controls over access to the exchange account, because a compromised exchange account means lost assets regardless of how secure the exchange itself is.

Private key loss is permanent and irreversible. There is no “forgot password” process, no bank to call, and no fraud protection. This asymmetry makes control documentation more critical for crypto custody than for almost any other asset class your non-Big 4 clients hold.

Transaction monitoring is another area where traditional controls break down. A client with an active crypto treasury may execute dozens of transactions per day across multiple wallets and exchanges. If the client has no reconciliation process between blockchain transactions and their accounting records, completeness of transaction recording becomes a significant risk. Request and review whatever reconciliation process exists. If none exists, consider whether this represents a material weakness in internal controls over financial reporting.

Worked example: auditing Brouwer Payments B.V.

Scenario: Brouwer Payments B.V. is a payment processor in Amsterdam that accepts crypto payments from merchants and converts them to euros daily. At 31 December 2024, Brouwer holds: 4.2 BTC (€168K at year-end), 22 ETH (€55K), and 850,000 USDC (€782K, pegged 1:1 to USD at €0.92/USDC). Total digital assets on the balance sheet: €1,005K. Brouwer classifies all holdings as intangible assets under IAS 38.

Step 1: Evaluate classification

Brouwer buys and sells crypto daily in the ordinary course of business. This pattern matches the broker-trader model under IAS 2.3(b), not the intangible asset model under IAS 38. USDC, as a stablecoin with a contractual redemption right, should be classified under IFRS 9 as a financial asset. The client’s blanket IAS 38 classification is incorrect for both the trading portfolio and the stablecoin.

Step 2: Test existence

Obtain the wallet addresses from Brouwer’s treasury records. For the BTC and ETH holdings (self-custodied in a hardware wallet), verify balances on Blockchain.com and Etherscan at 31 December 2024. Request a signed message test from the CFO to confirm private key control. For the USDC (held on Bitvavo, a Dutch-licensed exchange), send an ISA 505 confirmation request to Bitvavo.

Step 3: Test valuation

For BTC and ETH under IAS 2 (broker-trader), fair value less costs to sell applies. Identify the principal market by volume (Binance for both at this date). Obtain the midnight UTC price from CoinMarketCap as the corroborating source. BTC: €40,000 per coin × 4.2 = €168,000. ETH: €2,500 per coin × 22 = €55,000. For USDC under IFRS 9, verify the 1:1 peg held at year-end and convert at the ECB EUR/USD rate: €0.92 × 850,000 = €782,000.

Step 4: Test rights and obligations

Ask Brouwer’s CFO directly: are any tokens staked, lent, pledged, or locked in DeFi protocols? Brouwer confirms none are. Verify on-chain: check whether any tokens moved to known staking contract addresses during the period. Review the Bitvavo terms of service to confirm withdrawal on demand is permitted.

The reclassification from IAS 38 to IAS 2 and IFRS 9 changes Brouwer’s income statement: unrealised gains now flow through P&L for the trading portfolio instead of remaining frozen under cost or going through OCI under revaluation. A reviewer looking at this file will see a clear classification analysis, independent existence verification, documented principal market selection, and a rights confirmation that covers staking and lending.

Practical checklist

1. Obtain a complete list of every token type the client holds, with wallet addresses and custody method (self-custody, exchange, or third-party custodian). Verify against the blockchain before accepting the client’s records.
2. Classify each material token under the correct IFRS standard (IAS 38 for held intangibles, IAS 2 for broker-trader inventory, IFRS 9 for tokens with contractual cash flow rights). Document the analysis per token type with paragraph references.
3. For self-custodied assets, perform a signed message test to verify private key control. For exchange-held assets, send ISA 505 confirmations and assess the exchange’s regulatory status.
4. Identify the principal market for each token under IFRS 13.16, verify the price at the reporting date with a specified timestamp convention, and document corroborating evidence from aggregator sources.
5. Ask the client specifically about staking, lending, yield farming, and liquidity pool participation. If any apply, reassess the rights assertion, consider the impact on classification, and include the confirmation in the ISA 580 representation letter.
6. Review low-liquidity tokens for whether they require Level 2 or Level 3 fair value measurement and the expanded disclosures under IFRS 13.93.

Common mistakes

• Accepting a screenshot of an exchange balance as sufficient existence evidence without independent blockchain verification. The PCAOB’s 2023 staff guidance on digital assets specifically noted that client-prepared evidence from exchange interfaces does not constitute external confirmation under the standards.
• Applying IAS 38 to all crypto holdings without analysing the client’s business model. Broker-traders who buy and sell tokens daily should apply IAS 2 under paragraph 3(b), and the measurement difference (fair value through P&L versus cost or revaluation) is material on most engagements where crypto is a significant balance.

Related content

Frequently asked questions

Further reading and source references

• IFRS Interpretations Committee Agenda Decision (June 2019): Holdings of Cryptocurrencies — confirmed IAS 38 as the default standard.
• IAS 38, Intangible Assets: paragraphs 74–87 on cost model and revaluation model.
• IAS 2, Inventories: paragraph 3(b) on commodity broker-traders.
• IFRS 13, Fair Value Measurement: paragraphs 16–18 on principal market and most advantageous market.
• ISA 500, Audit Evidence: paragraphs A1–A31 on the nature of sufficient appropriate evidence.
• PCAOB 2023 Staff Guidance: digital asset audit considerations.