Imagine a simple brief: a UK customer loads pounds into an app, converts them into a fiat-backed stablecoin, holds the stablecoin in the app and sends it to a merchant. Product asks Legal one question: “Can we launch?”

There is no useful yes-or-no answer until that single customer journey is broken into separate activities.

The product briefCustomer deposits GBP → receives or buys a stablecoin → holds it in-app → pays a merchant → merchant can redeem or convert back to fiat.

1. Draw the money and asset flow before reading the rulebook

The first task is not to label the product a “wallet” or a “stablecoin payment app”. Map what happens at every step: who receives the pounds, who creates or supplies the stablecoin, who controls the customer’s cryptoassets or private keys, who transfers the asset, who contracts with the merchant and who provides redemption.

This matters because the UK framework treats different cryptoasset activities separately. The FCA’s perimeter guidance identifies regulated activities including issuing a qualifying stablecoin, safeguarding cryptoassets, arranging safeguarding, operating a qualifying cryptoasset trading platform, dealing, arranging deals and arranging staking.

Product-counsel question: if the customer experiences one button, how many legally distinct activities sit behind it?

2. Are we issuing the stablecoin, or only using someone else’s?

If the group creates the stablecoin, offers or arranges its offer from a UK establishment, undertakes redemption and holds or arranges reserve assets to maintain its value, the new regulated activity of issuing a qualifying stablecoin may be engaged.

That is very different from a product that uses a stablecoin issued by an unrelated third party. The customer experience may look similar, but the regulatory role of the company can be completely different.

Decision: identify the issuer before deciding what authorisation analysis the product needs.

3. Who actually controls the customer’s stablecoin?

“We provide a wallet” is still not enough information. If the company safeguards the customer’s qualifying cryptoassets—or arranges for safeguarding—the custody perimeter becomes relevant. A genuinely non-custodial software product raises a different set of questions from an app in which the company or its provider controls customer assets.

Decision: document who can move the asset, where keys or equivalent control sit, what happens if the provider fails and whether a third-party custodian is acting for the customer or for another group entity.

4. A stablecoin payment product can sit across two regulatory projects

This is where the launch analysis becomes more interesting. The UK has already created the future cryptoasset regime, which is due to take effect on 25 October 2027. At the same time, the Government is modernising payment-services regulation and is considering how certain stablecoins used for payments should fit into that framework.

The FCA also notes that the Government has proposed changes intended to avoid unnecessary overlap for certain activities involving UK-issued qualifying stablecoins, while the future treatment of stablecoin payments continues to develop.

Decision: do not assume that obtaining a crypto permission answers every payments question. The analysis needs to be refreshed against the legislation actually in force at launch.

5. Put a legal entity next to every box in the product flow

Now imagine the group has a UK operating company, an EEA payments entity and a separate technology company. Product may see one service. Regulation sees legal persons carrying on particular activities.

For every step in the flow, ask: which entity contracts with the customer? Which receives fiat? Which supplies or issues the stablecoin? Which safeguards it? Which executes the transfer? Which contracts with the merchant? Which promises redemption?

Decision: the launch architecture should show product flow and entity structure on the same page.

6. Only then build the permissions gap

Existing status is relevant, but it is not the conclusion. The FCA says firms wishing to undertake the new regulated cryptoasset activities will need the appropriate FSMA authorisation or variation of permission. That includes firms already registered under the Money Laundering Regulations and firms already authorised or registered under payment-services or electronic-money legislation.

A useful internal output is therefore not “Legal reviewing”. It is a table with four columns: activity, entity, current permission and permission or change potentially required.

What Product needs back from LegalNot a twenty-page summary of stablecoin regulation. A launch map: what can proceed, what depends on a permission or structural change, what remains legally unsettled, who owns each dependency and which assumptions must be rechecked before launch.

So, can we launch?

The answer depends on the architecture. A company issuing its own UK qualifying stablecoin, holding customer assets and operating the payment flow presents a different regulatory problem from a software product that integrates a third-party stablecoin and regulated service providers.

The practical job of product counsel is to turn “stablecoin payments” from one feature name into a sequence of activities, entities, permissions and dependencies. Only then does a launch decision become useful.

Primary sources

  1. FCA — PS26/18: Cryptoasset perimeter guidance, 16 September 2026.
  2. FCA Handbook — PERG 18: Guidance on regulated cryptoasset activities.
  3. FCA — Overview of our cryptoassets regime policy statements.
  4. FCA — Cryptoassets: How the gateway will operate, updated 22 September 2026.
  5. HM Treasury — Modernising Payment Services Regulation consultation.
  6. HM Treasury — Policy note on draft amendments to the Cryptoassets Regulations, updated 15 September 2026.
Scope noteThis is independent research and commentary, not legal advice. It uses a fictional product to illustrate a decision process and summarises public UK materials as at 28 September 2026. The stablecoin-payments framework is still developing, so the applicable position should be checked against legislation and FCA rules in force at the relevant launch date.