The risk changes because the rules focus on persons that provide facilitative services, not on code itself. If an entity controls access, knows the customer, and can identify the transaction, it may be pulled into reporting obligations. By contrast, someone who only publishes software and no longer controls the interface is less likely to fit that broker-like role under the proposed framework.
How compliance risk shifts when an intermediary is running the service, not just shipping the code
The compliance profile changes when the business is no longer a passive publisher of software. Once an entity operates the interface, knows the customer, can observe the transaction, or can affect execution, it can move from a product role into a regulated facilitation role. That is why the same technical system can sit outside one rule set while the operating business, custody model, or customer relationship pulls another actor into scope.
This distinction matters because compliance frameworks typically attach duties to conduct, control, and visibility, not to code authorship alone. A software publisher may distribute tooling without collecting customer data or controlling transactions, while a middleman may be able to screen, log, route, block, or disclose activity. That operational control is often what turns a technical platform into a compliance subject. For governance expectations around access, logging, and operational accountability, see ISO/IEC 27002:2022 Information Security Controls and CIS Controls v8.
In financial and asset-transfer contexts, the key compliance trigger is often whether the entity is providing a facilitative service rather than merely producing software. That is why customer identification, transaction traceability, and reporting capability become central. Where the subject is virtual-asset or value-transfer activity, the compliance lens also shifts toward AML/KYC obligations and suspicious-activity handling, which are captured in the FATF Recommendations. For platform-side operational accountability and assurance expectations, SOC 2 Trust Services Criteria is also a useful reference point.
Why software publishers and protocol developers are treated differently
Pure software publishers and protocol developers usually remain closer to a neutral upstream role. They design, publish, or maintain code and specifications, but they may not control customer onboarding, transaction routing, user screening, recordkeeping, or the operational environment in which the system runs. When those functions are absent, the compliance risk is generally lower because the entity is not the one exercising the broker-like or intermediary function that many regimes care about.
By contrast, if the same organisation hosts the service, controls the interface, can identify counterparties, or can change how transactions are handled, it is harder to argue that it is only a publisher. The practical question is not “who wrote the code?”, but “who can intervene in the transaction and who has the customer relationship?”. That is also why outsourcing, hosted tooling, and managed interfaces often create more compliance exposure than downloadable software. For implementation guidance on how compliance expectations translate into controls, the OWASP Cheat Sheet Series is useful for authentication, session handling, and secrets hygiene.
For organisations that operate in digital-asset ecosystems, the middleman role can create obligations even when the underlying technology is open or decentralised. If the business can see, influence, or mediate activity, regulators may treat it as a service provider with compliance duties. If it merely ships a protocol or publishes software without operating the service layer, the compliance risk is usually more limited, though not always eliminated.
Practitioner guidance for assessing broker-like exposure
What to verify: Test the actual operating model before relying on the label “software provider.” If the organisation controls onboarding, transaction routing, customer records, or screening, treat compliance scope as service-provider risk rather than product-only risk.
What to measure: Track whether the business can identify the transacting parties, produce records on demand, and explain which entity can freeze, block, or alter activity. Those are the functions that most often move an entity into a facilitative-services category.
Common mistake: Teams often assume that publishing code, using open-source infrastructure, or distributing a protocol automatically avoids compliance duties. That shortcut fails when the same entity also operates the customer-facing service or retains control over the workflow.
Practitioner takeaway: The decisive issue is operational authority, not technical authorship, so compliance scoping should follow who controls the service relationship and transaction visibility.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 / 8 / 14 — Access Control Management, Audit Log Management, Security Monitoring | Operational intermediaries need account control, logging, and monitoring to support compliance evidence. |
| Recommendation — Tighten account control and logging for platforms that mediate transactions or customer access. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
