Crypto License in Poland under MiCA – the Cross-Border Route to CASP Authorisation

Until 30 December 2024, any business operating a crypto-currency exchange, intermediation service, or custodial wallet for clients in Poland was required to obtain entry in the Register of Activities in Virtual Currencies – the so-called VASP register, maintained by the Director of the Tax Administration Chamber in Katowice. The regime was AML-only: an internal AML procedure, an appointed AML officer, KYC obligations, reporting to the General Inspector of Financial Information (GIIF), and that was effectively the entirety of the supervisory framework. There were no capital requirements, no fit-and-proper test, no ICT or operational resilience standards, no client-asset segregation rules, and no continuous regulator-led supervision.

MiCA replaces that lighter regime with a full prudential framework. A CASP must meet minimum own-funds requirements ranging from EUR 50,000 to EUR 150,000 depending on the services provided, demonstrate sound governance and the fit-and-proper standing of board members and qualifying shareholders, comply with the Digital Operational Resilience Act (DORA), segregate client crypto-assets from own funds, implement the Travel Rule, and submit to ongoing supervision by the competent national authority.

What changed in Poland is partial. The VASP register has been closed to new entries since 30 December 2024 – the date MiCA began to apply directly. Existing VASPs could continue providing services on the previous basis until 1 July 2026, the standard EU-wide transitional period under Article 143(3) of MiCA. Poland notified ESMA of its intention to shorten that period, but the shortening required the adoption of the national Crypto-Asset Market Act, which has not entered into force. The EU transitional period therefore governed until its expiry on 1 July 2026.

What has not changed in Poland is the absence of a route to authorization. Existing VASPs held a status that expired on 1 July 2026, and the route to a Polish CASP licence remains, for the moment, formally unavailable.

MiCA defines ten regulated crypto-asset services in Article 3(1)(16), governed by Articles 75–82 of the Regulation. A business providing any of these services on a professional basis to clients in the EU requires CASP authorization, regardless of where the business is incorporated or where its infrastructure is hosted.

The ten regulated services are:

• > Custody and administration of crypto-assets on behalf of clients – holding private keys or otherwise controlling access to client crypto-assets.
• > Operation of a trading platform for crypto-assets – bringing together third-party buying and selling interests in a system that results in contracts.
• > Exchange of crypto-assets for funds – converting crypto-assets to fiat currency for clients.
• > Exchange of crypto-assets for other crypto-assets – converting one crypto-asset to another for clients.
• > Execution of orders for crypto-assets on behalf of clients – concluding transactions on the client’s instructions.
• > Placing of crypto-assets – marketing crypto-assets to potential buyers on behalf of an offeror or issuer.
• > Reception and transmission of orders for crypto-assets on behalf of clients – taking orders and forwarding them for execution.
• > Providing advice on crypto-assets – issuing personalised recommendations to clients.
• > Portfolio management on crypto-assets – managing client portfolios on a discretionary basis.
• > Transfer services for crypto-assets on behalf of clients – moving crypto-assets between addresses or accounts on instruction.

Businesses issuing only their own native utility tokens, operating NFT marketplaces limited to genuinely non-fungible items, or running fully decentralised infrastructure may fall outside the CASP perimeter – but the analysis is fact-specific and turns on tokenomics, governance, and the nature of the user relationship. Reverse solicitation under Article 61 of MiCA permits non-EU providers to serve EU clients without authorization, but only where the client genuinely initiates the relationship without solicitation; the burden of proof rests on the provider, and the exemption is interpreted narrowly by EU regulators.

CASP applicants must satisfy four sets of requirements: corporate form, governance, substance, and prudential safeguards.

Corporate form and substance

The applicant must be a legal entity established in the EU, with a registered office in a Member State and at least part of its business activity actually conducted there. A shell with no operational substance will not pass authorization scrutiny. The Management Board must comprise at least two directors, and at least one of them must reside in the EU.

Fit-and-proper standing

Members of the Management Board, qualifying shareholders (holding 10% or more of capital or voting rights), and key function holders must demonstrate good repute; sufficient knowledge, skills, and experience to direct the business; and a clean record regarding offences related to money laundering, terrorism financing, fraud, market abuse, or other financial crime. Qualifying shareholders must submit a detailed ownership and voting-rights chart, and the regulator examines ultimate beneficial ownership through every layer of the structure.

Prudential safeguards (Article 67 of MiCA)

CASPs must hold prudential safeguards at all times equal to the higher of (i) the threshold set in Annex IV of MiCA, or (ii) one quarter of the prior year’s fixed overheads. The Annex IV thresholds are:

Where a CASP provides services in more than one class, the applicable threshold is the highest of the relevant classes (not their sum). Prudential safeguards may be composed of own funds (Common Equity Tier 1, Additional Tier 1, or Tier 2 capital under the Capital Requirements Regulation), an insurance policy covering the territories where services are provided, a comparable guarantee, or a combination of these. The fixed-overheads test ensures that the requirement scales upward as the business grows.

Once a Member State has designated its competent authority and a CASP procedure is operationally available, the application process under Article 62 of MiCA follows a defined sequence. The substantive expectations are uniform across the EU; the procedural details differ slightly between jurisdictions.

Pre-application: scoping and classification

Before any document is drafted, the applicant must answer two questions: which of the ten regulated services it intends to provide, and how each of its products maps to MiCA’s classification of crypto-assets (asset-referenced tokens, e-money tokens, or other crypto-assets). The classification of products is the single most consequential decision in the entire application – it determines the applicable disclosure regime, the prudential class, the conduct rules under Articles 75–82, and whether parts of the offering may instead fall under MiFID II as financial instruments. A scoping memorandum prepared at this stage saves months of rework later.

Documentation package

The Article 62 application package includes, at minimum:

1. 01 a programme of operations describing the services and the business model;
2. 02 a description of governance arrangements, internal controls, and risk-management procedures;
3. 03 the policies on conflicts of interest, complaints handling, outsourcing, and business continuity;
4. 04 the AML/CFT framework and Travel Rule implementation;
5. 05 the ICT systems description and the DORA-aligned operational resilience documentation;
6. 06 a description of the segregation of client crypto-assets and client funds;
7. 07 the prudential safeguards evidence;
8. 08 identity and fit-and-proper documentation for board members, key function holders, and qualifying shareholders; and, where applicable,
9. 09 the operating rules of any trading platform, custody policies, and order-execution policies.

Submission and acknowledgment

The application is filed with the competent authority of the home Member State. Within five working days of receipt, the authority issues an acknowledgment confirming receipt. The acknowledgment is procedural and does not constitute a completeness assessment.

Completeness assessment

The competent authority has 25 working days from receipt to assess whether the application is complete. If it is not, the authority specifies the missing elements and sets a deadline for the applicant to supplement the file. The assessment of completeness is a formal gate – substantive review begins only once the file is declared complete.

Decision

Once the application is complete, the competent authority has 40 working days to issue a decision granting or refusing authorization. The authority may suspend the period to request additional information or clarifications, in which case the suspension does not exceed 20 working days. In practice, the total elapsed time between filing and a decision typically ranges from four to eight months, depending on the complexity of the business model, the responsiveness of the applicant, and the workload of the regulator.

Drawing on direct work with CASP applications – including hands-on work on a CASP application 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.

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.

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.

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

1. 01 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. 02 AML/CFT (the EU AML Package – AMLR (Regulation (EU) 2024/1624) and AMLD6 (Directive (EU) 2024/1640), with AMLA supervision phasing in) – 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. 03 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. 04 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.

Authorisation defines the perimeter; product structuring decides whether the business inside it actually works – and it is a distinct workstream from getting the licence, not a step within it. The core question is whether the product fits the regime you are authorised for. Exchange, brokerage and trading-platform models sit under Articles 76–78; custodial and wallet design under Article 75; a stablecoin (EMT) product and its reserve model under Title IV. The sharpest edge is the PSD2 boundary under Article 70(4), where a crypto product quietly becomes a regulated payment service the moment value moves between unrelated parties.

This is work I have run from inside a regulated exchange, not advised on from the outside. I identified that allowing EMT transfers to third parties would amount to an unauthorised payment service under MiCA and PSD2, and restructured the product so that transfers were limited to accounts belonging to the same client. On a crypto-payments gateway, I screened the settlement flows and had a stablecoin that was not authorised under MiCA removed, closing off a flow that would otherwise have constituted an unauthorised payment service. Yield, “Earn” and staking products raise the same question in a different place – Article 70(1) prohibits using pooled client assets for the CASP’s own account, so a product whose economics depend on that use has to be restructured before the file is filed, not after. The classification analysis is the same one I run on token offerings: get the model wrong and you are authorised, precisely, for the wrong thing.

The AML and Travel Rule stack is a workstream in its own right – designed alongside the application, not bolted on after it – and it is where CASP files most often thin into a TradFi copy-paste that fails substantive review. The Travel Rule, built on FATF Recommendation 16 and implemented in the EU through the Transfer of Funds Regulation (TFR), was drafted for account-based, intermediated payments. Crypto does not always behave that way: CASP-to-CASP transfers, self-hosted wallets, UTXO-based transactions and batched settlements each raise mechanical questions a payment-services manual does not answer.

I led exactly this build from inside a regulated exchange – deciding what originator and beneficiary information to collect, and how to treat UTXO transactions on Bitcoin, at a point when no settled market guidance yet existed and the IT side needed concrete answers under time pressure. Around the Travel Rule sits the rest of the programme: the AML/CFT framework and risk-based controls, customer due diligence (CDD/EDD), sanctions and PEP screening, GIIF reporting procedures and AMLCO role design, and supervisory readiness for the EU AML Package – AMLR (Regulation (EU) 2024/1624) and AMLD6 (Directive (EU) 2024/1640), with AMLA supervision phasing in. Designed as frameworks and controls for the obliged entity to operate – not a compliance function performed on its behalf.