Crypto License in Germany 2026

CASP under MiCA vs the old German KWG regime

The legal center of gravity shifted from the old German national regime to the EU-wide MiCA framework when MiCA became fully applicable for CASPs on 30 December 2024. Before that, Germany was known for regulating crypto custody under the German Banking Act (KWG), which made BaFin one of the earliest and strictest crypto supervisors in Europe.

That history still matters because BaFin did not become permissive when MiCA arrived. It carried its existing supervisory discipline into the new regime. In practice, that means applicants should expect detailed questions on governance, safeguarding, outsourcing, source of funds, and operational resilience rather than a light-touch form review.

Legacy operators also need transition analysis. Transitional windows under MiCA were not operationally identical across all EU states, and firms that previously relied on national positioning must now test whether their old permissions, exemptions, or business assumptions still fit the MiCA perimeter. A common mistake is assuming that any pre-MiCA crypto activity can simply be relabeled as CASP activity without legal requalification.

Another nuance often missed in market commentary: passporting under MiCA does not retroactively sanitize a badly scoped national business model. If the underlying service mapping is wrong, cross-border expansion only multiplies the compliance risk.

Activities typically covered by CASP authorization

Services typically covered by CASP authorization in Germany are the MiCA-defined crypto-asset services. For most applicants, that means one or more of the following regulated activities:

• 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 for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients;
• placing of crypto-assets;
• providing transfer services for crypto-assets on behalf of clients;
• providing advice on crypto-assets;
• providing portfolio management on crypto-assets.

The licensing strategy should match the minimum viable service scope. Over-applying creates unnecessary prudential, operational, and documentation burden. Under-applying creates conduct risk because the firm may launch features it is not authorized to provide. In Germany, BaFin will compare your requested services against your product roadmap, user journey, fee model, and customer agreements.

A practical drafting point: if your app says “invest automatically,” “optimize yield,” or “rebalance for you,” those phrases may imply portfolio management or advice even if the founders think they are merely offering a technical tool.

The legal framework: BaFin, MiCA, AML, Travel Rule and DORA

The legal framework for a German crypto business in 2026 is a stack, not a single law. At the center sits MiCA — Regulation (EU) 2023/1114, which establishes the authorization and conduct framework for Crypto-Asset Service Providers (CASPs) and separate rules for certain issuers. In Germany, the competent authority for this area is BaFin, working within the broader EU supervisory architecture shaped by the European Commission, ESMA, and EBA.

MiCA answers the question: what crypto services are regulated, who can provide them, what own funds, governance, safeguarding, complaints, and conduct standards apply, and how passporting across the EU works. It does not answer every adjacent question. If the token is an EMT, ART, transferable security, fund unit, or payment instrument, additional regimes may apply.

Regulation (EU) 2023/1113, the recast Transfer of Funds Regulation (TFR), adds the Travel Rule layer. It governs the information that must accompany transfers of crypto-assets and forces firms to build operational messaging, screening, and exception-handling processes around transfers, including scenarios involving unhosted wallets.

GwG, the German AML Act, governs local AML/CFT obligations, beneficial ownership transparency, customer due diligence, suspicious transaction escalation, and interaction with FIU Germany. For crypto firms, GwG compliance is inseparable from product design: onboarding, wallet screening, sanctions checks, and transaction monitoring must be engineered into the platform.

DORA — Regulation (EU) 2022/2554 adds the operational resilience and ICT governance dimension. For regulated firms and adjacent financial entities, the conversation has moved beyond generic “cybersecurity.” Supervisors now expect structured governance around ICT risk management, incident classification, third-party ICT risk, testing, and resilience. Even where DORA applicability must be assessed in the exact fact pattern, no serious German CASP project in 2026 can ignore it.

Further overlap may arise under MiFID II, WpIG, WpHG, ZAG, eWpG, the Prospectus Regulation, and GDPR. That is why RUE treats German licensing as a regulatory architecture project, not a form-filling exercise.

Travel Rule obligations under the EU Transfer of Funds Regulation

The Travel Rule in Europe is governed by Regulation (EU) 2023/1113 and creates a separate operational compliance layer for crypto transfers. In practice, a German CASP must be able to collect and transmit required originator and beneficiary information, screen the transfer, handle exceptions, and preserve a defensible audit trail.

For CASP-to-CASP transfers, the challenge is interoperability: your firm must exchange required data with the counterparty CASP in a timely and reliable way. For CASP-to-unhosted wallet flows, the challenge shifts to risk assessment, sanctions controls, and, where relevant, verification or evidencing of wallet ownership or control. These are not merely policy questions; they affect product UX, transfer release logic, and support workflows.

A credible German implementation typically includes:

• Travel Rule messaging integrated with the transfer engine;
• screening of counterparties and wallet addresses before release;
• case management for missing, inconsistent, or rejected data;
• manual review triggers for high-risk geographies, mixers, or sanctions proximity;
• clear rules for rejecting, holding, or escalating transfers.

One technical nuance often overlooked in licensing files is message persistence. If you cannot prove what Travel Rule payload was sent, when it was sent, whether it was acknowledged, and which compliance rule cleared the transfer, your operational framework is weaker than it appears on paper.

Why DORA matters for crypto firms in 2026

DORA matters because ICT risk is now treated as a board-level regulatory issue, not an IT department issue. For crypto firms seeking German authorization, that changes how security, outsourcing, incident response, and resilience must be documented and governed.

In practical terms, a serious application should show:

• ICT risk governance with board oversight and defined ownership;
• asset inventory and classification of critical systems;
• incident classification and escalation workflows;
• business continuity with realistic RTO/RPO targets;
• third-party ICT risk controls for cloud, custody tech, KYC vendors, and analytics providers;
• testing through tabletop exercises, failover drills, and security assessments.

A practical insight from recent projects: firms that outsource most of their stack to vendors often assume DORA becomes easier. The opposite is usually true. The more critical vendors you have, the more governance, documentation, concentration-risk analysis, and exit planning you need.

Application documents: what BaFin expects to see

BaFin expects a coherent application pack that tells one consistent regulatory story. The strongest files are not the longest; they are the ones where the business plan, governance model, financial forecasts, AML framework, security architecture, outsourcing map, and customer documents all describe the same operating reality.

A typical German CASP application file includes:

• corporate documents, shareholder structure, and UBO evidence;
• directors’ and key function holders’ CVs, questionnaires, and supporting records;
• business plan and 3-year financial projections;
• service descriptions and customer journey mapping;
• AML/CFT framework, business-wide risk assessment, KYC and sanctions procedures;
• IT security documentation, architecture overview, access model, incident response, BCP/DR;
• outsourcing register, vendor due diligence, and key agreements;
• safeguarding and segregation model for client assets and client funds;
• complaints handling, conflicts of interest, and disclosure documents;
• source-of-funds evidence for capitalization.

The hidden test is consistency. If the forecast assumes institutional clients but the AML policy reads like a retail app; if the website promises instant global transfers but the Travel Rule process is manual; if custody is outsourced but no audit rights exist in the contract, BaFin will see the gap immediately.

RUE prepares the file as a single regulator-facing narrative and coordinates adjacent workstreams through Preparation of compliance documents for MiCA application and local legal support.

IT security, custody architecture and outsourcing controls

For German crypto licensing, IT security is not a supporting annex. It is part of the licensing case. BaFin expects the applicant to explain how client assets, customer data, privileged access, transaction integrity, and service continuity are protected in the real operating environment.

For custody or wallet models, the architecture should clearly describe:

• how private keys are generated, stored, used, rotated, and destroyed;
• which assets sit in cold vs hot environments;
• how approvals are segregated across operations, compliance, and security teams;
• what emergency procedures exist for compromise, insider risk, or vendor failure;
• how reconciliations and audit trails are maintained.

In practice, regulated custody discussions now revolve around HSM, MPC, and multisig rather than abstract “secure storage.” None of these is automatically best. The right choice depends on asset mix, transaction frequency, governance design, recovery model, insider-risk tolerance, and vendor concentration.

Applicants should also show mature baseline controls: MFA, SSO, RBAC, immutable logging, secrets management, vulnerability scanning, patch management, and tested backup procedures. External assurance such as ISO/IEC 27001, SOC 2 Type II, and penetration testing can materially improve credibility, especially for B2B and institutional models.

Outsourcing deserves equal attention. Cloud providers, KYC vendors, transaction monitoring tools, Travel Rule networks, custody technology providers, and managed SOC vendors all create dependencies. Under a German regulatory lens, outsourcing is not a shortcut; it is a separate control domain requiring due diligence, contractual audit rights, exit planning, concentration-risk review, and ongoing monitoring.

HSM vs MPC vs multisig — what matters for regulated custody

HSM, MPC, and multisig solve different parts of the custody problem. Regulators care less about buzzwords than about whether the chosen model reduces key compromise risk, insider abuse, single points of failure, and recovery weaknesses.

• HSM (Hardware Security Module): strong for tamper-resistant key protection and controlled cryptographic operations, especially where devices are certified under FIPS 140-2 or FIPS 140-3.
• MPC (Multi-Party Computation): avoids reconstructing a full private key in one place and can support flexible approval workflows across distributed parties.
• Multisig: blockchain-native quorum logic, often operationally transparent, but chain-dependent and not always functionally equivalent across assets.

The real regulatory question is governance: who holds approvals, how thresholds are set, how emergency recovery works, how key ceremonies are documented, and whether the model can survive both internal collusion and vendor outage. A weak MPC deployment with poor access governance can be worse than a well-run HSM setup. Likewise, multisig without disciplined signer segregation is just distributed fragility.

One practical point many founders miss: recovery design is a licensing issue. If your architecture is secure but cannot recover client access after a disaster without violating segregation or creating hidden key concentration, the model is incomplete.

AML/KYC, sanctions screening and transaction monitoring

A credible AML architecture for a German crypto business must connect onboarding, wallet intelligence, sanctions controls, transaction monitoring, and suspicious activity escalation into one operating system. Saying “AML/KYC is required” is not enough.

In practice, the framework should include:

• customer risk scoring at onboarding and throughout the relationship;
• identity verification and beneficial ownership checks;
• source of funds and, where relevant, source of wealth analysis;
• sanctions screening of persons, entities, and wallet addresses;
• blockchain analytics to detect exposure to mixers, darknet services, hacks, scams, and sanctioned ecosystems;
• transaction monitoring using scenario rules and manual review;
• periodic refresh of customer files based on risk;
• case management and FIU escalation where required.

Retail and institutional onboarding should be treated differently. Institutional clients require legal-entity verification, ownership-chain analysis, and often a deeper review of treasury flows, counterparties, and expected activity. Retail clients require scalable controls, but not simplistic ones. If your monitoring thresholds are too high, suspicious flows pass through; if too low, your analysts drown in false positives.

An advanced but increasingly relevant point is sanctions adjacency. Many high-risk wallets are not directly listed but interact with sanctioned services or exploit chains. A mature German AML setup should distinguish direct sanctions hits, indirect exposure, typology risk, and explainable false positives in a documented review process.

Conclusion: is Germany the right jurisdiction for your crypto business in 2026?

Germany remains one of the strongest jurisdictions in Europe for founders who want a high-credibility crypto setup under BaFin supervision. In 2026, the core route is usually MiCA CASP authorization, but the correct answer always depends on the exact service model, token qualification, governance design, and operational architecture.

If your goal is a serious, bankable, institution-ready business with durable EU positioning, Germany is often worth the extra effort. If your model is still legally ambiguous or operationally thin, the right first step is not filing an application. It is a regulatory scope assessment. RUE can map your business to the correct regime, build the documentation stack, and manage the licensing process from structure to post-approval readiness.

Last updated: 09 March 2026. This page is for general information only and does not constitute legal or tax advice.