CASP Wind Down Plan

Skip key takeaways

Key takeaways: CASP wind down plan 5

Updated July 29, 2026

What MiCA Article 74 actually requires, the two offboarding routes the act never reconciles and why no provision in MiCA puts a number on how long a wind-down has.

• Article 74 requires the plan, binds only providers of the Articles 75 to 79 services and defines nothing else about it Article 74 is one unnumbered paragraph of two sentences that reaches only the services in Articles 75 to 79, leaving reception and transmission of orders, advice and portfolio management and transfer services outside it.
• Article 64(8) sends client assets to a successor CASP and Article 75(6) returns them to the client, and MiCA never says which prevails Article 64(8) binds every CASP and covers crypto-assets and funds on withdrawal of authorisation, while Article 75(6) binds custody providers and returns crypto-assets or means of access to the clients themselves, and no order of priority is set between them.
• A withdrawal is not one event: mandatory, discretionary, partial and voluntary exits all land in the same Article 64 machinery Article 64(1) lists seven grounds and Article 64(2) two discretionary ones for authorisation withdrawal. Express renunciation under point (b) makes a voluntary exit a withdrawal, and Article 64(4) lets authorities withdraw one service, keeping the wind-down inside a live business.
• Article 68(9) fixes the retention floor at five years, up to seven on request, and gives clients a right to the records after their position closes Records of all crypto-asset services, activities, orders and transactions are kept for five years, extended to up to seven where the competent authority asks before the five years elapse, and they must be provided to clients on request, so decommissioning the trail on the last transfer breaks a duty that outlives the relationship.
• MiCA writes three timing formulas for cessation and none of them is a number, so a rehearsed window is the only real one Article 74 states no time, Article 64(8) says timely and orderly, Article 75(6) as soon as possible, and MiCA's only hard numeric return deadline is 25 calendar days under Article 14(3), for offerors on a cancelled offer, not CASPs.

Copy takeaways

If you are writing or rehearsing a CASP wind down plan against these two routes, we can build the standing procedures and the evidence trail they assume are already there.

See our MiCA compliance services

A CASP wind down plan is a MiCA obligation carrying almost no specification. Article 74 requires the plan, and then the regulation stops: no content standard, no filing duty, no review cycle and no deadline. What MiCA supplies instead is two conflicting destinations for client assets.

In short: Article 74 requires providers of the services in Articles 75 to 79 to hold a plan supporting an orderly wind-down under applicable national law, and says nothing else about it. Article 64(8) sends client crypto-assets and funds to another CASP on withdrawal of authorisation, Article 75(6) returns crypto-assets or the means of access to the clients themselves, and MiCA never says which route runs. A wind-down system has to execute both, so the rule picking between them is an internal control the CASP writes for itself. Records run five years under Article 68(9), extendable to seven, and clients keep a right to them after their positions close. No provision anywhere in MiCA puts a number on how long a CASP has.

A CASP wind down plan is what MiCA Article 74 requires and almost nothing else defines

A CASP wind down plan is required by one unnumbered paragraph of MiCA, quoted here whole:

Crypto-asset service providers that provide the services referred to in Articles 75 to 79 shall have in place a plan that is appropriate to support an orderly wind-down of their activities under applicable national law, including the continuity or recovery of any critical activities performed by those service providers. That plan shall demonstrate the ability of crypto-asset service providers to carry out an orderly wind-down without causing undue economic harm to their clients.

Three properties do the work. It carries no paragraph numbers, being one paragraph of two sentences, so the citation is Article 74 flat and a reference to Article 74(1) points at nothing. It does not bind every CASP: the scope reaches custody, trading platform operation, exchange, execution of orders and placing, leaving reception and transmission of orders, advice and portfolio management and transfer services outside it. And the string "Article 74" occurs exactly once in the regulation, in its own heading, with no recital using the phrase wind-down, no technical standard delegated on it and no Annex infringement entry citing it. That is provable from the act, though not evidence that nobody has specified anything: ESMA and EBA soft law were not searched here.

Licensing applications do not include this plan

Nor is the plan an application item. Article 62(2) asks an applicant for internal control mechanisms and a business continuity plan, a segregation procedure for client crypto-assets and funds and, where custody is intended, a custody policy. Under the Article 143(6) simplified procedure competent authorities must still confirm compliance with Chapters 2 and 3 of Title V, and Article 74 closes Chapter 2. So it sits inside the supervised perimeter unfiled, and its only stated success standard is an orderly wind-down "without causing undue economic harm to their clients".

A CASP wind down plan has to execute two routes that MiCA never reconciles

A CASP wind down plan has to send client assets somewhere, and MiCA gives two answers in two articles. First, from the withdrawal article:

Crypto-asset service providers shall establish, implement and maintain adequate procedures ensuring the timely and orderly transfer of their clients' crypto-assets and funds to another crypto-asset service provider when an authorisation is withdrawn.

Second, from the custody article:

Crypto-asset service providers providing custody and administration of crypto-assets on behalf of clients shall ensure that necessary procedures are in place to return crypto-assets held on behalf of their clients, or the means of access, as soon as possible to those clients.

	Article 64(8)	Article 75(6)
Who is bound	All CASPs	Custody CASPs only
Trigger	Authorisation withdrawn	None stated, a standing duty
What is owed	Crypto-assets and funds	Crypto-assets or the means of access
Destination	Another CASP	The clients themselves
Timing words	"timely and orderly"	"as soon as possible"

No order of priority is set between them, and no recital reconciles the two. A system that can only return to clients cannot serve a transfer to a successor, and one that can only transfer cannot serve a client who has none.

Scope and a default rule decide which route runs

Scope decides which phases bind you. A reception and transmission or advice-only CASP falls outside Article 74 and owes no plan, yet Article 64(8) binds every CASP, so Phase 0's standing procedures, Phase 1's trigger analysis and Phase 4's transfer leg still apply, as does Article 68(9) retention. Only the custody-specific parts drop away, the register of positions and the Article 75(6) return.

Which path runs is our rule rather than MiCA's. Our default: the client's instruction governs wherever the client can be authenticated and can name a destination, because Article 75(6) is the only route a client can execute alone. The transfer becomes operative for non-responders, for positions the client cannot self-custody and for fiat balances, which Article 75(6) does not reach at all. A defensible default rather than a requirement: MiCA supplies no tie-breaker.

Nothing in the text says who selects the successor CASP, whether the client consents, whether the successor must hold the same permission or what happens when no successor will take the book.

Phase 0 of a CASP wind down, what has to be standing before any exit decision

Phase 0 of a CASP wind down happens long before anyone decides to exit, because both offboarding duties are standing rather than triggered. Article 64(8) reads "establish, implement and maintain adequate procedures", present and continuous. Its counterpart requires that procedures "are in place". Neither switches on at the moment of withdrawal.

Those procedures execute against the client agreement. Article 75(1) makes seven items mandatory contents of it, and three govern how a wind-down can run: the custody policy at point (c), the means of communication including the client's authentication system at point (d) and the applicable law at point (g). A plan contradicting any of the three is a proposal to breach a contract under time pressure.

The custody policy at point (c) already fixes the loss standard an exit has to meet: under Article 75(3) it must "minimise the risk of a loss of clients' crypto-assets or the rights related to those crypto-assets or the means of access to the crypto-assets due to fraud, cyber threats or negligence". A wind-down raises all three of those at once.

Artefact: a plan bound clause by clause to the client agreement terms it has to meet.

Phase 1 of a CASP wind down, the trigger, because withdrawal is not one event

Phase 1 of a CASP wind down starts at a trigger, and the trigger is not one thing. Article 64(1) lists seven grounds on which competent authorities "shall withdraw" an authorisation, from an authorisation unused for 12 months to serious infringement of MiCA.

Point (b) is the one to design around: a provider that "has expressly renounced its authorisation". A voluntary exit is a withdrawal ground, so a CASP leaving the market lands in the same Article 64 machinery, and the same transfer duty, as one thrown out of it.

Article 64(2) adds two discretionary grounds: infringement of national anti-money-laundering law, and loss of a payment institution or electronic money institution authorisation left unremedied for 40 calendar days. Shall against may changes how much warning a plan can assume.

Partial withdrawal, refusal and notification also start the clock

Most operationally interesting is Article 64(4): "Competent authorities may limit the withdrawal of authorisation to a particular crypto-asset service." A CASP can lose custody permission and keep the rest, so the wind-down runs inside a live business with clients still trading on other services.

A refusal is a trigger too. Under Article 143(3) a provider operating in accordance with applicable law before 30 December 2024 could continue "until 1 July 2026 or until they are granted or refused an authorisation pursuant to Article 63, whichever is sooner", and Member States could shorten or decline that regime. So 1 July 2026 is an outer limit rather than a uniform end date.

The competent authority notifies ESMA and the host Member State single points of contact without undue delay, and ESMA publishes it in the Article 109 register. Whether the entry is removed or flagged is not established here.

Artefact: a trigger register mapping each ground to the route it selects.

Phase 2 of a CASP wind down, freeze and reconcile

Phase 2 of a CASP wind down produces the number every later phase is measured against. Article 75(2) already requires a register of positions "opened in the name of each client, corresponding to each client's rights to the crypto-assets". Wind-down use differs: freeze it, timestamp it and treat it as the baseline.

Paragraph 5 supplies the client-facing half: a statement of position covering the crypto-assets, their balance, their value and the transfers in the period, owed on request and at least quarterly. Issued at the freeze, it hands each client a countersignable starting number.

The on-ledger reconciliation against that register sits in our omnibus and segregated wallet topology analysis.

Artefact: a frozen, timestamped position baseline with a statement issued to every client.

Phase 3 of a CASP wind down, client instruction and authentication

Phase 3 of a CASP wind down is the highest fraud risk window in the sequence, because a legitimate mass withdrawal event and a social engineering campaign look identical from the outside.

Anchoring here is contractual. Article 75(1)(d) makes "the means of communication between the crypto-asset service provider and the client, including the client's authentication system" a mandatory content of the agreement. That path is a contracted term rather than an operational preference, so it cannot be relaxed to speed the return.

Route choice becomes client-facing here too. A transfer under Article 64(8) needs a named successor provider, a return under Article 75(6) needs a destination the client demonstrably controls, and both are instructions the system has to capture, evidence and be able to refuse.

Artefact: an instruction record per client, tied to the contracted authentication path and the route selected.

Phase 4 of a CASP wind down, executing the chosen route

Phase 4 of a CASP wind down runs two legs on two sets of rules, and the asset class decides which route is even available. Article 64(8) reaches "crypto-assets and funds". Article 75(6) reaches crypto-assets and the means of access only. A fiat balance therefore has one route rather than two, settling that leg without a judgement call.

One branch of a CASP wind down has no route in it: no successor will take the book. MiCA does not address that. Article 64(8) states the transfer duty, names nobody to find the successor and says nothing about what follows when none exists. Our rule, not MiCA's: fall back to Article 75(6) for every position a client can hold directly, then treat the residue as an escalation into the insolvency boundary below, where national law we did not retrieve governs.

Fiat safeguarding and liability keep running through the exit

Behind the fiat leg sits a standing duty. Under Article 70(3) client funds other than e-money tokens are placed with a credit institution or a central bank by the end of the business day following receipt, in an account separately identifiable from any holding the provider's own funds. That duty lives outside the custody regime and determines who holds the money when a transfer instruction lands. Article 70(5) disapplies it to CASPs that are electronic money institutions, payment institutions or credit institutions, so check the entity type before assuming it binds.

Liability does not pause during the window. Article 75(8) makes a custody CASP liable for the loss of client crypto-assets or of the means of access where the incident is attributable to it, capped at the market value of the asset lost at the time the loss occurred, a cap our MiCA custody requirements guide derives.

Artefact: per-client execution records covering both legs, each carrying the route, the destination and the timestamp.

Phase 5 of a CASP wind down, unwinding sub custody and third party positions

Phase 5 of a CASP wind down deals with client positions the provider does not hold itself. Article 75(9) restricts a custody CASP to sub-custodians "authorised in accordance with Article 59" and requires clients to have been informed that sub-custody is in use, so the unwind sequence is constrained by who is actually holding the position.

A sub-custodian is itself a CASP carrying its own Article 64(8) duty, so a transfer route can chain, and the sub-custodian's own successor becomes part of a path the client never contracted for. A plan mapping its chain one level deep has mapped the wrong thing.

Exiting the contracts underneath is a register event too, since DORA Article 28(3) requires a register of information on all ICT contractual arrangements, a data model our DORA register of information coverage owns.

Artefact: a sub-custody unwind ledger naming every holder in the chain and each position at hand-back.

Phase 6 of a CASP wind down, closing the register and the records that outlive it

Phase 6 of a CASP wind down closes the register and starts a clock running long after the client relationship ends. Article 75(2) qualifies its recording duty twice over: "where relevant", for movements "following instructions from their clients", evidenced "in such cases". Whether that reaches a CASP-initiated transfer to a successor or a sub-custody unwind, neither of which follows a client instruction, is not settled by the retrieved text. We record them to the same standard regardless, because an uninstructed movement is the one a supervisor asks about first.

Events keep arriving during the window. Article 75(4) requires that "Any event likely to create or modify the rights of a client shall immediately be recorded in the client's register of positions", and entitles the client to crypto-assets or rights newly created "on the basis and to the extent of" their positions at the time of that event, unless "a valid agreement signed" with the provider before it "expressly provides otherwise". A term varied after the event will not do it.

Retention duties survive the end of the client relationship

Retention sits in the governance article. Article 68 runs to ten paragraphs, so it is cited by paragraph. Paragraph 9 requires records "of all crypto-asset services, activities, orders, and transactions undertaken by them", and its second subparagraph is the offboarding point:

The records kept pursuant to the first subparagraph shall be provided to clients upon request and shall be kept for a period of five years and, where requested by the competent authority before five years have elapsed, for a period of up to seven years.

A client's right to the record survives the closure of their position, so a wind-down that decommissions the trail on the last transfer breaks a duty outliving the relationship. Article 68(10) gives ESMA a mandate over those records rather than content.

Artefact: a sealed record set with a retention clock attached and an export path a former client can use.

Where a CASP wind down plan stops applying, on the face of Article 2(2)(b)

A CASP wind down plan rests on duties that Article 2(2)(b) may remove at the worst possible moment. MiCA's scope article says the Regulation does not apply to "a liquidator or an administrator acting in the course of an insolvency procedure, except for the purposes of Article 47".

The carve-back names Article 47, the asset-referenced token redemption plan, and nothing else. Articles 74, 64(8) and 75(6) are not in it. On the face of the text, MiCA stops applying to that officeholder except for Article 47 purposes.

Now what the text does not say. It does not say the duties disappear, nor what becomes of the plan, the transfer procedures the CASP maintained or client assets already segregated from its estate under Article 75(7), which provides that creditors of the CASP "have no recourse to crypto-assets held in custody". Article 70(1) meanwhile requires arrangements safeguarding client ownership rights "especially in the event of the crypto-asset service provider's insolvency". What survives is a question of the applicable national law that Article 74 and Article 75(7) both defer to, and none was retrieved here. None of this is legal advice or a prediction about a real insolvency.

The engineering consequence does not wait on the legal question. A plan working only while the CASP's own management runs it has an undocumented expiry date. Its artefacts have to be legible to somebody who never saw the system and is working to a different statute.

What a CASP wind down deadline is when MiCA writes three and gives you none

A CASP wind down has no deadline in MiCA. The act writes three timing formulas for cessation and puts a number on none of them: Article 74 states no time at all, Article 64(8) says "timely and orderly" and Article 75(6) says "as soon as possible". Neither Article 70 nor Article 75 carries a mandate for technical standards that could later supply one. Two provisions in MiCA do carry hard numbers, and neither binds a CASP.

First is Article 14(3). On the cancellation of a public offer of a crypto-asset other than an asset-referenced token or e-money token, offerors must ensure that collected funds "are duly returned to them no later than 25 calendar days after the date of cancellation". That is the only hard numeric return deadline anywhere in MiCA and it binds offerors rather than CASPs. A reader carrying away a 25 day rule for custody offboarding has taken a real number from the wrong article.

Second is Article 47, where the asymmetry does the arguing. An asset-referenced token issuer's redemption plan has a named trigger, a notification duty within six months of authorisation or white paper approval, a competent authority that may require amendments within 40 working days and a standing duty to review it. Article 74 gives CASPs none of those, in one unnumbered paragraph against three. Both share the phrase "without causing undue economic harm", so the CASP provision reads as a lighter echo of the issuer one.

Rehearsal supplies the number MiCA does not

That leaves the number to the CASP. Our own figure comes from rehearsal: a 4 hour full platform recovery target, tested in roughly 10 drills across 6 client projects from 2015 to 2026, with the most recent run at 3 hours 35 minutes and the worst overrunning at just over 5 hours. Those are disaster recovery drills and never a measured asset return time. A plan nobody has executed states a window. A rehearsal produces one, plus the list of what made the worst run worse.

The CASP wind down evidence trail

The CASP wind down evidence trail is the deliverable a supervisor can ask to see, and it has to exist before the trigger. Each phase above ends in exactly one artefact. Who signs it and where it lives:

Phase	Signed by	Where it is retained
0, standing state	Management body	Governance repository
1, trigger	Compliance officer	Same repository, versioned
2, freeze	Operations and finance	Register of positions tooling
3, instruction	Client, countersigned internally	Client record store
4, execution	Operations	Positions and payment records
5, sub-custody	Operations and vendor management	Cross-referenced to the ICT register
6, closeout	Compliance officer	Archive readable without the platform

What holds this table together is the Article 64(8) standing duty rather than a retention rule: the procedures have to be established, implemented and maintained, so the rows accumulate while the business runs. Article 2(2)(b) sets the harder test, because the eventual reader may be a liquidator MiCA does not apply to, working from these rows alone. Article 68(9) retention, five years and up to seven, runs underneath. We file the trigger register and the unwind ledger as service records regardless, since a supervisor reads the sequence backwards. Moving a book of client assets is a governance capability too, the first item on the ESMA custody Common Supervisory Action scope list.

How Pharos Production helps

We come in at Phase 0 of a CASP wind down plan, long before any trigger exists. Building the standing procedures Article 64(8) and Article 75(6) both assume are already there is MiCA compliance software development work: route selection recorded as a control, instruction capture bound to the contracted authentication path, a register of positions that can be frozen, evidenced and exported without the platform that produced it. Phase 3, where fraud risk peaks, is cybersecurity work. Then we rehearse the sequence, because Phase 4 is a poor place to find out which artefact nobody can produce.

Sources: Regulation (EU) 2023/1114 (MiCA), Articles 2, 14, 47, 62, 64, 68, 70, 74, 75 and 143, via publications.europa.eu; Regulation (EU) 2022/2554 (DORA), Article 28, via publications.europa.eu. MiCA was read as originally published in OJ L 150, 9.6.2023 rather than as a consolidated text, and no search was made for amending regulations, so check for later amendments. Recovery drill figures are Pharos Production delivery data from around 10 drills on 6 client projects between 2015 and 2026, measuring disaster recovery rather than client asset return. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: July 29, 2026 · Reviewed by: Dmytro Nasyrov (Founder and CTO)

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 6

• ★ Featured question. Does MiCA require a CASP wind down plan?

  Copy link Copies a direct link to this answer to your clipboard.

  Yes. Article 74 requires a plan appropriate to support an orderly wind-down under applicable national law, including the continuity or recovery of critical activities, but it binds only CASPs providing the services in Articles 75 to 79 and it has no paragraph numbering, so the citation is Article 74 flat.

• Where do client assets go when a CASP's authorisation is withdrawn?

  Copy link Copies a direct link to this answer to your clipboard.

  MiCA gives two answers and does not reconcile them: Article 64(8) requires procedures for the timely and orderly transfer of clients' crypto-assets and funds to another CASP, while Article 75(6) requires procedures to return crypto-assets or the means of access to the clients themselves as soon as possible.

• Does the wind down plan go into the authorisation file?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 62(2) asks for a business continuity plan, a segregation procedure and a custody policy and does not ask for the Article 74 plan, although under the Article 143(6) simplified procedure the competent authority still has to confirm compliance with Chapters 2 and 3 of Title V, and Article 74 sits in Chapter 2.

• Is there a deadline for returning client crypto-assets?

  Copy link Copies a direct link to this answer to your clipboard.

  Not for CASPs. Article 74 states no time, Article 64(8) says "timely and orderly" and Article 75(6) says "as soon as possible"; the only hard number in MiCA is the 25 calendar days in Article 14(3), which binds offerors returning funds on a cancelled offer and not CASPs.

• How long must offboarding records be kept?

  Copy link Copies a direct link to this answer to your clipboard.

  Article 68(9) requires records of all crypto-asset services, activities, orders and transactions to be kept for five years, extended to up to seven where the competent authority requests that before the five years elapse, and those records must be provided to clients on request.

• How does a CASP know how long its own wind down would take?

  Copy link Copies a direct link to this answer to your clipboard.

  By rehearsing it, the same way recovery targets are tested: across around 10 full recovery drills we ran on 6 client projects, the measured median beat the stated target while the worst drill overran it.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.