Decentralised finance is a set of blockchain-based financial services that operate through software and distributed protocols rather than a traditional intermediary. Its compliance profile depends on who controls governance, access, and user-facing functions. Regulators often examine substance over branding when deciding whether a DeFi activity falls inside financial rules.
Expanded Definition
Decentralised finance, or DeFi, refers to financial services delivered through blockchain protocols, smart contracts, and tokenised governance rather than a conventional intermediary. In practice, the “decentralised” label can cover very different control models, from highly distributed community governance to systems where a small group still controls upgrades, admin keys, or front-end access. That boundary matters because security and compliance expectations change when real control is concentrated, even if the underlying protocol is public.
For practitioners, the key distinction is between protocol architecture and operational authority. A DeFi application may look permissionless at the contract layer yet still depend on privileged accounts, multisig signers, sequencer operators, oracle providers, or web interfaces that shape user access and transaction outcomes. NHIMG treats that distinction as central, because the security profile often follows the control plane rather than the branding.
There is no single consensus model for what qualifies as “sufficiently decentralised.” Regulators and auditors commonly assess substance over labels, especially when governance, custody, or user onboarding creates identifiable control points. That means DeFi should be understood as a spectrum of trust distribution, not a binary property.
Examples and Use Cases
DeFi appears in several common patterns, each with a different risk and governance shape. A user may interact with a protocol through a wallet, but the system may still rely on human-controlled keys or external services that can pause, upgrade, or redirect activity.
- Automated lending protocols that calculate collateral, liquidation, and interest rates through smart contracts.
- Decentralised exchanges that route swaps through liquidity pools instead of a central order book.
- Stablecoin systems that combine on-chain logic with governance votes, reserve management, or emergency controls.
- Yield and staking platforms where users delegate assets to protocol logic while depending on external oracles for price and state inputs.
- Front-end applications that present a decentralised protocol to users but remain operated like conventional web services.
A useful implementation tradeoff in DeFi is that more automation can reduce intermediary dependency, but it also increases reliance on code correctness, upgrade discipline, and the integrity of supporting components. The protocol may be distributed, yet the user experience often still depends on a small number of operational chokepoints.
Security Implications
Misunderstanding DeFi as “trustless” can hide where trust actually sits. If governance keys, admin privileges, oracle dependencies, or front-end hosting are not clearly understood, users and operators may overestimate immutability and underestimate the blast radius of a compromise. The result can be asset loss, market disruption, frozen functionality, or the silent redirection of transactions.
Common failure conditions include insecure upgrade paths, weak signer hygiene, flawed smart contract logic, compromised token governance, and dependence on external data feeds. In many incidents, the protocol itself is only one part of the exposure; the surrounding control stack determines whether an attacker can drain funds, manipulate prices, or prevent legitimate withdrawals.
Another practical symptom is governance ambiguity. When no one can clearly explain who can pause a contract, change parameters, or recover from failure, the system is harder to secure and harder to audit. In DeFi, the security question is often not whether a contract exists on-chain, but whether the protocol’s operational trust model is visible and enforceable.
Domain and Governance Relevance
DeFi matters in financial governance because decentralisation changes how control, accountability, and compliance are inferred. The presence of smart contracts does not eliminate ownership, and the presence of a DAO does not automatically remove operator responsibility. For regulators, auditors, and security teams, the important question is which parties can influence access, upgrades, or transaction outcomes in practice.
That makes DeFi especially relevant where non-human identities, token-based permissions, signing authority, or autonomous execution determine whether actions occur. In those environments, governance is not only about policy documents; it is also about who controls keys, who can approve changes, and how machine-enforced rights are created or revoked. NHIMG’s view is that DeFi should be assessed as an access-and-control system first, and a branding category second.
In security terms, the domain is defined by protocol trust distribution, operational authority, and the integrity of adjacent services. Those are the layers that determine whether decentralisation is structural, partial, or mostly nominal.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV — Governance | DeFi needs clear accountability for upgrade, custody, and control decisions. |
| Recommendation — Define ownership for protocol controls and document who can change, pause, or recover the system. | ||
| CIS Controls v8 | 6 — Access Control Management | DeFi exposes key, signer, and admin access paths that must be tightly governed. |
| Recommendation — Restrict privileged access to protocol keys, multisigs, and operational admin functions. | ||
| MITRE ATT&CK | T1090 — Proxy | DeFi front ends and routing layers can obscure the real control path and user destination. |
| Recommendation — Map redirection and relay patterns to T1090 when investigating traffic or transaction rerouting. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Inventory and Ownership | DeFi often depends on non-human keys, signers, or service identities with material authority. |
| NHI-04 — Secrets and Credential Management | Protocol admin keys, API keys, and signing secrets are central to DeFi compromise risk. | |
| Recommendation — Inventory every non-human identity that can sign, upgrade, pause, or move protocol assets. Rotate, protect, and revoke signing secrets that govern DeFi operations and upgrades. | ||
Related resources from NHI Mgmt Group
- How should security teams govern device-bound payment credentials in open finance?
- How should organisations calculate AI ROI across security, finance and productivity goals?
- Who is accountable when an AI system in finance makes a policy-relevant decision?
- Why does segregation of duties matter for IAM programmes beyond finance?
