When your institution holds digital assets on behalf of clients or treasury operations, the question is no longer whether custody matters. It is how you architect it so that an internal audit, a regulator, or a court can verify that assets were never at risk of misappropriation or loss through operator negligence. This post covers what digital asset custody actually means in production, the regulatory environment that shapes it, the architectural choices you will face, and the trap that catches practitioners who treat custody as a solved problem.
Let us start with precision. Digital asset custody is not holding tokens. It is a framework of infrastructure, process, and governance that ensures the following:
(1) private keys are controlled by the custodian and accessible only through authorized signing events,
(2) signing events are logged and auditable,
(3) the custodian can prove it never had access to both key material and transaction payload simultaneously, and
(4) assets can be recovered or transferred only through documented, policy-compliant workflows.
This matters because digital assets, unlike securities held at a central depository, exist only as a record on a distributed ledger. There is no certificate. There is no certificate number. There is only a private key and a state transition on chain. If someone signs a transaction with your key without authorization, the asset is gone. There is no insurance wrapper, no DTC reversal, no settlement window to catch the error.
The typical custody deployment separates three concerns: key management (where and how keys are generated, stored, and rotated), signing orchestration (when and under what conditions keys are unlocked to sign), and policy enforcement (what approvals, authorizations, and audit rules apply to each signing event). A custody system that conflates any two of these has a control failure.
For example, if your signing service can generate keys locally, sign transactions locally, and then send signed payloads out to the network, you have merged key management and signing into a single trust boundary. That is not custody. That is a wallet with high availability. A custody deployment separates these: keys live in an HSM or key vault, signing requests come from an application layer that never touches key material, and the signing service enforces policy before it even accesses the key.
The regulatory environment for digital asset custody is crystallizing around explicit liability and separation-of-duties requirements. MiCA (Markets in Crypto-Assets Regulation), which took binding effect in the EU in December 2024, sets Article 70 custody standards that are becoming a de facto global benchmark.
Article 70 requires that a custodian segregate client assets from its own assets, that it segregate assets of different clients (or maintain a documented exception), that it maintain "detailed records" of assets held, and critically, that it maintain insurance or a guarantee fund against loss or misappropriation. The operative phrase is "loss or misappropriation." This is not a best-effort standard. It is strict liability. If you cannot produce audit logs showing that your key material was never accessible during a transaction that harmed the client, you are liable regardless of whether you actually colluded.
BIS reports on CBDC infrastructure, including the 2023 report on distributed ledger technology in post-trade settlement, consistently cite custody as the architectural bottleneck for institutional adoption. Banks running pilot projects (including several we work with) have repeatedly found that regulatory sign-off on custody infrastructure takes longer than technical implementation because regulators require explicit proof of the separation-of-duties architecture, not just a attestation that it exists.
This is why documentation and auditability are not downstream concerns. They are core architectural decisions. Your custody system must generate, in real time, audit-grade logs that a regulator can inspect six months later and reconstruct every signing event, every approval, every policy decision. The BIS 2023 report on post-trade DLT emphasizes this point: institutions that delayed custody implementation typically did so because audit trail generation was retrofitted, not built in from the start.
Here is the mistake we see repeatedly in production deployments: institutions assume that custody implementation is a hardware security module (HSM) integration project. They procure an HSM, integrate it with their signing service, and declare custody "done."
What they discover, usually six months into production, is that the HSM is fast and reliable. The bottleneck is policy enforcement. A Tier 1 bank moving custody into production needs to enforce rules like: (1) a single withdrawal over $5M requires two department heads to approve, (2) withdrawals to non-whitelisted addresses are blocked, (3) outbound transfers during market hours trigger a compliance hold, (4) key rotation requires governance committee sign-off, (5) signing must occur only within designated time windows, (6) transactions fail open (deny by default) unless a policy explicitly permits them.
When you layer these rules onto a signing service, the decision latency grows. Each transaction becomes not just a cryptographic operation, but a state machine that must evaluate dozens of conditions, wait for external approvals, log results to multiple systems (audit trail, blockchain, internal ledger), and handle failure cases (what if the approval system is down? what if a policy conflicts with another?). We have worked with institutions where the policy evaluation engine, not key storage, added 4-6 seconds of latency to outbound transfers. At 500+ daily transactions, that compounds into throughput that no amount of HSM optimization will fix.
The fix is to treat policy enforcement as a first-class infrastructure component, not a validation layer bolted onto the signing service. This means: (1) policy is declared declaratively, not hard-coded in the application, (2) policies are versioned and auditable, (3) the policy engine runs in a separate process from signing (so a policy evaluation hang does not block key access), and (4) policy decisions are logged with their reasoning, not just their outcome.
Institutions we work with that did this upfront — where the policy engine and the signing service are separate components managed by separate teams — deploy custody systems that handle 2000+ daily transactions at sub-second latency. Those that retrofit policy after signing is live typically spend 3-6 months optimizing before they reach the same throughput.
Most institutional custody deployments use a warm wallet model: a portion of assets (typically 1-5% of total holdings) sit in an "active" wallet that can sign transactions without manual intervention, while the bulk sits in cold storage requiring multi-step recovery procedures. For daily transactions (client withdrawals, rebalancing, network fees), you sign from the warm wallet; for strategic moves or recovery scenarios, you sign from cold storage.
The warm wallet itself is not a single address or private key. It is an orchestrated set of signing infrastructure, typically tiered by authorization level. A common pattern: the custody service maintains multiple keys, each tied to a spending tier. Transactions below $10K auto-approve and sign from Tier 1 keys (held in a warm HSM); transactions between $10K and $500K require a single manager approval and sign from Tier 2 keys; transactions above $500K require dual approval from two different business units and sign from Tier 3 keys (potentially held in a cooler environment, adding signing latency). The custody service routes each transaction to the correct tier based on amount and recipient, enforces the approval policy, and executes the signing orchestration.
The key architectural decision is remote signing vs. co-located signing. In remote signing, the custody application (running in your data center or cloud region) submits a transaction payload to a separate, hardened signing service (often on-premise, or in a restricted network zone). The signing service holds the keys, evaluates local policy (rate limits, transaction format validation), signs, and returns the signature. The application never touches key material. This is the model we see at Tier 1 institutions because it cleanly separates the transaction application (which touches untrusted inputs, user requests, network APIs) from the cryptographic material.
In co-located signing, the custody application and HSM are in the same trust boundary, often accessed through a local PKCS#11 interface. This is faster (no network round trip) but makes the threat model much larger: if the custody application is compromised, the HSM is exposed to the same attack surface.
The tradeoff is simple: choose remote signing if you need regulatory separation-of-duties proof and your transaction latency tolerance is above 200ms. Choose co-located signing only if you are operating in a fully controlled environment (closed network, no external APIs, no untrusted inputs) and your throughput target requires sub-100ms signing latency. Most institutions choose remote signing for institutional-grade custody and only consider co-located for treasury operations where throughput is not the constraint.
Three operational details separate production custody from prototypes.
Key Rotation: Keys must be rotated periodically without losing custody of the assets. This means: (1) you generate a new key, (2) you transfer assets from the old address to the new address, (3) you retire the old key. If you do this on chain (transferring assets and waiting for finality), you have created an exposure window where assets are in flight. If you rotate keys without moving assets, you have created orphaned keys that still control assets. The solution is to maintain a mapping of keys to assets in your custody ledger, separate from on-chain state. You generate new keys and maintain them as "hot standby." You rotate the ledger metadata to point new custody requests to the new keys. You retire old keys only after a grace period confirming no asset transfers reference them. This is an operational process, not a cryptographic one, but it is where most custody deployments create audit failures: institutions lose track of which key controls which asset cohort and end up unable to prove they never signed unauthorized transfers.
Access Control: Who can trigger a signing request? In practice, you maintain a signing request queue that applications (client onboarding, treasury management, settlement matching) submit to via authenticated API. The custody service validates that the requester is authorized for this transaction type, amount, and recipient. Authorization is not a binary yes/no; it is a tiered escalation: normal approval paths, exception approvals, manual reviews. When we built support for policy-driven approval workflows at Kaleido, the core decision was whether to handle approvals in the custody service itself or delegate to a separate workflow engine. We chose delegation: the custody service submits requests to a workflow engine (our Workflow Engine component, part of the Web3 Middleware layer), which handles state transitions, multi-approver queues, and timeout escalations. The custody service then polls for approval state before signing. This separation ensures that the cryptographic critical path (the code that touches keys) stays small and auditable, while complex business logic (who can approve what, under what conditions) lives elsewhere and can be changed without touching signing infrastructure.
Auditability: Every transaction that touches key material must be logged with context: who requested it, what was approved, what policy was evaluated, what the signature covers, when the signature was applied, what the on-chain result was. These logs must be immutable (write-once, typically to append-only ledger or log aggregation system like Splunk) and queryable (so that auditors can reconstruct a transaction six months later). In our custody deployments, we generate audit events at four points: (1) signing request received, (2) approvals evaluated, (3) key accessed, (4) transaction submitted on chain. Each event includes request ID, principal (who requested), policy rules evaluated (as a JSON policy snapshot), transaction hash, timestamp, and signing key identifier. This creates a forensic trail that survives key compromise: even if a key is eventually leaked, the audit log proves who was supposed to use it and when.
Custody infrastructure can be built (keep cryptographic material on-premise in your own HSM, orchestrate signing yourself), bought from a specialized custodian (Coinbase Institutional, Fidelity Digital Assets, Kingdom Trust), or hybrid (use a managed custody platform like Kaleido that runs in your cloud account or on-premise, with your keys staying fully in your control).
The choice depends on two factors: regulatory appetite for third-party control, and engineering bandwidth.
Full build (keys on-premise, signing orchestrated in-house): Choose this if (1) you are a Tier 1 bank where regulatory approval for key material to leave your premises is unlikely, (2) you have a dedicated team (4-6 engineers) who can build and maintain signing infrastructure, custody ledger, key rotation, and audit trail generation, and (3) your throughput is under 1000 TPS (above that, the operational burden of scaling and failover becomes significant). The advantage is complete control; the disadvantage is that you now own the entire compliance surface and the operational risk if the system fails or keys are compromised.
Full buy (third-party custodian, your keys in their infrastructure): Choose this if (1) you are not a Tier 1 bank (regulatory friction is lower), (2) you want to reduce operational risk by delegating custody to an expert, and (3) you can tolerate a third party controlling your private keys (many institutions cannot). The advantage is speed to market and reduced operational burden; the disadvantage is regulatory complexity (you are liable for the custodian's failures, which means you must audit them regularly) and loss of key control.
Hybrid (managed platform, your keys in your cloud/on-premise): Choose this if (1) you want enterprise-grade custody infrastructure without building it yourself, (2) your keys stay in your infrastructure (your cloud account, your HSM), (3) you want the flexibility to run the custody service in a shared SaaS environment or your own Kubernetes cluster, and (4) you have compliance teams comfortable with a third party managing the orchestration logic but not the keys. This is the model most Tier 1 institutions are moving toward because it balances control (keys stay yours) with operational efficiency (you do not maintain signing infrastructure).
Most institutions we work with started with the assumption that they would build, ran into policy orchestration complexity within 6 months, and moved to a hybrid managed model. The shift typically happens when the institution realizes that custody is not just infrastructure; it is a regulated business process that changes every time compliance requirements evolve, and maintaining that in-house is staffing-intensive.
We built Kaleido's custody capabilities around the operational pattern we see at Tier 1 institutions: you own the keys, we handle the orchestration. Your private keys stay in your HSM, your cloud account, or your on-premise vault. Our custody layer provides three components: (1) Key Manager, which integrates with PKCS#11 HSMs and remote key vaults, allowing you to request signatures without exposing keys to the application layer, (2) Policy Manager, which enforces approval workflows, spending limits, and time-based rules using OPA (Open Policy Agent), so policy changes do not require code changes, and (3) Custody Ledger, which tracks asset ownership, key-to-asset mapping, and generates audit-grade logs at every signing event.
In our work deploying custody infrastructure at three Tier 1 banks, we found that the operational pain point was not key storage. It was the gap between "key is in the HSM" and "transaction is approved and signed." The application layer needs to request a signature, but before the signing service touches the key, it must evaluate dozens of conditions: Is the requesting principal authorized? Does the transaction exceed spending limits? Is the recipient address on the whitelist? Does the amount match the approved trade? What approvals are pending? When we built the Policy Manager component, the goal was to let institutions declare these rules as policies, not as code. A compliance team can now write a policy that says "any transfer over $5M requires approval from Risk and Treasury," and that policy applies to every signing request without touching the custody application code.
We have also worked closely with our users on the audit trail. When we designed audit event generation, the insight from one Tier 1 client was crucial: auditors do not need the raw logs; they need the ability to ask "show me every transaction involving key X in the last 90 days, with all approvals and policy decisions." This shaped how we structure audit events — not as individual cryptographic operations, but as transaction request flows that include all context. A single request may generate 10 audit events (received, policy checked, approval queued, approved, key accessed, signed, broadcasted, on-chain confirmation), but they are all linked by request ID so auditors can reconstruct the full journey in a query.
What is the difference between custody and a regular blockchain wallet? A wallet generates keys, stores them, and signs transactions. Custody adds separation of duties (keys are not accessible from the signing decision point), policy enforcement (not all signing requests are approved), and auditability (every signing event is logged and queryable). A wallet is personal or application infrastructure; custody is regulated infrastructure designed to prove that assets were never at unauthorized risk.
Do we need an HSM for institutional custody? For Tier 1 institutions, yes. An HSM provides FIPS 140-2 or EAL4+ certification, tamper detection, and generates audit logs of key access that satisfy regulatory review. A cloud key vault can work for smaller institutions or non-regulated custody, but HSMs are the standard for institutions holding client assets.
What happens if a key is compromised in custody? A compromised key in institutional custody is a 1-2 hour incident, not a catastrophe. Because custody systems separate keys from signing orchestration, a single key is never capable of authorizing arbitrary transactions. It can only sign within its tier (e.g., a Tier 1 key might be limited to transactions under $10K). Moreover, audit logs allow you to identify immediately which transactions were signed with the compromised key, which clients are affected, and what recovery action is needed. This is why separation of duties and auditability are not optional — they are how you bound the blast radius of key compromise.
Can we store all our digital assets in a single wallet address? No. Regulatory frameworks like MiCA Article 70 and common-law custody liability require asset segregation. Client assets must be segregated from the custodian's assets. Assets of different clients should be segregated (or you maintain a documented exception). In practice, most institutions use a tiered model: a single "master" address holds net positions, but individual client withdrawals are signed from tier-specific addresses, creating an audit trail that links each transaction to a specific client and approval chain.
What compliance standards apply to digital asset custody? MiCA Article 70 is the EU standard (now effective). The U.S. has no federal custody standard yet, but the SEC has filed custody guidance, and state regulators (particularly New York, under the BitLicense framework) impose custody standards. Common-law trust law and SEC Rule 17a-3 (custodial record-keeping) provide the conceptual basis. ISO 27001 (information security) and SOC 2 Type 2 (internal controls) are operational baselines. Most Tier 1 institutions we work with require custodians to be SOC 2 Type 2 certified and to undergo annual third-party security audits.
Digital asset custody is not a single technology. It is a framework of separated infrastructure layers, policy enforcement, and auditability. The institutions that have moved custody from proof-of-concept to production have done so by treating policy orchestration as a core concern, not an afterthought, and by building audit trail generation into the architecture from the start. Regulatory frameworks like MiCA are moving the needle from "best practice" to "mandatory," which means that today's optional audit requirements are tomorrow's baseline compliance controls.
If you are evaluating custody infrastructure, the questions to ask are: Can keys stay in our infrastructure? Can policy change without code changes? Can auditors reconstruct every signing event six months later? Can we prove separation of duties to a regulator? Most platforms answer yes to one or two of these. Institutions we work with, we help answer yes to all four.
Learn more about how Kaleido's Key Manager, Policy Manager, and Custody Ledger work together to provide enterprise-grade custody infrastructure. Start with our [Custody documentation](https://kaleido.io/docs/) or [schedule a conversation with our team](https://kaleido.io/contact/) to discuss your deployment model and regulatory requirements.
Kaleido makes it click-button simple to build a blockchain, launch a token, and choose your custody solution. Put our platform to work for you.
Request a DemoKaleido makes it click-button simple to build a blockchain, launch a token, and choose your custody solution. Put our platform to work for you.
Request a Demo
