The 1 July 2026 MiCA Cliff: Migrating a Grandfathered Crypto Business Onto a CASP Licence

The end of MiCA’s transitional relief is being treated across the industry as a licensing exercise. It is a systems migration with a legal deadline bolted to the front of it, and the systems are the part you cannot stand up in a fortnight.

MiCA has applied to crypto-asset service providers since 30 December 2024. Under Article 143(3), a business that was already providing crypto-asset services under national law before that date may keep operating until 1 July 2026, or until it is granted or refused authorisation under Article 63, whichever comes first. That is the cliff. It is later than most firms would like and earlier than most are ready for, and in several member states it is earlier still, because Article 143(3) let each state shorten the window. A number cut it to twelve months, some to six. If you are relying on the headline date without checking the transposing law where you operate, you may already have missed it.

Why this is an engineering deadline, not a paperwork one

The instinct is to route this to compliance and legal, because the visible artefact is an application to a competent authority. That framing is where firms lose the months they do not have. The authorisation dossier asks you to demonstrate, with evidence, that a set of systems and controls already exist and operate. You cannot demonstrate a custody control that you are still building. You cannot show a register of client positions that reconciles if the ledger integration is half-finished. The application is the moment the platform work is inspected, not the moment it starts.

So the real deadline is not 1 July 2026. It is whatever date, months earlier, by which the systems have to be provably done so that the dossier describes something real. Work back from the cliff through the supervisory review window, through your own internal testing and audit, through the build, and the point at which engineering must actually begin is uncomfortably close to now.

The dependency map matters more than the checklist

A flat checklist of CASP obligations hides the thing that will hurt you: the obligations are not independent, and they cannot be worked in parallel. Client-asset segregation under Article 75 depends on a register of positions that reconciles to on-chain and off-chain balances, which depends on a ledger-indexing and reconciliation service, which depends on the custody architecture being fixed. Safeguarding of client funds under Article 70 depends on account structures and reconciliation you may not run today. The systems, security and access protocols expected under Article 68 sit underneath all of it — there is no point evidencing a custody policy on infrastructure whose access controls you cannot describe. I have written before on Article 68’s operational-resilience obligations, and they are the foundation the rest of the migration rests on, not a separate workstream.

Draw that as a graph and the critical path becomes obvious. Custody architecture is upstream of almost everything. Reconciliation is the long pole because it depends on both the custody design and clean data out of the chains you support. Treat the obligations as a to-do list and you will discover the ordering the hard way, in April, when the reconciliation you needed in January has a three-month build in front of it.

The following is the shape of that map — a dependency graph and a control-readiness table that ties each obligation to the system evidence a supervisor will actually ask to see. Adjust the durations to your estate; the ordering is the point.

# casp-migration.yaml — dependency graph for the run to 1 July 2026
# durations are illustrative; replace with your own estimates
milestones:
  custody_architecture:
    depends_on: []
    weeks: 8
    evidence: custody design doc; key-management & HSM policy
  ledger_reconciliation:
    depends_on: [custody_architecture]
    weeks: 10
    evidence: register of positions reconciling on/off-chain balances
  client_asset_segregation:      # Art. 75
    depends_on: [ledger_reconciliation]
    weeks: 4
    evidence: segregated wallets; insolvency-remote holding proof
  funds_safeguarding:            # Art. 70
    depends_on: [custody_architecture]
    weeks: 5
    evidence: safeguarding accounts; daily reconciliation logs
  access_and_resilience:         # Art. 68
    depends_on: []
    weeks: 6
    evidence: RBAC matrix; BCP/DR test report; change log
  dossier_freeze:
    depends_on:
      - client_asset_segregation
      - funds_safeguarding
      - access_and_resilience
    weeks: 0
    note: systems must be live & evidenced BEFORE this date

# control-readiness checklist — obligation -> provable system evidence
readiness:
  - obligation: Segregate client crypto-assets   # Art. 75
    evidence: reconciled position register + segregated custody
    status: not_started
  - obligation: Safeguard client funds           # Art. 70
    evidence: safeguarding accounts + daily recon
    status: not_started
  - obligation: Systems & access protocols       # Art. 68
    evidence: RBAC + DR test evidence
    status: not_started
  - obligation: Complaints & conflicts records
    evidence: logged, timestamped, retrievable on demand
    status: not_started

The simplified route is not a shortcut around the systems

Article 143(6) lets member states offer a simplified authorisation procedure to entities that were already authorised under national law before 30 December 2024. It is worth using where it exists. But read what it simplifies: the procedure, not the substance. The competent authority must still be satisfied that the requirements of Chapters 2 and 3 of Title V are met before it grants the licence. A faster form in front of the same evidentiary bar does not shorten the build. Firms that hear “simplified” and slow the engineering down are misreading the word.

What a supervisor will actually inspect

The gap between a firm that passes and one that stalls is rarely the policy documents. It is whether the documents describe systems that exist. A custody policy that names a segregation model your wallets do not implement is worse than no policy, because it is a documented control you cannot evidence. A register of client positions that does not reconcile is the single most common failure I would expect to see, because reconciliation exposes every shortcut in the data pipeline at once. The wider set of expectations is the same ground covered in what crypto-asset businesses need to have in place — and it does not soften because you were grandfathered.

There is also a scheduling clash worth naming. The same platform teams doing this migration are, in most firms, the teams that stood up crypto-asset tax reporting under DAC8 from January 2026, and that carry DORA obligations that have applied to CASPs since 17 January 2025. These are not separate universes of work competing politely for time. They draw on the same ledger data, the same reconciliation, the same people. Sequence them together or they collide.

Put the cliff on the engineering roadmap, not the legal calendar, and work back from the date the systems have to be provably done. If your dependency map starts with the authorisation form rather than the custody architecture, you have drawn it upside down.