Ownership should be shared across compliance, IAM, fraud, and legal, with one accountable programme lead. That structure prevents gaps between who approves identity, who detects suspicious activity, and who responds to regulatory questions. In regulated marketplaces, fragmented ownership is usually where control failure begins.
Why This Matters for Security Teams
An NFT marketplace that handles fiat on-ramps, wallet activity, sanctions screening, and suspicious transaction monitoring cannot treat AML compliance as a single-team problem. The real risk is not just policy ownership, but operational handoff failure: compliance defines the rule, IAM enforces identity proofing, fraud monitors behavioural anomalies, and legal interprets regulatory escalation. Current guidance suggests that the accountable lead must sit above those functions, because AML obligations cut across control boundaries.
That is consistent with the control-first approach in the NIST Cybersecurity Framework 2.0 and NHIMG’s view of identity governance in regulated environments, especially in the Ultimate Guide to NHIs â Regulatory and Audit Perspectives. AML failure usually starts when each team assumes another function owns the final decision, leaving gaps in onboarding, monitoring, and regulator response. In practice, many security teams encounter control failure only after a suspicious account has already moved value through the platform, rather than through intentional governance.
How It Works in Practice
The most reliable operating model is a shared execution structure with one accountable programme owner. Compliance should define AML policy, threshold logic, retention expectations, and reporting duties. IAM should control identity verification, wallet-linking assurance, step-up checks, and privileged administrative access. Fraud and security should monitor transaction patterns, device signals, velocity, and mule-like behaviour. Legal should review jurisdictional exposure, disclosure language, and regulator correspondence. This division is useful only when the handoffs are explicit and measured.
In practice, AML ownership works best when the organisation defines:
- one accountable lead for policy exceptions, regulatory reporting, and remediation sign-off;
- clear RACI boundaries for onboarding, monitoring, escalation, and case closure;
- shared evidence collection so identity, transaction, and support logs can be assembled quickly;
- reviewable controls for high-risk accounts, beneficial ownership signals, and wallet clusters;
- periodic testing of escalation paths so suspicious activity does not stall between teams.
This is where NHI discipline becomes relevant even in a marketplace context. If marketplace automation uses API keys, bots, or service accounts to trigger screening, settlement, or moderation workflows, those NHIs need lifecycle controls, rotation, and scoped privileges. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs â Lifecycle Processes for Managing NHIs are useful references because the same governance mistakes that affect NHIs also affect AML tooling: unclear ownership, excessive access, weak revocation, and poor auditability. These controls tend to break down when the marketplace scales across multiple jurisdictions because local AML obligations, product workflows, and identity evidence requirements diverge faster than the operating model does.
Common Variations and Edge Cases
Tighter ownership often increases governance overhead, requiring organisations to balance clear accountability against product speed and multi-jurisdiction complexity. That tradeoff is especially visible in NFT marketplaces that support peer-to-peer transfers, creator launches, custody services, or embedded payments. Best practice is evolving, but there is no universal standard for whether compliance, risk, or operations should own every edge case. The important point is that the accountable lead must have authority to resolve conflicts, not just document them.
Two edge cases matter most. First, if the marketplace is decentralised or partially decentralised, legal exposure may differ by product line, but the need for a single accountable control owner does not disappear. Second, if automation performs AML checks through service accounts or vendor APIs, the security team must treat those non-human identities as governed actors, not invisible plumbing. That means access review, credential rotation, and alerting need to be part of the AML control design, not an afterthought. This becomes harder when multiple subsidiaries, payment providers, or marketplace partners each keep separate records, because audit evidence fragments and escalation timing becomes inconsistent.
For governance maturity, the practical rule is simple: shared responsibility, single accountability, and evidence that survives regulator review. If that structure is missing, ownership will be disputed at the exact moment an investigation needs a fast answer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-02 | AML needs clear governance ownership across compliance, IAM, fraud, and legal. |
| NIST CSF 2.0 | PR.AA-01 | Marketplace identity proofing and access decisions affect AML control quality. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Automation used in AML flows depends on governed non-human identities and secrets. |
Assign one accountable owner and define cross-functional AML responsibilities with documented escalation paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
