Digital Asset Custody — Best Practices and Supervisory Expectations

Custody is where digital-asset compliance stops being a paperwork exercise. Every other control — licensing, KYC, sanctions screening, the Travel Rule — assumes you can still move the assets you say you hold. Key management is the assumption underneath all of them.

This page sets out what US regulators now expect of firms that hold crypto-assets for customers, and how the key-management architectures on the market actually satisfy those expectations. It is written for the person who has to answer an examiner, not for the person choosing a wallet app.

The controlling document

On 14 July 2025 the OCC, the Federal Reserve Board and the FDIC issued a joint statement, Crypto-Asset Safekeeping by Banking Organizations. It is the clearest statement of supervisory expectations available in the United States, and it opens by saying what it is not:

This statement discusses how existing laws, regulations, and risk-management principles apply to this activity, and does not create any new supervisory expectations.

That framing matters. There is no crypto custody rulebook to comply with. There is the existing custody rulebook — 12 CFR 9 and 150 for fiduciary activity, the OCC's Custody Services booklet, Interpretive Letter 1170, the Interagency Guidelines Establishing Information Security Standards — applied to an asset class where a compromised key is an irreversible loss rather than a recoverable error.

The statement also draws a distinction worth keeping straight in your own documentation. Safekeeping is "the service of holding an asset on a customer's behalf." Custody is the broader set of services a firm may provide around assets it holds. The joint statement addresses safekeeping specifically.

The control test

The operative standard is narrower than most firms assume. A banking organization has control of a crypto-asset when it can reasonably demonstrate that

no other party — including the customer — has access to information sufficient to unilaterally transfer the crypto-asset out of the control of the banking organization.

Two consequences follow, and both are routinely missed.

Taking possession of a key is not taking control. The agencies say so directly: a firm that simply receives existing cryptographic keys may not have control, because the customer may have retained copies or given them to others. Importing a customer's key material does not establish custody. To establish initial control you will usually need the asset transferred to you on its own distributed ledger, into key material you generated.

The same standard applies to your sub-custodian. Delegating safekeeping does not delegate the control test. If your sub-custodian's arrangement would not satisfy the standard when you performed it yourself, it does not satisfy it when they do.

Choosing a key-management architecture

Three designs dominate institutional custody. They are not ranked; they fail differently, and the right answer is usually a tiered combination.

	HSM	MPC	On-chain multisig
Where the key lives	Whole, inside tamper-resistant hardware	Never exists whole; shares held separately	Whole keys, held by separate signers
Signing quorum enforced by	Device policy and operator authentication	Cryptographic threshold protocol	The chain itself
Visible on-chain	No — an ordinary single-sig address	No — an ordinary single-sig address	Yes
Chain coverage	Bounded by firmware curve/algorithm support	Broad; protocol is chain-agnostic	Only where the chain supports it
Independently verifiable by a third party	Via certification and audit	Via certification and audit	Via the ledger
Principal residual risk	Physical and operator compromise; firmware lag	Implementation correctness; share-refresh operations	Signer collusion; on-chain complexity and fees

HSMs put the key inside a certified boundary and never let it out. FIPS 140-3 validation is the common institutional bar, and Level 3 is what most examiners will recognise without argument. The strengths are the ones a regulator already understands: a hardware root of trust, quorum-based operator authentication, controlled cloning and backup domains, high-availability grouping. The constraint is coverage — the device has to support the curve and signature scheme your chain uses, and firmware trails new chains. Ask any vendor for the mechanism list, not the marketing sheet.

MPC splits the key so that it never exists in one place, at any time, including at generation. Signing happens as a threshold protocol between shares held by parties that can be organisationally and geographically separate. Because the output is an ordinary signature, MPC works across chains without per-chain contract support and leaves no distinguishing on-chain footprint. The trade is that your assurance now rests on the correctness of a protocol implementation rather than on a certified physical boundary, and on the discipline of share refresh. Treat proactive share rotation as an operational requirement, not a feature.

On-chain multisig is the only one of the three whose quorum is enforced and verifiable by anyone with a block explorer. That is a real property — it is why it remains the default for treasury reserves on chains that support it well. It is also chain-specific, more expensive, and it puts your recovery semantics on-chain where they cannot be changed quietly.

In practice, tier them. A common and defensible design uses MPC for the warm operational tier where transaction volume and policy complexity live, HSM-backed cold storage for reserves, and an HSM as the root of trust protecting MPC share material at rest. What a supervisor will ask is not which you chose but whether you can demonstrate control, recover from the loss of any single component, and evidence both.

Hot, warm and cold

The joint statement describes wallets as existing "on a continuum between 'cold' wallets permanently disconnected from the internet and 'hot' wallets that remain online at all times," and observes that "wallets that are more easily accessible may be less secure."

The compliance-relevant question is not the label but the ratio and the movement discipline: what proportion of customer assets sits in each tier, what triggers a movement between tiers, who authorises it, and whether the cold tier is genuinely air-gapped or merely on a different network segment. Firms fail this question by describing an architecture rather than a policy.

Note also that not all wallets are compatible with all crypto-assets. Asset coverage is a control question, not a product question.

Omnibus or segregated

The agencies flag this explicitly and decline to prefer one:

Omnibus accounts may permit greater efficiencies but could also create larger targets for theft. A banking organization using a separate account model might hold individual customer keys in separate, dedicated wallets, which could require the generation and management of a greater number of key pairs.

Omnibus concentrates operational risk and makes per-customer entitlement a book-entry claim rather than an on-chain fact. Segregated pushes the cost into key generation and lifecycle management at scale. Whichever you choose, the question that matters in an insolvency is whether your records can reconstruct each customer's entitlement — and whether the customer agreement says what you think it says.

Asset onboarding

Every asset you custody is a distinct risk decision. Sound practice, per the statement, includes

performing a comprehensive analysis of each crypto-asset before safekeeping that crypto-asset, including for example, by identifying vulnerabilities and dependencies that could create material risks.

That analysis should cover technical, operational, strategic, market, legal and compliance considerations for the asset and its underlying ledger — and it does not end at onboarding. You are expected to stay apprised of material developments affecting supported assets and chains. A listing committee with no ongoing review obligation does not meet this.

Sub-custodians and third parties

You remain responsible for what your sub-custodian does. That responsibility explicitly includes asset-selection decisions, even where the sub-custodian performed the analysis for you.

Due diligence should evaluate the effectiveness of the sub-custodian's key-management solution — policies, processes and internal controls — along with segregation, dual control and separation of duties. Two points deserve to be contractual rather than assumed:

• No commingling. The agencies state it would be inconsistent with appropriate risk management for a sub-custodian to commingle its own assets with assets held on your behalf, because that risks the assets being treated as the sub-custodian's property in a bankruptcy.
• Material-event notification. Contract for notice of any potential compromise of keys or sensitive information, any use of backup material, and any irreversible material transaction error.

Also analyse how customer assets would be treated at the sub-custodian in insolvency or an operational disruption — before you sign, not after.

What the customer agreement must address

A well-drafted agreement is treated as a risk-management tool in its own right. Beyond the ordinary duties and responsibilities, the statement identifies specific matters to address:

• on-chain governance and voting, and your role in it
• forks
• airdrops
• probabilistic settlement on permissionless chains
• the method of holding — cold, hot or hybrid
• the use of sub-custodians
• the use of smart contracts, including governance over their lifecycle

There is a related disclosure risk: customers may be misinformed about your actual role in the arrangement. Clear, accurate and timely information about what you do and do not do is the mitigation.

BSA/AML, sanctions and the Travel Rule

Safekeeping relationships carry the full BSA/AML, CFT and OFAC obligations — customer identification, due diligence on the nature and purpose of the relationship, ongoing monitoring and suspicious activity reporting, sanctions blocking, and the Travel Rule at 31 CFR 1010.410.

The agencies acknowledge that distributed-ledger design features may make some of these harder where compliance depends on reviewing identifying information attached to a transaction. That is an acknowledgement, not an exemption.

One procedural expectation is easy to satisfy and easy to forget: involve the BSA officer, the board or its designated committee, and senior management before offering the service, and document that you did.

Audit and independent assurance

Your audit programme must cover safekeeping, including third-party risk management. The statement is specific about scope:

an assessment of cryptographic key generation, storage, and deletion; controls related to transfer and settlement of customer assets; and the sufficiency of relevant information technology systems.

Audit should also assess whether management and staff actually have the expertise to identify and control the risks. Where that expertise does not exist internally, management is expected to engage external resources with sufficient independence — the statement says so directly, which makes "we had no one qualified to review it" an inadequate answer rather than an explanation.

Bank powers: what is settled

Three OCC interpretive letters bound the current position for national banks and federal savings associations:

• IL 1183 (7 March 2025) — crypto-asset custody, certain stablecoin activities, and participation in independent node verification networks are permissible.
• IL 1184 (7 May 2025) — a bank may buy and sell assets held in custody at the customer's direction, and may outsource permissible crypto activities including custody and execution to third parties, subject to third-party risk management.
• IL 1186 (18 November 2025) — a bank may hold crypto-assets on balance sheet in amounts necessary to pay network fees for otherwise permissible activities.

Permissible is not the same as prudent. Each letter conditions the activity on safe-and-sound conduct and compliance with applicable law.

Broker-dealers are on a different track

Firms holding crypto asset securities face a separate regime. On 17 December 2025 the staff of the SEC's Division of Trading and Markets issued a statement on how the Customer Protection Rule's possession-and-control requirement — Rule 15c3-3(b)(1) — applies to crypto asset securities, framed explicitly as an interim step while the Commission considers the broader custody questions.

The core expectation: a broker-dealer must establish, maintain and enforce reasonably designed written policies, procedures and controls, consistent with industry best practices, to protect against theft, loss or unauthorised use of the private keys needed to access and transfer the securities. It applies to any broker-dealer carrying crypto asset securities for customers — including firms running an otherwise traditional securities business.

If you are a bank building custody and a broker-dealer affiliate touches the same assets, you are running two rulebooks against one key-management platform. Map that before you build.

A control checklist

Questions worth being able to answer on demand, with evidence:

1. Can we demonstrate that no other party — including the customer — can unilaterally move a customer asset?
2. Was every key we hold generated by us, under our control environment, to a documented standard?
3. What happens to customer assets if any single vendor, facility or signer disappears tomorrow?
4. Who authorises a movement from cold to warm, and what independent check sits on that authorisation?
5. Can we reconstruct per-customer entitlement from our records without on-chain segregation?
6. When did we last test recovery from backup material — not review the procedure, test it?
7. Which assets did we onboard more than a year ago and have not reviewed since?
8. Does our sub-custodian contract prohibit commingling, and have we verified it in practice?
9. Does the customer agreement address forks, airdrops, governance voting and smart-contract risk?
10. Has an independent party with actual expertise assessed key generation, storage and deletion?

Items 6 and 7 are where firms with otherwise strong architectures tend to fail.