How should AML, fraud, and IAM teams work together on laundering cases?

Why AML, fraud, and IAM need a shared case picture

Laundering cases usually cross team boundaries because the suspicious pattern is not just a transaction problem or just an account problem. AML sees movement, fraud sees abuse of the customer journey, and IAM sees who controlled the account, when access changed, and whether the same entity kept reappearing under different labels. The practical goal is a single narrative that connects identity, access, and flow.

That shared picture should start with entity resolution, then extend to account ownership intelligence and transfer-pattern analysis. If teams do not reconcile those three views, they will miss the path from onboarding to account control to cash-out, which is often where laundering and fraud overlap most clearly.

Teams also need to treat identities as investigative anchors rather than isolated system records. A customer profile, a mule network, a beneficiary account, or a login history may each look incomplete on its own, but together they show whether the same actor is steering multiple accounts, reusing access, or coordinating a layered movement chain.

What each team contributes to the investigation

AML teams usually bring typologies, transaction monitoring, sanctions and suspicious activity context, and the ability to see whether movement patterns resemble layering, structuring, placement, or rapid pass-through. Fraud teams usually see the behavioural signals first, including application abuse, account takeover, synthetic identity patterns, and velocity anomalies around onboarding or payout. IAM teams contribute the control-plane evidence: authentication events, account ownership, role changes, step-up challenges, privileged access, session anomalies, and the access paths that explain how the account was used.

The strongest investigations combine those perspectives in a common case file. If AML flags transfer behaviour, fraud can validate whether the account was opened or manipulated under suspicious conditions, and IAM can confirm whether the access trail matches the claimed owner or a compromised, shared, or delegated identity. That is how teams separate ordinary customer activity from coordinated abuse.

Shared triage also prevents a common failure mode where each team treats the case as someone else’s problem. A laundering case often begins as a small anomaly in one domain, but it becomes actionable only when another team supplies the missing boundary, such as a device, login, or entitlement change that makes the transfer chain intelligible.

How to operationalise joint laundering work

The most useful operating model is a common investigation workflow with agreed handoffs. The teams should define a shared entity graph, a standard set of escalation triggers, and a clear ownership rule for each case stage so that alerts do not stall between surveillance, investigation, and access review.

• Use entity resolution to merge customer, beneficiary, device, and account records that may otherwise be treated as separate cases.
• Use transfer-pattern analysis to spot structuring, rapid movement, circular flows, and pass-through behaviour that indicate laundering mechanics.
• Use account ownership intelligence to confirm whether the actor controlling the account is the same person or entity that opened it, authorised it, or benefited from it.
• Use IAM telemetry to validate authentication strength, session continuity, privilege changes, delegated access, and suspicious access reuse.

This is also where data quality matters. If naming, ownership, or identity attributes are inconsistent across systems, the case will be fragmented and analysts will overfit to whichever view is easiest to query. The teams need a repeatable correlation method, not ad hoc screenshots or manual reconciliation.

Risk and Threat Considerations

When AML, fraud, and IAM do not share the same investigative frame, laundering activity can hide behind ordinary account lifecycle events, reused access, or identity ambiguity. The risk is not limited to missed alerts. It also includes weak attribution, duplicate investigations, delayed interdiction, and a false sense that one team has already contained the problem.

Failure mechanism: An actor can exploit the gap between onboarding controls, account control, and transaction monitoring by moving through compromised, mule, or shell identities while each team sees only its own slice of the case. Identity changes, delegated access, and rapid movement can make the same behaviour appear unrelated across systems.

Impact: The organisation may fail to connect placement, layering, and cash-out, allowing laundering to continue across channels. That increases financial loss, regulatory exposure, and the chance that a compromised or abused account is reused for additional fraud or downstream abuse.

Practitioner Guidance

What to prioritise: Start with the overlap zone, not the isolated alert. If a case has suspicious transfers and suspicious account behaviour, treat it as a shared investigation and assign one analyst from each function to build a single timeline.

What to verify: Confirm whether the account owner, the authenticated user, and the beneficiary chain actually align. If they do not, elevate the case quickly because the mismatch is often more informative than the transfer amount itself.

Common mistake: Do not let one team close the case because its own rule set is quiet. Laundering frequently survives by staying below any single team’s threshold while becoming obvious only when identity and movement evidence are combined.

Practitioner takeaway: The best joint model is one where AML explains the money, fraud explains the abuse pattern, and IAM explains who could have done it, because laundering cases are usually won or lost at those boundaries.

Related resources from NHI Mgmt Group

• How do fraud, AML, and IAM teams work together on crypto risk?
• How do IAM and fraud teams work better together on identity proofing?
• Why does digital commerce fraud force IAM and fraud teams to work together?
• How do fraud and IAM teams work together on AI-driven abuse?