Cryptocurrency businesses should combine customer screening, transaction monitoring, and ongoing sanctions risk review into a single risk-based program. That means blocking sanctioned parties from using the service, checking users and counterparties against sanctions lists, monitoring exposure to risky addresses, and filing required reports quickly. The strongest programs also include testing, auditing, and training so controls keep pace with evolving sanctions exposure.
How sanctions screening fits into the compliance stack
For cryptocurrency businesses, sanctions screening is not a standalone control, it sits between onboarding, transaction controls, and ongoing monitoring. The program has to address both named parties and exposure to wallet addresses or counterparties that may be linked to prohibited activity. It also needs clear escalation paths so screening hits become a compliance action, not just an alert queue.
That makes program design a question of coverage and timing as much as tooling. Screening at customer onboarding, rescreening existing relationships, and monitoring transactions in near real time all serve different failure modes, and the program should define which one stops activity, which one triggers review, and which one requires reporting.
Good programs also separate sanctions obligations from broader AML work while keeping the same evidence chain. Screening logic, match handling, case notes, and disposition records should be auditable end to end, because sanctions decisions often need to be explained after the fact to regulators, banking partners, or internal audit.
- Use onboarding screening to block prohibited users before access is granted.
- Use ongoing rescreening to catch list updates, ownership changes, and new counterparty exposure.
- Use transaction monitoring to detect risky flows that static customer checks miss.
- Keep case handling and reporting separate enough that reviewers can show why each decision was made.
What a risk-based screening workflow should actually cover
A workable workflow starts with the customer, but it cannot end there. Crypto businesses should screen customers, beneficial owners where relevant, and counterparties that appear in transaction flows, then apply additional scrutiny to jurisdictions, wallet clusters, mixers, intermediaries, and any pattern that suggests sanctions exposure. The objective is not perfect certainty, it is defensible coverage proportional to the business model.
The most common design mistake is treating sanctions screening as a one-time onboarding check. Crypto activity changes quickly, and list updates can make a previously acceptable relationship high risk overnight. That is why the workflow should include periodic refreshes, event-driven rescreening, and transaction monitoring rules that can halt or escalate activity when new information appears.
Businesses also need a practical approach to matches. False positives are inevitable, especially where transliteration, common names, or shared wallet infrastructure are involved. Strong programs define a triage path that distinguishes exact matches, likely matches, and low-confidence alerts, then require documented analyst review before release or escalation.
If the program includes screening infrastructure, align it with broader control objectives such as access restriction, auditability, and record retention. ISO/IEC 27001:2022 Information Security Management is useful here because sanctions screening becomes part of a managed control environment, and the FATF Recommendations — AML and KYC Framework remains the key external reference for customer due diligence, beneficial ownership, and suspicious reporting expectations. For operational control design, the ISO/IEC 27001:2022 Information Security Management standard and the FATF Recommendations, AML and KYC Framework are the most directly useful anchors.
Operational controls that keep the program defensible
Sanctions screening only works when it is testable. Teams should be able to show how list updates are ingested, how screening logic is tuned, who can override a match, how exceptions are approved, and how quickly escalations are reviewed. Testing should include known-good and known-bad scenarios so the business can confirm that screening is actually blocking what the policy says it should block.
Auditing matters because sanctions programs fail quietly when workflow shortcuts accumulate. If analysts can bypass dispositions, if case notes are incomplete, or if rescreening is not triggered after a list refresh, the organisation may look compliant on paper while carrying unresolved exposure. Training is also important, but it should be role-specific: onboarding teams, compliance analysts, operations staff, and escalation owners each need different decision boundaries.
For businesses that depend on third-party screening vendors or blockchain analytics providers, third-party risk is part of the program, not an adjacent issue. You want clear service levels for list freshness, alert latency, and evidence retention, plus a fallback process if the vendor fails or data quality drops. That is where broader governance guidance from the ISO/IEC 27002:2022 Information Security Controls and the SOC 2 Trust Services Criteria can help shape evidence, control ownership, and monitoring expectations.
Where the program intersects with wallet tracing, exchange relationships, or upstream exposure to compromised infrastructure, the failure mode is often indirect sanctions contamination rather than direct customer misuse. That is why businesses should understand how credential or infrastructure compromise can create downstream exposure, as illustrated by the JumpCloud Breach, and by identity compromise patterns in the Storm-2949 Azure Breach and Nx Package Attack, 2,300+ Credentials Leaked.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Access to screening rules and overrides must be restricted and reviewed. |
| Recommendation — Restrict who can approve, override, and modify sanctions screening outcomes. | ||
Practitioner Guidance
What to verify: Confirm that sanctions hits are screened at onboarding, on a refresh cycle, and during transaction monitoring, with separate handling for exact matches, close matches, and unresolved cases. If a control cannot show when it last ran and who resolved the alert, it is not operationally reliable.
What to prioritise: Start with the highest-risk exposure points, which are customer onboarding, counterparties embedded in transaction flows, and list-update rescreening. Those three areas usually produce the greatest compliance loss if they fail, and they are also the easiest places to prove control effectiveness.
Common mistake: Do not treat wallet screening as a substitute for broader sanctions governance. A business can have excellent blockchain analytics and still fail if it cannot explain why a customer, counterparty, or transaction was allowed to proceed after a sanctions match.
Practitioner takeaway: The strongest sanctions program is not the one with the most alerts, it is the one that can consistently block, review, document, and report high-risk exposure before the business creates avoidable regulatory or banking-partner friction.
Related resources from NHI Mgmt Group
- How should crypto businesses handle sanctions screening when wallet risk changes over time?
- How can compliance teams know whether sanctions screening is actually working?
- How should crypto compliance teams update screening when OFAC designates ISIS-linked wallets and money services businesses?
- How should compliance teams handle pre designation and post designation exposure in sanctions screening programs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
