Security teams should screen addresses before any transaction, contract interaction, or onboarding step that could expose the platform to sanctioned entities. In practice, that means checking wallet addresses against current sanctions data, enforcing the check in the user flow or smart contract path, and treating a positive match as a hard block until compliance review clears the case.
How sanctions screening should sit in the transaction flow
The practical rule is to screen before a wallet address is allowed to do anything that could create exposure, including an initial deposit, a smart contract call, a transfer, or account onboarding. That check should be part of the control path, not a back-office afterthought, so a sanctioned counterparty cannot get a foothold simply because the business process moved faster than compliance review.
For cryptocurrency teams, the important design choice is where to enforce the gate. If screening happens only after a transaction is prepared, the platform has already accepted risk and may need to unwind activity, freeze assets, or explain why a prohibited interaction was permitted in the first place.
What good sanctions screening needs to verify
Effective screening is more than matching a single address string. Teams should check the address against current sanctions data, maintain a process for updating lists and risk rules, and account for the fact that some blockchain activity is indirect, such as address reuse, intermediary services, or interactions that route through contracts and bridges.
The screening decision also needs to be tied to the specific business action. A wallet that is acceptable for viewing public data is not necessarily acceptable for sending funds, interacting with a protocol, or being onboarded as a customer, counterparty, or merchant.
For teams building onboarding and merchant flows, KYB and Business Identity Verification Guide is the closest internal reference because sanctions screening often sits alongside legal-entity verification and beneficial ownership review.
Why screening failures become compliance and operational problems
Sanctions screening failures create two kinds of exposure at once. The obvious one is regulatory and legal risk, because a prohibited address may be allowed to transact. The less obvious one is operational risk, because once a risky interaction is allowed, teams may have to reverse it, investigate it, or defend why the control did not stop it at the edge.
That is why the control should behave as a hard block when there is a positive match. A soft warning or delayed review can be useful for triage, but it should not be treated as clearance when the platform is about to process value or enable a contract interaction.
For US-facing teams, FinCEN guidance and reporting expectations are a useful external anchor for AML and sanctions-adjacent procedures, especially when screening outcomes feed escalation, case management, or SAR workflows. FinCEN remains the most direct public reference point for that operating context.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Sanctions screening is an access decision before a wallet can interact with the service. |
| IA-5 — Authenticator Management | Screening depends on reliable identity and account control material used to initiate access. | |
| Recommendation — Enforce access decisions before any sanctioned address can execute a transaction or contract call. Tie screening to managed credentials and revoke or block any access path linked to a positive match. | ||
| CIS Controls v8 | CIS-5 — Account Management | Wallet and service access must be governed so sanctioned actors cannot be onboarded or retained. |
| Recommendation — Block onboarding and remove access paths for addresses that fail sanctions screening. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Pre-use screening governs whether an address should be granted interaction rights. |
| A.5.15 — Access control | The topic is fundamentally about enforcing a deny-or-allow control before service interaction. | |
| Recommendation — Review and restrict interaction rights before any address is allowed to transact. Apply access control decisions at the point of interaction, not after the fact. | ||
Practitioner Guidance
What to prioritise: Put the block at the earliest point where the address can create exposure, not after the user has already initiated the transaction. If your design cannot stop the action before submission, you do not yet have a true pre-screening control.
What to verify: Confirm that the screening source is current, that re-screening occurs when sanctions lists change, and that the control covers every path that can cause value movement or onboarding. Smart contract paths, API paths, and manual exception paths all need the same enforcement standard.
Decision rule: If the address is a positive match or the match cannot be resolved with high confidence, treat the case as blocked until compliance clears it. Do not let business urgency convert an unresolved screening outcome into an implicit approval.
Practitioner takeaway: The control succeeds only when sanctions screening is enforced as a pre-authorization gate with consistent coverage across product flows, not as a post hoc compliance check.
Related resources from NHI Mgmt Group
- How should security teams govern Active Directory service accounts?
- How should compliance teams implement sanctions and PEP screening in customer onboarding without creating avoidable friction?
- How should security teams implement device posture checks before allowing access to internal applications?
- How should security teams prioritise NHI remediation in cloud environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
