FCA-Ready Crypto Exchange Architecture

FCA-ready describes an exchange whose architecture can evidence the requirements of the United Kingdom's incoming regulated-cryptoasset regime, rather than a platform that has secured a label or an approval. The distinction matters because the framework is changing shape: registration under the money-laundering rules, which many trading venues already hold, is a supervisory permission for financial-crime purposes and not authorisation to carry on regulated cryptoasset activities. An architecture built only to satisfy the former will not, on its own, evidence the latter.

The shape of that fuller regime is now known. The FCA published its final rules for regulated cryptoasset activities in mid-2026, an application window opens on 30 September 2026 and closes on 28 February 2027, and the mandatory regime is expected to take effect in October 2027, with a savings provision that allows firms applying within the window to continue operating while their application is determined. A venue's design decision is therefore concrete rather than hypothetical: whether its systems can produce the evidence an application will require, in time to be ready on the first day.

This article sets out what FCA-readiness means at the level of architecture: how custody, the customer journey, financial-crime controls and resilience are structured so that a supervisor, an external auditor or the firm's own compliance function can see how the platform behaves and who has changed it. The perspective is design and procurement rather than an implementation recipe.

What FCA-Ready Means for Architecture

Readiness is frequently misread as an endorsement. There is no status of an FCA-approved platform, and no supplier can confer authorisation on the firm that operates its technology; authorisation is granted to the operating firm by the supervisor against the way it actually runs. FCA-ready therefore describes an architecture structured around the relevant requirements, so that authorisation is achievable and, once granted, remains demonstrable under supervision.

The practical consequence is that readiness is a property of evidence rather than of features. Two platforms can offer the same trading and custody functions while only one can show, on request, how client assets are reconciled, how a customer was categorised before being allowed to trade, or who approved a change to a limit. The architecture that can answer those questions from its own records, without reconstructing them after the event, is the one that carries a defensible claim to being prepared for the incoming regime.

From MLR Registration to FSMA Authorisation

The most consequential shift for a UK venue is the move from registration to authorisation. Registration under the money-laundering rules addresses one question — whether a firm has adequate controls against financial crime — and its supervisory scope is correspondingly narrow. Authorisation under the incoming regime addresses the whole conduct of a regulated business: how client assets are protected, how customers are treated, how the market is kept orderly, how the firm remains operationally resilient, and how each of these is governed and evidenced. Designing for it means treating the prudential, consumer-protection and resilience obligations as first-class requirements from the outset — expressed in wallet and ledger design, in the customer journey, in role and permission design and in the audit trail — rather than as policies attached to a platform scoped around registration alone.

With the FCA's final rules settled and the application window now defined, readiness has a date attached to it: a firm seeking authorisation from the start of the regime works towards that window rather than an open-ended horizon. The efficient response is to treat the authorisation file as an output of ordinary operation — a platform designed around the regime produces most of what an application needs, from reconciliations and surveillance records to customer-journey logs and change histories, as a by-product of running normally, so that preparing to apply becomes a matter of collating existing records rather than commissioning new work.

The Financial-Promotion Customer Journey

A distinctively UK requirement is the treatment of cryptoasset promotions, which have sat within the financial-promotion regime since late 2023. The rules shape the journey a prospective customer takes before trading: a clear risk warning, a cooling-off period for first-time investors, a ban on incentives to invest, and an assessment that the customer understands what they are buying and falls into a category permitted to buy it. These are not marketing preferences; they are conditions that the platform has to enforce and record.

Architecturally this means the path from onboarding to first trade is a controlled workflow rather than a form. The system has to present the right warning at the right moment, hold a first-time customer through the cooling-off interval, capture the outcome of the appropriateness assessment and the customer's categorisation, and prevent trading until each gate has been passed. Because the regime turns on being able to show that a customer was treated correctly, every step in that journey has to be recorded against the individual it applied to.

Custody and Client-Asset Safeguarding

Where a venue holds crypto-assets or funds for customers, those holdings have to be protected and kept separate from the firm's own resources, and the UK safeguarding expectations were strengthened during 2026. At the level of architecture this translates into a wallet and ledger design that keeps customer positions segregated, reconciles them continuously against on-chain balances and internal records, and constrains who can authorise the movement of assets. The distribution of holdings across hot, cold and multisig arrangements is a control decision, because it determines how exposure is limited and how withdrawals are approved.

The evidence such a design must produce is specific: that recorded customer balances reconcile to assets actually held, that access to keys is restricted and attributable, and that every movement carries an approver and a reason. The detail of key-management procedures belongs inside the security function rather than in a public description, but the architectural requirement is constant — segregation and reconciliation must be continuous and provable rather than periodic and asserted.

Financial-Crime Controls and the Travel Rule

Financial-crime controls remain central, and for a UK venue they now sit inside a wider authorisation rather than standing alone as the basis of registration. Customer due diligence, sanctions and PEP screening, and transaction monitoring have to be integrated into the platform so that their outcomes are recorded against the customer and the transaction they relate to and can be produced on request. The relevant capabilities are described under AML screening software and KYC verification software.

The UK Travel Rule, in force since 2023, adds a specific obligation for transfers of crypto-assets: originator and beneficiary information has to travel with a transaction, be validated on receipt, and be handled when a counterpart institution cannot provide it. Architecturally this is an interoperability and record-keeping requirement rather than a screening one — the platform has to attach, transmit, receive and store the required data, and evidence that it did so for each transfer that fell within scope.

Operational Resilience and Third-Party Risk

Authorisation brings operational-resilience expectations that a registration-era platform may not have had to evidence. The firm is expected to identify the services whose disruption would cause the most harm, set tolerances for how much disruption it can absorb, and show through testing that it can stay within them. For architecture this means recovery objectives that are exercised rather than documented, primary and secondary environments whose failover is tested, and audit logs and change records that let the firm reconstruct what happened during an incident.

Third-party dependencies fall within the same expectation. Custody partners, market-data feeds, cloud infrastructure and screening providers are part of the service the customer relies on, and the firm has to understand its exposure to each and be able to exit or replace one without an uncontrolled outage. Designing these relationships as substitutable components, with the means to move away from any single provider, is what turns a resilience policy into something the platform can actually demonstrate.

Evidence and the Authorisation File

Each of the domains above resolves into a question about evidence, and a platform is ready when those questions can be answered from the system rather than from intention. The table below maps the domains discussed to the demonstration each one has to support under the incoming regime.

Assembling this evidence after the platform is built is possible but costly, because records that were not captured at the time cannot be recreated faithfully. The efficient path is to treat the authorisation file as an output of ordinary operation, produced continuously by a platform whose architecture was designed with the regime in view. The broader planning perspective is described under crypto exchange software, and the UK-specific considerations under regulatory readiness for the United Kingdom.

Summary and Next Steps

FCA-readiness is not a badge applied to a finished platform; it is a property of an architecture that can safeguard client assets, run a compliant customer journey, integrate financial-crime controls, withstand disruption and evidence each of these on request. With the regime's rules settled and its application window approaching, that architecture is a near-term requirement for a UK venue rather than a distant one, and the cost of retrofitting it is consistently higher than the cost of designing for it.

The practical next step is to state, for each domain above, what the platform will need to demonstrate and where that evidence will come from. A venue that can answer those questions before it selects a platform can evaluate providers against the operating model it actually has to satisfy — the incoming FSMA regime, not a feature list — and be ready to apply when the window opens rather than after it closes.