What Documents Does MiCA Require for CASPs?

A MiCA application does not fail because a firm omitted one template. It fails because the documents, business model, people and technical controls do not tell the same credible story. For founders asking what documents does MiCA require, the useful answer is not a generic checklist. It is a controlled evidence pack showing that the business can operate safely from day one.

For crypto-asset service providers (CASPs), MiCA authorisation is a regulator-facing build. National competent authorities will review the application under MiCA, but their practical expectations, filing portals and local forms can differ. The documents must therefore meet the Regulation's core requirements while being tailored to the authority in the Member State where authorisation is sought.

What documents does MiCA require for a CASP application?

The central document is the formal application for authorisation under Article 62 of MiCA. It is supported by a substantial set of corporate, operational, governance and compliance evidence. The exact volume depends on the services requested - such as custody, exchange, execution, portfolio management, advice, transfer services or operation of a trading platform - and on whether the applicant holds client crypto-assets or funds.

A complete pack normally addresses six areas: the applicant and its ownership, its programme of operations, governance and fitness of management, prudential and safeguarding arrangements, AML and conduct controls, and ICT resilience. A regulator should be able to trace each proposed service from the commercial plan through to the procedure, responsible person, system and testing evidence that support it.

Corporate and ownership documents

The authority will first establish who is applying and who ultimately controls the business. This generally includes the constitutional documents, certificate of incorporation, registered-office details, group structure chart and register of shareholders. Where there are qualifying holdings, applicants must identify the direct and ultimate owners, explain ownership percentages and provide information allowing the authority to assess their suitability.

For complex groups, do not submit a diagram that merely names holding companies. Explain decision-making rights, shareholder agreements, funding flows and any regulated or unregulated group entities. Opaque ownership is a frequent cause of avoidable regulator questions, particularly where overseas holding vehicles, nominee arrangements or recent share transfers are involved.

The application should also demonstrate that the applicant meets MiCA's prudential safeguard requirements. Depending on the service category, this may require evidence of own funds, qualifying insurance or a comparable guarantee, together with financial projections and assumptions. Capital should not be treated as a last-minute banking exercise. The regulator will consider whether the firm can fund its first operating period, meet its continuing obligations and absorb foreseeable losses.

Programme of operations and business plan

The programme of operations translates the commercial model into a regulated operating plan. It should specify the crypto-asset services sought, the types of crypto-assets involved, target customers, geographic reach, distribution channels, expected transaction volumes and the firm’s proposed commencement date.

It should also explain the complete customer journey. That includes onboarding, wallet creation where relevant, order placement, execution, settlement, asset or fund flows, reporting, complaints and offboarding. If the firm relies on group companies or third parties for customer support, liquidity, wallet infrastructure, screening or fiat payments, those roles need to be explicit.

Financial forecasts should be realistic and connected to the plan. A forecast that assumes rapid revenue growth but provides no customer acquisition strategy, staffing plan or technology capacity invites scrutiny. Conservative assumptions are often commercially preferable to a model that looks designed only to satisfy a minimum-capital calculation.

Governance documents MiCA expects

MiCA requires sound governance arrangements. In practice, this means more than appointing directors and producing a short organisational chart. The authority will expect a documented management structure with clear allocation of responsibilities, reporting lines, decision-making processes and internal controls.

Applications commonly include the following evidence:

• organisational chart, job descriptions and a responsibility matrix for key functions;

• CVs, identification, criminal-record disclosures where required, references and fitness-and-propriety declarations for directors and senior managers;

• board terms of reference, conflict-of-interest policy and records showing how independent challenge will operate;

• compliance, risk-management and internal-control policies, including monitoring and escalation procedures; and

• staffing plans showing that the local entity has sufficient substance and appropriately skilled personnel.

Management suitability is not a paperwork-only test. The authority will examine whether those directing the applicant collectively understand the services, technology, financial crime risks and legal obligations involved. A strong technical founder without regulatory experience can still be part of a credible application, but the governance design must close that gap with suitably qualified compliance, risk and operational leadership.

AML, conduct and customer-protection documentation

MiCA authorisation sits alongside the EU anti-money-laundering framework. A CASP must submit policies and procedures sufficient to show how it will prevent and detect money laundering and terrorist financing. The document set usually covers enterprise-wide risk assessment, customer due diligence, beneficial-owner verification, sanctions screening, politically exposed person controls, transaction monitoring, suspicious activity escalation, record keeping and staff training.

A generic AML manual purchased without reference to the actual product is poor evidence. For example, a custody provider, a fiat-to-crypto exchange and a decentralised-finance interface may each face different transaction patterns, wallet-risk indicators and reliance arrangements. The risk assessment and monitoring rules should reflect those differences.

Customer-facing documentation matters too. The authority will want to see how the firm meets MiCA conduct obligations, including fair, clear and non-misleading communications, transparent fees, conflicts management and complaint handling. Prepare client terms, disclosures, a complaints policy and register, marketing-approval controls, and procedures for recording and resolving customer issues.

Where services involve execution, advice or portfolio management, firms should also document how they assess client needs, manage conflicts, select execution venues or counterparties, and preserve records. The right documents depend on the permission perimeter. There is no benefit in producing policies for services the firm does not intend to offer, but omissions in a proposed service line are equally damaging.

Safeguarding, custody and operational-control evidence

Firms holding client crypto-assets or client funds face the highest evidential burden. The application must explain how customer assets are segregated from the firm’s own assets, how ownership records are maintained, and how assets can be returned promptly if the business fails.

For custody, expect to provide wallet architecture, key-management procedures, access controls, authorisation limits, reconciliation methodology, incident response and business-continuity arrangements. Regulators will examine whether hot, warm and cold wallet practices match the risk profile and whether private-key compromise, loss of access, employee fraud and third-party failure have been properly considered.

Where fiat funds move through payment institutions, banks or e-money institutions, describe the contractual flows and reconciliation controls in detail. A CASP should not imply it safeguards money where a separate regulated partner performs that function. Precise role allocation protects both the application and the operating model.

Outsourcing documentation is equally material. Cloud hosting, blockchain analytics, KYC vendors, custody technology, customer support and security operations can all be critical outsourced functions. The file should include an outsourcing policy, due-diligence records, service-provider risk assessments, materiality assessment, draft or executed agreements, audit and access rights, data-location information, exit plans and ongoing oversight procedures.

ICT and DORA documentation

Since DORA applies to CASPs, technology governance is not an annex to the legal application. It is part of the authorisation case. The regulator will expect evidence that the firm has identified critical systems, allocated ICT responsibilities and developed controls proportionate to its size, services and risk exposure.

The core file generally includes an ICT risk-management framework, information-security policy, asset inventory, access-management standards, vulnerability and patching procedures, logging and monitoring arrangements, incident-classification and reporting processes, backup and recovery plans, business-continuity plan, disaster-recovery testing, and third-party ICT risk controls.

The trade-off is proportionality. A small, limited-scope CASP does not need the same operating structure as a large exchange. It does, however, need demonstrable controls. Policies with no named owner, no implementation timetable and no testing record are unlikely to provide comfort.

Do you need a MiCA crypto-asset white paper?

Not every CASP applicant needs to prepare a crypto-asset white paper. White-paper duties concern offers to the public or admissions to trading of crypto-assets, and the requirements differ for asset-referenced tokens, e-money tokens and other crypto-assets. A firm applying solely to provide services may not be an issuer or offeror.

However, the distinction must be assessed carefully. A trading platform that lists assets, a group that issues a token, or a business combining exchange services with a token launch may trigger separate MiCA workstreams. The CASP authorisation documents should accurately identify these activities rather than leaving the regulator to infer them.

The fastest route to a credible MiCA filing is to map each permission against a written operating process, a responsible owner and evidence that the control works. That discipline reduces follow-up questions, protects the launch timetable and leaves the business with a compliance framework it can actually operate after authorisation.