Decentralization Tests Compared: SEC, FCA, MiCA, FATF, IOSCO
Quick answer. Each asks whether someone still controls the protocol. SEC staff seek a central party, the FCA's draft weighs three feature groups, MiCA excludes fully decentralised services, and FATF and IOSCO seek control or sufficient influence.
Video transcript
Five regulators and standard setters now ask one question about DeFi: does someone still control the protocol? They use different words, but they all look at the same contract facts.
The FCA looks at substance, not terminology. FATF looks at functions, not labels. And ESMA warns of decentralisation washing.
SEC staff look for a central party with operational, economic or voting control. The FCA's draft PERG 18 weighs three groups of features, none decisive. MiCA Recital 22 excludes fully decentralised services without defining the term. FATF and IOSCO look for control or sufficient influence.
FATF's July 2026 report offers 12 indicative indicators, onchain and offchain, from upgradeability and oracle control to multisig signatories and front ends.
Side by side, the overlap is clear. Upgrade keys, access gates and governance concentration recur across the texts. Oracle control is named only by FATF, and not named never means irrelevant.
None of the five texts treats a multisig as decisive. The FCA says the absence of unilateral control by one person does not settle it, and FATF lists signatories as an indicator.
One current inventory serves every regime. Record the code, every privileged role and its holder, timelocks and emergency bypasses, governance and money flows, and the people behind each key.
Guardian maps these facts from your deployed contracts, and your counsel owns the legal reading. Read the full comparison, or book a system review at guardian.security.
Between July and November 2026, four regulators and standard setters published their answer to who controls a DeFi protocol. IOSCO's 2023 DeFi recommendations sit underneath, and FATF refers jurisdictions to them.
No two use the same words, but all turn on the same evidence: who can upgrade, pause, gate, reprice or redirect a protocol, and who stands behind each key.
This hub compares them. The detailed posts cover the SEC central party test, the FCA's draft PERG 18 and FATF's 12 indicators.
This article explains the technical and security side of the SEC, FCA, MiCA, FATF and IOSCO texts below. It is not legal advice; confirm how it applies to you with counsel.
Five Texts, One Question
The FCA, IOSCO, FATF and ESMA texts start from the same premise: technology does not remove the person.
The FCA looks at “the substance of the arrangements, rather than the terminology used to describe them”. FATF looks at functions “rather than how they are labelled or marketed”.
Their legal force differs sharply:
| Text | Status | Date |
|---|---|---|
| SEC staff FAQs on crypto assets, Questions 1.4 to 1.6 | Staff views; the page says they have no legal force or effect | Added November 2, 2026 |
| FCA CP26/36, draft amendments to PERG 18 | Draft guidance; comments by November 18, 2026; final guidance planned for 2027 | Published October 21, 2026 |
| MiCA, Regulation (EU) 2023/1114, Recital 22 | In force; the recital does not define “fully decentralised” | Review consultation closed September 30, 2026 |
| FATF Targeted Report on Regulatory Challenges from Decentralised Finance | Report applying the existing FATF Standards and 2021 Guidance | July 21, 2026 |
| IOSCO Policy Recommendations for DeFi, FR/14/2023 | Nine recommendations to securities regulators | December 2023 |
How Each Test Works
SEC: the central party
The FAQs explain the “central party” concept in the Commission's March 17, 2026 interpretive release. They concern how crypto assets are classified.
A central party is “a person, entity, or group of persons or entities” with operational, economic or voting control (FAQ 1.4).
FAQ 1.5 gives examples of unilateral authority, such as limiting access or modifying code.
A central party generally does not oversee participation where discretion is exercised solely through a broad-based governance system whose participants are not themselves a central party.
The FAQs do not name multisigs, timelocks, pause functions or oracles.
UK FCA: three groups of features
Draft PERG 18.1 says the regime “does not create a specific or different perimeter test” for decentralized models. It weighs three groups of features: governance, operational and technical, and economic.
None is “necessarily determinative”, and “the fact that no single person exercises unilateral or complete control” does not necessarily determine the outcome.
EU: Recital 22 and the MiCA review
Recital 22 says that “where crypto-asset services are provided in a fully decentralised manner without any intermediary, they should not fall within the scope of this Regulation”. MiCA does not define the term.
The Commission's review consultation (Question 61) asked which criteria should show a DeFi application is not fully decentralised. These are questions, not proposals.
ESMA's response warns of “decentralisation washing”, where an identifiable operator relies on DeFi-type language to avoid MiCA obligations.
It asks the Commission to define DeFi in the legal text, with the exemption “as narrow as possible”, or to let ESMA issue technical guidelines.
FATF: control or sufficient influence
FATF's standards reach DeFi through Recommendation 15 where a person exercises “control or sufficient influence”.
The July 2026 report offers 12 indicative indicators, onchain and offchain, from upgradeability and oracle control to multisig signatories and front ends.
Transparently disclosed emergency functions kept for safety “may or may not, in themselves, indicate control”, while undisclosed or unilateral access rights “often indicate control”.
IOSCO: the Responsible Persons
IOSCO's Recommendation 2 says a regulator should aim to identify the Responsible Persons of a purported DeFi arrangement, including those “exercising control or sufficient influence”.
Nine Powers, Five Texts
Each cell gives the closest wording in that text. “Not named” means the text does not mention the power specifically, not that it is irrelevant.
The EU cells are candidate criteria in a consultation question or ESMA proposals, not MiCA rules.
| Power | SEC FAQs 1.4 to 1.6 | FCA draft PERG 18 | EU (MiCA review, ESMA) | FATF 2026 | IOSCO Rec. 2 |
|---|---|---|---|---|---|
| Upgrade keys and proxy admins | Unilateral authority to modify the rules-based code (1.5) | Who deploys, operates, maintains or updates the arrangements (18.1.18) | Q61 candidate: admin key control, such as upgradeability | Indicator i: upgradeability and back-door privileges | Administrative rights to smart contracts |
| Pause and emergency functions | Not named | Not named (group 2 covers discretion over operations) | Not named | Para 34: ability to pause | Not named |
| Allowlists, blocklists, access gates | Unilateral authority to grant, limit or revoke access (1.5) | Front ends: whether the provider determines what users can access (18.8.31) | Not named | Indicator vi: administration of permissioned access | Ability to set permissions or access rights |
| Parameter setters | A foundation setting operational parameters (1.4, footnote 4) | Who selected or can change material parameters (18.1.18) | Not named | Indicator ii: parameter setting | Setting or adjusting parameters |
| Oracle configuration | Not named | Not named | Not named | Indicator iii: oracle control | Not named |
| Governance concentration | Changing voting processes (1.5); broad-based means no concentration, including through delegation (1.4, footnote 2) | Not named (group 1 covers formal or legal control) | Q61 candidate: significant concentration of governance power | Indicator vii: governance concentration and voting power | Significant voting rights |
| Multisig signers and key holders | Not named; a central party can be a group (1.4) | Not named; lacking a single controller does not settle it (18.1.17) | Not named | Indicator viii: signatories and upgrade key holders | Not named; lists control of user funds through an administrative key |
| Fees, treasury and user funds | Economic control (1.4, 1.6); distributing rewards to users (1.4) | Financial benefit, control over expenditure (group 3) | Q61 candidate: custody of user assets by the protocol | Indicator v: fee flows and profits | Controlling user funds; profiting through fees |
| Front ends | Not named | Draft technical services exclusion, article 9Z2A (18.8.25 to 18.8.35) | ESMA's proposed regulated service for CASPs giving access to DeFi | Indicator ix: front-end operation | Providing a user interface |
One Inventory for All Five
One current inventory serves every regime. For each deployed contract, on every chain, record:
- Code: proxy and implementation addresses, and whether the running bytecode matches the audited commit.
- Privileged roles: each role, its holder, and whether that holder is an EOA, multisig, timelock or governance executor.
- Timelocks and bypasses: which actions wait, which emergency roles skip the wait, and whether that is disclosed.
- Access, parameters and oracles: allowlists, freeze functions, economic parameters, price feeds, and who administers each.
- Governance and money: token concentration, delegation, proposal rights, fee recipients and treasury signers.
- People: who signs for each multisig, who runs front ends and keepers, and which entities employ contributors.
- Change history: when each fact last changed and who approved it.
Counsel decides what the facts mean under each regime. The inventory makes sure everyone works from the same facts.
What Guardian Does
Guardian's system review is an hour with a Guardian engineer on your live contracts, the services that can reach them, and who holds the keys that can change either.
Guardian's regulatory and compliance work includes a privileged role and upgrade path map, read from the deployed contracts. Risk monitoring flags role, timelock, threshold and oracle changes against what was reviewed.
Guardian maps the facts; your counsel owns the legal reading.
Frequently Asked Questions
What is a decentralization test?
The analysis a regulator or standard setter uses to decide whether a person or group still controls a crypto protocol. It affects whether rules apply to that person or, for SEC staff, how the native asset is classified.
Does a multisig make a protocol decentralized?
None of the five texts treats a multisig as decisive. The FCA draft says the absence of unilateral control by one person does not necessarily determine the outcome, and FATF lists signatories and upgrade key holders among its indicators.
Which of these texts can I still comment on?
Only the FCA's: CP26/36 takes comments on draft PERG 18 until November 18, 2026, through the FCA's online response form or by email to cp26-36@fca.org.uk. The Commission's MiCA review consultation closed on September 30, 2026.
Sources
- SEC Division of Corporation Finance: Frequently Asked Questions on crypto assets, Questions 1.4 to 1.6 (added November 2, 2026)
- FCA: CP26/36 Cryptoasset perimeter guidance (October 21, 2026)
- FCA: CP26/36 consultation paper and draft PERG 18 text (PDF, October 2026)
- EUR-Lex: Regulation (EU) 2023/1114 on markets in crypto-assets (MiCA)
- European Commission: Targeted consultation on the review of MiCA (May 20 to September 30, 2026)
- European Commission: MiCA review targeted consultation document, Questions 59 to 65 (PDF, May 20, 2026)
- ESMA: Response to the EC consultation on the review of MiCA, ESMA75-113276571-1721 (PDF, September 30, 2026)
- FATF: Targeted Report on Regulatory Challenges from Decentralised Finance (July 2026)
- IOSCO: Final Report with Policy Recommendations for Decentralized Finance, FR/14/2023 (PDF, December 2023)
Map who controls your protocol
Guardian maps every privileged role, holder, threshold and timelock in your deployed contracts, so counsel can test the same facts against each regime.