Who is accountable when digital asset firms expand banking access and custody under evolving rules?

Why This Matters for Security Teams

When banking access expands into digital asset custody, the core issue is not just product eligibility. It is whether the firm can show who owns the control environment across onboarding, access approvals, transaction oversight, segregation of duties, and incident escalation. That matters because regulators and auditors do not treat policy change as a control. They look for named accountability, evidence of review, and consistent enforcement across business, compliance, and operations. NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls remains useful here because it makes ownership, monitoring, and auditability explicit.

The practical risk is that firms assume “the rule changed” means the governance problem is solved. It does not. Expanded access often introduces new counterparties, new wallets, new custodian relationships, and new operational dependencies that stretch existing approval chains beyond what they were designed to handle. If those relationships are not mapped to accountable control owners, gaps appear first in exception handling, then in reporting, then in loss events or supervisory findings. In practice, many security teams encounter accountability failures only after a control exception, customer complaint, or regulatory challenge has already exposed the lack of ownership.

How It Works in Practice

Accountability should be established as a governance model, not as an after-the-fact explanation. The institution needs a clear control matrix that ties each material obligation to a named function: risk acceptance, compliance review, legal interpretation, custody operations, technology controls, and independent assurance. For digital asset firms, that often includes explicit ownership for wallet access, key management, transaction limits, vendor due diligence, and reconciliation. For banks, it also includes the boundary between traditional banking controls and digital asset-specific controls, especially where custody or settlement flows cross teams.

A sound operating model usually includes:

• Named control owners for every high-risk activity, including approvals and exception handling.
• Documented escalation paths for breaches, suspicious activity, and control failures.
• Periodic attestation that policy, procedure, and system enforcement still match the approved business model.
• Independent testing of access, logging, reconciliation, and segregation-of-duties controls.
• Evidence retention that supports supervisory review and internal audit.

This is where identity governance becomes more than a back-office issue. Custody and banking expansion frequently introduce non-human identities such as service accounts, API keys, signing services, and orchestration tooling. Those identities can become the hidden operators of the business process, which is why the OWASP Non-Human Identity Top 10 is relevant to governance, not just engineering. If service accounts can move assets, trigger approvals, or access ledgers, their ownership and lifecycle must be as explicit as any human role.

Control design should also reflect the reality of shared accountability. Compliance may define the rule set, but operations typically runs the day-to-day control, while technology implements enforcement and risk validates whether the control is actually effective. The governance challenge is to avoid ambiguous handoffs. These controls tend to break down when custody, payments, and compliance operate in separate tooling stacks because evidence becomes fragmented and no single owner can prove end-to-end accountability.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster market access against stronger review, evidence, and escalation discipline. That tradeoff becomes sharper when rules are still evolving, because firms may need to launch with interim controls while legal and compliance interpretations remain unsettled.

Current guidance suggests a few recurring edge cases deserve special attention. First, outsourced or third-party custody arrangements do not remove accountability from the regulated firm; they only change where evidence must be collected. Second, where a banking partner and a digital asset firm share a control boundary, there is no universal standard for assigning responsibility, so contracts and operating procedures must state who owns the decision, who monitors it, and who reports issues. Third, non-human identities used for custody operations can blur accountability if their permissions are inherited from generic platform roles rather than assigned to a specific service owner.

For firms subject to broader operational resilience expectations, accountability should also be aligned with incident response and business continuity. That is especially important where custody, liquidity, and client access are tightly coupled. The practical test is simple: if a supervisor asks who approved a risky workflow, who can show the evidence without internal debate? If the answer depends on informal knowledge, the control model is not mature enough for expanded access.

Related resources from NHI Mgmt Group

• Who is accountable for access to retained data under lawful-access rules?
• Who should be accountable for access review decisions under SOX or ISO 27001?
• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when VPN-based access controls fail under the Online Safety Act?