Sanctions screening for crypto is where two very different data models collide. Sanctions authorities publish name lists: a person, a company, a vessel, a place. Blockchains record addresses: long strings of hex or base58 that move value without asking who owns them. The compliance job is to turn the first into the second, and then into a decision you can defend. A name list on its own tells you nothing about a transaction. What you need is address-level risk, applied before funds settle.
The lists you actually screen against
Two regimes dominate for European operators, and they do not overlap perfectly.
- OFAC (United States). The Specially Designated Nationals (SDN) list has included digital currency addresses since 2018, when the Treasury first attached Bitcoin addresses to Iran-linked designations. Each listing can now carry a structured
Digital Currency Addressidentifier tied to the sanctioned party. US reach is broad because most stablecoins, custodians and infrastructure touch US persons or US dollar rails at some point. - EU consolidated list. The EU maintains its Consolidated Financial Sanctions List of persons and entities subject to asset freezes and restrictions. It is less address-centric than OFAC's SDN file, so for on-chain work you often have to bridge from a named entity to the wallets attributed to it through investigation and intelligence, rather than reading an address straight off the list.
You will also meet national and UK lists (OFSI), plus UN designations. The practical takeaway: screening a single feed is not enough. A wallet clean under one regime can be frozen under another, and EU firms are bound by EU measures regardless of what OFAC publishes.
Why a name list is not an address list
The gap between a designation and a wallet is the hard part. Sanctions bodies publish comparatively few addresses directly. The real exposure sits one or more hops away:
- Addresses controlled by a designated party but never published.
- Deposit addresses at a sanctioned exchange or mixer.
- Funds that passed through a sanctioned service (for example a mixer designated by OFAC) before reaching your counterparty.
- New addresses spun up after a designation to evade the listed ones.
This is why crypto sanctions screening is not a string match. It is a graph problem. You take the small set of directly listed addresses as seeds, then reason about proximity: who funded this wallet, where did it send value, how many hops to a sanctioned cluster, and how much of the balance traces back to tainted flows.
From name to address-level decision
A workable pipeline looks like this:
- Ingest and normalise the lists. Pull OFAC SDN, the EU consolidated list, UN and relevant national lists. Extract every published digital currency address and keep the named-entity records for investigation.
- Attribute wallets to entities. Combine listed addresses with clustering heuristics and attribution intelligence so a designation maps to the addresses a party actually controls.
- Score exposure, not just identity. For each address you interact with, measure direct hits and indirect exposure: distance to a sanctioned cluster, share of funds traced to sanctioned sources, and interaction with mixers or high-risk services.
- Set thresholds and act. Decide what a direct match means (block, freeze, report) versus what indirect exposure at N hops means (review, request source of funds, escalate).
- Re-screen continuously. Lists change, and so does the chain. An address that was clean yesterday can become exposed when a new designation lands or when funds move.
Direct versus indirect exposure
Keeping these two ideas separate is what stops teams from either under-blocking or over-freezing.
| Type | What it means | Typical response |
|---|---|---|
| Direct match | The address is on a sanctions list | Block, freeze, file the required report |
| Indirect exposure | Funds trace to or from a sanctioned address within N hops | Risk-based review, source-of-funds request, escalation |
Indirect exposure needs a policy, not just a tool. How many hops count? Does a single old transaction through a since-sanctioned service taint an entire balance? Regulators expect a documented, risk-based answer, applied consistently and evidenced.
Governance around the screening
Screening technology is only half the control. The other half is the paper trail:
- A written methodology for hop distance, materiality thresholds and false-positive handling.
- Versioned records of which list, on which date, produced which decision.
- Continuous re-screening, because designations and fund flows both move after onboarding.
- Clear ownership between the MLRO, the sanctions function and investigations.
Under MiCA and the EU's transfer-of-funds rules, crypto-asset service providers are squarely inside the sanctions and AML perimeter, so this governance is now an expectation rather than a nice-to-have.
Where Seqlense fits
Two capabilities line up with this workflow. Seqlense Monitoring handles blockchain address monitoring, on-chain surveillance, risk scoring and alerts, so exposure is re-evaluated as designations and flows change rather than only at onboarding. When a match needs a human, Investigation supports tracing attribution from a named entity to the wallets behind it. And because sanctions and AML rules keep moving, Doc lets you watch the relevant regulators, filtering by doctype:sanction across the sources that matter to your permissions.
Turning a name list into an address-level decision is the whole task. Get the seeds, the graph and the governance right, and the screening holds up when someone asks you to prove it.