Subscribe to the Non-Human & AI Identity Journal
Home FAQ Governance, Ownership & Risk What do security teams get wrong about crypto…
Governance, Ownership & Risk

What do security teams get wrong about crypto compliance and fraud?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated June 10, 2026 Domain: Governance, Ownership & Risk

Teams often treat compliance and fraud as separate workstreams, but they usually fail together when identity evidence is weak or fragmented. If verification, monitoring, and escalation are not connected, attackers and bad actors exploit the gap between policy and execution. A single operating view is more effective than siloed controls.

Why This Matters for Security Teams

Crypto compliance and fraud teams often share the same evidence trail: wallet ownership, transaction provenance, device trust, approval history, and escalation context. The failure is usually not policy design but fragmented identity evidence. When controls are split across compliance review, fraud detection, and case management, attackers exploit the handoff. That is why NHI governance matters here: Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows how auditability depends on consistent identity evidence, not just strong rules.

Teams also underestimate how much fraud depends on machine identity quality. The NIST Cybersecurity Framework 2.0 emphasizes governance and continuous risk management, which is exactly what crypto environments need when wallets, API keys, service accounts, and signing systems can all act on behalf of a business process. In practice, many security teams discover identity drift only after a suspicious transfer has already moved beyond the point where a single control could stop it.

How It Works in Practice

Effective crypto compliance and fraud control starts by treating every automated actor as an identity with an accountable lifecycle. That includes exchange service accounts, custody automation, bot wallets, API integrations, signing services, and alerting workflows. Each should be tied to a named owner, a business purpose, and a revocation path. The goal is to make verification and monitoring part of the same operating model, not separate queues.

At minimum, teams should connect four layers:

  • Identity proof: establish who or what can initiate a transfer, approve a withdrawal, or change a payout destination.

  • Policy enforcement: use role, context, and transaction risk together, rather than relying on static allowlists.

  • Continuous monitoring: correlate wallet movement, login anomalies, API behaviour, and approval overrides.

  • Escalation and evidence retention: preserve the chain of custody so compliance review and fraud response use the same record.

NHIMG research on the Top 10 NHI Issues is useful here because the recurring failure pattern is over-privileged access combined with weak lifecycle control. That aligns with the operational reality in crypto: a compromised API key or signing workflow can look legitimate until it is abused at speed. Current guidance suggests that compliance teams should not rely on periodic attestations alone; real-time transaction context and ownership evidence need to be evaluated together. Controls tend to break down in high-volume exchange environments because automated approvals, hot-wallet operations, and exception handling create too many legitimate-looking paths for abuse.

Common Variations and Edge Cases

Tighter fraud controls often increase operational friction, requiring organisations to balance rapid customer movement against stronger evidence requirements. That tradeoff is especially visible in crypto businesses that handle retail withdrawals, institutional custody, or cross-border settlement. There is no universal standard for this yet, but best practice is evolving toward risk-based verification that changes with transaction size, destination risk, asset type, and account behaviour.

Some edge cases deserve special treatment. Treasury automation may need broader access than customer-facing systems, but that does not justify standing privileges without review. Travel-rule workflows and sanctions screening can improve compliance posture, yet they do not replace transaction-level fraud detection. Likewise, wallets controlled by third-party processors still require transparent ownership mapping, because outsourced execution does not remove accountability. For a deeper operational lens, Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is a strong reference for ownership, rotation, and deprovisioning discipline.

Security teams should also avoid assuming that one control domain can cover the rest. A fraud rule may block a suspicious withdrawal, but it will not correct weak identity provenance. A compliance review may satisfy audit, but it may miss lateral movement through APIs or delegated credentials. The practical answer is a shared operating view where evidence, monitoring, and escalation all point to the same identity record.

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 AI RMF set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Weak rotation and lifecycle control enable fraud through stale crypto credentials.
NIST CSF 2.0GV.RM-01Crypto compliance and fraud need shared governance and risk ownership.
NIST AI RMFIdentity-driven fraud detection depends on governed monitoring and accountability.

Assign one risk owner for identity evidence, monitoring, and escalation across compliance and fraud.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org