CASP Functional Test

What is the CASP functional test standard, and how does it differ from the common assumption of "looking at what the service calls itself"?

Most people's first intuition when encountering the CASP regulatory concept is to think "has this service positioned itself as an exchange," assuming that as long as a service isn't called an "exchange," it shouldn't be bound by this rule. But the regulatory framework's actual determination logic doesn't work this way — it looks at what the service objectively does, not what it calls itself. A platform, even if it calls itself a "wallet" or a "tool," could theoretically still fall under the CASP definition if it objectively provides functions like exchange, custody of user assets, or trade matching.

What makes this standard distinctive is that it breaks the intuitive shortcut of "service name equals service nature" — another term on this site discusses how centralized exchanges nearly inevitably fall under CASP due to their centralized characteristics like identity verification and trade matching, but this functional test standard's scope actually extends further, not limited to obvious exchange-type services, and potentially reaching services that on the surface appear to be just a tool or interface.

Why does the regulatory framework use a functional test rather than directly listing which specific services count as CASPs?

The fundamental logic behind this question is consistent with the asset classification principle discussed in another term on this site — regulatory rules are concerned with economic substance and objective function, not surface form or name labels. If a regulatory framework adopted a "named list" approach (explicitly listing which specific services count as CASPs), that list would immediately face two problems: first, crypto service innovation moves far faster than a regulator can update such a list, so any enumerated list would quickly become outdated; second, this enumerative approach actually creates an obvious incentive for evasion — as long as a new service's name or packaging doesn't appear on the list, it could claim to be unregulated, even if it objectively does exactly the same thing as a service already on the list.

Adopting a functional test standard essentially shifts the focus of determination from "what is this" to "what does this do." This design lets regulatory rules adapt to the reality of crypto services evolving rapidly and diversifying in form, and also makes shell-based evasion harder — because regardless of how a service is packaged or named, as long as its objective function matches certain characteristics, it could fall within the regulatory scope.

How does the CASP functional test standard actually work, and how do different scenarios differ?

There are three common scenarios:

1. Explicitly providing exchange or trade matching functions: this is the most direct scenario falling under the CASP definition — the service itself lets users buy, sell, or convert crypto assets. Regardless of what name this kind of service calls itself, its objective function matches CASP's core characteristics
2. Providing asset custody without directly matching trades: if a service lets users store crypto assets at an address controlled by the platform (rather than the user holding their own private keys), even without a direct trade matching function, this custody relationship itself could be an important factor in determining CASP coverage
3. Purely self-custody tools or interfaces: if a service only provides an interface for users to view their own wallet, or helps users sign their own transactions, without ever touching the user's private keys and without providing exchange matching functions, this scenario's objective function typically doesn't match CASP's core characteristics and is less likely to be classified as one — but if that same service provider later adds exchange or custody functions, the determination could change accordingly

In practice, determining which scenario a service belongs to requires specifically examining that service's actual operating method, rather than simply looking at its marketing description or name — particularly for services with more complex function combinations (such as offering both self-custody and built-in exchange functions simultaneously), which may need each specific function separated out and determined individually.

What does the CASP functional test standard actually mean for me, and what risks should I watch for?

The most direct impact is that you can't simply rely on a service's self-description or marketing language to determine whether the platform you use is bound by CASP regulation — as discussed in another term on this site, if a service is classified as a CASP, it typically requires you to provide due diligence documents like a tax residency declaration. If you find that a service you use (even one that calls itself a "tool" or "wallet") starts asking you for this kind of information, this typically means its objective function has already triggered a CASP determination, not that the platform is arbitrarily adding to your hassle.

Another easily overlooked risk is that this functional test standard's determination result can change as a service's own functions are added or removed — a purely tool-type service you use today, if it later adds exchange or custody functions, could shift from "not subject to CASP regulation" to "subject to CASP regulation." This means you need to watch for major functional changes in the services you use over the long term, rather than only determining this once at the start of use and assuming it stays fixed forever. In practice, it's advisable to periodically check whether the crypto services you use have added functions like exchange or custody — especially products that started as merely viewing tools and gradually expanded into comprehensive service platforms.