Nested services can inherit an exchange’s liquidity and trading access while operating with lighter visibility into end users and source of funds. That creates a pathway for illicit actors to move value through legitimate infrastructure and convert crypto into cash. When oversight is weak, the host exchange may become part of the laundering chain even if it is not the primary criminal actor.
How nested services change the exchange’s exposure
Nested cryptocurrency services are risky because the hosting exchange is no longer just providing trading rails, it is also extending those rails to another operator whose controls, customers, and transaction logic it may not fully see. That creates a mismatch between the host’s compliance obligations and the nested service’s actual behaviour, especially when funds can enter, pool, route, or exit through the host’s liquidity with limited transparency.
In practical terms, the risk is less about the nested service being “crypto adjacent” and more about the exchange losing assurance over who is using the service, why the flow exists, and whether the flow is consistent with the exchange’s own AML and sanctions controls. If the nested layer can onboard or serve high-risk users, the host can inherit the exposure without having directly contracted with those end users.
That is why the most important question is whether the host exchange can still trace beneficial ownership, transaction purpose, and source of funds at the point where the nested service connects to its infrastructure. When that visibility breaks down, screening and monitoring become much weaker than they appear on paper.
Why sanctions and laundering risk compounds through nested relationships
Sanctions risk rises when a nested service gives restricted parties indirect access to exchange infrastructure, fiat conversion, or liquidity pathways. Even if the host does not intentionally serve a sanctioned person, the nested relationship can obscure who is actually transacting, which jurisdiction they are in, and whether the flow is a prohibited one-step or multi-step evasion pattern.
Money-laundering risk rises for the same reason: nested services can act as a layer of aggregation, fragmentation, and reuse that makes illicit flow look like ordinary platform activity. If the host exchange cannot reliably distinguish legitimate customer activity from pass-through activity, the nested service may function as a concealment layer inside otherwise legitimate infrastructure.
One useful reference point is the FATF Recommendations on AML and KYC, which require customer due diligence, beneficial ownership awareness, and controls proportionate to virtual asset risk. For exchanges, that means the compliance question is not only “who is our customer,” but also “who is our customer’s customer, and what controls survive delegation?”
Relevant background on the underlying identity and secret-management failure mode is also visible in the broader non-human control plane, where exposure often comes from weak oversight rather than a single breach event. NHIMG’s Ultimate Guide to Non-Human Identities is a useful companion for understanding how weak visibility and weak revocation create systemic exposure.
What exchanges should verify before hosting nested services
The key control decision is whether the host can impose meaningful due diligence, monitoring, and termination rights on the nested service. If the answer is no, the relationship is not just a commercial integration, it is an unresolved compliance dependency.
What to verify: Know whether the nested service performs KYC, keeps records, and can evidence source-of-funds controls for its own users.
What to measure: Monitor for unexplained wallet clustering, rapid pass-through behavior, unusual cross-jurisdiction activity, and repeated use of the same pathways by unrelated users.
What good looks like: The host can trace the nested service’s activity to a defined risk owner, documented policy, and a clear exit path if screening or monitoring fails.
For practitioners, the central trade-off is scale versus assurance. Nested services can expand distribution quickly, but each layer of abstraction reduces confidence in who is actually behind the transaction and whether the host can intervene fast enough if a sanctions or laundering issue appears.
Useful external reference points are the FATF Recommendations, AML and KYC Framework and FinCEN, because both frame the reporting, due diligence, and suspicious activity expectations that become harder to meet when access is delegated through a nested provider.
Risk and Threat Considerations
Nested services create a classic control-gap problem: the exchange may hold the liquidity and the customer relationship while another party controls the user onboarding and transaction context. That separation can be exploited to route illicit value through a platform that appears compliant at the perimeter but lacks enough visibility to stop high-risk flows in time.
Failure mechanism: The host exchange relies on indirect assurance from the nested service, but cannot fully validate the nested service’s users, screening quality, or transaction purpose. The resulting visibility gap allows sanctioned or laundering activity to blend into ordinary exchange traffic.
Impact: The exchange can become a laundering intermediary, face sanctions exposure, trigger enforcement or de-risking action, and lose trust with banks, regulators, and counterparties even when it was not the original criminal actor.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while NIS2 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Nested services need controlled, reviewable access paths to exchange rails and customer data. |
| Recommendation — Restrict delegated access and revoke nested service privileges when monitoring or due diligence weakens. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The exchange must know who can access and move value through its environment. |
| GV.OV — Oversight | Nested services require governance over third-party risk and compliance accountability. | |
| DE.CM — Continuous Monitoring | Suspicious nested flow patterns require ongoing monitoring to detect laundering or sanctions abuse. | |
| Recommendation — Enforce strong identity assurance and access controls for all delegated service relationships. Establish oversight for nested providers and tie continued access to verified control performance. Monitor delegated transaction patterns for anomalies that indicate laundering or sanctions evasion. | ||
| NIS2 | Art. 21 — Cybersecurity Risk-Management Measures | The subject involves operational and governance measures to reduce exposure from third-party dependencies. |
| Recommendation — Apply risk-management measures to third-party dependencies that can affect regulated service integrity. | ||
| DORA | Art. 28 — ICT Third-Party Risk Management | Nested services are a third-party dependency that can transmit operational and compliance risk. |
| Recommendation — Contractually govern and continuously review third-party service risk before allowing platform dependency. | ||
Practitioner Guidance
Decision rule: If a nested service can move value through your rails without the same identity, source-of-funds, and jurisdiction checks you apply to direct customers, treat the relationship as high-risk by default. Delegated distribution is acceptable only when the host can prove the nested layer is continuously governed, not merely contractually promised.
What to prioritise: Put termination rights, monitoring expectations, and escalation thresholds ahead of commercial growth targets. If you cannot promptly freeze, delist, or segment the nested flow when screening signals deteriorate, you do not have a defensible control posture.
Practitioner takeaway: The real risk is not that the exchange knowingly launders funds, it is that weak oversight lets someone else use the exchange’s infrastructure as if it were their own compliance boundary.
Related resources from NHI Mgmt Group
- Why do ISIS-linked money services businesses create higher sanctions risk for exchanges and VASPs?
- Why do digital asset exchanges create sanctions and money laundering risk when they sit between high-volume wallets and cross-border flows?
- Why do cash to crypto laundering pipelines create such persistent sanctions and AML risk for exchanges?
- Why do crypto exchanges create AML and sanctions risk beyond direct customers?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
