VASP and CASP explained: What determines how your app is regulated

The number of licensed crypto-asset service providers in the EU grew 2.5x between 2022 and 2024, reaching 2,525 by year-end, and the European Banking Authority found that many of them lacked effective compliance systems.

Most teams building applications that handle crypto don't think about regulatory compliance until a regulator asks, or until an enterprise customer's legal team does. But, by then, the wallet architecture underpinning the product is already set. Changing it is expensive, sometimes impossible without a rebuild.

Whether your application qualifies as a Virtual Asset Service Provider (VASP), or within the EU, a Crypto-Asset Service Provider (CASP), determines what licenses you need, what data you must collect, and how the wallet infrastructure your product depends on has to be designed. 

This article explains VASP and CASP, what they require, and what they mean for the infrastructure choices your team is making right now. It also highlights how Turnkey’s infrastructure can help you design for compliance from the start.

What is VASP?

VASP stands for Virtual Asset Service Provider. The term was defined and standardised by the Financial Action Task Force (FATF), the international body that sets global standards for anti-money laundering (AML) and counter-terrorism financing (CFT).

Under FATF’s framework, any individual or entity that performs one or more of the following activities on behalf of another person qualifies as a VASP:

• Exchanging virtual assets for fiat currencies
  
  
• Exchanging one virtual asset for another
  
  
• Transferring virtual assets on behalf of another person
  
  
• Safeguarding or administering virtual assets, or instruments that enable control over them
  
  
• Participating in the issuance or sale of a virtual asset

FATF doesn't regulate companies directly. It sets standards, and individual countries implement those standards through national law. That's why onboarding flows and withdrawal requirements vary by exchange, but the underlying VASP obligations are consistent even though implementation differs.

The key phrase in the FATF definition is “on behalf of.” That’s what separates a VASP from a team that is simply writing software.

If your application holds or moves assets for users, it is likely in scope. If your application only provides an interface and users retain full control of their keys, it may fall outside that definition.

What is CASP, and how does it differ from VASP?

CASP stands for Crypto-Asset Service Provider. It's the EU's version of VASP, introduced under the Markets in Crypto-Assets Regulation (MiCA). MiCA became fully applicable on December 30, 2024.

The functional scope is similar to VASP. CASPs include custody and administration of crypto assets, operation of trading platforms, exchange of crypto-assets for fiat or other crypto-assets, execution of orders, reception and transmission of orders, portfolio management, and investment advice on crypto-assets. 

But CASP authorization under MiCA is materially stricter than most prior national VASP regimes in Europe. It requires formal authorization by a National Competent Authority (NCA), demonstrated governance structure, minimum capital reserves, technical security standards, and compliance with the EU's Digital Operational Resilience Act (DORA).

The competitive upside is significant. Authorization in one EU member state grants passporting rights across all 27. A CASP licensed in Luxembourg can legally serve customers in Germany, France, the Netherlands, and everywhere else in the bloc under a single authorization.

The VASP-to-CASP transition in practice

For companies that were already operating under national VASP regimes in EU member states before MiCA took effect, there is a transitional period. Existing providers can continue operating under their national registrations until as late as July 2026, provided they apply for CASP authorization before their member state's deadline.

In practice, the transition is slow. National competent authorities are processing CASP applications at 30 to 50 percent longer timelines than initially estimated, according to research from Hacken, with application volumes well above original projections. 

For builders entering EU markets now, the operational implication is clear: plan for the CASP framework from day one. There is no meaningful path to operating in Europe at scale without it.

Which wallet models trigger VASP and CASP status

Wallet architecture is one of the primary factors in regulatory classification. There are two core custody models that VASP addresses:

Custodial wallets are almost universally classified as VASPs. The provider holds private keys on behalf of users, and assets move at the provider’s direction. Full VASP obligations apply, including KYC, AML programs, transaction monitoring, and in many jurisdictions, formal registration or licensing.

Non-custodial wallets give users full control over their own private keys. The provider supplies the interface but never controls the assets. Direct VASP obligations are generally reduced. But this does not mean the compliance surface is zero. Adding a fiat on-ramp, executing transfers between parties, or retaining any meaningful control over signing can still create regulatory exposure.

An embedded wallet can be either custodial or non-custodial depending on how key management is implemented. Some providers position hybrid models as non-custodial, but under regulatory scrutiny this distinction might not hold.

If the provider retains any portion of key control, through key shards, server-side encryption, or threshold signing where the provider is a required participant, regulators may treat the arrangement as custodial or within scope of VASP/CASP obligations. The closer a provider is to having no participation in the signing process, the stronger the case for a non-custodial classification under the functional test regulators apply.
‍

Core compliance obligations that affect wallet architecture

Four obligations under VASP and CASP frameworks have direct implications for how wallet systems must be designed and operated.

Asset segregation
Client funds must be separated from company assets at both the wallet and accounting level. This requires isolated wallets per user or account, clear audit trails, and no pooled or shared signing environments.

The Travel Rule
VASPs and CASPs must collect and transmit sender and recipient data with transfers. In the EU, this applies to all transactions with no minimum threshold. Systems must support data collection, verification (for unhosted wallets), and integration with protocols like TRUST or TRP.

DORA (operational resilience)
CASPs must meet strict IT risk, uptime, and incident reporting requirements. Infrastructure must support high reliability, documented controls, and auditable incident response processes.

KYC, AML, and transaction monitoring
Wallet systems must link verified identities to addresses, support sanctions screening, and provide transaction data for monitoring. Missing these capabilities creates costly compliance gaps later.

This is where wallet architecture and compliance stack intersect most directly. Wallet systems that don't expose the right data fields, including user identity, wallet address provenance, and transaction metadata, are creating gaps that are expensive to retrofit later.

How Turnkey helps applications meet VASP and CASP requirements

The wallet provider you choose and how you integrate it determines your regulatory surface as your product scales. With Turnkey, application builders can choose from purely non-custodial, to a more managed model depending on their use case.

Turnkey offers several advantages when it comes to complying with VASP and CASP: 

Asset segregation. Turnkey provisions each user wallet inside its own sub-organization: a cryptographically isolated environment with its own wallets, authenticators, and policies.

The parent organization has read-only visibility into sub-organizations but no write access. This means your application's signing keys and your users' keys are structurally separated, not just logically separated. Each sub-organization can map to a single user, producing the per-user wallet isolation that CASP asset segregation requirements demand.

Non-custodial key management. Turnkey's secure enclave architecture means raw private keys are never exposed to Turnkey, to your application, or to your team.

All key generation, signing, and policy evaluation happens inside Trusted Execution Environments (TEEs) with no persistent storage, no external networking, and cryptographic attestation proving only authorized code is running.

This is what makes a non-custodial classification defensible: the infrastructure provider cannot unilaterally access or move user assets.

Policy engine for transaction controls. Every action in Turnkey passes through the policy engine before it executes. Policies are explicitly allow or deny, with no implicit permissions. You can restrict signing by destination address, transaction value, contract method, asset type, or a combination of all of the above. 

You can require multi-party approval for high-value transfers, enforce quorum-based consensus for sensitive operations, and scope individual service accounts to specific wallets. These are the governance controls that VASP and CASP frameworks require for transaction monitoring and authorization workflows.

Audit trails for compliance reporting. Turnkey logs every activity with timestamps, credential identifiers, approver records, and resource IDs. The production checklist outlines the logging pattern: activity IDs, status, creation date, credential IDs of approvers, and all relevant resource identifiers. This is the data trail that DORA incident reporting, CASP authorization audits, and KYC identity binding requirements depend on.

Taken together, these capabilities mean applications built on Turnkey can meet VASP and CASP compliance requirements at the infrastructure level, rather than retrofitting controls on top of a system not designed for them. 

Designing Wallet Infrastructure for Compliance with Turnkey

VASP and CASP classification is not determined by what your product is called but by how it actually operates. The key question regulators ask is simple: who controls the keys, and who participates in moving funds.

If your application participates in signing, enforces transaction approval, or retains any form of key dependency, your regulatory surface expands accordingly.

Designing for user-controlled key management, clear asset segregation, and verifiable system behavior are key factors in determining whether your product can scale across jurisdictions without constant rework.

Turnkey provides the primitives to make these decisions explicit. You can support fully user-controlled wallets, or introduce structured, policy-driven workflows where your application plays a role in transaction approval. The difference is transparent, configurable, and aligned with how regulators evaluate control in practice.

Addressing these requirements at the design stage is always easier than retrofitting them after launch … or after a regulator asks.

Start building with Turnkey. 

‍

^{Note: The regulatory frameworks discussed in this article, including those relating to Virtual Asset Service Providers (VASPs) and Crypto-Asset Service Providers (CASPs), are based on publicly available information as of the date of first publication of this article. Regulatory requirements in this area are evolving rapidly, and the information presented may not reflect the current state of the law in any jurisdiction.}

^{This article is published by Turnkey Global, Inc. (“Turnkey”) for general informational purposes only and does not constitute legal, regulatory, compliance, tax, or financial advice. Nothing in this article should be relied upon as a substitute for independent due diligence or consultation with qualified legal counsel regarding your specific circumstances. No attorney-client or advisory relationship is created by reading or relying on this content.}

^{Your use of this article is subject to Turnkey’s Terms of Service (turnkey.com/legal/terms) and Privacy Policy (turnkey.com/legal/privacy). Turnkey assumes no liability for actions taken or not taken based on the content of this article.}

‍