Jurisdictions should assess each DeFi arrangement on evidence, not labels. The key is whether identifiable persons exercise control or sufficient influence over the protocol, especially through governance, admin keys, fee flows, or front-end control. A proportionate approach distinguishes centralized, unidentified controller, and truly decentralized structures so oversight targets real authority rather than technical appearance.
Why This Matters for Security Teams
AML and CFT policy for DeFi fails when supervisors assume the protocol itself is the subject of enforcement, instead of asking who can actually change code, move funds, set fees, or control access to the user interface. That distinction matters because the practical risk sits in identifiable operators, governance participants, and service layers that can be used to enable or obstruct financial crime controls. FATF’s AML and KYC framework supports a risk-based approach, but jurisdictions still need evidence-based tests that reflect how modern DeFi is built and operated.
The operational mistake is treating decentralization as a binary label. Many arrangements are partially decentralized in code but still depend on a small group for upgrades, admin functions, treasury management, or oracle configuration. In those cases, AML and CFT obligations may attach to the human or legal persons behind those functions even if the smart contract itself is non-custodial. Current guidance suggests focusing on control, influence, and economic benefit rather than marketing claims about autonomy.
In practice, many compliance teams encounter the control question only after a protocol has already been used for laundering, rather than through intentional governance design.
How It Works in Practice
A workable jurisdictional model starts by mapping the DeFi stack into functional layers: protocol code, governance, admin controls, front-end access, custody or settlement touchpoints, and fee or revenue capture. Each layer should be tested for identifiable control. If a foundation, company, DAO core team, multisig signer set, or outsourced operator can pause, upgrade, whitelist, blacklist, or redirect value, that is relevant for AML and CFT analysis. The question is not whether the system uses smart contracts; it is whether natural or legal persons can meaningfully influence how the system behaves.
Authorities can then apply proportional obligations based on the level of control and exposure:
- Full AML and CFT duties where there is a clear operator or intermediary with customer-facing or transactional control.
- Targeted obligations for governance participants or administrators with effective influence over protocol behavior.
- Lower-touch supervision where there is no identifiable controlling person and the protocol operates with limited practical intervention points.
This aligns with the broader risk-based thinking found in FATF Recommendations, but implementation still depends on national law and supervisory discretion. The hardest evidentiary inputs are governance records, multisig signers, admin key arrangements, upgrade paths, revenue allocation, and the real-world control of web interfaces or app layers. Jurisdictions also need to distinguish between protocol authorship and ongoing operational control, because open-source contribution alone does not always create a regulated AML/CFT role.
Where DeFi integrates with custodial wallets, fiat on-ramps, or hosted interfaces, the identity and transaction-monitoring obligations become more concrete. That is often where practical enforcement should focus, alongside any persons who can alter sanctions screening, block users, or change transaction routing. For technical implementation guidance on governance and control patterns, protocol governance documentation can illustrate the kinds of functions that regulators may need to examine, although there is no universal standard for this yet. These controls tend to break down when governance is dispersed across anonymous token holders but upgrade power is still concentrated in a small multisig, because formal decentralization can mask effective central control.
Common Variations and Edge Cases
Tighter AML and CFT rules often increase compliance burden and legal uncertainty, requiring jurisdictions to balance financial crime prevention against innovation and open-source development. That tradeoff is especially visible in hybrid DeFi models, where a protocol may be partially autonomous but still depend on a clearly identifiable front-end operator, treasury manager, or foundation.
Best practice is evolving for DAO-heavy systems. Some regulators may treat governance token holders as too diffuse to regulate individually, while others may focus on the people or entities that structure proposals, maintain critical infrastructure, or receive ongoing revenue. There is no universal standard for this yet, so supervisory decisions should document which control signals were present and why they were sufficient to create AML/CFT responsibility.
Edge cases also arise when a protocol is immutable but access is mediated through a hosted application. In that situation, the app operator may become the more realistic compliance anchor even if the smart contract code cannot be changed. For broader digital-asset accountability and operational oversight context, FATF publications provide the policy backdrop, while supervisors may also look to technical control evidence from multisig operating models when assessing whether a protocol is functionally decentralized or still centrally steerable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-63 set the technical controls, while DORA, NIS2 and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | Risk management is needed to separate true decentralization from effective control. |
| NIST SP 800-63 | Identity assurance matters when identifiable operators or controllers must be verified. | |
| DORA | Operational resilience applies where DeFi front ends or governance services create systemic dependence. | |
| NIS2 | Cyber governance expectations help when a DeFi service has identifiable management responsibility. | |
| PCI DSS v4.0 | Payment-adjacent integrations can inherit stronger controls when fiat or card rails are involved. |
Map critical dependencies and require resilience for operator-controlled service layers.
Related resources from NHI Mgmt Group
- How should banking teams implement authorization without embedding rules in every service?
- How should CASPs prepare for MiCA licensing without missing AML/CFT obligations?
- What breaks when digital identity is accepted without clear AML policy rules?
- How can security teams apply GRC maturity benchmarks without creating process bloat?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
