A Programme of Operations can look like another item on the MiCA application checklist.
That is how applicants often treat it. They prepare the business plan, describe the products, add a few paragraphs about the target market and move on to the next document.
The problem is that the Programme of Operations is not there to make the business look ambitious. It is there to show how the regulated operation will function once authorisation has been granted.
That difference matters.
A business plan usually explains growth, revenue and investment. A Programme of Operations has to connect those ambitions with the people, systems, services and controls that will support them. It should explain what the CASP will actually do, for whom, in which markets and through which operating structure.
When those parts do not fit together, the problems beyond the Programme of Operations start to arise. The regulator may begin to question whether the applicant understands their business at all.
What the regulation requires
Article 62 of MiCA requires an application for CASP authorisation to include a Programme of Operations. The applicant must describe the crypto-asset services it intends to provide and explain where and how those services will be marketed.
Commission Delegated Regulation (EU) 2025/305 provides the detailed requirements. The programme must cover the three years following authorisation and address the applicant’s organisational structure, its strategy for providing services to its targeted clients and its operational capacity.
This is more than a request for a list of products.
The document should help the competent authority understand:
- Which services the CASP will provide.
- Which customers it intends to serve.
- Where those customers are located.
- How the services will be marketed.
- Which entity will perform each part of the operation.
- How the business will develop during the first three years.
- Whether the applicant has the capacity to support that development.
The Commission’s implementing regulation also includes the standard application form for CASPs. The Programme of Operations is therefore part of the formal authorisation process, not a supplementary presentation prepared for context.
The authority will read it alongside the rest of the application. That is where inconsistencies become difficult to hide.
It is not a pitch deck
The Programme of Operations may contain information that also appears in a business plan, but the two documents do serve different purposes.
A business plan is about revenue, customer acquisition, pricing, market size and investment. Its central question is usually whether the company can grow into a viable business.
The Programme of Operations asks how the regulated business will function.
If an applicant says it wants to provide custody, exchange, execution, transfer, advice and portfolio-management services, the programme should explain how those services will be delivered. It should not simply list them and leave the operational detail to other parts of the file.
A regulator may ask:
- Which service will be available on the first day?
- Which customers will be accepted at launch?
- Which entity will contract with those customers?
- Who will execute orders?
- Who will control customer assets?
- Which functions will be outsourced?
- Which employees will perform the key tasks?
- How will the control framework change as activity increases?
These are not questions about the quality of the company’s presentation. They are questions about whether the proposed business can operate safely.
A Programme of Operations that reads like an investor presentation may therefore create more doubts than confidence. Growth claims are easy to make. Explaining who will perform the work is more demanding.
The three-year horizon
The requirement to cover three years following authorisation changes the character of the document.
The applicant must describe more than the opening-day model. It must explain how the business expects to develop, while recognising that growth will place additional pressure on its controls.
The sequence matters.
What will happen during the first year? Which customers will be accepted? Which Member States will be targeted? Will the firm launch with one service or several? When will additional products become available? What needs to be in place before the company increases its customer base?
A credible programme should not treat expansion as a straight line on a forecast. More customers change the workload of onboarding, customer support, transaction monitoring, complaints handling and compliance.
More jurisdictions may require additional languages, procedures and local expertise. More products may introduce conflicts of interest or new customer-protection issues. More transactions may require additional monitoring capacity.
The programme should show how the company intends to respond.
That does not mean predicting every future development. It means explaining the assumptions behind the plan and showing that the applicant understands the operational consequences of its own growth strategy.
A company that plans to enter ten Member States may not need ten local offices. It should, however, explain how it will serve those markets, where management and compliance will be located, how customers will be supported and how the firm will remain within the scope of its authorisation.
Services must be described precisely
A common weakness is to describe services in broad commercial terms.
A company may refer to its platform as an exchange, marketplace, broker or wallet. Such labels, however, do not really explain what happens when a customer uses the service.
Consider a customer placing an order. Does the platform merely bring buyers and sellers together? Does it receive and transmit the order? Does it execute the order itself? Does it take the other side of the trade? Does it hold assets during settlement?
The answer may determine which MiCA services are being provided and which controls are needed.
A platform may describe itself as non-custodial, but the practical question is who can control the assets. If the customer needs the platform’s approval to make a transfer, or the platform can restrict wallet access or stop the assets from being moved, the arrangement may involve custody-related control despite the label.
The Programme of Operations should describe the mechanics of the service rather than repeat the language used by the marketing team.
This is particularly important where the firm is seeking authorisation for several services. The applicant should explain how they interact and where conflicts may arise.
For example, a company that provides execution and advice may need to explain how it avoids recommending products that benefit its own trading operation. A company that provides custody and exchange may need to describe how it protects customer assets while operating a trading platform.
The more services included, the more work is needed to show that the model is controlled.
ESMA’s supervisory briefing identifies applicants seeking several CASP services as deserving greater attention because multiple services can increase complexity and create conflicts.
A narrower application is not necessarily a weaker application. It may be easier to understand, supervise and support with the resources available.
Target customers shape the operation
The Programme of Operations should identify the customers the CASP intends to serve.
A business targeting retail customers will have different operational needs from one serving professional investors or institutional clients. The difference affects onboarding, support, communications, transaction monitoring and complaints handling.
It also affects the financial forecast.
A company that expects to serve high-volume institutional traders may need a different technology and support model from one serving occasional retail users. A firm offering custody to professional clients may need different controls from a platform that provides transfers without holding assets.
The programme should explain the target customer in practical terms rather than relying on broad categories.
What type of customer is the firm seeking? Which products will they use? How will they be onboarded? What jurisdictions will they come from? How will the CASP decide whether a particular customer falls within its risk appetite?
These details should be compatible with the AML framework.
If the Programme of Operations describes a carefully limited customer base, but the marketing strategy uses affiliates and online campaigns capable of reaching customers throughout the EU, the applicant may have to explain which model it actually intends to operate.
Marketing is part of the regulatory picture
Marketing is easy to treat as a separate commercial issue. The company may expect to adjust its campaigns later, once the product is live and the first results are available.
For a MiCA applicant, that separation is not so simple. The Programme of Operations must explain how the firm expects to attract customers and which channels it plans to use. The delegated regulation refers to websites, apps, social media, online advertising, influencers, sponsorships, webinars, affiliates, demo accounts, gamification and educational content.
Those choices give the regulator an indication of how the business will reach the market.
A campaign aimed at professional investors is different from one built around retail influencers. An affiliate network may reach customers in countries the applicant has not mentioned elsewhere. A mobile app promoted through online advertising may create a much broader customer base than the company’s operational and AML arrangements were designed to support.
The marketing plan should fit the business described elsewhere in the application. It should show which markets the firm intends to reach, who it expects to bring on as customers and whether its staff, onboarding process and monitoring systems are ready to handle that activity.
A campaign conducted in several languages may reach customers in Member States the applicant did not mention elsewhere. An affiliate arrangement may create questions about oversight and customer communications. Influencer marketing may reach retail customers in a way that differs from the controlled institutional strategy described in the business plan.
The applicant should therefore be able to explain:
- Which markets will be targeted.
- Which languages will be used.
- Which channels will be used.
- Whether external affiliates will be involved.
- How promotional content will be approved.
- How the firm will prevent marketing outside its intended scope.
- How marketing activity will affect customer onboarding and AML risk.
The Programme of Operations does not need to contain every future campaign. It should, however, give an honest account of the distribution model that will create the customer base.
The connection with AML
Same goes for AML. The customer-acquisition strategy cannot be separated from the AML framework.
A firm targeting customers across several Member States may face different customer and jurisdictional risks from a firm operating in one market. A platform marketed through affiliates may need additional oversight of how customers are referred. A company offering rapid transfers or high-volume trading may need more sophisticated transaction-monitoring arrangements.
The Programme of Operations should provide the context in which those controls operate.
Suppose the applicant expects to acquire customers through online advertising and affiliate partnerships. The AML framework should identify how those customers will be screened, how their risk will be assessed and whether particular jurisdictions or customer categories will be restricted.
The staffing plan should identify who reviews alerts. The technology documents should identify the tools used for screening and monitoring. The governance structure should explain who receives reports and who can take action.
No single document needs to repeat the entire process. They do need to describe compatible businesses.
This is one reason why a Programme of Operations can become a useful test of the application as a whole. It gives the regulator a clear account of the proposed activity and allows that account to be compared with the controls supporting it.
The group structure cannot be left vague
Many CASPs operate as part of a wider group.
The applicant may rely on a parent company for technology, liquidity, marketing, customer support, compliance or product development. That is not automatically unacceptable. It does mean that the Programme of Operations should explain how those relationships affect the applicant’s activities.
The authority will need to know which entity performs each function and which entity remains accountable.
A useful description might explain that the EU applicant contracts with customers and retains responsibility for compliance, while a group company provides specified technology under a written outsourcing agreement. It should then identify who monitors the provider, who receives incident reports and who can require changes.
A vague statement that “the group provides support” is unlikely to be enough.
The same issue arises where the parent company controls the product roadmap or approves major commercial decisions. The applicant should explain how its own management body can exercise responsibility for the regulated operation.
ESMA’s supervisory material warns against outsourcing arrangements that turn the CASP into a letter-box entity. The applicant must retain sufficient expertise and authority to supervise critical functions and remain capable of being supervised itself.
The Programme of Operations should therefore reflect the real allocation of control. It should not present the EU entity as independent if the important decisions are made elsewhere.
Outsourcing and operational capacity
Outsourcing can support a smaller CASP, but it does not remove the need for internal knowledge.
A provider may operate the cloud infrastructure, carry out customer screening or support the custody function. The applicant still needs to understand what the provider does, monitor its performance and act when the service fails.
The Programme of Operations should identify the role of important providers and explain how they fit into the operational model.
For a critical function, the applicant should know:
- What the provider is responsible for.
- What information and systems it can access.
- Who inside the CASP supervises it.
- How performance is measured.
- How incidents are escalated.
- Whether subcontracting is permitted.
- How the arrangement can be terminated.
- How customers would be protected during a transition.
A provider may be able to perform the task. That does not necessarily show that the applicant has operational capacity if nobody inside the applicant can assess the provider’s work.
This is particularly important for technology, custody and transaction monitoring. A failure in any of those areas may affect customers immediately. The Programme of Operations should show that the firm has considered failure rather than assuming that providers will always be available.
Governance must match the programme
The organisational structure described in the Programme of Operations should be consistent with the governance documents.
If the programme says that the compliance officer reports to the board, the organisation chart and internal policies should reflect that. If it refers to a risk committee, the application should explain who sits on the committee, what decisions it can make and how those decisions are documented.
The authority may ask what happens when commercial interests conflict with risk controls.
Can compliance delay a product launch? Can risk reject a customer? Can the board override a recommendation? If it does, how is the decision recorded and reviewed?
The applicant does not need to claim that conflicts will never arise. It needs to show that it has considered them and has arrangements for managing them.
The Programme of Operations should also distinguish between group standards and local responsibility. A parent company may provide a group policy, but the EU CASP remains responsible for applying it to its own customers and services.
A document that attributes every important task to the parent company may create the impression that the applicant has not retained enough control.
The financial plan has to support the operation
The Programme of Operations is not a financial forecast, but the two cannot be separated.
Every operational promise has a cost.
A firm offering multilingual support needs staff or a provider capable of delivering it. Continuous monitoring requires technology and review capacity. Custody requires security arrangements, access controls and incident response. Expansion into additional markets may require more compliance, legal and operational resources.
Those costs should appear in the financial plan.
If the Programme of Operations assumes that the company will hire several compliance and support employees during the first year, the forecast should fund those hires. If the business depends on providers, the relevant fees should appear in the budget. If the firm expects to enter new jurisdictions, the plan should reflect the costs of doing so.
The reverse is also true. A financial forecast can reveal that the Programme of Operations is too ambitious.
A company may project substantial customer growth while allocating almost no additional cost to compliance, monitoring or support. It may be relying on revenue that will arise only if the business launches services for which it does not yet have the necessary systems.
That is not necessarily an accounting error. It may indicate that the operating plan has been prepared separately from the commercial model.
How it differs from a business plan
The Programme of Operations and business plan should not be identical.
The business plan may contain detailed financial modelling, pricing assumptions, revenue projections and investment information. The Programme of Operations would use that material to explain how the regulated service would be delivered.
For example, the business plan may forecast a particular number of customers by year three. The Programme of Operations should explain what that means for onboarding, monitoring, customer support, complaints and technology.
The business plan may identify institutional customers as the main source of revenue. The programme should explain how those clients will be onboarded, which services they will use and whether retail customers will also be accepted.
The business plan may assume expansion across several Member States. The programme should identify those markets and describe how the services will be marketed there.
The documents should not copy one another. They should describe compatible parts of one business.
When the story stops matching
A Programme of Operations becomes most valuable when it is compared with the rest of the application.
The applicant may describe a limited launch in one Member State, while the marketing section refers to an EU-wide campaign. The AML framework may accept customers from jurisdictions not mentioned in the programme. The technology section may rely on a provider that does not appear in the outsourcing documentation. The staffing plan may assume that a key manager will be appointed later.
Each inconsistency creates a new question.
The company may have to change the customer scope, delay the launch or add staff before authorisation. It may also need to revise the financial forecast, risk assessment and governance arrangements.
This is why the programme should be reviewed alongside:
- The AML and customer-risk framework.
- The governance and organisation charts.
- The outsourcing register.
- The ICT and security documents.
- The custody arrangements.
- The complaints procedure.
- The financial forecast.
- The marketing strategy.
- The group structure.
- The wind-down plan.
The problem is not that every section must use exactly the same language. The problem is when different sections describe different businesses.
The danger of overpromising
Some applicants believe that a broader programme will make them look more capable.
It can have the opposite effect.
A company that intends to provide every major CASP service, serve customers throughout the EU, support a wide range of assets and grow rapidly is inviting detailed questions about management, systems and capital.
The issue is not ambition. It is whether the sequence makes sense.
A firm may plan to expand across the EU while beginning with one customer group and a limited number of markets. It may intend to introduce custody after it has hired the necessary staff and completed system testing. It may reserve certain services for a later stage when the governance structure is ready.
That approach can be more persuasive than presenting the eventual end-state as if it already exists.
A carefully limited first phase gives the authority something specific to assess. It also gives the applicant a realistic opportunity to demonstrate that the controls work before activity increases.
A programme the regulator can test
The Programme of Operations should allow the competent authority to test the applicant’s assumptions.
If the applicant says it will target professional clients, the authority can ask how those clients will be identified and onboarded. If it plans to use affiliates, the authority can ask how those relationships will be monitored. If it intends to provide custody, the authority can ask who controls the assets and what happens during an incident.
The applicant should be able to answer without creating a new version of the business.
That is the real standard. The programme does not need to predict everything that will happen over three years. It needs to provide a credible basis for supervision.
The three-year plan will not unfold exactly as written. The firm may find demand in a different market or delay a product launch. What matters is whether the original assumptions were sound and whether management can assess the consequences before changing course.
What matters is whether the assumptions were reasonable, if the company understood the risks and that it has governance for managing changes.
Preparing the document
The drafting should begin with the operating model rather than with a blank template.
Start with the customer journey. For each service, identify the customer, the entity, the system, the staff member and the provider involved. Then introduce a problem. A customer triggers an alert. A withdrawal fails. A critical vendor becomes unavailable. A complaint is escalated.
Who has the information? Who makes the decision? How is the outcome recorded? Which customers are affected?
The answers should be reflected in the Programme of Operations and the supporting documents.
Next, divide the first three years into stages. Identify which services and markets belong to the initial launch and which depend on future hiring, testing or capital. The company should be able to explain why the sequence is realistic.
Then compare the programme with the business plan, AML framework, governance documents, outsourcing arrangements and financial forecast.
Finally, remove claims that cannot be supported.
A simple programme that describes a business the applicant can actually run will usually be more persuasive than a sophisticated document promising services, markets and growth that the organisation is not prepared to support.
The point of the Programme of Operations
The Programme of Operations is easy to mistake for a formal version of a pitch deck. It is not.
The company is not being asked to describe how large it hopes to become or list every product it might launch in the future. The document should give a clear account of the regulated business at the point of authorisation, together with a realistic explanation of how that business will develop.
That means being specific about the services, the customers, the markets and the people responsible for running the operation. It also means showing how the firm will keep those activities under control as volumes increase, new products are introduced or the business enters additional jurisdictions.
This is why the Programme of Operations reaches into almost every other part of the application. The services described in it should match the customer journey. The target market should make sense alongside the AML framework. The staffing plan should support the growth forecast. The outsourcing arrangements should reflect where the important work is actually being performed.
When those documents describe the same business, the regulator can follow the applicant’s reasoning. When they do not, the gaps become difficult to explain.
A shorter programme is not necessarily a better one, and a long programme is not necessarily more convincing. The useful document is the one that describes an operation the applicant can run on the day authorisation is granted and still control as it grows.
That is the real purpose of the Programme of Operations. It turns a proposed business into something the regulator can examine in practical terms.
Sources:
- Regulation (EU) 2023/1114, Article 62
- Commission Delegated Regulation (EU) 2025/305
- Commission Implementing Regulation (EU) 2025/306
- ESMA, Supervisory Briefing: Authorisation of CASPs under MiCA ‘
CASP in Europe
