The 1 July MiCA cliff: what your product team needs to ship before the transition closes
Written by Tommy Jamet, Head of Product, CoinCover
Everyone in the room is quoting the same date. 1 July 2026. It is on every slide, every board paper, every panicked email from a CASP that left its application late.
The date is real. It is also, for a product team, the wrong thing to plan around.
1 July is the outer cap, not a shared starting gun. Article 143(3) of MiCA let each member state set its own transitional window, up to eighteen months from 30 December 2024 and no longer. Plenty shortened it. Germany and Ireland closed at the end of 2025. The Netherlands shut its window mid-2025. Sweden went in the autumn. If you operate there, your cliff already happened.
And the part everyone is panicking about is not the part product owns.
If you are not already deep inside your authorisation application, product cannot save your licence now. That is a legal and wind-down problem, and it belongs to your general counsel, not your roadmap. This post is for everyone else. And for what every authorised firm faces the day after the licence lands.
The cliff in one paragraph: roughly 17% got through
|
~200
CASP authorisations
|
By mid-June 2026, the ESMA register showed around 200 firms with full CASP authorisation, against a pre-MiCA pool north of 1,200 national registrations. 83% of legacy crypto firms hit the deadline without a MiCA licence.
|
|
~10
zero-authorisation jurisdictions
|
Close to ten EU jurisdictions had not issued a single authorisation. On 17 April 2026 ESMA confirmed there would be no extension.
|
So treat the licence as what it is. A programme, not a form. The application is the entry ticket. Staying authorised is the recurring exam. And that exam is mostly your roadmap.
A licence is a snapshot. Staying authorised is continuous
A licence is point-in-time. That is the reframe most product leaders need and few have internalised.
You pass the assessment on a given Tuesday. The obligations that bite every day after are different in kind: safeguarding client assets under MiCA, operational resilience under DORA. Those are not policy PDFs in a drive. They are things your engineering team builds, runs, and has to show working, on demand, repeatedly.
Which is why 1 July is a poor planning anchor for product. It is a one-off date attached to a one-off event. Your real cadence, the one that never stops, is set by DORA. And DORA has no cliff.
Five moves, in the order I would ship them
Not five obligations. Five moves, in the sequence I would actually run them, each with the smallest version that counts as shipped.
1
|
Run one real recovery, and keep the evidence
Ship this first, because it is weeks of work, not a licensing cycle, and it is the thing regulators scrutinise hardest.
Smallest shippable proof: A single recovery you executed end to end, dated, with artefacts showing the assets came back and who authorised the return. Not a plan. A run.
|
2
|
Wire incident tooling to DORA's clock
Same engineering muscle as recovery, so build them in parallel. DORA's window for reporting a major ICT incident is short, and a shared mailbox does not hit it.
Smallest shippable proof: For one incident class, an alert that classifies severity and drafts the regulatory submission inside the window. Then widen the net.
|
|
3
|
Confirm the Travel Rule is actually live
This one is not roadmap, it is remediation. Originator and beneficiary data has had to ride on every in-scope transfer since 30 December 2024. No grandfathering, ever.
Smallest shippable proof: The data captured and transmitted by your systems, with nobody copy-pasting.
|
|
4
|
Make segregation and key control inspectable
Whether this is a build or a vendor question depends on one thing: do you touch any keys yourself.
Smallest shippable proof: A client-asset segregation report you can generate on demand, plus a key-management setup an auditor can inspect rather than take on trust.
|
|
5
|
Get records into a format regulators can read
Lowest immediate bite, so it is last, but do not let it rot. ESMA has moved record-keeping onto JSON aligned to ISO 20022 for transaction and order-book records.
Smallest shippable proof: An export an NCA's system can ingest for one record type.
|
The product calls: build, buy, or cut
The hard part is not the list. It is the three decisions around it, and those are product decisions, not compliance ones.
|
Build or buy
|
If you self-manage any keys, you build, and you own the evidence. If you have outsourced custody, the job changes shape: you verify and evidence your provider, not abdicate to them. Buying a custodian buys you a capability, not an alibi.
|
|
What to cut
|
With days left, the most valuable thing a head of product can do is stop shipping new surface area. Freeze the feature backlog. Point the team at evidence. Saying no to the roadmap you were proud of last quarter is the actual skill here.
|
|
Not yours
|
The licence and any wind-down are legal's call. No amount of engineering closes a gap in an authorisation you never filed for. Marking it 'in progress' on a board deck fools no one who matters.
|
The one most teams under-ship: recovery you can prove
Of the five, one is consistently faked, and it is the one regulators are circling.
You can write a continuity plan in a week. A good one, even. What you cannot fake in a week is a recovery you have actually run, with evidence that holds up when someone who wants to disbelieve you reads it.
A signed PDF that says 'we have a plan' is an assertion. A captured, dated record of a recovery you executed, showing the assets came back and who signed off, is evidence. One survives an auditor. The other survives until the first follow-up question.
That gap, between the plan and the proof, is where most teams are quietly exposed right now. The firms that have closed it did one unglamorous thing. They ran the recovery, on purpose, before anyone made them.
DORA is the deadline that does not move
1 July is a one-off. DORA is permanent. DORA has applied since 17 January 2025, and it runs on a cadence, not a deadline: ICT risk management, resilience testing, incident reporting, forever.
Here is the quiet win. The same tested-recovery evidence answers MiCA safeguarding, DORA testing, and your ISO 27001 and SOC 2 auditors at once. Build the artefact once. Spend it in four places.
One artefact, four frameworks
|
One artefact
|
MiCA
|
DORA
|
ISO 27001
|
SOC 2
|
|
Tested recovery (executed, dated)
|
✓
|
✓
|
✓
|
✓
|
|
Incident classification + reporting
|
|
✓
|
✓
|
✓
|
|
Key segregation evidence
|
✓
|
✓
|
✓
|
✓
|
|
Travel Rule data capture
|
✓
|
|
|
|
|
Machine-readable records
|
✓
|
✓
|
|
|
The cliff is a date. Resilience is a practice
The firms that come through this do not treat 1 July as the end of a scramble. They treat it as the start of an operating discipline, the first day of an exam that repeats forever. The licence was the hard part to get. The proof is the hard part to keep.
In a market where more than 80% of firms did not make the conversion, the licence stops being the moat almost as soon as you hold it. Resilience you can actually prove is what is left.
If recovery evidence is the gap on your side, we wrote a CoinCover field note on what 'tested, with proof' actually looks like.
Sources
ESMA, Statement on the end of transitional periods under MiCA (17 Apr 2026)
ESMA, List of MiCA grandfathering periods (Art. 143(3))
ESMA MiCA interim CASP register (~204 authorisations, 18 Jun 2026)
Regulation (EU) 2023/1113 (Transfer of Funds / Travel Rule, applies 30 Dec 2024)
DORA Regulation (EU) 2022/2554
ESMA, Statement on MiCA data standards and format (Nov 2025)
Freshfields / Aosphere member-state grandfathering trackers
