Crypto Licensing

CASP authorisation under MiCA: the full application timeline and what stalls it

If you’re planning to run a crypto business in the EU under MiCA, the big question usually isn’t “do we need authorisation?” It’s “how long is this going to take, really?” Fair question. Founders hear “submit the application” and imagine a neat process with a start date, a regulator review, and then a licence at the end. Nice idea. Real life is messier.

CASP authorisation under MiCA can move well if you’re organised, your structure makes sense, and your AML setup isn’t held together with Notion docs and hope. But plenty of applications slow down before they even get properly reviewed. And honestly, most delays are self-inflicted.

This is the full timeline as it usually plays out, what tends to stall it, and what you should fix early if you don’t want to burn months.


First, what MiCA authorisation actually covers

MiCA applies to crypto-asset service providers offering regulated services in the EU. That might include operating a trading platform, custody, exchange, transfer services, execution of orders, advice, portfolio management, and a few other activities depending on your model.

Sounds simple until you realise lots of firms don’t describe their own business properly. They say “we’re an exchange” when they’re really doing custody plus broker-style execution plus fiat on/off-ramp through partners. Or they call themselves a wallet app while controlling customer keys. Big difference.

Your application timeline starts with scope. If you get the activity analysis wrong, everything downstream gets ugly – legal docs, compliance framework, financial projections, outsourcing disclosures, even the org chart.

If you’re still at the structuring stage, getting proper advice on VASP registration & MiCA compliance saves a lot of backtracking later.


The real timeline – from idea to filing

People usually talk about “regulatory review time”. That’s only one slice of it. For most founders, the heavier part is pre-application work.

A realistic timeline usually looks something like this:

  • Stage 1 – Scoping and structure: defining services, target markets, legal entity, group structure, key people, outsourcing model
  • Stage 2 – Build-out: drafting policies, AML framework, governance documents, financial model, operational controls, IT and security documentation
  • Stage 3 – Pre-submission cleanup: fixing gaps, aligning documents, collecting due diligence packs from directors, shareholders, UBOs, vendors, and group entities
  • Stage 4 – Filing and regulator review: submission, completeness checks, follow-up questions, clarifications, document resubmissions
  • Stage 5 – Post-approval readiness: operational launch prep, banking, reporting, staff training, live control testing

The first three stages are where alot of teams lose time. Not because MiCA is impossible. Because they leave hard questions too late.

I’ve seen firms spend weeks polishing AML manuals while having no settled answer on where customer funds flow, who actually controls the platform, or whether the board members can pass fitness and propriety checks. That’s backwards.


Stage 1 – scoping usually takes longer than founders expect

This part looks deceptively easy. A few calls. Maybe a legal memo. Done? Nope.

You need a clear map of what the company will do on day one, what it might do later, and which of those services fall inside MiCA authorisation. If your app says you’ll only provide exchange services, but your product flow shows customer wallets, internal transfers, and stablecoin handling, the regulator will spot the mismatch fast.

And then there is the corporate setup. Some founders want one EU company to do everything while development sits elsewhere, IP is owned in another jurisdiction, and group treasury runs through a parent outside Europe. That can work. Sometimes. But if the regulated entity looks empty – no real management, no control over outsourced functions, no substance – expect questions.

If you’re still choosing the right setup, company formation in multiple jurisdictions is usually less about tax shopping and more about building something a regulator and bank won’t hate.

A useful sense-check here is comparing entity choices against founder goals, especially if the team is spread across countries. This piece on UK Ltd vs Estonian OÜ isn’t about MiCA directly, but it shows how early structuring decisions spill into compliance and operations later.


Stage 2 – the application pack is where the work really starts

This is the part everyone underestimates. You don’t just hand over a company certificate and a shiny deck. Regulators usually want a complete picture of the business, the people behind it, the controls, the money, and how risks are managed in practice.

That means, at a minimum, you’ll be building out things like:

  1. Programme of operations – what you do, for whom, in which countries, through which channels
  2. Business plan and financial forecasts – with assumptions that match reality, not pitch-deck fantasy
  3. Governance framework – board oversight, reporting lines, delegated authority, decision-making
  4. AML/CFT controls – onboarding, screening, transaction monitoring, SAR escalation, recordkeeping
  5. ICT and security documentation – systems, access controls, incidents, vendor dependencies
  6. Outsourcing framework – who does what, where they sit, and how the regulated entity keeps control
  7. Due diligence files – directors, senior managers, UBOs, qualifying shareholders

And all of those documents need to agree with each other. That’s where teams slip. The AML policy says retail only. The business plan says retail and institutional. The website says global. The financial model assumes EU only. The outsourcing register lists a vendor not mentioned anywhere else. Small inconsistency, big headache.

Regulators don’t love contradiction. Banks hate it even more.


What stalls MiCA applications most often

Here’s the short version: weak substance, fuzzy business models, and documents that look copied rather than lived in.

The most common blockers I see are these:

1. The regulated entity has no real control
If key operations are outsourced, that’s not automatically a problem. But the CASP still needs oversight, escalation rights, reporting, and actual management involvement. If everything meaningful sits with a parent company or external provider, expect friction.

2. AML is generic
A template AML policy won’t carry you far. Regulators want risk controls that fit your exact flows – wallets, blockchain analytics, sanctions exposure, source-of-funds triggers, high-risk geographies, transaction typologies. If your model can’t explain why one customer is medium risk and another is high, fix that early. This article on customer risk scoring is worth reading because this is where a surprising number of applications wobble.

3. Directors or senior managers aren’t ready for scrutiny
Being a smart founder doesn’t automatically make you acceptable to a regulator. You’ll likely need clean personal documentation, career history, role clarity, and evidence that management understands the regulated activity. If someone is a figurehead, it tends to show.

4. Financials don’t match the business plan
This one sounds boring. It’s not. If your projections show explosive growth with tiny staffing, low compliance spend, and vague assumptions around revenue per customer, somebody will ask how that’s supposed to work.

5. Banking and payments are an afterthought
You can technically work on authorisation before banking is fully sorted, but leaving payment flows unclear is a mistake. Regulators want to understand how fiat moves, where safeguarding or client money issues may arise, and who your payment partners are likely to be. I’ve seen this kill momentum late in the process.


Regulator questions don’t mean your application is failing

Founders panic when the first round of questions lands. They shouldn’t. Questions are normal. Silence is not always a good sign either.

What matters is the quality of your response pack. Fast answers help, but rushed bad answers make things worse. If a regulator asks who owns a control, don’t send three paragraphs of waffle. Name the function, the person responsible, the report line, the review frequency, and where the evidence sits.

Be specific. Almost painfully specific.

And make sure one person is managing the whole response process. Not legal answering one part, compliance another, ops a third, and no one checking whether the final submission contradicts itself. That’s how review cycles multiply.


Don’t ignore the people side of the application

MiCA applications are document-heavy, sure, but they are also management-heavy. Regulators are looking at whether the business is actually governable. Can the board understand the risks? Does the compliance lead have enough authority? Is someone owning AML day to day, or is it just “the COO for now” because hiring is expensive?

For early-stage firms, outsourcing some functions can be sensible. Honestly, it’s often the only sane option before revenue settles. But outsourced doesn’t mean invisible. Responsibilities still need to be clear, documented, and supervised.

If you don’t yet have an internal compliance lead, using an outsourced AML officer and compliance function can be a practical bridge, especially if the alternative is pretending a founder has time to manage alerts, policy reviews, and regulator queries between fundraising calls.


How to keep the process moving

You don’t need perfection on day one. You do need discipline.

A few practical habits make a huge difference:

  • Freeze the business model before drafting core documents
  • Keep one master version of services, geography, and customer types across the whole pack
  • Collect personal due diligence docs from key individuals early – passports, proof of address, CVs, declarations, corporate docs for shareholder entities
  • Run an internal challenge session before filing: “what would a sceptical regulator question here?”
  • Map every outsourced function and show how the regulated entity keeps control

Simple stuff. But it works.


The blunt truth

CASP authorisation under MiCA isn’t just a filing exercise. It’s a test of whether your crypto business is mature enough to operate inside a regulated market. Some firms are ready. Some discover, halfway through, that they built a product before they built a licensable company.

That’s not fatal. But it does slow things down.

If you want the timeline to be reasonable, get the structure right, scope the activities properly, make AML specific to your real risks, and don’t treat governance as decorative paperwork. Do that, and the process is still demanding – but manageable. Ignore it, and you’ll spend months answering avoidable questions and cleaning up docs you should’ve sorted at the start.

And yes, that’s very common.

More insights