Combining those activities increases risk because each brings different regulatory obligations, control expectations, and customer harms. Trading platforms, custodians, staking providers, and stablecoin issuers must all manage AML, conduct, prudential, and disclosure duties, often with separate supervision triggers. If one operating model cannot evidence those controls clearly, the firm can face authorization delays, restrictions, or loss of permission to operate.
Why one operating model creates a compliance problem across crypto trading, custody, and stablecoins
Compliance risk rises when a firm uses one operating model for businesses that are supervised differently. Trading, custody, staking, and stablecoin issuance can each trigger separate expectations for AML, client asset protection, prudential resilience, disclosures, and conduct. When governance, controls, and evidence are blended, supervisors may see gaps in accountability, weaker segregation, or an inability to prove the right rule set is being applied to each activity.
A useful way to think about the issue is that the operating model is not just an organisational chart, it is the control boundary regulators test. If the firm cannot show which control owner, policy, and assurance process applies to each line of business, the shared model becomes a compliance failure mode rather than an efficiency gain. That is especially true when products are bundled but the legal and regulatory obligations are not.
That is why firms need to separate the questions of product design, risk ownership, and regulatory perimeter. A single platform can still support multiple activities, but the firm has to prove that its governance model distinguishes custody controls from trading controls, and both from stablecoin reserve, redemption, and disclosure obligations. The Fraud and Cyber Convergence Guide is a useful reference for the broader operating-model problem, because it shows how shared functions still need clear ownership, shared signals, and disciplined case handling.
Where the regulatory perimeter usually breaks first
The first pressure point is often AML and customer due diligence. Trading activity, custody flows, and stablecoin-related transfers can all create different transaction patterns and different screening expectations, so a unified process can miss edge cases if it assumes one rulebook fits all. In practice, the firm needs to show that onboarding, monitoring, escalation, and sanctions handling are calibrated to the specific activity, not just the legal entity.
Another common break point is control evidence. Supervisors do not only ask whether a control exists, they ask whether it is evidenced consistently across products and jurisdictions. If one team can produce reserve attestations, another can produce custody reconciliations, and a third can produce trading surveillance reports, but none can map them back to a shared control framework, the firm may look operationally capable but governance-poor. The GRC Maturity Model is relevant here because the core issue is maturity of evidence, ownership, and repeatability, not just policy volume.
Stablecoins add a further complication because they often bring reserve management, redemption expectations, disclosures, and sometimes payment-like oversight into the same operating picture. That makes segregation of duties and traceable reporting especially important. A firm that can operate a trading venue and a custody service may still struggle if it cannot demonstrate that stablecoin reserves, issuance logic, and redemption processes are controlled by a separate and auditable governance lane. The Identity Security Programme Guide is relevant as an operating-model analogue, because compliance often fails when ownership, RACI, and control boundaries are unclear.
Why supervisors treat the same setup as a conduct and prudential issue, not just a paperwork issue
When trading, custody, and stablecoin activity sit inside one model, the risk is not only that the firm breaches a rule. The larger concern is that one weakness can propagate across multiple regulated activities. A control gap in custody can affect client asset protection, a gap in trading surveillance can affect market integrity, and a gap in stablecoin governance can affect redemption confidence and disclosure quality. That is why supervisors may respond with delays, restrictions, or conditions on permission rather than a simple remediation request.
This kind of structure also increases concentration risk. A shared policy engine, shared control owner, or shared data platform can make the business look efficient, but it can also create a single point of failure for multiple obligations at once. If the shared model is wrong, every line of business inherits the same blind spot. The Web3 and Crypto Security Guide is useful as a practical reference because it shows how custody, key control, and incident response become systemic when they are not isolated properly.
For firms under active supervision, the real test is whether the model can prove proportionality. A crypto business does not need three unrelated operating models, but it does need enough separation to show that regulatory obligations are being met for each activity without confusion, overlap, or hidden assumptions. The Crypto Wallet Security Guide is relevant to the custody side of that equation because custody controls only work when ownership, key handling, and recovery responsibilities are explicit.
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, 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 CSF 2.0 | GV.OC-01 — Organizational Context | The question is about differing regulatory duties across crypto activities. |
| GV.RM-01 — Risk Management Strategy | A combined model changes how regulatory and compliance risk is owned and accepted. | |
| Recommendation — Define each crypto line of business and map its obligations before sharing controls. Set a risk strategy that separates trading, custody, and stablecoin obligations. | ||
| NIST SP 800-53 Rev 5 | PM-1 — Information Security Program Plan | The issue is operating-model governance and control ownership across activities. |
| Recommendation — Document a program structure that assigns control ownership per regulated activity. | ||
| ISO/IEC 27001:2022 | A.5.36 — Compliance with policies, rules and standards for information security | The model must evidence distinct compliance obligations and assurance paths. |
| Recommendation — Maintain evidence that each business activity meets its applicable compliance obligations. | ||
| CIS Controls v8 | CIS-17 — Incident Response Management | A shared model can spread failures across products and services, increasing response complexity. |
| Recommendation — Align incident response ownership to each regulated crypto activity. | ||
Practitioner Guidance
What to verify: Map each activity to its own licensing basis, control owner, and evidentiary set. If trading, custody, and stablecoin issuance share the same policy or reporting path, verify that the path still distinguishes the obligations that supervisors will test separately.
Decision rule: If a control cannot be demonstrated separately for each regulated activity, treat the operating model as too blended for the current risk profile. In that case, split the evidence model first, then decide whether the legal-entity or technology model also needs to change.
What good looks like: One operating model can support multiple businesses only when the firm can show clean segregation of duties, clear escalation paths, and activity-specific management information. The best signal is that a reviewer can trace any control from obligation to owner to evidence without needing tribal knowledge.
Practitioner takeaway: Efficiency is acceptable, but regulatory ambiguity is not. If the firm cannot explain how the same model meets distinct obligations for trading, custody, and stablecoins, supervisors will likely treat that as control weakness, not as operational sophistication.
Related resources from NHI Mgmt Group
- How should crypto businesses in Australia structure compliance when they may fall under both AUSTRAC and ASIC rules?
- Why do trading platforms face higher compliance pressure when they operate globally?
- Why do businesses that collect California consumer data face higher legal and operational risk under CCPA?
- Why do centralized exchanges face higher compliance and security exposure than many other crypto businesses?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org