How Banks Evaluate Digital Asset Custody Providers

Institutional digital asset custody is no longer a speculative line item on the innovation roadmap. Banks, asset managers, corporates and public-sector treasuries now hold tokenised securities, regulated stablecoins, central bank digital currency pilots and, in a growing number of jurisdictions, direct cryptoasset exposure on behalf of regulated clients. Whoever holds the keys holds the assets; whoever controls the signing path controls the bank's risk. Custody, in other words, has moved from the edge of the balance sheet to the centre of the control framework.

Selecting a digital asset custodian is therefore a multi-domain decision. A bank's due diligence committee will take evidence from technology risk, operational risk, legal and compliance, information security, internal audit and the business line that intends to use the service. Each function applies its own criteria, and the custodian that clears them all is not always the one with the slickest product surface. This pillar article sets out the framework that a serious evaluation follows: the risk domains that matter, the technical standards that translate risk into concrete engineering requirements, the governance and insurance questions that determine what happens on a bad day, and the structured checklist that a mature bank applies before signing an agreement. Companion articles unpack HSM architecture, multi-signature approval workflows, HD wallet derivation and the insurance and SOC 2 audit questions that recur in every custody evaluation.

A serviceable custody evaluation begins with three risk domains: operational, regulatory and technological. They are distinct but connected. Weakness in any one degrades the others.

Operational risk is the risk that the custodian fails to perform the mechanical functions of custody: safekeeping, segregation, accurate recordkeeping, timely settlement, correct fee accounting and reliable reporting. For digital assets this extends to the signing path, the recovery of keys in the event of loss, the handling of forks and airdrops, the reconciliation of on-chain state against books and records, and the ability to move assets cold-to-warm-to-hot without unacceptable latency or concentration of control. The key operational question is not whether the custodian can perform these functions on a good day; it is whether they continue to perform them on a bad day — during staff turnover, cyber incidents, infrastructure outages, counterparty failures or regulatory interventions.

Regulatory risk covers the legal characterisation of the custodian's services and the supervisory regime under which they operate. A bank cannot outsource a regulated function to a counterparty that is not itself fit to perform it. That means looking at the custodian's licensing posture — trust charter, e-money institution, virtual asset service provider authorisation, or local equivalent — and at the segregation, bankruptcy-remoteness and client-asset rules that apply in each jurisdiction where clients will be served. For banks with international books this is rarely a single-jurisdiction question. It extends to local rules on data residency, on qualified custodian status under investment-adviser regimes, and on travel-rule coverage for transfers above reportable thresholds.

Technological risk is the risk that the custodian's architecture fails in ways that undermine the safekeeping of assets. It is a specific discipline — cryptographic key management, secure enclaves, signing policy, code provenance, deployment integrity — that does not reduce to generic IT risk. A custodian with excellent corporate controls but weak key ceremony or an unaudited signing stack is not an institutional custodian. The converse is also true: a technically sophisticated provider that cannot evidence change management, access control and incident response to a bank's standard is not ready to serve regulated clients.

The three domains combine in the evaluation. Technical strength without regulatory posture is not enough; regulatory posture without operational depth is not enough; neither substitutes for the other.

The most consequential technical question in digital asset custody is how private keys are generated, stored, used and rotated. In an institutional context the default answer is a hardware security module — a dedicated, tamper-resistant cryptographic appliance that holds key material in a secure boundary and performs signing operations inside that boundary without ever exposing the underlying private key. The bank's test is not whether HSMs are mentioned in marketing material; it is whether they are load-bearing in the signing path.

Two standards anchor the conversation. FIPS 140-3 (and its predecessor FIPS 140-2) is the US federal cryptographic module standard. Within FIPS 140-3, the certification levels climb from Level 1 (software-only, minimal physical protection) to Levels 3 and 4, which require tamper evidence, tamper response, identity-based authentication and hardened physical protections. Institutional custody typically requires HSMs validated at FIPS 140-3 Level 3 at minimum; Level 4 appears in central-bank and sovereign-grade deployments. Common Criteria EAL4+ is the European counterpart most often referenced in tender documents. The serious evaluation asks for the validation certificate number and confirms it in the NIST cryptographic module validation database.

The standards, however, set a floor. The architectural questions go further. Where do keys originate — on the HSM, or imported from elsewhere? Is generation witnessed by a quorum of authorised operators, and is the ceremony auditable? How are signing keys segmented between clients, between product lines, between environments? What prevents a compromised application from using a key it should not have access to? How is the HSM backed up, and how is the backup itself protected against single-operator exfiltration? These questions distinguish a custody stack built around HSMs from a custody stack that happens to contain HSMs.

Multi-party computation has emerged as an alternative or complement to HSM custody. In MPC the private key is never assembled in one place: signing is performed by a protocol run among several parties that each hold a share. MPC can be a legitimate architecture, particularly for workloads that require flexible signing topologies across geographies. It does not, however, substitute for the discipline that HSM-backed custody enforces. A bank's evaluation should accept MPC when it is implemented by a provider that can evidence the correctness of the protocol, the integrity of the signing nodes and the protection of the shares — and, in practice, the strongest designs combine MPC with HSM-backed share storage rather than choosing between them. Our HSM architecture article covers this trade-off in more depth.

Technology holds keys. Governance decides when they sign. The bank's evaluation of a custody provider is substantially an evaluation of its signing policy: the rules that determine who can initiate a transaction, who must approve it, what limits apply, and what happens when the rules encounter an exception.

Segregation of duties is the foundational principle. The person who initiates a transaction must not be the same person who approves it, and neither may have unilateral control over the key material that performs the signing. In a mature custody stack these roles are mapped onto distinct operational identities, each backed by strong authentication, and the signing policy is enforced by the custody platform rather than by procedure alone. A provider that describes segregation as an HR practice is not describing segregation; segregation is a property of the signing path.

Multi-signature and quorum approvals take this principle into the cryptographic layer. An M-of-N approval structure requires M of N authorised signers to co-sign a transaction before it is valid. The choices — what M and what N, which roles they map to, how geographically distributed the signers are, what tiers apply to which transaction classes — are operational and risk decisions rather than technical ones. Cold wallets used for long-term reserves typically operate under higher quorums than warm-tier wallets used for operational liquidity; the quorum itself is a risk-adjustment lever. Our separate article on multi-signature approval workflows covers the design space in detail.

Policy must also cover limits and exceptions. Transaction amount limits, daily and monthly aggregates, counterparty allow-lists, address allow-lists, time-of-day restrictions and velocity checks are the controls that convert raw signing capability into a governable service. Emergency procedures — the path by which a compromised or unavailable signer is replaced, the dual-control override for an urgent out-of-policy transaction, the time-locked withdrawal that delays any large movement long enough for human review — are part of the same policy. A custody platform that cannot express these controls as data rather than as bespoke code is not ready for regulated clients.

The three questions a bank asks about worst-case scenarios are: who pays, who verifies, and how do we recover. The answers determine whether a custody relationship is viable.

Insurance is the financial backstop. Specie and crime policies written for digital asset custody cover loss from physical theft, internal fraud, external cyber events and, in some forms, the collapse of the custodian itself. The bank's diligence extends beyond the headline insured amount to the structure of the cover: primary limit, aggregate limit, sub-limits by peril, exclusions, deductibles, the named insured, and the rank of any sub-custodians. A headline figure that aggregates across all clients is a different product from per-client limits with dedicated capacity. Our article on custody insurance and SOC 2 audit covers the structure of institutional cover in practice.

Third-party audit is the independent check on the control environment. The most widely requested attestation is SOC 2 Type II, which evaluates a service organisation's controls over a defined operating period (typically six to twelve months) against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). A SOC 2 Type I snapshot is informative but not sufficient; a bank evaluating a custodian for production use expects a Type II report covering a period that overlaps the current and prior calendar year. ISO/IEC 27001 certification complements SOC 2 by evidencing a management system for information security. PCI DSS applies only where card data is involved. SOC 1, where produced, addresses controls relevant to financial reporting. A mature custodian will map each of these to its control catalogue and will share the reports under NDA.

Recovery is the operational question the audit and insurance framework cannot fully answer. If the primary site is lost, how is custody resumed? If the signing quorum is partially compromised, how is it reconstituted? If the custodian itself fails, what mechanism returns client assets? A robust design separates the signing path from the recovery path: backup key shares are held in jurisdictions and institutions distinct from the operating entity, recovery ceremonies are rehearsed on a schedule, and the bank's client agreement specifies the bankruptcy-remoteness of client assets from the custodian's own estate. Evidence of these arrangements — rehearsal minutes, escrow agreements, client-asset opinions — is what converts a recovery narrative into a recovery plan.

A bank's custody provider operates within a regulatory perimeter, and the shape of that perimeter shapes the relationship. A provider authorised as a trust company or a qualified custodian brings particular statutory protections that a provider authorised only as a virtual asset service provider may not, and vice versa in jurisdictions where the VASP regime is the relevant one.

In the United States, the qualified-custodian requirement for investment advisers and the trust-charter approach to digital asset custody in specific states (notably New York and Wyoming) set the frame. In the European Union, MiCA has established a harmonised regime for cryptoasset service providers with specific obligations for custody. In the United Kingdom, FCA registration for cryptoasset activities sits alongside the broader financial-services regime. In Singapore, MAS applies the Payment Services Act to digital asset custody and layers additional requirements for institutional service. In the Gulf, ADGM and DIFC operate dedicated cryptoasset frameworks and VARA governs the Dubai perimeter. In Pakistan, the PVARA framework establishes the licensing regime for virtual asset service providers.

The evaluation follows the footprint of the business. A bank planning to serve clients from multiple jurisdictions will require its custodian to evidence authorisation in each, or to route each jurisdiction through the correct authorised entity. Cross-border arrangements require particular attention to client-asset segregation rules: a jurisdiction's protections do not extend automatically to assets held offshore, and the bank's legal opinion on the provider's insolvency treatment must cover the actual jurisdiction in which the assets are held rather than only the jurisdiction in which the contract is signed.

Bridge operates a custody stack designed against the framework set out above. Key material is held in HSMs validated at FIPS 140-3 Level 3, with ceremony-based generation and quorum-enforced backup. The signing path is segmented by tier — cold, warm, hot — and by product line, with distinct key hierarchies mapped to HD wallet structures that support per-client account segregation and reproducible address derivation.

Signing policy is expressed as data inside Bridge's orchestration layer. Multi-signature quorums, per-role approval tiers, amount and velocity limits, counterparty and address allow-lists and time-locks are configured per client and per tier. The policy engine sits in the same orchestration service that coordinates identity, compliance and settlement, so a custody decision inherits the KYC status, the risk score and the regulatory context of the client and the transaction in one evaluation rather than several. Our companion multi-signature workflows article describes the policy surface in detail.

On the assurance side, Bridge maintains SOC 2 Type II attestation, ISO/IEC 27001 certification and a client-asset opinion under the relevant jurisdictional regime for each licensed entity. Cryptoasset insurance is structured per-client where the client's risk profile requires dedicated capacity, with specie cover for cold-tier holdings and crime cover for operational tiers. Recovery procedures are rehearsed on a fixed schedule and the outputs of each rehearsal form part of the audit record.

The proposition is not that Bridge holds every credential that every bank asks for in every jurisdiction on day one. It is that the framework set out in this article is the framework we use internally to build and evidence the custody stack, and that the evidence is available for diligence on request. A custodian that treats the evaluation framework as the product roadmap is the custodian that is built for regulated clients.

A structured checklist is the discipline that prevents a custody evaluation from drifting into either technology fetishism or generic vendor management. The list below is not exhaustive — every bank will add its own items — but it covers the material a serious evaluation will expect in the data room.

On corporate and regulatory posture: entity structure, group chart, ultimate beneficial ownership, licensing in each jurisdiction of operation, regulatory register entries, most recent supervisory correspondence (to the extent shareable), sanctions screening of officers, and confirmation of no open enforcement action.

On financial standing: audited financial statements for the most recent two to three years, capitalisation against regulatory minimums, off-balance-sheet commitments, sub-custodian relationships, and client-asset segregation evidence.

On technology and security: HSM make, model and validation certificates; key ceremony procedures and witnessed-ceremony records; signing policy description and change-control; source-code provenance and build-integrity evidence; production-environment access control; penetration test reports for the most recent two cycles; SOC 2 Type II for a period covering the current and prior year; ISO/IEC 27001 certification; incident history and post-mortem samples.

On governance and operations: organisation chart for the custody business; role descriptions for key-holding personnel; segregation-of-duties evidence; four-eyes and M-of-N implementations; transaction limit and allow-list configuration; exception procedures; business-continuity plan with RTO/RPO targets; disaster-recovery rehearsal records; third-party dependency map.

On insurance: specie and crime policies with carrier names, limits, sub-limits, deductibles, exclusions, aggregate structure and named insured; evidence of premium payment; broker contact; claims history.

On client-asset protections: bankruptcy-remoteness opinion, segregation-of-assets opinion, sub-custodian legal framework, termination and transition procedures, client-asset return mechanism under stress scenarios.

On integration and reporting: API specification, message formats, SLAs and credit support; reporting frequency and content; reconciliation method against on-chain state; audit-log retention and format; incident-notification protocols.

Banks that run this checklist consistently get comparable evidence from competing providers, and comparable evidence is what makes a defensible decision. A provider that fails to produce material against any item is not necessarily disqualified, but the gap is a finding, and the finding is a cost. The framework converts a marketing conversation into a risk conversation, which is the conversation the regulator expects.

Digital asset custody for regulated clients is a mature discipline, even though the assets it protects are still evolving. The framework — risk domains, key management, governance, insurance, audit, licensing, recovery — is the same framework a bank applies to any critical outsourced service, translated into the specific terms of cryptography and ledger architecture. Banks that run a serious evaluation get a custody provider that is fit for the risk. Banks that accept marketing for evidence get a provider that looks fit until the day it is tested.

The companion articles in this series take four of the questions this pillar surfaces and go into implementation depth: HSM-backed architecture, multi-signature approval workflows, HD wallet derivation for institutional custody and custody insurance and SOC 2 audit. For a discussion of how custody fits alongside the other elements of a regulated digital-finance stack, see our pillar on cross-border payment infrastructure and the product pages for bank custody and asset-manager custody. To schedule a custody review against the framework in this article, contact us at /contact.