MiCA-Ready Exchange Architecture

MiCA-ready describes an exchange whose architecture can evidence the requirements that apply to an authorised crypto-asset service provider, rather than a platform that has acquired a label. The Markets in Crypto-Assets framework has been in full application since 30 December 2024, and the transitional arrangements that allowed firms to trade under national regimes have now closed. The question a new venue faces is therefore not whether the framework applies, but whether its systems can demonstrate the controls the framework assumes are already in place.

The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. A platform assembled first and reconciled with the requirements afterwards inherits a remediation programme before it has taken a single order; a platform designed around the operating model produces most of the evidence an application requires as a by-product of operating normally.

This article sets out what MiCA-readiness means at the level of architecture: how custody, trading, financial-crime controls and resilience are structured so that a national competent authority, an external auditor or the venue'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 MiCA-Ready Means for Architecture

Readiness is frequently misread as a certificate. There is no such thing as a MiCA-certified platform, and authorisation is not granted by ESMA directly; it is granted by a national competent authority in the member state where the provider establishes itself, with ESMA maintaining the public register of authorised firms. MiCA-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 functions while only one can show, on request, how client assets are segregated, how an order was handled, or who approved a configuration change. The architecture that can produce those answers without reconstructing them after the fact is the one that carries a defensible claim to being MiCA-ready.

The CASP Operating Model as a Design Baseline

A crypto-asset service provider is authorised for specific services, and each service it offers carries its own obligations. Operating a trading platform, providing custody, exchanging crypto-assets for funds and executing orders on behalf of clients are distinct activities with distinct controls, and the combination a venue intends to offer defines the operating model its architecture must support. Selecting that combination late, after the platform has been built around a narrower assumption, is one of the more expensive corrections a project can make.

Because the transitional window has closed, there is no grandfathered route through which a venue can begin trading and align later. The governance the framework expects — a clear allocation of responsibilities, the separation of incompatible duties, and named accountability for control functions — has to be expressed in the platform itself, through role and permission design, approval workflows and the segregation of who can trade, who can move assets and who can change the system. These are architectural decisions before they are policy statements.

Custody and Client-Asset Segregation

Where a venue holds crypto-assets or funds for clients, the framework requires those holdings to be protected and kept separate from the firm's own resources. At the level of architecture this translates into a wallet and ledger design that keeps client positions segregated, reconciles them continuously against on-chain balances and internal records, and constrains who can authorise movement of assets. The distribution of holdings across hot, cold and multisig arrangements is a control decision, not merely an operational one, because it determines how exposure is limited and how withdrawals are approved.

The evidence such a design must produce is specific. It should be possible to demonstrate, at any point, that recorded client 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 and signing thresholds 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.

Orderly Trading and Market Integrity

Operating a trading platform brings obligations that reach into the core of the venue. Trading has to proceed under transparent and consistently applied rules, orders and their handling have to be recorded, and the platform has to support the detection and reporting of behaviour that could constitute market abuse. Architecturally this connects the matching layer, the market-data layer and the surveillance layer: the venue must be able to reconstruct how any order was received, prioritised and executed, and to surface patterns that warrant investigation.

Market integrity also depends on the management of conflicts of interest, which acquires an architectural dimension where a venue trades on its own account, operates a related liquidity function or lists assets in which it has an interest. The controls that separate these activities, and the records that show they were separated, form part of the same evidence base an authorisation review examines. A platform whose order lifecycle and surveillance output cannot be exported and explained is difficult to defend under supervision, whatever its performance characteristics.

Financial-Crime Controls and the Travel Rule

An authorised venue operates within the anti-money-laundering regime as well as the market framework, and the two are increasingly supervised together. Customer due diligence at onboarding, ongoing monitoring, sanctions and PEP screening, and the obligation to accompany crypto-asset transfers with originator and beneficiary information under the Travel Rule are all part of the operating model. The European anti-money-laundering authority is now operational and EU-level supervision is beginning to consolidate, with a single rulebook taking effect over the coming period, so an architecture designed for the current baseline should anticipate tighter and more uniform expectations rather than the fragmented regime it replaces.

For architecture the requirement is integration rather than adjacency. Identity verification and screening cannot sit in a disconnected tool whose results are re-keyed by hand; they belong in the onboarding and transaction flows, with outcomes recorded against the customer and the transaction so that a reviewer can see why an account was accepted or a transfer was held. The design considerations behind these controls are set out under AML screening software and KYC verification software.

Operational Resilience and Third-Party Risk

A MiCA-ready venue also has to satisfy the operational-resilience expectations that now apply across EU financial entities. DORA has applied since 17 January 2025 and treats resilience as something to be tested and evidenced: information-and-communication-technology risk management, incident handling and reporting, resilience testing, and the oversight of critical third parties are all in scope. For an exchange this reframes availability from an operational aspiration into a control that must be exercised, measured and shown to work.

Third-party dependency is the point where resilience and architecture meet most directly. Where custody, hosting, matching or screening are provided by external parties, those providers form part of the venue's control environment, and the framework expects assessment, testing and a workable exit plan rather than contractual assurance alone. A venue that cannot recover to a defined objective without a supplier's involvement, or that cannot leave a supplier without rebuilding, has a resilience gap that no document closes. Related engineering considerations are set out under regulatory readiness for the European Union.

Evidence and the Authorisation File

An authorisation review, and the supervision that follows it, test whether the venue can show what it claims to do. Each architectural domain therefore has a corresponding 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 above to the demonstration each one has to support.

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 CASP model in view. The broader planning perspective is described under crypto exchange software.

Summary and Next Steps

MiCA-readiness is not a badge applied to a finished platform; it is a property of an architecture that can segregate client assets, run an orderly market, integrate financial-crime controls, withstand disruption and evidence each of these on request. With the transitional period closed, that architecture is the starting condition for a new EU venue rather than a later refinement, 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 is in a position to evaluate providers against the operating model it actually has to satisfy, rather than against a feature list.