A compliant virtual asset service provider is an entity, or person acting on behalf of others, that participates in the transfer of value in the chain of transactions and therefore may need AML controls, licensing, and reporting. A truly decentralized application with no natural person connected to it may be excluded, but many platforms will not meet that threshold.
How FATF Separates an Entity-Based Provider From a Truly Decentralized App
The distinction turns on whether there is a responsible person or entity in the middle of the value transfer chain. If a platform is operated, controlled, or promoted by a natural person or business that can meet virtual asset service provider criteria, FATF expectations can attach. If the application is genuinely decentralized and no accountable operator is performing the covered activity, it may fall outside that perimeter.
The practical test is not the label on the website or whitepaper. It is whether the service behaves like an intermediary, can affect transaction flow, and can be supervised, licensed, or obligated to perform AML duties. Many products marketed as decentralized still have a team, governance body, admin keys, or economic control that makes them closer to a service provider than a pure protocol.
That is why the FATF Recommendations, AML and KYC framework matter here, they define the compliance perimeter around customer due diligence, reporting, and virtual asset transfer obligations rather than around branding. FATF’s standard is designed to capture the party that can actually perform or facilitate those controls.
What Makes a Platform Fall Inside or Outside the FATF Perimeter
A compliant virtual asset service provider usually has identifiable control points: onboarding, transaction screening, sanctions exposure handling, recordkeeping, and a party that can be compelled to change behavior. Those are the features that make AML supervision meaningful. A decentralized application, by contrast, only falls outside expectations when decentralization is real enough that no natural person or entity is carrying out the covered service on behalf of others.
In practice, the line often blurs. A front end, governance token, admin privilege, fee collector, upgrade path, or hosted interface can reintroduce a responsible intermediary even when the underlying smart contract looks autonomous. Regulators and compliance teams therefore look past protocol architecture and ask who controls access, who benefits economically, and who can influence the service lifecycle.
That control-based reading is also why many teams use a governance lens instead of a pure code lens. If a group can freeze assets, change routing, modify fees, or decide what users can reach, the platform may be functionally supervised even if it claims to be decentralized. If nobody can realistically do those things, the case for falling outside the VASP perimeter becomes stronger.
For a broader governance and controls baseline, the ISO/IEC 27001:2022 Information Security Management and CIS Controls v8 resources are useful reference points for how organisations establish accountable controls, even though FATF applies a separate regulatory test.
Risk and Threat Considerations
The risk is classification error. If a platform is treated as decentralized when it still has a controllable operator, AML, sanctions, and reporting obligations can be missed. If a truly decentralized protocol is treated as a conventional service provider, firms may over-collect data, overstate control, or build compliance processes that do not match the actual operating model.
Failure mechanism: The usual failure mode is governance opacity, where marketing claims, token-based governance, or partial automation hide the fact that a natural person or entity still directs material parts of the service.
Impact: That mismatch can create regulatory exposure, weak suspicious activity detection, and an inaccurate risk assessment of the platform, counterparties, and transaction flows.
When decentralization is only partial, attackers and bad actors can also exploit the weakest human or organisational control point, such as admin access, upgrade authority, or a hosted interface. That is why the operational question is often less about code purity and more about who can actually intervene in the system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The question hinges on who operates and controls the service. |
| GV.RM-01 — Risk Management Strategy | Misclassifying decentralization creates regulatory and control risk. | |
| Recommendation — Document the operating model and accountable parties before deciding compliance scope. Classify the service model within your risk strategy before relying on decentralization claims. | ||
| CIS Controls v8 | 15 — Service Provider Management | The answer depends on whether a third party is actually providing a controlled service. |
| 6 — Access Control Management | Control rights, admin keys, and change authority determine whether the app is truly decentralized. | |
| Recommendation — Assess service-provider accountability and contractual obligations for any platform that performs covered activity. Restrict and review administrative control paths that can change transaction behavior or user access. | ||
| PCI DSS v4.0 | 12.8 — Security Requirements for Service Providers | The distinction depends on whether an external operator is in scope as a provider. |
| Recommendation — Map provider responsibilities and oversight when a platform performs regulated services on behalf of others. | ||
Practitioner Guidance
What to verify: Determine whether there is a natural person, business, foundation, or operated interface that can influence onboarding, transaction handling, fee collection, upgradeability, or dispute resolution. If yes, do not assume the platform is outside FATF expectations simply because parts of it are automated.
Decision rule: If the platform can be controlled, modified, paused, marketed, or economically steered by an identifiable party, treat it as compliance-relevant and map the obligations before relying on decentralization claims.
What good looks like: A defensible assessment documents who controls the service, what activities are actually performed, and why the service does or does not meet the applicable virtual asset service provider threshold.
Practitioner takeaway: The important distinction is not “blockchain versus non-blockchain,” it is whether a real party is performing the covered service and can be held to AML obligations.
Related resources from NHI Mgmt Group
- What is the difference between using Rails for application delivery and using it to influence security culture?
- Who is accountable when a Virtual Asset Service Provider fails to meet Travel Rule requirements?
- What is the difference between IT asset visibility and service management automation?
- What is the difference between a data product and a traditional data asset in self-service environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
