● Evaluate digital asset custody providers against four criteria. Review regulatory licensing, insurance terms, security architecture, and integration requirements.● Confirm that each license covers the legal entity, services, and jurisdictions your institution will use. A general claim of being regulated provides too little information.● Read insurance policy language for covered wallets, assets, incidents, limits, and exclusions. Headline coverage amounts cannot show whether your loss scenario qualifies.● Match MPC, cold storage, or a hybrid model to transaction frequency and governance needs. Treat custody as one component within the broader tokenization build.

Why custody evaluation is different from picking a vendor off a list

A vendor list helps you identify candidates, but institutional due diligence tests whether a custodian can operate within your legal, risk, and technology requirements. Use the vendor comparison article for the ranked shortlist. Use this guide to examine the evidence behind each provider’s claims.

Licensing requires more than confirming that a regulator oversees the provider. You need to identify the licensed legal entity, understand whether it holds a state or federal trust charter, and verify that its permitted activities cover your intended service. Insurance requires similar scrutiny because crime, specie, cyber, and professional liability policies respond to different losses.

Security architecture and integration determine how custody works after contracting. MPC can support faster distributed approvals, while cold storage can reduce remote exposure for low-frequency holdings. Neither model resolves integration with treasury systems, compliance controls, reconciliation, reporting, and approval workflows.

A defensible review therefore follows four workstreams. Legal and compliance staff verify licensing. Risk staff inspect insurance terms and security controls. Treasury and technology staff test transaction governance, APIs, system compatibility, and operating overhead.

Regulatory licensing: what actually matters

● A vendor’s licensed status tells you little until you identify the licensed legal entity, its regulator, and its permitted activities. Buyers should review the charter, approval orders, supervisory restrictions, and service contract. A parent company’s registration does not necessarily cover the subsidiary that will hold your assets.

An OCC national trust bank charter places the custodian under one federal prudential regulator. Anchorage Digital Bank provides the established digital asset example. The OCC can authorize national trust banks to conduct custody and other fiduciary activities, but those banks cannot accept demand deposits or make general loans. Crypto activities also remain subject to supervisory review and risk-control expectations. Anchorage’s earlier consent order illustrates how approval and continuing compliance operate as separate questions. The national trust bank framework can reduce dependence on separate state licensing paths, but OCC supervision may require more resources.

Federal approval also should not be inferred from an application. The OCC’s digital asset licensing table lists multiple applications filed during 2026, including applications associated with Dakota, Payward, Agora, and EDX. Each application remains distinct from a final charter, and conditional approval may still require the applicant to meet operational requirements before opening.

State trust charters create a different route. A state regulator authorizes the trust company under its own statutes, and the available powers vary by jurisdiction. Some states move faster on new digital asset activities, while a state-chartered custodian may face additional analysis when serving clients or conducting activities across state lines. Buyers should ask whether the charter covers the specific custody service, asset type, and customer entity in the proposed contract.

Your institutional profile should guide the licensing review.
● A bank-affiliated buyer should examine whether its regulators will accept the custodian’s supervisory regime and whether the arrangement fits the bank’s third-party risk requirements.● A non-bank asset manager should determine whether the custodian satisfies every applicable custody obligation. A trust charter alone does not resolve the full legal analysis.● A trust company should compare the provider’s powers with its own fiduciary duties and determine which responsibilities remain with each party.

Procurement teams should request the charter certificate, current approval orders, examination authority, and any enforcement actions. Counsel should then map those documents to the planned service rather than treating “OCC chartered” or “state regulated” as a complete conclusion.

Insurance coverage: reading the policy, not the headline number

A custody insurance limit does not explain which events qualify for payment. Buyers need to examine each policy form, its exclusions, and the share of the limit available to their institution. A $500 million policy may provide limited protection if all clients share the limit or if the policy excludes the wallet configuration you use.

Custody programs commonly combine four forms of coverage. Crime insurance may cover external theft, employee dishonesty, fraudulent transfer instructions, and physical theft of key material. Specie insurance treats assets under the custodian’s control as property and often focuses on cold-storage devices, transit, or mysterious disappearance. Errors and omissions coverage can respond to negligent key management or failed execution. General cyber liability usually addresses incident response, data restoration, ransomware, and business interruption, but cyber policies often exclude professional negligence and executive liability.

Public disclosures show why buyers cannot compare custodians by limit alone. One published comparison reports $250 million of primary specie coverage for BitGo cold storage, a $320 million crime policy for Coinbase hot and cold wallets, and $500 million of specie coverage for Copper cold storage. The same comparison lists $30 million of protection for assets held through Fireblocks and an undisclosed crime policy for Anchorage Digital covering assets while hot, cold, or in transit. Those figures describe different risks and coverage structures, so they do not establish which provider offers greater protection. Policy limits, covered custody states, and treatment of key control vary materially.

Shared-key arrangements require specific review. In a multi-party computation setup, your institution may hold one key share while the custodian or another party holds the others. Some policies cover a loss only when the custodian controls all required key material. Ask the insurer to confirm in writing how coverage applies to every proposed signing configuration, including backup shares and disaster-recovery arrangements.

Social engineering creates another common gray area. Crime policies may cover employee dishonesty, but policy language can treat an employee who follows fraudulent instructions differently from an employee who intentionally assists a theft. Buyers should test scenarios involving compromised support staff, approval-workflow manipulation, phishing, and stolen client credentials.

Request the certificate of insurance and full policy wording under a nondisclosure agreement. Review aggregate and per-client limits, deductibles, sublimits, named insured status, loss-payee rights, territorial restrictions, and excess-policy layers. Confirm whether protocol failures, smart contract exploits, regulatory seizure, and client-side credential loss remain excluded.

Insurers increasingly use SOC 2 Type 2 reports to assess whether controls operated consistently over time. Ask for the current report, any exceptions, and remediation evidence. An audit report supports insurability, but the policy language determines whether a specific loss receives coverage.

MPC vs. cold storage: choosing the right security model

MPC distributes control of a wallet across several key shares. A threshold signature scheme requires a defined number of shares, such as three of five, to approve a transaction. The parties create the signature together without assembling the full private key in one place. Modern MPC systems can also refresh or replace shares without changing the wallet address, which supports staff changes and disaster recovery without moving the assets.

Cold storage keeps signing keys offline and commonly protects them with air-gapped devices or hardware security modules. Network isolation reduces exposure to remote attacks, but each transfer may require physical access and a controlled key ceremony. Hardware security modules can provide detailed logs and certifications familiar to auditors. However, custody continuity depends on device availability, secure backups, and lifecycle management. An unavailable device or failed recovery procedure can delay access or cause permanent loss.

MPC generally fits institutions that need frequent transactions, automated liquidity access, or approvals across regions. Distributed shares let authorized staff sign without gathering around one physical device. Policy engines can enforce thresholds, withdrawal delays, and approved destination addresses. MPC still requires careful control design because a provider may hold one share and therefore participate in every transaction or recovery event. Buyers should establish who stores each share, who can replace it, and what happens if the provider becomes unavailable.

Cold storage generally fits long-term reserves and other holdings with low transaction frequency. Physical isolation limits the remote attack surface, while slower access creates less operational friction when withdrawals are rare. Buyers should test the complete recovery procedure rather than accepting a description of backup hardware. The test should cover device failure, loss of an authorized employee, and access during a regional disruption.

Auditability depends on the custodian’s records as much as its cryptography. MPC signatures usually do not reveal the internal approval structure on-chain, so you need logs that identify participating shares and applied policies. Cold-storage reviews should document device custody, ceremony participants, and every movement between offline and connected environments. HSMs remain familiar to institutional auditors, while MPC can provide verifiable internal signing records when the provider exposes enough detail.

A hybrid model suits institutions that separate working liquidity from strategic reserves. MPC can govern active wallets, while air-gapped hardware protects low-frequency holdings. Some designs also store individual MPC shares inside HSMs or keep one share offline, combining distributed authorization with hardware isolation.

The chosen model should match the insurance policy language. MPC buyers must determine whether coverage applies when one share is compromised, when the custodian controls only one share, or when an employee approves a fraudulent transfer. Cold-storage buyers should examine exclusions involving device access, key ceremonies, and backup handling. Insurance certificates that refer broadly to keys or wallets may not resolve these scenarios.

Integration complexity: the cost buyers underestimate

Integration often delays institutional custody programs because the custodian must connect with existing ledgers, compliance controls, treasury tools, and reporting systems. API availability alone does not prove that those components will work together. Institutional infrastructure remains tightly coupled, so buyers should assess the complete transaction path before signing a contract.

Three friction sources shape the integration workload. Data standardization determines how wallet addresses, transaction hashes, fees, and token balances map into systems built for cash or securities. Process alignment determines how continuous blockchain settlement fits with batch reconciliation, cutoffs, and exception handling. Control and governance determine whether every transfer preserves segregation of duties, policy enforcement, and an audit trail across multiple systems.

Buyers should test each architecture layer with a representative transaction and failure scenario.
● Test the client interface. Confirm that users can initiate, review, approve, cancel, and investigate transactions under role-based permissions. Ask how the interface handles incomplete data and unavailable downstream services.● Test transaction orchestration. Follow a transfer through validation, approval, signing, broadcast, confirmation, and reconciliation. The vendor should expose each state through documented APIs and event notifications rather than forcing your systems to poll for updates.● Test custody and key management. Determine where signing components run, who controls them, and how recovery works. Ask whether hardware security modules or key shares can operate in your cloud environment and how the vendor handles upgrades without interrupting access.● Test governance and compliance. Confirm that the policy engine applies limits, address allowlists, sanctions screening, blockchain transaction monitoring, and Travel Rule checks before approval. Post-transaction screening may identify a problem after assets have already moved.● Test ecosystem connectivity. Verify support for the specific blockchains, exchanges, liquidity providers, and banking rails your program will use. Generic connector lists do not establish compatibility with your account structures or reconciliation requirements.

Day-two operations can cost more than the initial API work. Key ceremonies require authorized participants to create, distribute, rotate, or recover signing material under documented controls. An m-of-n quorum requires a defined number of named approvers to act, which creates staffing and escalation needs outside normal hours. Institutional transaction flows may also require policy checks, KYT screening, Travel Rule validation, and executive approval before signing occurs, with security events sent to existing monitoring tools in real time (example institutional flow).

Due diligence should therefore include operating procedures, failure testing, staffing assumptions, and ownership boundaries. Buyers need to know who investigates blocked transfers, who updates compliance rules, and who restores service when a custody component or connected network fails.

Custody selection is one decision inside a larger build

A custody provider secures private keys and enforces transaction authorization policies. Its services may also include wallet infrastructure, settlement connectivity, and transaction reporting. The provider remains one component within a tokenization program.

An implementation partner connects the selected custodian to core banking systems and the wider tokenization stack. It also translates compliance requirements into approval workflows, transaction monitoring checks, and audit records. These integrations determine how assets move between issuance, custody, trading, and redemption.

Custody selection should therefore follow the institution’s target architecture and operating model. A provider may pass security and licensing reviews but still create problems if its APIs cannot support existing systems or its approval model conflicts with internal controls. Buyers should test those dependencies before signing a long-term agreement.

Restart Fintech serves as an implementation partner rather than a standalone custody provider. Restart Fintech helps banks, asset managers, and trust companies integrate their chosen custodian into custom tokenization infrastructure without building an in-house blockchain team. Institutions planning a tokenization program that includes custody can contact Restart Fintech to scope the architecture, integration work, and fractional CTO support required for launch.

FAQs