How MiCA Registration Works for CASPs

If you want to serve EU crypto users, a U.S. registration is not enough. You need an EU legal entity, approval from an EU national regulator, and a file that matches your services, controls, and forecasts from start to finish.

Here’s the short version:

• MiCA sets one EU rulebook for crypto-asset service providers, or CASPs.
• Approval comes from a national regulator, not ESMA.
• As of July 1, 2026, the 18-month transition had ended, so firms without MiCA approval must stop EU activity.
• A narrow first application is often easier than filing for every service at once.
• Most delays come from regulator questions, not from the first filing itself.
• After approval, you can passport across the EU and EEA, but reporting and conduct duties still apply.

I’d boil the process down to four steps:

1. Map each product to a MiCA service category
2. Build a file with matching business, AML, ICT, and client-protection documents
3. Answer regulator follow-up requests without creating gaps
4. Use passporting after approval to enter other EU and EEA markets

A few points stand out from the article:

• If you offer custody, exchange, trading, execution, order handling, advice, placement, or portfolio management, you likely need CASP approval.
• Some already regulated EU financial firms may use notification instead of a separate CASP application.
• If your scope includes transfers, Travel Rule checks and wallet ownership or control checks become part of the review.
• Weak local presence, thin safeguarding, generic AML files, and missing ICT audit evidence are common reasons files stall.
• Statutory deadlines exist, but clock-stops during regulator RFIs can stretch the timeline.

Bottom line: I’d treat MiCA registration as a paperwork and controls test at the same time. If your business plan says one thing and your policies, systems, or numbers say another, the regulator will spot it fast.

That’s the core of the article: scope first, consistency next, then passporting after approval.

Map Your Services to the Right CASP Scope

Match Your Products to MiCA Service Categories

Before you write a single page of the application, list what your firm actually does and map each product, transaction flow, and customer journey to the right MiCA CASP service category.

Keep the product descriptions neutral and factual. Skip claims like "faster" or "best." Those kinds of statements can turn a plain service description into a public offer.

It also helps to split core services from ancillary ones. That keeps the first application tighter and easier to defend. If you want to add more services later, it's often smarter to extend scope after your governance, capital, and controls are working in practice.

Decide What to Apply for Now Versus Later

As of July 1, 2026, the 18-month MiCA transitional period had ended. Any firm operating in the EU without CASP authorization must wind down EU activity.

That deadline has pushed many firms to keep the first application focused on core services instead of trying to cover every possible activity at once.

A narrower first scope is easier to defend. Why? Because governance, capital, and controls must work in practice, not just sit nicely on paper. Once you lock the scope, you can build the application around those exact services.

Connect Transfer Services to Travel Rule Requirements

If your scope includes transfer services, the EU Travel Rule framework becomes part of the application scope. For CASP-to-CASP transfers and self-hosted wallet transactions, your firm needs infrastructure to identify the parties involved and verify wallet ownership or control. Regulators also expect wallet ownership and control checks.

Here’s how some common activities connect to MiCA duties:

Activity	Triggered Requirement	Scope Impact
CASP-to-CASP transfers	Travel Rule	Wallet ownership/control verification infrastructure
High-volume transactions	AML monitoring	Real-time monitoring and suspicious activity reporting
Custody or transfer of client assets	Safeguarding	Counterparty risk and operational resilience documentation

That control map becomes the base for the documents in the next section. Use the scope map to put together the application package.

sbb-itb-0796ce6

Build Your MiCA Application Package Step by Step

Use the approved scope as your north star. Every document should line up with the same services, markets, and controls. The biggest place applications go off the rails is inconsistency: the business plan points to one level of activity, but the control framework can’t back it up.

Corporate, Business Plan, and Capital Documents

Start with the exact services and transaction flows you already mapped. Then build the package around them with incorporation records, capital information, and a clear operating plan.

Your business plan should state:

• which services you’ll provide
• which markets you’ll serve
• how those services connect

Pair that with financial projections and expected transaction volumes that match the controls you describe. Regulators check these documents against your operating model, and any gap between them can slow the review.

Governance, AML, and Client Protection Policies

Your AML/CFT risk assessment should match your actual customer base and product mix. Don’t lean on a generic template. KYC procedures, transaction monitoring workflows, and sanctions screening should read like live processes already in use, not ideas parked on a future roadmap.

You’ll also need client-facing conduct-of-business disclosures under Article 66, along with client protection policies that fit the services you plan to offer.

Place the required disclaimer next to each asset listing.

"Disclaimers should be placed in close proximity to the specific description of the crypto asset, and not merely included in general terms and conditions or broad disclaimers." - Miriam Broucek, Partner, Kinstellar

ICT Security, Outsourcing, and Asset Safeguarding

Include current security audit evidence, incident response procedures, and outsourcing controls. Regulators expect current security audit evidence and cyber-resilience controls in the initial package. Access controls, outsourcing oversight, and safeguarding documents should show how the system works today, not how you hope it will work later.

Document Category	Key Evidence Required	Common Failure Point
Operational Controls	Real-time transaction monitoring; AML/CFT risk assessments	Policies not embedded in daily operations
ICT Security	Current IT security audits; cyber resilience plans	Lack of ongoing audit frameworks
Asset Listings	Due diligence review scope; neutral language descriptions	Evaluative language or missing disclaimers

Once the package is internally consistent, the NCA moves to completeness review and follow-up questions.

Review Stages, Timing, and Common Delays

From Completeness Check to Final Decision

Once the package is filed, the regulator checks whether the documents line up with the services, controls, and markets described earlier. After submission, the national competent authority starts with a completeness check and then moves into substantive review.

This is where things often slow down. During substantive review, you should expect RFIs, which are formal requests for clarification or extra documents. Each RFI can trigger a clock-stop, pausing the statutory review window until you send back a response. And yes, more than one RFI round is common.

In practice, most delay doesn't come from the completeness check. It comes from RFIs and the revisions that follow. The usual problem areas are pretty consistent: mismatches, missing evidence, and repeated RFI cycles.

Issues That Trigger Regulator Pushback

The main reasons applications stall are familiar and, in many cases, predictable.

AML files often get stuck when the controls look generic or don't fit the actual operating model. Weak local presence is another common issue, especially when the application fails to show a real physical and operational presence in the home member state.

Other pain points include:

• financial forecasts that aren't supported
• gaps between the business plan and the policies submitted
• safeguarding arrangements that are too thin to pass scrutiny
• missing audit evidence in ICT materials
• weak cyber-resilience testing

If the file says one thing but the documents suggest another, regulators tend to push back fast.

Statutory vs. Real Timelines: Comparison Table

Review Stage	Statutory Requirement	Observed Timeline	Common Delay Cause
Completeness Check	Formal window for acknowledgment and initial review	Often delayed by multiple rounds of RFIs	Missing documents or incomplete forms
Substantive Review	Fixed statutory windows for assessment	Often extended by clock-stops	Multiple RFI rounds
Approval / Decision	Final decision within a set legal timeframe	Can be delayed by scrutiny of local presence and safeguarding arrangements	Weak local presence or safeguarding gaps
Total End-to-End	Statutory window	Varies by NCA and application complexity	Accumulated RFIs and revisions

After approval, the next step is passporting across the EU and EEA.

Passporting After Approval and Final Takeaways

How Passporting Works Across the EU and EEA

Once a CASP is authorized, the next step is passporting. If a firm gets approval in one EU member state, it can passport services across the EU and EEA.

To enter another member state, the firm notifies its home regulator. After that approval, the firm still has to meet ongoing supervision, reporting, and conduct rules. Approval opens the door, but it doesn't end the compliance work.

Pre-Submission Checklist

Before filing, run one last consistency check to cut down on RFIs and clock-stops.

Checkpoint	What to Verify
Service Scope	Every service listed maps cleanly to a MiCA category with supporting documentation; business plan and financials align
AML / Travel Rule	Controls reflect your actual operating model, not a generic template
Incident Workflows	Documented and tested, not just described in policy
Safeguarding	Arrangements are specific, verifiable, audit-ready, and supported by realistic capital assumptions

Regulators spot mismatches fast. If your AML section describes one operating model but your business plan describes another, expect pushback.

Key Points to Remember

Scope, controls, and filings must match. When they line up, the review tends to move with fewer objections.

Define your service scope early and be exact. A vague or overly broad scope usually leads to follow-up questions and slows the process. Once the scope is set, build every document around it so the file reads as one package.

Treat authorization as an ongoing operating discipline. Compliance needs to show up in your systems and workflows, not just in policy documents.

Budget beyond the statutory window. RFIs often pause the clock and stretch the actual timeline.

FAQs

Do all crypto firms need MiCA approval?

No. MiCA applies only to Crypto-Asset Service Providers (CASPs).

If your business offers any of MiCA’s ten regulated services, you need a CASP license to operate lawfully in the European Economic Area. That includes services such as:

• operating a trading platform
• executing orders
• providing custody
• managing portfolios

If a firm doesn’t offer those services, it may sit outside CASP licensing.

There’s one catch, though: if a platform serves EU clients, these rules still apply no matter where the company is incorporated.

Which documents matter most in a CASP application?

The most important documents are your Programme of Operations, AML/CFT controls, governance documents, and ICT risk and incident reporting frameworks for DORA compliance. Together, they need to show how your business works in practice: your model, services, customers, revenue plan, and day-to-day readiness.

This is where many applications fall apart. Not because the business idea is weak, but because the paperwork is thin, generic, or full of gaps.

Applications often fail when documents are incomplete, inaccurate, or copied from a template without being shaped to fit the business. Your policies should match how your company actually runs and be backed by thorough, audit-ready records.

How long can MiCA registration take?

MiCA registration usually takes 3 to 12 months.

On paper, the formal review period is about 70 working days:

• 25 days for completeness checks
• 40 days for substantive review

But the day-to-day reality can look a bit different. Timing often shifts by jurisdiction.

For example, applications in Lithuania or the Czech Republic may wrap up in 3–4 months. In Germany, BaFin may take 9–15 months.

A lot comes down to two things: the quality of the application and the way the local regulator handles its process.

Related Blog Posts

• EU Crypto Regulations: Impact on Cross-Border Payments
• MiCA Explained: What the EU Crypto Regulation Means for Your Wallet in 2026
• Step-by-Step Guide to CASP Licensing Under MiCA
• CASP Registration Guide: Regional Rules 2026