How to screen virtual-asset transfers under BIS / EAR

A payments business routes a transfer of digital tokens through a US-incorporated exchange. The underlying counterparty is a hardware manufacturer in a third country whose products appear on a controlled-item classification list. The exchange screens the wallet address. It finds no match on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons). The transfer clears. Three months later, the business learns that the goods the tokens were paying for required a licence under the EAR (the US Export Administration Regulations, administered by the Bureau of Industry and Security). The payment facilitated an unlicensed export. Name screening passed. Export-control screening never ran. That gap is the exposure that surfaces only after a breach – and it is exactly where virtual-asset transfer screening fails most often.

Virtual-asset transfer screening under BIS / EAR requires more than matching wallet addresses or entity names against sanctions lists. The EAR governs the transfer of controlled technology, items, and software, and a payment that facilitates an unlicensed export can itself constitute a violation. A complete screening programme treats the underlying transaction – its purpose, the goods or technology involved, the destination, and the end user – as the primary subject of review, with digital-asset mechanics as a secondary layer on top.

This guide walks through how that screening works in practice: what the BIS / EAR regime requires, how the travel rule interacts with export-control obligations, where the cross-regime picture differs from OFAC and OFSI, and what a step-by-step compliance checklist looks like for a virtual-asset business operating across borders.

Step 1 – Understand what the BIS / EAR regime actually covers

The EAR reaches further than most virtual-asset compliance officers expect. It governs not just physical goods but also technology and software – and that includes information transferred electronically, which means a token payment linked to a controlled-technology transaction can bring the payer within scope.

Items subject to the EAR fall into two broad categories. The first is items on the Commerce Control List (the CCL, a schedule of controlled goods, software, and technology organised into ten categories and five product groups), each assigned an ECCN (Export Control Classification Number) that determines where a licence is required. The second is items not on the CCL but still subject to the EAR, designated EAR99. EAR99 items face far fewer controls, but they can still be restricted to denied parties or embargoed destinations.

For virtual-asset businesses the critical point is this: the EAR does not care how value moves. A token transfer that pays for, facilitates, or is part of the financing chain for a controlled export is caught if the business or its personnel are US persons, or if the transfer routes through US infrastructure. In our practice, we regularly see businesses assume that because they are not exporters – they are merely processing payments – the EAR does not apply. That assumption is wrong. Facilitation of an unlicensed export by a US person is itself a violation.

The BIS also maintains the Entity List and the Denied Persons List. Dealings with parties on those lists require a licence or are outright prohibited, independently of whether the underlying goods are controlled. A wallet address that resolves to a listed entity creates an immediate stop regardless of the item being paid for.

Step 2 – Map where the travel rule intersects the export-control obligation

The travel rule – the obligation that originator and beneficiary information must accompany a virtual-asset transfer – was developed principally within the AML and financial-crime compliance tradition, not the export-control world. That creates a structural mismatch that a BIS / EAR-aware screening programme must bridge.

Under the travel rule, a VASP (virtual-asset service provider) transmitting funds must pass on the originator's name, account number, and address details alongside the transaction. The underlying logic is that regulators and compliance teams can trace who sent what to whom. From a BIS / EAR perspective, that data is useful – but it answers only the "who" question. Export-control analysis also demands the "what" and "where": what is the economic purpose of the transfer, and does it connect to goods or technology that require a licence?

In practice, the travel rule data a VASP receives is the starting point, not the conclusion, of a BIS / EAR screening workflow. The originator's identity and jurisdiction open the enquiry. The next question is whether the transaction purpose – as disclosed, or as inferable from business context – involves controlled items. That question cannot be answered from a name and an address alone.

A cross-border comparison is instructive here. Under EU rules, the transfer-of-funds regime requires originator and beneficiary data on every crypto-asset transfer regardless of value, applying a zero threshold between crypto-asset service providers. That data richness improves the EU compliance officer's starting position. The US travel-rule position for VASPs has been subject to rulemaking that is still developing; the practical result is that many US-linked VASPs operate with less originator data at the point of screening than their EU counterparts. A business operating across both regimes must manage that gap explicitly – it cannot rely on the weaker data standard to discharge the fuller obligation.

Under OFSI in the United Kingdom, the financial-sanctions obligation and the export-licensing obligation run in parallel, as they do in the US. But OFSI's strict-liability penalty basis – no proof of knowledge required – means that a UK-connected VASP screening for both OFSI and BIS purposes faces two different liability standards simultaneously. The tighter standard governs each element, and there is no netting out between them.

Step 3 – Build the virtual-asset transfer screening checklist

A complete BIS / EAR-aligned virtual-asset transfer screening programme runs in five sequential stages. Working through each stage in order is the only reliable way to ensure that a transfer is clear before value moves.

Stage one: party screening. Screen the originator and beneficiary – and, where the travel rule data is available, any intermediate parties – against the Entity List, the Denied Persons List, and the SDN List. The SDN List is primarily an OFAC instrument, but a hit on it signals potential BIS-relevant risk too; the two regimes often target the same actors. Record the search, the lists checked, the date, and the result. Five years is the minimum record-keeping period under the EAR, as currently in force.

Stage two: destination and end-user analysis. Identify the jurisdiction of the ultimate beneficiary and the stated or inferable purpose of the transfer. Where the destination is a destination for which licence requirements are heightened – or where BIS has applied military end-use and end-user restrictions – that fact triggers enhanced review, not a presumptive clearance. A country's export-control country-group classification determines which licence exceptions apply; that classification can change, and changes apply prospectively.

Stage three: item and purpose review. Establish whether the transfer relates to goods, software, or technology that carries an ECCN. If the purpose is not apparent from the travel-rule data, apply a reasonable-inquiry standard: what does the business relationship suggest? What does the counterparty's industry suggest? A token payment between two parties where one is a semiconductor manufacturer and the other is in a high-control-risk jurisdiction requires deeper analysis than a payment between consumer-goods traders.

Stage four: licence and exception check. If a controlled item is in scope, determine whether a licence exception applies. Exceptions under the EAR are item-, end-use-, and destination-specific. Eligibility cannot be assumed; it must be verified for each transaction. If no exception applies and no licence is held, the transaction must stop pending an application.

Stage five: escalation and hold. Any transaction that cannot be cleared at stages one through four is escalated for counsel review. The escalation must be documented. The transfer must not proceed during the escalation period. In our experience, the absence of a clear escalation protocol – with authority assigned and a documented hold mechanism – is the single most common structural gap we find when reviewing a virtual-asset business's compliance programme.

Step 4 – Identify the risk flags that standard screening misses

Name screening alone is not enough. That is the most persistent myth in virtual-asset compliance, and correcting it is the central practical task of a BIS / EAR alignment exercise. The following risk flags regularly evade standard screening tools and are the points at which a programme fails.

Layered wallet structures. A controlled person's beneficial interest can sit behind two or three intermediate wallets, each of which is clean in isolation. The EAR's ownership analysis is not limited to the direct counterparty. Where BIS has listed an entity, dealings with entities it owns 50 percent or more in the aggregate – applying the same ownership aggregation logic as OFAC's 50 percent rule – require equivalent scrutiny. Screening only the immediate wallet fails this test.

Technology-adjacent payments. A transfer that appears to be a routine commercial payment may, on examination of the business relationship, be financing the acquisition of controlled technology. Advanced computing hardware, semiconductor equipment, and related software all appear on the CCL. A VASP handling payments for a technology trader faces elevated risk if its know-your-customer process has not established what the trader actually sells.

AIS and transit red flags in linked transactions. Maritime sanctions experience is directly relevant here. A sharp change in trade flows to a neighbouring or transit jurisdiction – the same indicator that flags potential cargo diversion in shipping compliance – appears in virtual-asset chains too: a sudden shift in the jurisdiction of a counterparty's transactions, or onward transfers to a high-risk relay jurisdiction immediately after receipt, is a diversion indicator that a rule-based screening system will not catch without a behavioural analytics layer.

Deemed exports through remote access. Where a US person or a US-infrastructure platform releases controlled technology – including through a software-as-a-service product or a remote access arrangement – to a foreign person, that constitutes a deemed export under the EAR, even if no physical item crosses a border. A VASP providing access to a technology platform as part of its service offering may need to assess this angle specifically.

The myth that name screening alone satisfies the rules is understandable – name screening is what most AML-heritage tools are built to do. But a BIS / EAR compliance programme has a different architecture. It is transaction-purpose-led, not name-led. Have you reviewed your current programme against that standard?

Step 5 – Understand cross-regime divergence and when it changes the analysis

A virtual-asset business operating across the US, UK, and EU simultaneously is subject to three overlapping compliance regimes that do not fully align. Understanding where they diverge is not optional: where two regimes both apply, the stricter prohibition governs conduct, and there is no netting one against the other.

The most significant divergence for virtual-asset businesses concerns the knowledge standard. OFAC civil liability under IEEPA is generally strict – no proof of intent or knowledge is required for the violation itself. OFSI in the UK operates on the same strict-liability basis for monetary penalties. BIS enforcement, by contrast, can require proof of knowledge for certain criminal charges, but the civil and administrative enforcement paths do not necessarily carry that requirement. In practice, this means that a business hoping to rely on good-faith ignorance of a party's listed status is in a weak position under all three regimes.

A second divergence concerns the scope of the reporting obligation. OFAC requires blocked-property and rejected-transaction reports within 10 business days of the blocking or rejection. OFSI operates a separate reporting obligation for relevant firms with knowledge or suspicion of a designated person – the timeline and trigger differ from the US rule. The EU imposes its own reporting requirements under the relevant Council regulations. A business with obligations in all three jurisdictions must run three parallel reporting tracks, each with its own trigger and deadline.

Third, the treatment of digital-asset wallet addresses differs by regime. Blockchain analytics is used by regulators in all major jurisdictions to trace wallet clusters; a designation can extend to addresses associated with a designated person. But the methodology by which a regulator connects a wallet to a person – and the degree to which that connection is disclosed to the market – varies. A VASP that relies solely on a public sanctions list without running independent blockchain analytics is operating below the standard that regulators now expect.

For a fuller view of how the travel rule applies across jurisdictions, see our cross-border virtual-asset travel rule guide and the separate EU-specific virtual-asset travel rule guide. Where your business's exposure extends to affiliate-level restrictions under the EAR, our affiliate-level restrictions service page sets out the analysis in detail.

Step 6 – When to involve specialist counsel

There are six situations in which early specialist involvement is not a preference but a necessity. Delay in each of them narrows the options materially.

The first is a positive hit on the Entity List or the Denied Persons List where the business is uncertain whether the item being paid for falls within scope. The analysis requires a classification determination and a licence-exception assessment; both are specialist tasks.

The second is discovery of a past transfer that may have facilitated a controlled export without a licence. The voluntary self-disclosure (a recognised mitigating factor in BIS and OFAC enforcement) decision must be made with full information about the likely enforcement posture, the strength of the mitigating factors, and the statutory limitations period. Counsel needs to see the facts before a decision is made, not after.

The third is a programme design question: a business that is building or revising its virtual-asset compliance programme and needs to map BIS / EAR obligations alongside OFAC, OFSI, and EU requirements. Getting the architecture right at the design stage is significantly less costly than remediating after a regulator enquiry.

The fourth is a transaction-specific clearance question for a high-value or high-risk transfer – for example, a payment involving advanced-computing hardware, semiconductor-related software, or a counterparty in a jurisdiction with elevated control risk. In our cross-border practice, we regularly advise on single-transaction clearance requests of this kind, where the business needs a documented legal assessment before it moves.

The fifth is where a foreign financial institution restriction or a correspondent-account restriction is in play – situations where US authority has been applied against a financial institution in the counterparty's jurisdiction, which then affects the routing of the transfer. That analysis combines BIS / EAR, OFAC, and banking-law considerations in a way that a single-regime compliance team is unlikely to cover adequately.

The sixth is where an enforcement enquiry or a licence application is pending and the business needs to demonstrate that its compliance programme meets the current regulatory standard. Voluntary self-disclosure, enforcement defence, and licence application work all benefit from counsel involvement from the first day, not after the regulator has set the terms of the dialogue.

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