Organisations should build a compliance assessment into product design, then revisit it as the service evolves. That includes identifying who controls the service, what financial activity it enables, whether counterparties need screening, and whether Travel Rule, reporting, or jurisdiction-specific obligations apply. Early legal and compliance review reduces the chance of launching a model that later needs costly redesign.
How regulators and compliance teams will read a virtual asset service model
The practical question is not whether a protocol is technically decentralised, but whether the operating model creates a service that looks like custody, exchange, transfer, intermediation, brokerage, or another regulated financial activity. That assessment usually turns on who can influence transactions, who holds control keys or wallet flows, and whether the organisation is effectively arranging activity for others rather than merely publishing software.
When that line is unclear, the safest interpretation is to treat the design as potentially in scope until counsel and compliance can rule it out. A useful reference point is the FATF Recommendations, because virtual asset treatment is often driven by jurisdictional AML, CDD, and Travel Rule obligations rather than by the protocol label alone.
For teams building products with wallets, token rails, or embedded transfer logic, the key issue is whether the organisation is creating a repeatable service layer around value movement. That includes hosted wallets, managed signing, routing, swap execution, order matching, or any flow where the operator can materially affect access, settlement, or counterparty selection.
What to assess in the protocol, wallet flow, or token model
The assessment should start with control and move outward to the activity the system enables. Identify whether the organisation can freeze, block, route, aggregate, or otherwise influence assets, then map that to the actual financial function being performed. If the platform receives value from one party and delivers value to another, the regulatory analysis becomes much more serious than if it only publishes code or provides a passive interface.
Counterparty handling is another major trigger. If the service transmits value between users, intermediaries, or exchanges, it may need screening, sanctions review, recordkeeping, or originator and beneficiary information collection depending on the jurisdiction and transfer pattern. The same is true where the token model introduces redeemability, transferability, or economic rights that make the asset function more like a regulated instrument than a simple utility token.
Product and legal teams should also examine whether the service design creates delegation, agency, or operational control over customer assets. A wallet flow that looks user initiated in the UI can still be a regulated service if the operator retains decisive control over execution, policy enforcement, or transaction finality. For protocol design, audience-bound or delegated flows should be documented carefully, and token handling should be reviewed against standards such as RFC 9700: Best Current Practice for OAuth 2.0 Security when access tokens or delegated approval chains are part of the operating model.
Why the classification can change over time
A model that starts as software can drift into regulated service territory as governance, custody, and transaction handling are added. That is why the answer cannot be a one-time launch checklist. If the team later adds hosted accounts, automated routing, treasury functionality, third-party integrations, or customer support that can reverse or remediate transfers, the regulatory posture may change even if the original whitepaper did not promise those features.
This is especially important for token models with evolving economics. A governance token, reward token, or settlement asset can cross into a different compliance category when transfer restrictions are removed, redemption is introduced, or the issuer starts operating a market-facing service around it. The architecture should therefore include a formal re-review trigger whenever control of funds, transaction execution, or customer onboarding changes.
Operationally, the most dangerous assumption is that decentralisation alone removes obligation. Regulators and supervisors typically evaluate actual control, facilitation, and commercial role, not just where the code is hosted. A design review that is tied to product milestones catches the point where “software” becomes “service” before the business is locked into a model that is difficult to unwind.
Risk and Threat Considerations
Misclassifying a wallet flow or token model can create licensing, AML, sanctions, and customer disclosure exposure long before the organisation recognises it. The risk is not only regulatory enforcement, it is also forced redesign, transaction interruption, and the possibility that counterparties or partners will refuse to integrate once the operating model is understood.
Failure mechanism: The service accumulates control over value movement, counterparty decisions, or delegated execution, then crosses a jurisdictional threshold that makes it a regulated virtual asset service without the necessary controls, screening, or reporting in place.
Impact: The organisation may need to suspend flows, add compliance gates after launch, re-paper partner relationships, or unwind product decisions that were built around an incorrect legal assumption.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | Assessing virtual asset service exposure is fundamentally a regulated risk decision. |
| AC-6 — Least Privilege | Control over transfers and delegated execution should be tightly bounded to reduce service and custody exposure. | |
| Recommendation — Perform a formal risk assessment before launch and whenever wallet or token flows change. Restrict who can initiate, approve, or alter value-moving functions to the minimum necessary. | ||
| ISO/IEC 27001:2022 | A.5.31 — Legal, statutory, regulatory and contractual requirements | The question turns on regulatory classification and jurisdiction-specific obligations. |
| A.5.14 — Information transfer | Wallet and token flows involve controlled transfer of value and associated data handling. | |
| Recommendation — Track applicable legal and regulatory obligations for each market before product launch. Define and review rules for controlled transfer paths and required counterpart checks. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The regulated-service question must be built into product design, not added later. |
| Recommendation — Embed compliance review into the software design and change process before release. | ||
Practitioner Guidance
What to prioritise: Put the compliance review on the critical path for any design that can hold, route, exchange, or settle value for others. The first question is usually control, not terminology: who can actually move or block assets, and who is the service acting for?
What to verify: Maintain a written decision trail for custody, transfer facilitation, counterparty screening, and Travel Rule analysis, and update it when the product changes. If the business cannot explain why a model is outside scope in one jurisdiction, it is not ready to treat that answer as stable.
Practitioner takeaway: The safest pattern is to treat regulatory classification as a living design property, not a launch-time label, because value movement features tend to expand into obligation even when the original product story says they will not.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
