Germany MiCA License 2026

MiCA vs old German crypto licensing language

The market still searches for crypto license in Germany because Germany historically regulated certain crypto activities through national concepts, especially under the German Banking Act (KWG) and the well-known crypto custody business perimeter. MiCA did not erase German financial regulation; it changed the primary EU framework for crypto-asset services.

In practice, this means:

• older market language such as BaFin crypto license still appears in commercial use;
• new CASP applicants generally look to MiCA authorization as the main route for in-scope crypto-asset services;
• Germany-specific legal analysis remains necessary where the token or service may qualify as a financial instrument, payment instrument, deposit-like structure, or another regulated product outside MiCA.

A common mistake is to assume that MiCA created a single universal bucket for all tokenized activity. It did not. For example, if the token qualifies as a transferable security or another MiFID II financial instrument, the project may sit outside MiCA entirely. Likewise, tokenized securities or certain electronic securities structures can bring eWpG and capital markets rules into the analysis.

That is why a serious Germany MiCA project starts with a written perimeter memo, not with company formation or policy drafting.

Who needs a Germany MiCA license — and who may not

You need a Germany MiCA license if your company provides one or more regulated crypto-asset services in or from Germany on a professional basis. The analysis turns on what your platform, desk, wallet, app, or API actually does for the client.

Typical activities that often trigger CASP authorization:

• custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders on behalf of clients;
• placing of crypto-assets;
• reception and transmission of orders;
• providing advice on crypto-assets;
• portfolio management on crypto-assets;
• transfer services for crypto-assets on behalf of clients.

Examples that often require deeper perimeter review rather than an automatic yes/no answer:

• software-only wallet interfaces where the provider never controls client keys;
• DeFi front ends with varying degrees of governance, fee capture, or admin control;
• NFT projects where assets may or may not be truly unique and non-fungible in substance;
• white-label providers that claim to be “technology only” but still influence onboarding, execution, custody, or client communications;
• staking, treasury, or yield features that may create additional regulatory touchpoints.

Activities that may fall outside MiCA or into other regimes:

• financial instruments under MiFID II rather than MiCA;
• certain EMT or ART issuance structures with separate issuer obligations;
• payment services or e-money functions potentially touching ZAG;
• fully decentralized arrangements where no identifiable service provider exists, although this is a narrow and fact-sensitive area;
• certain pure infrastructure or software vendors that do not intermediate regulated services.

The practical rule is simple: if your company touches client orders, client assets, client funds, execution logic, or transfer flow, assume licensing analysis is needed. RUE usually starts with a business-model decision tree and a token classification memo before recommending Germany as the home state.

What documents BaFin expects in a MiCA application package

BaFin expects a structured dossier that proves the applicant understands its legal perimeter, can operate the proposed services safely, and has the people, controls, systems, and funding to do so. “Prepare documents” is not enough; the file must work as an evidence package.

Core legal and corporate documents usually include:

• articles of association and company registration extracts;
• ownership chart, shareholder chain, and UBO documentation;
• source-of-funds and source-of-wealth evidence for relevant owners;
• director and key function holder CVs, questionnaires, references, and integrity evidence;
• intragroup agreements, outsourcing contracts, and service-level documentation;
• banking evidence or onboarding strategy where client funds or operational funds are relevant.

Operational and control documents usually include:

• program of operations for each CASP service;
• 3-year business plan and financial projections;
• AML/CFT framework under GwG;
• Travel Rule operating procedure under TFR;
• safeguarding policy and reconciliation procedure;
• complaints handling, conflicts of interest, and client disclosure set;
• outsourcing policy and outsourcing register;
• ICT architecture, information security policy, incident response, BCP/DR, and access control framework;
• risk management framework and wind-down plan.

One practical nuance: BaFin increasingly tests whether the policy set is actually tied to the service scope. A custody provider and a pure advisory CASP should not submit the same depth of safeguarding, wallet governance, and incident playbooks.

RUE prepares Germany MiCA files with version control, cross-document consistency checks, and regulator-facing drafting. That is especially important where founders, developers, and external vendors describe the model differently.

Step-by-step process to obtain a MiCA license in Germany

The normal path to a MiCA License in Germany starts with perimeter review and ends with post-approval operational readiness. A realistic timeline for a well-prepared file is often 3-6+ months, but complex models or weak submissions can take longer.

1. Pre-application perimeter review

Start by defining the exact service scope, token classification, target markets, custody model, and outsourcing structure. This stage usually takes 1-2 weeks for internal scoping and longer if the model touches MiFID II, eWpG, or payment services perimeter questions.

2. Incorporation and substance build-out

Set up the German entity, office, governance structure, key hires, and banking strategy. A GmbH can often be incorporated within 1-4 weeks depending on founder readiness, notarization, and bank/account setup. This is a corporate law step, not the license itself.

3. Dossier preparation

This is usually the most work-intensive phase and often takes 6-10 weeks. The file should include the program of operations, governance map, AML framework, safeguarding design, ICT documentation, financial projections, and all fit-and-proper materials.

4. Filing and completeness review

Once filed, the authority typically performs a completeness check. The legal benchmark under MiCA is commonly referenced as up to 25 working days for completeness review. If the file is incomplete, the clock may not progress cleanly and further requests may follow.

5. Substantive assessment and RFIs

After the file is considered complete, the substantive review period is commonly referenced at up to 40 working days, subject to pauses, extensions, and additional information requests. In practice, this is where most timing variance occurs. BaFin may ask for clarifications on safeguarding, AML design, outsourcing chains, governance, or financial assumptions.

6. Approval and go-live readiness

Authorization is not the same as operational launch. Before go-live, the company should finalize banking, client disclosures, Travel Rule workflow, vendor contracts, reconciliation routines, and incident escalation processes.

What usually delays approval:

• weak or inconsistent perimeter memo;
• thin local substance or unclear decision-making location;
• generic AML documents not tied to actual transaction flows;
• unclear safeguarding and wallet governance;
• outsourcing of critical functions without credible oversight;
• financial projections that do not match staffing and vendor costs;
• slow or incomplete responses to BaFin RFIs.

RUE manages the process as a controlled project with legal, compliance, corporate, and banking workstreams running in parallel. That is usually the fastest way to a file BaFin can actually review.

MiCA vs other German and EU laws: where founders get confused

MiCA is not a universal wrapper for all tokenized business. The first legal question is always: is the token or service actually inside MiCA?

Common perimeter splits in Germany:

• MiCA generally covers crypto-assets that are not already excluded and services performed on them by CASPs;
• MiFID II may apply if the token is a financial instrument, such as a transferable security or another investment-type instrument;
• KWG remains relevant where banking or financial services perimeter issues arise under German law;
• eWpG becomes relevant for certain electronic securities and tokenized capital market structures in Germany;
• ZAG may become relevant where payment services or e-money style functions are present;
• KAGB may matter if the structure resembles a fund or collective investment undertaking;
• Prospectus Regulation and related capital markets disclosure rules may apply to public offerings of securities rather than MiCA white-paper logic;
• DORA and GDPR sit alongside the licensing perimeter and affect day-to-day operations.

When a token is not under MiCA:

• it qualifies as a financial instrument under MiFID II;
• it is a structured deposit or another excluded product;
• it is a genuinely unique NFT rather than a fungible or fractionalized mass product;
• the arrangement is claimed to be decentralized but in fact still has a controllable operator, admin key, fee controller, or governance core—this point often needs close analysis rather than assumptions;
• the product is really an EMT, ART, or payment/e-money structure with separate obligations.

One technical nuance often missed in founder decks: token labels do not decide the perimeter. BaFin and EU supervisors look at rights attached to the token, transferability, settlement mechanics, governance rights, redemption rights, and the economic substance of the arrangement.

RUE therefore combines MiCA licensing with token classification, legal perimeter analysis, and where needed coordination with German corporate, tax, and banking counsel. This avoids filing a CASP application for a model that should have been structured differently from the start.

Practical checklist before you apply for a MiCA license in Germany

Use this pre-filing checklist before spending money on a full BaFin application:

• confirm whether the business model actually falls within MiCA CASP services;
• prepare a written token classification and perimeter memo;
• decide whether Germany is the right home Member State for your target clients and banking strategy;
• select the legal entity structure and map real substance in Germany;
• identify directors, MLRO/compliance coverage, and ICT/security responsibility;
• prepare ownership, UBO, source-of-funds, and shareholder evidence;
• design the safeguarding model and reconciliation logic before drafting policies;
• map fiat flows, banking partners, and payment providers;
• build AML/KYC onboarding, sanctions, KYT, and Travel Rule workflow;
• create outsourcing inventory and vendor oversight framework;
• document ICT architecture, access control, incident response, and BCP/DR;
• prepare realistic 3-year financial projections and own-funds logic;
• align client terms, disclosures, complaints, and conflicts framework;
• test internal consistency across the whole dossier;
• plan post-license operations, not just authorization.

Most failed or delayed applications break on one of these points, not on the headline legal theory.