Why does FATF’s treatment of DeFi protocols create AML and CFT risk for owners and operators?

Because FATF looks past decentralization claims and focuses on the people who control the service. If an owner or operator profits from the protocol, sets rules, changes operations, or can shut it down, regulators may treat that party as responsible for AML and CFT obligations. The practical risk is that compliance duties attach even when users interact with smart contracts rather than a traditional intermediary.

How FATF Moves the Compliance Question From the Protocol to the People Behind It

FATF’s approach matters because it does not stop at the code path or at claims of decentralization. The key issue is whether someone still exercises meaningful control, economic benefit, or operational authority over the protocol. Once that is true, the compliance question shifts from “is this software automated?” to “who can influence outcomes, change rules, or stop the service?”

That distinction is why a DeFi protocol can still trigger AML and CFT obligations for owners and operators even when users interact only with smart contracts. A protocol may be technically distributed, but if governance, upgrade rights, fee capture, or emergency controls are concentrated, regulators can still treat the human or corporate actors as responsible parties. For the underlying standard, see FATF Recommendations, the AML and KYC framework.

What matters in practice is the functional role, not the branding. If an operator can set parameters, curate access, modify liquidity routing, or decide whether the protocol continues to operate, those powers can look like the kind of control FATF expects firms and jurisdictions to assess for financial crime risk.

Which DeFi Features Usually Drive AML and CFT Exposure

The risk does not come from “DeFi” as a label, it comes from specific control points that create accountable conduct. Common examples include admin keys, upgradeable contracts, governance token concentration, protocol revenue sharing, and the ability to pause or blacklist activity. Those features can make an otherwise automated system look like a managed financial service from a supervisory perspective.

That is also why owners and operators should not assume that removing a traditional front office removes compliance exposure. If the protocol supports value transfer, asset swaps, lending, or onboarding of users with real-world touchpoints, AML and CFT expectations can attach through the parties who design, maintain, or economically benefit from that flow. For European supervisory context, the EBA AML and CFT guidance shows how supervisory expectations extend across financial activity that carries crime-financing risk.

In operational terms, the control question is whether the protocol can be altered in a way that changes customer risk, transaction screening assumptions, or the ability to intervene. If the answer is yes, the protocol is no longer easy to defend as “just code” for compliance purposes.

What Owners and Operators Should Expect When the Liability Lens Turns On

Once a regulator or counterparties views the project as having accountable operators, the practical burden expands quickly. Teams may need customer due diligence logic, sanctions screening decisions, suspicious activity escalation, recordkeeping, ownership analysis, and documented governance over protocol changes. The exact obligations vary by jurisdiction, but the compliance design problem is the same: identify where control lives and prove how risk is managed.

For practitioners, the most important step is to map every point where humans can intervene, profit, or reverse the system. That includes treasury control, deployment authority, bridge administration, governance quorum design, and any off-chain interface that routes users into the protocol. The presence of smart contracts does not eliminate these obligations, it only changes where the control surface sits. If US reporting obligations become part of the analysis, FinCEN is the primary enforcement and guidance reference.

For teams that want a more technical control lens, the operational analog is to treat privileged protocol control the way you would treat any high-impact access path: reduce standing authority, document exception handling, and keep change control auditable. Where you need an implementation benchmark for that control mindset, the Ultimate Guide to NHIs is useful for the lifecycle and governance mechanics behind high-risk machine-access patterns, and Codefinger AWS S3 ransomware attack shows how exposed control material can be turned into direct operational harm.

Risk and Threat Considerations

DeFi creates AML and CFT risk when control is distributed in theory but concentrated in practice. If attackers, insiders, or sanctioned actors can exploit governance rights, admin functions, or weak off-chain controls, the protocol can become a channel for laundering, fraud, or rapid asset movement before detection catches up.

Failure mechanism: Regulatory exposure increases when the project’s human controllers can influence money movement, governance, or service continuity, because that makes the protocol look like a managed financial intermediary rather than neutral software.

Impact: Owners and operators may face remediation demands, licensing or registration pressure, transaction monitoring expectations, or enforcement actions tied to how the protocol actually operates.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OV-01 — Organizational Context	DeFi operator control shapes financial crime governance and accountability.
Recommendation — Define protocol control points and assign AML/CFT accountability to the parties with real operational authority.
CIS Controls v8	5.1 — Establish and Maintain an Inventory of Accounts	Operator-facing compliance depends on knowing who can act on the protocol and where privilege sits.
Recommendation — Inventory privileged protocol accounts, admin keys, and governance actors with change authority.
NIST SP 800-63	1.1.2 — Identity Proofing	AML/CFT obligations often depend on customer due diligence and verified identity processes.
Recommendation — Use identity proofing where user onboarding or transaction access requires regulated customer due diligence.
MITRE ATT&CK	T1090 — Proxy	DeFi abuse often relies on layered routing and intermediaries to obscure transaction origins.
Recommendation — Detect proxy-like routing and layered transfer paths that can conceal source, destination, or control.

Practitioner Guidance

What to verify: Test whether the protocol has any party that can change fees, pause execution, upgrade contracts, control treasury assets, or decide user access. If any one of those powers exists, treat the compliance posture as operator-facing until proven otherwise.

Decision rule: If the project can economically benefit from the protocol or alter its behaviour after deployment, document who owns those powers, what oversight exists, and which AML and CFT controls are actually feasible at that control point. Do not wait for a legal opinion before mapping the operational facts.

Practitioner takeaway: FATF risk is driven less by whether a service is coded as decentralized and more by whether a real person or entity still controls meaningful financial outcomes.