VASP and CASP are related terms, but they come from different rule systems. VASP is widely associated with the Financial Action Task Force’s anti-money-laundering and counter-terrorist-financing standards for virtual-asset service providers. CASP is the term used by the European Union’s Markets in Crypto-Assets Regulation for a crypto-asset service provider. A business can encounter both concepts, along with separate rules for funds transfers, sanctions, data protection, consumer protection, and financial instruments. Replacing one acronym with the other can hide material differences in scope and obligations.
The correct approach is to map services and assets against each applicable framework. This guide explains how to build that map, with particular attention to decentralized products and interfaces. It does not provide a licensing conclusion or a complete account of MiCA, related technical standards, national competent authority practice, or other EU financial law. Teams should use the official legal text and obtain qualified EU advice for a specific product and launch plan.
Understand the source and purpose of each term
The VASP concept is part of an international standard-setting framework focused on money laundering, terrorist financing, and proliferation-financing risk. Countries implement those standards through their own laws, so local definitions and requirements can vary. MiCA is a directly applicable EU regulation establishing a framework for crypto-assets and related services that are not already governed by certain existing financial-services rules. Its CASP provisions address authorization, organization, conduct, prudential safeguards, client protection, and service-specific duties.
Because the purposes differ, the categories should not be treated as identical. A service can raise AML/CFT questions even when another product-perimeter analysis is unresolved. Conversely, a MiCA authorization question may involve organizational and conduct requirements beyond the VASP shorthand. Build separate columns for each regime and show how they interact. Do not use an AML registration analysis as proof of MiCA authorization or assume that a MiCA category answers every national AML question.
Create an asset-classification gate
Before mapping services, identify the asset. Determine whether it is a crypto-asset within MiCA, an asset-referenced token, an e-money token, or potentially outside MiCA because another EU financial-services framework applies. Unique and non-fungible characteristics require substance-based analysis rather than reliance on an NFT label. Token design, rights, redemption, transferability, use, and how the asset is offered can affect classification. The responsible issuer or service provider should preserve the evidence and reasoning behind the classification.
A product that supports many assets needs a repeatable review process. Define required documentation, legal sign-off, technical verification, change monitoring, and delisting or restriction criteria. Assets can evolve through governance, wrappers, bridges, redemption changes, or market use. A token approved under one set of facts should not remain indefinitely approved when those facts change. The asset gate should feed marketing, disclosures, service permissions, and jurisdictional availability.
Map each crypto-asset service separately
Do not classify the company as a single service. List custody and administration, operation of a trading platform, exchange for funds, exchange for other crypto-assets, execution of orders, placing, reception and transmission of orders, advice, portfolio management, and transfer services where relevant. Then map every product feature to those categories. An application can combine several services, and a white-label or API channel can differ from the retail interface.
For decentralized products, examine who provides the interface, routes orders, selects liquidity, controls upgrades, receives fees, and maintains the client relationship. A smart contract may be one component of a service delivered through an organized business. Alternatively, an autonomous protocol may lack an identifiable service provider for a particular layer while an interface operator has a separate role. Record facts and uncertainty rather than announcing that “DeFi is exempt.” The legal analysis must apply the regulation and related guidance to the actual arrangement.
Distinguish authorization from AML obligations
CASP authorization and AML/CFT compliance are connected but not interchangeable. An authorized service provider must still implement applicable customer due diligence, monitoring, recordkeeping, reporting, sanctions, and transfer-information controls. The EU transfer-of-funds framework for certain crypto-asset transfers adds another operational layer. Build a regulatory architecture that assigns owners to authorization conditions, prudential requirements, safeguarding, conduct, complaints, outsourcing, ICT risk, market-abuse controls, and AML/CFT obligations.
A control should identify the rule it serves. Customer identity can support AML/CFT, suitability, complaints, and fraud controls, but each use has its own legal basis, quality, and retention requirements. Avoid one vague “compliance” system that cannot prove which decisions were made under which rule. Data governance should manage reuse, access, and retention. Regulatory reporting and supervisory requests should be traceable to validated source data.
Account for location and cross-border service
Map the legal entities providing each service, their establishment, personnel, outsourcing, and clients. Determine which entity contracts with the client and controls the relevant systems. Marketing, language, local partnerships, support, and active solicitation can be relevant to cross-border analysis. A website’s global availability does not eliminate the need for a deliberate market-access strategy, and a geofence alone may not resolve active offering or operational nexus.
Create a country rollout matrix with legal basis, entity, services, assets, client types, required disclosures, limits, and control dependencies. Link product configuration to the matrix so unsupported combinations cannot be activated through a marketing or engineering change. Monitor reverse-solicitation or equivalent assumptions carefully and do not use them as a default business model without advice. Preserve launch approvals and the facts on which they depend.
Build authorization evidence into operations
Authorization is not only an application project. Policies, governance, capital or safeguards, outsourcing oversight, security, continuity, conflicts, complaints, custody arrangements, client-asset protections, and service-specific procedures must operate after launch. Map every commitment made in an application to a control owner and evidence source. Product changes should be assessed for whether notifications, approvals, or updated documentation are needed.
Management information should show service volumes, incidents, complaints, outsourcing performance, safeguarding, client-asset reconciliation, breaches, and remediation. The board or governing body needs clear accountability and sufficient expertise. For decentralized arrangements, evidence should explain how smart-contract risk, admin permissions, governance dependencies, and immutable transactions are managed. Do not present automation as eliminating operational responsibility when the CASP maintains the service relationship.
Use a two-axis comparison, not an acronym swap
The practical comparison has two axes. The first asks whether the activity and participants fall within relevant AML/CFT virtual-asset provider rules as implemented locally. The second asks whether the asset and service fall within MiCA or another EU financial-services framework, and which entity needs authorization. Additional axes cover transfer information, sanctions, data protection, operational resilience, and national law. A conclusion on one axis should state whether the others remain open.
Keep the map versioned by product, asset, entity, and country. New technical standards, supervisory guidance, or product facts can change implementation. The authoritative starting point for the EU axis is the official text of Regulation (EU) 2023/1114, including its definitions and crypto-asset service provisions:
Keep terminology precise in public materials
Websites, white papers, partner decks, and terms should use regulatory language carefully. Saying that a company is “a VASP” or “MiCA compliant” can imply a status broader than the actual registration, authorization, service, entity, or territory. Maintain approved descriptions that name the entity, competent authority where appropriate, services, and geographic scope. Review marketing when an authorization changes or a new product is added. Precision protects users and prevents commercial language from outrunning the legal and operational perimeter.
Conclusion
VASP and CASP should be treated as different analytical lenses. One comes from an international AML/CFT standard implemented through national law; the other is defined by an EU crypto-asset market framework with authorization and conduct requirements. Their overlap is important, but it is not complete.
A service-by-service, asset-by-asset, entity-by-entity map is more reliable than choosing the acronym that sounds closest to the product. Tie the map to country rollout, product configuration, control ownership, and change management so the analysis remains true after launch.