Four variables sit buried in the middle of a consultation paper that most of the industry has not finished reading. Price. Liquidity. Cost. Execution speed. The UK Financial Conduct Authority lists them as the criteria by which an algorithm's venue selection may constitute a regulated activity. Every production smart order router in decentralized finance optimizes for those same four variables. This is not a coincidence. It is jurisdiction by objective function.
The document is CP26-36. On October 24 it entered consultation. It closes on November 18 โ a window so compressed that most affected operators will discover it after it has shut. And somewhere inside the same paper, three dates cannot all be true at once: the paper is numbered for 2026, the application window for existing UK-facing firms opens September 30, 2026 and closes February 28, 2027, and the stated finalization target is January 2027. An application window that begins before the rules it applies to are finalized. I have spent enough hours inside regulatory drafts to know that timestamp inconsistencies are rarely clerical errors. They are compressed schedules. Somebody is moving faster than the published cadence admits.
The timeline is the least interesting anomaly in this document. The substance is that the FCA has quietly redrawn the boundary between software and financial service. It has done so not by naming protocols, but by naming the mathematical operations those protocols perform. If your algorithm decides where a trade goes, you may be arranging deals. If you are arranging deals, you need authorization. And if you need authorization, the entity that needs it must be identifiable, capitalized, and resident enough to be fined.
That is the whole paper in three sentences. Everything else is detail. The detail is where the bodies are buried.
Context: What "Arranging Deals" Actually Means, and Why It Was Never About DeFi
The FCA does not regulate protocols. It regulates persons. This is the first thing anyone approaching British financial regulation from a smart-contract background gets wrong. The Financial Services and Markets Act, and the Regulated Activities Order that hangs beneath it, define a list of activities that may only be carried out by authorized persons. One of those activities is "arranging deals in investments." The statutory language is deliberately broad. It covers making arrangements for another person to buy, sell, subscribe for, or underwrite a particular investment. It covers the arrangement's design and the arrangement's operation. It was written in an era when the arrangement was a desk, a telephone, and a broker with a compliance manual.
The regulation never specified the medium. That is the entire vulnerability that DeFi spent a decade pretending did not exist. The medium is irrelevant. The activity is the thing.
Under MiFID II, the European regime from which much of this thinking descends, smart order routing is already a recognized and regulated function. A firm that routes client orders across venues, optimizing for price and execution quality, is not a neutral pipe. It is a service provider with a fiduciary-adjacent obligation. The four best-execution criteria that MiFID used โ price, cost, speed, and likelihood of execution and settlement โ map almost one-to-one onto the FCA's list in CP26-36. The fifth MiFID criterion, likelihood of settlement, has been dropped in favor of liquidity. That substitution is instructive. Likelihood of settlement is a TradFi concept. Liquidity is a DeFi concept.
The FCA is not inventing a new category of regulated activity. It is transplanting an existing category into a new substrate. This matters enormously for how the industry should read the paper. A regulator that invents a category is guessing. A regulator that transplants a category is asserting continuity. Continuity assertions are harder to fight because they come with a body of precedent attached. The FCA can point to a decade of MiFID enforcement and say: this is the same activity, executed differently, and the difference in execution technology does not change the nature of the service.
Which brings us to the timeline. Consultation papers of this type typically run twelve weeks. CP26-36 runs three and a half. Either the FCA has already made up its mind and is going through the ritual, or something has forced the pace. The more probable reading is that the paper was written alongside the policy, not before it, and the consultation is being run to generate a paper trail rather than to generate a decision. I have seen this pattern before โ in the 2024 stablecoin consultations, in the 2023 marketing rules, in the 2021 cryptoasset promotions regime. When the FCA shortens a consultation window, the conclusion is already drafted. The window exists to test the political cost of the conclusion, not the conclusion itself.
What is the conclusion? That algorithmic venue selection is a regulated activity, that the entities operating those algorithms require authorization, and that the exemption for pure technical services is narrow enough to be functionally irrelevant. Everything else โ the four criteria, the three discretion indicators, the automation carve-out โ is scaffolding around that single load-bearing claim.
The regulation has a name for the scaffold. It calls them factors. Factors are how a regulator maintains flexibility while signalling intent. A bright-line rule can be litigated. A factor can be weighed. And a factor list that happens to enumerate the exact operations of an entire industry is a bright-line rule wearing a factor's clothing.
The Four Criteria as an Objective Function
Here is the analytical move that makes CP26-36 different from previous attempts at DeFi regulation. Previous regimes tried to define the regulated entity by what it holds, by what it issues, or by who its customers are. The FCA defines it by what it computes. That is a fundamentally different regulatory technology, and it is far more effective.
Consider what a modern aggregator does in a single routing decision. It queries multiple liquidity sources. It reads the depth of each pool at the relevant price impact. It calculates the gas cost or fee cost of each path. It estimates settlement latency and slippage exposure. Then it selects. This is not a simplification. This is a literal description of a router's inner loop, and every one of those five operations maps onto one of the four FCA criteria. Price is the quoted output. Liquidity is the pool depth. Cost is the fee and gas estimate. Speed is the latency estimate. The FCA has written a specification of the routing decision and called it a trigger condition.
Now consider the implication. A router that optimizes along axes orthogonal to those four โ say, a router that selects purely on the basis of a randomized or fixed rule โ is not in the FCA's crosshairs. A router that touches any of the four is. The regulator has effectively defined a compliance-safe algorithm: one that does not optimize. A non-optimizing router is, by definition, an inferior product. Users will not use it. So the practical consequence is that the entire competitive advantage of the aggregator category โ the thing that makes it exist โ is the thing that triggers the obligation.
I have audited enough routing logic to know this is not accidental. Optimization is not a feature of an aggregator. Optimization is the aggregator. A swap front-end that does not optimize is a thin wrapper over a single pool. Route splitting, multi-hop construction, gas-adjusted optimality, MEV-aware path selection โ these are the engineering artifacts that justify the category's existence. Remove them and you have Uniswap's own interface with a different logo.
So the FCA has, with a factor list, made a structural determination. It has said: the value-add of this category is the regulated activity. There is no version of this business that survives the classification unmodified except one that abandons its value-add. The escape hatch is technically present and commercially sealed.
The fee structure compounds this. Aggregators monetize through routing fees โ a basis-point skim on executed volume. That revenue is a direct function of the routing decision's quality. If the routing decision is the regulated activity, then the revenue stream is a regulated revenue stream. The FCA does not need to say this explicitly. It follows from the classification the way a signature follows a key.
There is a second-order effect that I have not seen raised in the coverage of this paper. Once routing is a regulated activity, the routing decision acquires an evidence obligation. Under MiFID-style best-execution regimes, firms must demonstrate that a routing decision was in the client's interest. That requires logging, retention, and reconstructability. For a purely on-chain router, the decision is reconstructed from public state โ which is fine. For a hybrid router or a front-end with any off-chain component, the evidence obligation attaches to the off-chain layer. This is where the compliance cost actually lands, and it is where I would expect the first enforcement actions to originate: not against a protocol, but against an operator that could not produce the routing rationale.
The Three Discretion Indicators and the Death of the Neutral Pipe
The FCA's discretion test is stated in three parts. A router may be exercising discretion if it modifies the client's instruction, if it determines execution timing, or if it selects a path based on counterparty risk or expected outcome.
This looks like a narrow test. It is not. It is a description of the standard feature set of every aggregator shipped in the last four years.
Start with instruction modification. A limit order that gets split across venues is a modification. A trade that gets routed with an adjusted size to control price impact is a modification. A transaction that gets wrapped in a slippage-tolerance check and reverted if the tolerance is breached โ that is a modification of the outcome, executed by the router. Slippage protection is not a safety feature from the FCA's perspective. It is the router substituting its judgment for the client's.
Move to execution timing. Time-weighted average price execution. Delay-based MEV protection. Any router that holds an order for a block or two to see if a better price materializes is engaged in timing discretion. The FCA does not accept the claim that the timing decision is algorithmic and therefore exempt โ that claim is dismantled below. What matters is that the timing decision exists and is made by the software on behalf of the client.
Then the third indicator, which is the most dangerous of the three: path selection based on counterparty risk or expected outcome. This is where the DeFi community's instincts and the regulator's instincts diverge most sharply. In DeFi, avoiding a path that touches a compromised pool is responsible engineering. Avoiding a path that touches a sanctioned address is compliance best practice. Avoiding a path that exposes the user to sandwich attacks is user protection. Every one of these behaviors is a routing decision made on the basis of a risk assessment about the counterparty to that path. The FCA's factor list captures all of them.
This is the trap. The safety features the industry built to protect users are the features that establish discretion. MEV protection is counterparty-risk-based routing. Oracle-based pool filtering is counterparty-risk-based routing. Sanctions screening at the address level is counterparty-risk-based routing. The more responsible the aggregator, the more clearly it discloses that it is exercising judgment, and the more clearly it falls inside the regulated perimeter.
There is a perverse equilibrium here that I want to state plainly. An aggregator that routes blindly and reports no risk assessment is closer to the exemption. An aggregator that routes carefully and documents its reasoning is closer to the licensing requirement. The regulation, read literally, penalizes diligence. This is not what the FCA intends, but it is what the factor list produces, and intention is not a defense.
Automation Is Not Immunity
This is the provision that will be quoted in every legal memo written about CP26-36 for the next five years. The FCA states that an algorithm executing according to standards set by the provider does not, by that fact alone, fall outside the regulated activity. The provider set the standards. The provider is therefore exercising the discretion. The algorithm is the mechanism, not the actor.
For anyone who spent the last decade arguing that smart contracts are law, this is the most consequential sentence in the document. It closes the doctrinal door that DeFi relied on for its entire legal theory of itself. The claim was always that an immutable contract cannot be a regulated intermediary because the contract has no intent, no discretion, and no ability to do anything other than what it was programmed to do. The FCA's response in CP26-36 is: correct, and irrelevant. The relevant question is who decided what the program would do. That person, or that entity, is the arranger.
I have nitpicked this argument from the other side for years. The reason it always felt fragile is that it proves too much. If an algorithm cannot exercise discretion because it only follows its code, then no algorithmic trading system anywhere exercises discretion, and the entire MiFID regime for algorithmic trading collapses. The regulators were never going to accept a premise that would deregulate the most heavily automated parts of traditional finance. What they have done instead is apply the same standard to crypto that they apply to everything else: the standard-setter is the decision-maker.
Which means the compliance question for an aggregator is not is the code autonomous but who can change the code, who set the parameters, and who receives the economic benefit. If there is a multisig that can upgrade the router, there is an entity. If there is a DAO that votes on routing parameters, there is โ in the FCA's likely reading โ a decision-making body, whether or not it is a legal person. If there is a foundation that funded the deployment and holds the treasury, there is an identifiable counterparty for enforcement.
The uncomfortable corollary is that the most genuinely decentralized protocols in the category are the hardest to regulate, not because they are safe, but because there is nobody to serve the paper on. This creates the exact inversion I flagged earlier: the regulation will land disproportionately on the operators who did the work of establishing legal structure, and lightly on the ones who did not. That is not a policy failure. It is a policy outcome. Enforcement is always easier downstream of a bank account.
The Technical Services Exemption and the Disappearance of Pure Forwarding
The FCA retains an exemption for services that are purely technical in nature โ a category inherited from the wider regulated-activities framework. The paper's description is that a service which only transmits instructions without affecting the execution outcome may fall outside the licensed perimeter. Transmit only. Do not affect the outcome.
This is where the compliance perimeter becomes genuinely ambiguous, and where I would expect the most litigation. The problem is that "affecting the outcome" is undefined and, in a swapping context, almost impossible to avoid. Consider a front-end that transmits a user's exact parameters to a single pool with no route selection at all. Does it affect the outcome? It chose the pool. If it did not choose the pool, the user did, which means the front-end is a message bus โ and message buses are technically not arrangers. Now add a single feature: the front-end checks the quoted output against a floor before submitting. It has now affected the outcome. It declined to submit a trade the user asked for. That is an intervention in the client's instruction, which is the first discretion indicator.
There is essentially no version of a useful swap interface that clears this bar. Every interface that shows a quote before submission is comparing; every interface that shows a route is selecting; every interface that simulates the transaction is evaluating. The exemption describes a product that does not exist, or one so useless that no user would choose it.
Layer on the practical enforcement dimension. The FCA's predecessor guidance made clear that the technical services exemption is applied narrowly and that the burden of demonstrating the exemption is on the firm claiming it. A firm that claims the exemption and is wrong has been operating an unlicensed regulated activity โ which is a criminal offense, not a regulatory slip. The asymmetry between claiming the exemption and applying for authorization is enormous: the downside of a wrong exemption claim is a criminal exposure, and the downside of authorization is cost. Nobody rational takes that bet in the presence of an ambiguous definition.
I expect the practical outcome to be that the exemption is treated as unavailable by counsel, and every serious operator either seeks authorization or exits the jurisdiction. The exemption's function is to give the FCA a reasoned basis for treating non-optimizing relays differently from optimizing ones, not to give the industry a path to compliance.
The Timestamp Problem and What It Reveals About the Schedule
The document number is CP26-36. The consultation date is October 24. The application window for firms with existing UK business runs September 30, 2026 to February 28, 2027. The finalization target is stated in one place as January 2027 and in another as spring 2027. The rules take effect October 25, 2027.
There are three readings of this. The benign reading is that the document number refers to a forward-looking series, and the FCA routinely numbers papers ahead of their publication year for project-tracking reasons. I have seen this in other regulators' numbering conventions and it is not impossible. The less benign reading is that the schedule has been pulled forward and the numbering reflects the original plan, not the current one. The third reading, which I consider most probable, is that these dates are drawn from a rolling project plan that has been partially revised, and that the published paper captures the revision unevenly. This is common in large regulators and is not a sign of incompetence โ it is a sign of parallel workstreams.
Why does the timestamp matter? Because the application window is the practical deadline, not the effective date. A firm that wants to continue serving UK users under authorization must file during the window. The window opens before the rules are finalized. That means a firm must decide to apply before it knows exactly what it is applying for. This is not unique to crypto regulation, but it is unusually stark here, because CP26-36's substantive classification is genuinely uncertain. An operator could commit significant capital to an application, only to find that post-consultation revisions have narrowed or widened the scope in a way that invalidates the application's premise.
There is an important strategic implication buried in the dates. The consultation closes November 18. The application window opens ten months later, on September 30, 2026. The gap between consultation close and application open is where the FCA will do its real work โ drafting the final rules, testing them against the legal framework, and negotiating internally. Firms that submit comments by November 18 will influence that drafting. Firms that wait for the finalized rules will have missed the only input window that exists before the application clock starts. I have said this before in the context of other consultations and I will say it again: the comment period is not a courtesy, it is the product. This is the last moment at which the four criteria can be narrowed, or the discretion indicators can be softened, or the technical services exemption can be given a workable definition. After November 18, all that is left is implementation.
Ecosystem Position: The Orchestrator Layer and Its Structural Exposure
To understand why the FCA chose this layer, it helps to look at where aggregators sit in the DeFi stack. Upstream is liquidity: AMMs, order books, and cross-chain bridges. Downstream is user access: wallets, dApps, and interfaces. The aggregator sits in the middle, holding no liquidity of its own, taking no principal risk, and functioning as an orchestrator โ the entity that reads what liquidity exists and decides how a given trade should traverse it.
This is the most exposed position in the stack, and the FCA has correctly identified it. Compare to the alternatives. The upstream liquidity layer can claim protocol neutrality: a pool is a curve, not a service. The downstream access layer can claim tooling: a wallet displays information and signs transactions at the user's direction. The orchestrator cannot claim either. It is doing something on the client's behalf that the client could not easily do alone, and it is doing it for a fee. That is the defining shape of a financial service.
I have made a version of this argument for years in the Layer 2 context, and it applies here with more force. Value in a stack accrues to the layer that can charge for judgment, not the layer that supplies a commodity. Liquidity is approaching a commodity. Interfaces are approaching a commodity. Judgment about where to send an order is still scarce, and scarcity is what attracts both margin and regulation.
The consequence is that the value and the risk are co-located. The aggregator's differentiation โ its routing quality โ is exactly what makes it a regulatory target. A protocol with no differentiation is ignored by both users and regulators. This is the trade-off that the industry's most successful players have been deferring for years, and CP26-36 is the point at which the deferral expires.
There is a specific sub-case worth flagging. Cross-chain aggregators, which route not only between pools but between chains, face compounding exposure. They already carry bridge risk โ the most consistently exploited surface in DeFi. CP26-36 adds a second layer of exposure by classifying the path-selection decision as potentially regulated. A cross-chain router today makes a decision that involves not only price and liquidity but also bridge security assumptions, which is a counterparty-risk assessment in the most literal sense. Every cross-chain aggregator is, on the FCA's factors, a textbook arranger. I expect this segment to be the first to seek legal structure or retreat from UK-facing service, not because it is more regulated but because its existing risk posture makes the marginal cost of compliance lower than the cost of contesting the classification.
The composability question is also worth noting. DeFi's structural advantage over TradFi is that its components call each other. A compliant aggregator whose routing logic is subject to authorization requirements may find that it cannot expose that logic to other protocols without creating liability for those protocols. If the composability of the routing layer degrades, the downstream protocols that depend on it lose functionality. The regulation does not need to target those downstream protocols to affect them. It only needs to make the upstream component expensive to compose with.
Competitive Restructuring and the Concentration Effect
There is a reading of CP26-36 as a pure cost imposition, and there is a reading of it as a market-structure intervention with a concentration effect. I lean toward the second.
The cost of authorization is not trivial. It includes legal fees, capital requirements, compliance personnel, reporting infrastructure, and ongoing supervision. For a large aggregator with existing legal structure and revenue, this is a line item. For a small or anonymous team, it is an existential decision. The FCA has created a filter that selects for size and legal form โ the two attributes that correlate most strongly with being an easy enforcement target and least strongly with being a bad actor.
The consequence, if the classification holds, is a consolidation of the UK-accessible aggregator market. Marginal players exit. Surviving players absorb volume. Market share concentrates into a smaller number of authorized operators. Whether this improves user outcomes is an empirical question, but the structural direction is not ambiguous: fewer, larger, more compliant, more expensive.
The interesting wrinkle is that the same dynamic produces a shadow market. Operators without UK-identifiable entities cannot be authorized, which means they cannot lawfully serve UK users โ but they also cannot be easily compelled to stop. The FCA can pressure interfaces, payment rails, and hosting, and it will. But a fully on-chain router with no recoverable assets and no jurisdictionally resident operator presents a genuine enforcement gap. The result is likely a bifurcated market: a compliance tier accessible through regulated interfaces, and a permissionless tier accessible through any wallet whose developer is out of reach.
This is the structure I would expect to see emerge by 2028. It is not novel. It resembles the pre-regulation gambling market, the pre-regulation file-sharing market, and the pre-regulation prediction market. The pattern is always the same: the regulated tier serves mainstream users at a higher cost and lower risk; the unregulated tier serves the remainder at lower cost and higher variability. Both exist. Neither eliminates the other. Policy debates about whether this is desirable do not change the equilibrium.
The Front-End Split and the Architecture of Compliance
There is an important technical distinction that the paper's framing invites but does not resolve. On-chain contracts are immutable, or close to it. Front-ends are not. The FCA's enforcement capacity is far greater against the second than the first.
This produces what I expect to be the dominant architectural response to CP26-36: the separation of routing intelligence from contract logic, with compliance applied at the interpretable layer. In practice, this means an on-chain router that continues to function permissionlessly for any caller, paired with a front-end whose operators are authorized persons subject to FCA supervision. The on-chain layer is the commodity. The front-end is the service. Persons using the front-end are served by a regulated entity. Persons calling the contract directly are not.
I want to be careful here, because this architecture is often presented as a loophole and I do not think it is one. The FCA's discretion test looks at who sets the standard, and if the front-end operator sets the routing parameters, the front-end operator is the arranger regardless of where the code executes. The split architecture is not a compliance strategy. It is a liability allocation strategy. It determines which entity is exposed, not whether exposure exists.
That said, liability allocation is not nothing. An operator that deploys a permissionless contract and then operates a front-end under authorization has contained its regulatory exposure to the front-end entity, which can fail without taking the protocol down. This is the standard move in regulatory adaptation: quarantine the regulated activity into a corporate shell, leave the infrastructure permissionless, and accept that the shell absorbs the cost. Whether the FCA accepts this structure is an open question, and it will not be resolved by the consultation paper. It will be resolved by the first enforcement action against a firm that tried it.
My working expectation is that the FCA accepts the structure in principle and attacks it in practice, by examining the operational relationship between the front-end entity and the on-chain protocol. If the same team controls both, if the front-end entity funds the protocol's development, if the tokenomics route value from the protocol to the front-end's owners, the separation will be treated as a formality. The FCA has done this repeatedly in TradFi, piercing structures that exist only on paper. There is no reason to expect different treatment here.
Wallets and the Blurring of Tool and Service
The downstream layer is where the paper's implications become hardest to bound. Wallet-embedded swaps โ the swap buttons inside MetaMask, Rabby, Phantom, and dozens of others โ are aggregators in everything but name. They route, they compare, they select. The paper does not name them. The factors capture them.
A wallet that displays a swap button and routes the trade through a single venue is on one side of the line. A wallet that routes through multiple venues on the basis of a quote comparison is on the other. The difference is a single line of code โ whether the quote comes from one source or several โ and it is a difference that no user will notice and that no wallet developer can safely ignore.
The practical effect is that wallets will need to decide whether their swap feature is a tool or a service. Treating it as a tool โ meaning the wallet transmits the user's chosen venue and nothing else โ preserves the exemption but degrades user experience, because the user now has to choose a venue without the wallet's help. Treating it as a service requires either authorization or a change to the wallet's relationship with UK users. Neither option is free, and both are visible in the product.
There is a strategic dimension that I think is underweighted. Wallets are the most regulated-adjacent layer in DeFi because they are already subject to some jurisdictional rules in several markets and because they typically have corporate entities and identifiable developers. Unlike anonymous protocols, wallets can be served papers. Which means the FCA's most effective route to influencing aggregator behavior may not be through aggregator enforcement at all โ it may be through wallet-level pressure, requiring wallets to disclose the regulatory status of the routing services they surface. This is a classic regulatory technique: regulate the access point, not the service, because the access point is where the users are and where compliance can be verified.
If the FCA adopts that approach, the practical effect on UK users will be visible within a year of the rules taking effect โ not as a ban, but as a warning label. Interface-level disclosure is the lowest-cost enforcement tool available to the regulator, and it is the one I would predict.
What the Paper Does Not Say, and Why That Matters
Equally instructive is what CP26-36 leaves unaddressed. There is no discussion of MEV, despite MEV protection being a routing decision on counterparty risk. There is no discussion of oracle dependency, despite oracle selection being a venue-selection decision. There is no discussion of intents-based architectures, in which the user specifies an outcome and solvers compete to produce it โ a model in which the discretion is arguably displaced from the aggregator to the solver, and in which the FCA's framework would need substantial extension to apply cleanly.
The intents question is the most significant omission, because intents-based routing is where the category is moving. If the user's intent is the instruction and solvers compete to fill it, then the aggregator is a matching venue and the solvers are the arrangers. The FCA's factor list does not obviously capture this. Which either means the regime will be extended in a future consultation, or the category will migrate toward intent architectures specifically to escape the classification. I would bet on both, sequentially, and I would expect the migration to precede the extension. That is the standard dynamic: the regulation defines the shape of the escape, and the industry takes it.
The Contrarian Reading: This Is Not About DeFi at All
Here is the reading that I think most of the coverage has missed. CP26-36 is not primarily a DeFi regulation. It is a front-end regulation dressed as a protocol regulation, and its real function is to establish that the interface between users and on-chain liquidity is a financial service regardless of what runs underneath it.
Follow the enforcement logic. The FCA can fine persons. The FCA can withdraw authorizations. The FCA can compel disclosures. The FCA cannot easily modify an immutable contract, cannot seize assets that exist only as contract state, and cannot arrest a multisig. Every effective enforcement tool it has operates on the identifiable operations layer โ the companies, the foundations, the front-ends, the wallets, the marketing channels. CP26-36's substantive classification, whatever its doctrinal ambition, is operationally aimed at that layer.
That is why the paper is careful to enumerate the four criteria and the three discretion indicators. They are not a taxonomy. They are a test that a regulator can apply to a company's description of its own product. When the FCA asks an aggregator operator to explain how it selects venues, the operator will describe price comparison, liquidity checking, cost estimation, and latency optimization. The operator will have just described the regulated activity, in its own words, on the record. The factor list is an interrogation script.
The second element of the contrarian reading is that this protects incumbents. I have watched regulatory complexity function as a moat in too many markets to see this one as different. Authorization costs are regressive relative to firm size โ they consume a larger share of a small firm's resources and a smaller share of a large firm's. When the compliance bar rises, the marginal exit is always at the bottom of the market. The firms that survive are the ones that already had legal teams, capital reserves, and the ability to absorb a multi-year authorization process. The firms that die are the ones whose differentiation was technical and whose overhead was minimal.
The third element is the part nobody in DeFi wants to say out loud, and I will say it because it is true and because pretending otherwise has cost this industry a decade. The decentralization defense was always a legal stratagem, not a description of the systems it described. Every protocol that claimed to be autonomous had a team, a treasury, a foundation, a multisig, a governance process, or a set of upgrade keys. The claim that the code was the actor was never taken seriously by regulators because it was never true in the way that would have mattered. What CP26-36 does is close the gap between what the industry said and what the industry was, and the gap is narrower than the industry's rhetoric suggested.
The protocols that are genuinely hard to regulate are the ones that did the hard technical work of removing their own control โ no upgrade keys, no admin functions, immutably deployed routing. There are very few of these. I can count them on one hand, and most of them do not have the liquidity or the interface presence to matter to UK users. The rest made a choice between retaining control and gaining regulatory clarity, and most chose control, and now they face the bill.
Complexity hides risk; simplicity reveals it. The DeFi stack presented itself as simple โ code is law, the contract executes, nobody is in charge. It was not simple. There were owners everywhere, and the regulation has simply found them.
The Compliance Economics Nobody Is Pricing
There is a financial dimension to CP26-36 that the market has not yet absorbed and that will matter more than the doctrinal question. Authorization under the UK regime implies capital requirements, and capital requirements are balance-sheet obligations. An aggregator that routes ten billion dollars of annual volume on a basis-point fee is not a capital-rich business. Its revenue is a thin skim on other people's liquidity, and its balance sheet is typically a treasury token and a multisig.
Meeting a capital requirement means either raising capital or retaining earnings, both of which reduce the surplus available to token holders or equity holders. In a category where the marginal operator is already near breakeven on the routing fee and dependent on token incentives to sustain liquidity, a capital requirement is not a cost โ it is a revaluation. The compliant version of the business may be a smaller business than the non-compliant version, permanently.
I have modeled this in other contexts and the pattern is consistent. Regulatory compliance is a fixed cost, and fixed costs scale badly in thin-margin volume businesses. The aggregators that can absorb it are the ones with the largest volume and the strongest treasury. Concentration follows mechanically.
The strategic options for an affected operator are, in order of increasing cost, exit the UK market, restructure to move the UK-facing activity into an authorized subsidiary, acquire or partner with an authorized entity, or pursue authorization directly. Each of these has a different time horizon, and the application window's September 2026 opening date means the decision has to be made long before the rules are final. Firms that start now will be ready. Firms that wait for the final rules will miss the window and have to serve UK users through a partner or not at all.
That deadline, more than any doctrinal point in the paper, is what will determine the shape of the market. The regulator has not just changed the classification. It has imposed a decision timeline that forces the affected industry to reorganize before it knows the final rules. This is not an accident. It is how regulators compress deliberation.
Takeaway: The Vulnerability Forecast
The dominant narrative that will form around CP26-36 is that it is a crackdown on DeFi. That framing is wrong and will lead operators to misallocate their response. This is not a crackdown. It is a reclassification with a filing deadline.
The vulnerability that the paper creates is not regulatory capture of protocols โ the FCA cannot capture a protocol. The vulnerability is that the identifiable layer of the DeFi stack, which is the layer that handles user access and routing decisions, has been told that its core function is a regulated activity and given eighteen months to restructure before the window closes. The operators that read this as a doctrine debate will be arguing when they should be filing. The operators that read it as a schedule will be authorized when the rules take effect.
The second-order vulnerability is the exemption. Every operator that claims the technical services exemption on the basis of a router that optimizes for the four criteria is claiming something the paper does not support. The downside of being wrong is not a fine โ it is unlicensed activity. That asymmetry will push every serious operator toward authorization regardless of whether the classification is correct, which means the classification will become correct by default. Regulators achieve more through uncertainty than through clarity, because uncertainty forces the conservative choice. CP26-36 is a masterclass in the technique.
The third-order vulnerability is the one nobody is watching. If the front-end is the regulated layer and the contract is not, the smart move is to hold no contract and operate no front-end โ to be the routing standard other people implement, compensated in a way that does not touch UK users' transactions. Licensing a routing engine rather than operating a routing service is a different shape of business, and it may be the one that survives. Somebody will build it in the next twelve months. The question is whether the FCA considers a licensed routing engine a settled matter or the next consultation.
I have watched four regulatory cycles in this industry now. The pattern is identical each time. The paper arrives, the industry debates the doctrine, the deadline passes, and the market reorganizes around whoever filed. Gas up or get left behind is the crude version of the lesson. The precise version is that the schedule is the regulation, and the substance is the distraction. Read CP26-36 as a calendar, not a manifesto, and the next eighteen months become legible.
Proofs verify truth, but context verifies intent. The FCA's intent is not in dispute. Only the calendar is, and the calendar is the part you can still influence โ for another three weeks. After November 18, the only variable left is who applied.