Blockchain analytics in sanctions screening under OFSI: step by step

A payments firm onboards a new business client. The client's name clears every list check. Two months later, a blockchain analytics run on inbound settlement wallets flags a cluster of addresses linked to a designated person under the UK's financial-sanctions regime. The firm had no hit on name screening. It had a breach. That gap – between what a name screen catches and what actually reaches the account – is precisely where blockchain analytics in sanctions screening adds value under OFSI, and where its absence creates the greatest exposure.

Under the OFSI (Office of Financial Sanctions Implementation) regime, financial-sanctions obligations attach to knowledge or reasonable cause to suspect that a transaction involves a designated person or their assets. Blockchain analytics is not legally mandated by name, but it is increasingly the standard a well-run compliance programme is expected to meet – and its absence may constitute a gap in a firm's risk-based systems. As of January 2026, OFSI can impose monetary penalties on a strict-liability basis, meaning a firm need not have known it was dealing with a sanctioned party for a penalty to follow.

This guide walks through the decision points a compliance officer or general counsel faces at each stage: from the initial question of whether analytics is required at all, through the mechanics of running a screen, to what the output means and when to call counsel.

Does your business need blockchain analytics in its sanctions screening at all?

The first decision point is whether your business model creates the exposure that blockchain analytics is designed to detect. Not every firm handling digital assets faces the same risk profile, and the answer shapes everything that follows.

If your firm receives, processes, or transmits cryptoasset transfers – or holds wallets, operates exchange services, or acts as a custodian – the answer is almost certainly yes. The OFSI regime applies to anyone in the UK and to UK-connected persons wherever they are. A designated person's assets are frozen regardless of the form they take. Cryptoassets are assets. That is the starting point, not a contested edge case.

If your firm is a bank or payment firm with fiat settlement but receives funds that passed through a cryptoasset layer before conversion, the exposure is less obvious but still real. In our experience, firms in this second category are the most likely to underestimate their risk. The conversion of a cryptoasset into fiat does not cleanse the underlying transaction. If the original wallet belongs to or is controlled by a designated person, the converted fiat may still represent their property.

Ask three questions. First: do any of your customers, counterparties, or settlement routes touch a blockchain at any point? Second: do you accept deposits or payments from virtual-asset service providers (VASPs – firms that exchange or transfer cryptoassets) without conducting transaction-level analytics? Third: have you relied on name screening alone as the terminal check? If the answer to the first or second is yes, and the third is also yes, you are at risk of a screening gap that surfaces only after a breach.

The cross-regime point is worth flagging early. Under the EU transfer-of-funds rules, a zero-value threshold applies to transfers between crypto-asset service providers: originator and beneficiary information is required regardless of the transaction size. OFSI's obligations arise differently – through the prohibition on dealing with a designated person's assets – but the practical effect is similar: transaction-level visibility matters, not just entity-level name matching.

If exposure exists: how do you classify the wallets you need to screen?

Wallet classification is the foundational analytical step, and it is where most errors originate. Before a blockchain analytics tool can return a useful output, a firm must be clear about which addresses it is screening and what question it is asking.

There are three categories of address a firm typically encounters. First, customer-attributed addresses: wallets a customer has declared as their own during onboarding or a transaction. Second, counterparty addresses: wallets that send funds to the firm or receive funds from it, which may not have been declared by any identified party. Third, watch-list addresses: addresses that a blockchain analytics provider flags as associated with a designated person, a sanctioned cluster, or a high-risk entity.

The analysis differs across these categories. Customer-attributed addresses require periodic re-screening as designations change. Counterparty addresses require transaction-level analysis even before the counterparty is identified by name. Watch-list addresses require a protocol for what happens when a match is returned.

A critical point: OFSI's financial-sanctions obligations are not limited to direct relationships. The ownership and control test – the UK's equivalent of OFAC's 50 percent rule – means that an entity can be caught by the regime without itself being named on a list, if it is owned or controlled by a designated person. Blockchain analytics, used properly, surfaces wallet clusters that belong to such entities. Name screening does not.

Regulators, including OFSI and its counterparts in the EU and at OFAC, use blockchain analytics to trace wallet clusters in enforcement contexts. Practitioners advising on OFSI matters note that a firm's own analytics output can also become evidence in a review, which makes the quality of the methodology a legal as well as a technical question.

What does the screening process itself look like, step by step?

A compliant blockchain analytics screening process has six operational steps, each of which creates its own decision point and documentation obligation.

Step one: data gathering. Collect all blockchain addresses associated with the customer or transaction. This means not only declared wallets but also receiving and sending addresses visible in on-chain transaction data. For a VASP client, this may mean requesting a full wallet list as part of onboarding, and re-requesting it at defined intervals or on trigger events.

Step two: provider run. Submit the addresses to your blockchain analytics provider. The provider returns a risk score and, depending on the tool, a percentage of funds that can be traced to specific address clusters – including clusters associated with designated persons, darknet markets, mixers, or high-risk jurisdictions. The score and the trace are different outputs. Compliance decisions should be based on the trace, not only the score.

Step three: triage by exposure type. Distinguish between direct exposure (funds traced directly to a designated person's address) and indirect exposure (funds that passed through intermediary wallets before reaching the cluster). The degree of separation matters for proportionality, but it does not remove the obligation to investigate. OFSI's strict-liability basis means that "we did not know" is not a complete defence; "we had no reasonable cause to suspect" requires demonstrable process.

Step four: ownership and control overlay. Where a trace returns an entity rather than a natural person, run an ownership and control check. If the entity is owned or controlled – directly, indirectly, or in aggregate – by one or more designated persons, the asset-freeze obligation may apply even if the entity itself is unlisted. This is the step that most automated screening tools do not perform automatically: it requires a human judgment layer.

Step five: decision and escalation. If the trace returns a direct or indirect link to a designated person, the decision tree forks. Is there a general or specific licence that covers this transaction? If not, the firm should stop the transaction, block the funds if they have been received, and file a report with OFSI. Blocked-property and rejected-transaction reports must be submitted within a short statutory window – ten business days under OFSI's reporting framework, as currently in force – and records must be kept for five years.

Step six: documentation. Record every step: the addresses screened, the date and version of the analytics run, the risk output, the ownership and control check, the decision taken, and by whom. This record is your defence in a review. A firm that ran proper analytics and documented it is in a materially different position from one that did not, even if both ended up with an exposure.

What if the analytics output is ambiguous?

Ambiguous outputs are more common than clean hits, and they carry their own compliance obligation. Treating an ambiguous result as a non-match without documented investigation is itself a risk.

An ambiguous output typically takes one of four forms. First, a high-risk score without a direct designated-person trace: this may reflect a counterparty that transacts with high-risk entities but is not itself designated. Second, an indirect trace through a mixer or a high-volume intermediary: the analytical link is present but attenuated. Third, a name or entity match on the provider's proprietary risk list that does not correspond to a current OFSI designation. Fourth, an address that was previously associated with a designated person but has since been used by an apparently unrelated party.

In each case, the question is whether the firm has reasonable cause to suspect that the funds represent the property of a designated person. That standard – reasonable cause to suspect – is both an obligation trigger and a litigation concept. It requires documented analysis, not a binary yes/no from a software tool.

In our cross-border practice, we regularly advise firms that have received ambiguous analytics outputs and need to determine whether to freeze, report, or seek a specific licence. The practical answer often turns on the volume of funds, the nature of the counterparty relationship, and whether the firm has sought independent legal advice before making a decision it cannot easily reverse.

One useful cross-regime comparison: under OFAC's regime, a firm facing a potential voluntary self-disclosure (VSD – the process of proactively reporting a possible violation to the regulator) benefits from a documented analytics trail that shows the firm identified and investigated the exposure. The same logic applies under OFSI. A VSD supported by a complete analytics and investigation record is treated more favourably than one that is reactive and incomplete.

How does this process differ across OFSI, OFAC, and the EU?

OFSI, OFAC, and the EU each impose financial-sanctions obligations, but the mechanics differ in ways that matter for a firm operating across jurisdictions.

Under OFSI, the monetary penalty regime operates on a strict-liability basis: the maximum penalty is the greater of £1,000,000 or 50 percent of the value of the breach, as currently in force. Knowledge is not required for liability, though it is a factor in the penalty assessment. OFSI's licensing grounds are defined and specific; a transaction that does not fall within a licensing ground cannot simply be licensed out.

Under OFAC, the 50 percent rule is the primary ownership test: any entity owned 50 percent or more, directly or indirectly, in the aggregate by one or more blocked persons is itself blocked regardless of whether it appears on the SDN List. Blockchain analytics that surfaces wallet clusters attributable to such entities is directly relevant to that rule. OFAC's civil penalty regime is also strict-liability, and the Enforcement Guidelines reward VSD and co-operation.

Under the EU regime, asset-freeze prohibitions extend to making funds or economic resources available, directly or indirectly, to or for the benefit of listed persons. The EU control test looks at ownership exceeding 50 percent as well as the broader concept of control. EU transfer-of-funds rules – which require originator and beneficiary information for crypto transfers between service providers, at a zero-value threshold – impose a screening obligation that is operationally more demanding than the equivalent OFAC or OFSI rule.

The practical implication for a firm operating across all three regimes: a blockchain analytics programme calibrated only to OFSI will not satisfy OFAC if the firm has US-nexus transactions, and will not satisfy the EU transfer-of-funds requirement if the firm operates within scope of those rules. Where two regimes both apply, the stricter obligation governs the conduct; you cannot net the requirements out against each other.

We have acted for financial institutions that discovered mid-matter that their analytics programme was calibrated for one regime and left a gap under another. Calibrating the tool – including its address-risk thresholds and its ownership overlay – requires a regime-by-regime review, not a single global setting.

When does a screening gap require external counsel?

The myth that name screening alone is enough to meet the rules dies quickly once a compliance officer has worked through a blockchain analytics escalation. Name screening matches entity names against a list. Blockchain analytics traces the economic reality of where funds originate and where they go. The two tools are not substitutes.

That said, not every ambiguous analytics output requires external counsel immediately. The decision tree has a threshold. Below the threshold, documented internal investigation and a contemporaneous record are often sufficient. Above it – or where the decision has consequences that cannot be reversed – external review protects the firm and the individuals responsible for the decision.

Involve sanctions compliance counsel when: (1) the analytics output shows a direct or near-direct trace to a designated person and a transaction decision must be made in a short window; (2) the firm is considering a VSD and needs to scope the apparent violation before filing; (3) the firm has identified a potential breach and is deciding whether to freeze and report or to seek a licence; (4) there is disagreement within the compliance team about whether the ownership and control test is met; or (5) the firm faces a regulatory inquiry from OFSI following a blocked or reported transaction.

In our experience, the decisions that lead to the worst outcomes are those made without counsel at point three – the freeze-and-report versus licence decision. The two routes have different procedural consequences. Reporting a possible breach and seeking a licence are not mutually exclusive, but the order and framing matter. Acting quickly without advice can close options that would otherwise have been available.

The risk flag that most often surprises firms: the five-year record-keeping requirement. OFSI can review a transaction years after it occurred. A firm that ran good analytics but kept poor records is in a weaker position than its underlying conduct would otherwise warrant. Documentation is not an administrative afterthought – it is part of the legal defence.

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