Who gets MiCA-licensed, who fails, and why.

Three visible routes to success

1. Existing regulated financial entity adding narrow or equivalent crypto services. Banks, investment firms, EMIs/PIs, CSDs and AIFMs use Article 60 — but the notification still requires programme of operations, AML/CFT, ML/TF risk, BCP, ICT/security, segregation and custody-policy evidence, and the CASP cannot begin services while the notification is incomplete.^[S2]
2. Clean VASP-to-MiCA conversion with local substance and implemented controls. Moderate service scopes, recognisable domestic or EU operating history, alignment between product and service codes.
3. Large crypto-native platform with broad scope — but enough resources, local substance and remediation capacity to satisfy scrutiny. Visible in Malta, Luxembourg, Ireland, Austria and the Netherlands; carries higher host-NCA, investor-protection and supervisory-convergence risk.

Failure, delay and withdrawal are harder to observe because there is no public EU-wide rejection register. The strongest entity-level negative signals are MEXC in the Netherlands and LWEX in Slovakia — both regulatory-concern / non-authorised-operation cases, not proven rejected applications. AFM warned MEXC was operating without the required licence in the Netherlands and actively targeting Dutch consumers, with the entity location and legal entity unclear.^[S6] NBS said LWEX continued to provide crypto-asset services in Slovakia without appropriate authorisation and was entered under MiCA Article 110 into ESMA's non-compliant register.^[S14]

The blunt practical answer: weak applicants fail or stall because they ask the NCA to trust assertions. Successful applicants supply evidence. A CASP application is not a policy-writing exercise; it is a test of whether the business can operate exactly as described, under an identifiable EU entity, with real people, real systems, real capital, and auditable controls.

1. Benchmark dataset analysis

1.1 Jurisdiction distribution

Germany dominates numerically, but the German cluster is not a simple crypto-native exchange cluster — it is heavily influenced by banks, brokers, asset managers and investment-firm-style service scopes. Malta has a much higher average service breadth and a concentration of broad crypto-native exchange models. The Netherlands combines early authorisations with a large crypto-native and retail/broker base. France, Ireland and Luxembourg appear more institutionally selective.

1.2 Service-code distribution

Custody (a) and transfer services (j) are the dominant rails — present in 117 and 107 records respectively. Trading platform (b) is rare with only 14 records, and should be treated as a high-risk service: it brings order-book integrity, market abuse, operational resilience and conflicts-management issues. Advice (h) and portfolio management (i) are also relatively uncommon, reflecting suitability, conflict, competence and investment-process burdens.

1.3 Timing waves and scope breadth

The early wave starts in the Netherlands on 30 December 2024 and in Malta/Germany in January 2025. The large numerical wave is late 2025 — especially December 2025 (42 records) — coinciding with national transition pressure in several Member States. Lithuania's central bank publicly stated that its transition period ended on 31 December 2025 and that provision of crypto services without a MiCA licence after that date would be illegal financial activity.^[S10]

125 of 177 records are narrow (1–2 services) or moderate (3–4 services) scope. Only 5 records are very broad (8–10 services). This strongly supports a sequencing lesson: broad "everything-at-once" applications are the exception, not the norm, and tend to be associated with larger, better-resourced or already regulated applicants.

2. What separates success from failure

Across the positive-control population, successful applicants share at least one of four credibility anchors: pre-existing regulation; a recognisable VASP operating history; a narrow or coherent scope; and entity / perimeter clarity. The negative-signal population is the inverse — unclear legal entity and location, unauthorised activity during transition, incomplete or low-quality files, weak local substance, outsourcing that blocks effective supervision, and MiCA-washing where regulated and unregulated products are mixed on the same platform.^[S3][S12]

3. Article 60 vs Article 63 as success routes

Article 60 is not a shortcut for any fintech with a licence. It is a notification regime for specified financial entities and equivalent services. Credit institutions may notify crypto services; CSDs may notify custody; investment firms may notify equivalent investment services; EMIs are limited to custody and transfer services for their own EMTs; UCITS managers / AIFMs may notify equivalent portfolio / advice / RTO services; market operators may notify trading-platform operation.^[S2]

This means the positive-control register can overstate "new CASP licensing activity" where entries are actually notifications by existing regulated entities. It also means Article 60 applicants can still fail operationally if the notification is incomplete: the CASP cannot begin services while the notification is incomplete.^[S2]

4. Jurisdiction patterns — without lazy conclusions

• Germany — high activity, but much of the volume is regulated-financial-institution style and often narrow. The correct inference is not "BaFin is easy"; it is that Germany has a deep regulated banking / broker / custody ecosystem that can map crypto services onto existing governance.
• Netherlands — active early mover with crypto-native conversion and broker / exchange concentration. AFM says even a best-case CASP licence takes at least five months, longer where products / services are complex, high-risk or organisational changes are required.^[S5]
• France — credible mix of banks, institutional players and domestic crypto firms. AMF says original MiCA files are rarely complete and clarifications / substantial changes often cause additional delay.^[S9]
• Malta — clearly active for broad crypto-native platforms, but supervisory-convergence credibility is not costless. ESMA's peer review found MFSA's process only partially met expectations in a reviewed case.^[S11]
• Ireland — not a shortcut. CBI requires VASPs to go through the full CASP application process; timelines depend on preparedness, application quality and robust engagement.^[S7][S8]
• Lithuania — strong fintech / payment context, but large legacy VASP attrition. Bank of Lithuania cited 370+ declared crypto-service providers, 120 actually operating, ~30 applications and 10 under assessment.^[S10]

5. Applicant archetypes and probability

Translating the data into archetypes makes the decision sharper for any team planning an application. Probabilities below are calibrated against the positive-control population, regulator process statements, and the negative / weak-control dataset — not legal advice.

6. Hard blockers, delay factors, strategic mistakes

Hard blockers

1. Unclear group structure, legal entity, booking model, UBO chain or EU/offshore service perimeter.
2. Weak local substance and decision-making outside the applicant entity.
3. Unfit or uncredible management; unresolved adverse supervisory or enforcement history.
4. AML/CFT deficiencies — sanctions, blockchain analytics, transaction monitoring, Travel Rule, high-risk customer controls.
5. Custody / safeguarding failure: no segregation evidence, weak key governance, no reconciliation, unauthorised third-country custody dependency.
6. ICT/DORA resilience gaps and critical outsourcing that prevents effective supervision.
7. Insufficient own funds, liquidity, insurance or wind-down funding.
8. Misleading marketing or MiCA-washing — using authorisation to imply protection for unregulated products.
9. Incomplete Article 60 notification or Article 63 application pack.
10. Live high-risk products inconsistent with the proposed regulated perimeter.

Major delay factors

• Applying for a broad service set from day one.
• Combining trading platform, custody, exchange, transfer and advice / portfolio services.
• High retail exposure and aggressive cross-border marketing.
• Large token universe with weak listing / delisting controls.
• Cross-border or third-country outsourcing of ICT, custody, compliance or operations.
• Travel Rule or sanctions controls not live.
• Policies written but not evidenced through logs, MI, tests, reconciliations or board records.

Strategic mistakes

• Choosing jurisdiction for speed rather than substance, model fit and credibility.
• Treating MiCA as a legal form-filling exercise instead of an operating-model audit.
• Copying generic policy templates.
• Leaving the website / app / ToS inconsistent with the application perimeter.
• Keeping high-risk yield, lending, derivatives, staking or offshore services live for EU users while applying.
• Assuming former VASP registration means MiCA authorisation will follow.
• Assuming Article 60 notification is automatic.

7. The application playbook — what to have ready

1. Programme of operations, service-by-service perimeter map and country / passporting plan.
2. Legal entity, group, UBO, intra-group service and booking-model pack.
3. Board, senior management, key function holder, time-commitment and fit-and-proper pack.
4. AML/CFT and financial-crime evidence — risk assessment, CDD/EDD, sanctions, transaction monitoring, Travel Rule, blockchain analytics, SAR/STR, high-risk client controls.
5. Custody / safeguarding evidence — wallet architecture, key governance, client-asset segregation, reconciliations, incident response, insolvency analysis.
6. ICT/DORA pack — ICT risk framework, incident reporting, BCP/DR testing, access controls, cyber testing, vendor risk, outsourcing register.
7. Conduct / consumer pack — complaints, disclosures, marketing approvals, conflicts, product governance and unregulated-product segregation.
8. Financial resources pack — own funds, capital, liquidity, loss scenarios, insurance and wind-down funding.
9. Control-evidence appendix — screenshots, logs, MI, test results, board minutes, reconciliations, policy approvals, outsourcing due diligence and remediation tracker.

Recommended sequencing: narrow first; add services later; separate regulated and unregulated products; clean website and marketing before contact; use the pre-application meeting to test perimeter, service codes, Article 60 eligibility and evidence expectations; bring a regulator-ready governance pack that shows who is accountable, where decisions are made, and how control functions challenge the business.

Companion data

The cleaned benchmark dataset, summary tables, weak-control dataset, red-flag checklist, readiness scorecard and applicant-archetype matrix are published alongside this analysis. The full report includes the methodology, the confidence scores attached to each row, and the unresolved data gaps.

• Cleaned benchmark dataset (177 records) mica_casp_cleaned_benchmark.csv
• Summary by jurisdiction mica_casp_summary_by_jurisdiction.csv
• Summary by competent authority mica_casp_summary_by_nca.csv
• Summary by service code mica_casp_summary_by_service.csv
• Service-code combinations mica_casp_service_combinations.csv
• Timing — monthly mica_casp_timing_monthly.csv
• Timing — quarterly mica_casp_timing_quarterly.csv
• Summary by inferred business model mica_casp_summary_by_business_model.csv
• Summary by service-scope breadth mica_casp_summary_by_scope_breadth.csv
• Failure / weak-control dataset mica_casp_failure_weak_control_dataset.csv
• Red-flag checklist mica_casp_red_flag_checklist.csv
• Application-readiness scorecard mica_casp_readiness_scorecard.csv
• Applicant archetypes matrix mica_casp_applicant_archetypes.csv
• Jurisdiction findings matrix mica_casp_jurisdiction_findings.csv
• Source list mica_casp_source_list.csv
• Full report (Markdown) mica_casp_forensic_licensing_success_report.md