The MiCA Article 60 Notification Process: Step-by-Step Guide to the 40-Day Fast Track
- Yiannos Ashiotis
- 15 hours ago
- 6 min read
Understanding MiCA’s Article 60 eligibility is only the first step. The real challenge is executing a flawless notification that satisfies competent authorities within the 40-day timeline.
Unlike traditional authorization where regulators exercise discretionary judgment, Article 60 establishes a fixed 40-working-day countdown—but only when notifications are complete from day one. Incomplete submissions trigger clock suspensions that can extend timelines by weeks or months, destroying the speed advantage the MiCA Article 60 provides.
This article explains exactly how the notification process works, what documentation you must submit, and how to avoid the mistakes that cause delays.
1 How the 40-Day Clock Actually Works
1.1 Notification vs. Authorization: Why It Matters
MiCA’s Article 60 is a notification regime, not an authorization process, and this distinction is critical.
In authorization regimes, regulators assess merit, exercise approval power, and work variable timelines. In notification regimes, they verify completeness within fixed timelines—and entities commence services on day 40 if notification is complete, regardless of whether substantive review has concluded.
Competent authorities verify three things: all Article 60(7) information submitted, planned crypto services are equivalent to existing authorizations, and you can comply with MiCA requirements. That's it. No approval letter, no formal authorization decision.
1.2 The Timeline Step-by-Step
Day 0: You submit notification to home member state competent authority
Days 1-20: Competent authority conducts completeness assessment
If complete → clock runs to day 40, you launch
If incomplete → authority immediately notifies you of missing information, sets deadline (max 20 working days), and clock suspends until you respon
Critical rule: You cannot commence services while notification is incomplete
Day 40: If notification complete, you launch crypto services
After day 40: Even if competent authority requests clarifications, these don't suspend the clock—you're already operational
1.3 Clock Suspension: The Killer
Here's what destroys most timelines: If the competent authority identifies missing information on day 10, your 40-day launch plan becomes 60+ days instantly. The clock freezes until you provide complete responses or their 20-day deadline expires.
A notification submitted January 15 expecting February 25 launch suddenly faces delays until late March if incompleteness triggers suspension.
The strategic implication: Submit comprehensive documentation that anticipates every question upfront. First-time completeness is everything.
2 What You Must Submit: MiCA Article 60(7) Requirements
MiCA Article 60(7) mandates eleven information categories. Missing any element = incomplete notification = clock suspension.
2.1 Programme of Operations
What they want: Specific details on crypto services you'll provide, where, and how you'll market them.
Not acceptable: "We will provide custody services in the EU via our website"
What works:
Precise services: custody for bitcoin, Ethereum, and top 20 tokens by market cap; hot wallet (20%) and cold storage (80%) split; institutional and high-net-worth retail clients
Geographic scope: Launch in home state (Ireland), passport to Germany, Netherlands, France in Q2
Marketing: Institutional relationship managers, targeted LinkedIn advertising, crypto media partnerships
2.2 AML/CFT Framework
What they want: Crypto-specific financial crime controls, not generic AML policies.
Must address:
How you handle CDD when clients interact via blockchain addresses
Chain analysis capabilities (which tools, what risk indicators)
Enhanced due diligence for mixing services, high-risk jurisdictions, DeFi interaction
Travel Rule compliance procedures
Crypto-specific transaction monitoring
Common failure: Submitting your existing MiFID AML policy with "crypto-assets" find-and-replaced throughout. Competent authorities spot this immediately.
2.3 ICT Systems and Security
What they want: Both technical documentation AND plain-language summary.
Technical side:
System architecture diagrams (wallets, nodes, databases, APIs)
Hot/cold/warm wallet architecture with percentages
Multi-signature schemes, HSM usage
Blockchain integration (full nodes vs. third-party providers)
Plain-language side:
Non-technical explanation of how systems work
How you protect client assets
Security measures in understandable terms
Why both: Competent authority staff reviewing notifications may not be blockchain engineers—they need to assess whether you understand your own risks.
2.4 Client Asset Segregation
What they want: Both legal and operational segregation proof.
Legal: Client assets remain client property in insolvency (trust structures, contractual terms, insolvency protection)
Operational: Separate wallets for client vs. proprietary holdings, daily reconciliation, audit trails, accounting systems distinguishing client from firm positions
For omnibus wallets: Explain how you maintain client-level records when blockchain only shows omnibus address.
2.5 Service-Specific Requirements
Depending on services you're providing, additional documentation applies:
Service | Additional Documentation Required |
Custody | Custody model (self/third-party/hybrid), insurance coverage, third-party custodian details if applicable |
Trading Platform | Operating rules, order types, matching algorithms, market abuse surveillance systems |
Exchange Services | Pricing methodology, spread calculation, data sources, non-discrimination policy |
Execution | Best execution policy adapted to crypto markets |
Advice/Portfolio Mgmt | Staff CVs, crypto expertise evidence, competence assessment procedures |
Transfer Services | Travel Rule compliance methodology, sanctions screening |
2.6 The Information Reuse Shortcut
Here's the efficiency hack: MiCA Article 60(9) says you don't need to resubmit information previously provided to competent authority if it's identical.
How to use this:
When submitting your notification, reference:
"AML/CFT framework as submitted on [date] for MiFID authorization review, confirmed current as of [date]"
"ICT security documentation as provided on [date] during operational resilience assessment, updated to reflect crypto-specific infrastructure per attached supplement"
Provide only new or changed information specific to crypto services. This cuts preparation time significantly for entities with established regulatory relationships.
2.7 Common Mistakes That Trigger Incompleteness
Based on actual notification failures, here's what competent authorities reject:
Generic templates: "We will implement secure systems" without technical specifics
❌ Future tense: "We will establish AML controls" instead of "We have established..."
❌ Missing diagrams: No system architecture, wallet structure, or process flows
❌ No crypto-specific risk analysis: Generic AML policies that don't address mixing services, DeFi, chain analysis
❌ Vague custody models: Unclear whether self-custody or third-party, no insurance details
❌ Missing staff qualifications: For advisory/portfolio management, no CVs or expertise evidence
❌ Incomplete market abuse systems: For trading platforms, no surveillance vendor or detection methodology specified
3 Strategic Preparation: Ensuring First-Time Completeness
3.1 3-4 Weeks Before Submission
Conduct brutal gap analysis against all MiCA Article 60(7) requirements:
✅ Programme of operations: Detailed, specific, with volume projections
✅ AML/CFT: Crypto-specific risk assessment and controls
✅ ICT documentation: Technical diagrams + plain summary
✅ Segregation procedures: Legal and operational clarity
✅ Service-specific policies: Complete for every service you're providing
✅ Token categorization: Clear classification
✅ Transfer methodology: If providing transfers, Travel Rule compliance detailed
Engage external advisors:
Regulatory advisors validate completeness
Technology auditors review ICT documentation
AML consultants assess crypto-specific controls
3.2 Documentation Quality Standards
What distinguishes successful notifications:
✓ Specific, crypto-tailored documentation (not generic templates)
✓ Consistent terminology throughout
✓ Both technical and plain-language explanations
✓ Present-tense descriptions of implemented frameworks
✓ Cross-references between related sections
3.3 The Pre-Notification Consultation Option
Some competent authorities offer informal pre-notification discussions where you can surface issues before formal submission.
Benefits: Identify gaps before clock starts, clarify expectations, build relationship
Caution: Not all authorities offer this, informal discussions aren't binding, balance seeking guidance with appearing prepared
3.4 Responding to Information Requests
If competent authority identifies missing information within the 20-day assessment period, respond fast and completely:
Best practice:
Respond within 48-72 hours (don't use full 20 days)
Provide comprehensive responses addressing not just the literal question but anticipated follow-ups
If request seems unreasonable or outside Article 60(7) scope, engage legal advisors before responding
Why speed matters: Every day your response is pending, your launch is delayed. Submitting partial responses that trigger additional requests compounds delays.
3.5 Post-Notification: The 40-Day Preparation Window
While the clock runs, finalize operational readiness:
Technology: Complete user acceptance testing, security penetration testing, blockchain node connections, wallet generation and signing tests
Staffing: Complete crypto training, conduct competence assessments, finalize roles and accountability
Vendors: Execute SLAs, test integration with custody providers and blockchain data vendors
Client documentation: Finalize terms and conditions, risk disclosures, client education materials
3.6 Consider Phased Rollout
Rather than full launch on day 40, consider:
Days 40-60: Limited pilot with select clients
Days 61-90: Expanded rollout with enhanced monitoring
Day 91+: Full commercial launch
Benefits: Identify operational issues in controlled environment, refine based on real experience, demonstrate prudent risk management to competent authority
4 Conclusion: Preparation Determines Speed
The MiCA Article 60 notification process offers a 40-day timeline that represents dramatic acceleration over traditional CASP authorization—but only when you submit complete documentation from day one.
Entities submitting incomplete notifications face clock suspensions that extend timelines by weeks or months, negating Article 60's competitive advantage entirely. Those investing in thorough preparation, engaging expert advisors, and submitting first-time-complete notifications launch in under two months while competitors navigate six-month processes.
The final strategic question: When should you pursue Article 60 versus full CASP authorization? The next article examines the decision framework, equivalence limitations, and scenarios where the fast track isn't sufficient.
About the Author
This article was written by Yiannos Ashiotis, Managing Partner at Pnyx Hill, an international advisory firm specializing in regulatory compliance, corporate governance, risk management, and digital asset regulation across the UAE and Europe. Our teams support banks, investment firms, asset managers, and crypto service providers with Article 60 eligibility assessment, notification execution, and MiCA compliance.
For advisory support on MiCA Article 60 strategy, equivalence analysis, or EU crypto market entry pathways, contact our EU and UAE digital asset advisory practice.