MiCA Authorisation and Technology Readiness

MiCA authorisation is now the baseline condition for offering crypto-asset services in the European Union. Since the framework came into full application and its transitional window closed, a firm that provides these services to EU clients is expected to hold authorisation as a crypto-asset service provider, or CASP, granted by a national competent authority in a member state. Authorisation is not a document a firm obtains and files away; it is a description of how the business will operate, and a large part of that description is about technology.

The point that is easy to miss is that much of a MiCA authorisation is an account of systems and controls. A competent authority assessing an application wants to understand how the applicant will custody client assets, screen customers, monitor activity, keep records, protect its systems and recover from disruption. These are engineering and operational questions before they are legal ones, and the quality of the answers depends on how the platform has been built rather than on how the policies have been written.

This article looks at MiCA authorisation through the lens of technology readiness: what a competent authority expects an applicant’s systems to be able to do, why those expectations are better met by design than by retrofit, and how they connect to the operational-resilience and anti-money-laundering obligations that apply alongside MiCA. It stays at the level of architecture and evaluation. It describes what an authorised CASP has to be able to demonstrate, not how to build any particular component.

What MiCA Authorisation Means Now

Under MiCA, providing crypto-asset services in the European Union—operating a trading platform, exchanging crypto-assets, executing or transmitting orders, or holding assets in custody, among others—requires authorisation as a CASP. That authorisation is granted by the national competent authority of the member state in which the firm is established, following an assessment of the applicant’s governance, controls and systems. The European Securities and Markets Authority does not authorise individual providers; it maintains the Union-level registers that record who has been authorised, drawing on the information competent authorities supply. A firm therefore applies to a national regulator, but operates within a common European framework.

The timing matters. The MiCA transition has ended. New EU cryptoasset projects must be designed for an authorised CASP operating model from the beginning. There is no longer a grace period in which a provider can operate while its authorisation is prepared; the authorised model is the starting point, not a later milestone. For a new platform this means the systems, controls and records that authorisation depends on have to be part of the initial design. For an existing provider it means the same capabilities have to be demonstrably in place rather than planned.

It is also worth being precise about what authorisation is not. It is not a certification of a particular piece of software, and no platform can be described as MiCA certified. It does not guarantee that a firm can passport its services across the Union without meeting the conditions attached to that process. And selecting a member state in which to seek authorisation is a question of substance and operating model, not of finding the most permissive jurisdiction. What a competent authority ultimately assesses is whether the firm—its people, processes and technology together—can operate the services it seeks to offer in a controlled and supervisable way.

Why Authorisation Is a Technology Question

An application for CASP authorisation is, in large part, a structured description of how the firm’s systems work. The applicant has to explain how client assets are held and segregated, how customers are identified and screened, how orders are handled, how records are kept and retained, how information is protected, and how the service continues to operate through disruption. Each of these is answered by the architecture of the platform. A description that is not backed by systems capable of doing what it claims is difficult to sustain, because supervision increasingly tests the capability rather than the statement.

This is why readiness is better built in than retrofitted. A platform designed from the outset to segregate client assets, produce reconcilable records, screen customers and log activity can describe those capabilities honestly and evidence them on request. A platform that treated these as features to be added later can often be brought into line, but usually at greater cost and with weaker evidence. The distinction becomes sharper once a firm is authorised, because an authorised CASP is expected to operate resiliently and controllably from its first day of activity, without a separate runway to mature its systems.

The Dimensions of Technology Readiness

Technology readiness for MiCA authorisation can be organised into a small number of dimensions. None of them is a product to be purchased in isolation; each is a capability the platform has to possess and sustain. Setting them out this way helps a firm evaluate whether a platform—built in-house, licensed, or delivered as a bespoke system—can actually support the controls that authorisation and ongoing supervision require.

These dimensions are interdependent. Custody records are only trustworthy if reconciliation and record-keeping are sound; screening is only effective if the onboarding system enforces it; resilience and security underpin all of the others. A platform that is strong in one dimension and weak in another is not partially ready; a supervisor assesses the whole. Treating readiness as a coherent property of the platform, rather than a checklist of separate tools, is what makes an authorisation credible and sustainable.

Custody, Segregation and Client-Asset Records

Custody is where MiCA’s expectations are most concrete for many CASPs. A provider that holds client crypto-assets is required to keep them segregated from its own and to maintain records that identify what belongs to each client at any point in time. This is not only a matter of using separate wallets; it is a records discipline. The platform has to link customer-facing balances, its internal ledger, and the on-chain or custodial holdings that back them, and it has to be able to demonstrate that these line up. A provider that segregates assets but cannot continuously prove the segregation has a records problem, not merely an operational one.

The same discipline connects custody to the wider platform. Whether a firm operates its own crypto exchange and custody platform or integrates external custody, the requirement to keep complete, identifiable and reconcilable client-asset records is constant. Reconciliation of custody records—comparing the internal record against what is actually held—is what turns segregation from an assertion into a demonstrable control, and it is one of the capabilities a competent authority expects an applicant to have engineered rather than improvised.

Where MiCA, DORA and AML Requirements Meet

MiCA authorisation does not sit on its own. An authorised CASP is a financial entity for the purposes of the European Union’s digital operational resilience framework, DORA, which means the systems that deliver crypto-asset services are subject to supervised expectations on ICT risk management, incident handling, resilience testing and the oversight of critical technology suppliers. These apply proportionately—a smaller provider carries lighter expectations than a large multi-asset platform—but no authorised CASP is outside them. Designing for authorisation therefore means designing for operational resilience at the same time, because the two are assessed on the same systems.

Anti-money-laundering obligations run alongside both. A CASP is expected to identify and screen its customers, monitor activity and screen crypto-asset transactions and wallets, which is why identity verification and screening are treated here as a readiness dimension rather than an afterthought. Firms building these controls can approach them as connected systems—identity verification and AML screening feeding the same onboarding and monitoring workflow—rather than as isolated tools. Across all three areas, the boundary of what a technology partner can do should be stated plainly. We do not provide legal opinions or guarantee authorisation. We implement regulatory and audit requirements across technology, infrastructure and operations. The interpretation of the framework and the authorisation decision remain, respectively, matters for qualified advisers and the competent authority.

What an Authorisation-Ready Platform Looks Like

A platform that is ready to support a MiCA authorisation shares a recognisable set of characteristics. It segregates client assets and can identify and reconcile each client’s holdings on demand. It builds identity verification and screening into onboarding and ongoing monitoring. It keeps complete, retainable records of activity and can reproduce them as evidence. It is engineered to operate resiliently and to recover from disruption, with security and access control designed in rather than added around the edges. And it supports the customer-facing obligations—disclosure, conflict management, complaint handling—as functioning systems rather than statements of intent.

None of this is achieved by acquiring a single component. Authorisation readiness is a property of how custody, records, onboarding, resilience and security are organised and maintained as the platform evolves. Firms structuring this work can review our perspective on EU regulatory readiness, and, where the question is how to sequence and design the underlying architecture, our fintech architecture advisory sets out how these capabilities fit together.

Summary and Next Steps

MiCA authorisation is, to a large degree, an account of technology. A competent authority grants it, ESMA records it, and the firm sustains it—but what all three depend on is a platform that can custody client assets, screen customers, keep records, protect itself and keep running. Because the transition has ended, these capabilities have to be present from the start rather than promised for later, and because DORA and anti-money-laundering obligations apply to the same systems, readiness is best treated as a single, coherent design goal rather than a series of separate compliance tasks.

Firms planning or reviewing a platform can begin with the architecture and the evidence it can produce, rather than with individual tools. Our view of regulatory readiness sets out how technology, infrastructure and operations come together to support authorisation and the supervision that follows.