The UK Financial Conduct Authority opened a consultation on DeFi guidance on October 21, 2026, with responses due November 18. The immediate issue is accountability: when a financial firm uses a decentralised protocol, which responsibilities remain with the firm?
The GC26/7 consultation addresses operational resilience and financial crime under applicable existing requirements. It is proposed guidance, rather than a new DeFi licence or an approval of individual protocols. That distinction matters to businesses choosing infrastructure and customers deciding whom they can rely on.
Two consultations answer different questions
GC26/7 concerns how firms manage risks. The accompanying CP26/36 concerns the regulatory perimeter, including exclusions for certain technical services. Neither label should be used as a shortcut for the other assessment.
Put simply, a business first needs to establish what activity it actually performs, whether that activity is carried on by way of business in the UK, and whether an exclusion or exemption is relevant. If obligations apply, the next question is how the business meets them while relying on DeFi. Operating a website, writing software, selecting strategies and executing customer transactions are different functions; the legal answer depends on the arrangement.
CP26/36’s draft perimeter guidance emphasises substance and assessment of relevant participants separately. Decentralised governance or overseas infrastructure does not settle the question. Equally, it would be wrong to infer that every developer or governance-token holder automatically requires authorisation.
Follow the service the customer actually receives
Consider a hypothetical app that selects a lending pool, routes a customer’s deposit and displays a withdraw button. The pool’s contracts may be publicly accessible. Yet the app still makes decisions about the product it presents. A customer who cannot withdraw needs more than an explanation that the blockchain remains online.
The useful investigation follows the service from screen to settlement. Who selected the pool? Who controls the interface? Which data source values the collateral? Can anyone change contract parameters? Which party receives alerts when withdrawals fail? These are practical questions for assessing an arrangement, not a universal legal test or a predetermined allocation of liability.
| Observed function | Question to investigate | What the label alone cannot establish |
|---|---|---|
| Frontend or wallet access | Is it only technical access, or part of another service? | That every interface is excluded |
| Protocol or strategy selection | Who chooses exposures and can change them? | That a DAO vote removes business decisions |
| Upgrade or emergency controls | Who holds powers, under what constraints? | That having a key determines every legal obligation |
| Customer-facing financial service | Which permissions and ongoing duties apply? | That using open contracts transfers those duties away |
This approach also keeps different risks separate. A party might control a frontend without custody of the assets. A strategy manager might choose protocols without controlling their code. Customers need to understand both the choices a provider makes and the limits of its intervention powers.
An audit is evidence about code, not a recovery plan
The FCA’s established operational resilience observations call for mapping dependencies and testing disruption. Under SYSC 15A, in-scope firms set impact tolerances for important business services, considering potential customer harm. The concern extends beyond whether a server is running.
For example, imagine a wallet depends on one RPC provider to submit transactions. If that connection fails, the chain can remain healthy while the wallet’s customers lose access. A second RPC provider may help that failure, but it cannot repair a bridge exploit or remove a protocol’s withdrawal queue. Testing needs to match the actual failure.
A realistic exercise would ask whether customers can see accurate balances, whether transactions can be submitted through an alternative route, and what the firm can say when recovery timing is unknown. Reporting “no assets stolen” would offer little reassurance to a borrower approaching liquidation because a deposit cannot move.
Code reviews have a narrower purpose. They can identify vulnerabilities within their scope; they cannot promise uninterrupted access or a buyer for a receipt token. The KTX explanation of liquid staking shows why protocol redemption and selling a transferable receipt are different exits.
Public transaction records still need interpretation
Financial crime controls require more than visibility of addresses. The FCA’s Financial Crime Guide discusses understanding blockchain analytics, investigating alerts and maintaining appropriate sanctions controls. A risk score is an input to a decision; it is not a complete account of the person or transaction.
Take a hypothetical deposit that arrives after several swaps and a bridge transfer. An analyst needs to understand the alert, its evidence and its limits. Automatic execution makes the timing important: reviewing an alert after the firm has completed an irreversible transfer is different from reviewing it beforehand. This example does not imply that every bridged transfer is suspicious.
The broader policy direction is also visible in FATF’s July 2026 DeFi report, which favours functional, risk-based analysis, including identifying control. FATF recommendations and UK legal obligations should not be presented as interchangeable rules.
The commercial effect depends on how services are delivered
Our assessment is that clearer boundaries could favour providers able to explain their dependency chain and incident decisions. That could mean better records, fewer unsupported integrations or more selective product access. It could also increase operating costs. The consultation itself does not establish which firms will change their offerings.
For users, the useful comparison is more concrete than “centralised versus decentralised.” Ask who offers the service, what the service promises, where assets can become inaccessible and which recovery options actually exist. The KTX guide to automated yield farming provides another example of automation sitting above underlying protocol exposures. Neither an educational article nor a provider’s branding establishes FCA authorisation.
Watch the timetable and the final wording
The consultation webpage targets January 2027 for final GC26/7 guidance, while its PDF says Q1 2027. CP26/36 targets spring 2027. The wider new cryptoasset regime is scheduled for October 25, 2027. These are different milestones; consultation closure is not commencement of the regime.
The next useful evidence will be the final treatment of technical access, the explanation of responsibility across distributed participants and any changes following feedback. Until then, proposed interpretations should remain clearly labelled as proposals.
FAQ
Does a smart-contract audit prove regulatory compliance?
No. An audit addresses a defined technical scope. It does not establish that the business has the permissions or controls required for its activities.
Does non-custodial automatically mean unregulated?
No. Custody is one feature of an arrangement. Other services and applicable exclusions still need assessment.
Must every DeFi participant perform identical identity checks?
The consultation does not justify that conclusion. Duties depend on the participant’s activities and applicable requirements, rather than a single ecosystem-wide label.
Does the consultation guarantee compensation after a loss?
No. A consultation is not a compensation promise. Any rights or protection depend on the relevant service, legal arrangements and eligibility conditions.
Is November 18 a deadline for users to move their assets?
No. It is the consultation response deadline, not a general withdrawal instruction.
For information only, not legal or investment advice. Proposed guidance may change. DeFi can involve contract losses, interrupted access and limited recovery.