AML screening for crypto exchanges and VASPs

AML screening for crypto firms is sanctions, PEP and adverse-media screening extended to an on-chain environment, where the party on the other side of a transaction may be identified only by a wallet address and value can settle in seconds. The obligations are not new; virtual asset service providers are regulated financial institutions in most jurisdictions and are expected to screen customers and counterparties as any other regulated firm would. What changes is the operating environment: pseudonymous identifiers, unhosted wallets with no institution behind them, and throughput that leaves no room for a screening step that throttles the flow. A crypto screening program has to handle all three without letting detection quality fall.

Why is AML screening different for crypto?

The obligation is the same, but three features of virtual assets change how screening has to work. First, identifiers are pseudonymous: a counterparty is often a wallet address, not a named person or company, so the richest matching signal, the name, may be absent at the point of transaction. Second, settlement is fast and often irreversible, which means a screening control that adds latency either slows the business or gets bypassed, so it has to run at speed. Third, transactions can involve unhosted wallets with no regulated institution on the other side to share diligence with. Layered on top is the on-chain dimension itself: screening now covers not only the customer's identity but the addresses they send to and receive from, checked against designated addresses and against the risk associated with the entities behind them. None of this removes the sanctions, PEP and adverse-media obligations; it adds a technical layer to meeting them.

What are sanctioned wallets and addresses?

Sanctions authorities now designate specific cryptocurrency wallet addresses, not just people and companies. OFAC, for example, has added digital-currency addresses to its Specially Designated Nationals list as identifiers attached to designated parties, so a wallet address can be a listed entry in its own right. A transaction to or from a designated address is a direct sanctions exposure, the on-chain equivalent of dealing with a named SDN. Screening therefore has to check the addresses involved in a transfer against these designated-address entries, alongside the usual name-based screening of the customer. Because addresses can be created without limit and value can be moved through fresh ones, address screening alone catches only the addresses already listed. The exposure often sits one step back, in the entity that controls a cluster of addresses, which is why address matching has to be paired with resolution of the party behind it, the same principle set out in our guide to sanctions lists.

How does travel-rule counterparty screening work?

The travel rule, drawn from FATF guidance for virtual assets, requires that when value moves between two service providers, originator and beneficiary information travels with the transfer, just as it does for a wire between banks. That data is exactly what screening then acts on. When a provider receives the required originator and beneficiary details for an inbound or outbound transfer, it screens those parties against sanctions, PEP and adverse-media coverage before completing the transaction, and checks the counterparty provider itself. The rule pulls the other side of the transaction into scope, so screening is no longer only about your own customer; it extends to the person or entity your customer is transacting with. Where the counterparty is another regulated provider, the required data supports that screening. Where it is not, or where the data is missing or inconsistent, that gap is itself a risk signal the program has to weigh rather than ignore.

What is the risk from unhosted wallets?

An unhosted, or self-hosted, wallet is controlled directly by an individual rather than held at a regulated provider, so a transfer to or from one has no institution on the other side to conduct diligence or supply travel-rule data. That does not make the transfer prohibited, but it does remove a control that exists in institution-to-institution transfers, so the screening burden falls entirely on your side. The program has to screen the unhosted address against designated-address lists, weigh the on-chain behaviour associated with it, and resolve, as far as possible, the entity that controls it. The absence of a counterparty institution is itself a factor in the risk assessment: it raises the weight placed on on-chain analysis and entity resolution, because there is no second regulated firm to share the picture. Handling unhosted-wallet exposure well is less about a single match and more about combining address screening with the entity signals around it.

How do you screen at crypto throughput?

Crypto settles fast, so screening has to return a decision without becoming the bottleneck. A control that adds noticeable latency to every transfer either degrades the customer experience or, worse, gets routed around, so throughput is a design requirement rather than a nice-to-have. Meeting it means screening that resolves matches quickly and precisely, so the system is not both slow and noisy. The false-positive problem compounds here: at volume, a screening engine that raises weak alerts on common-name or partial matches forces a manual queue that cannot keep pace with settlement, and the vast majority of those alerts are not real. This is where precise matching earns its place, because reducing false positives is what lets a program screen every transaction in real time without a review backlog forming. Our screening engine is designed to reduce false positives by up to 80% through agentic entity resolution, which is what keeps throughput and detection quality aligned rather than in tension.

How does BriteBase screen for crypto firms?

Our screening platform applies the same sanctions, PEP and adverse-media coverage crypto firms need, delivered as a self-serve screening API for real-time transaction and onboarding checks or as a unified case-management platform. Sanctions coverage spans OFAC, Canada, the EU, the UK, Australia and APAC regimes, including designated addresses where authorities publish them, and the data layer is structured for agentic entity resolution rather than delivered as raw feeds. That structure is what lets deep-tier ownership and the 50% Rule apply to the entity behind an address, not just to a listed name, and material decisions stay under human review. For the program and registration context that sits around this, a Canadian VASP can start with our VASP compliance primer, and the industry view is set out on our crypto and digital assets page.

FAQ