Blockchain analytics in sanctions screening under OFAC: step by step

A payment firm onboards a corporate client whose principals pass every name-screening check. Six months later, a blockchain analytics tool flags a wallet cluster linked to a designated person. The firm has been processing transactions the entire time. That is not a hypothetical: it is the operational gap that surfaces regularly when virtual-asset businesses and financial institutions rely on name-screening alone.

Blockchain analytics in sanctions screening under OFAC means applying on-chain transaction analysis to identify wallets, clusters, and fund flows connected to blocked persons or sanctioned jurisdictions – going well beyond matching names on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons). OFAC has stated that a risk-based compliance programme (a structured set of controls proportionate to exposure) for virtual-asset businesses must address blockchain-specific risk, including the tracing of wallet addresses associated with designated persons. Screening a name without tracing the underlying address is not, by itself, a complete control.

This guide walks through the process in five sequential steps – from classifying your exposure, through deploying analytics, to handling a hit and benchmarking against other major regimes.

Step 1: Establish whether blockchain analytics is a required element of your programme

Not every business needs a blockchain analytics layer, but the threshold for needing one is lower than many compliance teams assume. If your business touches virtual assets – directly as an exchange, custodian, or payment processor, or indirectly as a bank providing services to those businesses – OFAC expects controls proportionate to the blockchain risk you bear.

The governing authority is OFAC, acting under the International Emergency Economic Powers Act (IEEPA). OFAC has published guidance specific to virtual-asset service providers (VASPs) affirming that the 50 percent rule (OFAC's rule treating entities owned 50 percent or more by blocked persons as themselves blocked) extends to wallet addresses: a wallet associated with a blocked entity is itself blocked, regardless of whether a human name appears on any list. That principle means a business that sends value to or receives value from a blocked wallet has potentially committed a prohibited transaction, even if every counterparty passed a name screen.

In our experience, the firms that discover this problem late are those that built their compliance programmes around AML name-matching tools and assumed that covered sanctions as well. It does not. The two disciplines overlap but they are not the same exercise. Ask yourself: does your current screening tool even accept a wallet address as an input?

The practical trigger for deploying blockchain analytics is any one of the following: you accept cryptocurrency deposits or withdrawals; you provide banking or correspondent services to VASPs; you clear or settle transactions denominated in or linked to virtual assets; or you are an M&A or due-diligence team reviewing a target with a virtual-asset book. If any of these apply, move to Step 2.

Step 2: Select and calibrate the right analytics tooling

Blockchain analytics tools work by clustering wallet addresses into entities using on-chain behavioural heuristics – shared inputs, timing patterns, and known exchange deposit addresses – and then attributing those clusters to real-world actors where possible. Selecting the right tool is a compliance decision, not only a procurement one.

Several commercial providers offer OFAC-screened attribution databases that map wallet addresses to known sanctioned entities, darknet markets, and high-risk mixing services. The key questions when calibrating a tool are: how frequently is the attribution database updated; what is the provider's methodology for linking an address to a designated person; and what risk-scoring categories are used?

Calibration – setting the thresholds at which a wallet cluster triggers a review versus a block – is where most implementations go wrong. Set thresholds too high and you miss indirect exposure; set them too low and your operations team drowns in false positives and stops taking the alerts seriously. We regularly advise clients on calibrating risk-score categories against their specific counterparty mix and transaction volumes. There is no single correct threshold: it depends on your customer base, the blockchains you touch, and your operational capacity to investigate alerts.

Two parameters matter most. First, the indirect exposure horizon: how many hops from a sanctioned cluster should still generate an alert? One hop is generally a minimum. Two hops introduces significant volume. Firms serving retail customers often stop at one hop for auto-blocking and use two hops as a trigger for enhanced due diligence. Second, mixer and tumbler exposure: funds that have passed through a mixing service carry elevated risk because they obscure origin. Regulators treat this as a red flag regardless of whether the underlying source can be conclusively identified as sanctioned.

Step 3: Run the screening workflow – what "step by step" looks like operationally

A blockchain analytics screening workflow under OFAC runs in parallel with, not in substitution for, name and entity screening. The two layers address different risks.

The sequence is as follows. At onboarding, collect wallet addresses the customer acknowledges using or controlling and submit them to your analytics tool for a baseline attribution check. Flag any address that scores in your alert band. For transaction monitoring, configure the tool to screen incoming and outgoing transactions in real time or near-real time, depending on your settlement architecture. Any transaction that touches an address attributable to the SDN List or a sanctioned jurisdiction triggers an immediate hold.

When a transaction is held, the clock matters. Blocked property and rejected-transaction reports must reach OFAC within 10 business days of the blocking or rejection. This is a firm statutory deadline; missing it is itself a violation. In our practice, the firms that breach this window are almost always those that have not pre-assigned responsibility for filing: the compliance team investigates, escalates, consults, and the ten days expire during the discussion.

Records of the screen, the alert, the investigation notes, and the filing must be retained for five years. That retention obligation applies to records of both blocked and rejected transactions. It also applies to the compliance evidence supporting a decision not to block – so document your reasoning when a potential hit is cleared.

Between onboarding and ongoing monitoring, insert a periodic re-screening step – at minimum when OFAC adds new addresses to its published wallet lists, which it does without advance notice. Automated feed integration with OFAC's SDN data is the standard approach. Manual monitoring is not adequate for any business operating at scale.

Step 4: Handle a hit correctly – the decision tree after a positive match

A positive match from a blockchain analytics tool requires a structured response. A hit is not the same as a confirmed violation, but it must be treated as one until you can establish otherwise. The failure mode is treating a hit as a nuisance rather than a legal obligation.

First action: hold the transaction and preserve all analytics output – the attribution report, the risk score, the chain of hops, and the timestamp. Do not process, release, or return the funds until you have completed the triage below. Returning funds to a sender associated with a blocked address can itself be a prohibited transaction.

Second action: run a confirmatory check. Analytics tools attribute probabilistically. A high confidence score is not a certainty. Pull the OFAC SDN List entry for the attributed entity and confirm that the wallet address your tool has matched is either on the list directly or is attributable through a published designation. If OFAC has published the wallet address in the SDN data, the block is confirmed. If the attribution is the tool's own inference rather than a published OFAC address, document your independent verification step.

Third action: apply the OFAC reporting framework. Blocked transactions require a report within the statutory window. Rejected transactions – those you decline to process – have the same reporting obligation. Use the OFAC blocked-and-rejected-transaction reporting portal and retain a copy of the submission.

Fourth action: assess whether a voluntary self-disclosure (VSD – a self-initiated disclosure to OFAC of a potential violation before the regulator identifies it) is warranted. VSD is a recognised mitigating factor under OFAC's Enforcement Guidelines. Whether to disclose depends on the facts: how many transactions are involved, what the apparent value is, whether the violation was wilful or resulted from a control failure, and whether the firm took prompt corrective action. This is the step where legal counsel is essential. OFAC distinguishes egregious from non-egregious cases, and the characterisation has a direct bearing on the penalty range.

Step 5: Benchmark against OFSI and the EU – where the regimes diverge

A business operating across the Atlantic faces a more demanding environment than OFAC alone. The UK and EU regimes apply their own requirements, and the cross-border comparison produces some important practical differences that affect how you build a single unified programme.

Under OFSI, the UK financial sanctions authority, the legal obligation sits on a strict-liability basis: knowledge of the violation is not required for a penalty to be imposed, as currently in force, verify before reliance. The maximum OFSI monetary penalty is the greater of £1,000,000 or 50 percent of the breach value. Critically, OFSI has a separate legal reporting obligation: relevant firms (broadly, those in the regulated sector) must report to OFSI as soon as reasonably practicable if they know or suspect that a person is a designated person or has committed a financial-sanctions offence. That reporting duty is triggered by suspicion, not certainty. A blockchain analytics hit that is not yet confirmed as a violation may already trigger the OFSI reporting clock.

Under the EU regime, Council regulations impose asset-freeze prohibitions that extend to making funds or economic resources available, directly or indirectly, to or for the benefit of listed persons. The EU control test – looking at both ownership above 50 percent and actual control – can reach entities not on any list. For virtual-asset businesses, the EU's transfer-of-funds rules apply a zero threshold to transfers between crypto-asset service providers: originator and beneficiary information is required regardless of transaction value, as currently in force, verify before reliance. That makes a blockchain analytics layer not merely prudent but operationally necessary to populate the required data fields.

Regulators across all three regimes – OFAC, OFSI, and the EU – use blockchain analytics themselves. OFAC has designated wallet addresses publicly; OFSI and EU designations have followed with their own address-level identifiers. The practical implication: a wallet that is not on the OFAC SDN List today may appear on an OFSI or EU list, and a firm with cross-border exposure needs a tool that covers all three designation datasets, not just one.

Where OFAC, OFSI, and EU sanctions all apply to a single business, the stricter prohibition governs. You cannot net the regimes against each other. If one regime requires a block and another does not clearly require one, the default position for a business subject to both is to block. For more on the UK-specific analytics screening workflow, see our blockchain analytics screening guide under OFSI.

How does OFAC's compliance standard actually apply to blockchain – and what does a gap look like?

OFAC's five-element compliance programme standard – management commitment, risk assessment, internal controls, testing and auditing, and training – applies to virtual-asset businesses in the same way it applies to traditional financial institutions, but the risk assessment element looks different because the threat surface is different.

A blockchain-specific risk assessment should map: which blockchains you process; what transaction volumes flow through each; what proportion of your customer base is anonymous or pseudonymous at the wallet level; which counterparty jurisdictions are touched; and what your current detection rate for high-risk wallet exposure is. A risk assessment that does not address these points is not tailored to the actual risk, which is itself a compliance gap under the OFAC standard.

The most common gap we see in practice is not a failure to have analytics tooling – it is a failure to integrate it into the decision process correctly. The tool generates an alert. The alert sits in a queue. Operations processes the transaction before compliance reviews the alert. By the time the review happens, the funds have moved. That sequencing failure is the definition of an ineffective internal control.

A second common gap is treating the analytics layer as a one-time onboarding check. OFAC adds wallet addresses to the SDN data on a rolling basis. A wallet that cleared at onboarding may not clear today. Re-screening at defined intervals – and automatically on every SDN update – is an internal-controls requirement, not a discretionary enhancement.

For businesses assessing their broader BIS and EAR exposure alongside sanctions risk – particularly where virtual-asset infrastructure involves export-controlled technology – the analysis is connected. See our guide on affiliate-level restrictions under the BIS and EAR for the export-control dimension. And for the dual-use and control classification angle, see our guide on control beyond the bright line under the BIS and EAR.

OFAC's de-risking concern (a financial institution exiting a relationship to avoid sanctions exposure) is also relevant here. Wholesale exit from virtual-asset correspondent relationships may reduce exposure in one direction but can produce its own regulatory and commercial consequences. The proportionate response is a programme that detects risk, not one that avoids all engagement.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@caldervance.com.