The day after authorization: What MiCA compliance looks like in practice
Getting a MiCA authorization is a project. What MiCA compliance looks like in practice, once you have it, is a different question entirely.
MoonPay was authorized in the Netherlands on December 31, 2024. We had the advantage of submitting early through an initial portal process, which meant by the time the regulation came into full effect, we had already been living across the EEA for eighteen months. That runway taught us something you cannot really learn from reading the regulations: the distance between a policy that satisfies an application and a framework that actually works is enormous.
Let me try to close some of that distance.
From AML to something much larger
The first thing compliance teams need to understand is that MiCA is not an extension of your existing AML regime. It is a different kind of regulatory animal.
Under a VASP framework, the risks were, broadly speaking, familiar. Money laundering. Terrorist financing. Concepts with a certain intuitive weight are understandable even to people outside the compliance function. MiCA adds an entirely new vocabulary: conflicts of interest, market integrity, financial safeguarding, and requirements that look far more like MiFID II than anything crypto compliance teams have typically worked with.
Getting the business to understand this shift is itself a challenge. You are not just building new controls. You are building new literacy across teams that have never had to think this way. And then, once your framework is in place, expect it to change. I describe our compliance framework to colleagues as a Jenga stack. We are constantly pulling pieces out and placing them on top. The business evolves. Products change. New typologies emerge. The stack never stops moving. The policy you submitted on day one will not be the policy you are running on day three hundred.
The regulator will ask for the details
Here is what I have found to be the single most important thing to understand about operating under MiCA: the scrutiny is different from what most crypto compliance teams have experienced.
Under VASP regimes, national competent authorities had meaningful room to apply their own interpretation. MiCA is designed to be uniform across the EEA. Whether you are authorized in Malta, Finland, or the Netherlands, the standard is supposed to be the same. ESMA sits above your national regulator and expects consistency. Your regulator knows this and will apply pressure accordingly.
What this means in practice is that the quality of your evidence matters far more than many teams anticipate. It is not enough to have the right policy. It is not enough to have implemented the right controls. You need to get into the data at a granular level and be able to demonstrate, on request, that what you said you would do is what you are actually doing.
At MoonPay, we use Unit21 for case management and transaction disposition. But that is the surface. The work is what sits behind it: validating outputs, testing thresholds, building QC programs, documenting the reasoning behind every material decision. The regulator will ask you to walk them through it. You need to be able to do that in a room, with a person across the table, and stand behind your answers.
AI can help you get there faster. We use it to draft SAR narratives, which cuts the time on a single filing roughly in half. That is not a small thing when you are filing at volume. But AI cannot sit in that room with you. The accountability rests with the responsible individual, and that will not change.
Market abuse: low risk is not zero risk
One of the MiCA requirements that catches teams off guard, particularly those whose background is primarily AML, is market abuse. For an on-ramp business like MoonPay, the inherent risk is low. High volume, low value transactions, limited exposure to the conditions that create market manipulation.
We concluded that. But we did not start with that conclusion. The foundation is the risk assessment, your CIRA or its equivalent, done honestly at the level of your actual business. Low risk still requires control. The extent of the control can be proportionate to the risk. The control itself cannot be absent.
What we did was configure our workflows in Unit21 so that every transaction flagged as unusual, whether because of velocity, value, or pattern, includes a market abuse review step. The probability of detecting market abuse in most of these cases is low. But the evidence that the question was asked, every single time, is exactly what a regulator wants to see. If you are subject to an inspection, you can point to the workflow and show that market abuse was considered on every relevant alert. That is defensible. Assumption is not.
The problem nobody has solved
I will be direct about this: the travel rule is an operational challenge that no one in the EEA has genuinely cracked.
The threshold is set at zero euros. Every transaction requires originator and beneficiary information to travel with it. That is already a significant lift. The harder problem is self-hosted wallets. The EBA guidelines give you several verification methods, and none of them work cleanly in practice. Cryptographic signatures fail at a fundamental level with UTXO models like Bitcoin, where you are dealing with a new wallet address on every transaction. The Satoshi test, where you send a small amount of crypto and ask the customer to confirm the amount, creates fraud exposure I am not willing to accept. Screenshots are not a serious verification method.
So you are left choosing between controls onerous enough to drive customers toward unregulated providers, and controls you know are not genuinely fit for purpose. That is the real choice. The industry has flagged it. Regulators have heard it. There are early discussions around MiCA 2.0, and some hope that the approach will shift toward something more risk-based, as the UK has done. For now, you implement the best control you can, document your reasoning carefully, and ensure your residual risk sits within your appetite.
What I would tell someone just authorized
Hire for the detailed work. Find people who want to get into data at a granular level, not just write good policies. Build a relationship with your local FIU. There are forums where you can get feedback on your approach without unnecessary exposure, and that feedback is genuinely useful when you are calibrating thresholds or deciding how to handle edge cases.
And do not underestimate the cost. Legal counsel, substance requirements, additional analysts on the ground in your jurisdiction, non-executive directors, prudential capital requirements based on revenue thresholds - it adds up quickly and keeps adding up. When you are communicating to senior stakeholders, and they are looking at the bill, the framing is straightforward: access to the EEA, the largest single market in the world, comes at a cost. The cost is worth understanding clearly before you commit to it.
The authorization is the beginning of the work, not the end of it.
