Crypto firms should combine list screening with blockchain analytics, then tune decisions by exposure type, transaction context, and jurisdiction. Direct exposure to a sanctioned entity is easier to act on, while indirect exposure requires assessing whether the intermediary relationship is meaningful. The goal is not blanket blocking, but risk-based screening that supports compliant growth and avoids unnecessary customer friction.
Design screening around exposure type, not just list matches
Sanctions screening works best when firms separate the question of “is a sanctioned party present?” from “how far does the exposure reach?” direct exposure is usually a straightforward hit because the sanctioned party is the transacting counterparty. Indirect exposure is different: it demands a judgement about whether the intermediary is acting as a meaningful proxy, whether control exists, and whether the transaction path actually changes sanctions risk.
That distinction matters because blockchain activity is often layered. A firm may need to screen addresses, entities, beneficial owners, counterparties, and transaction paths differently rather than forcing every signal into one yes or no decision. Overbroad blocking tends to collapse those distinctions and creates avoidable false positives.
In practice, that means the screening logic should be exposure-aware and scenario-aware: same customer, different transaction path, different risk conclusion. Where the exposure is indirect but economically or operationally meaningful, the firm should preserve the case for review rather than auto-blocking by default.
Use context to decide when indirect exposure is material
Indirect exposure is not automatically benign, but it is also not automatically disqualifying. The meaningful question is whether the intermediary relationship changes the sanctions posture in a way that is relevant to the firm’s obligations. That usually depends on control, ownership, routing, transaction purpose, counterparties, and whether the relationship looks structured to evade controls rather than facilitate ordinary activity.
Crypto firms should therefore make screening decisions using multiple context layers: asset flow, address clustering or attribution confidence, customer profile, jurisdiction, and the role of the intermediary in the transaction chain. A weak or unverified relationship should not be treated the same as a clearly controlled or sanctioned relationship. Where attribution confidence is low, escalation and monitoring are often better than immediate denial.
This is also where blockchain analytics becomes essential. Analytics can help a firm distinguish direct exposure from indirect proximity, identify intermediary services, and spot patterns that would otherwise be invisible in a pure list-screening workflow. The control objective is not perfect certainty, but a defensible threshold for action.
Build a policy that blocks only when the risk justifies it
A workable sanctions program needs tiered outcomes, not a single hard stop for every suspicious signal. Direct hits, confirmed sanctioned ownership, and clearly prohibited flows should be blocked or escalated immediately. Indirect exposure should move through a structured review path that considers transaction value, jurisdiction, customer type, timing, and whether the exposure is incidental or meaningful.
This is especially important for firms that want compliant growth without degrading the customer experience. If screening is too blunt, legitimate users get caught in repetitive reviews, delayed withdrawals, or unnecessary account restrictions. If it is too permissive, the firm accepts prohibited exposure and weakens its compliance position. The policy has to set a measurable threshold for when proximity becomes actionable.
One useful operating discipline is to document the decision rules for escalation, clearance, and rejection, then test them against real transaction patterns. That gives compliance teams a way to tune false positives without weakening the underlying sanctions standard.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while NIS2 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 6 — Access Control Management | Sanctions screening needs rule-based access decisions and escalation paths for restricted transactions. |
| Recommendation — Enforce access decision rules that block prohibited flows and route borderline cases to review. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Screening outcomes depend on controlled access decisions tied to customer and transaction context. |
| PR.DS — Data Security | Blockchain analytics and screening depend on protecting transaction and attribution data used in decisions. | |
| GV.RM — Risk Management Strategy | Risk-based screening requires explicit thresholds for when indirect exposure becomes actionable. | |
| Recommendation — Apply access-control governance to separate prohibited exposure from cases needing review. Protect and validate screening data so exposure decisions rest on reliable transaction evidence. Define risk thresholds that distinguish direct hits from indirect exposure requiring escalation. | ||
| NIS2 | ICT Risk Management Measures | Material screening controls support broader ICT risk governance where financial crime exposure affects operational resilience. |
| Recommendation — Implement risk-based screening controls as part of documented ICT risk management. | ||
| PCI DSS v4.0 | Req. 7 — Restrict access by business need to know | Least-privilege thinking supports limiting high-risk transaction handling to justified cases. |
| Req. 8 — Identify users and authenticate access to system components | Strong identity and authentication controls underpin reliable review and exception handling. | |
| Recommendation — Restrict high-risk transaction approval to personnel with a clear business need. Authenticate privileged reviewers and preserve accountability for sanctions decisions. | ||
Practitioner Guidance
What to prioritise: Separate direct sanctions hits from indirect proximity cases in the workflow and give each its own treatment path. If the same rule is handling both, the program will either overblock or under-enforce.
What to verify: Confirm that reviewers can see the evidence behind attribution, intermediary role, jurisdiction, and transaction context before a case is auto-blocked. If they cannot explain why the exposure is material, the rule is probably too aggressive.
Decision rule: Treat direct exposure as presumptively high risk; treat indirect exposure as a risk-ranking problem, not an automatic prohibition, unless the relationship suggests control, evasion, or sanctioned benefit.
What practitioners underestimate: False positives are not just a customer-service problem. In sanctions screening, they can push teams toward informal exceptions and inconsistent judgments, which is how weak screening often starts to drift.
Practitioner takeaway: The best sanctions design is not the one that blocks the most activity, it is the one that can defend why a specific exposure path was blocked, reviewed, or cleared.
Related resources from NHI Mgmt Group
- How should financial institutions handle wallet exposure in sanctions screening?
- How should crypto businesses handle sanctions screening when wallet risk changes over time?
- Why do crypto exchanges create AML and sanctions risk beyond direct customers?
- How should ecommerce teams handle AI-generated return claims without overblocking good customers?
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
