How should crypto compliance teams handle FATF’s function-based approach when deciding whether a service counts as a VASP?

How FATF’s function-based test changes the VASP decision

The practical shift is that compliance teams should assess what the business actually does, not what it calls itself. That means mapping each service to the underlying virtual asset function, then checking whether it is performed on behalf of another person or entity. A platform’s branding, wallet model, or custody posture may inform the analysis, but none of those labels is decisive on its own.

For teams building the review process, the key question is whether the activity creates regulated intermediation between users and virtual asset movement or safekeeping. Services that exchange, transfer, safeguard, or issue in ways that place the provider in the middle of customer value flows are the ones most likely to trigger VASP treatment. That functional lens is why internal product descriptions often need to be translated into plain operating reality before the legal conclusion is made.

One useful way to structure the analysis is to separate the service layer from the control layer:

• Identify the exact activity, such as exchange, transfer, safekeeping, or issuer-related handling.
• Determine who controls the transaction, asset movement, and customer relationship.
• Test whether the firm acts on behalf of others rather than only for its own account.
• Document why the activity does or does not fall within the FATF function set.

That approach reduces the chance that teams over-rely on labels like “technology provider,” “non-custodial,” or “software-only.” It also helps compliance, legal, and product teams speak the same language when the operating model changes, because a small product change can move a service from outside scope to inside scope. For teams comparing the classification to broader control obligations, FATF’s own framework remains the anchor for this functional review, and the same logic aligns with the compliance and governance expectations described in FATF Recommendations.

Why business labels and technical architecture are not enough

FATF’s function-based approach is designed to prevent form-over-substance mistakes. A service can look decentralised, automated, or self-described as non-custodial and still fall within scope if it materially performs a virtual asset function for customers. The reverse is also true: some technical intermediaries support the market without actually carrying out the regulated function that would make them a VASP.

That means the review cannot stop at architecture diagrams. Compliance teams need enough product and transaction detail to understand whether the firm is touching user assets, routing transfers, controlling execution, or managing the issuance process. If the answer depends on a particular workflow, then the scope analysis should be tied to that workflow, not to a generic platform description.

In practice, this is where teams should be careful about delegation and outsourcing. If a service provider or embedded partner is actually performing the regulated function on behalf of customers, the VASP analysis may attach even if another entity owns the front end. The control question is therefore not only “what does the company build?” but also “what function is being delivered to the customer, and by whom?”

For practitioners who need an operational reference point, the definition logic should be read alongside the broader AML and customer due diligence architecture in the FATF Recommendations framework, because that is where the compliance consequences of a VASP classification become actionable.

How teams should operationalise the classification decision

The best practice is to turn the VASP decision into a repeatable control, not a one-time memo. Teams should maintain a service inventory, document the functional test applied to each product, and tie the classification to specific trigger events such as a new transfer feature, a custody change, a brokered onboarding flow, or a new issuer service. When those triggers occur, the classification should be revisited before launch.

Where a service is in scope, the compliance program should be able to show the downstream controls that follow from that status, especially KYC, monitoring, suspicious activity escalation, and governance over outsourced functions. Where a service is outside scope, the file should still show why the conclusion was reached and what facts were tested, because regulators generally care more about the reasoning than the marketing language.

What to verify: Keep evidence that shows the actual operating model, including customer flow diagrams, terms of service, transaction handling roles, and the rationale for excluding or including each function. If the service changes hands, changes control, or changes how assets move, treat that as a reclassification event rather than an administrative update.

Practitioner takeaway: The safest VASP decision process is a living functional review, because scope usually changes when the service changes, not when the label changes.

Related resources from NHI Mgmt Group

• How should crypto compliance teams handle concentrated illicit flow patterns?
• How should compliance teams handle crypto flows when sanctioned entities reuse the same services as criminals?
• How should security teams handle GitHub-based phishing that tries to steal crypto wallet approvals from developers?
• How should compliance and fraud teams distinguish service theft from personal wallet compromise when assessing crypto loss trends?