Crypto Permissions and Perimeter: How to Scope the UK Authorisation Route

What It Is

Permissions and perimeter analysis is the first serious workstream in any UK crypto authorisation programme. Before a firm can sensibly draft governance documents, prudential assessments, or custody procedures, it needs to decide exactly which activities it intends to carry on in the UK, which entity will carry them on, how customers are onboarded and serviced, and which parts of the model rely on group or third-party infrastructure.

Under the incoming UK regime, this exercise is no longer just an abstract legal opinion about whether a token might be inside or outside the perimeter. It is an operating-model scoping exercise. The FCA's current package of crypto consultations points toward a regime in which trading platform activity, custody and safeguarding, stablecoin-related activity, staking-related features, market conduct, prudential standards, and conduct obligations all need to be considered in a joined-up way. A firm therefore needs a permissions view that reflects its actual customer journey and technology model, not a simplified marketing description.

That is why a permissions memo is often the most important early authorisation document. It provides the factual and regulatory map that the rest of the programme builds on.

Why the FCA Cares

The FCA's gateway stance across sectors has been consistent for several years: it wants to understand what a firm actually does, not what it calls itself. In crypto, that matters even more because many business models collapse multiple functions into one proposition. A firm may describe itself as an exchange, for example, but the real model may also include custody, staking, promotions, outsourced dealing arrangements, treasury activity, and retail distribution into the UK.

The FCA is also concerned about effective supervision. If the UK entity is thin, if material functions sit overseas, or if key decisions are taken by a non-UK group company, perimeter analysis becomes inseparable from governance and structure. The regulator will want to know who is carrying on the activity, who controls the relevant risks, what records the UK entity can access, and whether the legal structure allows meaningful supervision after authorisation.

This is why permissions work should not be treated as a short preliminary note that gets filed away. It is the first test of whether the proposed model is supervisable.

Which Firms Are Most Exposed

The heaviest perimeter complexity usually sits with firms that combine several crypto functions in one customer proposition. Trading platform and exchange models are the clearest example, because they often involve customer onboarding, asset admission decisions, custody dependencies, internal treasury logic, retail-facing disclosures, and surveillance responsibilities. The same applies to custody-led businesses that also offer staking or other yield-like features, because the customer-facing description may differ significantly from the legal and operational treatment of customer assets.

Overseas groups with UK users are another high-risk category. Many of these firms have historically operated with a central global platform, shared technology, and cross-border customer support. Under the incoming regime, they will need a more precise answer to a harder question: what exactly is the UK entity doing, and can it evidence control over the regulated activity if critical infrastructure or expertise sits elsewhere in the group?

Stablecoin-adjacent models also need care. Even where the firm is not itself the issuer, reserve management, wallet handling, redemption mechanics, safeguarding roles, and payment-adjacent features can alter the permissions analysis materially.

What Firms Get Wrong

The most common mistake is starting with product labels rather than activity analysis. "Exchange", "custodian", "wallet provider", or "staking platform" are commercial descriptions, not permissions conclusions. They do not answer which entity contracts with the customer, where the regulated activity takes place, whether the model includes agency or principal elements, or how admissions and disclosures are governed.

The second mistake is separating perimeter work from the operating model. In practice, the permissions answer depends on contractual flows, decision rights, onboarding logic, treasury arrangements, and outsourcing. If those facts are still fluid, the perimeter note will become stale quickly. Firms that draft the memo too early often end up redesigning it once the governance or legal structure is clarified.

The third mistake is underestimating UK nexus questions. A firm may assume that a non-UK platform with no substantial UK substance can continue to rely on historical logic. The current FCA direction of travel suggests that firms should be much more careful, especially where the model is retail-facing, UK-targeted, or supported by a planned UK structure.

What Evidence the FCA Is Likely to Expect

The FCA is likely to expect a permissions analysis that is anchored in evidence rather than broad summary language. In practice, that means the memo should be tied to legal entity charts, customer flow maps, contracting terms, outsourcing schedules, treasury flows, and internal responsibility maps. If the model relies on group support, the analysis should explain what those services are, where they sit, and how the UK entity oversees them.

A credible permissions file will usually need to answer at least six practical questions:

1. What are the proposed day-one activities?
2. Which legal entity or branch carries each activity on?
3. Where does the UK nexus arise?
4. Which third parties or group entities support the model?
5. Which control functions sit in the UK and which sit elsewhere?
6. Which additional workstreams follow from that analysis, including prudential, custody, AML, and market conduct?

This is one reason the permissions memo should be written early but not in isolation. It needs enough factual maturity to survive FCA scrutiny.

Good Implementation Looks Like

Good implementation starts with a factual scoping exercise rather than a legal-only write-up. The firm maps the end-to-end customer journey, identifies each legal entity and service provider involved, documents where decisions are taken, and then overlays the permissions analysis on top of that operating map. That forces the firm to confront any mismatch between how the model is described externally and how it really works internally.

The output should not be a generic perimeter note. It should be a permissions pack with an entity map, customer-flow description, responsibility mapping, and a list of follow-on workstreams that the authorisation programme must cover. If the analysis identifies areas of uncertainty, those should be recorded explicitly rather than buried. A clear, cautious permissions memo is more credible than an overly confident paper that assumes difficult issues away.

Finally, the permissions work should be kept live. As the governance design, prudential thinking, or custody model develops, the permissions memo may need to be refined. In a real crypto authorisation programme, perimeter analysis is usually the beginning of the build, not a one-off attachment.

Current FCA Materials to Track

The current starting points are the FCA's new regime overview, the FCA's gateway timetable update, and CP26/13: Cryptoasset perimeter guidance. For firms with broader operating-model questions, the regime papers on regulated cryptoasset activities and Handbook application also matter because they show how the permissions answer links into the wider control environment.

How MEMA Supports This Work

Our crypto readiness work starts here. We help firms translate their product description into a permissions-led operating model, document the UK structure and group dependencies, and identify the downstream workstreams the FCA is likely to test. That often includes follow-on work on governance, financial crime, prudential design, custody and safeguarding, and FCA-facing application materials.