Digital asset risk management: the risks a VaR model cannot see

Five categories cover a crypto book, and the first two are familiar.

Market risk is price and volatility, measurable with the usual tools and treated under bitcoin volatility. Counterparty risk is the exchange, the lender and the clearing house holding your margin or your coin. Operational risk covers the processes around a transfer, including the signing process itself. Key management risk is the possession of the asset: lose the key and the position is gone, with no counterparty to claim against and no court that can restore it. Chain risk is the ledger itself: a reorganization, a fork, a halted network or a bridge failure.

The useful discipline is to run these through the frameworks you already have instead of inventing a parallel structure, which is how institutions have approached it, as 3iQ describes in its account of sizing and managing the allocation. The categories that are genuinely new get new controls; the rest reuse what works.

A key ceremony is the generation of key material under controlled conditions, and it is a single event whose failure is permanent. The controls are physical and procedural: a scripted process, named participants, dual control throughout, a recorded and witnessed session, and the resulting shares distributed so that no one person or location holds enough to sign.

The signing process is the daily version of the same risk. An institution needs a transfer to require more than one person, an allowlist of destination addresses so a wrong or substituted address cannot be paid, a limit above which authorization escalates, and a tested recovery path for the case where a signer is unavailable. MPC wallets cover the technology that implements this, and the technology does not remove the procedure: a threshold scheme with all shares in one team's hands is a single point of failure wearing a better name.

The 2022 failures taught a lesson that is now standard practice: an exchange balance is an unsecured claim on that exchange, not a holding. Every coin left on a venue to facilitate trading is credit exposure, and the limit framework has to treat it as such.

Four controls follow. A per-venue cap on the balance held, sized to what you could lose and not to what is convenient for trading. A sweep discipline that moves balances above the cap into segregated custody on a schedule nobody can skip. Diligence on each venue covering its licensing, its segregation practice and its reserve disclosures. And concentration limits per asset and per venue, plus caps on low-liquidity tokens where your own position is the market.

A settled transfer is not always final. A chain reorganization replaces recent blocks, which can reverse a transaction you treated as complete, which is why custodians and exchanges wait a number of confirmations before crediting. That waiting period is a risk parameter: set it too low and you credit a payment that disappears, set it too high and you cannot settle on time.

Two further chain events belong in the framework. A hard fork splits an asset and creates a second holding with its own valuation, tax and custody questions. A network halt stops settlement entirely while prices keep moving elsewhere, which is the scenario where a hedge cannot be adjusted. Each needs a written playbook, because each arrives with no notice and is handled badly under time pressure.

For a regulated European firm, the operational side of a crypto book is not optional self-discipline. The Digital Operational Resilience Act applies ICT risk management duties to financial entities, covering the governance of ICT risk, incident classification and reporting, resilience testing and the oversight of third-party ICT providers.

Two consequences bite hardest here. A custodian or a node provider is an ICT third party, so it needs the contractual terms, exit plan and monitoring DORA requires, and a crypto custody arrangement signed before that framework existed usually needs reopening. And a key management incident is a reportable ICT incident on DORA's timetable, not an internal matter. DORA in Germany sets out the regime.

An equity stress scenario applied to a crypto book understates it. The historical record for a major crypto-asset includes drawdowns of seventy to eighty percent and single days with double-digit falls, so the scenario has to come from crypto's own history and not from a scaled equity shock.

Three scenarios belong alongside the price move, because they are what actually breaks a position. A liquidity scenario in which the book thins and your exit costs several percent in slippage. A counterparty scenario in which the largest venue exposure goes to zero. And a correlation scenario in which the crypto sleeve falls with equities on the same day, since the diversification argument fails exactly when it is needed, which crypto portfolio allocation examines.

The second line owns it. A crypto book sits inside the firm's existing risk function, with limits set by risk and not by the desk, which is the arrangement that makes a limit mean anything. Where a firm has set up a separate digital assets unit, the frequent weakness is that the unit also sets its own limits.

The board sees four things, and a reporting pack that shows only the position and its mark is incomplete. Exposure against each limit, with breaches named. Counterparty exposure by venue and custodian. The stress results against the scenarios above. And the operational incidents of the period, including failed transfers and key management events. In Germany the MaRisk expectations on governance and limit setting are the frame for all of this, described under risk management in Frankfurt.