Because the blockchain only shows value movement, not the full identity context behind control of the wallet or service account. AML and fraud teams still need onboarding records, beneficial ownership data, and case history to determine intent and responsibility. Without those controls, transparent ledgers can still produce opaque governance.
Why This Matters for Security Teams
Crypto platforms create risk that sits outside the blockchain because the ledger does not answer who really controls the wallet, how the account was funded, or whether a transaction pattern reflects fraud, mule activity, or sanctioned exposure. That gap makes onboarding, beneficial ownership checks, and ongoing monitoring core security controls, not just compliance paperwork. For platforms that custody assets or mediate transfers, identity proofing and case history become part of the control plane.
Current guidance suggests treating AML and fraud operations as linked but distinct disciplines. AML teams look for typologies, source-of-funds signals, and suspicious network behaviour, while fraud teams focus on account takeover, synthetic identity, social engineering, and payment abuse. The same event can trigger both investigations, which is why evidence quality matters. NHIMG’s research on Top 10 NHI Issues shows how weak credential governance creates downstream trust failures, and the same pattern applies when platform-controlled service accounts or automation are involved.
For control design, teams should align operational monitoring with the FATF Recommendations and the NIST Cybersecurity Framework 2.0, because the issue is not only transaction surveillance but governance over identity, access, and evidence. In practice, many security teams encounter the true risk only after a disputed transfer, account compromise, or law-enforcement request has already exposed gaps in ownership records and review history.
How It Works in Practice
Operationally, crypto AML and fraud control depends on joining chain telemetry with off-chain context. A blockchain explorer can show address interactions, but it cannot verify whether a customer completed a valid onboarding flow, whether a wallet belongs to a sanctioned counterparty, or whether a service account was used by an authorised automation process. That is why controls usually span KYC/KYB, beneficiary and wallet risk scoring, device and session analytics, transaction monitoring, and case management.
Strong programmes separate three questions: who the customer is, who benefits from the activity, and whether the activity is consistent with the declared purpose. For example, a high-volume withdrawal pattern may be legitimate treasury activity for one customer and layering behaviour for another. The difference lies in verified identity data, historical behaviour, and the quality of exceptions handling. NHIMG’s OWASP NHI Top 10 is useful here because many platform failures start with compromised machine identities, overprivileged API keys, or automation that can move funds faster than human review can intervene.
- Bind wallet risk to customer identity, beneficial ownership, and source-of-funds evidence.
- Monitor for account takeover indicators such as device changes, impossible travel, and session anomalies.
- Correlate on-chain movement with off-chain behaviour, including login history and support interactions.
- Use human review for escalations where typology, sanctions, or jurisdictional ambiguity is present.
Security teams should also preserve immutable case records and decision rationale so investigators can explain why a transaction was cleared, held, or escalated. These controls tend to break down when platforms rely on fragmented identity stores, outsource verification without retaining evidence, or let automation execute transfers before risk scoring completes.
Common Variations and Edge Cases
Tighter transaction screening often increases friction, false positives, and customer abandonment, so organisations need to balance faster conversion against stronger provenance checks. That tradeoff becomes sharper as platforms expand across jurisdictions, support self-custody, or offer embedded finance features.
Not every crypto business faces the same exposure. A pure software wallet provider has different obligations from a custodial exchange, OTC desk, or payment intermediary, and guidance varies by jurisdiction. There is no universal standard for how much off-chain evidence is enough, but best practice is evolving toward risk-based, entity-level controls rather than address-only scoring. This is especially important where shared custody, omnibus wallets, or delegated operations obscure the link between a transaction and the responsible party.
Edge cases also arise when non-human identities initiate activity. API keys, bots, relayers, and settlement automations can look like legitimate infrastructure until one is abused. That is why crypto governance now overlaps with broader NHI discipline, including secret rotation, privilege minimisation, and machine identity monitoring. NHIMG’s Ultimate Guide to NHIs is relevant where automated accounts can trigger transfers or approvals, while the DeepSeek breach demonstrates how hidden secrets and exposed records can undermine trust at scale.
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, NIST SP 800-63, NIST SP 800-53 Rev 5 and FATF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 | Risk management is central when AML and fraud controls depend on off-chain identity evidence. |
| NIST SP 800-63 | IAL2 | Identity proofing quality affects whether customer records can support AML and fraud decisions. |
| NIST SP 800-53 Rev 5 | AU-2 | Audit records are needed to reconstruct decisions across onboarding, monitoring, and case handling. |
| FATF | R.10 | Customer due diligence is required because blockchain data alone does not establish who controls value. |
| OWASP Non-Human Identity Top 10 | NHI-2 | Compromised machine identities can move funds or alter controls without normal user visibility. |
Inventory service accounts and rotate secrets so automation cannot become an invisible transfer path.
