CASP Authorisation: The Technology Evidence Regulators Actually Want

A reading of what a CASP authorisation application has to contain on the technology side, written for applicants who want to file once and not be sent back for missing pieces.

Since MiCA’s CASP authorisation regime became applicable on 30 December 2024, the National Competent Authorities — CySEC, MFSA, BaFin, AMF, CSSF, CBI, and the rest — have been working through applications. Some are sailing through. Most are not. The reason is rarely the legal structure or the capital requirement. It is the technology file.

This is a reading of what the competent authorities are actually looking for in the technology evidence, and what gets applications downgraded to high-scrutiny review.

What MiCA Article 59 requires

MiCA Article 59 says no person may provide crypto-asset services in the Union without authorisation from a competent authority. Article 62 sets out what the application must contain. It is a long list — corporate documents, fit-and-proper assessments, programme of operations, business plan, AML procedures, complaints handling, organisational structure, internal controls, conflict-of-interest policies, ICT systems descriptions, business continuity, outsourcing arrangements, custody arrangements, and more.

The technical implementing standards (Commission Delegated Regulation EU 2025/303) specify the format and content of the application. The competent authorities have ninety working days to complete the assessment from the point at which the application is complete. The clock does not start until the file is complete — which is why missing or weak technology evidence is so costly: it pauses the clock indefinitely.

Who this is for

• The applicant CASP that is preparing or finalising its authorisation file and wants to know what the technology workstream should contain to a regulator’s standard.
• The CASP that has been authorised provisionally under a transitional regime and is preparing for full authorisation.
• The financial services firm that is extending its existing licence to include crypto-asset services under MiCA’s notification regime — even with the simpler procedure, the technology evidence still has to be there.

It is not a list of every document required. It is a reading of what the competent authorities specifically scrutinise on the technology side.

The five technology workstreams

A complete CASP authorisation file has, on the technology side, five distinct workstreams. Each produces evidence the competent authority will read against the same standard.

1. Programme of operations — the technology section. A narrative description of each service, the systems supporting it, the technology architecture end-to-end, expected volumes, order routing and execution logic, custody model, and integration with third parties. Typically thirty to seventy pages. Generic templates copied between applicants are recognised instantly and the file is downgraded.

2. ICT systems and security policies. The body of policies covering ICT risk management, information security, business continuity, incident response, change management, access control, and cryptography. Must align with DORA Article 6 framework requirements. Must be current — not dated documents inherited from a previous business.

3. Custody architecture documentation. Required for any service involving custody — which is most CASPs. Cold-warm-hot split, key management ceremony, signer arrangements, segregation of duties, access controls, smart contract risk assessment if relevant, and the relationship between custody and the rest of the business. This is the most regulator-scrutinised single document in the file.

4. Outsourcing register and arrangements. Every material outsourcing, with contracts, risk assessments, exit plans, audit rights, sub-outsourcing provisions, and data localisation. DORA Articles 28 to 30 set the bar. The cloud provider arrangement is the largest single item; the long tail of smaller providers is where most applicants have gaps.

5. Business continuity and disaster recovery. The BCP itself, the disaster recovery plan, the most recent test report, the recovery time objectives for each service, and how the arrangements interact with critical third parties. If the BCP is theoretical — never tested — that is a finding.

Where applications get downgraded

The recurring patterns the competent authorities have flagged in published feedback to applicants:

Programme of operations copied from a template. Several law firms and consultancies have published CASP application templates. They are recognised by regulators. A programme of operations that reads like a template is downgraded to high-scrutiny review, and the assessment timeline extends.

Non-resident senior management. Article 68 requires real EEA residence for management body members. Flying in monthly does not satisfy the substance test in Cyprus, Malta, Lithuania, or Ireland. The technology lead does not need to be EEA-resident, but the senior managers responsible for the technology function under the governance framework usually do.

Capital that is held but not segregated. Own funds in the same account as operating cash will fail the Article 67 check on first inspection. The technology workstream interacts with this where the treasury and accounting systems must demonstrate the segregation.

Outsourcing critical functions without a written contract meeting DORA Article 30 requirements. Audit rights, exit plans, sub-outsourcing controls, data protection. A standard cloud provider terms-of-service does not satisfy DORA Article 30. The CASP needs a specific contractual addendum or a regulated cloud provider relationship.

Custody architecture described at marketing depth. “We use industry-leading custody technology” is not a custody architecture. The regulator wants the cold-warm-hot allocation in percentages, the key management ceremony procedures, the signer arrangements with names and roles, the disaster recovery for keys, and the insurance arrangements.

The competent authority differences

While MiCA harmonises the substantive law, the competent authorities differ in what they ask for in detail. From the first wave of authorisations:

• MFSA (Malta) has the longest history with crypto under the previous VFA Act and tends to ask the most detailed custody and key management questions.
• CySEC (Cyprus) emphasises the programme of operations narrative quality — generic submissions are rejected early.
• CSSF (Luxembourg) applies its fund-administration sensibilities — outsourcing arrangements get the closest reading.
• BaFin (Germany) takes a particular interest in ICT systems documentation and resilience testing arrangements.
• AMF (France) tends to focus on consumer protection and market integrity controls within the technology stack.

None of these are formal differences in law. They are differences in supervisory style. A complete file written to the highest of these standards will pass any of them.

How we engage with this

We read CASP authorisation files. Before submission, as a Technology Control Review scoped to MiCA, we identify what is missing, what is generic, and where the file would be downgraded. The output is written in regulator language — so the applicant can read it, fix the file, and submit with confidence.

We do not draft authorisation files. We do not act as law firm. We do not run the application process. We read what has been written and identify what is missing.

Pricing is published at /pricing/. If you are preparing a CASP authorisation file and want an independent technology reading before submission, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.