Banks should assess each crypto business on its own transaction patterns, counterparties, controls, and regulatory obligations. Blockchain transparency makes that possible in a way that is often unavailable in traditional finance. The practical goal is not blanket approval or rejection, but a risk-based view that combines KYC, AML, sanctions, fraud, and market-risk analysis before onboarding or expanding services.
Evaluating Crypto Businesses as Individual Counterparties
Banks get better results when they treat crypto businesses as distinct counterparties rather than as proxies for a whole asset class. The right question is not whether “crypto” is inherently safe or unsafe, but whether a specific business has understandable flows, credible controls, and a supportable regulatory position. That shifts review from sector stigma to evidence-based onboarding.
A useful evaluation starts with the business model. An exchange, broker, custodian, market maker, payment firm, miner, or treasury service may all present different transaction patterns, customer types, and control expectations. If a bank cannot explain how funds move, who controls the wallets, and where settlement risk sits, the case is still too opaque to support informed banking.
Blockchain transparency helps, but it is not a shortcut. On-chain visibility can reveal wallet clusters, exposure to sanctioned addresses, concentration in high-risk flows, and links to known counterparties, yet those signals must be interpreted alongside off-chain facts such as corporate ownership, licensing, sanctions screening, and the quality of the business’s internal controls. That is why blockchain data is an input to due diligence, not a replacement for it. Where banks need a baseline for access and control thinking, PCI DSS v4.0 and ISO/IEC 27001:2022 Information Security Management both reinforce least-privilege access, authentication, and control discipline that matter when crypto firms handle sensitive transaction infrastructure.
What Banks Should Test Before They Onboard or Expand Services
The practical screening set should be narrow enough to be consistent and deep enough to explain the risk. Transaction provenance, source of funds, counterparty concentration, jurisdictional exposure, custody model, and sanctions controls usually tell more than the label “crypto business” ever will. A bank should also test whether the customer’s activity is stable, explainable, and bounded, or whether it changes too quickly for the bank’s monitoring to keep up.
KYC and AML are necessary, but they are not sufficient on their own. For crypto firms, the bank also needs to understand wallet governance, segregation of client assets, how keys are protected, whether any third parties can move value, and whether the business can evidence control over operational exceptions. If the firm cannot produce reliable records for these areas, it is not just a compliance concern, it is a model risk concern for the bank’s own monitoring and escalation process.
For this reason, banks should ask for the same kind of operational evidence they would require from any higher-risk correspondent or payments counterparty. That includes policies, independent testing, incident handling, sanctions escalation, and demonstrable ownership of critical controls. When a crypto business is relying on cloud or API-heavy infrastructure, control expectations become even more important, and the bank can use authoritative control references such as NIST SP 800-53 Rev 5 Security and Privacy Controls and NIST Cybersecurity Framework 2.0 as a common language for governance, protection, detection, and response.
Why the Bank’s Risk View Must Stay Dynamic
Crypto relationships can change quickly. A business that looks low risk at onboarding may add new jurisdictions, new products, new chains, or new counterparties that materially alter the exposure profile. Banks should therefore review not only whether the customer passed onboarding, but whether the customer still fits the original risk decision. That matters because stale approvals are a common failure mode in fast-moving sectors.
Market structure also changes the risk picture. The same entity may become more exposed during volatility, liquidity stress, or sanctions events, even if its nominal business model is unchanged. Banks should watch for anomalous transaction bursts, reliance on a small set of counterparties, repeated hops through high-risk services, and control drift in customer disclosures. These are the points where an account that seemed acceptable can become hard to justify.
Current guidance suggests treating crypto as a sector with heterogeneous risk rather than as a uniformly prohibited category. That approach is more defensible because it aligns decisions to observable behavior, not reputation. It also makes escalation more precise: the bank can narrow restrictions to the product, corridor, or activity that drives risk instead of freezing the entire relationship by default.
Risk and Threat Considerations
The main risk is false equivalence, where a bank either overgeneralises from a few bad actors or underestimates a business because the sector is novel. Both errors can produce harm: the first drives arbitrary de-risking, and the second can leave the bank exposed to sanctions breaches, fraud, weak custody controls, or poor traceability of funds.
Failure mechanism: Banks often fail when they rely on sector labels, stale onboarding narratives, or manual reviews that do not test actual transaction behavior. That creates blind spots around counterparties, beneficial ownership, wallet control, and control exceptions, especially when the customer’s activity shifts faster than the bank’s review cycle.
Impact: The bank may retain relationships it cannot adequately explain to regulators, or it may exit sound businesses unnecessarily and lose a risk-based banking model. In both cases, the institution’s monitoring, escalation, and financial-crime controls become less reliable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Crypto firms expose external users and services that banks must authenticate and govern. |
| AC-6 — Least Privilege | Banks need bounded access and narrow permissions when reviewing or integrating crypto counterparties. | |
| Recommendation — Verify external-user and service authentication before granting access to crypto-related banking systems. Limit permissions to the minimum needed for onboarding, monitoring, and escalation. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | Banks must identify customer-specific risk signals instead of bucketing all crypto firms together. |
| Recommendation — Document each crypto business’s distinct vulnerabilities, controls, and counterparties before deciding. | ||
| CIS Controls v8 | CIS-5 — Account Management | Customer and service account control matters when assessing access and operational maturity. |
| Recommendation — Review account ownership, access scope, and lifecycle control as part of due diligence. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Crypto businesses often depend on APIs and control misconfiguration can change their risk profile. |
| Recommendation — Assess API and platform configuration as part of the business’s operational control review. | ||
Practitioner Guidance
What to verify: Require evidence that the customer’s transaction patterns, counterparties, licensing position, and sanctions controls match the story being presented. If the business cannot tie those together cleanly, treat the relationship as not yet bankable, even if the sector headline sounds acceptable.
Decision rule: If the bank can only describe the customer by saying “it is a crypto firm,” the review is too shallow. If the bank can describe the firm’s flows, control owners, and escalation triggers in plain terms, the onboarding decision is much more defensible.
Practitioner takeaway: The right unit of analysis is the business, not the category. Banks that evaluate observable behavior and control quality can manage crypto exposure selectively instead of turning an entire sector into an undifferentiated risk bucket.
Related resources from NHI Mgmt Group
- How should security teams use MFA without treating it as the whole identity strategy?
- How should banks reduce account takeover risk without making login unusable?
- How should small businesses handle shared passwords without creating more risk?
- How should crypto businesses handle sanctions screening when wallet risk changes over time?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
