Subscribe to the Non-Human & AI Identity Journal

Who is accountable when mule accounts are used to launder stolen funds?

Accountability is shared across the institution that opened the account, the team that monitored it, and the counterparties that accepted its activity signals. In practice, the failure is usually a lifecycle gap, a response gap, and a coordination gap happening together. The organisation that can act fastest on evidence usually has the best chance of limiting loss.

Why This Matters for Security Teams

Mule-account laundering is rarely a single-owner failure. It usually starts with weak onboarding, incomplete KYC or KYB signals, poor transaction monitoring, and slow interdiction when suspicious movement appears. Under NHI Management Group guidance, the same lifecycle problem shows up in other identity classes too: the Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that identity misuse becomes systemic when accountability is fragmented. Fraud teams, account-opening teams, and operations all influence whether a mule account is created, tolerated, or removed.

The practical question is not just who made the first mistake, but who had the clearest duty to detect, freeze, escalate, and preserve evidence once laundering signals emerged. That is why accountability needs to be mapped across the full account lifecycle, not treated as a single-line owner on a chart. Guidance from the 52 NHI Breaches Analysis reinforces that breach patterns often persist because no one owns the handoff between creation, monitoring, and revocation. In practice, many security teams encounter mule-account abuse only after funds have already been dispersed, rather than through intentional early containment.

How It Works in Practice

Accountability should be assigned by control point, not by hindsight. The institution that opened the account owns customer due diligence, sanctions screening, risk scoring, and ongoing review. The monitoring team owns alert triage, anomaly detection, and case escalation. Payment operations own holds, freezes, recalls, and suspicious activity preservation. Counterparties that accept rapid, inconsistent, or patterned inbound flows also carry responsibility to investigate their own exposure. This is less a moral question than an operating model question: every transfer path needs a named decision-maker.

Operationally, the strongest approach is to define explicit triggers and response SLAs. For example:

  • Account opening: verify beneficial ownership, device and behavioral risk, and expected transaction profile.
  • Ongoing monitoring: flag velocity changes, round-dollar layering, split transfers, and account hopping.
  • Containment: freeze or limit movement when thresholds are crossed, with documented escalation authority.
  • Evidence handling: preserve logs, timestamps, beneficiary details, and analyst actions for legal and regulatory review.

The control logic should be supported by policy, not ad hoc judgment. Current guidance suggests using clearly mapped ownership across fraud, compliance, security, and operations, with a single case lead during active investigations. Where institutions already track identity lifecycle rigorously, they can detect misuse faster and reduce dwell time. That same lifecycle discipline is reflected in the NHI context, where NHI Management Group stresses that visibility, rotation, and offboarding are inseparable from governance. These controls tend to break down when mule activity spans multiple business units because ownership becomes unclear at the exact moment rapid action is required.

Common Variations and Edge Cases

Tighter fraud controls often increase friction for legitimate customers, requiring organisations to balance loss prevention against onboarding speed and service experience. That tradeoff matters most in high-risk corridors, agent-assisted account opening, and instant-payment environments where the window to act is short. There is no universal standard for this yet, but best practice is evolving toward shared accountability registers and clear response playbooks.

Edge cases create the biggest ambiguity. A newly opened account may be the responsibility of the onboarding team until the first suspicious transfer, then of the monitoring team once alerts fire, and finally of the incident lead once funds begin to move. If a counterparty bank ignores obvious mule indicators, accountability does not disappear upstream; it becomes shared across the institutions that failed to act on available evidence. Where AI-assisted screening is used, the human owner still remains accountable for model tuning, false-positive review, and override decisions. The Anthropic report on AI-orchestrated cyber abuse is a useful reminder that automation can accelerate abuse pathways, but it does not replace human accountability for control failure. In practice, the hardest cases are correspondent and fintech partnerships where each party assumes the other is watching the same risk signals.

Standards & Framework Alignment

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

NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST CSF 2.0 ID.AM-1 Accountability depends on knowing who owns each account and transfer path.
NIST CSF 2.0 RS.MI-1 Mule-account laundering requires rapid containment once suspicious activity appears.
NIST AI RMF AI risk governance supports accountable use of automated fraud screening and review.

Maintain a current inventory of account owners and control handoffs across onboarding, monitoring, and response.