A common mistake is treating DeFi as exempt simply because it uses smart contracts or lacks a conventional intermediary. In practice, regulators may look at control points, governance structures, and service responsibilities. If those elements exist, compliance duties can still apply. Teams should assess substance over labels and avoid assuming technical decentralisation removes legal accountability.
Why DeFi Labels Do Not Remove Regulatory Duties
The main error is assuming that “decentralised” is a legal shield. Regulators do not stop at the front-end language or the presence of smart contracts; they look at who can change parameters, who benefits from the service, who sets policy, and who can intervene when something goes wrong. That means a protocol can still present identifiable governance, custody, promotion, or operational control points that attract obligations even when no single firm looks like a traditional intermediary.
For organisations, the practical issue is that regulatory exposure often follows substance, not branding. A protocol with admin keys, upgrade rights, fee-setting authority, or a managed interface may create a clearer accountability path than teams expect. This is why the right question is rarely “Is it DeFi?” and more often “What activities, control rights, and customer-facing functions exist?” See the broader control perspective in NIST Cybersecurity Framework 2.0, which is useful where governance and operational accountability need to be assessed together.
In practice, many organisations discover regulatory obligations only after a product has already launched with governance features that looked temporary at design time but became durable control points.
How Legal and Operational Reality Diverge in DeFi
DeFi teams often describe the protocol layer as autonomous and the interface layer as neutral, but that separation is not always persuasive in supervision or enforcement. If a team controls the codebase, approves upgrades, curates token lists, runs a hosted front end, or maintains incident response authority, regulators may view those functions as part of the regulated activity. The more a project looks like an organised service with decision-makers, the less credible it becomes to argue that legal responsibility disappeared because execution is on-chain.
In practice, substance-based assessment usually turns on a few recurring questions:
- Who can change the protocol or pause activity?
- Who defines access, onboarding, or user restrictions?
- Who markets the product and benefits economically from its use?
- Who can see, process, or act on customer data or transaction flows?
- Who owns the interface that most users rely on?
Those questions matter because compliance duties can attach to governance, distribution, custody-adjacent functions, or financial crime exposure even when settlement itself is automated. For that reason, obligations tied to AML and KYC should also be reviewed where the service facilitates regulated financial activity; the FATF Recommendations remain a useful reference point for the kind of functional analysis supervisors expect.
Organisations also get the temporal dimension wrong: a protocol that begins as a loosely governed experiment can evolve into a quasi-managed service through token concentration, delegated control, or operational dependence on a small team. The legal posture can therefore change without any change to the branding. Where the service boundary is ambiguous, teams should assume the accountability test is still live and document why they believe particular functions are or are not in scope. This guidance breaks down when a project has no meaningful governance, no operator role, and no user-facing service layer at all.
Where DeFi Compliance Assumptions Break Down
Tighter regulatory analysis often increases internal workload, requiring organisations to balance decentralisation claims against the cost of proving them. The hardest cases are not fully centralised platforms or fully permissionless code; they are hybrids that mix autonomous settlement with managed governance, hosted access, or discretionary intervention.
Common edge cases include protocol treasuries, multisig control, admin key recovery, and DAO-style governance where voting exists but effective control remains concentrated. A project may also be outside one regulatory category while still falling into another because it performs exchange, brokerage, custody, lending, or transfer functions in substance. That is why teams should avoid treating technical architecture as the final answer. Architecture can support the analysis, but it does not replace it.
There is also a governance-versus-consensus distinction that matters. In the industry, people often debate whether “true DeFi” should count as regulated finance; in practice, that debate does not decide supervisory treatment. The more useful question is whether the service creates identifiable control, customer reliance, or financial risk transmission. If it does, legal teams need to map those functions carefully rather than relying on decentralisation as a binary defence.
For NHI-sensitive organisations, the intersection appears when protocol administration, signing authority, or operational access sits with service accounts, automation, or privileged keys. That does not make the issue primarily an identity problem, but it does mean access governance can become part of the regulatory fact pattern. The moment a team cannot explain who can alter the system, the exemption argument weakens materially.
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, NIST SP 800-63 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC — Organizational Context | DeFi scope depends on service context and control points, not labels. |
| GV.RM — Risk Management Strategy | Assuming exemption creates unmanaged legal and compliance exposure. | |
| ID.BE — Business Environment | Regulatory treatment follows the activity the organisation actually performs. | |
| Recommendation — Map protocol functions and control points to determine where accountability begins. Treat decentralisation claims as a risk assumption that needs explicit validation. Classify the service by actual business activity before assigning compliance duties. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Onboarding and customer identity checks can remain relevant in DeFi services. |
| Recommendation — Assess whether user verification requirements apply to the service model in scope. | ||
| CIS Controls v8 | 6 — Access Control Management | Admin keys and governance rights are control points regulators may treat as accountability evidence. |
| 15 — Service Provider Management | Hosted fronts, operators, and delegated services can create third-party obligation exposure. | |
| Recommendation — Inventory and restrict privileged control paths that can change protocol behaviour. Review outsourced or hosted components for compliance duties tied to the service. | ||
Practitioner Guidance
What to prioritise: Start with a function-based inventory of the protocol, interface, and governance stack, not with a label review. The critical question is which activities could be interpreted as financial services, custody-adjacent control, or market-facing intermediation.
What to verify: Verify who holds upgrade rights, admin permissions, treasury control, and user-access control. If those rights are distributed but still traceable to a small group or operating entity, treat that as a regulatory accountability signal rather than a decentralisation conclusion.
Common mistake: Teams often overstate the legal effect of open-source code and understate the significance of hosted interfaces, curated governance, and operational discretion. A system can be technically decentralised and still be organisationally managed.
Decision rule: If the project can be changed, promoted, supported, restricted, or rescued by identifiable actors, assume regulators will ask what duties follow from that control. If nobody can explain the control path clearly, the compliance posture is probably not defensible yet.
Practitioner takeaway: DeFi regulation questions are usually won or lost on control and function, not on whether the system calls itself decentralised.
Related resources from NHI Mgmt Group
- What do organisations get wrong when they assume passwordless login automatically means stronger security?
- What do organisations get wrong when they assume blockchain automatically removes the need for intermediaries?
- What do organisations get wrong when they assume low-code and AI automatically make development safer?
- What do organisations get wrong when they assume a foreign individual certificate automatically makes a transaction legally safe?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
