UK crypto firms face a two-market regulatory challenge

The final transitional period under the European Union’s Markets in Crypto-Assets Regulation (MiCA) expired on July 1, 2026.

Crypto businesses that previously operated under national registration arrangements can no longer rely on MiCA grandfathering. Firms carrying out regulated crypto-asset activities in the European Union must now hold the relevant authorisation.

The timing is particularly important for UK-based crypto companies. The EU has completed its transition to a harmonised regulatory framework while the UK is preparing to introduce a separate regime.

The Financial Conduct Authority is expected to accept applications between Sept. 30, 2026, and Feb. 28, 2027. The new UK framework is due to take effect on Oct. 25, 2027. Registration under the existing anti-money laundering regime will not automatically convert into authorisation under the new rules.

UK founders pursuing growth in Europe must therefore address two regulatory programmes at the same time. The resulting challenge extends beyond licensing. It affects group structure, governance, product design, financial records and the technology used to support regulated services.

“The period in which crypto firms could build their strategy around regulatory arbitrage is drawing to a close,” said Pavel Shumsky, CMO at digital banking technology provider Velmie. “MiCA authorisation is now a condition of access to the EU market, while the UK is moving towards a full financial services regime. Competitive advantage will increasingly depend on the quality of the operating model behind the licence.”

Two regulatory regimes require one coherent operating model

MiCA allows an authorised crypto-asset service provider to offer regulated services across the European single market, subject to the relevant passporting and notification requirements. The UK framework will operate separately. A firm serving customers in both jurisdictions may need an authorised EU company alongside an FCA-regulated UK entity.

Establishing the entities is only the first step. The wider operating model must reflect the regulatory perimeter of each business.

Customer agreements should identify the correct service provider. Banking, custody, and outsourcing contracts may need to be held by the relevant regulated company. Revenue, expenses, assets and liabilities must be allocated consistently between entities. The technology platform also needs to support this separation. Customer accounts, transaction records and management records should clearly identify the legal entity that provided the service and assumed the corresponding obligation.

A platform designed for one company may require significant changes before it can support several regulated entities. This is particularly likely where the current architecture relies on shared accounts, common operational teams or data that cannot be separated by jurisdiction.

Addressing these issues while the regulatory and product models are being designed may help reduce complications later. Restructuring them during an authorisation process can increase cost and delay market entry.

The financial record may face greater scrutiny

Many crypto firms have spent the past few years improving the parts of the business customers see: onboarding, trading, funding and withdrawals. As regulatory requirements evolve, the quality of the financial records supporting those services may receive closer attention.

Regulated firms may be expected to maintain records supporting customer balances. That means showing how money or assets entered the business, how they moved through the platform and how the final position is supported by records from banks, custodians, liquidity providers and blockchain networks.

Consider a customer who funds an account by bank transfer and then purchases a crypto-asset. The firm should be able to trace that activity from the incoming payment through the internal ledger to the external execution and custody records. The same standard applies when transactions are delayed, reversed, rejected or completed externally before the internal account is updated.

These situations are part of normal operations. The important question is whether the firm can identify the break, reflect it correctly in its books and retain a clear record of how it was resolved.

“A regulator will not limit its assessment to the balance visible in the customer application,” Shumsky said. “The firm must be able to substantiate that balance from its books and records. The ledger should provide a consistent account of the customer obligation and the corresponding movement of money or assets.”

MiCA introduces specific record-keeping requirements for custody providers. Firms must maintain accurate client positions, record movements affecting those positions and distinguish customer assets from their own holdings.

The ledger therefore has a broader role than maintaining balances. It supports custody records, reconciliations, customer statements and regulatory oversight.

Reporting requirements influence data architecture

Regulatory reporting is closely connected to the design of the underlying transaction records. The requirements vary by activity: a trading platform, a custody provider and a firm dealing in asset-referenced or e-money tokens may each be required to capture and report different information.

The platform should therefore record the relevant customer, legal entity, service, asset and transaction status at source. It must also preserve the history of any rejection, reversal, amendment or other change affecting the transaction.

For firms operating in both the UK and the EU, a common financial record can support reporting in each jurisdiction while maintaining a consistent transaction history. The reports themselves will remain market-specific, but they should be produced from the same controlled source data.

“Regulatory reporting should be produced from controlled operating data,” Shumsky said. “It should not require compliance teams to reconstruct transactions from bank files, custody statements and spreadsheets at the end of each reporting period. That approach becomes progressively more expensive and difficult to govern as the business grows.”

Specialist reporting systems may still be necessary. Their reliability will depend on the quality of the source data supplied by the core platform and connected providers.

The architecture should also preserve a record of subsequent changes. Corrections, reclassifications, and manual adjustments may require appropriate access controls and a documented audit trail.

Working with specialist providers can introduce integration considerations

Many crypto firms work with multiple providers. A typical structure may include a bank, custodian, liquidity provider, blockchain analytics service and customer verification platform.

This model can reduce development time and give firms access to specialist capabilities. It can also create dependencies between organisations that may not share responsibility for the complete transaction.

A custodian may confirm that an asset transfer was processed correctly while the internal customer balance remains inaccurate. A banking provider may receive a payment that the platform cannot allocate. A compliance decision may be returned after another component has already progressed the transaction.

In each case, the providers may have performed their individual roles correctly. The regulated firm still has an unresolved issue.

Clear responsibility for the overall transaction flow may therefore be important. One team needs sufficient visibility to investigate incidents across provider boundaries and coordinate changes affecting several systems.

Where that responsibility is not assigned to an external delivery partner, it remains with the regulated company.

“When responsibility is fragmented across providers, the regulated firm is left to manage the gaps between them,” Shumsky said. “That includes integration ownership, reconciliation, incident resolution and changes that affect more than one system. Firms should understand the operational cost of taking on that role before selecting a multivendor model.”

Vendor selection should therefore consider more than functionality and software fees. Firms may need to consider who will design the broader environment, deliver the integrations, and support the service after launch.

The UK preparation period is already under way

The timetable may give firms limited flexibility if delays arise. Although the UK regime is due to take effect in October 2027, the application window is expected to open in September 2026. By then, applicants may be expected to have established their business model, governance arrangements, financial resources, and operating systems.

UK firms planning to serve EU customers face an additional constraint. The MiCA transition period has ended, so access to the European market now requires the appropriate authorisation.

Management teams may therefore need to consider which services will be offered in each market, which legal entity will provide them, and whether the existing platform can support that structure. Customer accounts, transaction records and management reporting must be clearly attributed to the relevant regulated entity.

A broad product roadmap may have limited value if the supporting controls are not sufficiently developed. In many cases, a more focused proposition, supported by reliable records and a workable operating model, will provide a stronger basis for authorisation and subsequent growth.

Investing involves risk and your investment may lose value. Past performance gives no indication of future results. These statements do not constitute and cannot replace investment advice.