MiCA License in Czech Republic

Use this block to separate search-language from legal classification. The label on the homepage is not the same thing as the actual MiCA route.

Practical rule: if the business model is still being described in homepage terms like “crypto license,” the first step is classification, not filing. A careful scope memo saves time, capital, and rewrite cycles later in the process.

CASP authorization vs old VASP registration vs token issuance regimes

CASP authorization is the current MiCA route; the old Czech VASP route is historical context only for 2026. This distinction matters because many legacy pages still mix terms in ways that are commercially convenient but legally imprecise.

Old VASP registration

The pre-MiCA Czech model was primarily AML-driven and much lighter than a full CASP authorization. It did not equal MiCA authorization and did not create the same harmonized EU passporting position.

CASP authorization under MiCA

This is the current route for new entrants. It requires a full authorization package covering governance, capital, own funds, complaints handling, safeguarding, outsourcing, ICT controls, and management suitability. It is supervised by the ČNB under the MiCA framework.

ART and EMT issuance

ART and EMT issuance are not simply “higher classes” of CASP activity. They sit in separate MiCA perimeters. EMTs in particular intersect with the e-money framework and are not something a standard CASP authorization automatically covers. This is one of the most common legal errors in competitor content.

Transition dates that still matter:

• 30 December 2024: MiCA CASP regime fully applicable;
• 31 July 2025: key Czech transition filing deadline for eligible legacy providers;
• 1 July 2026: end of the Czech grandfathering period for qualifying legacy firms.

For new applicants in 2026, the practical answer is direct: build for MiCA from the start.

Which services require a CASP license in Czech Republic

A CASP license is required if your Czech entity provides in-scope crypto-asset services under MiCA. The analysis starts with the real operating model, not with the label on the homepage.

The core MiCA service categories commonly relevant to founders include:

• Custody and administration of crypto-assets on behalf of clients – typically relevant for custodial wallets, centralized exchanges, and institutional custody solutions;
• Operation of a trading platform for crypto-assets – relevant where the platform brings together multiple third-party buying and selling interests;
• Exchange of crypto-assets for funds – crypto/fiat conversion models;
• Exchange of crypto-assets for other crypto-assets – swap and conversion services even without fiat legs;
• Execution of orders on behalf of clients – broker-style models that execute client instructions;
• Reception and transmission of orders – introducing or routing models where the firm handles client orders without full execution discretion;
• Transfer services for crypto-assets on behalf of clients – moving crypto-assets between addresses or accounts for clients;
• Providing advice on crypto-assets – personalized recommendations, not just generic educational content;
• Providing portfolio management on crypto-assets – discretionary management of crypto-asset portfolios.

Business-model examples:

• An app that holds user keys or can unilaterally move client assets is usually in custody territory;
• An OTC desk that quotes both sides and settles client trades may trigger exchange and execution analysis;
• A broker that routes orders to a third-party venue may still need authorization for reception/transmission and possibly execution depending on the flow;
• A staking interface may or may not fall within MiCA service categories depending on custody, intermediation, and control over client assets.

Unique practical point: many “non-custodial” products fail the legal test because the operator still controls recovery logic, transaction authorization, or omnibus settlement. The regulator will look at key control, contractual rights, and technical fallback powers, not only at marketing language.

What is outside MiCA or only partially covered

Not every blockchain activity is inside MiCA, but labels like NFT or DeFi do not create automatic exemptions.

• Financial instruments under MiFID II: outside MiCA and potentially inside securities/investment services regulation;
• Unique NFTs: may fall outside MiCA, but fractionation, series issuance, or economic fungibility can change the analysis;
• Pure DeFi: may sit outside MiCA where there is no identifiable intermediary, but many projects claiming DeFi still have a controlling operator, governance core, or front-end intermediary;
• Reverse solicitation: narrow and fact-specific; not a scalable go-to-market strategy;
• Mining, node validation, and pure software publishing: often outside CASP scope, but surrounding services may still be regulated.

The correct approach is substance over label. RUE often maps borderline models against our broader MiCA CASP guidance, NFT analysis, and DeFi regulatory notes before deciding whether a Czech filing is the right route.

Company setup and substance requirements in the Czech Republic

The standard vehicle for a Czech MiCA application is usually an s.r.o., but the legal form is only the starting point. What matters more in 2026 is whether the company has credible governance, transparent ownership, and operational substance consistent with the requested CASP scope.

Incorporation of a Czech s.r.o. can often be completed in 1-3 weeks if shareholder documents, powers of attorney, UBO information, and apostilled or translated documents are ready. In practice, the licensing critical path is not incorporation; it is the build-out of the authorization package and the operating model behind it.

Typical pre-filing setup includes:

• Czech legal entity with registered office;
• UBO disclosure and ownership chart;
• Articles, corporate approvals, and director appointments;
• Share capital funding plan;
• Local address and document handling capability;
• Accounting and tax setup;
• Management and control function allocation.

Substance in 2026 means evidence, not slogans. The regulator may test where strategic decisions are made, who approves onboarding exceptions, who owns the outsourcing register, who signs off on suspicious activity escalation, and who can shut down a wallet flow or trading module during an incident. A project run entirely from outside the EU with only a Czech mailbox is far less defensible than it was under legacy market narratives.

RUE assists with the local build-out through legal address services for Czech companies, office rent support in Prague, legal setup, and ongoing company accounting support.

Management, MLRO, compliance and fit-and-proper expectations

The management body must be able to run a regulated crypto business, not just sponsor one. That means competence, reputation, time commitment, and control over outsourced functions.

For a Czech CASP license, the regulator will typically expect:

• Directors or senior managers with relevant financial services, crypto operations, AML, or technology governance experience;
• An MLRO/AML officer with authority, escalation access, and practical understanding of crypto typologies;
• A compliance function proportionate to the model;
• Clear segregation of duties between business, control, and technology functions;
• Evidence that key persons can challenge vendors and internal teams.

Unique practical point: in 2026, fit-and-proper review increasingly overlaps with operational literacy. A director who cannot explain the difference between omnibus custody, segregated wallets, and delegated signing authority may be viewed as too distant from the actual risk profile of the firm.

Where needed, RUE supports clients with MLRO services in the Czech Republic and KYC and AML officer support for Czech crypto companies.

Documents required for a Czech CASP license application

The authorization package is the most important part of the Czech Republic MiCA license process. A strong file does not merely list policies; it proves that the business model, governance, and controls are internally consistent.

The core document set usually includes:

• Application form and corporate details – identifies the applicant, legal form, ownership, and requested service scope;
• Programme of operations – explains what services will be provided, how they work, who the clients are, and what the operational flow looks like;
• Business plan and financial forecasts – usually a 3-year model with assumptions, runway, cost base, and growth logic;
• Governance documents – management structure, reporting lines, decision rights, committee logic if any, and control function allocation;
• Ownership chart and UBO documentation – including qualifying holdings analysis where relevant;
• Fit-and-proper pack for key persons – CVs, references, criminal record certificates, declarations, and time-commitment evidence;
• AML/CFT framework – business-wide risk assessment, KYC/KYB procedures, monitoring rules, sanctions controls, escalation and reporting process;
• Travel Rule procedures – originator/beneficiary data collection, transmission, exception handling, and reconciliation;
• Complaints handling policy – intake, classification, response times, escalation, and root-cause tracking;
• Conflicts of interest policy – identification, prevention, mitigation, and disclosure;
• Safeguarding and custody controls – especially where client assets are held or administered;
• ICT and security documentation – architecture, access controls, incident response, backup/recovery, vendor oversight, and resilience testing;
• Outsourcing policy and outsourcing register – critical function mapping, due diligence, SLAs, audit rights, exit strategy, concentration risk;
• Capital and funding evidence – source of funds, paid-in capital plan, and prudential support logic;
• Client-facing legal documents – terms, disclosures, fee schedule, privacy notices, and complaint channels.

What each document is really for:

• The programme of operations shows whether the applicant understands its own regulatory perimeter;
• The business plan shows whether the model is viable and prudentially credible;
• The AML pack shows whether the firm can identify and control abuse risks;
• The ICT pack shows whether the business can survive incidents and vendor failures;
• The governance pack shows who is accountable when something goes wrong.

Common mistakes that delay review:

• Documents copied from another jurisdiction without Czech or MiCA adaptation;
• Contradictions between website, terms, and programme of operations;
• Calling a model “non-custodial” while retaining practical control over keys or transfers;
• Weak outsourcing oversight where core functions are delegated to vendors;
• Financial forecasts that ignore compliance, staffing, and ICT costs;
• No evidence of Travel Rule operating logic for transfer-related services.

The minimum policy stack most applicants underestimate

One AML policy is not enough for a Czech CASP filing. Most applicants need a policy architecture of roughly 8-12 core documents, sometimes more for custody or platform models.

Typical minimum stack:

• AML/CFT policy and business-wide risk assessment;
• KYC/KYB onboarding procedure;
• KYT and transaction monitoring rules;
• Sanctions and PEP screening procedure;
• Travel Rule procedure, often aligned with IVMS101 data standards in market practice;
• Complaints handling policy;
• Conflicts of interest policy;
• Safeguarding or custody policy;
• ICT security policy;
• Incident response plan;
• Business continuity and disaster recovery plan;
• Outsourcing policy and register.

Unique practical point: if you use Travel Rule providers or blockchain analytics vendors, the regulator will care about fallback procedures. A compliant design should explain what happens when the vendor is unavailable, when counterparty data is incomplete, or when the transfer involves self-hosted wallets and elevated sanctions risk.

RUE prepares regulator-facing documentation through our MiCA application document preparation service and coordinates Czech corporate formalities, translations, and legalizations where needed.

Step-by-step process to obtain a MiCA license in Czech Republic

The real process runs from service scoping to post-approval launch, not from company registration to a quick filing. In 2026, the quality of pre-filing preparation is the main variable that determines whether the review stays manageable.

Stage 1 – Scope definition and gap analysis. The first task is to map the business model against MiCA services, exclusions, and adjacent regimes. This is where we determine whether the company is actually a CASP, whether custody exists in substance, whether the model touches ART/EMT or MiFID II, and what capital threshold is likely to apply.

Stage 2 – Company setup and governance design. The Czech legal entity is incorporated, ownership is documented, and the governance architecture is fixed. This includes director roles, MLRO/compliance allocation, outsourcing map, and initial funding logic.

Stage 3 – Documentation build. This is usually the most labor-intensive phase. The authorization package, policy stack, financial model, client documents, and ICT controls are drafted and aligned. Weak applications usually fail here because documents are prepared in silos and do not match each other.

Stage 4 – Filing and regulator review. The application is submitted to the ČNB with the state fee. The regulator reviews completeness and substance, then issues requests for information where needed. Complex questions often focus on custody, outsourcing, Travel Rule flows, governance, and management competence.

Stage 5 – Remediation and authorization decision. Most applications require at least one remediation loop. This may involve policy refinement, additional evidence, revised forecasts, or clarifications on technical architecture and client protection arrangements.

Stage 6 – Post-license operationalization. After approval, the company still needs to finalize banking, vendor onboarding, staff training, incident workflows, reporting calendars, and, where relevant, passporting notifications for other EU markets.

Realistic timeline in 2026: best case, realistic case, delayed case

The honest answer is that timelines are scenario-based, not guaranteed.

• Best case: 4-6 months – possible where the model is narrow, management is strong, documents are prepared to a high standard, and regulator questions are limited;
• Realistic case: 6-9 months – the most defensible planning range for a standard Czech CASP application in 2026;
• Delayed case: 9+ months – common where there are classification issues, weak governance, cross-border outsourcing complexity, or repeated RFIs.

Unique practical point: the biggest hidden delay is not usually the regulator. It is internal inconsistency between product, legal, compliance, and tech teams. If the app flow, wallet design, and terms of service are not aligned before filing, every RFI takes longer because the company is still discovering its own model during the review.

AML, Travel Rule and sanctions controls for Czech CASPs

A Czech CASP license is inseparable from AML, Travel Rule, and sanctions readiness. MiCA gives you the authorization perimeter, but operational credibility is built through your AML/CFT and financial crime controls.

In the Czech Republic, CASPs operate within the combined framework of Act No. 253/2008 Coll., Regulation (EU) 2023/1113, EU sanctions law, and the broader FATF logic applied to crypto-asset transfers. This means the compliance stack must cover both onboarding and transactional behavior.

What the regulator expects in practice:

• Risk-based KYC/KYB and beneficial ownership verification;
• Customer risk scoring with triggers for enhanced due diligence;
• KYT or equivalent transaction monitoring for blockchain exposure where relevant;
• Sanctions, PEP, and adverse media screening at onboarding and on a periodic basis;
• Travel Rule data exchange for in-scope transfers, including exception handling;
• Escalation and suspicious transaction reporting workflow;
• Record retention and auditability.

Travel Rule is not just a checkbox. A mature file explains how originator and beneficiary data is collected, validated, transmitted, matched, and stored. In market practice, firms often use Travel Rule providers and data standards such as IVMS101. The regulator will also care about what happens when the counterparty VASP is unreachable, unverified, or located in a higher-risk jurisdiction.

Sanctions is where crypto-specific design matters. Screening only customer names is not enough for many models. A stronger framework addresses wallet screening, exposure to sanctioned services, mixers, darknet typologies, chain-hopping, and red flags around self-hosted wallets. For higher-risk models, the escalation matrix should define when a transfer is paused, when EDD is triggered, and who can approve release or rejection.

Practical compliance stack: KYC, KYB, KYT, screening and reporting

The practical stack usually combines policy, process, and vendor tooling. A common operating model includes:

• KYC/KYB: identity verification, corporate registry checks, beneficial ownership review, document authenticity controls;
• Screening: sanctions, PEP, adverse media, and periodic refresh logic;
• KYT: blockchain analytics to identify high-risk counterparties, typologies, and exposure clusters;
• Travel Rule: messaging layer and reconciliation workflow for crypto transfers;
• Reporting: internal case management, MLRO review, and suspicious transaction reporting where required.

Tools such as Chainalysis, TRM Labs, Elliptic, and Travel Rule networks are examples of market practice, not regulatory mandates. The real test is whether your controls are proportionate, documented, and actually embedded into operations.

RUE supports this layer through Czech AML structuring, MLRO support, and documentation design so the compliance stack is defensible before both the ČNB and the wider AML enforcement context.

ICT, cybersecurity and DORA-related readiness for a Czech Republic MiCA license

ČNB review in 2026 is not limited to legal paperwork; it also tests whether your ICT environment is governable and resilient. This is where many otherwise strong applications become weak.

The relevant framework is shaped by MiCA, DORA, and supervisory expectations around ICT risk management. For a CASP, this usually means documented controls across:

• Access management – role-based access, privileged access controls, maker-checker logic, MFA, and joiner/mover/leaver procedures;
• Logging and monitoring – centralized logs, alerting, audit trails, and evidentiary retention;
• Incident management – classification, severity levels, escalation ownership, communication trees, and lessons-learned loop;
• Backup and recovery – tested backups, restoration procedures, and documented RTO/RPO targets;
• Outsourcing oversight – vendor due diligence, criticality mapping, contractual controls, exit planning, and concentration risk management;
• Security testing – vulnerability management, patching, external/internal testing, and periodic penetration tests;
• Business continuity – scenario testing for provider outage, wallet compromise, cloud failure, and internal fraud.

Unique practical point: regulators increasingly focus on operational dependency chains. If your onboarding, wallet infrastructure, transaction monitoring, and Travel Rule transmission all depend on separate vendors, the file should explain who orchestrates failure handling when two or more of those vendors fail at the same time.

What the regulator will expect for custody, wallets and key management

Custody models face the highest technical scrutiny. Where the CASP controls or administers client crypto-assets, the regulator will usually expect a detailed explanation of:

• How keys are generated, stored, rotated, and retired;
• Whether HSMs, multisig, or other institutional controls are used;
• How signing authority is segregated and approved;
• How client assets are segregated in wallets and accounting records;
• How reconciliation is performed and by whom;
• What happens in case of key compromise, insider abuse, or chain congestion.

References to ISO/IEC 27001, NIST CSF, and CIS Controls can strengthen the file when they reflect actual implementation rather than marketing claims. The regulator is not looking for buzzwords; it is looking for control ownership and evidence.