What the FCA is consulting on
On October 21, the UK Financial Conduct Authority published CP26/36, a consultation on guidance for further exclusions from the cryptoasset regulatory perimeter. The FCA lists temporary settlement arrangements, temporary holding of UK qualifying stablecoins for payment transactions, arrangements involving stablecoin backing assets, some proprietary trading, and technical services that merely provide access to a third-party service or decentralised protocol. These are the FCA’s reported proposals; the production conclusions below are Ineeza analysis.
The consultation closes on November 18, 2026, and the FCA aims to publish final guidance in January 2027. The broader regime is due to take effect on October 25, 2027. The FCA also says it will allow limited additional time for otherwise complete applications where uncertainty about the technical-services exclusion materially affected the arranging-permission analysis.
This is draft guidance under consultation, not a final determination that any named architecture or provider is outside regulation. Its immediate significance is operational: wallet, payment, exchange, custody, and protocol-access products often combine several functions, while an exclusion may attach only to one narrowly defined function.
Classify each function, not the product label
A service described as a wallet, gateway, API, or protocol interface may authenticate users, select routes, construct transactions, hold assets, submit orders, arrange counterparties, and reconcile settlement. A single product name hides those different control points.
Ineeza analysis: teams should maintain a perimeter map at the level of executable functions. For every path, record the legal entity, user type, jurisdiction, asset classification, counterparty, custody state, decision owner, transaction authority, and duration of control. The resulting classification should be versioned with the code and product configuration that implement it. An exclusion applied to passive access should not silently flow into routing, execution, or safeguarding functions that require a separate assessment.
“Merely allows access” must remain true at runtime
The proposed technical-services exclusion concerns services that merely allow access to a third-party service or decentralised protocol. The practical boundary therefore depends on what the system actually does, not only on contractual wording or interface design.
Ineeza analysis: an access layer should produce evidence showing whether it only relays user-directed instructions or also chooses a venue, recommends or alters terms, controls transaction ordering, holds signing authority, or can substitute a destination. Feature flags, smart routing, agentic execution, and managed keys can change that functional profile after launch. Release review should re-run perimeter classification whenever those capabilities change.
Temporary stablecoin holding needs explicit state and time bounds
The FCA specifically identifies temporary UK qualifying stablecoin holding arrangements used for payment transactions. “Temporary” and “for payment” are lifecycle properties: they cannot be demonstrated by a wallet balance alone.
Ineeza analysis: a payment system should bind each holding event to a payment instruction, expected recipient, amount, currency, permitted rail, entry timestamp, deadline, and terminal state. It also needs deterministic rules for failed delivery, refunds, disputes, sanctions holds, chain congestion, and assets left after partial execution. Monitoring should detect balances that outlive the permitted window, while reconciliation should connect wallet movements to the payment and customer records that explain them.
Build evidence for change, not a one-time legal memo
The consultation arrives while firms are already preparing applications, and the FCA acknowledges that late legislative changes created uncertainty for some technical-service providers. Final guidance may still differ from the consultation text.
Ineeza analysis: perimeter decisions should become controlled operational artifacts. Store the source rule and interpretation version, affected functions, assumptions, approval owner, effective dates, and tests proving that production behavior remains inside the assessed boundary. Use deployment gates for changes to custody, routing, signing, asset support, or counterparties, and maintain a rollback path if the final guidance changes the classification.
Ineeza’s view
CP26/36 matters because it turns regulatory scope into a system-design question. The reliable boundary is not “we are a technology provider” or “funds are held briefly.” It is a provable chain of functions, authority, state transitions, and time limits. Teams that encode that chain in architecture, release controls, and runtime evidence will be better prepared both for the final UK guidance and for operating the product they actually built.