UK crypto regulation now has a legislative timetable, but a law being made is not the same as every part of a new regime being operational. The February 2026 regulations set a full commencement date of 25 October 2027 and allow specified preparatory work earlier. Customers and businesses need to distinguish those stages when assessing a provider or planning a product.
That distinction is the practical subject of this guide. It explains how to read the legislation, map a business activity and ask better questions about a provider’s status. It does not assume that rules or implementation details published after 6 March 2026 are already known.
Read the commencement clause before the headline
The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 were made on 4 February 2026. Regulation 1 provides for full commencement on 25 October 2027, subject to earlier commencement for listed preparatory purposes.
Those earlier purposes include enabling the FCA to make rules and guidance, take preparatory steps and deal with relevant permission applications. They do not mean that a customer can assume the complete future framework applies to every crypto service immediately.
Put three dates in any research note: when the instrument was made, when a particular provision starts to operate, and when the full regime begins. If a news summary mentions only the first, return to the instrument.
This habit is useful beyond crypto. Legislation often separates enactment, rulemaking, application windows and operational commencement. Treating those events as a single launch date produces avoidable mistakes.
Map the activity instead of relying on the word crypto
The instrument addresses different activities and types of cryptoasset. Its structure includes provisions concerning public offers, admission to trading, market abuse and amendments to the regulated-activities framework.
For a business, the starting description should be operational. Does it safeguard customer assets, operate a trading venue, arrange transactions, issue a qualifying stablecoin or provide a different service? Does it control keys or merely provide software? Which entity performs each part?
A broad label such as “Web3 platform” is not detailed enough to establish the relevant perimeter. The same website can contain several services with different legal implications. A group can also distribute those activities across entities.
Create an activity map before seeking a legal conclusion. It should show customers, assets, money flows, key control, contractual counterparties and the countries involved. That gives an adviser or regulator something concrete to assess.
Separate the provider’s different kinds of status
A provider may describe itself as registered, supervised, licensed or authorised. These terms need a named authority, legal entity, jurisdiction, activity and date to be meaningful.
Ask what the claimed status actually covers. A registration connected with anti-money-laundering obligations should not be read as a blanket approval of every product or a guarantee against losses. Likewise, a group affiliate’s permission does not automatically cover the entity in your contract.
Keep the present and future claims separate. “Preparing for authorisation” describes an intention or process. It does not establish that authorisation has been granted. A planned application is also different from an application accepted for consideration.
| Provider statement | Evidence to request | Question still to answer |
|---|---|---|
| Registered with an authority | Entry for the exact legal entity | Which obligations does it cover? |
| Applying for future permission | The actual stage and scope | Has permission been granted? |
| Part of a regulated group | Contracting entity and group structure | Does that permission cover this service? |
| Preparing for new rules | Implementation plan | What applies to customers now? |
| Assets are protected | Contract and protection framework | Protected against which failure? |
This table is a due-diligence method, not a determination of any provider’s legal status.
Read product rights separately from platform permissions
A platform’s regulatory status and a token holder’s rights answer different questions. A token may represent a claim, access right, asset exposure or some other arrangement. The platform interface cannot tell you all of that.
The February instrument includes a disclosure framework for qualifying cryptoasset public offers and admissions to trading. Its disclosure provisions focus on information material to assessing the cryptoasset, including relevant rights and obligations. The detailed application depends on the instrument and subsequent rules.
For a reader, the useful habit is to ask what is being acquired and from whom. Identify the issuer or responsible party, the rights attached to the asset and the conditions under which those rights can be exercised.
Do not infer that regulatory coverage turns a speculative asset into a safe investment. Rules can address conduct and market structure without eliminating price volatility, operational failures or the possibility of an unsuitable purchase.
Distinguish custody from a return promise
Suppose an app offers both a storage service and a product that pays a return on deposited tokens. The first may be described as custody, while the second may involve lending, staking or another arrangement. The risk and legal analysis can differ.
Read the terms for each service rather than assuming one account agreement produces the same rights everywhere in the app. Look for transfers of title, asset-use permissions, withdrawal conditions and third-party dependencies.
Our guide to crypto custody and failure explains how to trace the contracting entity and custodian. That exercise remains useful during a regulatory transition because the present agreement still matters.
For a business planning a new service, document when a customer’s assets move between arrangements. A button labelled “earn” can conceal a significant change in rights. Make that transition part of the product and legal review.
Build a preparation file for a small crypto business
Begin with a factual description of the business rather than an application narrative. List legal entities, beneficial owners, customer groups, supported assets, transaction routes and the services performed by contractors.
Add the activity map and a register of assumptions. Mark questions that require legal interpretation instead of converting them into confident statements. Record the source and date for each important regulatory conclusion.
Then identify the operational work that is useful regardless of final rule detail: accurate records, clear ownership of responsibilities, incident handling, reconciliation, access controls and intelligible customer terms. These are preparation areas, not a claim that a particular checklist satisfies the future regime.
Avoid making irreversible product commitments based on a headline. If a launch depends on a permission or interpretation, make that dependency visible in the plan and budget. A timetable should include the possibility of further information requests and changes to implementation details.
Test the plan with a concrete service
Consider an illustrative company that wants to provide a crypto trading interface to UK customers while using another firm for custody. It plans to receive customer instructions, route trades and display balances.
The company should map each function separately. Who contracts with the customer for execution? Who holds assets? Who controls the transaction instruction? Which firm handles complaints and account records? Does the interface itself perform an activity within the new perimeter?
The answer cannot be derived solely from the fact that custody is outsourced. Outsourcing one function does not settle the treatment of the others. Nor does a supplier’s statement that its own service is regulated determine the company’s obligations.
The practical output is a list of activities and accountable entities that can be assessed against the legislation and relevant guidance. This is more useful than an early marketing claim that the business is “fully compliant” with a regime whose implementation is still developing.
Treat the transition as an information-management problem
Keep one current regulatory note with the source documents and their dates. Separate enacted provisions, consultations, proposed rules, final rules and provider statements. These are different kinds of evidence.
When a new document appears, identify what it changes. Does it alter the activity perimeter, a deadline, an application process or a customer-protection requirement? Avoid rewriting the whole plan because a headline sounds important.
Assign an owner to each material uncertainty. “Waiting for regulation” is too vague if the business can already clarify its own service model or collect required operational information.
For customers, the equivalent task is smaller: identify the present contracting entity, understand current rights and revisit the provider’s status when new claims are made. Do not rely indefinitely on a screenshot taken before a transition.
Keep future protections out of today’s decision
A future rule can be relevant to a long-term business plan without being protection available to a customer today. This is particularly important when a provider uses an upcoming regime in promotional language.
Ask the provider to explain which rules presently apply and which changes are planned. If the answer mixes the two, request a dated distinction. You need the current agreement and current status to assess a current transaction.
Also consider the practical risks that regulation does not remove: concentrated exposure, loss of access, weak recovery arrangements and a mismatch between the asset’s liquidity and your obligations. Legal progress does not make those questions obsolete.
The sound conclusion from the February legislation is that there is a defined legal framework and timetable to study. It is not that every uncertainty has disappeared or that every product now carries the same protections as a familiar financial account.
Check the evidence behind a regulatory badge
Save the link to the authority’s own entry for the exact contracting entity, where a relevant public register is available. Record the permissions or status shown and the date checked. A logo copied onto a provider’s website is a claim that still needs verification.
If the entity name differs from the account agreement, ask the provider to explain the relationship before relying on the badge. Group membership can explain the difference without extending a permission. The evidence should connect the service you use to the status being claimed, rather than leave that connection to an inference.
Questions
Did the complete UK crypto regime start in February 2026?
No. The regulations were made in February and provide for earlier preparatory purposes, while specifying 25 October 2027 as the full commencement day.
Does registration mean every service a company offers is authorised?
No. Check the exact entity, activity and scope of the claimed status. Different forms of registration and permission serve different purposes.
Can outsourcing custody remove all regulatory questions for an app?
No. The app’s own activities still need to be mapped and assessed. A supplier’s status does not automatically answer the customer’s or intermediary’s obligations.
Does regulation remove investment risk?
No. It does not eliminate price changes, operational failures or the risk that a product is unsuitable for a particular purpose.
