Compliance teams should map every touchpoint that could support an Iran-linked digital asset flow, including exchanges, OTC desks, payment intermediaries, and infrastructure providers. The key test is not just direct dealing with a listed party, but whether services could be construed as operating in or supporting the sector. Screening, jurisdictional review, escalation, and rapid remediation should all be tightened.
Why This Matters for Security Teams
Secondary sanctions exposure is not limited to a direct transaction with a designated Iranian person or entity. In crypto, liability can arise when a firm provides services, liquidity, custody, infrastructure, or facilitation that meaningfully supports an Iran-linked flow, even if the counterparty chain is indirect. Compliance teams therefore need to assess ownership, control, geography, transaction routing, and the practical role each service provider plays in the value chain.
The challenge is that sanctions risk often sits at the intersection of AML, payments, custody, and digital identity controls. A strong program should treat sanctions screening as a lifecycle control, not a point-in-time check, and should align with broader governance expectations reflected in the NIST Cybersecurity Framework 2.0. That means documenting escalation triggers, preserving evidence, and ensuring decisions are reviewable by legal and compliance. It also means understanding that counterparties can be obscured through nested wallets, OTC desks, brokers, or shared infrastructure, which makes simplistic address screening insufficient.
Best practice is evolving toward scenario-based review, where teams ask what the service enables, who benefits, and whether the activity could be interpreted as support to a sanctioned sector or sanctioned person. In practice, many compliance teams encounter secondary sanctions risk only after a payment path, customer relationship, or liquidity relationship has already been exposed, rather than through intentional pre-clearance.
How It Works in Practice
Effective assessment starts with a defensible map of the full transaction chain. Compliance teams should identify the customer, any beneficial owners, any intermediary service provider, the destination wallet or exchange, and any off-platform arrangements such as OTC execution or brokered settlement. For Iran-linked exposure, the key question is not just whether a named party appears on a sanctions list, but whether the organization is dealing with a person, service, or network that could be viewed as facilitating sanctioned activity.
A practical review process usually includes:
- Screening all counterparties, beneficial owners, and known control persons against sanctions and watchlists.
- Reviewing jurisdiction, residency, and operating presence for each participant in the flow.
- Assessing whether the activity touches high-risk sectors, front companies, or payment channels associated with sanctioned access.
- Checking whether wallets, nodes, bridges, custody providers, or APIs create hidden support or indirect access.
- Escalating cases where ownership, control, or end-use cannot be verified with reasonable confidence.
Because sanctions programs depend on evidence, teams should retain transaction graphs, screening hits, analyst notes, and legal determinations. That evidence supports internal governance and any later regulatory inquiry. Where crypto activity is automated, controls should also cover change management and access governance so exceptions cannot be silently introduced into onboarding or routing logic. Guidance from FATF Recommendations remains highly relevant for KYC and beneficial ownership diligence, even when the specific concern is sanctions rather than pure AML.
Teams should also pair sanctions analysis with incident response discipline. If a route, counterparty, or wallet is later found to be Iran-linked, containment should include suspension, enhanced review, legal escalation, and re-screening of related accounts and counterparties. These controls tend to break down when firms rely on static sanctions lists alone and cannot trace the full service chain behind wallet-based or brokered crypto activity.
Common Variations and Edge Cases
Tighter sanctions controls often increase onboarding friction and investigative overhead, requiring organisations to balance rapid business execution against regulatory exposure. That tradeoff is especially visible in crypto markets, where counterparties may be nested behind custodians, omnibus wallets, liquidity routers, or cross-border intermediaries. There is no universal standard for this yet, so firms should treat edge cases with documented policy rather than informal judgment.
One common edge case is indirect support through infrastructure. A provider may not face the sanctioned jurisdiction directly, yet still enable access through hosted services, settlement rails, or execution paths that materially support restricted activity. Another is mixed exposure, where a customer base includes both legitimate and higher-risk users, making jurisdictional tagging and source-of-funds review essential. A third is incomplete attribution, where wallet ownership cannot be established but patterns indicate probable Iran nexus; in those cases, current guidance suggests conservative escalation rather than assuming benign intent.
Crypto programs that already align to sanctions and cybersecurity governance can improve consistency by integrating case management, audit trails, and access controls. For broader operational resilience, teams can use NIST SP 800-53 Rev 5 Security and Privacy Controls and the control-family structure of ISO/IEC 27001:2022 Information Security Management to harden screening workflows, evidence retention, and access governance around sensitive decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, while EU AI Act and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM, PR.AA | Sanctions exposure needs governed risk ownership and access-aware controls. |
| NIST SP 800-63 | Identity assurance supports counterparty and beneficial-owner verification. | |
| NIST AI RMF | GOVERN | Automated screening and risk scoring need accountability and oversight. |
| EU AI Act | If AI supports screening decisions, governance and traceability expectations rise. | |
| PCI DSS v4.0 | 12.8 | Third-party oversight is relevant where payment intermediaries touch regulated flows. |
Maintain explicit service-provider governance for any intermediary in the crypto payment chain.
Related resources from NHI Mgmt Group
- Why do crypto addresses create a compliance problem for sanctions teams?
- How should compliance teams respond when sanctioned crypto exposure is detected?
- How should compliance teams detect trafficking-related crypto activity more effectively?
- How should crypto compliance teams update screening when OFAC designates ISIS-linked wallets and money services businesses?
