A virtual-asset service provider onboards a corporate client through automated screening. The platform flags nothing. Six months later, a compliance review reveals that the client routes payments through an intermediate wallet controlled by an entity appearing on the Entity List (BIS's list of foreign parties subject to export-licence requirements, maintained under the Export Administration Regulations). The VASP has been processing transactions for months. What now?
Crypto and VASP sanctions compliance under BIS / EAR requires a business to identify whether its technology, software, or services constitute a controlled "export" or "reexport" under the Export Administration Regulations (the EAR, administered by the Bureau of Industry and Security – BIS), and to screen counterparties, wallet addresses, and intermediate nodes against the applicable control lists. As of July 2026, BIS maintains the Entity List, the Denied Persons List, and the Unverified List as primary screening targets; OFAC's SDN List (the list of Specially Designated Nationals and blocked persons) operates in parallel and is not administered by BIS. Failure to meet either set of obligations can result in significant civil and criminal penalties under the applicable regime.
This guide walks through the practical steps: classifying your technology, screening your counterparties, managing the cross-regime overlap with OFAC, OFSI, and EU controls, and designing the programme checkpoints that keep a VASP on the right side of the rules.
Step 1: Classify your technology and establish your EAR obligations
The first question for any VASP is whether its software, technology, or services are subject to the EAR at all – and the answer determines everything that follows.
The EAR applies to items that are "subject to the EAR": goods, software, and technology that originate in the United States, incorporate a threshold level of US-origin content, or are produced using US technology. For a VASP, the relevant categories typically include the underlying cryptographic software, the transaction-matching engine, and any cybersecurity tools used to protect the platform. Each item carries – or should carry – an ECCN (Export Control Classification Number, the alphanumeric code on the Commerce Control List that determines what licence requirements apply to the item). Where no ECCN applies, the item is classified as EAR99, meaning it is subject to the EAR but not to any licence requirement under normal circumstances.
Why does this matter in practice? Because a VASP that licenses its matching engine to an overseas affiliate, provides cloud-based software access to a counterparty in a third country, or supplies technical assistance to a foreign operator may be making an "export" or a "reexport" under the EAR regardless of whether any physical goods move. We regularly advise VASPs that discover mid-transaction that their standard licence terms do not account for EAR obligations at all. The gap is not academic; it is the starting point for every BIS inquiry we have seen in this sector.
The classification step should produce a written technology-control matrix: each product or service line, its ECCN or EAR99 status, and the consequent licence requirement by destination and end use. That matrix is a living document. It needs to be reviewed whenever the technology changes or when the firm enters a new geographic market.
Step 2: Screen against the BIS control lists – and understand what each list requires
BIS maintains three lists that a VASP must screen against, each carrying a different legal consequence.
The Entity List is the most consequential. A person or entity on the Entity List is subject to a licence requirement for any item subject to the EAR, and BIS policy for most Entity List entries is that licences will be denied. This is a hard stop: there is no general licence equivalent that permits routine transactions with Entity List parties. The Denied Persons List records individuals and companies that have been denied export privileges by BIS; transacting with a denied person violates the EAR irrespective of what is being supplied. The Unverified List records foreign parties whose bona fides BIS has been unable to verify; dealing with an Unverified List party raises a "red flag" that requires the exporter to take additional steps before proceeding.
For a VASP, wallet-level screening is not optional. A corporate client may itself clear all three lists, yet route value through intermediate addresses tied to an Entity List party. In our experience, the failure point is almost always at the wallet level rather than the entity level. Screening the named counterparty but not the intermediate nodes is equivalent to screening the payee on a wire transfer while ignoring the correspondent bank.
Screening frequency also matters. A party's status can change between onboarding and the tenth transaction. The prudent standard – which reflects what we see BIS expect in its outreach guidance – is ongoing, transaction-level screening rather than periodic batch review. Verify the current position before relying on any static list snapshot.
Step 3: Manage the OFAC overlap – the two regimes are not the same
BIS and OFAC operate concurrently and independently. A transaction can violate the EAR, OFAC's sanctions programmes, both, or neither. Understanding the difference between them is not optional for a VASP with cross-border exposure.
OFAC administers economic sanctions programmes under IEEPA and TWEA. Its primary screening target is the SDN List. Where a person or entity on the SDN List is involved, OFAC requires the blocking of property and the reporting of the blocked transaction. The 50 percent rule (OFAC's rule treating entities owned 50 percent or more by SDN-listed persons as themselves blocked) applies automatically, without the entity needing to appear on any list. A VASP that processes a transaction on behalf of a company owned 50 percent or more by a listed person has committed a sanctions violation even if the wallet address is clean on every commercial screening tool.
BIS's control mechanism is different. It is licence-based rather than property-blocking. The consequence of supplying a controlled item to an Entity List party is that you have exported without the required licence – a violation of the EAR. There is no "blocking" in the OFAC sense; the obligation is to stop, seek a licence, or decline the transaction.
The practical implication: a VASP's compliance programme must run two parallel analytical tracks. One track asks whether the transaction involves property or interests of a blocked or designated person (OFAC). The other asks whether the technology, software, or service being provided requires a licence under the EAR (BIS). Neither track substitutes for the other. A transaction cleared by OFAC screening can still require a BIS export licence.
Where does the UK regime fit? Under OFSI (the Office of Financial Sanctions Implementation), the ownership and control test (the UK test for whether a non-listed entity is caught through a listed person's control) is not purely mechanical in the way OFAC's 50 percent rule is. OFSI considers control as well as ownership, meaning a 30 percent owner who exercises decisive management influence may bring the target entity within the prohibition. For a VASP with UK customers or a UK-based node, this difference can determine whether a transaction is permitted. We advise clients operating across both jurisdictions to map the control analysis separately rather than assuming OFAC and OFSI reach identical conclusions.
Step 4: Apply the "red flag" standard to suspicious patterns
Both BIS and OFAC operate a "reason to know" standard. A VASP that proceeds in the face of red flags – unusual transaction patterns, obscured wallet structures, onboarding information that does not cohere – will not avoid liability by pointing to a passed screening check.
What counts as a red flag in the crypto context? BIS's published guidance identifies several patterns that should prompt further enquiry: a customer who is reluctant to identify end users, transaction routing that obscures origin or destination, payment in cash or through mixers, requests for items with no obvious application to the stated business, and discrepancies between the stated purpose and the technical specifications of the service. These are not exhaustive. They are indicators that the customer's due-diligence file needs to be upgraded before the transaction proceeds.
For a VASP, the red-flag analysis extends to wallet analytics. Does the wallet address have a history of interaction with addresses associated with sanctioned entities? Does the transaction volume match the stated business profile? Wallet analytics tools are commercially available and their use is, in our experience, increasingly expected as a baseline control rather than an enhancement. A compliance programme that does not incorporate them will find it difficult to argue that it took "reasonable precautions" in a BIS or OFAC enforcement review.
Equally, a VSD (voluntary self-disclosure to a regulator) is a meaningful option when a VASP identifies a past violation. Both BIS and OFAC treat voluntary disclosure as a significant mitigating factor in penalty determinations. The window to act matters: the longer a firm waits after identifying an apparent violation, the weaker the case for mitigation. Have you reviewed your transaction history against current list versions? The question is not rhetorical – it is one of the first we ask in an engagement.
Step 5: Design the programme architecture for a VASP operating across multiple regimes
A VASP with exposure to US, UK, and EU rules needs a programme architecture that is coherent across all three, not three separate compliance silos.
The five elements that appear consistently in what BIS and OFAC both treat as an effective compliance programme are: management commitment, risk assessment, internal controls, testing and auditing, and training. These are not check-the-box items. Management commitment means that senior leadership has formally endorsed the compliance function, allocated resource to it, and is accountable for its outputs. Risk assessment means the VASP has mapped its products, customers, geographies, and delivery channels against the control regimes and has documented where the highest exposures sit.
Internal controls for a VASP specifically should cover: onboarding KYC/KYB requirements calibrated to sanctions risk; transaction monitoring logic that goes beyond entity-level screening to wallet and cluster analysis; escalation procedures for flagged transactions; a process for blocking or rejecting a transaction and reporting it where required; and record-keeping that covers the full transaction chain. Five years is the record-keeping period required under the EAR; verify the current position under each applicable regime before setting your retention policy.
Testing and auditing means the programme is reviewed against actual transaction data, not just against written procedures. We regularly advise VASPs after an internal audit has identified gaps – a product line that was never classified, a customer segment that bypassed enhanced due diligence, a technology update that changed the ECCN but was not reflected in the control matrix. The audit is not a pass-or-fail event; it is a prompt to correct the programme before an external review does it for you.
Cross-border alignment matters. The EU's dual-use regime, administered at member-state level under the applicable EU regulation, imposes its own control requirements on cryptographic software. A VASP with EU operations should not assume that EAR compliance satisfies EU requirements; the two regimes overlap but are not identical. Where both apply, the stricter prohibition governs. The same principle applies across UK, Swiss (SECO), and Australian (DFAT) controls: each regime must be assessed separately, and the most restrictive applicable requirement sets the floor.
Step 6: Identify the escalation triggers and when to involve sanctions counsel
Not every compliance question requires external counsel. But some do – and identifying the boundary in advance is itself a risk-management decision.
The clearest escalation triggers in the VASP context are: a transaction that involves a party on any BIS or OFAC list; a wallet analytics alert linking a customer's address to a known sanctioned cluster; a regulatory enquiry or request for information from BIS, OFAC, or OFSI; an internal audit finding that suggests past transactions may have violated the EAR or a sanctions programme; and any situation where the firm is considering a VSD. In each of these cases, the firm's own legal team – and in most cases external sanctions lawyer and compliance counsel with BIS / EAR experience – should be involved before any action is taken.
The instinct to resolve the issue internally and quickly is understandable. It is also, in our experience, the instinct that most often converts a manageable compliance matter into an enforcement problem. OFAC and BIS both have detailed guidance on the factors that aggravate and mitigate penalty assessments. The single factor that most reliably converts a voluntary disclosure into a reduced penalty outcome is early, well-prepared engagement with the regulator – and that requires legal counsel who knows the process.
In a recent matter, a payment-services business with a VASP subsidiary identified – during a routine wallet-analytics review – a series of transactions that had passed entity-level screening but linked, through three intermediate addresses, to a cluster associated with an Entity List party. We were instructed at that point. We scoped the apparent violation, assessed whether the firm's technology qualified as an item subject to the EAR, advised on the VSD process, and prepared the disclosure. The matter proceeded through the BIS review process; we do not represent that any specific outcome is guaranteed, but early instruction preserved options that would have narrowed with delay.
The position above covers the standard escalation case. Your specific facts – the technology, the customers, the regimes in play, the transaction history – change the analysis materially. If a transaction has already been flagged, or an internal review has surfaced potential violations, an early external review is almost always the right step.
Contact Calder & Vance at info@caldervance.com for a confidential assessment of your VASP's exposure under BIS / EAR and the parallel OFAC and OFSI regimes.
Related practices
- Sanctions compliance audit and testing – programme review, gap analysis, and testing against live transaction data
- Crypto and VASP compliance: BIS / EAR guide, part 3 – extended analysis of licensing and end-use controls for virtual-asset businesses
- Crypto and VASP compliance: BIS / EAR guide, part 4 – enforcement posture, VSD practice, and cross-regime penalty mitigation