MiCA License in Malta

The first requirement is correct legal scoping. The applicant must identify which crypto-asset services are actually being provided under Regulation (EU) 2023/1114 and whether the model also touches other regimes such as EMT issuance, ART issuance, MiFID II, e-money, or payments.

• Typical in-scope models include custody, exchange of crypto-assets for funds, exchange of crypto-assets for other crypto-assets, execution of orders, reception and transmission of orders, placement, transfer services, advice, portfolio management, and operation of a trading platform;
• White-label structures, OTC desks, and broker-style flows often require deeper perimeter analysis than founders initially expect;
• Some software-only or genuinely decentralized models may fall outside CASP authorization, but this must be assessed case by case.

Incorrect scoping is one of the most common reasons applications stall, because every later document depends on the exact service perimeter.

Under Article 67 MiCA, a CASP must maintain prudential safeguards at least equal to the higher of the applicable Annex IV minimum (€50,000, €125,000 or €150,000) and one quarter of the preceding year’s fixed overheads. A provider operating for less than one year uses projected fixed overheads for its first 12 months. The safeguards may consist of qualifying own funds, an insurance policy or comparable guarantee meeting Article 67, or a combination of these.

Class 1 (€50,000): execution, placing, transfers, reception/transmission, advice and portfolio management. Class 2 (€125,000): Class 1 services plus custody or exchange against funds or other crypto-assets. Class 3 (€150,000): Class 2 services plus operation of a trading platform. The highest applicable class determines the Annex IV minimum.

Capital must be paid up in fiat, not in crypto-assets. In practice, the MFSA also reviews whether the business has enough liquidity to survive the first 12 months, so minimum capital alone is not enough for approval.

The applicant normally needs a Maltese legal entity registered through the Malta Business Registry (MBR), a registered office, and credible local substance. A letterbox structure is not sufficient for a serious MiCA License in Malta.

• The MFSA expects effective mind and management, not merely outsourced administration;
• Board meetings, strategic decisions, and oversight should be demonstrably anchored in Malta;
• The local setup should match the scale and complexity of the business model;
• Where critical functions are outsourced, the applicant must still retain control, monitoring, and escalation capacity.

Substance is assessed qualitatively. A small no-custody advisory model may justify a lighter setup than a custody or platform business, but both still need real governance and decision-making capacity.

A CASP applicant must appoint directors and key function holders who can pass fit-and-proper assessment. The regulator looks at competence, integrity, reputation, time commitment, conflicts of interest, and ability to understand the actual crypto business model.

• Typical roles include board directors, MLRO, compliance officer, risk function, and where proportionate, internal audit;
• Nominee-style appointments without real involvement are a red flag;
• Excessive role concentration can raise segregation-of-duties concerns;
• Shareholders and controllers may also be reviewed, especially where qualifying holdings are involved.

Documentation usually includes CVs, references, police conduct certificates, questionnaires, proof of qualifications, and evidence of relevant crypto, payments, securities, or AML experience.

A Malta CASP operates under both MiCA and AML/CFT expectations. The FIAU remains central for AML supervision, and the applicant must show a business-wide framework that is tailored to its actual products, customers, geographies, and transaction patterns.

• Required controls usually include customer risk scoring, CDD/EDD, PEP screening, sanctions screening, ongoing monitoring, suspicious transaction reporting, and recordkeeping;
• Crypto transfer flows must be aligned with the Transfer of Funds Regulation and Travel Rule data requirements;
• Source of funds and source of wealth checks are especially important for founders, investors, and high-risk clients;
• Generic AML manuals copied from non-crypto sectors are usually easy for the regulator to detect.

In 2026, the operational AML stack often includes blockchain analytics, case management, alert escalation logic, and structured Travel Rule messaging such as IVMS101-compatible data exchange.

A MiCA license in Malta requires more than a short IT policy. The regulator will expect a coherent technology architecture, access control model, incident handling process, and outsourcing governance framework proportionate to the services offered.

• Custody models should address wallet segregation, key management, privileged access, transaction authorization, reconciliation, and recovery procedures;
• Common control concepts include HSM, MPC, multisig governance, penetration testing, logging, and vendor due diligence;
• Operational resilience should define escalation paths, incident classification, business continuity, and measurable RTO/RPO targets;
• The broader compliance environment may also intersect with DORA expectations depending on the entity’s classification and ICT dependency model.

Weak technical documentation is a frequent cause of delays, especially where the business claims institutional custody or high-volume exchange capability.

The application file must show that the business is commercially coherent and operationally controllable. The MFSA will review whether the applicant understands its revenue drivers, cost base, risk exposures, and outsourcing dependencies.

• The business plan should describe services, target markets, onboarding channels, customer categories, complaints handling, and growth assumptions;
• Financial projections should usually cover at least 3 years and reconcile with staffing, capital, and compliance costs;
• Every critical outsourced function should be mapped, with service providers, SLAs, oversight controls, audit rights, and exit plans;
• Over-reliance on third parties for compliance, technology, and management simultaneously often triggers deeper scrutiny.

A strong application file reads like an operating model, not a marketing deck. That distinction matters in Malta.

Where the business touches client assets or client orders, safeguarding arrangements must be demonstrable, not theoretical. The applicant should explain how customer crypto-assets, fiat balances, records, and entitlements are segregated and how errors are detected and remediated.

• Custody providers should document wallet segregation, reconciliation frequency, incident response, and recovery governance;
• Exchange and platform models should explain order handling, execution logic, conflicts management, and market abuse controls;
• Complaints procedures should include intake channels, classification, response timelines, escalation, and board reporting;
• Client disclosures must be consistent with the real risk profile of the service.

Applications often fail on this point when the legal documents promise protections that the actual technology stack cannot deliver.