Who is accountable when crypto crime passes through enterprise-controlled channels?

Accountability usually sits with the organisation that owns the exchange account, wallet, or platform control, even if the criminal actor is external. If a firm extends trust through weak onboarding, poor monitoring, or unclear approvals, the resulting control failure becomes a governance issue as well as a crime response issue.

Why This Matters for Security Teams

When crypto crime moves through enterprise-controlled channels, the issue is rarely just “fraud by an outsider.” The accountability question usually turns on whether the organisation controlled the account, wallet, approval path, or monitoring layer that enabled the transfer. That makes this a governance problem, an access-control problem, and often a sanctions or financial-crime response problem at the same time. NIST SP 800-53 Rev. 5 treats these as enforceable control obligations, not informal expectations.

Security teams often miss the point that enterprise channels can be abused without a technical breach if onboarding, privilege assignment, or review workflows are weak. NHIMG’s Ultimate Guide to NHIs — Why NHI Security Matters Now notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a useful reminder that control ownership matters as much as attacker origin. In practice, many organisations discover accountability gaps only after a disputed transfer, rather than through intentional approval design.

That is why NHI governance, auditability, and clear delegation need to be explicit whenever a platform can move value on behalf of the business. The most common failure is not a missing policy, but a control path that was never made provable.

How It Works in Practice

Accountability follows control. If an exchange account, custody wallet, payment rail, or API-driven transfer system is owned, configured, or approved by the enterprise, then the organisation is expected to show who was authorised, what checks ran, and how anomalies were detected. This is where NHI governance becomes relevant, because many of the operational actors are not people at all, but service accounts, API keys, signing workflows, and automation tools.

Practitioners should think in terms of evidence, not assumptions. A defensible control stack usually includes:

• Named ownership for wallets, exchange sub-accounts, and admin consoles.
• Least-privilege access for humans and non-human identities.
• Step-up approval for unusually large, rapid, or high-risk transfers.
• Transaction logging with immutable timestamps and reviewer identity.
• Continuous monitoring for sanctions exposure, address reuse, and abnormal routing.

On the identity side, this often intersects with the same problems highlighted in NHIMG’s Ultimate Guide to NHIs — Standards: weak lifecycle control, unclear revocation, and poor visibility into privileged machine access. If an API key can initiate value movement, that key is effectively part of the regulated trust boundary and should be governed like any other high-impact credential.

From a control-mapping perspective, NIST SP 800-53 Rev. 5 supports this with access enforcement, audit, and incident-response expectations, while FATF guidance on virtual assets and blockchain analytics explains why traceability alone does not remove responsibility. Current guidance suggests organisations should be able to prove who approved the channel, who operated it, and what automated checks were in place before the funds moved. These controls tend to break down when crypto functions are embedded in fast-moving product teams because ownership is split between finance, engineering, and compliance with no single accountable operator.

Common Variations and Edge Cases

Tighter approval controls often increase friction and slow legitimate transfers, so organisations have to balance speed against evidentiary strength. That tradeoff is especially visible in treasury operations, custody platforms, and customer-facing wallets where user experience pressures can weaken review discipline.

There is no universal standard for every crypto operating model yet, so accountability varies by role. A fintech that merely provides rails may share responsibility with a regulated custodian, while a company running its own wallet infrastructure will carry much stronger control obligations. If third-party processors, bridge services, or hosted wallets are involved, the accountability chain should be documented contractually and operationally, not assumed from vendor branding.

Edge cases also arise when an enterprise is both a victim and a control owner. If a compromised employee, stolen credential, or rogue automation sends funds through an approved channel, the criminal act remains external, but the control failure still belongs to the organisation if the access model, monitoring, or exception handling was inadequate. That is why the strongest programs treat crypto movement as an identity problem as much as a payments problem, using NIST SP 800-53 Rev. 5 Security and Privacy Controls alongside internal NHI lifecycle controls.

For enterprises subject to sanctions, fraud, or digital-asset oversight, the practical question is not whether crime traversed a corporate channel, but whether the organisation can demonstrate reasonable control over that channel before, during, and after the event.

Related resources from NHI Mgmt Group

• Who is accountable when PHI is exposed through ChatGPT Enterprise use?
• Who is accountable when a third-party enterprise application is exploited through a zero-day?
• Who is accountable when CUI is lost through endpoint channels?
• Who is accountable when a crypto exchange account is taken over through recovery abuse?