Who is accountable when exchange exposure leads to sanctions or AML failures?

Why This Matters for Security Teams

Exchange exposure is not just a technical incident; it is a governance failure that can trigger sanctions breaches, AML control gaps, and regulatory reporting obligations. The accountability question usually spans the operator, compliance leadership, legal review, and the owners of onboarding and offboarding workflows. When access, jurisdiction screening, and transaction monitoring are fragmented, no single team can prove it had effective control over the risk path.

That matters because regulators and auditors look for evidence, not intent. A plausible policy is not enough if third-party wallets, API keys, or privileged admin access are left active after a relationship should have ended. NHIMG’s research on The 52 NHI Breaches Report shows how often exposures turn into operational compromise when identity lifecycle control is weak. In practice, many security teams discover accountability gaps only after an investigation has already tied an exposure to a reportable compliance failure.

How It Works in Practice

Accountability should be assigned to the people who own the control points, not only the people who respond after the fact. For an exchange, that usually means compliance owns AML rule design and case escalation, operations owns customer and counterparty onboarding, security owns secrets and access protection, and executive governance owns risk acceptance and regulatory sign-off. The control chain must cover who approved access, who reviewed jurisdictional restrictions, who monitored suspicious activity, and who confirmed offboarding when relationships changed.

Current guidance suggests that defensible accountability depends on evidence across the full lifecycle: customer due diligence, sanctions screening, transaction monitoring, privilege management, and incident escalation. The FATF Recommendations remain the baseline for AML and KYC governance, while NIST SP 800-53 Rev. 5 Security and Privacy Controls is useful for mapping control ownership, monitoring, and auditability. For exchange environments that rely on automation, the identity of the system itself matters too. NHIs, service accounts, and API keys often execute screening, withdrawals, and reconciliation, so their permissions should be reviewed like any other privileged asset. NHIMG’s Guide to the Secret Sprawl Challenge is relevant here because hidden credentials and duplicated secrets often make it impossible to prove who could actually act on the exchange’s behalf.

• Define a named control owner for sanctions screening, AML monitoring, and offboarding.
• Maintain evidence of access reviews, escalation decisions, and exception approvals.
• Treat automation accounts and API keys as governed identities with lifecycle records.
• Document jurisdiction blocks and relationship terminations in a way auditors can trace.

These controls tend to break down when exchange activity spans multiple legal entities or outsourced onboarding platforms because the evidence chain becomes split across systems and no single owner can reconstruct it quickly.

Common Variations and Edge Cases

Tighter sanctions and AML control often increases operational overhead, requiring organisations to balance speed of onboarding against assurance, traceability, and legal defensibility. In practice, some failures arise even when policy looks sound, especially where local subsidiaries, broker relationships, or embedded finance partners use different screening thresholds or case-management tools. There is no universal standard for delegated accountability in those structures, so the governance model has to be explicit.

One common edge case is when exposure comes from an NHI rather than a human operator: an API token, bot account, or reconciliation service may have initiated the prohibited action, but the accountability still sits with the organisation that issued, approved, and failed to constrain that identity. Another edge case is delayed offboarding, where a dormant integration can continue to route transactions after a counterparty has been restricted. The same logic appears in broader AI-enabled operations as well, where autonomy increases the need for clear ownership and audit trails. Anthropic’s report on first AI-orchestrated cyber espionage campaign is a reminder that tool-using systems need explicit governance, not informal trust. Current guidance suggests the safest approach is to assign accountability at the control-owner level, then verify that identity, access, and monitoring evidence all point back to that owner.

Related resources from NHI Mgmt Group

• Who is accountable when KYC and AML failures lead to financial crime exposure?
• Who is accountable when credential abuse leads to operational loss?
• Who is accountable when segmentation failures lead to patient-impacting disruption?
• Who is accountable when lateral movement leads to a breach?