Lithuania cryptocurrency regulation in 2026 is no longer a legacy VASP story. The operative framework is MiCA, the EU Transfer of Funds Regulation (TFR) for crypto transfer data, Lithuanian AML/CFT law, and adjacent operational rules such as GDPR and, where applicable, DORA. For founders, compliance leads and legal teams, the real question is not whether Lithuania is “crypto-friendly”, but whether the planned business model fits the CASP perimeter, capital class, governance expectations and post-licensing operating burden.
This page is an informational regulatory guide prepared by RUE for 2026. It is not legal, tax, or investment advice. Crypto regulation depends on the exact service scope, token design, customer geography, group structure and supervisory interpretation at the time of application.
Key regulatory facts, timeline markers, and practical next steps for a fast initial read.
Lithuania was often discussed through AML registration and national crypto business setup logic rather than full MiCA authorisation architecture.
The market had to separate legacy VASP language from the new EU-wide CASP framework and prepare for the end of transitional reliance.
New analysis should start with CASP scope, token classification, TFR compliance, governance substance and passporting mechanics.
Lithuania cryptocurrency regulation in 2026 is an EU-first compliance exercise, not a simple local company registration project. The legal perimeter is built around Regulation (EU) 2023/1114 (MiCA) for crypto-asset services and token-related disclosures, the recast Transfer of Funds Regulation for crypto transfer data, Lithuanian AML/CFT law for anti-money-laundering controls, and adjacent rules on data protection, outsourcing, accounting, tax and corporate substance.
The Bank of Lithuania is the authority to watch for CASP authorisation and supervisory expectations. FCIS / FNTT remains critical for AML/CFT practice. This split matters operationally: a file can look legally coherent on paper but still fail in practice if the AML narrative, source-of-funds logic, sanctions controls, self-hosted wallet procedures or suspicious activity escalation process are weak.
The most common strategic mistake is treating Lithuania as a “fast licence” jurisdiction without modelling the post-licensing burden. In the MiCA era, the winning application is usually the one that connects business model, service taxonomy, governance, ICT controls, outsourcing oversight, complaints handling and cross-border rollout into one consistent supervisory story.
The key change is conceptual: Lithuania no longer should be analysed through a standalone “crypto licence” marketing lens. In 2026, the correct starting point is whether the business falls within MiCA’s CASP perimeter, whether any token qualifies as a crypto-asset subject to disclosure or issuer rules, and how the business will satisfy TFR Travel Rule, AML/CFT, governance and operational resilience requirements.
Another major change is that passporting now sits inside an EU authorisation architecture. A Lithuanian setup can still be attractive, but the value proposition is no longer “register locally and operate everywhere”. The real value is obtaining a compliant authorisation in one EU member state and then using the proper notification route for cross-border activity.
| Topic | Legacy Approach | Current Approach |
|---|---|---|
| Core licensing label | Market often used “VASP licence” as the default label for Lithuanian crypto activity. | The operative label for regulated crypto-asset services is CASP authorisation under MiCA. |
| Regulatory map | AML registration logic often dominated the analysis. | Analysis must combine MiCA + TFR + Lithuanian AML law + GDPR + corporate/tax rules, and in relevant cases operational resilience obligations. |
| Cross-border model | One local setup was often marketed as de facto EU access. | EU access depends on passporting procedure, service scope and proper supervisory notifications. |
| Application quality | Template documents and light substance were often marketed as sufficient. | Supervisory focus is on fit-and-proper, governance, outsourcing oversight, complaints handling, financial projections and real operating substance. |
| Token projects | Issuance was often bundled into generic “crypto licence” discussions. | Token issuance must be analysed separately: utility crypto-assets, ARTs, and EMTs follow different MiCA tracks. |
| Operational compliance | Post-registration burden was often understated. | Ongoing compliance includes Travel Rule data exchange, AML monitoring, record retention, governance reviews, incident handling and reporting. |
No single act regulates all crypto activity in Lithuania. The legal framework is layered. MiCA governs authorisation, conduct and certain disclosure rules for crypto-assets and crypto-asset service providers. The Transfer of Funds Regulation adds mandatory originator and beneficiary data requirements for crypto transfers. Lithuanian AML/CFT law governs customer due diligence, suspicious activity controls and local anti-financial-crime enforcement. GDPR applies because crypto businesses process large volumes of customer and transaction-related personal data.
A practical nuance often missed in market guides is that outsourcing and ICT architecture are not side issues. Even where a crypto company relies heavily on third-party KYC, screening, wallet infrastructure or analytics vendors, the regulated entity remains responsible for oversight, escalation and auditability. This is one of the main reasons weak applications fail despite having a polished legal memo.
| Law / Regime | Scope | Applies To | Why It Matters |
|---|---|---|---|
| Regulation (EU) 2023/1114 (MiCA) | Authorisation and conduct framework for crypto-asset service providers; disclosure and issuer rules for certain crypto-assets; prudential, governance, complaints and operational obligations. | CASPs, offerors, persons seeking admission to trading, and issuers depending on token type and activity. | This is the main legal basis for assessing whether a Lithuanian crypto business needs authorisation and what services can be passported across the EU. |
| EU Transfer of Funds Regulation (recast TFR) | Travel Rule layer for crypto transfers, including transmission of originator and beneficiary information between relevant service providers. | CASPs involved in covered crypto transfers and related transfer workflows. | A business can be well-structured under MiCA and still fail operationally if it cannot exchange required transfer data in a compliant and auditable way. |
| Lithuanian AML/CFT law | Customer due diligence, enhanced due diligence, sanctions-related controls, suspicious transaction escalation, internal controls, record retention and AML governance. | Obliged entities operating in Lithuania, including crypto businesses within the relevant perimeter. | This is the local enforcement layer that determines how AML/CFT obligations work in practice, including interactions with FCIS / FNTT. |
| GDPR and Lithuanian data protection framework | Lawful basis for processing, retention, data subject rights, cross-border transfers of personal data, vendor processing terms and security of personal data. | Any crypto business processing customer, employee, beneficial owner or transaction-related personal data. | Travel Rule, KYC, sanctions screening and blockchain analytics all create data protection implications that must be reflected in policies and vendor contracts. |
| Corporate, accounting and tax rules in Lithuania | Company formation, beneficial ownership disclosure, bookkeeping, financial statements, tax filings and corporate maintenance. | Lithuanian legal entities, including UAB structures used for crypto operations. | Authorisation does not replace ordinary company law and tax compliance; weak corporate housekeeping often surfaces during due diligence and banking reviews. |
| Operational resilience and ICT control expectations | Security governance, incident handling, business continuity, vendor oversight and resilience of critical systems. | Relevance depends on business model, group structure, outsourcing design and the exact regulatory perimeter. | Supervisors increasingly expect crypto firms to evidence real control over wallet infrastructure, access rights, key management, logging and incident escalation. |
Crypto in Lithuania is supervised through an institutional stack, not by one office acting alone. The Bank of Lithuania is the central authority for MiCA authorisation and supervisory dialogue. FCIS / FNTT is critical for AML/CFT enforcement and anti-financial-crime practice. Registrų centras handles company and register infrastructure. VMI matters for tax treatment and reporting. For token projects and cross-border models, founders should also monitor the convergence role of ESMA and EBA.
The practical implication is simple: a compliant launch requires alignment across licensing, AML, corporate records, tax and data governance. A business that focuses only on the authorisation file usually discovers the missing pieces during banking, audit, vendor onboarding or first supervisory questions.
| Authority | Role | Typical Trigger |
|---|---|---|
| Bank of Lithuania (Lietuvos bankas) | Competent authority for CASP authorisation and supervision under the applicable MiCA framework in Lithuania; reviews governance, prudential setup, business model clarity and control environment. | CASP application, scope expansion, passporting communication, supervisory review. |
| Financial Crime Investigation Service (FCIS / FNTT) | Key AML/CFT enforcement authority; relevant for suspicious transaction logic, anti-money-laundering controls, financial crime risk expectations and practical enforcement posture. | AML/CFT compliance, suspicious activity escalation, inspections, anti-financial-crime remediation. |
| Centre of Registers (Registrų centras) | Maintains legal entity and related corporate register infrastructure, including company establishment and corporate record maintenance. | Entity incorporation, corporate changes, beneficial ownership and register maintenance. |
| State Tax Inspectorate (VMI) | Tax administration authority relevant for corporate income tax, VAT analysis, withholding tax context and tax reporting obligations. | Tax registration, returns, audits, clarification of tax treatment. |
| ESMA / EBA | EU-level convergence, technical standards and interpretive environment, especially relevant for MiCA implementation, token categories and prudential expectations. | Interpretation of EU-level rules, technical standards, supervisory convergence. |
A business needs authorisation analysis if it performs a regulated crypto-asset service, not simply because it uses blockchain. In Lithuania, the right question is whether the operating model falls within the MiCA service perimeter. That includes activities such as custody and administration of crypto-assets on behalf of clients, operating a trading platform, exchanging crypto-assets for funds, exchanging crypto-assets for other crypto-assets, executing orders, placing crypto-assets, receiving and transmitting orders, providing advice on crypto-assets, portfolio management and transfer services for crypto-assets on behalf of clients.
A useful practical distinction is between technology providers and service providers. Pure software development, non-custodial tooling or infrastructure support may fall outside the authorisation perimeter if the business does not intermediate regulated services. But once the company controls client onboarding, order flow, custody, settlement logic, transfer execution or client-facing intermediation, the authorisation analysis usually becomes unavoidable.
| Business Model | MiCA Relevance | Adjacent Regimes | Practical Answer |
|---|---|---|---|
| Fiat on-ramp / off-ramp exchange | High | AML/CFT, TFR, sanctions, tax, GDPR | Usually requires CASP analysis and, in most cases, authorisation. |
| Custodial wallet provider holding client keys | High | AML/CFT, TFR, security governance, outsourcing controls | Usually within the regulated perimeter because custody and administration risk is central. |
| Broker or app routing client crypto orders | High | AML/CFT, complaints handling, order governance | Often falls into reception/transmission and possibly execution or advice depending on the model. |
| Non-custodial analytics or wallet software vendor | Model-dependent | GDPR, B2B contracting, IP, cybersecurity | May sit outside CASP scope if it does not intermediate regulated services or control client assets. |
| Token issuer raising funds from the public | Separate issuer analysis required | MiCA white paper rules, consumer disclosures, AML, marketing review | Do not assume a standard CASP authorisation solves issuance obligations. |
| DAO-like front-end with central operating team | Fact-specific but potentially high | AML/CFT, consumer law, governance attribution | Regulators usually look through labels and assess who actually controls onboarding, fees, interfaces and service delivery. |
Token classification drives the legal path. A founder cannot decide the regulatory category by branding alone. Under MiCA, the main distinction is between other crypto-assets often discussed in the market as utility-type tokens, asset-referenced tokens (ARTs) and e-money tokens (EMTs). That distinction affects whether a white paper is needed, whether a separate issuer authorisation logic applies and whether banking or e-money law becomes relevant.
The most expensive classification error is treating a payment-oriented token as a generic utility token. Supervisors and counterparties will look at stabilisation mechanisms, redemption expectations, reserve structure, reference assets, rights attached to the token and actual user messaging. Economic function matters more than marketing language.
| Category | Core Feature | Typical Trigger |
|---|---|---|
| Other crypto-assets / utility-type crypto-assets | Typically provide access, utility or ecosystem functionality and do not aim to maintain value by reference to official currencies or baskets of assets. | White paper and conduct analysis may apply depending on offering structure, admission to trading and exemptions. |
| Asset-referenced tokens (ARTs) | Seek to maintain stable value by referencing another value, right or combination of values, including multiple official currencies or other assets. | Stricter issuer regime and supervisory expectations; cannot be analysed as a standard utility token. |
| E-money tokens (EMTs) | Purport to maintain stable value by referencing the value of one official currency. | Closer interface with e-money logic and stricter issuer requirements; frequently requires a separate regulated analysis beyond standard CASP services. |
| Excluded or separately regulated instruments | Some instruments may fall outside MiCA or into other EU financial services regimes depending on their legal and economic features. | Requires separate legal qualification before any Lithuania market-entry decision is made. |
Yes: Analyse as a potential EMT and assess the separate issuer regime.
No: Move to the next classification question.
Yes: Analyse as a potential ART with stricter issuer implications.
No: Move to the next classification question.
Yes: Analyse as another crypto-asset and assess white paper, marketing and trading-admission obligations.
No: Check whether the instrument may fall into another financial regulatory regime or outside MiCA.
Yes: Disclosure and offering analysis becomes central regardless of the project’s marketing narrative.
No: Private or limited structures still require careful perimeter review; absence of a public offer does not eliminate all obligations.
The transition story matters because many public materials still mix old and new regimes. Lithuania had an established crypto business narrative before MiCA, but 2026 analysis must start from the current EU framework. Legacy references can still matter for understanding historical registrations, remediation projects and group restructurings, but they should not be used as a substitute for current CASP authorisation analysis.
For practical planning, the transition question is now mostly a remediation and legacy-operations issue. New entrants should focus on the current authorisation perimeter, while existing groups should confirm whether any old structures, policies, contracts or customer terms still rely on pre-MiCA assumptions.
Useful for historical context, but insufficient for 2026 licensing and cross-border planning.
Businesses had to re-map service scope, governance, capital and passporting assumptions.
Founders should review old AML manuals, customer terms, outsourcing maps and token documents for MiCA/TFR alignment.
A legacy registration or historical market presence does not automatically answer the 2026 authorisation question. RUE generally treats old VASP-era documentation as background material only. The operative review should test the current service scope, customer journey, wallet logic, transfer flows, governance, outsourcing and target markets against the live MiCA and AML framework.
The licensing process is a structured supervisory exercise. In practice, the fastest files are not the shortest ones, but the ones where business model, governance, AML, ICT and financial assumptions are internally consistent.
Set up the Lithuanian legal entity, usually a UAB, establish the registered office, map group ownership, disclose beneficial owners and define who will actually manage regulated operations. Incorporation is only the corporate shell; it does not authorise crypto services. A recurring weak point is using a nominal structure without clear management accountability, local contact capacity or documented control over outsourced functions.
Translate the business model into MiCA service categories. This is where many teams lose time by using commercial labels such as “broker”, “exchange” or “wallet” without legal mapping. The application should show which services are requested, what customer journey triggers each service and which prudential threshold applies.
Prepare the business plan, financial projections, governance framework, AML/CFT manual, risk methodology, complaints handling process, outsourcing oversight, ICT/security controls, conflict management and fit-and-proper materials for managers and key shareholders. A strong file explains not only what the policy says, but how the control works in operations.
After submission, the authority reviews completeness and then engages with the applicant on substance. Questions often focus on source of funds, target markets, safeguarding logic, outsourcing dependencies, transaction monitoring, sanctions controls and the realism of projected volumes. The quality of responses matters as much as the initial filing.
Authorisation is not the end of the project. Before launch, the company should finalise vendor onboarding, Travel Rule integrations, customer agreements, incident escalation, record retention, board reporting and market-entry notifications for other EU states where relevant. Teams that postpone this work often create avoidable post-approval delays.
The file should read like one operating model, not like disconnected policy appendices.
| Document | Purpose | Owner |
|---|---|---|
| Detailed business plan | Explains the business model, target markets, service scope, customer journey, revenue logic and operating assumptions. | Founders / legal / compliance |
| Financial projections and capital evidence | Shows prudential readiness, sustainability assumptions and the relationship between projected volumes and control infrastructure. | Finance / founders |
| AML/CFT policy set | Documents CDD, EDD, sanctions, transaction monitoring, suspicious activity escalation, record retention and internal governance. | MLRO / compliance |
| Governance and fit-and-proper file | Supports the suitability, experience and reputation of managers, key function holders and relevant owners. | Legal / HR / founders |
| ICT and security framework | Explains access controls, wallet/key governance, incident handling, logging, resilience and vendor dependencies. | CTO / security / compliance |
| Outsourcing and third-party oversight pack | Shows which critical functions are outsourced, how vendors are selected, monitored and audited, and how concentration risk is managed. | Operations / legal / compliance |
| Complaints handling and client disclosure materials | Demonstrates customer-facing governance, escalation routes and transparency of service terms. | Legal / operations |
| Corporate and UBO documents | Confirms ownership, control chain, incorporation status and beneficial ownership disclosures. | Corporate secretary / legal |
The real cost of a Lithuanian crypto launch is a stack, not a filing fee. Founders should separate one-off setup costs from recurring compliance costs. The one-off layer usually includes incorporation, legal drafting, policy architecture, application preparation, fit-and-proper pack assembly and initial vendor setup. The recurring layer usually includes AML tooling, sanctions screening, blockchain analytics, compliance staffing, accounting, audit support, legal maintenance and periodic remediation.
The hidden cost driver is usually not capital but operating discipline. Teams often budget for company formation and legal drafting, but under-budget for transaction monitoring, Travel Rule integrations, board-level reporting, vendor due diligence, penetration testing, incident handling and multilingual customer support where cross-border activity is planned.
| Cost Bucket | Low Estimate | High Estimate | What Drives Cost |
|---|---|---|---|
| Entity setup and corporate formation | Variable | Variable | Depends on shareholding complexity, foreign documents, apostille/legalisation needs and beneficial ownership structure. |
| Legal structuring and application drafting | Variable | Variable | Cost depends on whether the file covers one service line or a multi-service model with custody, exchange, transfer and cross-border rollout. |
| AML/KYC and sanctions tooling | Variable monthly | Variable monthly | Usually includes identity verification, sanctions/PEP screening, transaction monitoring and case management. Volume-based pricing is common. |
| Blockchain analytics and Travel Rule stack | Variable monthly | Variable monthly | Often overlooked in early budgets. Cost depends on transfer volume, counterpart network coverage and workflow complexity. |
| Compliance staffing and MLRO function | Variable monthly | Variable monthly | Depends on whether the function is in-house, hybrid or supported externally, and on the risk profile of the customer base. |
| Accounting, tax and audit support | Variable recurring | Variable recurring | Crypto bookkeeping, wallet reconciliations, token accounting and cross-border revenue mapping can materially increase cost. |
| Security, penetration testing and resilience controls | Variable recurring | Variable recurring | Especially relevant for custodial, exchange and API-heavy models where wallet, access and incident governance are core supervisory concerns. |
The most common budgeting mistake is assuming that a Lithuanian CASP project is mainly about incorporation plus a licence application. In reality, the larger cost often sits in recurring controls: Travel Rule interoperability, sanctions handling, blockchain analytics, outsourced KYC oversight, policy maintenance, staff training and remediation after the first audit or supervisory review.
AML in Lithuania is an operating system, not a policy binder. A crypto business must be able to identify customers, understand beneficial ownership, assess source of funds and source of wealth where relevant, screen against sanctions and PEP lists, monitor transactions, escalate unusual activity and retain records for the applicable statutory period. For crypto businesses, this must be connected to wallet logic, blockchain analytics and transfer workflows rather than handled as a generic financial-services template.
The Travel Rule is the most under-estimated operational requirement. Where the TFR applies, the business must be able to collect, verify where required, transmit and retain originator and beneficiary information connected to crypto transfers. This means legal, product and engineering teams must work together. If the product architecture cannot support compliant data exchange, the AML framework is incomplete even if the written policy looks strong.
A practical 2026 nuance is the treatment of self-hosted wallets. Firms should not rely on outdated threshold folklore or vendor marketing summaries. The correct approach is to map when verification, risk-based review, ownership/control checks and enhanced monitoring are triggered under the applicable EU and Lithuanian framework, and then document those triggers in the transfer workflow.
| Workflow Step | Control | Owner |
|---|---|---|
| Onboarding | Collect identity, beneficial ownership and business-profile information; screen for sanctions and PEP exposure; assign initial risk score. | Compliance / onboarding operations |
| Wallet and address assessment | Link customer profile to wallet usage, supported assets, expected transaction behavior and blockchain risk indicators. | Compliance / blockchain monitoring team |
| Transaction monitoring | Review transfers against behavioral thresholds, typologies, sanctions exposure, mixer/high-risk indicators and deviations from expected activity. | AML operations |
| Travel Rule handling | Capture and exchange originator and beneficiary data for covered transfers using auditable workflows and vendor/interoperability controls. | Compliance / product / engineering |
| Escalation and reporting | Investigate alerts, document rationale, freeze or restrict activity where required, and escalate suspicious activity through the proper internal and external channels. | MLRO / FCIS reporting function |
| Retention and review | Retain records, review customer risk periodically, refresh KYC and test the effectiveness of controls and vendor outputs. | Compliance / internal control |
Yes, but only through the proper passporting route. A Lithuanian CASP can generally provide authorised services in other EU member states once the relevant notification process is completed through the competent authority. This is the real strategic advantage of a compliant Lithuania setup: not “automatic Europe”, but legally structured access to the EU single market for the authorised service scope.
The practical constraint is scope discipline. Passporting does not cure an under-scoped authorisation, and it does not eliminate local consumer, marketing, tax or language issues. If the business plans to market actively in several member states, customer terms, disclosures, complaints handling, sanctions logic and support operations should be designed for cross-border use from the start.
Reverse solicitation should be treated as a narrow exception, not a distribution model. If the business targets EU clients through marketing, local-language funnels, affiliate campaigns, onboarding flows or sales outreach, it is usually difficult to defend a pure reverse-solicitation position. RUE generally advises clients to build the cross-border plan around authorised services and proper notifications rather than around exception-based arguments.
The highest-risk failures are perimeter mistakes, AML failures and misleading cross-border assumptions. In practice, enforcement exposure usually starts before any formal sanction: bank account friction, payment-provider termination, investor due diligence failure, inability to onboard institutional counterparties and repeated supervisory questions are often the first warning signs.
For founders, the strategic point is that enforcement risk is cumulative. A weak source-of-funds file, poor sanctions controls, unclear outsourcing governance and aggressive marketing into other EU states may each look manageable in isolation. Together, they create a pattern that regulators and counterparties interpret as weak control culture.
Legal risk: Exposure to supervisory action, cease-and-desist measures, contractual disruption, banking friction, fines and reputational damage.
Mitigation: Complete a perimeter analysis before launch and document why each service is in or out of scope.
Legal risk: Misalignment between actual operations and current authorisation expectations; remediation risk and possible interruption of growth plans.
Mitigation: Re-paper the business model, policies, customer terms and control framework against the 2026 MiCA/TFR baseline.
Legal risk: AML enforcement exposure, suspicious activity handling failures, onboarding restrictions and serious reputational consequences.
Mitigation: Implement risk-based CDD, quality transaction monitoring, sanctions controls and tested escalation procedures.
Legal risk: Operational non-compliance, transfer friction, audit findings and supervisory remediation pressure.
Mitigation: Select interoperable tooling, test data exchange paths and define fallback procedures for failed or incomplete transfer data.
Legal risk: Control failure even where the vendor is competent, because accountability remains with the regulated entity.
Mitigation: Maintain an outsourcing register, due diligence files, SLAs, audit rights and board-level vendor review.
Legal risk: Unauthorised market-entry allegations, consumer-law friction and supervisory scrutiny in multiple jurisdictions.
Mitigation: Sequence marketing, onboarding and country rollout only after the relevant notification path is confirmed.
Lithuanian tax analysis for crypto companies should start with the revenue type, not with the word “crypto”. The baseline corporate income tax rate commonly referenced for Lithuanian companies is 15%, but the actual tax position depends on the legal entity, income profile, deductible costs, transfer pricing, group structure and whether any special regime applies. VAT treatment is more nuanced and depends on the nature of the service. Founders should avoid blanket statements such as “crypto is VAT-free” or “crypto is not taxed in Lithuania”.
The accounting layer is often harder than the headline tax rate. Crypto businesses need defensible treatment of trading fees, spreads, custody revenue, token-related income, treasury positions, staking-related flows where relevant, wallet reconciliations and fair-value or inventory questions under the applicable accounting framework. Tax risk often arises from poor records rather than from the rate itself.
| Topic | Why It Matters | Responsible Team |
|---|---|---|
| Corporate income tax | The commonly cited baseline rate is 15%, but the real tax burden depends on profit calculation, deductible expenses, transfer pricing and group structure. | Finance / tax |
| VAT treatment of services | VAT analysis depends on the exact service supplied. Exchange-type services and ancillary technology or consulting services may not follow the same treatment. | Tax / legal / finance |
| Withholding tax and distributions | Cross-border payments, dividends and group flows may trigger withholding tax analysis and treaty review. | Tax / corporate |
| Bookkeeping and wallet reconciliation | Accurate ledgers, wallet mapping and transaction-level records are essential for both tax reporting and audit defence. | Accounting / operations |
| Token-related income recognition | Issuance proceeds, treasury holdings, fee income and token-based compensation can create complex accounting and tax questions. | Finance / legal / external tax advisers |
| Cross-border reporting footprint | Serving clients across the EU can create additional VAT, permanent establishment, consumer-tax or reporting questions depending on the operating model. | Tax / legal / finance |
First 90 days before filing or launch
These items define perimeter clarity, application readiness, and first-line control credibility.
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 a Lithuania CASP rollout.
The main 2026 analysis should be framed around CASP authorisation under MiCA, not around a standalone VASP label. “VASP” may still appear in historical or AML-context discussions, but for new regulated crypto-asset services the operative question is whether the business falls within the MiCA service perimeter and what authorisation scope is required.
VASP is mainly a legacy or AML-context term, while CASP is the MiCA-era EU legal category. A CASP is a crypto-asset service provider authorised for specific services under MiCA. The difference matters because MiCA adds a fuller framework around prudential requirements, conduct, governance, complaints handling and EU passporting.
The Bank of Lithuania is the key authority for CASP authorisation and supervision, while FCIS / FNTT is central for AML/CFT enforcement. In addition, Registrų centras matters for company records and VMI for tax. In practice, a crypto business must satisfy all of these layers, not just the licensing authority.
The commonly referenced MiCA capital thresholds are €50,000, €125,000 and €150,000. The correct threshold depends on the exact authorised services and prudential class. Founders should avoid generic claims such as “one capital amount fits all crypto licences” because the final mapping depends on service scope.
A realistic planning range is often 3–6 months end-to-end for a well-prepared project. Incorporation may be relatively quick, but drafting, internal alignment, completeness review and supervisory questions take time. After a complete file, the formal review stage can run to about 65 working days, with practical timing depending on the quality of the submission.
Yes, passporting is one of the main strategic advantages of an EU-authorised CASP. However, passporting is not automatic in the casual sense. The company must follow the relevant notification process and can only passport the services that are actually within its authorised scope.
A registered office is part of the corporate baseline, but the real issue is operational substance. Supervisors look beyond the address and assess whether the Lithuanian entity has credible governance, management accountability and control over regulated operations. A minimal shell structure is usually a weak foundation for a serious CASP application.
MiCA covers more than CASP services; it also includes disclosure and issuer rules for certain crypto-assets. But token issuance is not the same as CASP authorisation. Utility-type crypto-assets, ARTs and EMTs follow different legal paths, and some projects may trigger a separate issuer analysis even if they also plan to operate a service business.
The Travel Rule adds mandatory transfer-data obligations on top of MiCA. For covered crypto transfers, a firm must be able to collect, transmit and retain originator and beneficiary information in a compliant workflow. In practice, this affects onboarding design, wallet handling, vendor selection, data protection and the engineering roadmap.
FCIS / FNTT is the key AML/CFT enforcement authority to monitor in the Lithuanian crypto context. That said, AML readiness is also relevant to the authorisation process itself because weak AML architecture can undermine the credibility of the entire CASP application before the business even launches.
Yes, crypto companies in Lithuania are not outside the tax system. The commonly referenced baseline corporate income tax rate is 15%, while VAT treatment depends on the exact service supplied. The correct analysis requires a review of revenue streams, accounting treatment, wallet records and cross-border flows.
The business can face supervisory action, banking disruption, enforcement exposure and serious reputational damage. The practical fallout often starts with failed due diligence, payment-provider offboarding and investor concern before any formal penalty is imposed. The safest approach is to complete a perimeter review before launch and document the basis for the chosen structure.
RUE helps founders, legal teams and compliance leads map business models to the Lithuanian and EU crypto regulatory perimeter, prepare MiCA-era applications and fix weak points in AML, Travel Rule, governance and cross-border rollout strategy.
