Who should own stablecoin fraud governance across IAM and payments?

Why This Matters for Security Teams

Stablecoin fraud governance is not just a payments problem or an IAM problem. It is a control-plane issue that spans identity proofing, session trust, payment authorisation, wallet permissions, and settlement integrity. When ownership is unclear, teams often leave gaps between onboarding controls and payment controls, which fraudsters can exploit through account takeover, mule activity, or compromised service identities. Current guidance suggests this should be treated as shared governance with one enforceable policy, not siloed handoffs.

The practical risk is that each function sees only part of the chain. IAM may validate access, payments may verify transaction context, and fraud may score behaviour, but no team alone owns the end-to-end decision. That is why NHI lifecycle thinking matters, especially the handoff points documented in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. For control design, the NIST Cybersecurity Framework 2.0 is useful because it forces governance, protection, detection, and response to be owned explicitly rather than assumed. In practice, many security teams encounter fraud escalation only after a payment path has already been abused, rather than through intentional joint design.

NHIMG research shows how quickly shared responsibility becomes a blind spot: in the State of Non-Human Identity Security, only 1.5 out of 10 organisations were highly confident in securing NHIs.

How It Works in Practice

Effective governance starts by separating decision rights, not by splitting the problem. Fraud teams typically own behavioural risk rules, IAM owns identity proofing and access enforcement, compliance owns policy interpretation and evidence, and payments owns transaction controls and settlement safeguards. The accountable model is a shared risk policy that defines who can approve, block, step-up, or revoke at each stage. That policy should be mapped to lifecycle checkpoints such as onboarding, authentication, authorisation, transaction approval, and exception handling.

For stablecoin environments, identity is not only a user account. It can also include wallet controllers, API clients, treasury bots, and automated payment workflows. This is where workload identity becomes important. Controls should use strong, cryptographic identity for systems and agents, then apply least privilege, time-bound access, and transaction-specific authorisation. The Top 10 NHI Issues is relevant here because over-privileged accounts and weak rotation are common failure modes. NIST also reinforces this separation of duties and evidence capture in NIST SP 800-53 Rev. 5 Security and Privacy Controls.

• Define one control owner for policy, and separate owners for enforcement, monitoring, and exception approval.
• Require step-up checks for high-risk wallet changes, payout changes, and anomalous settlement paths.
• Use short-lived credentials and session binding for payment automation and service-to-service access.
• Log all approvals, overrides, and revocations so fraud and audit can review the same evidence set.

These controls tend to break down when settlement is automated across multiple platforms because each platform enforces different identity, fraud, and payment rules.

Common Variations and Edge Cases

Tighter governance often increases operational overhead, requiring organisations to balance fraud reduction against payment latency and support burden. That tradeoff is especially visible in high-volume stablecoin flows, where false positives can interrupt legitimate transfers and create customer friction. Current guidance suggests using tiered controls, with stronger checks reserved for new beneficiaries, large-value transfers, privileged service accounts, and unusual transaction patterns.

There is no universal standard for ownership structures yet, so the right model depends on how stablecoin is used. In treasury operations, payments may lead and IAM may support access enforcement. In consumer-facing platforms, fraud may lead because behavioural anomaly detection is central. In regulated environments, compliance should have explicit veto and evidence rights. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful for defining who must retain evidence and why. For broader control mapping, the governance emphasis in NIST Cybersecurity Framework 2.0 helps keep ownership tied to outcomes, not org charts. Organisations that rely on manual sign-off alone often discover the gap only after a disputed transfer or compromised automation has already moved value.

Related resources from NHI Mgmt Group

• Who should own 2FA governance across the enterprise?
• What is the difference between human IAM controls and NHI governance?
• What does the 144:1 NHI-to-human ratio mean for IAM governance programmes?
• Who should own continuous governance across IAM and NHI programmes?