Software alone is not usually the regulated actor. A VASP is identified by the services it performs, such as exchange, transfer, or custody of virtual assets on behalf of customers. In practice, the difference turns on who exercises control, who initiates or manages transfers, and whether human or organisational decision-making is involved in the regulated activity.
Software Support Versus Regulated VASP Activity
The key distinction is between enabling technology and the party performing the regulated service. Software can support virtual asset transfers, recordkeeping, routing, or workflow, but that does not automatically make the software itself a VASP. The regulated question is whether an entity is actually carrying out exchange, transfer, custody, or similar activity for customers, and whether it does so with real control over the asset movement or customer relationship.
That distinction matters because regulatory duties generally attach to the operator, not to every tool in the stack. A platform may be exposed to licensing, AML, sanctions, and governance expectations if it materially conducts the activity, while a vendor supplying software may sit outside that regime unless it crosses into operational control. For teams, the hard part is proving where the service boundary sits, especially when automation makes the software look more autonomous than it is.
In practice, many compliance teams discover the boundary only after a product review or supervisory challenge has already forced them to explain who actually controls the transfer.
How the VASP Boundary Is Assessed in Practice
Assessment usually starts with function, not form. If an organisation merely provides software that lets others initiate or manage virtual asset activity, it is closer to a technology provider. If it decides how assets move, holds custody keys, approves transfers, intermediates exchange, or otherwise acts on behalf of customers, it begins to look like the regulated entity. The same product can fall on either side depending on operating model, contractual control, and who can change transaction outcomes.
Several practical questions help separate the two:
- Who has authority to initiate, approve, or reverse transfers?
- Who controls custody, keys, or access to the underlying asset?
- Does the entity merely provide infrastructure, or does it actively execute the service?
- Are customer instructions passed through unchanged, or interpreted and managed by the provider?
- Who bears the customer-facing responsibility for compliance, screening, and dispute handling?
The answer is rarely determined by the product label alone. A hosted wallet, routing engine, or orchestration layer may be software support in one deployment and regulated service delivery in another. That is why legal structure, operating procedures, and technical control evidence all need to align. In cross-border models, the same service may also be assessed differently by different regulators, so governance must document how the entity is positioned in each jurisdiction. For a useful comparison point on machine-like control and service accountability, NHIMG also points readers to the OWASP Non-Human Identity Top 10, which helps teams think about when software-driven access becomes a control problem.
Where this guidance breaks down is when the software provider has enough discretion over customer assets or transaction handling that it is no longer just supporting the service.
Boundary Cases, Outsourcing, and Control Drift
Tighter automation often improves scale and consistency, but it also makes the boundary between tool and operator harder to see, requiring organisations to balance efficiency against regulatory clarity.
Outsourced or embedded models are the most common edge cases. If a vendor hosts infrastructure, processes instructions, or operates an internal workflow but does not decide the transaction, it may still be outside the VASP definition. If, however, the software is configured so the provider can materially influence custody, execution, or access, the legal and operational picture shifts. Industry practice is not fully uniform here, so teams should treat the boundary as a fact pattern to evidence, not as a branding exercise.
Another gotcha is control drift. A product can begin as passive software support and later accrete managed services, administrative override, recovery access, or exception handling that changes the regulatory character of the arrangement. That is especially important when customer support staff, administrators, or automated policy engines can intervene in asset movement. The practical test is whether the entity can still show that it is only enabling the service, rather than performing the service itself.
In short, the regulated status follows operational reality. If the organisation can change the outcome of a virtual asset transaction, it should expect scrutiny as if it were part of the service boundary, even if the original contract describes it as software only.
Risk and Threat Considerations
The main risk is misclassifying a software-driven operating model as mere tooling when it actually concentrates control over transfers, custody, or customer instructions. That creates regulatory exposure, weak accountability, and the possibility that compliance obligations are being carried by an entity that cannot evidence the actual service boundary.
Failure mechanism: The failure usually appears when product design, contractual language, and real operating behaviour diverge. Automated workflows, administrator overrides, recovery access, or hidden approval paths can give the software provider effective control over asset movement, turning a supposed support function into a regulated activity in practice.
Impact: The organisation may face licensing, AML, sanctions, governance, and customer-harm consequences, alongside remediation cost and supervisory challenge. It can also create unclear liability if an incident occurs and no party can cleanly show who controlled the transfer or custody decision.
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, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 — Cyber Supply Chain Risk Management Strategy | Service boundaries and provider roles shape regulatory and operational exposure. |
| PR.AC-1 — Identities and Credentials Issued, Managed, Verified, Revoked, and Audited | Control over who can act in the environment is central to determining effective service authority. | |
| Recommendation — Define provider boundaries and document which party owns regulated service controls. Tighten access governance around the accounts that can change transaction outcomes. | ||
| CIS Controls v8 | 5.1 — Establish and Maintain an Asset Inventory | Inventorying services and dependencies helps distinguish tooling from operational control. |
| Recommendation — Inventory service components and map where operational authority actually sits. | ||
| NIST SP 800-63 | SP 800-63-3 — Digital Identity Guidelines | Identity assurance becomes relevant where customer-facing authorization and control decisions determine service activity. |
| Recommendation — Align identity assurance with the party that can authorize or alter regulated actions. | ||
Practitioner Guidance
What to verify: Confirm the entity boundary by tracing who can initiate, approve, halt, or reverse asset movement, and do not rely on product descriptions or sales contracts alone.
Common mistake: Treating “we only provide software” as a complete answer when operational staff, admin access, or managed services still shape the regulated outcome.
What good looks like: The organisation can evidence a stable operating model in which software support, custody authority, transfer control, and customer responsibility are clearly separated and consistently documented.
Practitioner takeaway: The question is not whether software is involved, but whether the entity can influence the regulated virtual asset service in a way that regulators will treat as substantive control.
Related resources from NHI Mgmt Group
- What is the difference between a static asset inventory and a software-aware CMDB?
- What is the difference between software supply chain risk and NHI risk?
- What is the difference between SaaS supply chain security and software supply chain security?
- What is the difference between code review and access review in AI-generated software?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
