Warning signs include a central group that can change rules, decide operations, control reserves, direct product launch, or profit from the service. Those signals indicate regulators may view the business as responsible for compliance, even if the software is distributed or non-custodial. Teams should treat governance control as a regulatory exposure and assess it early.
What the warning signs are really telling you
The practical question is not whether a platform uses smart contracts, self-custody logic, or distributed infrastructure. It is whether the business has enough human or organisational control to look like the party operating a regulated virtual asset service. If a core team can alter rules, steer launches, touch reserves, or decide who gets access, regulators may see a responsible operator rather than a neutral software publisher.
That is why early drift usually shows up in governance, not code. A protocol can be technically non-custodial while the company behind it still exercises launch authority, economic control, or binding oversight over customer-facing activity. The closer the business gets to directing outcomes, the harder it becomes to argue that compliance obligations sit nowhere in the organisation.
Governance control is the first signal to examine
Look first at who can actually make consequential decisions. If a small group can change product rules, approve listings, pause activity, or determine reserve handling, the business is no longer just providing software support. That kind of central authority is often the clearest indicator that legal and regulatory responsibility may attach before launch.
The same applies when the company controls the launch sequence itself. A business that schedules rollout, gates user onboarding, or retains a veto over whether the service goes live is behaving like an operator. Public claims about decentralisation do not cancel that fact if the practical decision-making remains concentrated.
One useful test is whether the business can be removed without changing what the service does. If removing the company would break rule changes, reserve management, issue resolution, or customer access, then the business likely has more than a passive vendor role. That is the point where VASP analysis should move from theory to documented review.
Operational and financial control often matter more than labels
Regulators also look at whether the company can direct funds, reserves, or transaction outcomes. Even limited control over treasury functions, fee allocation, or redemption flows can create exposure if the firm is effectively administering part of the asset lifecycle. The presence of a non-custodial interface does not eliminate that risk if the business still influences the economics or settlement path.
Another warning sign is profit-sharing tied to service operation rather than pure software licensing. If the business earns from transaction flow, reserve management, or execution decisions, that commercial model can support a view that it is participating in the service itself. In practice, economic participation and operational control often reinforce each other.
Teams should also scrutinise who holds the keys to critical dependencies. Access to administrative wallets, upgrade rights, deployment credentials, or reserve controls can turn an apparently distributed platform into a centrally managed service. Governance and access structure matter here as much as product architecture, because the operational reality is what external reviewers will test.
What to do before launch when the line is not yet clear
Before shipping, map every decision point that can change customer outcomes, fund movement, access control, or service availability. Then ask whether each decision is owned by the business, by a foundation, by users, or by no one in a way that is genuinely enforceable. Where the answer is unclear, treat that ambiguity as a launch blocker until the operating model is documented and reviewed.
It is also wise to separate technical decentralisation from organisational accountability. A design can reduce custody risk without eliminating regulatory exposure if the business still runs the service, sets policy, or coordinates critical actions. The launch decision should therefore be based on actual control surfaces, not on branding terms such as “decentralised” or “non-custodial.”
For teams working near the boundary, the most useful discipline is to test the business model against the service model. If the company can influence user rights, reserves, listings, fees, or rule changes, assume the compliance conversation has already started. Early legal and governance review is usually cheaper than retrofitting controls after launch.
Risk and Threat Considerations
A crypto business drifting into VASP territory faces more than classification risk. If control is concentrated in a few hands, the same central points that make the service look regulated also become attractive targets for abuse, insider misuse, or post-launch enforcement action if the operating model does not match the public claims.
Failure mechanism: The business retains enough operational, financial, or administrative control that regulators can attribute service responsibility to it, even if the user-facing system appears distributed or non-custodial.
Impact: The organisation can inherit licensing, AML, customer due diligence, sanctions, or reporting obligations before it expected them, and a weak launch posture can turn a product decision into a regulatory and operational incident.
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 | AC-6 — Least Privilege | Central control over launch and reserves raises access minimisation concerns. |
| IA-5 — Authenticator Management | Wallets, admin consoles and deployment paths depend on tightly managed credentials. | |
| Recommendation — Restrict administrative powers to the smallest viable set of operators. Rotate and govern privileged credentials that can affect service outcomes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Launch authority and reserve control are access-governance issues in this scenario. |
| A.8.2 — Privileged access rights | Privileged access determines who can steer operations, listings and recovery. | |
| Recommendation — Define and enforce who may change rules or move critical funds. Review and limit privileged access to operationally critical functions. | ||
| CIS Controls v8 | CIS-5 — Account Management | The warning signs hinge on who controls accounts, keys and operational authority. |
| Recommendation — Inventory and remove unnecessary accounts that can direct the service. | ||
Practitioner Guidance
What to verify: Confirm who can alter rules, control reserves, approve listings, pause service, and recover access to production-critical wallets or deployment paths. If those powers sit with the company or a small operator group, treat the VASP question as live rather than theoretical.
Decision rule: If the business would still be seen as the actor making binding service decisions after removing the smart-contract layer, assume the operating model is carrying regulatory weight and escalate for formal review before launch.
Practitioner takeaway: The most reliable warning sign is not custody alone, it is whether the business can still be recognised as the party directing outcomes.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- What are the signs that SAML metadata is drifting out of sync before users report an outage?
- What are the signs that an Oracle E-Business Suite compromise may be unfolding before full ransomware deployment?
- What are the signs that a DeFi protocol has not been tested enough before launch?
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
