Start by classifying counterparties by role in the transaction chain, not by broad industry label. Separate custody, exchange, brokerage, wallet, and infrastructure functions, then assign different review depth, approval thresholds, and monitoring expectations to each. That gives compliance and security teams a repeatable way to match controls to real exposure instead of relying on generic crypto risk assumptions.
Why This Matters for Security Teams
Risk classification drives whether a counterparty gets enhanced due diligence, sanctions screening, transaction monitoring, or a standard onboarding path. In crypto, the same label can hide very different exposure: a custody provider holding customer assets, an exchange routing many counterparties, or an infrastructure vendor that only supports messaging or wallet operations. Compliance teams need a role-based view because the operational failure modes are different, and the escalation path should be different too.
That distinction matters because controls should track actual control over funds, keys, and transaction flow. Guidance from the FATF Recommendations — AML and KYC Framework supports a risk-based approach, while NHI governance research from Ultimate Guide to NHIs — Regulatory and Audit Perspectives shows why identity and credential control matter when third parties handle sensitive access. In practice, many teams only discover the weak point after a high-risk counterparty has already been approved on the basis of an oversimplified crypto category.
How It Works in Practice
The practical method is to classify the counterparty by function, then map that function to a defined review tier. That means separating entities that take custody of assets, entities that execute trades, entities that introduce or broker customers, and entities that provide supporting infrastructure such as wallets, node access, analytics, or settlement tools. Each role changes the compliance question: who controls keys, who can move funds, who can alter instructions, and who can obscure beneficial ownership or transaction provenance.
Teams usually get better decisions when they score multiple factors together rather than relying on a single crypto label:
- Control of private keys or signing authority
- Ability to initiate, modify, or delay transactions
- Exposure to customer funds or pooled assets
- Jurisdiction, licensing, and sanctions exposure
- Quality of KYC, AML, and source-of-funds controls
- Reliance on sub-processors, APIs, and outsourced custody
This is also where identity governance becomes relevant. A counterparty that uses service accounts, API keys, or automated workflows to move value should be treated as an identity-control problem as well as a financial-crime problem. NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Report both reinforce that overprivileged machine access and weak secret governance are common paths to compromise. On the control side, the NIST Cybersecurity Framework 2.0 is useful for mapping governance, protection, detection, and response expectations to each counterparty tier. These controls tend to break down when a crypto business mixes multiple roles under one legal entity because compliance teams lose visibility into which function actually creates the risk.
Common Variations and Edge Cases
Tighter classification often increases onboarding friction, requiring organisations to balance risk reduction against business speed and false positives. That tradeoff is unavoidable in crypto, especially when counterparties operate hybrid models that combine brokerage, custody, and technology services in one platform. Current guidance suggests treating the highest-risk function as the default until the counterparty can evidence segmentation, but there is no universal standard for this yet.
Some edge cases need explicit handling. A non-custodial wallet provider may still warrant enhanced review if it controls routing logic, key recovery workflows, or compliance data. A liquidity venue may look like an exchange but function more like infrastructure if it never touches customer funds. A third-party that only provides analytics or screening may still need monitoring if its alerts feed into automated payment release. Where the business model is unclear, ask for organizational charts, flow diagrams, custody boundaries, and a description of any automated signing or approval paths. For broader control design, NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls provides a strong benchmark for access, audit, and system integrity expectations, while NHIMG’s Lifecycle Processes for Managing NHIs is a useful reference when crypto counterparties rely on machine identities to execute transactions. In practice, the hardest cases are decentralised or rapidly restructured firms, where legal form, technical control, and transaction authority no longer line up cleanly.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Counterparty classification is a governance and oversight decision tied to risk posture. |
| NIST AI RMF | GOVERN | Risk-based counterparty decisions need accountability, documentation, and oversight. |
| OWASP Non-Human Identity Top 10 | NHI-02 | Crypto counterparties often rely on API keys and machine identities to move value. |
Define counterparty tiers, assign owners, and review risk decisions on a recurring governance cadence.
