UK crypto regulation 2026: what FCA authorisation will mean for firms
The FCA has published its final perimeter guidance and the application gateway opens this month. The questions authorisation asks of a firm reach well beyond permissions.
For several years, UK crypto regulation could be discussed in the future tense. That option has now closed. The FCA published its final cryptoasset perimeter guidance, PS26/18, on 16 September 2026. The application gateway for the new regime opens on 30 September 2026 and, for firms that want to rely on the savings and transitional provisions, closes on 28 February 2027. The regime itself takes effect on 25 October 2027, underpinned by the Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026, which Parliament made on 4 February.
The FCA has been unambiguous on one point: existing registrations and permissions will not convert. A firm registered under the Money Laundering Regulations, authorised under FSMA for other activities, or operating under the Payment Services or Electronic Money Regulations will need authorisation, or a variation of permission, if it carries on a regulated cryptoasset activity. Firms that apply after the window closes lose access to the savings provisions and may have to cease the relevant activity until they are authorised.
Those are the mechanics. The more consequential change is what authorisation asks. A firm applying under FSMA must show that it meets, and will continue to meet, the Threshold Conditions: that its legal structure, governance, financial resources, systems and controls, and treatment of customers are appropriate for the activities it performs. That is a far more searching test than whether a product can be described accurately on an application form, and for many businesses it will surface issues that have very little to do with the compliance function.
What changes under the UK cryptoasset regime from October 2027
The Cryptoassets Regulations bring a defined set of activities within the FCA's perimeter: operating a cryptoasset trading platform, safeguarding qualifying cryptoassets, dealing as principal or agent, arranging deals, issuing qualifying stablecoins, and arranging cryptoasset staking.
For a firm already active in digital assets, the first job is a mapping exercise. Which regulated activity is being performed, by which legal entity, for which customer, and through which infrastructure? On paper that is administrative. In practice it tends to expose questions a business has never had to answer with precision.
A customer-facing fintech may regard itself as a software or distribution business while a separate entity performs execution. A group may run trading through one entity and custody through another. An overseas firm may serve UK users from outside the jurisdiction. A firm already authorised for payments or investment services may have added crypto functionality to an established product without ever asking whether that addition created a new regulated activity. The perimeter is applied to what is actually happening, not to the label the business has attached to itself, and a number of firms will find the two do not line up.
One complication is already visible. In April 2026 the government published a draft statutory instrument that would exclude activities involving UK-issued qualifying stablecoins from the dealing and arranging activities, with the intention of regulating them under a modernised payments framework instead. The FCA plans to consult on updated perimeter guidance in late 2026 to reflect that change. Firms building stablecoin payment flows should map against the legislation as it will stand, not as it was first drafted.
All of which is the reason to resist framing the regime as a licensing project owned by compliance. For most firms of any scale, it is a review of the operating model.
FCA crypto authorisation applies the Handbook, not an AML checklist
An MLR registration told the FCA about a firm's anti-money laundering controls and little else. Authorisation applies the core of the FCA Handbook to regulated cryptoasset activity: the Consumer Duty, COBS, the Senior Managers and Certification Regime, operational resilience requirements, and the financial crime framework. Each carries operational questions the firm will have to answer with evidence rather than assertion.
SM&CR is the sharpest example. A named senior manager will hold personal accountability for the crypto business, and that person needs to understand the risks the product creates. What management information reaches senior leadership, and how often? How are incidents escalated, and to whom? What happens when an exchange, custodian, technology provider, or banking partner becomes unavailable? What records exist that would allow the firm to reconstruct a transaction or a customer event months after the fact?
A crypto service can perform well from the customer's point of view while resting on processes that would struggle under scrutiny. Manual reconciliations, informal escalation paths, heavy dependence on a single provider, inconsistent record keeping, and unclear ownership of decisions can remain invisible until the business reaches a certain scale or something fails. Authorisation brings those weaknesses forward, which is uncomfortable but usually cheaper than discovering them during an incident.
Existing FCA permissions do not extend automatically to crypto
Traditional financial firms enter this process with a real advantage: most already operate mature governance and control frameworks. That advantage should not be mistaken for coverage. The FCA has said plainly that firms authorised under FSMA for other activities, MLR-registered firms, payment institutions, and electronic money institutions may all need crypto-specific permissions where their activities fall within the new perimeter.
For fintechs this is particularly relevant. A payments business adding stablecoin functionality, a wealth platform offering digital asset exposure, or a broker introducing crypto trading can each create a new regulated activity inside a business whose core product was authorised long ago. The useful question is which entity is performing which activity, under which permission, at each stage of the customer journey. That level of precision becomes harder to maintain as products combine several specialist providers behind a single interface.
Outsourcing crypto infrastructure does not outsource accountability
A persistent assumption in fintech is that using a specialist provider moves the difficult part of the problem somewhere else. Operationally there is some truth in that. From a governance perspective the picture is less convenient.
There are good reasons to use external infrastructure for execution, custody, wallet technology, market data, or compliance tooling. Few firms gain anything from rebuilding mature financial plumbing for the sake of owning it. The regulated firm nonetheless remains responsible for understanding how the service works: where customer orders are routed, how execution behaves when liquidity thins, who holds assets at each point in the process, what records exist, how failures are handled, and which party carries responsibility when something goes wrong.
Provider due diligence also has to outlast procurement. Concentration risk, substitution options, service dependencies, operational resilience, and the practical cost of changing providers all deserve continuing attention. The quickest integration at launch can become the most expensive decision the firm has made once it is embedded deeply enough that replacing it means redesigning the product.
Data architecture under the new UK crypto rules
Data receives less attention in this discussion than it deserves. Regulation creates an obligation to evidence what happened, and crypto businesses are unusually prone to fragmented records. For custodians the point is explicit: CASS 17 makes ownership records, record keeping, and reconciliation formal obligations rather than good practice.
A single transaction can begin in a customer application, pass through an internal ledger, reach an execution provider, touch one or more venues, move through custody infrastructure, and eventually land in finance and reporting systems. Each of those systems may describe the same event slightly differently. At low volumes a team can reconcile the discrepancies by hand. At institutional volumes that approach breaks.
Firms will need consistent identifiers across systems, reliable timestamps, well-defined transaction states, and a clear view of which system is authoritative for each piece of information. The ability to reconstruct an order or an asset movement serves operations, customer service, risk, compliance, and financial reporting at once. Regulation often improves infrastructure by this indirect route, forcing the formalisation of data flows that grew organically and were never designed.
Prudential requirements change the economics of the business
The FCA published its final prudential rules on 30 June 2026 in PS26/12, introducing two new sourcebooks, COREPRU and CRYPTOPRU, with requirements that vary according to the firm's activities and business model.
Performing an activity in-house can therefore carry a different regulatory and capital footprint from accessing the same capability through another regulated provider. That does not make partnering automatically preferable, but it does mean the true cost of a product cannot be measured in engineering hours and provider fees alone. Permissions, people, capital, governance, operational resilience, and ongoing supervision all sit on the cost side of the ledger, and a fintech weighing a broader crypto proposition should have them in view from the start of the build-versus-partner conversation.
Using the FCA application window well
The FCA has asked firms to apply as early as possible within the window, and it will review applications in the order they arrive. There is a reason beyond regulatory goodwill to take that seriously: applications become materially harder when the underlying operating model is still changing beneath them.
A well-run authorisation exercise should also leave the firm with something more valuable than an approved permission. It should produce a clear map of activities, responsibilities, entities, providers, systems, risks, and controls. That map tells management where the business depends on a single provider, which activities have drifted beyond their original scope, which systems fail to reconcile cleanly, and where the customer proposition has become more sophisticated than the organisation supporting it.
For firms likely to fall within the new perimeter, the practical sequence is to map every cryptoasset activity to the legal entity performing it, map the infrastructure and external dependencies beneath each activity, identify where the current control framework was designed for a smaller or simpler business than the one now operating, and then ask whether the resulting model would still hold at materially higher volumes.
That final question is the one most often skipped. Regulation tends to expose problems created during growth rather than at launch. A service built around thousands of transactions behaves differently at hundreds of thousands, and a provider that is manageable when it supports one feature becomes a critical dependency once five products rely on it. Whether digital assets will sit inside the UK financial services perimeter is no longer in doubt. Whether the infrastructure, governance, and economics behind a given product are ready to sit there with them is the question each firm now has to answer for itself.