Luxembourg crypto regulation in 2026 is driven primarily by MiCA (Regulation (EU) 2023/1114), the EU Transfer of Funds Regulation (Regulation (EU) 2023/1113) and Luxembourg AML/CFT supervision led by the CSSF and the FIU Luxembourg. The practical question is not whether crypto is "legal" in Luxembourg, but whether your business model falls within a regulated perimeter requiring authorisation, AML controls, Travel Rule implementation and ongoing supervisory readiness.
Luxembourg crypto regulation in 2026 is driven primarily by MiCA (Regulation (EU) 2023/1114), the EU Transfer of Funds Regulation (Regulation (EU) 2023/1113) and Luxembourg AML/CFT supervision led by the CSSF and the FIU Luxembourg. The practical question is not whether crypto is "legal" in Luxembourg, but whether your business model falls within a regulated perimeter requiring authorisation, AML controls, Travel Rule implementation and ongoing supervisory readiness.
This page is an informational overview, not legal advice. Regulatory perimeter analysis in Luxembourg depends on the exact service, token design, custody model, client base and cross-border footprint.
Key regulatory facts, timeline markers, and practical next steps for a fast initial read.
Luxembourg crypto rules must now be read through the EU rulebook first, then through CSSF supervision and local AML implementation.
The decisive work happens before filing: service mapping, token classification, custody design, governance and outsourcing structure.
Expect iterative regulator questions on AML, governance, ICT controls, complaints handling and operational substance.
Authorisation is the start of supervision, not the end of the compliance project.
Crypto regulation in Luxembourg is not a standalone national code operating in isolation. The practical framework is layered. At the first level, MiCA defines the authorisation and conduct perimeter for crypto-asset service providers and certain issuers across the European Union. At the second level, the Transfer of Funds Regulation imposes the EU Travel Rule architecture for crypto transfers. At the third level, Luxembourg supervision is operationalised through the CSSF, local AML/CFT controls, governance expectations and reporting interfaces involving the FIU Luxembourg. For firms, the decisive issue is whether the business model involves a regulated crypto-asset service, a token issuance activity, or an adjacent regulated function such as payment services, investment services, e-money or custody infrastructure. That is why searches for “Luxembourg crypto regulation”, “Luxembourg crypto rules” and “Luxembourg crypto license” all converge on the same core task: map the service perimeter correctly before launch. In practice, the strongest applications are built around five pillars: precise service classification, credible governance, functioning AML controls, defensible ICT and custody architecture, and a realistic cross-border operating model.
The material change is conceptual. Earlier market practice often treated crypto compliance as a narrow anti-money laundering problem. In 2026, that approach is no longer sufficient for firms carrying on in-scope crypto-asset services. The operating question is now broader: authorisation, conduct, governance, disclosures, complaints handling, ICT resilience, outsourcing control and cross-border rights must be assessed together. A second change is that token analysis has become more granular. Firms must now distinguish between crypto-assets generally, asset-referenced tokens (ARTs), e-money tokens (EMTs), and structures that may fall into other financial-sector categories. A third change is operational: the Travel Rule is no longer a theoretical compliance note but a systems integration project affecting onboarding, wallet screening, transfer workflows, data exchange and exception handling.
| Topic | Legacy Approach | Current Approach |
|---|---|---|
| Primary compliance lens | AML registration or AML-only controls were often treated as the main regulatory hurdle. | MiCA authorisation + AML/CFT + Travel Rule + governance + ICT resilience must be assessed as one operating framework. |
| Meaning of "crypto license" | Used loosely to describe any form of crypto registration or local status. | Usually means CASP authorisation under MiCA, but the exact permission set depends on the services actually provided. |
| Cross-border strategy | Firms often relied on fragmented national analysis. | The value proposition increasingly turns on EU passporting after proper authorisation. |
| Travel Rule compliance | Handled manually or deferred as a future issue. | Requires operational design, data standards such as IVMS101, counterparty due diligence and exception management. |
| Technology review | Security was presented as a generic IT issue. | Custody architecture, MPC/HSM, segregation, incident response, outsourcing governance and resilience metrics are now licensing-grade issues. |
The correct legal map starts with the EU texts, not with a generic national summary. MiCA (Regulation (EU) 2023/1114) sets the core regime for crypto-asset service providers and certain issuers. Regulation (EU) 2023/1113, the recast Transfer of Funds Regulation, extends Travel Rule requirements to crypto-asset transfers. DORA (Regulation (EU) 2022/2554) matters because regulated firms must treat ICT risk, outsourcing, incident management and resilience as board-level obligations rather than technical afterthoughts. Luxembourg then applies these rules through local supervision, AML/CFT controls and institutional practice. A practical nuance that many summaries miss is that a crypto business may sit inside more than one perimeter at the same time: a token can trigger MiCA analysis, while the service layer can also raise payment, e-money, investment, outsourcing or consumer-facing conduct questions.
| Law / Regime | Scope | Applies To | Why It Matters |
|---|---|---|---|
| MiCA — Regulation (EU) 2023/1114 | Authorisation and conduct framework for crypto-asset service providers (CASPs) and rules for certain crypto-asset issuers, including ARTs and EMTs. | Exchanges, custodians, trading platforms, brokers, advisers, portfolio managers, transfer service providers and relevant issuers, depending on the exact model. | It is the central answer to most searches for Luxembourg crypto regulation and Luxembourg crypto license because it defines the permission perimeter and EU passporting logic. |
| Transfer of Funds Regulation — Regulation (EU) 2023/1113 | Travel Rule obligations for transfers of funds and certain crypto-asset transfers, including originator and beneficiary information requirements. | CASPs involved in relevant transfers and transfer workflows. | It converts AML expectations into a concrete data, messaging and operational control framework. |
| DORA — Regulation (EU) 2022/2554 | ICT risk management, incident handling, resilience testing, outsourcing and third-party risk oversight for financial entities in scope. | Relevant regulated firms and their ICT operating model. | It affects cloud governance, vendor oversight, security architecture, registers of outsourcing and incident escalation design. |
| Luxembourg AML/CFT framework | Customer due diligence, beneficial ownership, sanctions screening, suspicious activity escalation, recordkeeping and risk-based controls. | In-scope firms operating from Luxembourg and their compliance functions. | Even a well-structured MiCA application can fail in practice if AML governance, monitoring and escalation are weak. |
| GDPR and data governance | Lawful processing, retention, access control, data minimisation and cross-border data handling for KYC and transaction monitoring data. | Any crypto firm processing personal data in onboarding, screening, monitoring or Travel Rule workflows. | Travel Rule and AML tooling create large personal-data footprints; governance failures here can become parallel compliance problems. |
The CSSF is the main institution founders usually mean when they ask about a Luxembourg crypto regulator, but it is not the only authority that matters. The FIU Luxembourg is central to suspicious transaction intelligence and AML escalation. At EU level, ESMA and EBA shape supervisory convergence, technical standards and interpretive expectations under the EU framework. The European Commission remains the legislative anchor for the underlying regulations, and the ECB can become relevant where token models, banking interfaces or e-money structures intersect with broader prudential questions. The practical lesson is simple: authorisation, AML reporting, token qualification and cross-border operations do not sit in a single box.
Primary Luxembourg supervisory authority for financial-sector authorisation, supervision and enforcement in relevant crypto-related cases.
You need CSSF-facing analysis when your business model may qualify as a CASP, intersects with financial services rules, or requires ongoing supervised operations in Luxembourg.
Receives and processes suspicious transaction intelligence through the AML reporting chain.
Atypical wallet flows, sanctions concerns, source-of-funds anomalies, structuring patterns or other AML red flags can trigger internal escalation and reporting obligations.
Supports supervisory convergence and develops technical and interpretive materials under the EU framework.
Relevant when analysing MiCA implementation detail, market conduct expectations and cross-border supervisory consistency.
Important for prudential, governance and token-related aspects, especially where ARTs and EMTs are concerned.
Relevant when the model touches governance, reserve, safeguarding or issuer-side obligations with banking-adjacent implications.
Legislative source of the EU regulatory architecture.
Relevant for primary-law interpretation and the evolution of the EU crypto rulebook.
Not the day-to-day crypto supervisor for most firms, but relevant in banking and monetary-system-adjacent contexts.
Becomes more relevant where token structures overlap with e-money, payment systems or bank-linked issuance models.
The right question is not “Do we touch crypto?” but “Which regulated function do we perform for clients or the market?” Under the MiCA logic, authorisation analysis usually turns on the service layer: custody, exchange, execution, trading platform operation, order handling, placement, advice, portfolio management and transfer services are the core reference points. A useful perimeter nuance is that control beats branding. Calling a product “non-custodial” does not help if the firm still controls keys, transaction approval logic, omnibus wallets, recovery mechanisms or client asset movement. Another nuance is that token issuance and service provision are different analyses. A firm can be outside the core CASP service list for one activity while still triggering issuer-side obligations or adjacent financial regulation elsewhere.
Custody and administration of crypto-assets on behalf of clients
Usually requires authorisation
Operation of a crypto-asset trading platform
Usually requires authorisation
Exchange of crypto-assets for funds
Usually requires authorisation
Exchange of crypto-assets for other crypto-assets
Usually requires authorisation
Execution of orders for crypto-assets on behalf of clients
Usually requires authorisation
Reception and transmission of orders for crypto-assets on behalf of clients
Usually requires authorisation
Providing advice on crypto-assets
Usually requires authorisation
Providing portfolio management on crypto-assets
Usually requires authorisation
Providing transfer services for crypto-assets on behalf of clients
Usually requires authorisation
Pure software development with no custody, no intermediation and no client-facing regulated service
Needs case-by-case analysis
| Business Model | MiCA Relevance | Adjacent Regimes | Practical Answer |
|---|---|---|---|
| Centralised exchange with client onboarding and order execution | High | AML/CFT, Travel Rule, ICT resilience, sanctions, consumer-facing conduct | Usually requires full authorisation analysis and is commonly within the regulated perimeter. |
| Custodial wallet provider holding or controlling client keys | High | AML/CFT, Travel Rule, security architecture, outsourcing, incident response | Usually treated as a regulated custody-type activity. |
| Broker or routing interface that transmits client orders to other venues | High | AML/CFT, complaints handling, best-execution-style governance logic where relevant | Often within scope if the firm intermediates orders as a business. |
| Advisory desk recommending crypto-assets to clients | Material | Conduct, conflicts, recordkeeping, suitability-style governance depending on structure | Can fall within regulated advice-related services and needs careful scoping. |
| Non-custodial interface with no key control and no execution intermediation | Case-by-case | AML exposure may still arise depending on the operating model, data flows and ancillary services | May fall outside scope, but only if the facts support genuine lack of control and intermediation. |
| White-label infrastructure provider to regulated firms | Case-by-case | Outsourcing, ICT third-party governance, security, data processing | May be outside direct authorisation scope but still critical to regulated outsourcing analysis. |
| Issuer of tokenised value instrument | Depends on token type | ART/EMT analysis, disclosures, reserve or e-money implications, possible securities overlap | Needs token classification before any license conclusion can be reached. |
The first classification question is not whether a token uses blockchain, but what the token represents, how it is marketed, what rights it gives and whether it seeks to stabilise value by reference to assets or official currency. Under the EU framework, firms must distinguish ordinary crypto-assets from ARTs and EMTs, while also testing whether the instrument may instead fall under other financial legislation. A frequent error is to classify by marketing language rather than by rights and redemption mechanics. Another is to ignore fractionalisation: a structure presented as a unique digital item can become much closer to a fungible financial exposure once split, pooled or standardised for trading.
| Category | Core Feature | Typical Trigger |
|---|---|---|
| Crypto-asset | Digital representation of value or rights using distributed ledger or similar technology. | Baseline category for MiCA analysis unless a more specific category or another regime applies. |
| Asset-referenced token (ART) | Purports to maintain stable value by referencing another value, right or combination, including assets or currencies. | Requires enhanced issuer-side analysis and cannot be treated as a generic utility token. |
| E-money token (EMT) | Purports to maintain stable value by referencing the value of one official currency. | Raises e-money-style considerations and demands careful overlap analysis. |
| NFT or purported unique token | Presented as unique, but legal treatment depends on actual economic function and market structure. | Uniqueness labels do not automatically remove the token from regulatory analysis, especially where fractionalisation or standardised economic rights exist. |
| Potential financial instrument or other regulated product | Rights profile may place the token under another financial regime instead of, or in addition to, MiCA. | Always test substance over form before concluding that MiCA is the only relevant framework. |
Yes: Test ART or EMT treatment before applying a generic crypto-asset analysis.
No: Move to the next question on rights, function and other regulated characteristics.
Yes: Assess whether another financial regime may apply in place of, or alongside, MiCA.
No: Continue with general crypto-asset analysis.
Yes: Do not assume NFT-style exclusion; perform substance-based review.
No: Continue to service-perimeter and disclosure analysis.
Yes: Run CASP authorisation analysis even if the token itself is not the main issue.
No: Focus on issuer-side, distribution and marketing perimeter.
The market still uses legacy language, but the legal and commercial consequences are different. A historical AML-focused status addresses anti-money laundering obligations; it does not automatically grant the full permission set, conduct framework or cross-border value of a CASP authorisation under MiCA. That distinction matters in 2026 because firms planning a Luxembourg launch often inherit old assumptions from pre-MiCA structuring memos, group entities or vendor onboarding questionnaires. The practical test is straightforward: if the business wants to provide in-scope crypto-asset services across the EU with a durable supervisory footing, it must analyse the MiCA authorisation route rather than relying on an AML-only narrative.
Useful for AML compliance, but not equivalent to a full authorisation framework for crypto-asset services.
Firms must evidence governance, conduct controls, ICT resilience, complaints handling and service-specific readiness.
Group structures and market-entry plans must be redesigned around authorised services and notification mechanics.
Firms need documented operating procedures, vendor due diligence and tested escalation paths.
An AML/VASP-type status and a MiCA CASP authorisation are not equivalent in scope, supervisory intensity or EU market-access value. Founders should not assume that a legacy compliance posture can simply be relabelled as a Luxembourg crypto license.
A credible application usually moves through four phases: regulatory scoping, entity and governance build-out, documentation and control design, then filing and remediation. In practice, weak applications fail long before the formal submission because the business model has not been mapped precisely enough. The regulator will expect the applicant to explain what it does, for whom, with which tokens, through which wallets, under which outsourcing arrangements, with which control functions and with what incident-response capability. The strongest dossiers are internally coherent: the business plan, financial model, AML risk assessment, custody design, outsourcing map and governance chart all tell the same story.
Define the exact services, token types, client categories, wallet architecture, fiat rails, jurisdictions served, onboarding channels and outsourcing dependencies. This is where you test whether the model is custody, exchange, broker, platform, advice, transfer, issuance or a mixed model. A useful expert practice is to produce a service-by-service perimeter matrix rather than one narrative memo.
Build the Luxembourg entity, board and senior management structure around real decision-making capacity. The regulator will focus on fit-and-proper credibility, segregation of duties, escalation authority, local substance and whether control functions can challenge the business effectively. Nominee-style governance and paper-only substance are recurring red flags.
Prepare the core policy pack: AML/CFT manual, business-wide risk assessment, onboarding procedures, sanctions policy, transaction monitoring methodology, complaints handling, conflicts management, outsourcing policy, information security framework, incident response, key management controls and recordkeeping design. Good applications show how these controls operate in production, not just on paper.
After filing, expect iterative questions on perimeter, governance, outsourcing, ICT, custody, financial assumptions and AML operations. Remediation is normal. What matters is whether the applicant can answer with evidence, decision logs, revised procedures and realistic implementation plans rather than generic promises.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Regulatory perimeter memo | Explains why the business model falls within, outside or across specific regulated services and token categories. | Legal / regulatory lead |
| Business plan and operating model | Shows revenue logic, client journey, products, jurisdictions, outsourcing and growth assumptions. | Founders / strategy |
| Governance map and fit-and-proper pack | Documents board structure, reporting lines, committee logic, senior management responsibilities and suitability evidence. | Board / HR / legal |
| AML/CFT framework and business-wide risk assessment | Sets out customer risk, geography risk, product risk, channel risk, monitoring and escalation methodology. | Compliance / MLRO |
| Sanctions and screening procedures | Defines screening points, escalation thresholds, blocking logic and review ownership. | Compliance / operations |
| Travel Rule operating procedure | Explains data collection, transmission, counterparty checks, exception handling and recordkeeping. | Compliance / product / engineering |
| ICT security and incident response framework | Covers access control, encryption, key management, logging, vendor oversight, incident escalation and recovery metrics. | Security / CTO |
| Outsourcing register and vendor oversight pack | Identifies critical third parties, contract controls, concentration risk and exit planning. | Operations / legal / risk |
| Custody and safeguarding design | Explains wallet segregation, MPC/HSM use, approval workflows, reconciliation and asset movement controls. | Operations / security |
| Complaints handling and client disclosure materials | Demonstrates conduct readiness and customer-facing governance. | Compliance / customer operations |
There is no honest one-number answer to the question “What does a Luxembourg crypto license cost?” because the real spend sits across legal structuring, policy build, staffing, security, regtech, Travel Rule integration, audit support and local substance. Founders often underestimate the recurring operating cost more than the initial application cost. The second common mistake is to budget for documents but not for evidence. Regulators do not authorise slide decks; they assess whether the firm can actually operate the controls it describes. For planning purposes, it is safer to think in cost buckets and a total project horizon of 6–12+ months, with more time for custody-heavy or exchange models.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Legal structuring and perimeter analysis | EUR 20,000 | EUR 80,000+ | Varies with group complexity, token analysis, cross-border footprint and the need for iterative regulator-facing revisions. |
| Governance build and policy documentation | EUR 15,000 | EUR 60,000+ | Includes drafting, tailoring, internal workshops and operating-model alignment rather than template-only documents. |
| AML tooling and blockchain analytics | EUR 10,000 annually | EUR 100,000+ annually | Depends on transaction volume, screening depth, case management and vendor stack such as Chainalysis, Elliptic, TRM Labs or Scorechain. |
| Travel Rule implementation | EUR 5,000 annually | EUR 50,000+ annually | Depends on counterparty network, transaction volume and integration model using providers or standards such as IVMS101-based workflows, TRISA or OpenVASP-type interoperability. |
| Security and custody architecture | EUR 15,000 | EUR 150,000+ | Costs rise sharply for MPC, HSM, secure signing workflows, penetration testing, logging, recovery infrastructure and external assurance. |
| Compliance and MLRO staffing | EUR 70,000 annually | EUR 250,000+ annually | Local senior hires, outsourced support and second-line depth can materially change the cost base. |
| Audit, assurance and external remediation support | EUR 10,000 | EUR 75,000+ | Often omitted from founder budgets even though it becomes necessary once control maturity is tested. |
The main budgeting error is to treat the Luxembourg crypto license as a one-off filing expense. In reality, the durable cost sits in people, controls, technology, vendor oversight and ongoing supervision readiness.
A compliant crypto firm must be able to identify customers, verify beneficial ownership, assess risk, screen sanctions exposure, monitor transactions, escalate anomalies and document why decisions were made. In crypto, that operating model is more data-intensive than in many traditional businesses because wallet activity, blockchain analytics, counterparty exposure and Travel Rule messaging all interact. A useful practical model is to score risk across customer, geography, product and channel dimensions. For illustration only, a firm might use a weighted formula such as Overall AML Risk = (Customer x 0.35) + (Geography x 0.25) + (Product/Service x 0.20) + (Channel x 0.20), then calibrate thresholds through typology testing and alert outcomes. The Travel Rule then sits on top of this framework by requiring originator and beneficiary data handling for relevant transfers. The most mature firms connect onboarding, wallet screening, Travel Rule data exchange and case management in one workflow rather than in separate tools.
| Workflow Step | Control | Owner |
|---|---|---|
| Client onboarding | KYC, UBO verification, sanctions screening, product-risk classification and wallet attribution where relevant. | Compliance / onboarding operations |
| Pre-transfer review | Screen destination or source wallet, assess counterparty CASP status, determine whether Travel Rule data exchange is required. | Operations / compliance |
| Travel Rule messaging | Transmit and receive originator and beneficiary data using an interoperable workflow, commonly aligned to IVMS101-style data structures. | Product / engineering / compliance |
| Transaction monitoring | Run post-event analytics, behavioural rules and sanctions re-checks; generate alerts for anomalies. | AML monitoring team |
| Internal escalation | Case review, evidence capture, MLRO decision and documentation of rationale. | Compliance / MLRO |
| External reporting where required | File suspicious transaction intelligence through the appropriate reporting chain to the FIU Luxembourg. | MLRO |
A properly authorised CASP can use the MiCA framework to provide services across the European Union, which is why Luxembourg remains relevant for internationally oriented crypto businesses. The attraction is not only local market access; it is the combination of a recognised financial centre, multilingual operating environment and a route into wider EU activity. That said, passporting should not be oversold. It depends on the exact authorised services, the notification mechanics and the firm’s ability to operate those services compliantly across borders. Another practical nuance is that cross-border strategy must be aligned with marketing, onboarding, complaints handling, sanctions controls and local consumer-facing restrictions in the target states.
Reverse solicitation should be treated cautiously. It is not a substitute for a proper cross-border permissions analysis, and it is weak as a scaling strategy where the firm actively targets EU clients.
The main enforcement risk is not only formal sanction for unlicensed activity. In practice, perimeter failures cascade. Banking partners can offboard the firm, payment rails can be restricted, counterparties can refuse onboarding, auditors can qualify controls, investors can reprice risk and M&A diligence can expose hidden regulatory debt. A second risk is AML exposure: weak onboarding, poor monitoring or inadequate suspicious activity escalation can create separate liability even where the licensing analysis is still being debated. A third risk is operational: if custody, outsourcing or incident response is weak, a security event can quickly become a supervisory event. This is why mature firms treat Luxembourg crypto regulation as a board-level risk architecture rather than a legal memo.
Legal risk: Potential supervisory action, forced remediation, business interruption and serious market-access consequences
Mitigation: Complete service-by-service perimeter mapping before launch and align product design to the authorised scope
Legal risk: Misstated permissions, invalid cross-border assumptions and exposure in partner due diligence
Mitigation: Separate AML status analysis from MiCA service authorisation and document the difference clearly
Legal risk: AML/CFT breaches, reporting failures and heightened scrutiny from supervisors and banking partners
Mitigation: Implement risk-based onboarding, blockchain analytics, alert governance and MLRO-led escalation
Legal risk: Regulatory findings, counterparty friction and operational disruption of transfers
Mitigation: Deploy interoperable data exchange, counterparty due diligence and exception handling procedures
Legal risk: Governance failures, concentration risk and inability to evidence control over critical functions
Mitigation: Maintain an outsourcing register, due diligence, contractual controls and exit plans
Legal risk: Supervisory escalation, civil claims, contractual breaches and reputational damage
Mitigation: Use layered custody controls, MPC/HSM, segregation, dual approval and tested incident response
A crypto launch in Luxembourg should not defer tax analysis until after authorisation planning. The legal entity structure, revenue model, token flows, treasury policy, transfer pricing and client geography all affect tax treatment and reporting obligations. The correct approach is to connect tax workstreams to the operating model rather than run them separately. A practical nuance is that AML, accounting and tax data models should be reconcilable from the start; otherwise the firm creates avoidable audit friction later.
| Topic | Why It Matters | Responsible Team |
|---|---|---|
| Corporate structuring | Entity design affects substance, transfer pricing, governance and the defensibility of the operating model. | Tax / legal / finance |
| Revenue recognition | Exchange fees, spread income, custody fees, staking-related revenue and token-based income may not be accounted for identically. | Finance / tax |
| Treasury and token inventory treatment | The firm needs a documented accounting and valuation approach for proprietary holdings and client-asset segregation. | Finance / operations |
| Cross-border reporting | EU-facing business models can create multi-jurisdiction reporting touchpoints and data-governance obligations. | Tax / compliance |
| Audit trail integrity | Wallet-level activity, fiat reconciliation and ledger exports must support both audit and tax reporting. | Finance / engineering / operations |
Pre-filing readiness checklist
Sequence these after the core perimeter, governance, and launch-control decisions are stable.
Open the key issues founders, compliance teams and legal leads usually need to confirm before launch.
Yes, crypto activity is not generally prohibited in Luxembourg, but legality does not mean the activity is unregulated. In 2026, the decisive question is whether the business model falls within MiCA, Luxembourg AML/CFT supervision or an adjacent financial-services perimeter. Custody, exchange, platform operation, advice and transfer services usually require formal analysis.
The main Luxembourg supervisory authority is the CSSF. AML intelligence escalation connects to the FIU Luxembourg. At EU level, ESMA, EBA and the European Commission shape the wider framework. For most firms, the CSSF is the central authority in any Luxembourg crypto license discussion.
You may need authorisation if you provide in-scope crypto-asset services such as custody, exchange, execution, order transmission, platform operation, advice, portfolio management or transfer services. The answer is activity-specific. A software-only or genuinely non-custodial model may fall outside scope, but only if the facts support that conclusion.
A legacy VASP/AML-type status addresses anti-money laundering obligations. A CASP authorisation under MiCA is broader: it concerns permission to provide regulated crypto-asset services, conduct obligations, governance, supervision and EU passporting. They are not equivalent in scope or market-access value.
It depends on the firm’s authorisation status, the services offered, the target-market activity and whether MiCA cross-border rights are available. A foreign company should not assume it can serve Luxembourg clients merely because it is licensed elsewhere outside the EU. Cross-border analysis must be done service by service.
Sometimes no, but the answer depends on actual control and functionality. If the provider does not control client keys, does not intermediate execution and does not provide another regulated service, it may fall outside scope. If the provider retains practical control through recovery, delegated signing, omnibus structures or transaction approval logic, the analysis changes.
Some are, some are not. The label “NFT” is not decisive. The analysis depends on uniqueness, fungibility, fractionalisation, economic rights, marketing and whether the token functions more like a standardised financial exposure or another regulated product. Substance prevails over branding.
A realistic planning horizon is often 6–12+ months from initial scoping to launch, depending on complexity. A typical project includes 2–4 weeks of scoping, 6–12 weeks of dossier preparation and 3–9 months of review and Q&A, with additional remediation where needed.
Yes, that is one of the main commercial reasons firms consider Luxembourg. But passporting under MiCA is not automatic in the colloquial sense. It depends on proper authorisation, the services within scope of that authorisation and the relevant notification mechanics for cross-border activity.
Core obligations include KYC, UBO verification, sanctions screening, transaction monitoring, suspicious activity escalation, recordkeeping and Travel Rule data handling for relevant transfers. In practice, firms increasingly rely on blockchain analytics, wallet screening and interoperable data standards such as IVMS101 to operationalise these duties.
If you are unsure whether your model requires a Luxembourg crypto license, whether your current AML setup is sufficient, or how MiCA changes your EU market-access strategy, the next step is a structured perimeter and readiness assessment. The fastest way to lose time is to file before the business model, governance and control architecture are aligned.
