Virtual-asset transfer screening and the travel rule under BIS / EAR: support

A virtual-asset business operating between the United States and Europe closes a promising token-transfer partnership, only to discover weeks later that its counterparty's wallet cluster has been linked to a restricted end-user under the Bureau of Industry and Security's controls. The transaction has already settled. The compliance team had screened the company name. Nobody had mapped the technology transferred, the destination jurisdiction, or the downstream application. That gap – between name screening and a full export-control analysis – is where the real exposure lives. And as of January 2026, that exposure is growing.

Virtual-asset transfer screening and the travel rule under BIS / EAR legal support covers the intersection of US export-control obligations with the cross-border movement of digital assets: classifying controlled technology embedded in wallet infrastructure, applying the travel rule (the obligation to transmit originator and beneficiary information alongside a transfer) to transactions that may also carry export-control risk, screening counterparties against the Entity List and Denied Persons List, and identifying when a deemed-export analysis is required. BIS administers these obligations under the Export Administration Regulations. Name screening alone is not sufficient: a complete control requires item classification, end-user verification, and jurisdiction mapping on every relevant transfer.

This page explains the problem in practical terms, sets out the governing regime and procedure, maps the cross-regime picture across OFAC and the EU, identifies the risk flags that most often surface in virtual-asset contexts, and describes how Calder & Vance assists businesses that need expert guidance here.

Why virtual-asset businesses face an export-control problem they did not expect

Export controls do not attach to the physical movement of goods alone. They attach to technology and software. Virtual-asset platforms routinely develop, license, and transmit software and related technical data that may be classified on the Commerce Control List. When that software crosses a border – or is accessed remotely by a foreign person – the EAR can apply. The risk is structural, not incidental.

Consider the range of activity a typical exchange or wallet provider conducts in a single trading day. It releases software updates to nodes operating in multiple jurisdictions. It grants API access to institutional counterparties whose beneficial owners may sit in restricted destinations. It transmits transaction data – potentially including cryptographic parameters and protocol specifications – to foreign persons as a matter of operational routine. Each of those flows is a candidate for export-control analysis under the EAR.

The classification question starts with the Export Control Classification Number (ECCN – the code on the Commerce Control List that specifies which licence requirements apply to a given item). Items that are subject to the EAR but do not appear on the CCL are designated EAR99. For most common consumer software EAR99 is the answer. But cryptographic software with functionality beyond broadly available mass-market specifications, security technology, or software with military or intelligence end-uses can carry a higher ECCN with licence requirements that bite immediately on export to certain destinations. Have you confirmed the ECCN for every software component in your stack?

The deemed-export rule adds another dimension. A deemed export occurs when controlled technology or source code is released to a foreign national inside the United States. Remote access – a code repository shared with a developer in a restricted destination, a technical briefing given to a foreign-national employee, a platform demonstration given over videoconference – is sufficient. Virtual-asset businesses that operate globally and employ internationally mobile technical staff are exposed to deemed-export risk with almost every significant product release.

In our experience, the majority of virtual-asset businesses that first approach us have no ECCN determination on file and have not mapped their technology-release activity against their workforce's nationality and location. That is not a failing unique to smaller operators: we see the same gap at well-resourced institutions that have invested heavily in financial-crime controls but have not extended the same rigour to their export-control programme.

The travel rule: where financial-compliance obligations and export-control risk converge

The travel rule requires that originator and beneficiary information travels with a virtual-asset transfer. In most major jurisdictions the rule is framed as a financial-crime or anti-money-laundering obligation administered by the financial regulator. But the information collected and transmitted under the travel rule is precisely the information needed to run a complete export-control screening: who is the originator, who is the beneficiary, what is their jurisdiction, and what is the underlying business purpose of the transfer?

Where an exchange or wallet provider collects travel-rule data and does not feed it into an export-control screening process, it has the raw material for a complete check but has only used it for half the task. The FATF-aligned travel rule frameworks operating in the EU, UK, Singapore, and elsewhere generally require a zero threshold for transfers between virtual-asset service providers: originator and beneficiary data is required on every transfer regardless of value. Under the EU's transfer-of-funds regime, that zero-threshold requirement applies to transfers between crypto-asset service providers, meaning the data collection burden is already embedded in operational workflows.

That data – collected for financial-crime purposes – is also relevant to BIS. An institutional counterparty whose beneficial owner controls a node in a destination subject to military end-use restrictions raises an export-control question that the travel-rule data can help answer. The compliance architecture should be integrated: a single counterparty-identification and transaction-monitoring process that feeds both the financial-crime and export-control workflows, rather than two separate silos that never speak to each other.

In our cross-border practice, we work with compliance teams to map the travel-rule data they already collect against the Entity List and Denied Persons List, identify the destinations that trigger heightened end-use review, and design the escalation logic that flags a transaction for export-control assessment when the travel-rule data raises a concern. That integration is more efficient than it sounds; it does not require rebuilding the compliance architecture from the ground up.

How the BIS screening procedure works in a virtual-asset context

The BIS screening process for a virtual-asset business has five operational steps, each of which differs in important respects from the standard name-screening exercise that most compliance teams already run.

Step 1 – Item classification. Before any transaction is screened, the business must determine whether the technology or software involved is subject to the EAR and, if so, what its ECCN is. Classification is the responsibility of the exporter or transferor. It is not a one-time exercise: it must be revisited whenever the product changes materially, whenever the regulatory lists are updated, and whenever a new use-case emerges that might alter the end-use analysis.

Step 2 – Party screening. The counterparty, the beneficial owner, and any known intermediary are screened against the Entity List, the Denied Persons List, the Unverified List, and the Military End-User list. BIS maintains these lists; dealings with listed parties require a licence or are prohibited, depending on the list and the applicable reason for control. Name screening is a starting point, not an end point: a counterparty that does not appear by name may still be captured through the 50 percent rule for entities owned by listed parties, as currently in force – verify before reliance.

Step 3 – Destination and end-use review. The destination of the export or deemed export is mapped against the EAR's country-group framework. The country-group classification determines which licence requirements and licence exceptions are available. Military end-use and end-user controls apply to specified destinations and require heightened diligence beyond standard list screening; BIS administers these controls under the EAR.

Step 4 – Licence exception analysis or licence application. If a licence requirement is identified, the compliance team must determine whether a licence exception covers the transaction or whether a specific licence application to BIS is required. Licence exceptions under the EAR are item-, end-use-, and destination-specific. An incorrect reliance on an exception that does not apply is itself a violation. In our experience, this is one of the most common error points in virtual-asset export-control programmes.

Step 5 – Record-keeping. Records relating to the transaction, the classification determination, the party-screening result, and any licence or licence-exception reliance must be retained. US export-control record-keeping requirements specify a retention period; businesses should verify the current requirement with counsel and maintain records accordingly.

Cross-regime picture: how OFAC and the EU differ from BIS on virtual-asset screening

A business operating in virtual assets almost certainly faces obligations under more than one regime simultaneously. Understanding where those regimes converge – and where they diverge – is essential to building a control that works across all of them.

OFAC. OFAC's sanctions programmes are list-based and territorial: the question is whether a counterparty appears on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons), or is owned 50 percent or more in the aggregate by blocked persons. OFAC's liability is strict: knowledge or intent is not required for the underlying civil violation. Importantly, OFAC has designated wallet addresses associated with designated persons; a screening process that checks only legal names and corporate identities without also checking known wallet addresses is incomplete for OFAC purposes. OFAC and BIS operate separately: a transaction might be clean under OFAC but require a BIS licence, or vice versa. Where both regimes apply, the stricter prohibition governs.

OFSI and the UK regime. OFSI administers UK financial sanctions under SAMLA. The ownership-and-control test under UK rules can catch a non-listed entity that is controlled by a designated person, going further than OFAC's purely ownership-based threshold. OFSI can impose monetary penalties on a strict-liability basis, as currently in force – verify before reliance. The UK's travel-rule obligations for cryptoasset businesses are administered separately by the FCA; a business facing OFSI sanctions exposure and FCA travel-rule requirements may be running two separate compliance obligations that should be integrated.

EU regime. EU sanctions are imposed by Council Regulation. The EU's asset-freeze test extends to making funds or economic resources available, directly or indirectly, to or for the benefit of listed persons – a broader formulation than OFAC's blocking framework. The EU's transfer-of-funds regime applies its zero-threshold travel-rule requirement to crypto-asset service providers. The EU Blocking Regulation can in principle prohibit EU operators from complying with specified US measures, creating a genuine compliance conflict for businesses operating on both sides of the Atlantic.

For a business subject to all three regimes, the practical answer is a single unified screening architecture that applies each regime's specific tests to the transaction data already collected under the travel rule, rather than three separate processes each acting on the same underlying data set. That is the architecture we help clients design and implement.

What are the main risks in virtual-asset transfer screening and the travel rule under BIS / EAR?

The principal risk flags we see in virtual-asset export-control practice fall into five categories. Each represents a gap where a control that looked adequate at the time of design fails under operating conditions.

Classification error. Treating all software components as EAR99 without a documented classification analysis is a structural control failure. Cryptographic items, security monitoring technology, and protocol software can carry ECCNs that require a licence to export to specified destinations. A classification error does not become apparent until a breach is under investigation, at which point the remediation cost is multiples of the preventive cost.

Wallet-level screening gap. A screening process that checks the name of the counterparty legal entity but does not verify the beneficial owner's identity, the jurisdiction of the originating node, or the wallet addresses associated with the transaction misses the most common pattern of sanctions exposure in virtual-asset markets. Blockchain analytics tools exist precisely to close this gap; their output should be integrated into the party-screening workflow rather than treated as a separate exercise.

Deemed-export exposure from technical collaboration. International technical teams, remote-access development environments, and cross-border investor briefings all create deemed-export risk. Many virtual-asset businesses have not mapped their technology-release activity against their workforce and investor base. The first time the deemed-export analysis is done is often in response to a BIS inquiry.

Licence-exception misreliance. The EAR provides licence exceptions that can cover many common transactions. But eligibility is item-, destination-, and end-use-specific. Relying on an exception without a documented eligibility analysis – or continuing to rely on an exception after a product update that changes the item's classification – creates an unrecorded violation that may not surface until a voluntary self-disclosure or an enforcement action.

Travel-rule data silos. Collecting counterparty identification data for AML and travel-rule purposes but not routing that data into the export-control screening process means the business has the information it needs to conduct a proper check but has not used it. This is a programme-design failure, not a data failure.

Is your current screening programme addressing all five of these gaps, or has it been designed primarily to meet financial-crime requirements with export-control screening treated as an afterthought?

The myth that name screening alone is enough

The most persistent misconception we encounter is that screening the counterparty's name against sanctions lists satisfies the BIS / EAR compliance requirement for virtual-asset transfers. It does not, for at least four distinct reasons.

First, BIS obligations are triggered by item classification, not only by counterparty identity. If the software or technology involved is controlled, a licence may be required regardless of whether the counterparty appears on any list.

Second, the Entity List and related BIS lists operate differently from OFAC's SDN List. A party that does not appear by name may still be captured through ownership links to a listed entity; a party that appears on the Unverified List does not trigger the same prohibition as one on the Entity List, but does require heightened diligence before proceeding.

Third, deemed exports are not counterparty transactions at all. A foreign national accessing controlled technology inside the United States is not captured by a transactional screening process. It requires a separate mapping of technology access against workforce and visitor records.

Fourth, the military end-use and end-user controls that apply to specified destinations are triggered by the nature of the end-use, not only by the identity of the named party. A transaction to an unlisted entity that will use the technology for a military application in a specified destination may require a licence regardless of the clean screening result.

We regularly advise compliance teams that have invested significant resource in name-screening tooling and are surprised to discover that the tooling addresses only one part of a multi-part compliance requirement. The correction is not to replace the screening infrastructure but to layer the item-classification, deemed-export, and end-use analyses on top of it.

How Calder & Vance assists: from risk mapping to programme design

Our work on virtual-asset transfer screening and the travel rule under BIS / EAR covers the full range of tasks a business in this space is likely to need, from an initial exposure assessment to a fully integrated compliance programme and ongoing advisory support.

For businesses encountering this issue for the first time, we begin with a technology and transaction mapping exercise: we work through the product stack to identify controlled items, map the jurisdictions to which they are exported or accessed, and identify the workforce and counterparty populations that create deemed-export risk. This gives the compliance team a clear picture of where the exposure sits before any remediation is designed.

Where a classification has not been completed, we assist with ECCN determination: applying the item parameters against the Commerce Control List, identifying the applicable reason for control, and documenting the determination in a form that withstands regulatory scrutiny.

We then work with the compliance team to test the screening logic, map ownership and control across the Entity List and related BIS lists, and redesign the programme to integrate travel-rule data collection into the export-control workflow. This is the single most effective change a virtual-asset compliance team can make: using the data it already collects for financial-crime purposes to run a concurrent export-control check, rather than treating the two as separate exercises.

For clients that have identified a potential breach – a transaction that proceeded without a required licence determination, or a deemed export that was not identified at the time – we scope the apparent violation, advise on voluntary self-disclosure (VSD – a recognised mitigating factor under OFAC's Enforcement Guidelines and a mechanism available under the EAR), and prepare the position for the regulator. Early advice is material here: the options available in the first days after identification narrow quickly.

In a recent matter, a financial-technology business providing blockchain infrastructure services discovered that it had been transmitting protocol specifications to a counterparty network that included nodes operating in a destination subject to military end-use controls. The item classification had never been conducted. We assessed the ECCN, mapped the affected transactions, and advised on the voluntary disclosure process. The matter was handled under a structured programme that addressed both the immediate exposure and the longer-term programme gaps.

For clients operating under multiple regimes – OFAC, OFSI, and EU simultaneously alongside BIS – we provide an integrated analysis that maps each regime's obligations against the same transaction data, identifies where the stricter prohibition governs, and designs the escalation logic to handle each type of flag correctly. That cross-regime capability is what distinguishes specialist sanctions and export-control counsel from a standard financial-crime advisory.

A law firm for virtual-asset transfer screening and the travel rule under BIS / EAR that understands both the regulatory technology and the underlying export-control law can move faster and produce more durable results than one that approaches the task from only the financial-crime direction. We act for multinationals, financial institutions, and exporters on sanctions and export-control matters across the major regimes.

Related practices

• Affiliate-level restrictions under BIS / EAR – managing export-control obligations for affiliated entities and group-wide compliance.
• BIS / EAR vs EU: affiliate-level restrictions analysis – a side-by-side comparison of the US and EU approaches to group-entity controls.
• BIS / EAR vs OFAC: affiliate-level restrictions analysis – how BIS and OFAC frameworks interact and diverge for group structures.

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