MiCA Compliance Checklist: What Founders Must Build Before Applying
- ASD Labs
- Nov 22
- 33 min read
~15–20 min read – A founder‑level roadmap to MiCA operational readiness: the governance, systems, controls, and evidence you need before filing a CASP application.
This guide turns the legal MiCA rulebook into a practical MiCA compliance checklist you can actually run: a readiness assessment across governance, systems, controls, and evidence so you know whether you’re 2, 6, or 9+ months away from a credible application.
For the official regulatory perspective behind this checklist, it’s worth skimming the ESAs factsheet on crypto-assets – what MiCA means for investors – and the EU Supervisory Authorities’ warning on risks and limited protection for certain crypto-assets and providers, and keeping an eye on the ESMA website and EBA website for the latest texts and guidance.
Jump to:
TL;DR – What "MiCA‑ready" Actually Means in 2025
Being "MiCA‑ready" in 2025 doesn’t mean you’ve collected legal memos – it means you can show a supervisor that your governance, systems, controls, and evidence already work in practice. This article gives founders, COOs, and MLROs a pragmatic MiCA compliance checklist they can run as an internal readiness audit before filing a CASP application.
At a glance, a MiCA‑ready CASP has:
Governance – A functioning board and oversight structure: named MLRO and compliance function, clear reporting lines, basic risk/compliance committee work already happening on paper (minutes, decisions, risk appetite).
Systems – A live or near‑live stack for AML/KYC, transaction monitoring, custody/wallet management, and regulatory reporting – not just vendor logos on a slide.
Controls & testing – Documented policies and procedures mapped into day‑to‑day controls, with at least some testing or dry‑runs completed (e.g. high‑risk alert handling, incident simulations, key ceremonies).
Evidence – A growing evidence pack: documentation, registers, logs, sample reports, and test outputs that you can attach or refer to in the CASP application.
Quick self‑check – are you even close to MiCA‑ready?
If you’re a founder or MLRO, skim this list and mark each item Yes / In progress / No:
We can draw our governance diagram (board, MLRO, compliance, risk/internal audit) in under 60 seconds and it matches reality.
We have chosen and integrated an AML/KYC + transaction monitoring stack, and can show at least a handful of real or test cases flowing through it.
Our custody and wallet architecture is documented, including how client assets are segregated and who can approve movements.
For each critical process (onboarding, withdrawals, incident response), there is a policy + SOP that staff can actually find and follow.
We can open a folder today and see evidence: board minutes, risk decisions, system diagrams, alert logs, test reports, and outsourcing due‑diligence files.
If our supervisor asked "What would break if you doubled volumes next quarter?", we could answer based on a basic risk and capacity assessment, not guesswork.
If you answered "No" or "In progress" to most of these, treat the rest of this article as your implementation playbook: each section deep‑dives into one pillar of readiness and what to build next.
How to Use This MiCA Compliance Checklist
Most people land on this page in one of three situations:
You’re 6–12 months before a CASP application and want to know what to build in what order.
You’re 3–6 months before filing and worried that legal work is ahead of operations.
You’re already licensed or in review and your supervisor is asking uncomfortable questions about systems, controls, or evidence.
This checklist is written for founders, COOs, and MLROs who are responsible for making MiCA work in production, not just on paper. It won’t replace your lawyers or the formal CASP licensing guide. It will show you where your operational gaps are and what to prioritise next.
Use it as a simple loop:
Pick your scope. Decide whether you’re assessing the whole firm or a specific service line (e.g. exchange, brokerage, custody). For complex groups, run the checklist per business line.
Copy the checklist into your own tracker. A spreadsheet, Notion board, or internal project tool works fine. Each row should roughly look like: `Item | Score | Owner | Target date | Evidence link`.
Score each item honestly. Use a 0–3 scale or Red / Amber / Green:
0 / Red – Nothing exists yet.
1 / Amber‑ – Something exists, but it’s ad hoc, undocumented, or not used.
2 / Amber+ – Documented and used, but only partially tested or not yet consistent.
3 / Green – Built, documented, tested, and backed by evidence you can show a supervisor.
Attach real evidence. For anything you mark 2 or 3 / Amber+ or Green, link to where the proof lives: a policy, board pack, system diagram, alert log, or test report.
Turn gaps into a build plan. Group all 0/Red and 1/Amber‑ items by theme (governance, systems, controls, evidence) and assign owners and dates. Those become your MiCA operational roadmap.
This article walks through the same structure: governance → systems → controls → evidence → assessment. You can read it end‑to‑end once, then come back and work through one pillar at a time with your team. The goal is not a perfect score on day one, but a clear, defensible explanation of what’s in place now, what’s being built, and how you’re tracking progress.
What this checklist is not:
It is not legal advice or an official ESMA/NCA template.
It does not guarantee licence approval or remove the need for a structured CASP application.
It is deliberately operational – it assumes you already know what MiCA requires at a high level and now need help with how to make it real.
Use it alongside your CASP licensing work (including your Program of Operations and other formal MiCA annexes): legal and policy teams define the requirements; this checklist keeps the governance, systems, controls, and evidence build moving so you don’t discover critical gaps three weeks before a regulator meeting.
If you need the full licensing decision tree and application steps – including MiCA vs EMI/PI scope, country nuances, and ESMA register mechanics – read this checklist alongside our EU CASP licensing requirements guide.
Governance Setup & Key Roles
The first thing a supervisor will look at is not your product demo, but who is actually in charge of this CASP and how they make decisions. If governance is weak, every other control will be treated as fragile, no matter how good your vendors or policies are.
This section turns the high‑level "CASP governance requirements" into a concrete org chart and decision log you can defend in a meeting.
Board and Strategic Oversight
Under MiCA, the board is expected to own the risk profile and direction of the CASP, not just sign the application. Supervisors will look for a board that:
Understands the specific crypto services you provide (exchange, brokerage, custody, advice, etc.).
Has enough independence to challenge founders and executives.
Actually discusses risk, compliance, outsourcing, and new products – and leaves a paper trail.
In most EU jurisdictions, supervisors also expect the management body to include at least one member who clearly owns AML/CFT and compliance at board level. That doesn’t mean a director who only does AML and nothing else, but it does mean their portfolio explicitly includes AML/CFT and conduct risk, they can credibly challenge the business and the MLRO, and their role and time commitment are documented in the governance map and board/committee terms of reference. The MLRO then owns day‑to‑day execution, but supervisors will look for both a named AML/CFT director at board level and a capable MLRO in the second line.
For a MiCA‑ready board, you should be able to show:
A clear governance map: who sits on the board, which committees exist (e.g. risk/compliance, audit), and how often they meet.
Terms of reference for the board and key committees that explicitly cover MiCA‑relevant topics (risk appetite, client asset protection, outsourcing, incident oversight).
Board and committee minutes for at least a few meetings where you see:
Approval of the CASP business model and services in scope.
Discussion and approval of risk appetite (what risks you are willing to take and within what limits).
Decisions on key outsourcing arrangements (AML/KYC provider, custody vendors, cloud, core systems).
A simple new product / change process – even if it’s just a one‑page checklist the board uses when green‑lighting new features.
When you run the checklist later, ask yourself:
Could we send our last three board packs and minutes to the supervisor without rewriting them?
Is it obvious from those documents who owns MiCA risk and compliance at board level, or does it look like an afterthought?
If the answer is “no”, this is one of the first pillars to fix; everything else (systems, controls, evidence) depends on credible oversight.
MLRO and Compliance Function
For most CASPs, the MLRO is the visible face of compliance to the supervisor. Under AMLD5 and MiCA, regulators expect an MLRO who is:
Formally appointed with a written mandate and job description.
Senior and independent enough to challenge the business and escalate concerns.
Given the time and resources to actually run the AML and compliance programme.
In practice, a MiCA‑ready MLRO setup looks like this:
The MLRO has a direct reporting line to the board or a risk/compliance committee, not just to the CEO.
Their responsibilities clearly cover both financial crime (AMLD5) and MiCA‑specific conduct/operational risks.
There is at least a small compliance function around them (internal staff, outsourcers, or a hybrid model) so they are not purely a symbolic appointment.
Key processes – onboarding, transaction monitoring, investigations, reporting, sanctions screening – have named owners and the MLRO has visibility over metrics and exceptions.
For smaller CASPs, regulators understand that roles may be combined (e.g. MLRO is also Head of Compliance or even CFO). What they will not accept is:
An MLRO who cannot explain your business model clearly.
An MLRO with “one day a month” capacity and no practical oversight of systems and alerts.
An MLRO who is effectively reporting into the sales function.
When you score this area in your checklist, look for:
A signed appointment letter and job description for the MLRO.
An organisation chart that shows where compliance sits and how it connects to operations and risk.
Evidence that the MLRO reports to the board at least quarterly (slides, board minutes, or written reports).
If you cannot point to those artefacts quickly, you are likely at 0/Red or 1/Amber‑ on MiCA governance, even if you have a name in the MLRO box.
Risk Management and Internal Audit (or Alternatives for Smaller CASPs)
MiCA leans on the familiar three lines of defence model: business owners, risk/compliance oversight, and internal audit / independent assurance. Supervisors know smaller CASPs will not build a full bank‑grade structure on day one. They will still ask who challenges the first line and who checks the checkers.
Think about this in terms of functions, not titles:
Risk management – Someone (or a small team) owns the risk register, documents key CASP risks (operational, market, liquidity, conduct, technology, outsourcing), and tracks mitigants.
Independent assurance – Someone independent of day‑to‑day operations periodically checks that controls are designed and working as described.
Pragmatic options for smaller or earlier‑stage CASPs include:
A part‑time or dual‑hat risk lead (e.g. COO with explicit risk mandate) supported by structured risk workshops and documented outputs.
Outsourced internal audit to a firm with crypto/fintech experience, with a narrow initial scope (e.g. custody and AML)
An independent non‑executive director playing a more active challenge role on risk and controls, supported by external reviewers.
What matters for MiCA readiness is that you can show:
A risk register or similar document that is more than a generic template – it names your services, your key risks, and current mitigants.
At least one independent review or test of a critical area (e.g. custody controls, key management, transaction monitoring) with findings and actions.
A clear answer to “Who would notice if this control stopped working?” for your highest‑impact controls.
In the checklist, these are the items that often move you from 1/Amber‑ (“we sort of think about risk”) to 2/Amber+ or 3/Green (“we have a structured, repeatable challenge process with evidence”).
Systems & Architecture Blueprint
Once your governance is credible, supervisors will quickly move to a second question: show us how this business actually runs in systems. Under MiCA, you don’t get extra credit for naming big vendors; you get credit for having a coherent architecture where client data, risk decisions, and controls line up across the whole customer and transaction lifecycle.
This section focuses on the minimum viable MiCA‑ready stack: AML/KYC tooling, transaction monitoring, custody/wallet architecture, and the reporting interfaces that connect you to regulators and other authorities.
AML/KYC and Customer Lifecycle
MiCA depends heavily on your existing AMLD5 obligations. For a CASP, that means you need a joined‑up view of the customer lifecycle, not just an onboarding form and a vendor logo.
Regulators will expect to see that you can:
Describe, end‑to‑end, how a customer moves from prospect → onboarded → active → reviewed or offboarded.
Explain your risk‑based approach – what makes a client low, medium, or high risk, and how that links to enhanced due diligence.
Show how sanctions, PEP, and adverse media screening is embedded in the flow (at onboarding and on a periodic/trigger basis).
Retrieve, on demand, the KYC file for a given client: documents, data points, risk score, and review history.
For MiCA readiness, you should be able to put in front of a supervisor:
A simple customer lifecycle diagram that names the systems involved (onboarding front end, KYC provider, CRM/core, document store).
A risk‑scoring methodology (even if basic) and how it is implemented in tooling.
Screenshots or exports from your KYC system showing real or test customer files, with timestamps and decision logs.
In the checklist, items here translate into questions like:
“We have a documented customer lifecycle with named systems and owners.”
“Our KYC and screening flows are configured and have been tested end‑to‑end.”
“We can retrieve a full KYC file with risk score and review history for any customer within X minutes.”
Transaction Monitoring and Risk Engines
If AML/KYC is about who your customers are, transaction monitoring is about what they do – on‑chain, off‑chain, or both. MiCA doesn’t mandate a specific vendor, but supervisors will expect monitoring that is (a) risk‑sensitive, and (b) actually used by humans, not just generating unattended alerts.
For a MiCA‑ready setup, you should be able to explain:
Which flows are in scope for monitoring (deposits, withdrawals, internal transfers, trading activity, fiat flows).
Where you use on‑chain analytics vs traditional payment/transaction monitoring, if applicable.
How your rules or models are calibrated – which scenarios you monitor for, and what thresholds you use.
What happens after an alert fires: triage, investigation, escalation to MLRO, and reporting.
Evidence that supports this includes:
A rules catalogue or scenario list for your monitoring engine, with owners and last review dates.
A log of threshold changes and tuning decisions linked to risk rationale.
A small set of sample cases (closed investigations) that show alerts, analyst notes, decisions, and any SAR/STR filings.
When you score this area in your checklist, you’re looking for more than “we have a vendor account”:
0/Red – No live monitoring in place; only ideas or contracts.
1/Amber‑ – Monitoring tool connected, but rules are generic and cases are not consistently reviewed.
2/Amber+ – Rules tailored to your services and risk profile; investigations are happening with basic QA.
3/Green – Monitoring is tuned, documented, and evidenced by a case history and MI that the MLRO regularly reports to the board.
If you want a concrete pattern to copy, our three-layer crypto transaction monitoring approach article shows what a mature monitoring stack looks like in practice.
Custody and Wallet Architecture
For CASPs that hold or control client cryptoassets, custody and wallet design is one of the highest‑impact parts of the architecture. Under MiCA, supervisors will look closely at how you segregate client assets, manage keys, and prevent a single point of failure or abuse.
A MiCA‑ready custody architecture typically shows:
Clear segregation between client assets and the firm’s own assets at the wallet and ledger level.
A documented hot / warm / cold wallet strategy that matches your volumes and risk tolerance.
Strong key management: where keys are generated and stored (e.g. HSMs, MPC, hardware wallets), who can access them, and how access is controlled and logged.
Dual‑control or multi‑party approval for sensitive operations (e.g. large withdrawals, key ceremonies).
From a readiness‑checklist perspective, you want to be able to show:
A current architecture diagram of your wallets and custody stack, with data flows and trusted third parties labelled.
Written SOPs or runbooks for key operations: wallet creation, deposits, withdrawals, key rotation, incident response.
Evidence that you have tested failure scenarios – loss of a key shard, vendor outage, sudden spike in withdrawals – and know what happens.
This is also where it pays to go deeper on the technical custody patterns behind the checklist items: our MiCA VASP fund segregation best practices and HD‑wallet key management for crypto fund segregation articles walk through concrete wallet structures, reconciliation flows, and key‑management options you can plug into this architecture.
Reporting & Regulatory Interfaces
Finally, MiCA‑ready systems must be able to talk to the outside world: supervisors, FIUs, and other authorities. Even if early reporting is manual, you need a credible story for how you will produce complete, timely, and accurate data.
Think in terms of three layers:
Data foundations – You can reliably extract the data needed for prudential, volume, client asset, and incident reporting from your core systems.
Workflows – There are clear processes (and owners) for preparing, validating, and submitting reports and notifications.
Interfaces – Where relevant, you know which APIs, portals, or secure mailboxes your NCA/FIU uses and how you will connect to them.
Evidence here can include:
A list of regulatory reports and notifications you expect to file (by frequency and owner).
Example report mock‑ups or test exports from your systems, even if they are still being refined.
Screenshots or documentation for how you access FIU/NCA portals and who holds credentials.
In the checklist, you can capture this as:
“We have identified all MiCA‑related and AMLD5 reports/notifications and assigned owners.”
“Our systems can already produce the core datasets needed for those reports (even if formatting is still manual).”
“We have documented how to access and use the relevant supervisory/FIU interfaces.”
Internal Controls, Policies, and Testing Regime
Governance sets who decides, systems show how the business runs; controls and policies are where supervisors look for day‑to‑day discipline. This is often where MiCA applications fall down: firms have a stack of advice and some good tools, but no repeatable way to ensure that people actually follow the rules – and no evidence that controls work over time.
This section focuses on three questions:
Do you have the right policy suite and procedures on paper?
Have you translated those into concrete controls with owners and evidence?
Do you test and review those controls often enough to trust them?
Policy Suite and Minimum Documentation
MiCA doesn’t come with a standard policy pack, but supervisors will expect your CASP to have a coherent, non‑boilerplate policy suite that matches your services and risk profile.
At a minimum, you should have current, approved policies and procedures covering:
Governance and risk management – roles of the board, committees, MLRO, risk function; how you set and review risk appetite.
AML/CFT and sanctions – customer due diligence, ongoing monitoring, screening, investigations, and reporting.
Customer onboarding and KYC operations – how you collect and verify information, handle edge cases, and escalate issues.
Transaction monitoring and investigations – alert handling, triage, escalation, case closure, and quality assurance.
Custody and safekeeping of client assets – wallet management, segregation, reconciliations, key ceremonies, incident response.
Operational resilience and cybersecurity / ICT risk – access management, change management, backups, incident response, business continuity, and (for EU CASPs) alignment with the emerging Digital Operational Resilience Act (DORA) expectations on ICT risk management, testing, and incident handling.
Outsourcing and third‑party risk – how you select, approve, and oversee critical vendors (KYC, monitoring, custody, cloud).
Conflicts of interest and market conduct – dealing with own‑account trading, related‑party relationships, and fair treatment of clients.
Complaints handling – how clients can complain, how you investigate and respond, and how you track themes.
For each document, you want to be able to show:
A clear owner (by role, not just name).
Version control and review dates (e.g. annual, or on material change).
Evidence that staff know these documents exist and where to find them (for example, links in the intranet, onboarding training decks, short SOPs).
On your checklist, this translates into items such as:
“Our core policy suite is documented, approved, and mapped to our CASP services.”
“Each policy has an owner, review cycle, and supporting procedures/SOPs.”
“New joiners in relevant roles receive training on key policies within X days of starting.”
If, when you look in your shared drive, you find a mixture of generic templates, outdated drafts, and one‑off emails instead of policies and SOPs, you are likely sitting at 0/Red or 1/Amber‑ for MiCA controls, even if individual team members “know what to do”.
Three Lines of Defence and Control Design
Earlier, we looked at three lines of defence at the level of functions (business, risk/compliance, internal audit). Here, the question is more granular: for each critical process, what are the actual controls, who performs them, and how do you know they happened?
A simple way to think about this is to build a control register or matrix. For each key risk and process (onboarding, withdrawals, custody operations, incident response, etc.):
Define the control objective (what risk the control is meant to reduce).
Describe the control activity (what is done, how often, by whom).
Specify the first line owner (operations, product, finance, etc.).
Specify the second line oversight (compliance/risk checks, thematic reviews, MI).
Note the evidence produced (logs, reports, reconciliations, approvals) and where it is stored.
Your third line of defence – internal audit or an outsourced equivalent – should then use this same control register as the backbone for independent testing. In your procedures, define a risk‑based review frequency (for example, custody operations and transaction monitoring audited at least annually, lower‑risk back‑office processes every 2–3 years) and make sure audit scopes explicitly reference the controls and evidence recorded in the register.
Examples:
Onboarding: “All high‑risk clients are subject to enhanced due diligence review and MLRO sign‑off before activation; evidence stored in KYC system with MLRO approval log.”
Custody: “Daily reconciliation between on‑chain balances and internal ledger; exceptions reviewed and signed off by operations lead, with monthly MI to the board.”
Withdrawals: “Large or unusual withdrawals (over X threshold or risk score Y) require dual approval and trigger additional checks; approvals recorded in system logs.”
When you later run the MiCA readiness checklist, well‑designed controls will show up as:
A populated control register that someone actually uses.
Clear mappings from each major policy to specific controls and evidence.
The ability to answer a supervisor’s question: “Show me how this specific risk is controlled in practice.”
This is typically the difference between 1/Amber‑ (“we rely on people doing the right thing”) and 2/Amber+ (“we have explicit controls with owners and evidence”).
Testing, Reviews, and Drills
Once the controls look good on paper, the obvious MiCA question is: “How do you know this still works today?” Testing, review, and drills are how you turn a static control register into a living system regulators can trust.
For a CASP, you don’t need a bank‑grade testing machine, but you do need a deliberate cadence that matches your risk profile. A practical way to think about it is three overlapping layers:
Routine monitoring and QA – Day‑to‑day sample checks by team leads or compliance to confirm that controls are actually being applied. Examples:
Spot‑checking KYC files against policy (is EDD really happening for high‑risk clients?).
Reviewing a subset of transaction‑monitoring alerts to see if analysts followed the playbook.
Re‑performing reconciliations or approvals on a sample basis.
Periodic thematic reviews – More structured deep dives into areas where MiCA risk is concentrated: custody operations, key management, sanctions screening, incident handling, outsourcing oversight. These should end with written findings, owners, and deadlines.
Drills and simulations – Tabletop exercises for the scenarios that would genuinely keep a supervisor awake: key compromise, major fraud case, a serious outage, or data loss. The goal is not a perfect response, but clear evidence that you learned and updated your runbooks.
When a supervisor asks for evidence, you want to be able to open a folder and show:
A concise testing plan or calendar that sets out what you test each quarter/year and who owns it.
QA checklists or sampling sheets with signatures, dates, and any issues found.
An issues and remediation log that links findings from QA, thematic reviews, internal/outsourced audits, and supervisory feedback to specific actions and closure dates.
Short summaries of incident simulations or tabletop exercises, plus the concrete changes you made to policies, controls, or systems afterwards.
On your MiCA compliance checklist, this will surface as items like:
“We have a documented, risk‑based plan for testing key controls, with clear owners and frequencies.”
“Findings from QA, reviews, audits, and drills are tracked through to remediation and signed off.”
“We have run at least one simulation of a major custody or operational incident in the last 12–18 months and updated our procedures based on what we learned.”
If, today, you cannot point to any testing artefacts – no QA checklists, no review notes, no remediation log, no exercise write‑ups – then this pillar is likely at 0/Red or 1/Amber‑, even if your team feels confident. For MiCA supervisors, documented tests and improvements carry much more weight than assurances that “we would handle it on the day”.
If you’re experimenting with AI‑enabled monitoring or QA, start with our AI in compliance: practical guide to real-world automation and the AI compliance tools FAQ for EU fintech and crypto teams, so any pilots you run fit inside a control framework supervisors will actually recognise.
Evidence & Documentation Pack Regulators Expect
Everything so far – governance, systems, controls, testing – only becomes real to a supervisor when you can pull the evidence on demand. A MiCA‑ready CASP doesn’t just say “we do this”; it can open a folder and show board packs, diagrams, logs, and reports that back up every key claim in the application.
Think of this section as your MiCA evidence vault blueprint: what should already exist today, where it should live, and how quickly you should be able to assemble it for an NCA. This is not an attempt to list every formal application document (such as the Program of Operations, business plan, or policy annexes); instead, it focuses on the operational artefacts that should sit behind those documents and be visible in day‑to‑day practice.
Governance & Strategy Evidence
Supervisors use governance artefacts to answer three questions:
Does the board understand what this CASP is actually doing?
Has it thought seriously about risk, compliance, and client asset protection?
Is there a documented trail of decisions they can rely on later?
In practice, your evidence pack should include:
Recent board and committee packs (agendas, slides, papers) where MiCA‑relevant topics were discussed: business model, services in scope, risk appetite, outsourcing, custody model, major incidents.
Approved minutes from the board and key committees (risk/compliance, audit) showing:
Formal approval of the CASP strategy and services.
Discussion and approval of risk appetite and key risk limits.
Oversight of major outsourcing and custody decisions.
A current governance map / org chart showing the board, committees, and key functions (MLRO, risk, internal audit) with reporting lines.
The latest risk appetite statement or equivalent, and any related policies that anchor it.
From a checklist perspective, governance evidence items could look like:
“We can assemble a complete board/committee evidence pack for the last 12–18 months within two working days.”
“Our governance map and risk appetite statement are current and have been formally approved.”
If today you would need weeks of email archaeology to reconstruct how decisions were taken, this is a clear MiCA readiness gap, even if the right conversations happened informally.
System and Control Evidence
For systems and controls, regulators will want to see that your architecture and control design exist beyond whiteboards and vendor sales decks.
Your evidence set should cover:
Current architecture diagrams for core systems: onboarding/KYC, transaction monitoring, trading/exchange engine, custody/wallet stack, ledger/finance, reporting. These should show data flows and key integrations, not just boxes with logos.
A system inventory or register listing critical applications and services, their owners, and where they are hosted (on‑prem, cloud provider, vendor SaaS).
Your control register / matrix, or at least extracts for high‑risk areas (onboarding, monitoring, custody, incident response), with owners and evidence sources populated.
Representative standard operating procedures (SOPs) and runbooks for day‑to‑day operations (e.g. onboarding steps, reconciliations, withdrawals, incident response workflows).
Screenshots or samples from systems that demonstrate how controls are executed in practice (e.g. approval screens, workflow states, logs).
In your internal checklist, system/control evidence might translate into:
“We maintain up‑to‑date architecture diagrams and a system inventory for all MiCA‑relevant systems.”
“For each critical process, we can show at least one SOP/runbook and the control evidence it produces.”
If diagrams live only in people’s heads or in stale pitch decks, regulators will treat your control environment as fragile, regardless of how strong your policies sound.
Testing & Monitoring Evidence
Testing evidence answers the question: “Are we learning and improving, or just hoping?” Under MiCA, supervisors will be less interested in how pretty your control register looks, and more interested in what your tests and monitoring have actually found – and what you did about it.
Your evidence pack should include:
Transaction‑monitoring and case‑management logs: examples of alerts, investigations, decisions, and any SAR/STR filings.
QA and sampling records from KYC, monitoring, custody operations, etc. – checklists, sample results, and issues raised.
Reports from thematic reviews and internal/outsourced audits, with findings, risk ratings, and management responses.
An issues and remediation tracker that links findings to specific actions, owners, and closure dates.
Brief post‑exercise summaries for incident simulations or major real incidents, including lessons learned and changes made.
On your checklist, this might become:
“We have at least 6–12 months of monitoring and case‑management data we can share in anonymised form.”
“Findings from QA, reviews, audits, and drills are logged and tracked through to closure.”
If you cannot show any closed cases, QA samples, or resolved findings, supervisors will assume your monitoring and testing are either brand new or not yet embedded – both red flags for MiCA readiness.
Outsourcing and Vendor Management Evidence
Many CASPs rely on third‑party providers for KYC, monitoring, custody, cloud, or other critical functions. MiCA doesn’t forbid this, but it does expect you to stay in control of outsourced risks.
Your outsourcing evidence should cover the full lifecycle:
Selection and due diligence – RFP/RFQ documents, due‑diligence questionnaires, risk assessments, and recommendations to the board or a committee.
Contracts and SLAs – Signed agreements that clearly set out services in scope, performance standards, data protection, subcontracting, exit rights, and audit/inspection rights.
Ongoing monitoring – Periodic vendor review notes, KPI/KRI reports, meeting minutes, and any incident or breach reports from providers.
Governance linkage – Board or committee minutes where critical outsourcing arrangements were approved and are periodically reviewed.
Checklist‑ready outsourcing items could be:
“All critical outsourcings (KYC, monitoring, custody, cloud) have documented due diligence, contracts, and named owners.”
“We can evidence periodic performance and risk reviews for each critical vendor.”
If the only record of a key outsourcing decision is a commercial contract and a few Slack threads, expect pointed questions from supervisors about who is really in control.
Running a MiCA Operational Readiness Assessment (Checklist + Scoring)
By this point, you’ve seen what MiCA‑ready governance, systems, controls, and evidence look like in isolation. This section collapses everything into one practical assessment you can run in 60–90 minutes with your founders, COO, MLRO, and key team leads.
Use it as your working MiCA compliance checklist: copy the structure into your tracker, score yourselves honestly, and turn the gaps into a build plan and board‑level narrative.
The Checklist Itself (Printable / Copy‑paste Friendly)
You don’t need a fancy tool to start. Take the list below and turn it into a table with columns such as:
Item code
Description
Score (0–3)
RAG (Red / Amber‑ / Amber+ / Green)
Owner
Target date
Evidence link
Re‑use the same scoring scale from earlier:
the 0–3 / Red‑to‑Green model defined in the “How to Use This MiCA Compliance Checklist” section.
Then work through the checklist category by category.
Governance & Key Roles (GOV)
GOV‑1 – Board ownership of CASP strategy and risk.
Board has formally approved the CASP business model and services in scope; this is visible in board or committee minutes.
GOV‑2 – Documented risk appetite for CASP activities.
There is a written risk appetite statement (or equivalent) covering key MiCA risks (business, conduct, financial crime, operational, custody, outsourcing) that the board has approved.
GOV‑3 – Board‑level AML/CFT and compliance owner.
At least one management‑body member explicitly owns AML/CFT and conduct risk in their mandate, and this is reflected in governance maps and terms of reference.
GOV‑4 – MLRO appointment and reporting.
MLRO is formally appointed with a job description, has a direct reporting line to the board or risk/compliance committee, and provides at least quarterly reports.
GOV‑5 – Risk management function.
A risk register exists that names your services, key risks, and mitigants, and has been reviewed by management and the board within the last 12 months.
GOV‑6 – Independent challenge / internal audit.
At least one independent review (internal or outsourced) has been completed on a high‑risk area (e.g. custody, transaction monitoring), with findings and actions tracked.
Systems & Architecture (SYS)
SYS‑1 – Documented customer lifecycle and systems.
The end‑to‑end customer journey (prospect → onboarded → active → reviewed/offboarded) is documented, with the systems and owners for each step clearly mapped.
SYS‑2 – AML/KYC tooling configured and tested.
Your onboarding/KYC stack (internal and vendor) is configured, integrated, and has been tested end‑to‑end with real or realistic test customers.
SYS‑3 – Transaction monitoring coverage and rules.
All relevant flows (deposits, withdrawals, internal transfers, trading, fiat legs) are in scope; monitoring rules/scenarios are documented with owners and review dates.
SYS‑4 – Case management and escalation.
There is a workflow for alerts (triage, investigation, escalation, closure) implemented in a tool or clearly defined process, with examples of closed cases.
SYS‑5 – Custody and wallet architecture.
Current wallet/custody architecture diagrams exist, showing segregation of client vs firm assets, hot/warm/cold strategy, and key vendors.
SYS‑6 – Key management and reconciliations.
Key generation, storage, access control, and rotation are described in SOPs/runbooks; daily reconciliations between on‑chain and internal ledgers are performed and evidenced.
SYS‑7 – Regulatory reporting data paths.
You have identified all MiCA‑related and AMLD5 reports/notifications and can already extract the core datasets needed for them, even if formatting is still partly manual.
Controls, Policies, and Testing (CTRL)
CTRL‑1 – Core policy suite in place.
Policies and procedures exist and are approved for: governance/risk, AML/CFT and sanctions, onboarding/KYC, transaction monitoring, custody and safekeeping, operational resilience/cyber, outsourcing, conflicts/market conduct, and complaints.
CTRL‑2 – Policy ownership and review cycle.
Each policy has a named owner (by role), review frequency, and last review date; new joiners in relevant roles are trained on key policies within a defined timeframe.
CTRL‑3 – Control register for critical processes.
A control register or equivalent matrix exists for high‑risk processes (onboarding, monitoring, custody, withdrawals, incident response), with control objectives, activities, owners, and evidence sources populated.
CTRL‑4 – First‑line controls operating.
Operational teams can show that key controls (e.g. EDD approval, dual authorisation, reconciliations) actually happen and leave a trace in systems or logs.
CTRL‑5 – Second‑line oversight and MI.
Compliance/risk perform regular QA or thematic reviews over high‑risk areas and produce management information (MI) that goes to the MLRO and board.
CTRL‑6 – Testing plan and execution.
There is a documented, risk‑based plan for testing key controls; at least some testing (QA, thematic reviews, or internal/outsourced audits) has been performed in the last 12–18 months.
CTRL‑7 – Drills and incident simulations.
You have run at least one tabletop or simulation of a major custody, fraud, or operational incident in the last 12–18 months and updated runbooks based on lessons learned.
Evidence & Outsourcing (EVD)
EVD‑1 – Governance evidence vault.
You can assemble a complete set of board and committee packs/minutes covering CASP strategy, risk appetite, outsourcing, and custody decisions for the last 12–18 months within two working days.
EVD‑2 – Architecture and system inventory.
Up‑to‑date architecture diagrams and a system inventory exist for all MiCA‑relevant systems, with owners and hosting locations recorded.
EVD‑3 – Monitoring and case history.
You can show at least several months of monitoring and case‑management data (alerts, investigations, decisions), even if volumes are still ramping up.
EVD‑4 – Issues and remediation tracker.
There is a central log for findings from QA, reviews, audits, and incidents, with owners, target dates, and closure status.
EVD‑5 – Outsourcing due diligence and contracts.
All critical outsourcings (KYC, monitoring, custody, cloud, core banking/ledger) have documented due diligence, signed contracts/SLAs, and named business owners.
EVD‑6 – Ongoing vendor monitoring.
Periodic vendor performance and risk reviews are documented (KPI/KRI reports, review notes, incident reports) and are visible in governance minutes where relevant.
In practice, you’ll probably add a few firm‑specific rows (for niche services or bespoke risks). The point is that every major MiCA pillar is represented, you can assign ownership, and you can link each score to concrete evidence.
Typical Timelines and Critical Path Items
Once you’ve scored the checklist, resist the urge to obsess over a single number. Instead, look at three things:
Where are the 0/Red scores?
Where are 1/Amber‑ scores sitting in obviously high‑risk areas?
How many 2/Amber+ and 3/Green items do you have in each pillar?
As a rough rule of thumb for CASPs:
You should aim to have no 0/Red items in high‑impact areas (board/MLRO, custody, transaction monitoring, incident response, critical outsourcing) before you file.
Most high‑impact items should be at least 2/Amber+ by the time you submit your application, with a clear plan and timeline to get them to 3/Green.
Lower‑risk, back‑office items can sit at 1/Amber‑ at filing, as long as you can show a credible remediation plan that is already in motion.
How long does it realistically take?
Timelines vary by jurisdiction and starting point, but founders consistently underestimate how long it takes to move an item from 0 to 2 or 3. If you’re weighing Lithuania as a lead NCA, our data-driven insights on the Lithuanian VASP industry – a 2025 snapshot gives a realistic view of how that market and its supervisors already look in practice. As a directional guide:
Governance & roles
Appointing or reshaping the board, clarifying mandates, and standing up committees: 3–6 months, depending on recruitment and regulatory fit‑and‑proper checks.
Building a risk register, risk appetite, and getting them properly discussed at board level: 2–4 months from first workshop to signed‑off documents and minutes.
Systems & architecture
Selecting and contracting with key vendors (KYC, monitoring, custody): typically 2–4 months including due diligence and procurement.
Integrating and configuring those systems end‑to‑end, and running meaningful pilots in test or sandbox environments (not live, unlicensed client flows): 3–6 months, often in parallel with other work.
Controls, policies, and testing
Writing and approving a coherent policy suite and SOPs: 1–3 months if you have experienced owners; longer if you’re starting from templates.
Designing a control register and running the first round of QA/thematic reviews: 2–3 months.
Evidence and history
Accumulating 6–12 months of rich monitoring logs, QA samples, and board reporting is a longer‑cycle task. New CASPs won’t have a full production history before authorisation, but you should still plan for at least a few months of internal dry‑runs and test‑environment activity (using synthetic data, vendor test cases, or, where permitted, regulatory sandboxes) so you can demonstrate how monitoring, investigations, and reporting will work from day one of your licence – and then build real history once you are authorised. You should not run live client flows that require a licence before you are allowed to.
The critical path is usually a mix of:
Getting the right people in place (board, MLRO, risk, internal audit or equivalent).
Making irreversible architecture choices (custody model, monitoring stack) and proving they work.
Building enough operational history and evidence that your controls look lived‑in, not theoretical.
If your assessment shows multiple high‑risk items at 0/Red (for example: no MLRO, no monitoring engine, no custody design, no outsourcing oversight), you are likely 6–9+ months away from a credible MiCA application, even if the legal memo is ready. If most high‑risk items are already at 2/Amber+ and your gaps are in lower‑risk areas, you may be 2–4 months away, assuming you keep executing.
Turning scores into a board‑ready story
Finally, don’t keep the checklist in a drawer. Turn it into a simple, recurring artefact:
Heatmap for the board. Roll the item‑level scores up into a one‑page view per pillar (Governance, Systems, Controls, Evidence) and present it at least quarterly.
Action log. For every 0/Red and 1/Amber‑ item, record the action, owner, and target date in your remediation tracker and reference it in MLRO or COO reports.
Trend line. Re‑run the assessment every 3–6 months and keep old versions. Supervisors care as much about direction of travel as about the exact score on day one.
When a supervisor asks, “How do you know you’re MiCA‑ready?”, you want to be able to show not just a legal gap analysis, but a living operational checklist, clear scores, and an evidence‑backed roadmap that the board is already tracking.
When Readiness Shows You Need EMI/PI or CASP+ (Strategic Pivot)
Sometimes the most valuable outcome of a MiCA readiness assessment is not a score, but the realisation that you’re aiming at the wrong licence configuration. Many founders start with “we just need a CASP licence”. Then they discover that their roadmap quietly includes payment accounts, cards, or stablecoins that look a lot like e‑money.
This section won’t give you legal advice or a perfect decision tree. That lives in your CASP vs EMI vs PI work with counsel. It will help you read your own checklist results for signals that a CASP‑only path is too narrow.
When a CASP‑only licence is probably enough
Your MiCA operational readiness work is broadly pointing towards a “CASP‑only is fine” world if all of the following are true:
You do not hold client fiat funds in your own payment accounts – a bank or authorised payment institution handles client money, and you only ever see cryptoassets and fee revenues.
Clients cannot pay third‑party merchants or bills from their balances with you; usage is limited to trading, investing, custody, or on/off‑ramping via regulated partners.
You are not issuing stablecoins or tokens that promise par‑value redemption in fiat; you list or custody such assets for clients, but you are not the issuer.
Your product and marketing language clearly describe you as a trading / investment / custody platform, not as a current account, e‑money wallet, or payment app.
In that pattern, the MiCA checklist you have just run is primarily about CASP scope: governance, custody, AML, conduct, and operational resilience around crypto‑asset services. You still need to think about payment partners, safeguarding, and DORA, but the regulatory “anchor” is MiCA.
Red flags that you might need EMI/PI on top of (or instead of) CASP
As you work through governance, systems, and controls, watch for items that feel oddly complex for a CASP‑only business. Typical red flags include:
Client fiat balances behave like payment accounts.
Clients hold significant fiat balances with you for extended periods, not just during an on/off‑ramp.
They can make payments to third parties (e.g. merchants, billers) from those balances.
You issue cards or payment instruments linked to client balances.
Debit cards, virtual cards, or other instruments that can be used at the wider card/payment network, funded from balances on your platform.
You are effectively issuing e‑money or e‑money‑like stablecoins.
Clients give you fiat, you issue a token or balance that is redeemable at par and marketed as cash‑equivalent stored value.
Operationally, you are running safeguarding, segregation, and redemption processes that look very similar to an e‑money institution.
You run merchant acquiring or payout flows.
You collect fiat from payers and settle to merchants or partners, even if the underlying asset is crypto at some point in the flow.
Your board papers and product roadmap talk about “replacing a bank account”.
If internal decks describe you as “crypto current account”, “borderless euro account”, or similar, supervisors will quickly ask why you think MiCA alone is sufficient.
If stablecoins sit at the centre of your model, pair this checklist with our MiCA stablecoin regulation guide and two companion pieces – Stablecoins under the hood – what keeps them stable (or not) and Stablecoin adoption beyond the numbers – why automation isn’t the problem – so your licensing and operational decisions are grounded in how these tokens really behave.
When several of these show up in your operating model, your MiCA readiness checklist will also start to look like an EMI/PI checklist: safeguarding rules, daily reconciliations of fiat client money, additional capital and liquidity thinking, more demanding incident and outage playbooks.
That is usually the moment to pause and ask, with your lawyers and advisors:
Are we actually designing a payment institution (PI) or electronic money institution (EMI) on top of the CASP?
Do we need a group structure where one entity is the CASP and another is the PI/EMI?
Is there a staged path (e.g. CASP first, then PI/EMI once we have more evidence and capital), or should we design for both from day one?
What “CASP+” looks like operationally
Even if you stay within CASP scope, your readiness work may show that you are effectively building a CASP‑plus operation:
Multiple CASP permissions (exchange, brokerage, custody, advice, portfolio management) under one roof.
Complex cross‑border set‑ups (passporting, branches, or tied agents) that require more mature governance and risk functions.
Heavy reliance on outsourced critical functions (custody, KYC, monitoring, core ledger) that look, in scale and criticality, very similar to what you would see in a PI/EMI.
In practice, this means that even if you don’t need a separate payment licence, your governance, systems, and controls will need to be much closer to the “grown‑up” end of the spectrum. Your MiCA checklist scores should then be interpreted with that in mind: a CASP‑plus model with a lot of moving parts has far less room for 0/Red scores in outsourcing, resilience, and testing.
Using your readiness assessment to drive the pivot conversation
The point of this section is not to re‑run legal scoping, but to give you a structured way to talk about it with your board and advisors.
Take your completed MiCA readiness tracker and look for clusters:
Do you have a high concentration of items about fiat safeguarding, payment flows, cards, or merchant payouts?
That’s a strong hint you should revisit the PI/EMI vs CASP question.
Are you already designing bank‑grade reconciliation, liquidity, and incident routines because “otherwise the product doesn’t work”?
You may be under‑estimating the licence mix and capital/operational commitments required.
Does your product team keep adding features that make you look and feel like a payment account or e‑money wallet, even if the current legal scope says “CASP only”?
Better to confront that mis‑match early, while you can still reshape the roadmap.
Use the checklist as a neutral artefact in those conversations. It’s easier to discuss “this stack of controls looks a lot like an EMI” than to argue over slogans. From there, you can drop into a more detailed CASP/EMI/PI comparison guide and formal scoping with your legal team.
For the legal and supervisory side of that comparison – how MiCA CASP permissions interact with EMI/PI regimes in practice, typical supervisor expectations, and country‑by‑country wrinkles – pair this operational view with our EU Licensing Requirements for CASPs guide.
FAQ – MiCA Compliance and Operational Readiness
Q1. What are the MiCA compliance requirements for CASPs in 2025?
MiCA requires CASPs to meet standards in four areas: governance and fit & proper, client‑asset protection, systems and conduct controls, and operational resilience/outsourcing. In practice, you need a supervised‑ready management body, custody model, AML/monitoring stack, and resilience/outsourcing framework that already work in production, not just on paper. See the governance, systems, controls, and evidence sections above for detail.
Q2. What governance roles and committees must be in place before applying?
You should be able to show, at minimum: a competent board, a board‑level AML/CFT and compliance owner, a MLRO with sufficient independence and capacity, someone owning risk management, and access to independent assurance (internal or outsourced audit). Larger CASPs will usually back this with formal risk/compliance and audit committees; smaller firms can combine roles but must still show who challenges the business and where the evidence lives.
Q3. What systems and controls do regulators expect (AML, monitoring, reporting)?
Supervisors expect a joined‑up stack, not just vendor logos. At a minimum you need:
AML/KYC and screening embedded in onboarding and ongoing monitoring.
Transaction monitoring and case management with clear escalation and STR/SAR decisions.
A robust custody/wallet set‑up, reconciled books and records, and credible paths for regulatory reporting.
Your policies, SOPs, control register, QA, and testing should then prove these controls actually run day‑to‑day.
Q4. What evidence/documentation is submitted with a MiCA CASP application?
Formally, you submit a Program of Operations, business plan, financials, detailed service and systems descriptions, and a policy/procedure pack (plus jurisdiction‑specific annexes). Practically, NCAs may also ask for governance minutes, risk and architecture artefacts, control registers, monitoring and QA logs, audit/thematic review reports, and outsourcing files. The evidence section above is structured as a checklist of these underlying artefacts.
Q5. How do I run a MiCA operational readiness assessment and what are typical timelines?
Copy the checklist from this article into your own tracker, scope it, score each item 0–3 / RAG based on real evidence, and turn every 0/Red and 1/Amber‑ into an action with an owner and date. As a rule of thumb: expect 3–6 months for governance and roles, 5–10 months to select, integrate, and test core systems, 1–3 months for policies and control design, and another 2–3 months for the first QA/review cycle once those controls exist.
Q6. Do I only need a MiCA CASP licence, or also EMI/PI?
If you only provide trading, investment, or custody services and rely on regulated partners for fiat on/off‑ramp, a CASP‑only licence may be sufficient. If clients hold fiat balances with you, can pay third parties, use cards linked to their balances, or hold par‑redeemable e‑money‑like stablecoins you issue, you should treat your readiness results as a signal to revisit EMI/PI vs CASP scope with your lawyers and consider whether you need a combined or sequenced licensing strategy.
MiCA Readiness Review / Book a 20‑min Mapping Call
If you’ve worked through this MiCA compliance checklist and still aren’t sure whether you’re 2, 6, or 9+ months away from a credible application, a short working session with someone who does this every week is usually the fastest way to get clarity. That’s what this 20‑minute MiCA Readiness Review is for – and it’s also how we decide whether you need a Strategy Architecture Sprint, Fractional Advisory, or a deeper Operational Architecture Build‑out, or simply a sharper internal plan.
What we’ll cover in 20 minutes
5 minutes – Quick context. Your CASP services, jurisdictions, target filing date, and where you think you are today across governance, systems, controls, and evidence.
10 minutes – Walk through your scores. A focused review of your key Red/Amber items in the four pillars (Governance, Systems, Controls, Evidence), calling out anything that sits on the critical path or hints that you might need CASP+ or EMI/PI permissions.
5 minutes – Match gaps to next steps. A realistic view of what must be in place before you file, what can follow post‑authorisation, and whether your gaps are best solved by a 2–3 week Strategy Architecture Sprint, ongoing Fractional Advisory, a hands‑on Operational Architecture Build‑out, or internal delivery.
What you leave with
A short follow‑up email summarising your readiness heatmap, top 5 actions, and an indicative timeline to a credible application.
A neutral view on whether your roadmap looks like CASP‑only or CASP + EMI/PI, so you can calibrate next steps with your lawyers and board.
One practical way to plug this checklist and your scores into your board pack or Program of Operations planning, instead of starting from a blank slide.
Clear options for how we could help – from a Strategy Architecture Sprint (define model, architecture, regulatory path, and roadmap), through Fractional Advisory (weekly senior guidance and decision support), to a larger Operational Architecture Build‑out (implementing monitoring, workflows, controls, and licensing readiness) – with zero obligation to pick any of them.
The session is designed for founders, COOs, MLROs, and board members who want an external sense‑check rather than a generic “intro call”. There’s no heavy prep beyond a rough sense of your current gaps, and no slide‑deck sales pitch. If you’d like that outside view, use the “Book a 20‑min MiCA mapping call” link on this page to pick a slot and share two or three lines about your firm.
If you’d rather understand where we fit in the ecosystem before booking time, you can skim What we do at ASD Labs for a straight overview of our strategy, advisory, and operational architecture work.
Comments