Both. IAM governs who can create, own, and use hosted access paths, while AML determines whether the resulting activity fits expected financial behaviour. If those functions operate separately, an account can look valid from one perspective and suspicious from the other, creating blind spots that adversaries can exploit.
Why this is both IAM and AML, not one or the other
Cryptocurrency exchange abuse sits at the boundary between identity control and financial crime monitoring. IAM answers whether the account, session, API credential, or delegated access path should exist and what it can do; AML answers whether the resulting activity is consistent with customer profile, source of funds, and transaction behaviour. Treating only one side as authoritative creates blind spots.
The practical mistake is to assume a clean login or a valid API token means the activity is legitimate. An account can be properly authenticated and still be used for mule behaviour, layering, rapid withdrawal, or other patterns that AML controls are meant to detect. The reverse also happens: suspicious activity can be blocked or investigated, yet poor identity governance leaves the same access path reusable, stale, or over-privileged.
For the identity side, the important question is not just “who signed in?” but “who was allowed to create or control the access path, and was that permission still appropriate?” Hosted wallets, exchange APIs, recovery flows, privileged support tooling, and shared operational accounts all create abuse opportunities when ownership, rotation, and offboarding are weak. That is why lifecycle and access governance matter as much as authentication.
Where the control boundary breaks in practice
Abuse usually emerges when IAM and AML are tuned to different signals and different owners. IAM teams may see a valid principal with normal authentication events, while AML teams see transaction patterns that look high-risk only after value has already moved. The gap is widest when API keys, delegated permissions, or recovery channels are treated as technical plumbing rather than as controlled financial access.
That separation is dangerous because hosted access paths can be abused without looking obviously stolen at first. A well-formed credential can be used from a legitimate device, through expected geographies, or via a trusted integration, yet still drive activity that violates the customer’s expected behaviour. In other words, “valid access” and “acceptable financial activity” are different control questions and need different telemetry.
For practitioner teams, the issue is not whether one domain replaces the other. It is whether IAM telemetry, case management, and AML alerting are stitched together well enough to follow the same principal across login, entitlement, transaction, and offboarding events. When they are not, organisations often discover abuse only after funds have been moved or accounts have been repurposed.
What good control looks like across the full abuse chain
A defensible operating model treats identity governance and financial monitoring as linked stages in one abuse chain. IAM should govern account creation, delegated access, privileged support actions, key rotation, recovery, and deactivation. AML should monitor transaction velocity, counterparty risk, source-of-funds plausibility, structuring, and withdrawal behaviour. Neither set of controls is complete on its own.
This is why lifecycle discipline matters so much. Hosted access that is old, shared, or insufficiently attributable can be reused to create apparently legitimate activity long after the original purpose has changed. Strong governance also helps incident response: if the organisation can quickly answer who owned the access, when it was last used, and what it could reach, AML investigators can interpret behavioural anomalies faster.
For exchanges and custodial platforms, the most useful design principle is to connect identity state to transaction state. The team should be able to see whether the actor is newly created, recently modified, unusually privileged, or operating through a support or automation path, and then combine that with activity patterns that may indicate misuse. That connection is where abuse becomes visible.
Risk and Threat Considerations
When IAM and AML are split, attackers and abusive users can exploit the gap by keeping access valid while making behaviour look abnormal only in the financial layer, or by keeping activity plausible while relying on weak identity governance behind the scenes. The result is delayed detection, poor attribution, and higher blast radius when an account, token, or recovery path is compromised.
Failure mechanism: A principal, API key, or hosted access path remains technically valid after the original trust assumption has changed, so the identity layer continues to authorise actions that the AML layer only recognises after value has already moved.
Impact: Organisations lose the chance to stop early-stage abuse, response teams receive incomplete context, and attackers gain a repeatable path for account misuse, mule activity, or rapid withdrawal before controls converge.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of API keys, tokens, and other authenticators used in exchange abuse. |
| IA-9 — Service Identification and Authentication | Applies where hosted APIs or service paths authenticate on behalf of exchange functions. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports correlating access events with suspicious transaction patterns and abuse indicators. | |
| Recommendation — Rotate, revoke, and track authenticators that can drive exchange access or withdrawals. Bind machine-to-machine exchange access to managed service authentication and least privilege. Correlate identity events with financial activity and escalate mismatches quickly. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Exchange abuse often starts with compromised or misused API authentication. |
| API6 — Unrestricted Access to Sensitive Business Flows | Covers abuse of exchange flows that move funds or trigger withdrawals. | |
| API5 — Broken Function Level Authorization | Relevant when a valid user or client can invoke actions beyond their intended exchange privilege. | |
| Recommendation — Harden API authentication and revoke credentials that can be reused for abuse. Restrict high-risk exchange flows and add step-up checks for sensitive actions. Enforce function-level authorization on transfer, withdrawal, and account-change actions. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Directly addresses identity governance for exchange access, privilege, and lifecycle control. |
| Recommendation — Apply IAM governance to access creation, review, and revocation across exchange systems. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports access governance over exchange systems and privileged paths. |
| Recommendation — Define and enforce access rules for exchange users, admins, and service accounts. | ||
Practitioner Guidance
What to prioritise: Build a shared case view that ties account ownership, credential state, privileged access, and transaction behaviour to the same customer or operational entity. If the IAM record and AML record cannot be joined reliably, that is a control gap, not a reporting inconvenience.
What to verify: Confirm that creation, rotation, recovery, and offboarding events are visible to both IAM and AML operations, and that support staff cannot silently create or extend access without leaving an auditable trail. Also verify that alert rules can distinguish between a legitimate but risky account and a suspicious but technically valid session.
Practitioner takeaway: Cryptocurrency exchange abuse is best handled as a shared identity-and-financial-behaviour problem, because the decisive question is not only whether access was allowed, but whether the resulting activity still fits the trust model.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org