MiCA License in Poland 2026

MiCA vs the old Polish VASP regime

The old Polish regime was not a MiCA authorization regime. Historically, Poland operated an AML-focused registration model for activities involving virtual currencies. That older framework was materially lighter than a full CASP authorization under MiCA and should not be described as a “CASP license since 2021.”

Key differences:

• Old model: registration and AML compliance focus, with lower entry barriers and no MiCA-style prudential/governance architecture.
• New model: authorization-based regime with own funds, governance, safeguarding, complaints handling, outsourcing controls, and conduct obligations.
• Old model: no automatic EU passporting logic under MiCA.
• New model: EU-wide passporting after authorization and notification.

The commercial consequence is significant. A business that was viable under the old Polish VASP-style setup may not be viable under MiCA without additional capital, stronger management, better AML tooling, and a more mature operating model. Existing operators should therefore run a structured VASP-to-CASP gap analysis rather than assume continuity.

For broader regulatory background, see cryptocurrency regulation in Poland and our general CASP license guide.

Why “MiCA license in Poland” usually means CASP authorization

For most operating businesses, a MiCA license in Poland means authorization as a Crypto-Asset Service Provider. That covers the firms actually providing regulated crypto-asset services: custody, exchange, order execution, transfer, portfolio management, advice, placing, reception/transmission of orders, and operation of a trading platform.

The phrase becomes incomplete when the business is primarily an issuer. If the project issues an asset-referenced token (ART) or an e-money token (EMT), MiCA applies through a different and heavier track. In particular, EMT issuance is generally reserved to credit institutions or electronic money institutions, which means some token models cannot be solved by a standard CASP filing alone. Founders exploring payment-like token structures should also review our EMI license in Poland page.

A second perimeter issue is MiFID II. If the token qualifies as a financial instrument, it falls outside MiCA and into securities law logic. This is why listing committees, token issuers, and legal teams should run a formal perimeter memo before drafting the application.

Who needs a CASP authorization in Poland

Any person or company providing regulated crypto-asset services in or from Poland on a professional basis should assume a CASP analysis is required. The answer does not depend on whether the platform calls itself an exchange, wallet app, broker, OTC desk, or infrastructure provider. It depends on what the business actually does.

Typical models that require authorization include:

• custodial wallet providers holding client keys or controlling transfer execution;
• crypto-to-crypto and crypto-to-fiat exchanges;
• OTC brokers executing trades for clients;
• platforms matching third-party buy and sell interests;
• firms transmitting or executing client orders in crypto-assets;
• portfolio managers making discretionary decisions on client crypto portfolios;
• advisers recommending crypto transactions or portfolio allocations;
• firms transferring crypto-assets on behalf of clients.

The perimeter becomes more nuanced for software-only providers, DeFi interfaces, NFT projects, treasury operations, validators, and token issuers. A non-custodial front end may still create regulated touchpoints if the operator effectively controls execution, onboarding, fees, routing, or client-facing intermediation. This is why RUE starts most Poland MiCA projects with a written service mapping and legal qualification matrix.

CASP classes, capital requirements and license scope

The correct Poland CASP scope is the narrowest scope that still matches the real business model. Over-applying increases cost and review complexity. Under-applying creates perimeter risk, re-filing costs, and future enforcement exposure.

In practical planning, founders often use a three-level capital matrix:

• Class 1 / €50,000: narrower service models such as advice, portfolio management, order reception/transmission, or transfer services.
• Class 2 / €125,000: broader intermediary models such as execution or exchange without the highest-risk platform/custody profile.
• Class 3 / €150,000: custody/administration and trading platform operation, where safeguarding and operational risk are materially heavier.

The exact legal mapping should always be checked against the final service mix and MiCA text. Founders should not choose a class by analogy to another jurisdiction or by what a software vendor calls the product. The correct method is: service map → legal qualification → capital bucket → governance load → budget.

Capital is not the full budget: realistic launch cost model

The minimum own-funds figure is not the amount required to launch a Poland CASP. For most applicants, the real budget is several times higher once legal work, staffing, tooling, banking, and post-license readiness are included.

A realistic founder budget usually includes:

• company setup and corporate documentation: incorporation, KRS filings, office, translations, notarial actions where needed;
• licensing work: legal drafting, application pack, governance documents, financial model, regulator responses;
• compliance tooling: KYC/KYB, sanctions screening, blockchain analytics, Travel Rule, case management;
• people: compliance lead, AML function, legal support, operations, support staff, or outsourced equivalents;
• ICT and security: cloud, monitoring, incident response, penetration testing, DORA artefacts;
• banking and PSP onboarding: due diligence packs, reserve requirements, onboarding fees, fallback providers.

Planning formula: Initial funding = minimum capital + 12-month operating expenses + one-off setup costs + contingency reserve. For advisory-only models, the total launch envelope may still be manageable. For custody or exchange models, founders should expect materially higher burn because safeguarding, reconciliation, support, and security controls are heavier from day one.

RUE can also coordinate crypto business bank account support and Polish accounting setup as part of the launch budget.

Legal entity, substance and management requirements in Poland

A Polish CASP applicant needs a legal and governance structure that can be supervised in practice. The usual starting point is a Polish company registered in KRS, with tax and statistical identifiers such as NIP and REGON. Foreign founders can own the company, but ownership transparency and source-of-funds evidence are critical.

Which company form to use: sp. z o.o., S.A. or P.S.A.?

For most CASP projects, a sp. z o.o. is the default choice. It is familiar, workable, and efficient for founder-led and investor-backed setups. An S.A. may make sense for more complex capital structures or future institutional positioning. A P.S.A. can be attractive in innovation-heavy ventures, but it is not automatically the best fit for a regulated financial-services style application where governance conservatism matters.

The right choice depends on:

• capital-raising plans;
• board structure and investor rights;
• whether the business expects later transformation or institutional funding;
• how the entity will present itself to banks, auditors, and the regulator.

For founders who need local setup support, see company incorporation in Poland by power of attorney.

Directors, shareholders and UBO due diligence

The fit-and-proper review is about credibility, not paperwork volume. Directors and key shareholders should be able to explain the business model, risk controls, source of funds, and their actual role in governance. Typical document sets include criminal record certificates, detailed CVs, ownership charts, declarations on conflicts, and evidence of relevant experience.

A subtle but important point: regulators and banks increasingly test time commitment. A director or compliance lead holding multiple roles across unrelated businesses may look formally qualified but operationally weak. The stronger file shows decision rights, reporting lines, and real availability.

Compliance architecture required for a Poland MiCA license

A CASP license is an operating system, not a PDF bundle. The applicant should be able to show how governance, AML/CFT, Travel Rule, safeguarding, complaints handling, outsourcing, and ICT risk management work together on a daily basis.

AML/CFT, sanctions screening and GIIF reporting

The AML framework should start with a business-wide risk assessment tied to actual products and client types. A Polish CASP should define onboarding tiers, beneficial ownership checks, sanctions and PEP screening, KYT triggers, escalation paths, and reporting logic to GIIF. Stronger files also define how blockchain analytics alerts interact with manual review and when a wallet exposure becomes a customer risk issue rather than a transaction-only issue.

Travel Rule implementation under Regulation (EU) 2023/1113

Travel Rule compliance is an operational data-flow problem. For outbound and inbound transfers, the CASP should be able to collect, verify, transmit, receive, and retain originator and beneficiary information. Mature setups usually document:

• required data fields and validation logic;
• counterparty CASP identification and screening;
• self-hosted wallet checks and risk scoring;
• audit trail retention;
• messaging interoperability, often referencing IVMS101.

One practical nuance: Travel Rule failures often arise not from missing software, but from unresolved exception handling for incomplete inbound data, sanctions hits, and transfers involving nested service providers.

DORA and ICT governance for CASPs

DORA requires governance over ICT risk, incidents, and third-party dependencies. Applicants should maintain an ICT asset inventory, incident classification matrix, access management rules, backup and recovery logic, vendor register, and testing plan. Exchange and custody models should also document privileged-access control, key ceremony logic where relevant, and change management for wallet infrastructure.

Safeguarding client assets, custody controls and complaints handling

Safeguarding is where legal drafting meets operational evidence. The CASP should show segregation of client assets, reconciliation routines, wallet governance, approval thresholds, and recovery procedures. Complaints handling should not be a generic inbox policy; it should define intake, categorization, responsible owner, response times, remediation tracking, and record retention. Where personal data is processed, GDPR governance should align with the complaints and onboarding workflow.

For firms needing document support, see preparation of compliance documents for MiCA application.

Documents required for a CASP application in Poland

A complete application pack should read like a regulated operating manual for the business. At minimum, founders should expect to prepare:

• corporate documents for the Polish entity;
• ownership chart and UBO disclosures;
• proof of capital and source of funds;
• business plan and 3-year financial forecasts;
• governance map, board roles, and fit-and-proper files;
• AML/CFT policy suite and risk assessment;
• Travel Rule operating procedure;
• DORA / ICT governance documents;
• safeguarding and custody control documents where relevant;
• complaints, conflicts, outsourcing, and incident-response policies;
• vendor inventory and key contracts;
• client disclosures and terms.

Corporate, financial and governance documents should be internally coherent. If the forecast shows rapid scaling, the staffing plan and vendor stack must support it. If the applicant requests custody, the governance file should identify who approves wallet movements, who reconciles balances, and how incidents are escalated.

Policy suite and operational documentation should usually cover at least these categories: AML/KYC, sanctions, risk management, conflicts of interest, outsourcing, complaints handling, safeguarding, information security, incident response, business continuity, record-keeping, and staff training. Copy-paste policy packs are easy to spot because they fail to match the applicant’s actual services and systems.

Risks, sanctions and common reasons applications fail

Most failed or delayed applications suffer from credibility gaps, not just missing forms. The KNF, banks, and counterparties all test whether the business can operate safely, transparently, and with real control over risk.

Top 10 mistakes founders make

1. Wrong perimeter analysis: the requested scope does not match the real business model.
2. Weak governance: directors are nominal and cannot explain the operating model.
3. Copy-paste policies: documents do not reflect actual products, vendors, or workflows.
4. Unclear source of funds: capitalization is not documented cleanly.
5. No banking strategy: the business has no credible fiat-flow or payment-partner plan.
6. Underbuilt AML stack: no real KYT, sanctions, or case-management logic.
7. Travel Rule gaps: no exception handling for incomplete or high-risk transfers.
8. DORA blind spots: no incident register, vendor register, or tested BCP/DRP.
9. Unrealistic forecasts: revenue assumptions ignore compliance and support costs.
10. Poor regulator responses: RFIs are answered slowly, defensively, or inconsistently.

Sanctions exposure is a particular risk area in 2026. A firm may have a technically compliant onboarding flow and still fail a banking or supervisory credibility test if it cannot explain jurisdictional restrictions, wallet screening logic, nested counterparty risk, or how it handles exposure to mixers, darknet-linked wallets, or sanctioned services. This is one reason RUE treats sanctions controls as a board-level governance issue, not only an AML-operations issue.