DEX Compliance: Can Decentralised Exchanges Meet AML Rules?

This is Part 2 of our "DeFi Compliance" series. In Part 1, we examined whether DeFi falls within the regulatory perimeter. Here, we focus on the most common DeFi primitive — the decentralised exchange — and how front-end operators are navigating AML requirements.

Decentralised exchanges process hundreds of billions of dollars in trading volume annually. Unlike centralised exchanges, DEXs execute trades through smart contracts — automated market makers (AMMs) that operate without an order book, without custody, and without a traditional intermediary. This architecture creates a fundamental tension with AML/CFT frameworks designed around identifiable intermediaries who know their customers.

Yet the question is no longer whether DEXs can be regulated — it is where in the stack compliance controls should be applied. The emerging consensus among regulators, legal scholars, and increasingly the industry itself is that the front-end interface is the natural point of control.

Protocol vs. Front-End: The Critical Distinction

Understanding DEX compliance requires separating two distinct layers:

The Protocol Layer

The smart contracts that execute swaps, manage liquidity pools, and determine prices. Once deployed on a public blockchain, these contracts operate autonomously. Anyone can interact with them directly — through a block explorer, a command-line tool, or a custom interface. The protocol itself does not perform KYC, does not block addresses, and cannot be "shut down" by any single party (assuming the contracts are immutable and deployed on a sufficiently decentralised blockchain).

The Front-End Layer

The web application (e.g., app.uniswap.org, app.aave.com) that provides a user-friendly interface to interact with the protocol. This front-end is:

• Operated by an identifiable entity — Uniswap Labs, Aave Companies, etc.
• Hosted on centralised infrastructure — DNS, web servers, CDNs
• Capable of implementing access controls — wallet screening, geo-blocking, terms of service
• Often monetised — through front-end fees, token allocations, or venture capital funding

This distinction is legally significant. While the protocol may be beyond regulatory reach, the front-end operator is a legal entity with a jurisdiction, a team, and — increasingly — regulatory obligations.

What AML Controls Can DEX Front-Ends Implement?

DEX front-ends cannot replicate the full AML programme of a centralised exchange — they do not hold customer funds, do not require account creation, and typically do not collect personal information. However, they can implement a meaningful set of controls:

1. Wallet Screening

When a user connects their wallet to the front-end, the operator can screen the wallet address against:

• Sanctions lists — OFAC SDN, EU consolidated list, UN sanctions
• Known illicit addresses — addresses associated with hacks, scams, ransomware, darknet markets
• Mixer/tumbler exposure — wallets with recent interactions with mixing services
• High-risk entity labels — addresses linked to unlicensed exchanges, gambling platforms in restricted jurisdictions, or known fraud operations

If the wallet fails screening, the front-end can block the connection or display a warning. This does not prevent the user from interacting with the protocol directly — but it removes the operator's facilitation of the transaction.

2. Geographic Restrictions

Front-ends can implement geo-blocking based on IP address and VPN detection, restricting access from sanctioned jurisdictions (e.g., North Korea, Iran, Cuba, Russia) or jurisdictions where the service is not licensed. While imperfect (users can use VPNs), it demonstrates good-faith compliance effort.

3. Token/Pool Restrictions

Front-ends can delist or hide tokens associated with scams, securities violations, or sanctioned entities. The protocol still supports these tokens, but the front-end does not facilitate their discovery or trading.

4. Transaction-Level Screening

More advanced implementations screen not just the connecting wallet, but also the counterparty risk of each transaction — assessing whether the liquidity pool or token contract the user is interacting with has exposure to sanctioned or illicit addresses.

The Regulatory Landscape for DEXs

MiCA (EU)

Under MiCA, operating a front-end that facilitates the "exchange of crypto-assets for other crypto-assets" (Art. 3(1)(16)(d)) could constitute providing a crypto-asset service. If the front-end operator exercises control over the user experience, collects fees, or curates available tokens, they may need CASP authorisation.

ESMA has not yet issued definitive guidance on DEX front-ends specifically, but the direction of travel is clear: if there is an identifiable operator providing a service, that operator has obligations. The "fully decentralised" exemption in Recital 22 is narrow and fact-dependent.

United States

The regulatory picture in the US is fragmented:

• OFAC — has demonstrated willingness to sanction DeFi protocol addresses (Tornado Cash). All US persons must screen against OFAC lists regardless of the technical architecture.
• SEC — has argued that some DEX protocols facilitate securities trading. The SEC's position on Uniswap (investigation closed without action in 2023) provided some clarity, but the broader legal question remains unresolved.
• CFTC — has taken enforcement action against DeFi protocols offering derivatives (bZx/Ooki DAO), including holding governance token holders personally liable.
• FinCEN — a proposed rule requiring banks and MSBs to report and verify customers for transactions with unhosted wallets was withdrawn in April 2024. No DeFi-specific BSA/AML rulemaking is currently active, though FinCEN retains authority to designate DeFi services as money transmission.

FATF

As discussed in Part 1, FATF's owner/operator test applies to DEXs. If a DEX has an identifiable entity that maintains the front-end, controls protocol parameters, or profits from the protocol, that entity is a VASP with AML/CFT obligations under FATF Recommendation 15.

Technical Implementation: Screening at the Interface

Implementing compliance at the front-end layer requires a screening solution that can operate in the unique constraints of a DEX environment:

• Speed — screening must complete in milliseconds, not seconds. Users expect instant wallet connections. A slow screening API creates UX friction that drives users to unscreened alternatives.
• Coverage — screening must cover all major sanctions lists plus a comprehensive database of high-risk addresses. OFAC alone is insufficient — EU sanctions, mixer addresses, and known scam wallets must also be covered.
• Privacy — the screening query should not require the front-end to transmit unnecessary personal data. Wallet address screening is privacy-preserving by design — no personal information is needed.
• Multi-chain — DEXs operate across multiple blockchains. The screening solution must support Ethereum, Polygon, Arbitrum, Optimism, Base, BSC, Solana, and emerging L2s.
• Auditability — the front-end operator needs a log of every screening decision for regulatory defence. If a sanctioned address was blocked, the record should show when and why.

How BlockchainAnalysis Powers DEX Front-End Compliance

BlockchainAnalysis provides a screening API purpose-built for DeFi front-ends. When a wallet connects to your interface, a single API call returns a risk assessment in milliseconds — covering OFAC, EU, and UN sanctions, plus our proprietary database of 1B+ labelled addresses across 80+ blockchains.

The integration is lightweight: a single API call at wallet connection, with optional transaction-level screening for higher-risk interactions. The API returns structured risk data — sanctions matches, risk scores, entity labels, and exposure analysis — enabling the front-end to make programmatic decisions about access and functionality.

For DEX operators who need to demonstrate compliance to regulators without compromising the decentralised user experience, our screening API operates as a compliance layer at the interface — exactly where regulators expect controls to exist.

Next in the series: DeFi Compliance #3 — Stablecoin Regulation Under MiCA: EMT vs ART Requirements, where we examine how MiCA's stablecoin framework applies to issuers and the operational implications for CASPs that list, custody, or transfer stablecoins.