How Do Businesses and Institutions Take Custody of Bitcoin?

By Blockstream Engineering · Last updated June 2026

From Individual to Institutional: What Changes at Scale

An individual secures bitcoin with a single private key or a personal multisig configuration. The threat model is straightforward: protect the key, protect the recovery phrase, verify the signing device. One person makes every decision. One person bears all risk. (That individual setup is covered in How Does Bitcoin Custody Work?) This article focuses on what changes when an organization, rather than one person, holds the bitcoin.

Organizations operate under different constraints. A corporate treasury holding bitcoin on its balance sheet, a fund custodying client assets, or a broker-dealer settling trades on behalf of institutional clients all face the same underlying challenge: no single person should have unilateral control over the funds. The cryptographic fundamentals remain identical. Private keys still sign transactions. Multisig still requires signatures from several independent keys. Hardware signing devices still protect keys from software-based attacks. What changes is the operational layer built on top of those fundamentals.

That operational layer includes governance (who can authorize what), compliance (what regulations constrain the process), access control (how roles and permissions are structured), auditing (what records must be maintained), and disaster recovery (what happens when a key holder is unavailable, incapacitated, or terminated).

Governance and Access Control

Governance is the policy layer that determines who can initiate transactions, who must approve them, and under what conditions approvals are valid. In institutional custody, governance structures are encoded into both the cryptographic scheme (multisig quorum) and the policy engine (rules that constrain when and how signatures can be applied).

Multisig Quorum Design

Multisig (M-of-N) configurations require a defined number of independent signers to authorize a transaction. Individual users typically choose 2-of-3 for personal funds. Institutional treasuries operate at higher thresholds.

A corporate treasury might use a 3-of-5 configuration, distributing signing authority among the CFO, CEO, two board members, and an external custodian. A large fund custodying client assets might use 4-of-7, with keys distributed across geographic locations and organizational roles. The quorum threshold (M) balances security against operational availability. Setting M too high creates a risk that legitimate transactions cannot be signed if signers are unavailable. Setting M too low weakens the governance model.

Quorum design decisions include:

• Threshold selection: What is the minimum number of approvals required, and does this change based on transaction size?
• Key distribution: Are keys held by internal personnel, external custodians, or a combination? What is the geographic distribution?
• Backup keys: How are recovery keys stored, and who can access them? What quorum is required for recovery scenarios?
• Key rotation: How often are keys rotated, and what process governs the transition?

Role-Based Access Controls

Beyond the cryptographic quorum, institutional custody systems enforce role-based access controls that determine what each user can do within the system. A transaction analyst might initiate a withdrawal request, but only a treasury manager can approve it. A compliance officer might review and flag transactions but cannot sign them. An administrator can configure policy rules but has no signing authority.

Effective role-based access follows the principle of least privilege: each role has only the permissions required for its function, and no more. Common roles in institutional custody include:

Separation of Duties

The core principle is that no single individual can move funds without the participation of at least one other authorized person. This applies at every level: the person who creates a transaction request cannot approve it, policy configuration is kept separate from key signing, and account administration carries no signing authority.

This separation is a regulatory expectation for entities that custody client funds, and a fiduciary requirement for corporate treasuries managing shareholder assets.

Policy Engine Controls

Modern institutional custody platforms go beyond static M-of-N quorums to implement dynamic policy engines that can enforce rules based on transaction context. Blockstream Enterprise provides institutional custody infrastructure with multisig governance, configurable policy engines, role-based access controls, and multi-party approval workflows. Policy engines on such platforms can enforce rules based on transaction context, such as amount-based approval tiers and destination whitelisting.

Typical policy engine capabilities include:

• Amount-based approval tiers: Transactions below $10,000 require two approvals. Transactions above $100,000 require four approvals including a board member. Transactions above $1 million require a full quorum plus a 24-hour delay.
• Destination whitelisting: Transactions can only be sent to pre-approved addresses. Adding a new address to the whitelist requires a separate approval workflow.
• Time-based restrictions: Transactions can only be executed during business hours or must include an additional approval if initiated outside normal operating windows.
• Velocity limits: Maximum daily or weekly withdrawal amounts, regardless of individual transaction approval status.

Operational Security and Compliance

Institutional custody operates within regulatory frameworks that impose specific requirements on how digital assets are stored, accessed, and reported. These requirements vary by jurisdiction and entity type, but several patterns are consistent across most regulated environments.

Key Ceremony Procedures

A key ceremony is the controlled process for generating, distributing, and backing up cryptographic keys. For individual users, key generation happens when a hardware wallet creates a recovery phrase. For institutions, the process is more involved.

A formal key ceremony typically includes:

• Witnessed generation: Keys are generated in a physically secure environment with multiple witnesses present. The entropy source must be a hardware random number generator (TRNG), or a cryptographically secure pseudorandom number generator (CSPRNG) seeded from hardware entropy. The generation process is documented and signed by all participants.
• Air-gapped hardware: Signing keys are generated and stored on dedicated hardware signing devices that have never connected to the internet. Enterprise-grade hardware security modules (HSMs) achieve FIPS 140-2 Level 3 or Level 4 certification, with tamper-responsive enclosures that zeroize key material if physical intrusion is detected. At smaller scale, Jade Plus supports air-gapped QR code-based signing, removing the need for USB or Bluetooth connections during key operations.
• Backup distribution: Recovery materials are split and distributed to multiple secure locations (bank vaults, safety deposit boxes, or dedicated secure facilities). Some institutions use Shamir's Secret Sharing (splitting a recovery phrase into K-of-N shares where any K shares reconstruct the original but fewer than K reveal nothing). No single location holds enough information to reconstruct a quorum.
• Chain of custody documentation: Every step of the key lifecycle is documented: who generated each key, where each backup is stored, who has access to each storage location, and when each key was last verified. Each key follows the HD derivation hierarchy (BIP-32) with documented derivation paths, so auditors can verify that addresses match the expected key tree.

Key ceremonies are not one-time events. They recur whenever keys are rotated, new signers are onboarded, existing signers are removed, or backup integrity needs verification.

SOC 2 Type II Compliance

SOC 2 (System and Organization Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA). It evaluates an organization's controls related to security, availability, processing integrity, confidentiality, and privacy. A SOC 2 Type II report covers a sustained period (typically six to 12 months) and evaluates whether controls are operating effectively over time, not just whether they exist on paper.

For custody providers, SOC 2 Type II compliance means an independent auditor has verified that:

• Access controls are enforced consistently
• Cryptographic key management follows documented procedures
• Incident response plans exist and are tested
• Change management processes are followed
• Monitoring and alerting systems detect anomalies

When evaluating custody providers, a current SOC 2 Type II report is a baseline expectation, not a differentiator. Absence of a SOC 2 report for a provider custodying institutional funds is a disqualifying signal.

Insurance Considerations

Insurance coverage for custodied digital assets remains an evolving market. Key considerations:

• Coverage scope: Most policies cover theft through external attack or internal collusion. Few cover loss due to smart contract bugs, protocol-level exploits, or regulatory seizure.
• Coverage limits: Total insured amounts are typically a fraction of total assets under custody. A custodian holding $5 billion in client assets may carry $500 million in insurance. Understand the ratio.
• Cold vs. hot storage: Policies often differentiate between assets in cold storage (air-gapped, offline signing) and hot wallets (connected, automated signing). Premiums and coverage terms differ significantly.
• Underwriter quality: A Lloyd's of London syndicate policy carries different counterparty risk than coverage from a smaller, less-established insurer. Evaluate the underwriter, not just the coverage amount.

Audit Trails and Regulatory Reporting

Every transaction, approval, rejection, policy change, and access event must be logged in an immutable, timestamped audit trail. For entities subject to financial regulation, comprehensive logging is mandatory, and for internal governance it is a practical necessity: boards and audit committees need to verify that custody operations conform to approved policies.

Audit trail requirements include:

• Full transaction history with initiator, approvers, and signers identified
• Policy change logs showing what changed, who changed it, and when
• Access logs showing every login, permission change, and role modification
• Failed transaction attempts and rejected requests
• Exportable reports in formats compatible with external audit tools

Treasury Management

Corporate treasury management for bitcoin holdings introduces accounting, tax, and segregation considerations that do not apply to individual holders. The regulatory and accounting treatment of corporate bitcoin holdings has shifted significantly since 2024. Organizations that hold bitcoin on their balance sheets now operate under clearer rules.

Corporate Treasury Considerations

Public companies adding bitcoin to their corporate treasuries follow a model established by MicroStrategy (now Strategy) beginning in 2020 and adopted by an increasing number of corporate treasurers since. The core proposition: hold bitcoin as a treasury reserve asset alongside or in place of traditional reserves (cash, short-term bonds, money market instruments).

Key decisions for corporate treasurers include:

• Allocation size: What percentage of treasury reserves is allocated to bitcoin, and what is the authorization process for increasing or decreasing the allocation?
• Acquisition strategy: Lump-sum purchase, dollar-cost averaging, or opportunistic buying on dips? Each has different cash flow and reporting implications.
• Custody structure: Self-custody, third-party qualified custodian, or a hybrid model? The answer depends on the company's technical capabilities, insurance requirements, and board risk tolerance.
• Liquidity requirements: What portion of holdings must be accessible within specific time frames? This affects the split between cold storage and more accessible configurations.

Accounting Treatment

In December 2023, the Financial Accounting Standards Board (FASB) issued ASU 2023-08, which requires entities to measure bitcoin and certain other digital assets at fair value in each reporting period. This standard became effective for fiscal years beginning after December 15, 2024.

Before this change, companies holding bitcoin had to use indefinite-lived intangible asset accounting, which required impairment charges when the price dropped but did not allow marking up the value when the price recovered (without selling). The result was that balance sheets consistently understated the actual value of bitcoin holdings.

Under fair value accounting:

• bitcoin holdings are marked to market each reporting period
• Both unrealized gains and losses flow through the income statement
• Balance sheets reflect the current market value of holdings
• Companies can present the economic reality of their bitcoin treasury to investors

Separately, the SEC's Staff Accounting Bulletin 121 (SAB 121), which had required entities custodying digital assets for others to record a liability (and corresponding asset) on their balance sheets, was effectively rescinded in early 2025. This removed a significant barrier that had discouraged regulated banks from offering custody services. The repeal opened the door for traditional banks to enter the Bitcoin custody market without the punitive capital treatment that SAB 121 imposed.

Segregation Requirements

Organizations that custody bitcoin on behalf of clients have a fundamental obligation: client funds must be provably separated from the firm's operational funds. Mixing the two, a practice known as commingling, creates legal, regulatory, and counterparty risk.

Segregation in Bitcoin custody takes several forms:

• Address-level segregation: Each client's bitcoin is held at distinct addresses that can be independently verified on-chain.
• Wallet-level segregation: Client funds and operational funds use entirely separate wallet infrastructure with separate key management.
• Proof of reserves: Regular, cryptographically verifiable attestations that the custodian holds the bitcoin it claims to hold. Proof of reserves combines on-chain verification with auditor attestation to provide assurance without revealing individual client balances.

Tax Implications

The tax treatment of custodied bitcoin varies by jurisdiction and entity type. Common considerations include:

• Disposition events: Every sale, exchange, or use of bitcoin to pay expenses is a taxable event in most jurisdictions. Treasury managers must track cost basis at the lot level.
• Cost basis methodology: FIFO (first in, first out), LIFO (last in, first out), or specific identification. The choice affects realized gains and losses and must be applied consistently.
• Cross-border complexity: Multinational organizations holding bitcoin across entities in different jurisdictions face transfer pricing, withholding, and reporting obligations that vary by country.
• Yield considerations: For entities lending bitcoin or using other yield-generating products, the tax treatment of yields and the timing of recognition add complexity. Consult qualified tax counsel.

Choosing Custody Infrastructure

Institutional custody spans a spectrum of approaches, from fully outsourced third-party custody to fully self-sovereign key management. Each position on the spectrum trades off control against operational complexity.

The Custody Spectrum

Build vs. Buy

The build-vs.-buy decision for custody infrastructure is a function of three variables: risk tolerance, operational capability, and cost.

Building in-house means the organization controls every component of the custody stack. Key generation, storage, signing workflows, policy enforcement, and audit logging all live within infrastructure the organization operates. The upside is maximum control and no third-party dependencies. The downside is significant engineering investment, ongoing operational cost, and the need to maintain security expertise across a system that handles high-value assets and has zero tolerance for bugs.

Buying (or licensing) custody infrastructure means adopting a platform that provides the governance, policy, and signing layers as a managed or self-hosted service. Blockstream Enterprise provides this model: organizations deploy multisig custody with configurable governance policies, role-based access, and audit-ready logging without building the underlying infrastructure from scratch. The organization retains control over its keys and policies while the platform handles the complexity of workflow orchestration, policy enforcement, and compliance tooling.

Most organizations land somewhere between the two extremes. A common pattern is to license a custody platform for orchestration and policy enforcement while maintaining direct control over signing keys through hardware signing devices held by authorized personnel.

Evaluation Criteria for Custody Providers

When evaluating custody infrastructure, whether as a fully outsourced custodian or as an infrastructure platform for self-custody, these criteria apply:

• Security model: How are keys generated, stored, and protected? Is the signing process air-gapped? What hardware security modules (HSMs) or hardware wallets are supported?
• Audit history: Is there a current SOC 2 Type II report? How long has the provider been operating? Has the provider experienced a security incident, and if so, how was it handled?
• Insurance: What is the coverage amount, scope, and underwriter? What is covered and what is excluded?
• Geographic distribution: Where are keys and backups stored? Does the distribution model protect against localized risks (natural disaster, jurisdiction-level seizure)?
• Key management approach: Who holds the keys? If the provider holds keys, what is the quorum structure? If the client holds keys, what signing devices and protocols are supported?
• Open-source vs. proprietary: Can the signing and verification code be independently audited? Open-source custody components allow third-party review of the code that protects funds.
• Recovery procedures: What happens if the provider ceases operations? Can the client recover funds independently? What are the documented disaster recovery and business continuity plans?

Technical Due Diligence

Chief technology officers, information security officers, and technical advisors evaluating custody solutions need to go beyond marketing materials and compliance certifications. The questions below target the technical architecture and operational procedures that determine whether a custody system will perform under stress.

Key Storage and Generation

Where are private keys stored, physically and logically? The answer should be specific. "In a secure environment" is too vague; a real answer names the controls, such as "FIPS 140-2 Level 3 HSMs across three geographically distributed data centers, with each HSM requiring dual-control authentication for key operations."

Questions to ask:

• What is the random number generation source for key creation? Is it hardware-based or software-based?
• Are keys generated on the signing device itself, or are they generated elsewhere and loaded onto the device?
• Can keys be exported from the signing device? If yes, under what conditions and with what protections?
• What is the key derivation path, and is it documented and reproducible?

Signing Architecture

The signing architecture determines how transactions move from creation to broadcast. A well-designed system separates transaction construction (which can happen on connected systems) from transaction signing (which must happen on air-gapped or isolated hardware).

Under the Hood: PSBT and the Signing Pipeline

Institutional multisig signing relies on Partially Signed Bitcoin Transactions (PSBTs), defined in BIP-174 (and extended by BIP-370 for PSBT version 2 and BIP-371 for Taproot fields). A PSBT is a standardized binary format that carries the unsigned transaction along with all the metadata each signer needs: UTXO information, derivation paths (per BIP-32), redeem scripts, witness scripts, and partial signatures collected so far. The PSBT travels between signers, each adding their signature to the appropriate inputs, until the M-of-N threshold is met and the transaction can be finalized and broadcast.

For legacy and SegWit multisig, each signer provides an ECDSA signature (70-72 bytes, DER-encoded) verified against their public key using OP_CHECKMULTISIG. For Taproot multisig via Tapscript, each signer provides a 64-byte Schnorr signature (BIP 340) verified with OP_CHECKSIGADD (BIP 342). The PSBT format abstracts away these differences, allowing the same signing workflow to handle both legacy and Taproot inputs seamlessly.

Questions to ask:

• Is the signing process air-gapped? What is the communication channel between the transaction construction layer and the signing devices (QR codes, USB, NFC, Bluetooth)?
• What transaction format is used for partially signed transactions? PSBT (BIP-174, with BIP-370 PSBT v2 and BIP-371 Taproot fields as later extensions) is the Bitcoin standard for passing partially signed transactions between co-signers.
• Can signers review transaction details (destination address, amount, fee) on the signing device itself before signing?
• What happens if a signing device is lost or destroyed? What is the recovery process, and has it been tested?

Backup and Disaster Recovery

Backup procedures must protect against both data loss and unauthorized access. A backup that can be accessed by a single person undermines the multi-party security model.

Questions to ask:

• How are recovery phrases and key material backed up? What format (metal plates, tamper-evident bags, shamir secret sharing)?
• Where are backups stored? How many locations, and what is the physical security model for each?
• What quorum is required to access backups and initiate recovery?
• How often are recovery procedures tested? When was the last full recovery test performed?
• What is the recovery time objective (RTO)? How long does it take to restore full operational capability from backups?

Upgrade and Migration Path

Bitcoin's protocol evolves. Custody infrastructure must accommodate new transaction types, address formats, and signing schemes without disrupting existing holdings.

Questions to ask:

• What address types are supported (Legacy, SegWit, Taproot)?
• How are firmware updates applied to signing devices? Is the update process air-gapped?
• Can the custody system migrate between multisig configurations (e.g., from 2-of-3 to 3-of-5) without moving funds to new addresses?
• What is the vendor's history of supporting new Bitcoin protocol features (SegWit, Taproot, Miniscript)?

Red Flags in Custody Providers

Certain patterns should raise immediate concern during due diligence:

• Proprietary, closed-source signing code: If the organization cannot review the code that controls access to its funds, it is trusting the vendor's internal processes entirely. Open-source signing components allow independent verification.
• Vague key storage descriptions: "Bank-grade security" and "military-grade encryption" are marketing terms, not technical specifications. Demand specifics about HSMs, signing devices, and physical security.
• No SOC 2 report: For a provider custodying institutional funds, the absence of an independent audit report is not acceptable.
• Single-entity key control: If the provider holds all keys and a single internal team can authorize transactions without external checks, the custody model has a single point of compromise.
• Undocumented recovery procedures: If the provider cannot produce a written, tested disaster recovery plan, the organization's funds are at risk in any scenario the provider has not anticipated.
• Resistance to penetration testing: Credible custody providers welcome third-party security assessments. Resistance to external testing suggests either lack of confidence in the security model or lack of maturity in the security program.
• Commingled client assets: If client funds and operational funds are not demonstrably separated at the address and wallet level, the custodian is creating unnecessary counterparty risk. Proof of reserves should be available on request.

Putting It Together: A Practical Framework

Institutional custody is a design exercise that spans governance, security, compliance, and operations rather than a single product decision. The framework below maps organizational characteristics to custody architecture decisions.

Step 1: Define Requirements

• Regulatory status: Is the organization a registered investment advisor, broker-dealer, bank, or unregulated entity? This determines whether a qualified custodian is required by law.
• Asset value: Are holdings in the millions, hundreds of millions, or billions? The security model and insurance requirements scale with value.
• Operational frequency: How often are transactions executed? A treasury that moves funds quarterly has different infrastructure needs than a fund that rebalances daily.
• Technical capacity: Does the organization have an internal team capable of managing key infrastructure, or does it need to rely on external expertise?

Step 2: Design the Governance Model

• Select a multisig configuration that balances security against availability
• Define roles: who initiates, who approves, who signs
• Set approval tiers based on transaction amount
• Document the governance model and have it approved by the board or governing body

Step 3: Select Infrastructure

• Evaluate the custody spectrum: third-party custodian, collaborative custody, or self-custody
• Run technical due diligence on shortlisted providers
• Verify compliance certifications (SOC 2 Type II, insurance coverage, geographic distribution)
• Test the signing workflow end-to-end before committing funds

Step 4: Implement Operational Procedures

• Conduct a formal key ceremony with witnesses and documentation
• Distribute backup materials to secure, geographically separated locations
• Configure policy engine rules (amount thresholds, whitelists, time restrictions)
• Run a tabletop exercise simulating a key compromise, signer unavailability, and disaster recovery

Step 5: Ongoing Operations

• Schedule regular key verification (confirm all signing devices are functional and accessible)
• Review and update policies quarterly or when organizational structure changes
• Maintain audit trail exports for external auditors
• Test disaster recovery procedures at least annually

Frequently Asked Questions

What is the difference between a qualified custodian and self-custody for institutions?

A qualified custodian is a regulated entity (bank, trust company, or broker-dealer) that holds assets on behalf of clients and meets specific regulatory requirements. Self-custody means the institution holds its own keys and manages its own signing infrastructure. Certain regulated entities (such as registered investment advisors) are required by the Investment Advisers Act to use a qualified custodian for client assets. Corporate treasuries holding bitcoin on their own balance sheet typically have more flexibility to choose self-custody or collaborative custody models.

How many signers should an institutional multisig configuration have?

There is no universal answer; the right configuration depends on the organization's size, governance structure, and operational requirements. Common configurations include 3-of-5 for corporate treasuries and 4-of-7 for larger funds or custodians. The key design constraint is that the quorum threshold (M) must be high enough that no small group can collude to move funds, but low enough that legitimate transactions can be executed even if some signers are temporarily unavailable.

Does FASB fair value accounting apply to all organizations holding bitcoin?

ASU 2023-08 applies to all entities that hold bitcoin and other qualifying digital assets, effective for fiscal years beginning after December 15, 2024. This includes public companies, private companies, and not-for-profit organizations. The standard requires fair value measurement with changes recognized in the income statement. Early adoption was permitted.

What insurance coverage should an institution expect from a custody provider?

Coverage amounts, terms, and exclusions vary widely. Key questions to ask: What is the total coverage amount relative to assets under custody? What scenarios are covered (external theft, internal fraud, operational errors)? What is excluded (protocol-level vulnerabilities, regulatory actions)? Who is the underwriter, and what is their financial strength rating? Insurance is one layer of risk mitigation, not a substitute for sound security architecture.

What happened with SAB 121, and why does it matter for institutional custody?

SEC Staff Accounting Bulletin 121, issued in March 2022, required entities custodying digital assets for clients to record a liability on their balance sheet for the fair value of those assets, with a corresponding safeguarding asset. This created an outsized capital burden for banks, effectively discouraging them from offering custody services. The bulletin was rescinded in early 2025, removing this barrier and allowing traditional banking institutions to enter the Bitcoin custody market under more standard accounting treatment.

How do businesses and institutions take custody of bitcoin?

Businesses and institutions hold bitcoin using the same private keys and digital signatures as individuals, but they distribute signing authority across multiple keys and people so no single person can move funds. A typical setup uses an M-of-N multisig (for example, 3-of-5), with keys held by different officers in different locations and a policy engine that enforces approval thresholds, spending limits, and separation of duties. The keys can be held entirely by the organization (self-custody), shared with an infrastructure provider (collaborative custody), or held by a regulated qualified custodian, depending on the organization's regulatory obligations and technical capacity.

How do banks store bitcoin for customers?

Banks and qualified custodians typically store customer bitcoin in cold storage, generating and holding private keys inside isolated hardware security modules (HSMs) distributed across multiple secure facilities. Access requires multi-party authorization, and signing happens inside tamper-resistant hardware so the keys never leave in exportable form. Custodians keep client funds segregated from operational funds at the address and wallet level and can provide on-chain proof of reserves. In early 2025, the rescission of SEC Staff Accounting Bulletin 121 removed a major accounting barrier that had discouraged regulated banks from offering bitcoin custody.

Can an institution use hardware wallets like Jade Plus in a multisig setup?

Yes. Hardware signing devices like Jade Plus can serve as individual signing keys within a multisig configuration. Each device holds one key in the M-of-N arrangement, derives child keys on-device using BIP-32 derivation paths, and signs its portion of the PSBT (BIP-174) without exposing the private key. In an institutional context, each authorized signer holds a hardware device, and the custody platform coordinates the collection of signatures from multiple devices to meet the quorum threshold. The air-gapped QR code signing on Jade Plus is particularly suited to institutional environments where signing devices should have no direct electronic connection to networked systems. Both Jade Plus and Jade Classic support multisig configurations and are compatible with coordinator software like Sparrow, Specter, and Nunchuk.