Crypto License in Lithuania 2026

VASP vs CASP in Lithuania: terminology, legal status, and why Google results are confusing

VASP is a legacy AML term; CASP is the operative MiCA authorization term. The acronym VASP comes largely from the FATF vocabulary for virtual asset service providers. It remains relevant in AML discussions, especially when talking about Travel Rule messaging and virtual asset transfer risk. However, in the EU licensing context for 2026, the legally precise term is CASP.

This distinction matters because many older pages still market a vasp license lithuania as if it were the current route. That framing is outdated. A founder who wants to launch exchange, custody, brokerage, transfer, or platform operations should assess whether the business falls within MiCA service categories and, if yes, prepare for a casp license lithuania application.

There is also a strategic nuance: a company may still use VASP language internally for AML taxonomy, vendor mapping, or Travel Rule interoperability, while using CASP terminology in licensing documents and regulator communication. Mixing the two without explanation is one of the most common drafting mistakes we see in inherited application files.

Which regulator is responsible: Bank of Lithuania, FCIS/FNTT, or the Centre of Registers?

The Bank of Lithuania authorizes; FCIS/FNTT oversees AML/CFT functions; the Centre of Registers handles company registration. These roles are complementary, not interchangeable.

• Bank of Lithuania: national competent authority for MiCA authorization, prudential review, governance, conduct, safeguarding, and ongoing supervisory interaction;
• FCIS/FNTT: anti-money laundering and financial crime authority involved in suspicious transaction reporting, AML/CFT supervision, and enforcement functions;
• Centre of Registers: incorporation, registry entries, and corporate record administration;
• VMI: tax administration, VAT, corporate tax, and reporting matters.

From an execution standpoint, this means your crypto license in Lithuania file should be regulator-facing, your AML file should be FCIS-ready, and your corporate file should be registry-clean. Treating these as one undifferentiated document pack usually causes delays.

Class 1 CASP

Class 1 generally fits lower-complexity advisory and order-routing models. The starting capital threshold is €50,000. This class may suit firms focused on crypto-asset advice, portfolio management, or reception and transmission of client orders without taking custody of client assets. Even here, the regulator still expects governance, conflicts management, AML controls, and a credible operating model.

Class 2 CASP

Class 2 is the most commercially relevant category for many founders. The capital threshold is typically €125,000, and the category covers more operationally sensitive services such as custody, exchange, transfer, execution, or placing. If you are pursuing a lithuania crypto exchange license or custody-enabled model, Class 2 analysis is often where the project lands. The key burden here is safeguarding: segregation, reconciliation, wallet governance, and incident handling must be documented in detail.

Class 3 CASP

Class 3 applies to operation of a trading platform and carries the highest complexity. The minimum capital is generally €150,000. Platform operators should expect deeper scrutiny on order handling, fair access, market abuse controls, surveillance logic, conflicts between house and client activity, and resilience of the matching or execution environment. In practice, this is where many underprepared applicants discover that a platform is a regulated market infrastructure project, not just a website with an order book.

AML, KYC, sanctions, and Travel Rule compliance are central to a Lithuania CASP project

A Lithuanian crypto business must build an operational AML stack, not just an AML policy. The minimum viable framework includes customer identification, beneficial ownership verification, sanctions and PEP screening, wallet screening, transaction monitoring, enhanced due diligence, escalation, suspicious transaction reporting, and periodic review. For many business models, the real implementation challenge is not KYC collection but event-driven monitoring after onboarding.

Your AML framework should include at least the following control layers:

• business-wide ML/TF risk assessment by product, geography, client type, and delivery channel;
• KYC/KYB onboarding with documentary and non-documentary verification;
• sanctions screening against EU and other relevant lists;
• blockchain analytics and wallet exposure scoring;
• transaction monitoring scenarios and investigator workflow;
• STR/SAR escalation to FCIS/FNTT;
• staff training and second-line oversight;
• record retention and evidentiary audit trail.

Travel Rule and transfer compliance for crypto businesses

The Travel Rule is now an operational requirement for in-scope crypto transfers in the EU. Under the recast Transfer of Funds Regulation, CASPs involved in transfers must collect and transmit originator and beneficiary data. This is not optional middleware; it affects onboarding, transfer routing, counterparty due diligence, and exception handling.

In practice, firms often implement Travel Rule workflows using vendor networks and data standards such as IVMS101. A mature setup should define: when a transfer is in scope, how counterparty VASP/CASP status is verified, how missing data is handled, what happens with unhosted wallets, and how sanctions or fraud alerts interrupt the payment flow. This is one of the clearest gaps we see in first-draft applications prepared without crypto-native compliance support.

For related structuring and document support, see Preparation of compliance documents for MiCA application and MLRO services in Lithuania.

Most delays come from weak structuring, not from the filing form itself

The most common reason a Lithuania crypto license project slows down is inconsistency between documents. Applicants often submit a polished business plan, but the AML risk assessment, governance matrix, financial model, and technical annex describe a different business. Regulators spot that immediately.

Documentation mistakes that delay approval

• generic business plans that do not explain the actual customer journey or transaction flow;
• AML manuals copied from unrelated sectors, with no wallet screening or Travel Rule logic;
• unclear ownership chains or weak source-of-funds evidence;
• missing explanation of how client assets are segregated and reconciled;
• no operational detail on outsourcing, complaint handling, or incident escalation.

Banking and substance mistakes

• starting bank or EMI onboarding too late;
• using a purely nominal office or governance setup;
• appointing directors or AML officers with insufficient time commitment;
• assuming foreign ownership removes the need for local substance and control evidence.

A technical mistake we see surprisingly often is using crypto-native language that is accurate for product teams but unusable for regulators. Phrases like “non-custodial-ish flow” or “semi-decentralized routing” may describe architecture informally, but they do not answer legal questions about control, intermediation, or responsibility. RUE rewrites these sections into regulator-grade language without losing technical accuracy.