What are the signs that a bank is not ready to custody cryptocurrency safely?

A bank is not ready if it cannot explain who controls keys, how wallets are segmented, how transactions are reviewed, and what triggers intervention. Weak readiness also shows up when compliance and security teams are not aligned on monitoring, escalation, and customer risk screening. In custody, unclear ownership usually becomes an immediate control gap.

What readiness looks like before a bank takes custody

Safe custody starts with a control model, not a product demo. The bank should be able to describe who owns the keys, how approvals work, how wallet operations are segmented, and where human review is mandatory versus automated. If those answers are vague, the custody design is still immature, even if the technology stack appears polished.

A bank also needs a clear operating picture for transaction review, exception handling, and incident escalation. In practice, that means the custody function, security monitoring, and compliance oversight must share the same rules for intervention. When those teams describe different thresholds, the institution has not yet built a defensible custody process.

For banks, the best readiness signal is not volume or product breadth, but whether control ownership is explicit and testable. A bank that cannot show how it will prevent, detect, and stop an unsafe transfer path is not ready to protect customer assets at institutional scale.

Operational signals that the custody model is weak

One sign of weakness is ambiguity around wallet segregation and approval boundaries. If the bank cannot explain whether custody wallets are isolated by customer, product, environment, or operating purpose, then a single operational mistake can become a broad exposure. Segmentation is not a cosmetic design choice, it is part of blast-radius control.

Another warning sign is reliance on informal review rather than documented intervention criteria. Custody teams should know which transaction patterns require extra scrutiny, which changes trigger approval escalation, and which events pause execution. If staff are improvising those decisions in real time, the bank is depending on judgment where control evidence should exist.

Monitoring gaps matter just as much. A safe custody setup needs traceable approvals, event logging, reconciliation, and alert ownership. When compliance can see screening issues but security cannot act on them quickly, or when security sees anomalies but no one has authority to stop movement, the process is functionally undercontrolled.

Risk and Threat Considerations

Crypto custody concentrates operational and financial exposure in a small number of control points. If key ownership, wallet segmentation, or escalation authority is unclear, a single mistake, insider action, or external compromise can propagate into unauthorized transfers, delayed recovery, or customer loss.

Failure mechanism: Weak custody readiness usually fails through excessive privilege, poor separation of duties, weak transaction screening, or delayed intervention when unusual movement appears. That creates a path where a valid operator, compromised workflow, or misrouted approval can move assets before the bank can respond.

Impact: The result can be direct asset loss, unrecoverable settlement errors, customer harm, regulatory scrutiny, and a custody platform that is difficult to defend after the fact. In a high-value environment, unclear ownership is itself a control failure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Management	Custody readiness depends on who controls keys and wallet credentials.
	NHI-03 — Identity Lifecycle and Offboarding	Custody accounts and access paths must be revocable when roles or risk change.
	NHI-07 — Third-Party and Supply Chain Risk	Custody often relies on external platforms and services that can expand exposure.
Recommendation — Define ownership and rotation rules for custody keys and related secrets. Revoke custody access immediately when responsibilities or trust conditions change. Assess external custody dependencies before allowing asset movement.
NIST CSF 2.0	PR.AC — Access Control	The question turns on whether custody access is segmented and bounded.
	DE.CM — Continuous Monitoring	Safe custody needs transaction review, alerting, and monitored intervention points.
	RS.CO — Communications	Custody readiness requires coordinated escalation between security and compliance.
Recommendation — Enforce least-privilege access and separation of duties for custody operations. Monitor custody events continuously and escalate anomalous transfer activity. Establish clear escalation paths for custody anomalies and intervention triggers.
CIS Controls v8	6 — Access Control Management	Custody safety depends on explicit control of who can approve and move assets.
	8 — Audit Log Management	Transaction review and intervention require durable logs and traceability.
	15 — Service Provider Management	Custody implementations often depend on third parties and outsourced controls.
Recommendation — Review and restrict custody access rights to the minimum necessary. Log custody actions and review them for suspicious or unauthorized changes. Verify third-party custody controls before delegating asset-handling functions.
NIST SP 800-63	IAL — Identity Assurance Level	Banks must know how strongly operators and approvers are verified before granting custody authority.
Recommendation — Set assurance expectations for personnel who can authorize custody actions.

Practitioner Guidance

What to verify: Confirm that the bank can produce a tested custody runbook showing who can authorize key actions, who can block a transfer, and who is accountable when screening flags a problem. If that evidence does not exist, treat the operating model as incomplete rather than merely immature.

Decision rule: If the bank cannot demonstrate segregation of duties, transaction review, and escalation timing in a live exercise, do not treat the custody design as production-ready. Readiness should be proven with scenarios, not asserted in policy language.

Practitioner takeaway: A bank is ready for crypto custody only when authority, visibility, and intervention are explicit enough that a risky transfer can be stopped without debate.