MiCA Compliance After the Licence: The Operational Governance Most CASPs Are Missing
- Mar 31
- 17 min read
~15 min read – A diagnostic piece for licensed CASPs whose governance arrangements exist on paper but not in practice. Not a compliance checklist. Not a software pitch. A pattern you'll either recognise immediately or bookmark for your next board meeting.
You got your MiCA licence. Your firm is among the growing list of CASPs in the ESMA register that made it through the application process. Your policies are written. Your compliance officer is named. Your governance framework is documented.
Now ask yourself: if your NCA sent an examiner next month, could your management body demonstrate – with evidence – how governance decisions are actually made, who owns every regulatory function, and where the audit trail lives?
Not the policy manual you submitted with the application. The actual, functioning governance system – the one where decisions are logged, responsibilities are exercised, risks are surfaced weekly, and the board can demonstrate that it governs.
Most licensed CASPs can't show this. Not because they failed the application – because MiCA compliance after authorisation requires an operational governance layer that most firms never built. The application tested whether you documented the right things. Post-authorisation supervision tests whether you do them. And the gap doesn't show up during a supervisory visit first. It shows up every week – in the decisions that don't get made, the meetings that produce nothing, and the evidence that doesn't exist.
This article maps that gap. It starts with a Monday morning you'll recognise, diagnoses the pattern underneath, explains why the common fixes don't stick, and lays out the five operational components that supervisors actually test. If you're still preparing your application, start with our MiCA compliance checklist. This is what comes after.
Jump to:
Key Takeaways
60-second summary
The pattern: Licensed CASPs pass the MiCA application by documenting governance policies – but the policies aren't operational. When a supervisor examines the firm, the gap between "documented" and "functioning" is where findings land.
Why quick fixes fail: Hiring a compliance officer, buying a GRC platform, or adopting an off-the-shelf policy pack doesn't work without the operational infrastructure underneath. The policy assumes a functioning governance layer; most CASPs at this stage don't have one.
The five components: An authority matrix with documented decision rights, a weekly governance cadence, named ownership of every regulatory function (with deputies), auditable systems of record, and visible accountability through board-level compliance reporting. None are complicated. All are hard to install.
The test: If your NCA sent an examiner tomorrow – could your management body demonstrate how decisions are made, who owns what, and where the evidence is? Or would the answer be "it's in the policy document"?
What to do: Read to self-diagnose. If the pattern fits, The Honest Part explains how to get the governance layer built – internally or with help.
The Monday Morning You Know Too Well
It's Monday morning. Whether you're the CEO, the COO, or the compliance officer – you're the person who's supposed to make governance work at your CASP. Today, it isn't working.
You open your inbox to an email from the national competent authority – a request for information about your client onboarding governance. Due in 10 business days.
You ask the team: "Where's the documentation for the last three months of onboarding decisions?" The answer: partly in the compliance officer's email, partly in a Slack thread, partly in the head of the onboarding analyst who left in November.
Then the weekly management meeting. It was supposed to cover the AML risk appetite review, the new token listing decision, and a client complaint that escalated last Friday. It runs for 90 minutes. Nobody prepared written updates. "Status" means each person explaining what they've been doing. The token listing decision gets debated but not resolved – again – because nobody can confirm what was agreed two weeks ago.
By lunch, the CEO has personally arbitrated four decisions that should have been handled by function owners: whether to file a suspicious activity report, whether a new product variant needs a separate risk assessment, who approves changes to the transaction monitoring rules, and whether the IT incident from Thursday is reportable under DORA. None of these required the CEO. All of them were routed upward because nobody knew who else was authorised to decide.
You think: this team can't handle the basics.
They can. Your MiCA compliance governance exists on paper. It doesn't exist in practice.
The Governance Gap: MiCA Compliance on Paper vs. in Practice
I see the same pattern in every CASP that passed its application but hasn't built the operational layer beneath the policies. The governance framework was designed for the application file. It was never designed to actually run.
Article 68 of MiCA requires crypto-asset service providers to have "sound governance arrangements, including a clear organisational structure with well-defined, transparent and consistent lines of responsibility." Every licensed CASP documented this in their application. Very few have it running as a live system.
The governance gap has a consistent shape. If you're running a licensed CASP, you'll recognise at least three of these:
Nobody can make a decision without the me. Not because the team is incompetent – because nobody knows who's authorised to decide what. The authority matrix exists in the governance policy, but it's a static document nobody references. So every material decision routes upward to the one person the team trusts: you. The regulator calls this concentration-of-function risk. Your team calls it "just checking."
Governance meetings produce nothing. You have them. Maybe weekly. But nobody submits structured updates beforehand, nobody records decisions with rationale, and the same topics cycle back week after week because nothing was formally settled. The compliance officer raised the AML risk appetite review three meetings ago. It's still "pending."
There is no institutional memory. Decisions, commitments, follow-ups, open regulatory actions – they live in the compliance officer's head, in scattered emails, in a Slack channel nobody remembers. If your MLRO left tomorrow, every in-flight SAR, every pending escalation, every verbal agreement with the regulator would go with them. The firm is the people who remember things. That's not compliance – that's organisational fragility.
You rely on heroics instead of systems. The compliance officer works late to chase down missing evidence for a regulatory return. The risk manager manually reconciles data because the systems of record don't talk to each other. Your best people spend their time compensating for missing governance infrastructure. They're busy – but are they building the firm's compliance capability, or just keeping the chaos manageable?
Priorities shift with every regulatory email. An ESMA consultation drops. A client complaint escalates. The NCA requests a data extract. Each event reshuffles the week because there's no governance cadence that holds priorities in place. The team is reactive, not governed.
Policies exist but aren't referenced. You have a complaints handling policy. A client categorisation policy. An outsourcing policy. They were written for the application. They sit in a shared drive. When an actual complaint arrives, someone asks the compliance officer what to do – nobody opens the policy, because the policy doesn't map to a working process.
If three or more of those resonated, the problem isn't your team. It's the missing operational layer between your documented governance framework and your firm's daily practice.
Why Policy Documents, GRC Tools, and Compliance Hires Don't Fix It
Before they find a real solution, most CASPs try the obvious things. None of them stick – and understanding why they don't stick is more valuable than trying the next one.
What CASPs try | Why it falls short |
Hire another compliance officer | You now have two people operating in the same chaos. Without a governance system around them, the new hire inherits the same unclear decision rights, the same unstructured meetings, and the same missing evidence trail. They become busier, not more effective. |
Buy a GRC platform (Vanta, Drata, LogicGate, or a bespoke compliance tool) | A tool is not a system. It does not define who makes decisions, how governance meetings are run, or what happens when remediation actions slip. Without the operating layer underneath, a GRC platform becomes little more than a polished document repository – a dashboard that looks impressive and quietly goes unchecked. |
Commission more policies (from a law firm or consultancy) | Policies describe what should happen. They do not make it happen. A firm with 40 policies and no governance cadence is less compliant than a firm with 10 policies that are actively used, tested, and enforced. For most licensed CASPs, the real problem is not a policy gap – it is an execution gap. |
Push through it (heroics) | The compliance officer tracks everything personally, works weekends ahead of regulatory deadlines, and holds the function together through institutional knowledge and sheer willpower. This works right up until they burn out, go on holiday, or leave. Then the firm discovers that its compliance capability was never institutionalised – it was embodied in one person. |
The pattern is always the same: something gets implemented, it feels productive for two weeks, then it decays back to a handful of people manually holding the governance together. Not because the team resisted – because the operational infrastructure beneath the policies was never installed.
Think of it this way: your governance policies are the rules of the road. Your GRC tool is the vehicle. But the road itself – the infrastructure that makes policies operational and tools useful – is the governance system. Most licensed CASPs built the rules and bought the vehicle, but never laid the road.
What MiCA Compliance Actually Requires: Five Operational Components
Here's the road.
Every symptom above – your (CEO, COO, CCO) bottleneck, the meetings that produce nothing, the scattered evidence, the reactive fire drills – traces back to the same root cause: there is no operational layer between your governance policies and your daily practice. The policies assume this layer exists. It doesn't.
I call this layer operational governance infrastructure. Not a framework. Not a tool. Five structures that let a CASP operate its governance as a functioning system, rather than depending on individual effort. Each one maps to a specific breakdown from the Monday morning above. After the five, we'll replay the same Monday with the infrastructure in place.
Authority matrix and decision rights
Who can decide what, at what threshold, with what evidence. Not "we have a governance policy that mentions decision-making" – a live, referenced authority matrix: the compliance officer decides this, the MLRO escalates that, above this risk threshold the board approves, below it the function owner handles it. Documented. Referenced weekly. Enforced.
MiCA Article 68 requires "well-defined, transparent and consistent lines of responsibility." An authority matrix is how you prove this to a supervisor – not as a policy annexe, but as a working document your team actually uses.
Without documented decision rights, every material decision routes upward – exactly like the four decisions that landed on the CEO's desk by lunch. SAR filings, client offboardings, policy amendments – all routed to the one person the team trusts, because nobody clarified who else was authorised. This isn't a people problem – it's a design problem.
What a supervisor will ask: "Show me how a decision to restrict a client account is made. Who has the authority? Where is this documented? Show me the last three instances."
A weekly governance cadence
Not "we have a weekly meeting." A cycle: function owners submit structured written reports before the meeting – what progressed, what's blocked, what regulatory actions are pending, what decisions are needed. The meeting itself is focused on decisions and exceptions – not the 90 minutes of verbal updates that resolved nothing. After the meeting, decisions are logged with rationale, follow-ups are assigned with owners and deadlines, and the systems of record are updated.
MiCA's ongoing supervision obligations (Article 68 governance, combined with ESMA guidelines on post-authorisation monitoring) assume a regular rhythm for surfacing and resolving compliance issues. Without a governance cadence, problems surface only during crises – or during supervisory visits, which is worse.
What a supervisor will ask: "How frequently does management review operational and compliance risks? Show me the minutes and follow-up actions from the last month."
Named ownership of every regulatory function
Every material compliance function has a named owner and a named deputy. Not "the compliance team handles it" – a specific person who answers for AML/CTF, a specific person who answers for complaints handling, a specific person who answers for IT security, a specific person who answers for outsourcing oversight. When something breaks, there's no ambiguity about who owns the remediation. When someone goes on leave, their deputy steps in without a handover scramble.
Article 68 requires clear lines of responsibility. ESMA's guidelines specify that CASPs must designate responsible persons for compliance, AML, risk management, IT security, and complaints handling – with documented deputies for business continuity.
This sounds obvious. It almost never functions in practice. Ask yourself right now: if your MLRO took two weeks of leave starting tomorrow, who exactly would file the SAR on Thursday? If you had to think about it for more than a second, you don't have named ownership – you have named roles on an organisational chart that nobody operationalises.
What a supervisor will ask: "Your MLRO was on leave for two weeks in November. Who was acting? Where is the delegation documented? Show me the SARs filed during that period."
Auditable systems of record
A decision log that records what the board or management body decided, when, with what rationale, and when to revisit it. An action tracker that shows what remediation was committed and whether it was delivered. Reporting templates that produce consistent, comparable governance updates every week.
Not a tool – a discipline. You can run this in Google Sheets if you maintain it. The point is that when you need three months of governance decisions – because the NCA asked, or the supervisor visited – the evidence exists in one place. Not in someone's email, not in Slack, not in the head of an analyst who left in November. Article 68 governance records, Article 71 complaints-handling procedures, AML/CTF record-keeping obligations – supervisors don't test whether you have a policy. They test whether you can show what happened, when, by whom, and why.
The moment nobody updates the decision log, it dies – and you're back to institutional memory living in one person's head. That's the opposite of functioning governance.
What a supervisor will ask: "The board revised your AML risk appetite in Q2. Show me the meeting record, the rationale, and the subsequent changes to your transaction monitoring rules."
Visible accountability through compliance reporting
Not punishment. Visibility. When the board can see what was committed and what was delivered – open incidents, SAR filing status, regulatory deadline tracker, control testing results, remediation progress – governance happens naturally. People don't need someone standing over them. They need a system that makes their commitments visible to the management body and, ultimately, to the supervisor.
Article 68 (management body oversight) and ESMA's guidelines on the compliance function require periodic reporting to the board on the state of compliance. This isn't a policing exercise – it's making governance visible so the board can actually govern, and the supervisor can verify that it does.
This is the component most firms resist, because it applies to the board too. Visible accountability means the board's own commitments – the remediations they approved, the risk appetite decisions they signed off on – are also tracked and reported. That's the point.
What a supervisor will ask: "How does the management body oversee the compliance function? Show me the last three board reports on compliance status."
These five components together form the operational layer that your governance policies assume already exists. Build this layer first. Everything else – your GRC tool, your regulatory reporting, your supervisory responses – works better once the infrastructure is in place.
The Same Monday Morning – With Operational Components in Place
Same inbox. Same NCA information request. Same AML review on the agenda. Same incidents queuing up. But this time, the five components are running.
You open your laptop. Written governance inputs from every function owner are already in the shared folder – submitted Friday afternoon. Not status updates – structured regulatory reports from Key Roles: open compliance actions, pending SARs, upcoming regulatory deadlines, risk incidents requiring a decision, and any control deficiencies flagged during the week. You review them in 20 minutes. You know the compliance posture of the firm without asking a single person.
At 10:00, the weekly governance forum starts. There's a pre-set agenda derived from the reports. The blocked items get discussed first. The AML risk appetite review is resolved – the decision is logged on screen with the rationale, the approver, and the review trigger date. Two remediation actions from last week are reviewed: one is complete, one is delayed with a documented reason. The meeting ends in 50 minutes.
The compliance officer updates the action tracker and circulates the meeting summary within the hour. Decisions were made at the right level – the designated function owners handled them, with the authority matrix as the reference. The CEO wasn't pulled into any decision that didn't require the management body.
The NCA's information request from the morning? The compliance officer pulls the last three months of onboarding decisions from the decision log, attaches the relevant meeting minutes, and drafts the response by Tuesday. No scramble. No archaeology through email threads. The evidence exists because the governance system produces it every week.
It won't feel like this on week one. Week one feels like overhead – another meeting, another template. By week six, the cadence carries itself. By week twelve, you'll field a supervisory request and realise the evidence was already sitting in your governance folder. That's the difference between compliance on paper and compliance in practice.
What a Supervisory Visit Actually Tests
NCA examiners don't audit your policies. They audit your practice. The policies were assessed during the application. Post-authorisation supervision tests whether the governance arrangements you documented are actually functioning.
Here's what that looks like, mapped to the five components:
Component | What the supervisor asks | What “good” looks like | What a finding looks like |
Authority matrix | “Who authorised this client offboarding? Show me the decision trail.” | Delegated authority is clearly documented in the authority matrix. The decision is logged with date, rationale, and approver. Three comparable examples can be produced within minutes. | The CEO made the decision verbally. No log exists. The team responds with, “We just knew.” |
Governance cadence | “Show me your management body’s review of operational risks over the last quarter.” | Weekly governance meetings are supported by structured agendas, formal minutes, recorded decisions, and action items tracked through to completion. | There was a monthly meeting, but no minutes. Or the minutes simply state: “AML risks discussed – actions TBD.” |
Named ownership | “Your compliance officer was on leave for three weeks. Who acted in their place, and what did they do?” | A deputy is formally identified in the organisational structure. A delegation letter is on file. Evidence shows the deputy signing off on compliance matters during the relevant period. | “The CEO covered it.” No supporting documentation. Concentration-of-function risk is immediately apparent. |
Systems of record | “The board approved a revised complaints handling procedure in September. Show me the decision record and evidence of implementation.” | Board minutes capture the decision, rationale, and implementation timeline. An action tracker shows completion of the required steps with dates. The updated procedure is version-controlled and distributed to the relevant team members. | “We think it came up in a meeting. Let me check my emails.” |
Visible accountability | “How does the management body oversee the compliance function?” | The board receives a quarterly or monthly compliance report supported by a dashboard covering open incidents, SAR filings, regulatory deadlines, control testing results, and remediation status. Board minutes confirm that the report was reviewed and discussed. | “The compliance officer reports to the CEO informally.” No documented evidence of board-level oversight exists. |
This table is the difference between a clean supervisory outcome and a list of findings that triggers enhanced monitoring. Every finding maps back to one of the five missing components.
A Self-Check Before You Stop Reading
If your NCA sent an examiner tomorrow, could your management body demonstrate – with evidence – how governance decisions are made, who owns every regulatory function, and where the audit trail is? Or would the answer be "it's in the policy"?
If the answer is "it's in the policy," your MiCA compliance governance isn't operational yet. The policies aren't the problem. The missing layer between what's documented and what actually happens – that's the problem. And the longer you compensate for it with individual effort, the more your firm's compliance capability depends on specific people's bandwidth, which doesn't survive a holiday, a resignation, or a supervisory visit.
One more:
How many governance decisions got lost, reversed, or re-debated in the last quarter because nobody could point to when they were made, by whom, or with what rationale?
If you can name one immediately, it's on your mind. If you can name three, it's costing more than you think – in re-work, in regulatory risk, and in the credibility of every governance meeting you run.
The Honest Part
It's a pattern I've seen, lived in, and built the solution for – at a registered CASP that was going through MiCA application process where I helped install the operational governance layer from scratch.
Policies existed. The compliance function was staffed. But the governance wasn't operational. Decisions routed through two people. Meeting minutes were inconsistent. The compliance officer was the institutional memory. When the regulator asked for evidence of a governance decision, it took days to reconstruct.
I installed the system: an authority matrix the team actually referenced, a decision log that stopped the revert cycle, a weekly governance forum with structured reports and documented outcomes, named deputies for every regulatory function, and a compliance dashboard the board reviewed monthly.
Within a few weeks, the change was visible. Governance meetings had structure and didn't overrun. Decisions held because they were logged – no more re-debating what was agreed last month. The application file had real evidence behind it, not reconstructed narratives. The system was producing the governance artefacts that MiCA expects, and the team no longer depended on one person's memory to find them.
The system works. The question is whether you'll build it – internally, with a dedicated hire, or with help.
But the first step is always the same: stop treating this as a people problem. Your team isn't the issue. The missing operational layer between your policies and your practice is the issue.
Build the layer.
FAQ: MiCA Compliance
What is MiCA compliance?
MiCA (Markets in Crypto-Assets Regulation) is the EU's framework for regulating crypto-assets and their service providers. MiCA compliance means meeting both the application requirements – what you build to get the CASP licence – and the ongoing post-authorisation obligations– what you maintain to keep it. This article focuses on the second part: the operational governance layer that supervisors test after you're licensed.
How do you comply with MiCA after getting your licence?
Post-authorisation MiCA compliance requires operational governance, not just documented policies. Five components: a functioning authority matrix with documented decision rights, a regular governance cadence with structured reporting, named ownership of every regulatory function with deputies, auditable systems of record (decision logs, action trackers, meeting minutes), and visible accountability through board-level compliance reporting. Most CASPs have the policies on paper. Very few have them running as a live system.
Who enforces MiCA compliance?
National competent authorities (NCAs) – the regulator that issued your licence. ESMA coordinates at EU level and maintains the CASP register, but day-to-day supervision is national: Bank of Lithuania, BaFin (Germany), AMF (France), CSSF (Luxembourg), DNB (Netherlands), CBI (Ireland), and others. They will conduct on-site visits. They will ask for evidence. Your documented policies need to be operational, not just filed.
What does a MiCA supervisory visit look like?
The examiner reviews your governance arrangements against the application file you submitted. They ask for evidence: decision logs, governance meeting minutes, risk reports, SAR filing records, complaints handling logs, IT incident records. They interview key function holders – compliance officer, MLRO, risk manager. They test whether the governance policies you submitted are actually in use. The gap between "documented" and "operational" is where most supervisory findings land. See the supervisory visit table above for specific questions mapped to each governance component.
What are the requirements for a CASP under MiCA?
Beyond initial authorisation – capital requirements, fitness and propriety assessments, AML/CTF programme – CASPs must maintain ongoing governance (Article 68), prudential safeguards (Article 67), conduct of business rules (Articles 73–82), outsourcing governance (Article 83), and IT/cyber security requirements. This article focuses on Article 68 governance – the operational backbone that makes everything else function. For a comprehensive pre-application overview, see our MiCA compliance checklist.
What is the difference between MiCA and VASP regulation?
VASP regulation (under AMLD5) was a national registration regime – lighter, primarily focused on AML/CTF. MiCA is a fully harmonised EU-wide licensing regime with ongoing supervision, prudential requirements, conduct of business rules, and governance obligations. Former VASPs either obtained a MiCA licence or ceased operating – the transitional period ends in mid-2026 for most jurisdictions. The governance expectations under MiCA are materially higher than what VASP registration required, which is why many firms that passed the old regime are struggling with the operational reality of the new one. For more on this transition, see our analysis of the regulated crypto operating model under MiCA.
Comments