Institutional custody is often reduced to a wallet-label decision: exchange, custodian, or self-custody. That framing is too narrow. The real decision is how an institution designs its control plane, limits its loss paths, and preserves the ability to act when a person, provider, key, market, or operating system fails.
A useful review therefore starts with the full movement of assets and instructions. Who can authorize a transfer? Which systems can pause or reject it? Which counterparties, fiat rails, and service providers are involved? What evidence is retained? And how quickly can the institution contain an incident or recover from it?
Custody risk is not eliminated by moving assets to one “safer” location. It is managed by making authority, dependency, monitoring, and recovery explicit.
Exchange Custody: Platform and Withdrawal Exposure
Exchange custody can be operationally efficient for trading, settlement, and liquidity access. It can also concentrate several risks in one relationship: platform availability, withdrawal controls, asset segregation, account permissions, cybersecurity, and the institution’s ability to obtain timely records.
The review should focus on exposure, not on a provider label. An institution can map the balance held at an exchange, the authority required to move it, the withdrawal limits and review steps, the service-level assumptions, and the dependencies that sit behind the account. A trading venue may also be connected to a prime provider, broker, fiat bank, stablecoin issuer, or third-party technology layer, creating a larger dependency chain than the account statement suggests.
- Define what must remain immediately available for trading, settlement, or liquidity management.
- Separate trading permissions from withdrawal authority wherever the operating model allows.
- Document how balances, transaction history, approvals, and incident communications are exported and retained.
- Test the escalation path for a delayed withdrawal, account compromise, outage, or unexpected platform restriction.
Self-Custody: Ownership Adds Operating Controls
Self-custody changes the institution’s risk surface rather than removing it. Key ownership can reduce reliance on a platform for final authorization, but it introduces controls that must work every time: key generation, access policy, transaction review, signing devices, approval thresholds, backups, role separation, and incident response.
The question is not simply whether an institution “has the keys.” It is whether the institution can demonstrate that no single person, device, location, or undocumented procedure can create an unacceptable loss path. That includes reviewing how signing instructions are created, how destination addresses are verified, how policy exceptions are recorded, and how dormant or emergency access is governed.
Self-custody should be evaluated as an operating process with observable evidence. Policies need an owner, approvals need an audit trail, and control tests need a cadence. If a process depends on one expert’s memory, it is a concentration risk even when the cryptographic design is sound.
Counterparty and Dependency Concentration
Counterparty risk is broader than the legal entity named on a custody agreement. Institutions should map the connected ecosystem across custodians, exchanges, trading venues, lending or prime services, fiat rails, stablecoin exposure, cloud systems, communications channels, and key operational personnel.
Two accounts may look diversified while depending on the same bank, settlement route, software provider, liquidity venue, or stablecoin mechanism. A useful map identifies both direct balances and shared dependencies, then tests what happens if a dependency becomes unavailable, delayed, restricted, or operationally unreliable.
- Custodians and exchanges: where assets sit, how they move, and what authority or documentation each relationship requires.
- Trading and prime services: collateral, rehypothecation assumptions, margin processes, and the operational effect of a venue outage.
- Fiat rails: banking relationships, settlement timing, approval chains, and alternate routes for funding or redemption.
- Stablecoin exposure: the role of each stablecoin in settlement or liquidity, plus the dependencies that could interrupt conversion or access.
- People and technology: privileged users, vendors, cloud accounts, communication channels, and the recovery knowledge held by a small number of operators.
“The strongest custody review starts with the question: what has to fail before this position becomes unrecoverable?”— Dominion Capital Group Inc.
Recovery Is a Rehearsed Capability
Recovery planning is the point at which a custody policy becomes operationally credible. A document that describes backups but has never been tested is an assumption, not a control. Recovery should cover both the technical act of restoring access and the governance required to decide when, how, and by whom restoration occurs.
A practical recovery program addresses:
- Backups: what is backed up, how integrity is checked, and how backup access is protected from the same incident.
- Geographic separation: whether critical materials and authorized personnel are exposed to one location, event, or jurisdiction.
- Succession: how authority transfers if a key operator is unavailable, leaves, or cannot participate in an emergency.
- Incident response: the first actions, communication tree, evidence retention, and decision rights for a suspected compromise or loss.
- Recovery-time objectives: the maximum acceptable time to restore observation, approval, settlement, and full operating access for each asset class.
Recovery exercises should be staged and documented. A tabletop can expose unclear decision rights; a controlled access test can expose missing materials; a timed rehearsal can show whether the stated recovery-time objective is realistic. The goal is not to create a false sense of certainty. It is to reduce avoidable ambiguity under pressure.
A Six-Question Institutional Review Framework
Before selecting or revising a custody model, an investment committee or operating team can use six questions to make the decision concrete:
- What loss paths are we accepting? Name the technical, platform, counterparty, liquidity, people, and process failures that could affect the position.
- Who can authorize movement? Map initiation, approval, signing, withdrawal, and emergency authority, including the controls that separate those roles.
- Which dependencies are shared? Identify common custodians, venues, banks, stablecoins, software, cloud systems, and personnel across supposedly separate positions.
- What evidence proves the controls work? Specify the logs, approvals, reconciliations, access reviews, provider records, and test results the institution expects to retain.
- How do we respond when normal access fails? Set the incident owner, communication route, containment steps, escalation criteria, and recovery-time objective for each material scenario.
- When will we rehearse and reassess? Establish a testing cadence and trigger events such as a new provider, strategy, asset, jurisdiction, key person, or material system change.
The answers do not have to produce one universal custody architecture. A trading allocation may require different controls from a long-duration treasury position. What matters is that each choice has a documented rationale, an accountable owner, a visible dependency map, and a recovery path that has been practiced.
Institutional custody is a control-plane decision. Exchanges, self-custody, custodians, counterparties, and recovery procedures are components of that control plane. Evaluating them together gives decision-makers a clearer view of where authority sits, where concentration accumulates, and what the institution can actually do when conditions change.
This article is an informational risk-evaluation framework, not a provider endorsement or a recommendation to transact in any digital asset.