A virtual-asset exchange processes thousands of transactions daily. Its automated screening catches wallet addresses on the SDN List (OFAC's list of Specially Designated Nationals and blocked persons). But what about the software library powering its transaction-validation node? That library was compiled using components that carry an ECCN (Export Control Classification Number under the US Commerce Control List). The exchange's engineers updated it last month from a mirror server routed through a jurisdiction on the restricted-party lists maintained by BIS (the Bureau of Industry and Security, which administers US export controls under the Export Administration Regulations). The compliance team never saw it happen. That is the gap this guide addresses.
As of July 2026, virtual-asset service providers and crypto-infrastructure businesses face a dual sanctions and export-control obligation under US law: OFAC governs financial prohibitions against designated persons, while BIS and the EAR (the Export Administration Regulations) govern the transfer of controlled technology, software, and hardware to restricted destinations or parties. Both regimes bite simultaneously. Failing to manage either one creates civil and, in serious cases, criminal exposure – and neither agency regards ignorance of the technical controls layer as a mitigating factor.
This guide sets out six practical steps to manage crypto and VASP sanctions compliance under BIS / EAR, compares the BIS / EAR position with OFSI, the EU, and SECO obligations where they diverge, and identifies the risk flags that, in our experience, most commonly precipitate enforcement attention.
Step 1: Understand which BIS / EAR obligations apply to your crypto business
The EAR applies to any item – including software and technology – that originates in the United States or incorporates more than a de minimis threshold of US-origin controlled content, wherever in the world the exporting party is located. For a virtual-asset business, that catches more than most compliance teams expect: consensus software, cryptographic libraries, hardware security modules, zero-knowledge proof tooling, and node-client technology can each carry an ECCN classification that triggers licence requirements when transferred to a restricted destination or person.
The first step is to build an inventory. A technology-control plan (a structured record of which items your business develops, licences, or re-exports, and to whom) is standard practice for hardware exporters but is rarely seen in VASP compliance programmes. In our experience, most crypto firms have not classified the software components embedded in their products, have not identified whether US-origin content crosses the relevant threshold, and have not checked whether their cloud-infrastructure providers route processing through jurisdictions that trigger EAR destination controls.
The BIS Entity List – which identifies parties to whom exports, re-exports, and in-country transfers require a licence even for otherwise licence-free items – is a distinct list from the SDN List. Screening one without the other leaves a material gap. Have you verified that your screening logic queries both?
Step 2: Classify your software, technology, and hardware under the Commerce Control List
Correct ECCN classification is the foundation of EAR compliance; it determines which export-licence exceptions are available and which destinations and end-uses are controlled. Many crypto and blockchain software products qualify as EAR99 (items not specifically enumerated on the Commerce Control List and therefore subject only to the basic EAR prohibitions), but that determination must be made deliberately, not assumed.
Encryption functionality is the most common classification trigger for virtual-asset businesses. Software that implements or incorporates cryptographic algorithms may be classified at a category that restricts transfer to certain destinations without a licence or a self-classification filing. The EAR's encryption provisions have been revised repeatedly, and the applicable classification depends on the algorithm, key length, and the nature of the end-use. A classification memo should be reviewed whenever a product's cryptographic architecture changes materially.
Dual-use considerations arise at the hardware layer too. Hardware security modules, specialised mining hardware, and data-centre equipment used to run blockchain infrastructure have each drawn BIS attention in recent enforcement cycles. The classification analysis for physical goods follows the same Commerce Control List structure, but the destination controls and available exceptions differ from software. Businesses that manufacture or import hardware components for crypto infrastructure should treat the classification question as live, not settled.
Step 3: Screen counterparties, customers, and technical partners against the full US restricted-party universe
OFAC screening against the SDN List is, at this point, a baseline expectation – but it is not sufficient for BIS / EAR compliance. The complete US restricted-party universe for a VASP includes the SDN List, the BIS Entity List, the BIS Denied Persons List, the BIS Unverified List (which carries a red-flag obligation rather than an outright prohibition), and the State Department's debarment lists. A transaction that clears OFAC screening may still require a BIS licence if the counterparty appears on the Entity List.
Wallet-address screening is necessary but not equivalent to counterparty screening. A wallet is not a legal person. The underlying beneficial owner of that wallet may be a designated entity, a restricted party, or an entity owned 50 percent or more by a blocked person and therefore itself treated as blocked under OFAC's 50 percent rule (the rule treating entities owned 50 percent or more by blocked persons as themselves blocked). VASP compliance programmes that rely exclusively on wallet-screening miss the ownership-chain question entirely.
The cross-border dimension is acute here. A developer integrating a VASP's API may be located in a third country but may herself be on the BIS Entity List – perhaps because a previous employer exported controlled items without a licence. In our practice, counterparty screening for crypto infrastructure clients now routinely covers the individuals behind the technical integrations, not only the corporate contracting parties.
Step 4: Map destination controls and apply them to on-chain and off-chain activity
The EAR prohibits the export and re-export of controlled items to comprehensively sanctioned destinations without a licence, and licences for such destinations are generally unavailable as a matter of policy. For a VASP, "export" includes making controlled technology or source code available for download or access from a restricted destination – which means that a publicly accessible node client, an open-source SDK, or a developer portal can constitute an export if the technology is controlled and a user in a restricted destination accesses it.
IP-address geolocation filtering is the most common control deployed to manage this risk. It is not, however, a complete solution. VPN usage, Tor routing, and jurisdictional proxies can defeat IP-based controls. A sound destination-control programme pairs geolocation filtering with account-onboarding controls that verify claimed jurisdiction at the identity level, periodic re-verification for high-risk accounts, and a documented escalation path for anomalies. Where the technology is EAR99, the destination control is less restrictive, but comprehensively restricted destinations remain prohibited regardless of classification.
How does the BIS / EAR destination-control picture compare with the EU and UK positions? The EU dual-use regulation (the EU rules governing exports of items with both civil and military applications) imposes similar destination controls for listed technologies, including cryptographic items, but the catch-all control mechanism and the end-use certificate requirements differ in their procedural detail. OFSI in the United Kingdom applies financial prohibitions to persons and entities, not directly to technology transfers, but the UK Export Control Order imposes its own dual-use controls that parallel the EAR in structure. A business operating across US, UK, and EU infrastructure must manage all three in parallel; a licence or exception under one regime does not provide cover under another. Where regimes conflict, the stricter prohibition governs.
Step 5: Establish a documented compliance programme and record-keeping system
A written compliance programme is both a substantive obligation and the primary mitigation factor in any BIS enforcement proceeding. BIS's assessment of whether to pursue enforcement, and at what severity, takes into account whether the exporter had a functioning compliance programme at the time of the apparent violation. A VASP that can demonstrate documented classification decisions, screening logs, escalation procedures, and training records is in a materially different position to one that operated on informal practice.
Record-keeping under the EAR covers export-related transactions and must be maintained for a defined period – verify the current period against BIS guidance before relying on any stated figure, as this area is subject to regulatory update. Records include communications, contracts, shipping documents, classification memoranda, and the results of restricted-party screening. For a VASP, transaction logs and the underlying KYC/AML records for customer accounts form part of the compliance record to the extent they relate to export-controlled software or technology transfers.
The voluntary self-disclosure (VSD) mechanism – a process by which a party discloses an apparent violation to BIS before enforcement is initiated – is available to VASPs in the same way as to hardware exporters. A timely and well-prepared VSD can reduce penalty exposure significantly. In our experience, the decision about whether to make a VSD, and how to prepare it, is one of the most consequential calls in an export-control matter; it should not be made without specialist advice. We regularly advise clients on the VSD analysis, from scoping the apparent violation through to preparing the submission and managing BIS queries.
Step 6: Identify red flags and know when to involve counsel
BIS identifies a set of recognised red flags that, when present, impose a duty of inquiry on the exporter. Ignoring a red flag – proceeding without resolving it – can convert an otherwise-innocent transfer into a knowing violation. For a VASP, the relevant red flags translate into patterns that a compliance officer should be trained to recognise.
Common red flags in the crypto context include: a counterparty that is reluctant to provide standard KYC information about the end use of controlled software; a transaction structure that routes technology access through a jurisdiction that is not the stated location of the end-user; an API integration request that involves a product version with stronger cryptographic controls than the stated use case requires; and a developer account that was created from an IP address inconsistent with the claimed national jurisdiction of the account holder. None of these individually constitutes a violation. All of them require documented resolution before the transfer proceeds.
The OFAC-parallel risk flags are somewhat different in character. An OFAC red flag for a VASP might be a wallet that transacts in patterns consistent with known mixing services, a counterparty whose beneficial-ownership disclosure produces names that appear on secondary-sanctions watch-lists, or a fund flow that passes through a jurisdiction subject to comprehensive US sanctions. In our cross-border practice, we see these two categories of red flag – the BIS technical-controls layer and the OFAC financial-prohibitions layer – appear together in the same transaction more often than clients anticipate. The intersection is where the most serious exposure sits.
When should you involve sanctions lawyer or compliance counsel? The clearest triggers are: a potential red flag that the internal team cannot resolve; a transaction that involves a counterparty in or connected to a restricted destination; an apparent violation, whether discovered internally or raised by a counterparty or bank; a VSD decision; and any significant change to the product's cryptographic architecture or distribution model. Earlier involvement costs less than post-enforcement remediation – and the options available to a business narrow quickly once a BIS or OFAC inquiry is under way.
The position above covers the standard compliance analysis. Your specific facts – the technology stack, the customer base, the jurisdictions in play, the counterparty structures – change the analysis. To discuss your exposure under BIS / EAR, contact Calder & Vance at info@caldervance.com.
A common myth: "Crypto is borderless, so export controls do not apply to us"
The most persistent misunderstanding in VASP compliance is the belief that because a blockchain is decentralised and software can be downloaded from anywhere, the EAR simply does not apply. It does. The EAR applies to the transfer of controlled US-origin technology regardless of the medium of transfer. A download is an export. An API call that causes controlled code to execute in a restricted jurisdiction can constitute a deemed export or re-export.
The corollary myth is that open-source publication removes the EAR obligation. Making software publicly available can, under certain conditions, engage an EAR exception for published technology – but the conditions are precise and the exception does not extend to all categories of controlled technology, nor does it apply to transfers to comprehensively restricted destinations. In our practice, we regularly advise technology businesses that assumed their open-source publication strategy had resolved the export-control question. It had not. The analysis must be done properly, in writing, and it must track any change in the software's functionality.
A third misconception is that OFAC compliance is sufficient and BIS / EAR compliance is optional for a financial-services business. The two agencies operate distinct statutory authorities. OFAC's jurisdiction is financial prohibitions; BIS's jurisdiction is controlled-technology transfers. A VASP is potentially in both categories simultaneously. Running a thorough OFAC programme while ignoring the EAR is not a compliance programme – it is a partial one.
If a transaction has already been flagged, or if an apparent violation has been identified, early specialist review can preserve options that narrow with time. For a confidential review, contact us at info@caldervance.com.
Related practices
- Sanctions compliance audit and testing – independent testing of screening logic, programme design, and record-keeping against regulatory standards.
- Crypto and VASP sanctions compliance: the OFAC layer – how OFAC financial prohibitions interact with virtual-asset business models.
- Crypto and VASP sanctions compliance: the EU and UK dimension – EU dual-use rules and OFSI obligations for cross-border virtual-asset businesses.