TL;DR: MiCA’s grandfathering period is still active in some jurisdictions, but full licensing will be required across the EU from July 1, 2026, and SumSub’s guide focuses on scope, licensing milestones, and AML/CFT obligations that sit alongside MiCA rather than inside it.
At a glance
What this is: This guide explains how MiCA readiness for CASPs depends on identity controls, scope clarity, and evidence for licensing, while separating MiCA obligations from AML/CFT and Travel Rule requirements.
Why it matters: IAM, compliance, and risk teams need a clear read on where licensing obligations begin and end so they can align identity verification, governance, and documentation before EU licensing deadlines tighten.
Context
MiCA creates a licensing and operating regime for crypto-asset service providers and issuers, but the practical challenge is not just regulatory interpretation. CASPs must show they can evidence who they are, who they serve, and how their controls support the activities covered by the regime.
For identity and compliance teams, the important split is between MiCA itself and the separate AML/CFT and Travel Rule obligations that sit alongside it. That distinction matters because the licensing file has to prove operational readiness, not just policy awareness.
The guide is aimed at CASPs moving from grandfathering into full EU licensing, which makes the identity layer a core part of regulatory preparation rather than an afterthought.
Key questions
Q: How should CASPs prepare for MiCA licensing if grandfathering is still available?
A: Treat grandfathering as preparation time, not a reason to defer governance work. CASPs should map every regulated activity to the relevant licensing obligation, close evidence gaps, and prove that identity verification and control ownership are already operating in a repeatable way before full EU licensing applies.
Q: Why do AML/CFT and Travel Rule controls matter when MiCA does not create them?
A: Because regulators will still expect those obligations to be met through the correct legal basis outside MiCA. CASPs need separate evidence for identity verification, screening, and Travel Rule handling so the licensing file does not blur distinct compliance duties into one narrative.
Q: What breaks when a CASP treats MiCA readiness as a policy exercise only?
A: The application pack becomes weak, ownership stays unclear, and supervisors cannot easily verify that controls operate in practice. Policy language alone does not prove governance, so the firm risks failing to show how its identity and compliance processes support regulated activity.
Q: What should compliance and IAM teams align on before a MiCA licence application?
A: They should agree on which activities are in scope, which controls support each obligation, and which artefacts prove those controls are working. That alignment makes the licensing story coherent and avoids duplicated or contradictory evidence across teams.
Technical breakdown
MiCA scope depends on regulated actors and activities
MiCA applies to CASPs and issuers of crypto-assets, including asset-referenced tokens and e-money tokens, but the regulatory reach depends on the activity being performed. That means issuance, offering, and trading are not all governed in the same way, and teams need to map each service line to the specific obligation it triggers. In practice, the licensing question is not whether a firm is in crypto, but which regulated function it performs and what evidence it can produce for that function.
Practical implication: Map each CASP service and token activity to the exact MiCA obligation it creates before building the licence pack.
Identity verification sits beside MiCA, not inside it
The article makes a clear point that MiCA does not itself create AML/CFT or Travel Rule requirements. Those duties come from other EU regulations and directives, especially AMLD and TFR, which means identity controls have to be governed as separate compliance inputs rather than assumed to be bundled into MiCA. For practitioners, that separation is important because it prevents false scope assumptions in control design, evidence collection, and audit narratives.
Practical implication: Separate MiCA licensing evidence from AML/CFT and Travel Rule control evidence so reviewers can see each obligation clearly.
Licensing readiness is an evidence problem, not just a policy problem
The guide points readers toward a licence-preparation checklist and an application pack, which signals that regulators want structured evidence of governance, controls, and operational readiness. In regulated identity programmes, this is usually where firms underperform: they have controls in policy form, but not in a form that can be assessed consistently by a supervisor. The real test is whether the organisation can show repeatable processes, ownership, and supporting artefacts.
Practical implication: Build regulator-ready artefacts that prove control operation, not just control intent.
NHI Mgmt Group analysis
MiCA readiness is really a controlled-identity problem for CASPs: licensing only works when the firm can prove who it is, what activity it performs, and which obligations attach to that activity. The article makes clear that compliance is not satisfied by reading MiCA in isolation, because the operational burden sits in identity verification, governance, and evidence production. For CASPs, the practitioner question is how well identity controls map to regulated services, not whether the regulation exists.
MiCA is not the same thing as AML/CFT governance: the guide correctly separates the licensing regime from the surrounding obligations that come from AMLD and TFR. That distinction matters because control owners often collapse these into one workstream and then lose clarity on which evidence supports which duty. The result is a weaker licensing narrative and a harder supervisory review.
Grandfathering creates a temporary comfort that can become governance debt: some jurisdictions still allow transition time, but that window does not reduce the amount of evidence a CASP will eventually need. Teams that treat grandfathering as a delay rather than a preparation period accumulate documentation gaps, ownership ambiguity, and control drift. The implication is that identity and compliance work has to start before the deadline pressure becomes acute.
Licensing readiness should be measured by artefact quality, not policy volume: a CASP that cannot produce a coherent application pack or supporting checklist has not yet translated policy into operational control. This is where many programmes fail, because the supervisor is assessing whether the business can operate safely and consistently, not whether it can describe the regulation in broad terms. The practitioner standard is evidence that a control can be audited, repeated, and explained.
MiCA will push CASPs toward more explicit control ownership across compliance and identity teams: the guide shows why these functions cannot remain loosely connected. Licensing, identity verification, AML screening, and Travel Rule obligations all demand clear accountability, especially when the firm has to show how controls support regulated activities. Organisations that do not assign that ownership early will struggle to move from policy alignment to supervisory readiness.
What this signals
Licensing readiness will increasingly be judged by evidence quality rather than policy intent: CASPs that cannot produce coherent artefacts for verification, screening, ownership, and operating control will struggle to move from regulatory awareness to supervisory acceptance. The practical shift is toward demonstrable governance, not descriptive compliance.
MiCA programmes need a clearer boundary between licence scope and adjacent obligations: the next failure mode is not misunderstanding the regulation in general, but misclassifying which controls belong to MiCA and which belong to AML/CFT or the Travel Rule. That boundary has to be built into the programme structure early.
Control ownership becomes the real readiness signal: once compliance, legal, and identity teams share a single governance model, the organisation can show how regulated activities, verification workflows, and evidence packs fit together. Without that, transition periods simply defer the same structural weakness.
For practitioners
- Map regulated activities to MiCA obligations Build a service-by-service matrix that links each CASP activity, token type, and operating jurisdiction to the exact licensing and governance obligations it triggers.
- Separate AML/CFT evidence from MiCA evidence Maintain distinct control narratives and evidence packs for MiCA licensing, identity verification, AML screening, and Travel Rule compliance so reviewers can assess each obligation independently.
- Prepare an application pack with proof, not prose Assemble artefacts that show ownership, operating procedures, approval paths, and control operation, not just policy statements or high-level compliance claims.
- Use grandfathering time to close evidence gaps Treat the transition period as a deadline to eliminate missing artefacts, unclear control ownership, and inconsistent onboarding or verification records before full licensing applies.
- Align compliance and identity owners on one governance model Assign clear responsibility for verification, screening, and regulatory evidence so the licensing story is coherent across legal, compliance, and IAM stakeholders.
Key takeaways
- MiCA readiness for CASPs is not just a legal interpretation exercise. It depends on whether identity controls, verification evidence, and governance ownership can be shown in an auditable way.
- MiCA does not itself create AML/CFT or Travel Rule obligations, so CASPs need separate control narratives for those duties. Blurring them weakens the licensing file and confuses accountability.
- Grandfathering time should be used to close documentation and control gaps before full EU licensing applies. The strongest programmes will be the ones that can prove repeatable operations, not just describe compliance goals.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-63 and CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.32 — Security of Processing | Identity verification and customer data handling in CASP licensing intersect with personal-data governance. |
| Recommendation — Document processing safeguards that support secure verification and evidence handling under Art.32. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | CASP licensing readiness depends on clearly governed access and control ownership. |
| Recommendation — Define and audit access permissions for identity and compliance workflows under PR.AA-05. | ||
| NIST SP 800-63 | SP 800-63A — Enrollment and Identity Proofing | The article centres on identity verification measures for regulated crypto service providers. |
| Recommendation — Use identity proofing controls to support regulated onboarding and verification evidence. | ||
| CIS Controls v8 | CIS-5 — Account Management | CASP governance depends on controlled ownership and accountability for regulated workflows. |
| Recommendation — Apply account management controls to keep governance ownership and evidence traceable. | ||
Key terms
- MiCA licensing readiness: MiCA licensing readiness is the state of being able to prove that a crypto-asset service provider can meet the EU's authorisation and governance expectations. In practice, it means the firm can show scope mapping, control ownership, operating evidence, and the supporting documentation regulators need to assess the application.
- CASP: A Crypto-Asset Service Provider is an organisation that offers regulated services involving crypto-assets, such as custody, exchange, or transfer activities. For compliance teams, the key issue is that CASP status brings licensing, governance, and control evidence obligations that must be maintained continuously, not only at application time.
- Travel Rule: A Travel Rule is a regulated requirement for financial platforms to exchange originator and beneficiary information during qualifying transfers. In crypto, it turns transfer handling into an identity and compliance workflow, where the platform must know which counterparties can receive data and how that exchange is recorded.
- Asset-Referenced Token: An Asset-Referenced Token is a crypto asset that seeks to maintain value by referencing one or more assets, currencies, or other benchmarks. Under MiCA, ARTs are not treated as funds. They are governed by redemption, reserve, disclosure, and reporting rules designed to support market stability and supervisory oversight.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 5, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org