How to Get a Crypto License in Poland under MiCA (CASP)

Common Mistakes I See in CASP Applications

Drawing on direct work with CASP applications – including a successful authorization before CySEC and licensing work in Estonia – the same patterns of error recur across applicants. Six of them account for the majority of avoidable delays and post-authorization risk.

1. Mis-classifying products under MiCA

Applicants frequently treat product classification as a downstream documentation task rather than the foundational legal exercise it is. A token may be marketed as a “utility token” while functionally meeting the criteria of an asset-referenced token; a wrapped instrument may sit closer to a financial instrument under MiFID II than to a MiCA crypto-asset; a perpetual product may exhibit the economic features of a derivative. Each mis-classification cascades through the application: the wrong disclosure regime, the wrong prudential class, the wrong conduct rules, and – in the worst case – the wrong regulator. Regulators read product structures forensically. Where the legal classification is unclear or the product structure is unnecessarily complex, the file is treated as a red flag and substantive review is suspended pending a clean restatement.

2. Treating Travel Rule as a TradFi compliance copy-paste

Article 14 of Regulation (EU) 2023/1113 requires CASPs to accompany every transfer of crypto-assets with originator and beneficiary information. The rule was drafted on the model of FATF Recommendation 16 for wire transfers – a model built around account-based, intermediated payment systems. Crypto-assets do not always behave that way. UTXO-based transactions, transfers to and from self-hosted wallets, batched on-chain settlements, and refund flows each raise mechanical questions that the TradFi compliance template does not answer. Applicants who present a Travel Rule policy that simply ports across language from a payment-services AML manual fail the substantive review. The correct approach documents how each transaction archetype is captured, what data is collected, where it is stored, and how the CASP handles counter-party CASPs that are not yet Travel Rule-compatible.

3. Misreading Article 77 disclosure obligations

Article 77 of MiCA requires CASPs operating exchange and order-execution services to publish details of executed transactions. The provision is intended to support market integrity and equal treatment of clients. It also exposes spreads, pricing logic, and counterparty patterns that a CASP would ordinarily treat as commercially sensitive. Two errors recur. The first is underestimating the scope of the obligation at the application stage and discovering it post-authorization. The second is over-engineering compliance into a form that is technically correct but practically inaccessible to the average client – for example, an API-only feed with no human-readable presentation. Regulators increasingly read the second pattern as a substantive transparency failure rather than a compliance success.

4. Compliance pitfalls in product design: Articles 70 and 76(5)

Two MiCA provisions catch applicants whose product design predates regulatory analysis. The first is Article 70(1), which requires that client crypto-assets and client funds be safeguarded and segregated from the CASP’s own assets at all times. Yield, “Earn,” staking, and lending products built on pooled client assets often rely on the CASP using those assets – even temporarily, even in low-risk strategies – for its own account. Where the product economics depend on that use, the product as designed is not compatible with Article 70(1) and must be restructured before the application is filed, not after.

The second is Article 76(5), which prohibits a CASP operating a trading platform from executing client orders against its own proprietary capital on that platform unless the platform is a multilateral trading facility and the rules of the platform expressly permit it under defined conditions. Applicants who run an internal market-making desk, fill client orders from house inventory, or use the trading platform to manage their own treasury exposure typically discover this prohibition during regulator review, when the only fix is a structural separation of the trading platform from the proprietary book – a far costlier restructuring at that stage than at the design stage.

5. Choosing the jurisdiction without an operational analysis

MiCA harmonizes the substantive rules; it does not harmonize the practical experience of applying. Regulators differ markedly in the language they accept for documentation, the willingness to hold pre-application meetings, the depth of clarification provided during review, and the expected turnaround for written queries. Some authorities – the Estonian Financial Supervision Authority and CySEC among them – accept English-language documentation and engage in active dialogue with applicants. Others adhere to a stricter, paper-based model in the local language with limited substantive interaction during review. These operational differences materially affect the timeline, cost, and risk profile of an application. Applicants who choose a home jurisdiction on the basis of capital requirement minima or perceived prestige – without an operational analysis of how the regulator actually conducts authorization – discover the cost of that choice during the review, when the cost can no longer be undone.

6. Overlooking the boundary between MiCA and PSD2

MiCA regulates crypto-asset services. Directive (EU) 2015/2366 (PSD2) regulates payment services. The boundary between the two becomes material wherever a CASP handles e-money tokens (EMTs), because EMTs are, by definition, electronic money under Article 48 of MiCA – and moving electronic money between unrelated parties is, by definition, a payment service. Two design patterns trigger this issue. The first is allowing clients to send EMTs from their CASP account to a third party who is not the same client – a peer-to-peer EMT transfer that, executed by the CASP, may constitute a payment service requiring a separate PSP authorization. The second is offering a payment-acceptance product (a crypto payments gateway) that settles merchant transactions in EMTs, which sits squarely within payment-services territory regardless of how the front-end is described. Applicants who do not screen their product set against PSD2 at the design stage frequently find that part of their offering cannot be authorized under MiCA alone, and either restructure the product or pursue a parallel PSP authorization track.

Timelines and KNF Practice in Poland

The statutory timeline under Article 63 of MiCA – five working days for acknowledgment, 25 working days for completeness assessment, 40 working days for a decision once the file is complete, with a possible 20-working-day suspension for additional information – describes the procedural maximum. The realistic elapsed time between filing and a decision in most EU jurisdictions ranges from four to eight months, driven primarily by the iterative back-and-forth on documentation rather than by the formal review periods.

In Poland specifically, two factors will shape the practical timeline once the national law enters into force. First, KNF has historically conducted authorization processes in Polish, with documentation required in Polish – a working assumption that adds translation time and cost for foreign applicants. Second, KNF’s existing practice in payment-services and investment-services authorizations leans toward written, paper-based interaction rather than pre-application meetings or substantive dialogue during review. Applicants accustomed to the more conversational style of CySEC, the Estonian FSA, or the Hungarian MNB should plan for a longer and more formalised exchange.

Cross-Border Passporting and Reverse Solicitation

Article 65 of MiCA establishes a single-licence passport across the EU. A CASP authorized in any Member State may provide its services in any other Member State by notifying the home regulator at least 40 working days before service commencement; the home regulator transmits the notification to the host regulator within 10 working days. No host-state authorization is required, and host states may not impose authorization conditions on top of the home-state licence. For Polish-market participants, this is the operational answer to the current legislative gap: a CASP authorization obtained in Cyprus, Estonia, Germany, France, or Liechtenstein passports into Poland on the same terms as a domestic licence would.

Article 61 of MiCA contains a narrow exemption for non-EU providers: a third-country firm may serve an EU client without authorization if the client initiated the relationship at its own exclusive initiative. The exemption is interpreted strictly. The provider bears the burden of proof, may not solicit further services or new product categories beyond the original initiation, and must maintain documentary evidence of how each relationship began. Reverse solicitation is a defensive position for legacy relationships, not a market-entry strategy.

Ongoing Obligations after Authorization

Authorization is the entry point, not the endpoint. A licensed CASP carries continuous obligations across four regulatory regimes:

1. MiCA (conduct, prudential, transparency) – maintaining own funds at the level applicable to the services provided, complying with the conduct rules in Articles 66–82, publishing required disclosures, segregating client assets, and notifying the competent authority of material changes to the business.
2. AML/CFT (AMLD5/6 and the AML Package adopted in 2024) – internal AML procedure, designated AML officer, KYC and ongoing monitoring, transaction analysis, source-of-funds verification, suspicious-transaction reporting to the national Financial Intelligence Unit, and quarterly reporting where applicable.
3. Travel Rule (Regulation (EU) 2023/1113) – transmission of originator and beneficiary information with every crypto-asset transfer, and the corresponding policies for self-hosted wallets and non-compliant counterparty CASPs.
4. DORA (Regulation (EU) 2022/2554) – ICT risk management framework, ICT third-party risk register, incident classification and reporting, digital operational resilience testing, and information-sharing arrangements where adopted.

The breach consequences scale with the regime. MiCA permits administrative fines of up to EUR 5 million or 3% to 5% of annual turnover for legal persons, depending on the violation, and Member States may impose additional criminal sanctions. Regulators increasingly cross-reference compliance across these regimes during periodic supervisory reviews.