CASP License Application

Skip key takeaways

Updated September 8, 2026

• The application file is built from three instruments, not one MiCA Article 62 lists nineteen items and adds separate proof about people in paragraph 3, Delegated Regulation (EU) 2025/305 expands those items across eighteen articles of which seven apply only to particular activities, with two more conditional requirements inside Article 2, and Implementing Regulation (EU) 2025/306 supplies the annex form and the procedure around it.
• Most of the real requirement is the delta between MiCA and the RTS MiCA asks for a description or a proof, and the technical standards turn each of those words into a document set, adding the social accounts and the branch and office detail, the three-year program horizon with stress scenarios, the tested continuity plan and the named individuals with CVs behind governance and complaints handling.
• DORA reaches the application through the technical standards MiCA Article 62(2)(j) asks only for technical documentation of the ICT systems and security arrangements, while RTS Article 9 requires the DORA compliance arrangements, the ICT risk-management framework described against DORA and the GDPR, and the critical-function ICT third-party contracts.
• The 25 and the 40 are separate periods with separate start events The completeness check runs 25 working days from receipt and tests only whether the Article 62(2) items were submitted, while the 40-working-day substantive assessment runs from receipt of a complete application, with an undefined authority-set deadline for missing information capable of sitting between them.
• A wind-down plan is not an Article 62 or RTS application item MiCA Article 74 binds providers of the services in Articles 75 to 79 after authorization, the term appears nowhere in Delegated Regulation (EU) 2025/305, and the nearest application-stage artifacts are the business continuity plan under RTS Article 5 and the forecast accounting plan with stress scenarios.

Copy takeaways

An application for authorization as a crypto-asset service provider is not a form with blanks in it. It is a file assembled from three instruments. MiCA Article 62 lists what it must contain, a delegated regulation says what most of those items have to hold and an implementing regulation supplies the form and the procedure.

In short: MiCA Article 62(2) sets nineteen lettered items and Article 62(3) adds separate proof about the management body and qualifying shareholders. Delegated Regulation (EU) 2025/305 expands those items across eighteen articles, seven of which apply only to applicants intending a particular activity, with two more conditional requirements inside Article 2, and Implementing Regulation (EU) 2025/306 supplies the annex form and the change-notification rule. Two periods bind the authority and they do not run end to end: 25 working days from receipt to test completeness against the Article 62(2) list, then 40 working days from receipt of a complete application to a fully reasoned decision. The second can be suspended once for up to 20 working days, and updating the file under the ITS restarts it. A wind-down plan is not an application item.

What the CASP application file actually contains

Under Article 62(1) of MiCA, "Legal persons or other undertakings that intend to provide crypto-asset services shall submit their application for an authorisation as a crypto-asset service provider to the competent authority of their home Member State." The authorization that comes out names the services it covers rather than granting a general permission to run a crypto business.

Article 62(2) lists nineteen items lettered (a) to (s), and its chapeau asks for all of them rather than a selection. About a third are conditional on intent, because custody, trading-platform operation, exchange, order execution, advice and transfer services each pull in their own item. Settle the service mix first with our breakdown of the ten CASP services, because every later annex inherits it.

Article 62(3) sits apart from that list and is easy to fold into it. Under Article 62(3) the proof is about people rather than about the business, opening with "for all members of the management body of the applicant crypto-asset service provider, the absence of a criminal record in respect of convictions and the absence of penalties imposed under the applicable commercial law, insolvency law and financial services law" and setting a parallel requirement for qualifying holders.

Not everyone providing crypto-asset services files an Article 62 application. Certain already-regulated entities reach crypto-asset services through the Article 60 notification to their home authority instead, and that route is not an equivalent of the Article 62 one, because Article 60 gives each entity type its own scope. A credit institution may provide crypto-asset services under Article 60(1) with no service restriction. A central securities depository is confined to custody and administration of crypto-assets by Article 60(2), an investment firm to the services equivalent to those it is specifically authorized for under MiFID II by Article 60(3), an electronic money institution to custody, administration and transfer of the e-money tokens it issues by Article 60(4), and a UCITS management company or an alternative investment fund manager to services equivalent to portfolio management and the non-core services it is authorized for by Article 60(5). The CSSF states the baseline on its crypto-assets page: "Crypto-asset service providers (“CASPs”) are subject to an authorisation regime involving notably prudential and organisational requirements and consequently are subject to the CSSF’s supervision." That route runs on its own instruments, Commission Delegated Regulation (EU) 2025/303 and Commission Implementing Regulation (EU) 2025/304, and our companion piece on CASP versus VASP authorization works through which route an entity is on.

The dossier, document by document

Two of the four columns below are sourced and two are not. Document and legal basis come from MiCA, the RTS and the ITS, and every row names its article. Prepared by is our editorial allocation to the function that normally owns the material, and the gap is editorial too, derived from one repeatable operation: the difference between what Article 62(2) says and what the RTS adds. No frequency claim attaches to any gap, because nothing here measures how often it occurs.

Document	Legal basis	Prepared by (editorial)	The gap (editorial, from the MiCA to RTS delta)
Identity pack: names, LEI, legal form, articles of association, websites, social accounts	MiCA 62(2)(a) to (c), RTS Art 1	Company secretary	MiCA already names the LEI and the website. The RTS adds the social accounts, branch LEIs, incorporation details, national registration evidence and the office addresses
Program of operations, three years after authorization	MiCA 62(2)(d), RTS Art 2(1)	Founders with finance	MiCA fixes no horizon. The three years and the stress-tested forecast are RTS
Reception-and-transmission and placing procedures	RTS Art 2(2) and 2(3)	Compliance	Inside the program-of-operations article, so RTS headings hide them
Prudential safeguards evidence: amount, forecast, financial statements, own funds or insurance	MiCA 62(2)(e) and Art 67, RTS Art 3	Finance	MiCA says proof, the RTS says which documents
Governance and internal control, organizational chart, function heads with CVs, whistleblowing	MiCA 62(2)(f) and (i), RTS Art 4	Head of compliance	Named individuals with CVs, not a policy narrative
Business continuity plan	MiCA 62(2)(i), RTS Art 5	Operations with ICT	Testing evidence, degradation scenarios and key-person continuity
AML and CFT controls and risk assessment	MiCA 62(2)(i), RTS Art 6	MLRO	The controls are a separate build, in our MiCA KYC requirements guide
Management-body fit and proper	MiCA 62(2)(g) and 62(3), RTS Art 7	HR with background screening	Sits in Article 62(3), which the completeness test does not name
Qualifying holdings: organigram, capital and voting breakdown, per-holder information set	MiCA 62(2)(h) and 62(3)(c), RTS Art 8	Corporate counsel, with each shareholder	The RTS imports that set by reference, hiding its volume
ICT and DORA evidence: documentation, DLT infrastructure, ICT risk framework, third parties	MiCA 62(2)(j), RTS Art 9	CTO or CISO	DORA, the GDPR and Article 73 enter through the RTS
Segregation and safekeeping, key approval, client fund placement	MiCA 62(2)(k) and Art 70, RTS Art 10	Custody or treasury operations	Key approval and multi-signature wallets are named explicitly
Complaints-handling procedures	MiCA 62(2)(l) and Art 71, RTS Art 11	Client operations	A named owner with a CV and an investigation timeline
Service-conditional annexes: custody, trading platform, exchange, execution, advice, transfers	MiCA 62(2)(m) to (r), RTS Arts 12 to 17	Product owner per service, with legal	Each opens with the words applicants that intend to, so intent scopes the file
Crypto-asset type; the signed form with its accuracy declaration	MiCA 62(2)(s), ITS Art 2 and the Annex	Product; legal representative	The form routes to RTS articles and closes no gap

An already-regulated applicant need not rebuild all of it. MiCA Article 62(4) stops an authority requiring information it already received under the e-money, MiFID or payment services procedures, on the condition that what it holds is still up to date. That condition does real work: the exemption avoids duplicate filing rather than grandfathering a stale file.

What the RTS adds that MiCA does not say

Reading Article 62(2) and stopping there under-scopes the work. Delegated Regulation (EU) 2025/305 runs to eighteen articles, and each substantive one opens by naming the MiCA point it expands.

The program of operations is the clearest case. MiCA asks for a program setting out the services and how they will be marketed. RTS Article 2(1) fixes a three-year horizon and populates it with, among much else, "the applicant’s outsourcing policy and a detailed description of the applicant’s planned outsourcing arrangements, including intra-group arrangements, and the way that the applicant will comply with Article 73 of Regulation (EU) 2023/1114;" A business plan written for investors rarely contains that, nor the forecast accounting plan with stress scenarios the same article requires.

Business continuity is the second. Beyond testing arrangements and third-party degradation scenarios, RTS Article 5 asks for "information on how business continuity is ensured in the event of the death of a key person and, where relevant, political risks in the service provider’s jurisdiction." Complaints handling runs the same way, since RTS Article 11 wants a named owner with a CV and an investigation timeline where MiCA asks only for a description.

The third catches checklists built from headings, because two service-conditional requirements sit inside the program-of-operations article rather than in Articles 12 to 17. RTS Article 2(2) provides that "Where applicants intend to provide the service of reception and transmission of orders for crypto-assets on behalf of clients, they shall provide to competent authorities a copy of the procedures and a description of the arrangements ensuring compliance with Article 80 of Regulation (EU) 2023/1114." Article 2(3) does the same for placing. The qualifying-holdings annex under Article 8 is the other planning trap: it imports the information set for each holder from a separate delegated regulation by reference, so its volume is invisible from the RTS text.

ICT, DORA and safeguarding evidence

MiCA itself asks for little here. Article 62(2)(j) requires "the technical documentation of the ICT systems and security arrangements, and a description thereof in non-technical language;" Read alone, that is satisfiable with a system diagram and a plain-language summary. RTS Article 9 is where the requirement lives, asking for "technical documentation of the ICT systems, DLT infrastructure relied upon, where relevant, and the security arrangements, including a description of the arrangements and deployed ICT and human resources established to comply with Regulation (EU) 2022/2554" It goes on to require an ICT risk-management framework described against both DORA and the GDPR, plus the critical-function ICT services and the third-party contracts behind them.

Attribution matters when you are arguing scope internally. It is not accurate to say MiCA requires DORA evidence in the application. DORA reaches the file through the RTS, and separately binds an authorized provider through the MiCA governance article on continuity of service. Either way the artifacts are the ones a DORA readiness program produces.

Safeguarding is the other technical annex. RTS Article 10 applies to applicants intending to hold client crypto-assets, the means of access to them or client funds other than e-money tokens, and it turns the MiCA description into a specification. Among its items is "a detailed description of the approval system for cryptographic keys and safeguarding of cryptographic keys, including multi-signature wallets;" A procedure document with no key-management architecture does not answer that.

Fit and proper for management and shareholders

Article 62(3) evidence has to be obtained from national registers rather than produced in-house. The standard that evidence has to meet is in MiCA Article 68(1): "Members of the management body of crypto-asset service providers shall be of sufficiently good repute and possess the appropriate knowledge, skills and experience, both individually and collectively, to perform their duties." RTS Article 7 turns that into identity details, CVs and declarations. One structural point is worth planning around: the completeness assessment tests the Article 62(2) list, and Article 62(3) is a separate paragraph it does not name, so fit-and-proper weakness surfaces during the substantive assessment rather than in the first weeks.

The form, the contact point and the declaration

The procedure comes from Implementing Regulation (EU) 2025/306 and it is short. Each competent authority designates a contact point for applications and publishes its details on its own website, so the submission address is public record. The acknowledgement of receipt then has to carry the contact details of the department, function or staff member handling the application, which is the named escalation route.

The annex form itself is easy to misread. It is a routing sheet rather than a questionnaire: each content section points at the corresponding RTS article and invites the applicant either to set the information out there or to reference the relevant section of the application. Treating the form as the application badly understates what has to be produced. What it adds is the declaration the legal representative signs on the accuracy and completeness of everything filed, and a tick-box that turns the same form into a notification of changes.

The clocks, stated as rules

Every period below binds a named party and starts from a named event. None is a countdown to a launch date, and two of them do not run end to end.

Rule	Period	Binds	Runs from	Conditions the text attaches
Acknowledgement of receipt	5 working days	Competent authority	Receipt of the application	Promptly and in any event within the period, in writing
Completeness assessment	25 working days	Competent authority	Receipt of the application	Tests only whether the Article 62(2) information was submitted
Deadline for missing information	Not fixed by MiCA	Applicant	The authority setting it	Case by case, and one authority publishes a four-week practice
Substantive assessment and decision	40 working days	Competent authority	Receipt of a complete application	Fully reasoned decision, weighing nature, scale and complexity
Notification of the decision	5 working days	Competent authority	The date of the decision	A separate period, not part of the 40
Request for further information	By the 20th working day	Competent authority	Start of the 40-working-day period	In writing, specifying what is needed
Suspension of the assessment	Up to 20 working days	Both	Request date to receipt of the response	One suspension, and further requests do not suspend
Restart on updated information	Not capped	Applicant triggers it	Receipt of the updated information	An ITS rule, distinct from the suspension
Notification to ESMA after a grant	2 working days	Competent authority	Granting of the authorization	Refusals are also notified, with no period stated

Receipt is acknowledged first, promptly and in any event within five working days, in writing. Then the completeness test, in Article 63(2): "Competent authorities shall, within 25 working days of receipt of an application under Article 62(1), assess whether that application is complete by checking that the information listed in Article 62(2) has been submitted." That is narrower than it looks. It checks that the paragraph 2 items were submitted, not that they are any good, and it does not reach paragraph 3. Where items are missing the authority sets a deadline, whose length MiCA does not fix, and what follows is a power rather than a duty: "Competent authorities may refuse to review applications where such applications remain incomplete after the expiry of the deadline set by them in accordance with paragraph 2, second subparagraph."

That second period runs from receipt of a complete application, a different event from receipt of the application. Article 63(9) provides that "Competent authorities shall, within 40 working days from the date of receipt of a complete application, assess whether the applicant crypto-asset service provider complies with this Title and shall adopt a fully reasoned decision granting or refusing an authorisation". The applicant is notified within five working days of the decision date, on a period of its own. Nothing supports adding 25 and 40 into a total, because the undefined deadline for missing information can sit between them.

During those 40 working days the authority may request further information in writing and specify what it needs, no later than the 20th working day of the period. The effect on the clock is where the rule is easiest to state wrongly, so it is worth having verbatim from Article 63(12): "The assessment period under paragraph 9 shall be suspended for the period between the date of request for missing information by the competent authorities and the receipt by them of a response thereto from the applicant crypto-asset service provider." Suspension is the operative word, not extension. The cap and the standing of anything further sit in the same paragraph: "The suspension shall not exceed 20 working days. Any further requests by the competent authorities for completion or clarification of the information shall be at their discretion but shall not result in a suspension of the assessment period under paragraph 9." The clock stops and resumes rather than growing, and any further request by the authority is discretionary and stops nothing.

A separate rule in the ITS produces a larger effect and is easy to merge with the suspension by mistake. Article 4(1) puts a standing duty on the applicant: "The applicant shall notify the competent authority of any changes to the information provided in the application for authorisation without undue delay. The applicant shall provide the updated information by using the form set out in the Annex." And then the consequence, in Article 4(2): "Where the applicant provides updated information in accordance with paragraph 1, the time limit laid down in Article 63(9) of Regulation (EU) 2023/1114 shall start from the date of receipt of that updated information by the competent authority." That is a restart from receipt rather than a capped pause, and the applicant triggers it. A shareholder change or a revised program of operations filed mid-assessment therefore resets the substantive period, which makes the sequencing of corporate changes around a filing a real planning decision.

Why a clock stops or a file comes back

Three things keep the assessment period from running, and none of them is a finding on the merits. Incompleteness against the paragraph 2 list means an item is absent rather than weak, and it stops no running clock, because the 40-working-day period runs from receipt of a complete application and has not started. The authority may decline to review a file still incomplete after its deadline. A request for further information suspends the period once, and an update the applicant files under the ITS restarts it instead.

Refusal on the merits is separate. Among the grounds in Article 63(10) is a residual one covering what the specific grounds miss, where "the applicant crypto-asset service provider fails to meet or is likely to fail to meet any of the requirements of this Title." The likely-to-fail limb matters: an authority is not confined to the state of the applicant on the filing date.

National practice fills in what MiCA leaves open. BaFin, for example, publishes how it handles the completeness step: "If any documents required for processing are missing, it will set a deadline for their submission, following the ESMA recommendation to set a four-week deadline." That four-week figure is BaFin's own practice following an ESMA recommendation rather than a rule in MiCA, so it shows how the open-ended deadline gets filled rather than supplying a number to plan against elsewhere. BaFin also states what the file must carry on the technical side: "For standard authorisation, please use the application form in the Annex to the Regulation. You must document in the application that you comply with the requirements set out in the Digital Operational Resilience Act (DORA)." Where an authority publishes no equivalent guidance, the RTS is the safer basis for scoping, since it binds every authority identically.

Costs are out of scope here. Fees, capital and the way both vary by Member State are covered in our comparison of CASP license cost by country and in the wider MiCA compliance cost breakdown, while the MiCA compliance checklist sequences the program around the application.

Passporting and the register after authorization

Serving more than one Member State is a notification to the home authority rather than a fresh application to each host. MiCA Article 65(1) sets the content: the Member States concerned, the cross-border services, the intended starting date and a list of the provider's activities outside the regulation. Article 65(2) then provides that "The competent authority of the home Member State shall, within 10 working days of receipt of the information referred to in paragraph 1, communicate that information to the single points of contact of the host Member States, to ESMA and to EBA." Under paragraph 3 the home authority informs the provider of that communication without delay, and Article 65(4) keys the start to that notice, so a provider "may begin to provide crypto-asset services in a Member State other than its home Member State from the date of receipt of the communication referred to in paragraph 3 or at the latest from the 15th calendar day after having submitted the information". Note the change of unit there, working days for the authority and calendar days for the backstop.

The grant itself surfaces publicly on a short rule. Article 63(13) provides that "Competent authorities shall, within two working days of granting authorisation, communicate to ESMA the information specified in Article 109(5).", with the information available in the register by the date services start, which is what eventually makes an authorization checkable in the ESMA CASP register.

What is not an application item

Two things are not application requirements. The first is the wind-down plan. MiCA Article 74 provides that "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 critical activities. Read the scope clause rather than the heading: it binds providers of the Articles 75 to 79 services after authorization and is not an item in the Article 62(2) list. A search of the regulation's text finds the term nowhere in the RTS, and the nearest application-stage artifacts are the business continuity plan and the stress-tested forecast. The obligation itself is the subject of our separate guide to the CASP wind-down plan.

The second is anything justified as what supervisors informally expect. When ESMA consulted on this RTS it was asked to add information on interconnectivity, on bankruptcy effects and on hack effects, and it declined for want of a Level 1 basis. The boundary of the file is the RTS.

How Pharos Production helps

Much of the application file describes systems that have to exist before anyone can describe them. The ICT documentation, the key-approval architecture and the segregation design are engineering artifacts first. If you are scoping an authorization, our MiCA compliance software development team can map your service mix to the RTS articles it triggers and to the work sitting underneath each one.

Sources: Regulation (EU) 2023/1114 (MiCA), Articles 59 to 74, consolidated text on EUR-Lex; Commission Delegated Regulation (EU) 2025/305 of 31 October 2024, the RTS under Article 62(5), OJ L series 2025/305 of 31 March 2025; Commission Implementing Regulation (EU) 2025/306 of the same date, the ITS under Article 62(6), OJ L series 2025/306 of 31 March 2025; ESMA Final Report ESMA18-72330276-1634 of 25 March 2024; the BaFin crypto-asset services page; and the CSSF crypto-assets page. Read on 2 September 2026. Engineering guidance, not legal advice.

FAQ

Last updated: September 8, 2026

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. Which regulation says what a CASP license application must contain?

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

  Three instruments stack. MiCA Article 62(2) lists nineteen lettered items and Article 62(3) adds proof requirements about the management body and qualifying holders.

  Commission Delegated Regulation (EU) 2025/305, the regulatory technical standards adopted under Article 62(5), specifies what those items have to contain across eighteen articles. Commission Implementing Regulation (EU) 2025/306, the implementing technical standards adopted under Article 62(6), sets the annex form, the submission procedure, the acknowledgement of receipt and the rule for notifying changes. Both were adopted on 31 October 2024 and published in the Official Journal on 31 March 2025.

• How long does a CASP authorization decision take?

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

  No source states an elapsed time, and the two statutory periods cannot be added together. The competent authority has 25 working days from receipt of the application to check whether the Article 62(2) information was submitted.

  A separate period of 40 working days runs from receipt of a complete application to a fully reasoned decision, and the applicant is notified within five working days of the decision date. Between those two sits a deadline the authority sets for any missing information, whose length MiCA does not fix. Anyone quoting a single figure in months is estimating rather than citing.

• Can the 40-working-day assessment period be extended?

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

  It cannot be extended, but it can be suspended and it can be restarted, which are different things. A written request for further information, which must arrive no later than the 20th working day of the period, suspends it from the date of the request until the response is received, and that suspension may not exceed 20 working days.

  Any further request is at the authority's discretion and has no suspensory effect. Separately, if the applicant files updated information under Article 4 of the implementing regulation, the period starts again from the date the authority receives that update, with no cap on the effect.

• Does the CASP application have to include a wind-down plan?

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

  No. MiCA Article 74 requires an orderly wind-down plan from providers of the services referred to in Articles 75 to 79, which is an obligation of an authorized provider rather than an item in the Article 62(2) application list. A search of the regulation's text finds the term nowhere in the regulatory technical standards, and no article of Delegated Regulation (EU) 2025/305 asks for such a plan at application stage.

  The closest application-stage documents are the business continuity plan required by RTS Article 5 and the forecast accounting plan with stress scenarios required by RTS Article 2. On build order, our editorial view is that the items depending on third parties come first, since the Article 62(3) criminal-record and penalty evidence is issued by national registers and the qualifying-holdings information set under RTS Article 8 has to be collected from each holder, while the program of operations, the continuity plan and the ICT documentation are produced in-house.

• Where does DORA fit into a CASP license application?

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

  Through the technical standards rather than through MiCA itself. MiCA Article 62(2)(j) asks only for technical documentation of the ICT systems and security arrangements plus a non-technical description.

  RTS Article 9 is what requires a description of the arrangements and the ICT and human resources established to comply with Regulation (EU) 2022/2554, an ICT risk-management framework described against both DORA and the GDPR, and an identification of the ICT services supporting critical or important functions together with the third-party contracts behind them. Attributing the DORA requirement to MiCA Article 62 directly is inaccurate.

• Does a CASP need a separate application for every Member State it serves?

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

  No. Cross-border provision runs on a notification to the home competent authority under MiCA Article 65, not on a new authorization in each host state. The provider submits the list of Member States, the services to be provided cross-border, the intended starting date and a list of its non-MiCA activities.

  The home authority passes that to the host single points of contact, to ESMA and to the EBA within 10 working days of receiving that information, then informs the provider of the communication without delay. Services may begin from the date the provider receives that notice from its home authority or at the latest from the 15th calendar day after the information was submitted. Note the change of unit inside Article 65: the authority's period is counted in working days and the backstop in calendar days.

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.