DeFi Compliance: How to Navigate Regulatory Requirements

DeFi compliance is the operational process by which an identifiable person or entity behind a decentralized-finance protocol meets AML/CFT, sanctions and KYC obligations: KYC at fiat ramps, OFAC screening at the front-end, transaction monitoring, suspicious-transaction reporting and the Travel Rule. Code does not comply. The controller does.

That single sentence carries the whole problem. There is no compliance module you bolt onto a smart contract. The obligations attach to whoever the Financial Action Task Force (FATF) or EU regulators find to be an identifiable controller: the founding team, the foundation, the front-end operator, or a partnered exchange. Once such a person exists, the day-to-day programme looks much like any VASP or CASP AML programme, applied at the points where the protocol touches identifiable users and fiat. This guide covers those operational steps. For the legal-framework question of who is even in scope, see the DeFi legal framework.

What Is DeFi Compliance? (And Why Code Can't Comply)

DeFi compliance means the set of AML, sanctions and KYC controls run by the identifiable person or entity behind a decentralized protocol. It is not a property of the smart contract itself. Immutable code cannot perform customer due diligence, file a suspicious-transaction report, or screen a wallet against a sanctions list. People and organisations do those things, and the law looks for them.

The practical implication is that "compliance" in DeFi is really a question of *which surface* of the stack is operated by an obligated person, and what that person must run. FATF frames it bluntly: in many cases, decentralized-finance arrangements are decentralized in name only, and there are persons or centralized elements that may be subject to AML/CFT requirements as virtual asset service providers (VASPs) (FATF June 2023 Targeted Update, para 39).

Compliance vs regulation: which page you need

Regulation and compliance are adjacent but distinct. Regulation is the legal framework: which body governs you, whether you are in scope at all, how FATF, MiCA and US rules compare, and where the grey zones sit. Compliance is what you actually do once you are (or might be) in scope: the AML programme, OFAC screening, KYC at ramps, the Travel Rule and governance risk.

This page owns the operational angle. If you are trying to work out *whether* your protocol is caught, read the DeFi legal framework, which keeps the FATF-versus-MiCA-versus-US comparison and the owner/operator analysis. Here we assume you may be in scope and show you what to build.

The four operational surfaces of a DeFi protocol

Compliance concentrates where the protocol meets people and money. There are four operational surfaces, and obligations land wherever one of them is operated by an identifiable controller (FATF June 2023 Targeted Update, para 39):

• The front-end / interface: the hosted web app or DEX UI that users actually click. The most centralized and easiest-to-reach layer.
• The fiat on/off ramps: exchanges, payment processors and ramps a user passes through to enter or exit the protocol. Unambiguous VASPs running full KYC.
• Any custodial or fee-taking function: holding user assets, or routing orders and skimming fees, both look like regulated activity.
• Governance: the foundation, core team or DAO that controls treasury, parameters or a fee switch.

The rest of this guide walks each surface and the programme that sits on top of it.

Is Your DeFi Project In Scope? The FATF Control Test

Before you build anything, answer the gating question: is there an identifiable person or entity with control or sufficient influence over the arrangement? If yes, that person is treated as a VASP and must run the AML programme below. If no, a genuinely ownerless, non-custodial, immutable protocol strains the tests, but FATF's posture is that decentralized-in-name-only arrangements are caught.

This is not a fringe view. Of the advanced, Travel-Rule-implementing jurisdictions FATF surveyed, more than half (37 of 62 respondents) already require certain DeFi arrangements to be licensed or registered as a VASP, typically where the creator, owner or operator maintains control or sufficient influence (FATF June 2023 Targeted Update, para 40). If you are unsure where you fall, the safe planning assumption is that a controlled surface pulls you in.

"Decentralised in name only": what FATF actually says

FATF's June 2023 Targeted Update is direct that decentralization is often nominal. The standard-setter states that in many cases DeFi arrangements are decentralized in name only and that persons or centralized elements within them may be subject to the FATF requirements as VASPs (FATF June 2023 Targeted Update, para 39).

The practical difficulty FATF concedes is *identification*: it can be hard for jurisdictions to identify whether entities in a DeFi arrangement fall within their VASP perimeter and to ensure they comply, including with suspicious-transaction reporting (para 39). FATF also acknowledges that identifying who exercises control or sufficient influence continues to be challenging, which complicates supervision and enforcement (para 41). For builders, that uncertainty is a risk, not a shield: regulators look through decentralization theatre, so the burden of demonstrating genuine decentralization falls on the project.

Control self-check: six red flags that pull you into scope

Run this self-check honestly. Any single red flag likely makes someone an obligated VASP or CASP and triggers the full programme (FATF June 2023 Targeted Update, para 40):

1. Admin, upgrade or pause keys held by the team.
2. A flippable fee switch that the team or DAO can turn on.
3. A foundation or core team that runs governance or treasury.
4. Any custodial function that holds user assets, even briefly.
5. A hosted front-end that takes fees, routes orders or screens users.
6. An integrated fiat on/off ramp built into the product.

If the honest answer is "yes" to any of these, plan to become a licensed VASP or to operate under a partnered, licensed entity, and stand up the AML programme below.

The Operational AML Programme for an In-Scope DeFi Actor

Once an obligated person exists, the programme is the recognised AML/CFT spine, applied to the points where the protocol touches users and fiat. These are the standard FATF and CASP pillars, and they answer the "defi aml requirements" question directly. The components are summarised below, then unpacked.

To build the programme itself end to end, follow the steps in our guide to build an AML programme.

CDD / KYC and beneficial ownership

Customer due diligence is the foundation. The obligated entity verifies the identity of users it onboards and, where relevant, identifies beneficial owners. In a DeFi context, the realistic onboarding point is not the smart contract but the front-end and the ramps, so KYC discipline concentrates there. The deeper a project's interface integrates fiat or holds positions, the closer its CDD obligations resemble those of a traditional exchange.

Transaction monitoring and suspicious-transaction reporting (STR/SAR)

Monitoring runs continuously against on-chain risk indicators: mixer use, exposure to sanctioned addresses, and structuring patterns that fragment value to avoid thresholds. When activity is suspicious, the obligated entity files a suspicious-transaction report with the relevant financial intelligence unit. FATF explicitly flags STR reporting as part of the DeFi VASP obligation (FATF June 2023 Targeted Update, para 39). For a catalogue of the patterns monitoring should catch, see our guide to mixer and sanctioned-address red flags.

Recordkeeping, risk assessment, MLRO and independent audit

The programme rests on a governance spine: a documented enterprise risk assessment, retained records, a designated money-laundering reporting officer (MLRO), and periodic independent audit. These are unglamorous but decisive. In examinations and enforcement, the difference between a defensible programme and an exposed one is usually evidence: whether the controls were documented, applied consistently, and tested.

Where DeFi KYC Actually Bites: The Fiat On/Off-Ramp Chokepoint

The most reliable place AML gets enforced in a DeFi stack is where crypto meets fiat: centralized exchanges, payment processors and the on/off ramps a user passes through to enter or exit the protocol. Those ramps are unambiguous VASPs and CASPs that already run full KYC. This is the cleanest answer to "defi kyc requirements": obligations land at the chokepoints.

A pure on-chain swap between two self-custodied wallets has no natural KYC point, which is precisely why regulators push obligations onto the ramps and onto any front-end or interface operator. The operational takeaway for builders is uncomfortable but clear: even a non-custodial protocol typically inherits KYC discipline at its ramps, and a front-end that integrates fiat or takes fees becomes the de-facto compliance surface.

Front-end / UI compliance: geofencing, screening, disclosures

The hosted interface is the most centralized, easiest-to-reach layer, so operational compliance concentrates there. A serious front-end runs:

• Geo-blocking and geofencing of restricted and sanctioned jurisdictions at the UI.
• Wallet-address sanctions screening before allowing interaction, blocking SDN-listed and high-risk addresses.
• Disclosures and terms, and, where the operator takes fees or routes orders, potential full VASP or CASP onboarding.

A front-end that takes fees, screens users or routes orders looks like a regulated intermediary regardless of how immutable the underlying contracts are. That is the lesson of both the (since-repealed) US "DeFi broker" rule and the OFAC Tornado Cash episode, which we turn to next.

Sanctions Screening and the Tornado Cash Lessons

No episode shapes DeFi sanctions compliance more than Tornado Cash. It is the defining case study of how screening must work, why it must be continuous, and why delisting does not mean a counterparty is clean. The numbers and dates below come from the OFAC action and the subsequent litigation, with a verification note for the figures (see Open questions).

The Tornado Cash timeline: sanctioned, reversed, delisted

The arc runs across three dated milestones:

• 8 Aug 2022: OFAC sanctions Tornado Cash and adds it to the SDN list, citing more than 7 billion US dollars laundered through the mixer since 2019, roughly 455 million of it tied to North Korea's Lazarus Group, and treats the smart-contract addresses themselves as sanctioned property (OFAC, Treasury press release JY2206).
• 26 Nov 2024: In *Van Loon v. Department of the Treasury*, the Fifth Circuit holds that immutable smart contracts are not "property" under IEEPA because there is no ownership, control or exclusivity over them (Van Loon analysis, Venable).
• 21 Mar 2025: OFAC delists Tornado Cash and its associated addresses from the SDN list, citing the novel legal and policy issues raised, and Treasury chooses not to appeal (K2 Integrity, delisting analysis).

The terminal lesson is that delisting is not the same as clean. Analytics providers now reclassify Tornado Cash as a high-risk mixer rather than a sanctioned entity, which still triggers risk alerts.

"Delisting is not clean": five operational sanctions lessons

The episode yields five rules every in-scope DeFi actor should encode (Van Loon analysis, Venable; K2 Integrity; Merkle Science):

1. Screening is non-negotiable and continuous, even when a designation is later overturned. Delisting does not retroactively clean past exposure during the sanctioned period.
2. Delisting does not equal clean. Analytics now treat Tornado Cash as a high-risk mixer, not a sanctioned address, and mixer use remains one risk indicator among many. Firms must set their own risk tolerances.
3. The front-end and the people are the targets, not the code. *Van Loon* shielded immutable code, but operators, developers and abusers remain exposed.
4. Build OFAC screening into the front-end and the ramps, and keep risk-scoring current as listings change.
5. IEEPA may be amended. The court hinted that Congress could update the statute to reach mixing software, so the "immutable code is unreachable" reading may narrow.

To operationalise this, screen wallet addresses against the OFAC SDN and high-risk lists, geo-block sanctioned jurisdictions, and monitor for sanctioned-address and mixer exposure as a live system, not a one-time check.

Are DeFi developers personally liable?

They can be. *Van Loon* shielded the immutable code from sanctions designation, but the people who control, operate or abuse a protocol remain exposed, and the criminal cases ran independently of the sanctions delisting. Roman Storm's criminal trial (money laundering, sanctions and unlicensed money-transmitting charges) was scheduled for 14 July 2025, and the prosecutions continued after Tornado Cash was removed from the SDN list (Roman Storm case, Venable). The outcome of that trial is not confirmed here (see Open questions). The point for builders is structural: shielding code does not shield the controllers.

The Travel Rule in DeFi: Why You May Have to Build Ahead of the Rules

The Travel Rule (FATF Recommendation 16) requires VASPs to share originator and beneficiary information on transfers. It applies to a DeFi flow whenever an obligated VASP sits in that flow, for example a ramp or a partnered exchange. So a compliant project that interacts with other VASPs needs Travel-Rule capability.

The catch is that global uptake is poor. As of the April 2023 survey, 54 percent of jurisdictions had taken no steps towards Travel Rule implementation, and only 35 jurisdictions had passed implementing legislation, 58 once the EU's Transfer of Funds Regulation is counted (FATF June 2023 Targeted Update, paras 15–16). The practical consequence is that a serious project often has to build Travel-Rule capability ahead of, or in spite of, its local rules being immature. For the mechanics of compliant transfers, see the crypto Travel Rule.

Governance Tokens and DAO Compliance Risk

Governance tokens can create compliance obligations, depending on what the holders actually do. Passive voting on broad questions is lower-risk. An active DAO that controls a live fee switch, sets protocol parameters, or directs treasury can amount to control or sufficient influence under the FATF test, pulling the governing collective toward VASP or intermediary status.

The practical distinction is between *influence* and *control*. A token that lets holders signal preferences is one thing; a token that lets a quorum flip fees, upgrade contracts, or move treasury is functionally the steering wheel of a regulated business. DAOs that hold that kind of power should assume the control test is engaged and plan accordingly. Projects exposed to smart-contract failure as part of this operational risk picture sometimes pair governance controls with smart-contract cover.

DeFi Compliance Checklist: 10 Operational Steps

This is the how-to spine. Work through it in order; each step assumes the one before it.

1. Run the control self-check (the six red flags above) to decide whether an obligated person exists.
2. Separate the immutable protocol from the operated interface, so the compliance surface is identifiable and contained.
3. Stand up the AML programme on the obligated entity: CDD/KYC, monitoring, STR filing, recordkeeping, MLRO and audit.
4. Run OFAC and sanctions screening as a live system, not a one-time check, updating scores as listings change.
5. Anchor KYC at the fiat ramps, the most reliable enforcement chokepoint.
6. Build Travel-Rule capability even where local rules lag.
7. Manage governance-token risk: passive voting is lower-risk, an active fee-switch or parameter-control DAO is not.
8. Map the programme jurisdiction by jurisdiction, because in-scope tests and Travel-Rule status vary widely.
9. Keep evidence and disclosures audit-ready, because documentation is what survives an examination.
10. Treat classification as fact-specific, and take legal advice. This guide is not legal advice.

Not legal advice: classification is fact-specific

Whether a particular DeFi arrangement is in scope is a fact-specific legal question that depends on the exact control structure, the jurisdictions involved, and how the protocol is operated in practice. This guide explains the operational steps; it does not classify your project. For the in-scope analysis, read the DeFi legal framework and take qualified counsel before you rely on any conclusion.

Have questions about your specific situation? Book a free 15-minute discovery call with our licensed advisors, no commitment. Book a Call

How Crypto Valley Partners Helps DeFi Teams Get Compliant

Crypto Valley Partners AG is based in Zug, Switzerland, the heart of Crypto Valley, and works with founders, exchange operators and compliance officers on exactly the questions this page raises: am I in scope, what programme do I need, and how do I build it across jurisdictions.

From our practice: the recurring failure mode we see is not malice but structure. Teams build a genuinely useful protocol, keep a fee switch and a hosted front-end "for convenience", and assume decentralization insulates them. It usually does not. The work that protects a project is unglamorous: drawing a clean line between the immutable protocol and the operated interface, placing the AML programme on the right entity, and wiring sanctions screening into the front-end and ramps before launch rather than after an inquiry. We help teams do that sequencing in the right order, with crypto regulation insights feeding the programme as the rules move.