How to use blockchain analytics in screening under BIS / EAR

A compliance officer at a technology-hardware exporter receives a transaction alert. The counterparty name clears screening. The associated wallet address, however, clusters with addresses linked to a listed entity on the BIS Entity List. Does the shipment proceed? The answer depends on whether the compliance programme treats blockchain analytics as a genuine screening layer – or as a box-tick after the fact.

Blockchain analytics in sanctions screening under the BIS / EAR guide identifies the specific steps an exporter or intermediary must follow to screen digital-asset counterparties and wallet-linked entities against US export-control lists. The governing authority is the Bureau of Industry and Security under the Export Administration Regulations; BIS maintains the Entity List and the Denied Persons List, and dealings with listed parties require a licence or are prohibited outright. As of January 2026, regulators treat name-only screening as an insufficient control where digital-asset flows are part of the transaction picture.

This guide walks one representative engagement from the initial classification decision through wallet-cluster analysis, cross-regime comparison, and the escalation path a programme should follow when a hit emerges.

Step 1: Establish the export-control baseline before any analytics run

Blockchain analytics adds a layer on top of a classification and list-screening foundation; it does not replace it. The first task in any engagement is to confirm what the item is, what its ECCN (Export Control Classification Number under the US Commerce Control List) is, and which lists must be checked before goods or technology move.

The Commerce Control List is organised into ten categories and five product groups. An item that is subject to the EAR but does not appear on the CCL is designated EAR99 – the lowest-control tier. Even EAR99 items can be restricted if the end-user or end-use triggers a red flag, so classification does not end the analysis.

BIS maintains two principal denial lists: the Entity List and the Denied Persons List. A transaction with a listed party requires a licence or is prohibited, depending on the list. Neither list is static. Both are updated without a formal notice period that gives advance warning to exporters, which is precisely where a screening gap surfaces only after a breach.

Before any blockchain analytics tool is deployed, the compliance team must confirm: (1) the item's ECCN or EAR99 status; (2) which list-based restrictions apply at the point of export, re-export, or release; and (3) whether a deemed export (the release of controlled technology to a foreign person within the United States, including through remote access) is in scope. This baseline is the anchor against which wallet-level findings are then assessed.

Step 2: Map the digital-asset touchpoints in the transaction

The second step is to identify every point in the transaction where a digital asset moves, from the initial payment instruction through any intermediary wallet to the final settlement address. In our experience, exporters frequently map their fiat counterparties carefully but treat a digital-asset payment leg as a separate, siloed process outside the export-control review.

That separation is a structural risk. The question is not only who the named buyer is, but which wallet addresses are associated with the transaction and who, in turn, controls those addresses. Blockchain analytics tools assign risk scores and cluster addresses into ownership groups based on on-chain behaviour, shared inputs, and exchange relationships. A cluster associated with a BIS-listed entity is as material as a direct name hit.

The mapping exercise should produce a documented list of every wallet address linked to the transaction, the exchange or custodian through which the digital asset moves, and any intermediary address that appears in the transaction graph. That list becomes the input to the analytics run in Step 3.

One practical point: a transaction may involve a permitted-payment stablecoin issuer or a crypto-asset service provider subject to its own compliance obligations. Identifying those intermediaries at this stage allows the team to assess whether correspondent-level restrictions apply – a question that runs in parallel with, not instead of, the BIS / EAR analysis.

Step 3: Run the analytics and interpret the cluster output

Blockchain analytics platforms generate cluster maps, risk scores, and entity attributions; the compliance team's job is to interpret that output against the BIS Entity List and the Denied Persons List, not simply to record a score. A high risk score is a prompt to investigate, not a finding in itself.

The key analytical questions at this step are: Does any address in the cluster carry a direct attribution to a listed entity? Does the cluster include addresses previously flagged in a regulatory action? Are there AIS transmission gaps, unusual routing patterns, or evidence of chain-hopping that suggest an attempt to obscure ownership? Regulators treat a sharp change in transaction routing as a diversion red flag.

Blockchain analytics is used by regulators themselves to trace wallet clusters; a designation can extend to addresses associated with a designated person. This means that an address that does not appear on any published list may still carry indirect exposure if the analytics platform attributes it to a listed entity's cluster. The compliance team should record the attribution methodology the tool uses, because that methodology may be tested in an enforcement review.

Where the analytics output is ambiguous – a partial cluster match, a shared-input link of uncertain provenance, or a stale attribution that predates a de-listing – the file should note the uncertainty explicitly and record the decision taken. Undocumented decisions are a material weakness in an enforcement defence. In our practice, the quality of the contemporaneous file is frequently the deciding factor between a non-egregious and an egregious finding.

How does the BIS / EAR analysis differ from the OFAC and OFSI positions?

The BIS / EAR regime and the OFAC sanctions regime operate on different legal bases and list different parties, which means a clean OFAC screen does not answer the BIS question, and vice versa. The cross-regime comparison is mandatory for any programme handling digital-asset flows.

Under OFAC, the 50 percent rule (OFAC's rule treating entities owned 50 percent or more by blocked persons as themselves blocked) operates mechanically: aggregate the ownership of blocked persons and, if the result reaches or exceeds 50 percent, the entity is treated as blocked regardless of whether it appears on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons). That ownership arithmetic runs at the entity level and applies equally to the legal person that controls a wallet.

The BIS / EAR regime works differently. The Entity List and the Denied Persons List are list-based instruments; there is no automatic aggregation rule equivalent to the 50 percent rule. However, BIS administers end-use and end-user controls, including military end-use / end-user restrictions for specified destinations, and the Foreign Direct Product rules can bring foreign-produced items within US jurisdiction. An entity not named on a BIS list can still trigger a red-flag analysis if the end-use or end-user is suspect.

Under OFSI in the United Kingdom, the ownership-and-control test can catch a non-listed entity controlled by a designated person. The UK test is broader than a simple percentage: control encompasses the ability to direct the affairs of the entity, which may exist at ownership levels below 50 percent. For a digital-asset business operating between the United States and the United Kingdom, both tests must run in parallel. Where two regimes both apply, the stricter prohibition governs the conduct of a person subject to both.

The EU transfer-of-funds regime applies a zero-threshold requirement to transfers between crypto-asset service providers, so originator and beneficiary information is required regardless of value. This means that an EU-regulated CASP in the payment chain has independent verification obligations that the exporter's BIS screen does not satisfy – and a failure at the CASP level can generate its own compliance event.

For a practical illustration of the cross-border comparison, see our guide at blockchain analytics screening – cross-border guide. For the parallel OFAC analysis, the regime-specific treatment is covered at blockchain analytics screening – OFAC guide.

What are the risk flags that escalate a matter to counsel?

Not every analytics hit requires external escalation; a documented clean result and a clear negative determination can be handled within the compliance team. Certain patterns, however, indicate a level of legal complexity or enforcement risk that warrants involving specialist export-control and sanctions counsel early.

The first flag is a direct cluster attribution to a BIS Entity List or Denied Persons List party. If the analytics platform attributes any wallet in the transaction graph to a named restricted party, the transaction should be paused, the file preserved, and a legal assessment obtained before any further step is taken. Moving the transaction forward without that assessment is itself a compliance event under the EAR.

The second flag is a potential deemed-export exposure. Where the transaction involves the release of software, source code, or technology to a foreign person – including through a remote-access payment or a cloud-hosted API call – the deemed-export question is live. In our experience, export-control programmes frequently miss deemed-export risk in digital-product transactions because the delivery mechanism looks like an IT operation rather than a physical shipment.

The third flag is a cross-regime overlap: a transaction where the analytics reveal exposure under OFAC, OFSI, or an EU Council regulation in addition to the BIS question. Multi-regime matters require coordinated legal advice, not sequential screens. Treating the regimes as alternatives when both apply is a common and costly error.

The fourth flag is a voluntary self-disclosure question. Where a review reveals that a transaction has already occurred and the screening was inadequate, the question of whether to make a VSD (voluntary self-disclosure to a regulator) arises immediately. VSD is a recognised mitigating factor in OFAC's Enforcement Guidelines and, in the BIS context, an early, voluntary disclosure affects how a matter is characterised. Records must be kept for five years; destruction or alteration of records after a potential violation is identified is an independent and serious offence.

The fifth flag is the involvement of a foreign financial institution that may itself face correspondent-account restrictions. US authority allows measures against foreign financial institutions that conduct or facilitate significant transactions for designated persons or specified sectors; where an FFI in the payment chain falls within scope, the exporter's own exposure is compounded.

For more on the restrictions that apply at the affiliate and subsidiary level, see affiliate-level restrictions under BIS / EAR.

The compliance checklist: what a complete blockchain analytics screening looks like

A well-tested blockchain analytics screening programme for BIS / EAR purposes combines classification accuracy, list coverage, analytics depth, and documented decision-making. Each element is necessary; none is sufficient alone. The myth that name screening alone is enough to meet the rules is the single most common compliance failure we encounter – and it is one that an enforcement review will surface immediately.

The checklist below sets out what a complete screening looks like in practice.

Classification and list baseline: Confirm the ECCN or EAR99 status of the item. Confirm which BIS lists are in scope (Entity List, Denied Persons List, Unverified List). Document the classification rationale.

Counterparty and wallet mapping: Identify all wallet addresses linked to the transaction, including intermediary addresses. Identify the exchange or custodian holding each address. Document the mapping.

Analytics run and interpretation: Run the analytics against the mapped addresses. Record the platform used and the attribution methodology. Assess cluster output against the BIS lists. Document findings and any uncertainty.

Cross-regime check: Run the counterparty and wallet cluster against the OFAC SDN List, applying the 50 percent rule. Check the UK and EU lists if any party in the transaction is subject to OFSI or an EU Council regulation. Document the cross-regime result.

Decision and file: Record the compliance decision. If the transaction proceeds, state the basis. If it is paused or declined, state why. Retain all supporting documentation for the applicable record-keeping period.

Escalation protocol: Define the conditions that trigger an escalation to legal counsel and to senior management. Ensure the protocol is documented and tested at least annually.

We regularly advise exporters on calibrating each of these steps to their specific goods, customer base, and payment infrastructure. A screening programme that is well-designed for a traditional supply chain may need material adjustment when digital-asset payment legs are introduced.

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