Nested Crypto Services: One Address, Three Parties: The Forensic Blind Spot:
Why an attributed exchange address may identify the infrastructure provider, but not the account operator or the person whose transaction was actually executed.
One of the most misleading (and frustrating) moments in a blockchain investigation is also one of the most familiar: the trace reaches a deposit address attributed to a major centralized exchange.
Initially, that looks like good news. The investigator has identified a known service provider, and the next steps seem obvious. Preserve the account, serve the exchange, identify the customer, keep moving.
Except sometimes the exchange's customer is not the person behind the transaction. It is another financial service. A smaller exchange, an OTC broker, a swap provider, a payment processor, or a gambling platform may be operating through an account, subaccount, API, or white-labeled interface at the larger exchange. The smaller service takes transactions from its own users while relying on the host for custody, liquidity, trading pairs, conversion, and sometimes fiat access.
That arrangement is a nested service. FATF describes VASP-to-VASP relationships as including white-labeled platforms and nested services in which smaller providers receive accounts or platform access to obtain liquidity and trading pairs [1]. Its March 2026 report on offshore VASPs acknowledges that nested activity can be entirely legitimate, then warns that it can obscure the identity, risk profile, and transaction activity of the customers underneath [2].
One deposit address can represent three different parties
When funds arrive at an address controlled by a large exchange, an investigator may be looking at three distinct layers:
The infrastructure controller. The centralized exchange that holds the private keys and controls the blockchain address.
The direct account holder. The nested exchange, broker, or processor operating the account at the CEX.
The underlying transactor. The nested service's own customer, the person or entity actually initiating or benefiting from the transaction. To add one more layer of frustration, this individual can oftentimes be a money mule for a criminal organization, but we can discuss that another time.
The blockchain usually reveals the first layer. Exchange records may reveal the second. The third may exist only in the nested service's internal ledger, if it exists anywhere at all.
A blockchain label reading “Exchange X” therefore does not necessarily mean the suspect held an account at Exchange X. It may mean the suspect transacted through a service that itself held an account there. Who controls the address, who owns the account, and whose transaction is being executed can be three different answers.
How we discover a nested service
The first indication is usually behavioral. An address that should look like an ordinary deposit address instead receives funds from hundreds or thousands of apparently unrelated sources: repetitive deposits from unrelated wallets, a mix of very small and very large amounts, automated or API-like timing, rapid consolidation and withdrawal, and volume that resembles a commercial operation rather than an individual customer. FATF flags many of the same characteristics, including very high transaction frequency, repetitive timing patterns, algorithmic counterparties, and high-volume third-party payments inconsistent with the declared account profile [2].
Volume alone proves nothing, though. Market makers, merchants, funds, and institutional trading accounts produce similar fan-in patterns. Commercial-looking activity is a red flag that demands a second layer of attribution work, not a conclusion by itself.
Should centralized exchanges allow nested services?
Because many nested relationships are commercially legitimate. Smaller exchanges and brokers often lack the capital, technology, custody infrastructure, or liquidity to operate independently. Plugging into a larger exchange lets them offer competitive pricing, fast execution, more trading pairs, and deeper withdrawal capacity. For the host, these relationships bring institutional customers, volume, and fees.
So nested services can be legitimate. The problem becomes the undisclosed, misclassified, or inadequately controlled nesting.
A VASP serving thousands of downstream customers should not be onboarded and monitored like a retail user, and a host exchange should not let a business receive third-party funds through a generic corporate account without understanding what that business actually does. FATF treats these VASP-to-VASP arrangements as analogous to correspondent banking relationships. Its guidance directs the host to understand the counterparty's business, customers, reputation, regulatory status, and AML controls, and, where downstream customers can transact through the account, to be satisfied that customer due diligence has been performed and that relevant information can be produced on request [1] [2].
So the right question is whether any CEX should permit a nested service to use its infrastructure without knowing that it is a nested service, and without preserving meaningful visibility into the underlying activity.
We don't believe it should.
A broken investigative chain
Consider what happens after illicit funds are traced to a host CEX. The investigator serves the exchange and asks who received the funds. The exchange responds that the address belongs to its platform, but the account was operated by another service, and the person under investigation is not its customer.
The investigator then approaches the nested service, which may be incorporated offshore, unlicensed, hidden behind an opaque corporate structure, reachable only through an app or a Telegram channel, and located in a jurisdiction where formal legal process takes months or years. Each party can then point at the other. The host says it never onboarded the underlying customer. The nested service says the blockchain address belongs to the host. The investigator is left holding an attributed blockchain endpoint and no identified human being.
This is not hypothetical. We see it at least once a week. FATF's 2026 report documents a case in which investigators identified proceeds entering deposit-wallet addresses at several global VASPs but could not obtain originator or beneficiary information: it was absent from the transaction data, and the relevant foreign VASPs and FIUs did not respond to requests [2]. In another case study from the same report, an FIU tracing a large investment fraud found victim funds channeled through layers of intermediary funnel addresses, with offshore VASPs serving as the final cash-out points. One VASP-linked wallet held roughly $600 million at the time of analysis [2].
“Not our customer” should not mean “we have no evidence”
A host CEX may genuinely lack KYC information for the nested service's end user. It should still hold significant evidence about its direct customer and the activity that ran through its infrastructure. At a minimum, an adequately controlled host relationship should preserve:
The nested service's legal entity, beneficial owners, controllers, and authorized users
Its licensing or registration status, and the jurisdictions and customer populations it serves
How the customer was classified: VASP, broker, OTC desk, merchant, or processor
Master accounts, subaccounts, linked accounts, and associated deposit addresses
Internal transfers, trades, conversions, and withdrawal records
API access and account-level access logs
Travel Rule information where applicable
Compliance alerts, enhanced due diligence, restrictions, and communications about the account's intended and actual use
The host does not need a live duplicate of every downstream customer's KYC file. It does need enough visibility to monitor the relationship meaningfully, plus contractual and operational mechanisms requiring the nested service to associate transactions with downstream customers and produce that information quickly when lawfully requested.
FATF's standard is directionally clear on this point: where another VASP's customers can transact through an account or custodial wallet, the host should be satisfied that downstream due diligence has been performed and that relevant information can be provided on request [1] [2]. Without that capability, transaction monitoring is largely cosmetic.
Is the host liable for illicit activity processed through a nested service?
There is no universal answer. Liability depends on the jurisdiction, the applicable law, the type of violation, what the exchange knew or should have known, the controls it maintained, and how it responded to warning signs. AML liability, sanctions exposure, criminal liability, supervisory enforcement, and private civil claims are separate questions, and a CEX is not automatically liable for every illicit dollar that moves through a nested customer's account.
But nesting is not a liability shield, and the enforcement record, or lack thereof, shows what unmanaged nesting costs.
FinCEN's 2023 consent order against Binance is the clearest example. The order describes how a single Enterprise User could open up to 1,000 subaccounts under a master account, Exchange Brokers could open an unlimited number, and until the end of 2021 Binance did not even require brokers to attest that they performed AML checks on their own subaccount customers. The result, in FinCEN's account, was the establishment of nested exchanges operating inside the platform without sufficient oversight [3].
Garantex operated as a nested exchange on a global tier 1 CEX from its inception in March 2019 until one month before OFAC designated it in April 2022. A blockchain analytics tool that the CEX itself used identified close to 100,000 transfers between Garantex and the CEX in that period, and Garantex conducted over $100 million in potentially suspicious transactions with illicit actors, including roughly $6 million tied to Conti ransomware, without the CEX reporting any of it. Even after the designation, tens of millions of dollars in Garantex transactions continued into 2023. Suex, designated by OFAC in 2021 for laundering proceeds from schemes including the Colonial Pipeline attack, ran through non-KYC accounts and subaccounts for years. BestMixer moved over $40 million in bitcoin through transactions of 1.9 to 2 BTC, structured to sit just under the platform's no-KYC withdrawal threshold [3].
Perhaps the most striking detail in the order: the CEX's own educational webpage defined nested exchanges and warned that they “often have lax KYC and AML processes or none at all,” supporting money laundering, scams, and ransomware payments. The company published that warning while nested exchanges operated on its own platform without controls [3].
Those findings arose in one enforcement matter and are not a universal liability formula. They do show the pattern regulators punish: failing to identify that an account is being used as a financial service, letting a VASP masquerade as a retail or ordinary corporate customer, ignoring activity inconsistent with the declared business purpose, and maintaining relationships with services whose records cannot be obtained.
Sanctions exposure is less forgiving. OFAC has stated that civil penalties may be imposed on a strict-liability basis, meaning a person subject to U.S. jurisdiction can face civil liability without knowing a transaction was prohibited [4]. A host exchange that cannot see through a nested account cannot reliably know whose transactions it is executing.
What investigators should do after identifying a possible nested service
If you need help with any of these, ask us, BlockchainUnmasked can help with identification and liaison with the CEX and nested service within hours.
First, stop treating the CEX label as final attribution. Instead of writing that the suspect sent funds to an account at Exchange X, write what the evidence actually supports: the funds were transferred to an address controlled by Exchange X, transactional evidence indicates the receiving account may have been operated by a third-party financial service, and the beneficial transactor cannot be determined from blockchain data alone. In expert work, that precision is often the difference between a report that survives cross-examination and one that does not.
Second, document why the account appears commercial. Counterparty count and diversity, transaction frequency, amount distribution, timing, consolidation behavior, conversions, withdrawal patterns, and any automated cadence.
Third, send an immediate preservation request to the host CEX, and ask for more than “who owns this address.” The request should cover:
The master account and every relevant subaccount
The direct account holder and beneficial owners
The customer's business classification, and whether third-party funds were authorized
Whether the exchange knew or suspected the customer was providing VASP services
The internal ledger entry associated with the transaction
All trades, conversions, internal transfers, and withdrawals following the deposit
API, login, IP, and device information maintained at the account level
Any downstream customer identifier associated with the transaction
Relevant compliance reviews, alerts, restrictions, and communications
Fourth, identify the nested operator. Websites, apps, corporate registries, licensing databases, terms of service, deposit instructions, support handles, referral links, archived pages, and customer complaints will often connect the on-chain infrastructure to a legal entity, its operators, and its jurisdiction.
Fifth, serve the nested service separately. Its records may be the only source that connects the host CEX transaction to the underlying customer: downstream KYC, account-opening data, order and trade history, deposit and withdrawal mapping, IP and device information, communications, and source-of-funds records.
Sixth, when direct outreach fails, use supervisory, FIU, and international-cooperation channels. FATF reports that authorities often get faster and more complete responses when requests are routed through supervisors or financial intelligence units rather than sent directly to an offshore VASP [2].
Finally, keep tracing beyond the label. The blockchain identifies the outer infrastructure. The decisive evidence usually lives in internal ledgers, subaccount records, conversion history, and downstream customer mappings.
Where nested services find their customers
Most do not advertise as nested services, and their customers rarely know or care that the backend liquidity comes from another exchange. What gets advertised is the product: fast swaps, low fees, minimal verification, local payment rails, access in restricted markets, and sometimes explicitly private or “anonymous” trading. FATF identifies localized websites, app-store listings, domestic payment rails, influencers, affiliate programs, and Telegram and WhatsApp groups as the channels through which offshore services solicit users [2].
This is also why blockchain analytics alone will not solve the problem. On-chain tools identify transaction behavior and infrastructure. Determining which business is operating inside the account usually requires OSINT, corporate intelligence, compliance data, and cooperation from the host exchange. FATF reaches the same conclusion: blockchain analytics support tracing and investigation but are generally insufficient on a standalone basis to identify offshore VASP activity [2].
The standard the industry and regulators should demand
Nested services are not inherently illicit. Invisible nesting is the risk.
A responsible host exchange should identify and verify every nested financial-service relationship, prohibit VASPs from operating through retail or misclassified accounts, confirm licensing, ownership, and downstream customer types, assess the nested service's AML and sanctions controls, require auditable customer-to-transaction mapping, monitor for undeclared nesting through behavioral analytics, and terminate relationships where adequate records cannot be obtained. That is consistent with FATF's risk-based controls for correspondent-style VASP relationships and with its 2026 recommendations to detect potential nesting and avoid relationships with unlicensed or unregistered providers [1] [2]. It is also worth noting how far the regulatory floor still has to rise: FATF found that under half of jurisdictions, about 46 percent, have adopted an activity-based approach to regulating VASPs at all [2].
Blockchain intelligence providers need more precise attribution models too. A single label identifying the host CEX is not enough. Where the evidence supports it, attribution should distinguish host infrastructure from nested service from unknown underlying customer, because that distinction determines whether investigators serve the right entity, request the right records, preserve evidence in time, and accurately explain what the blockchain does and does not prove.
“Funds went to a CEX” should never be treated as the conclusion of an investigation. Sometimes it tells us only who controlled the keys. It does not tell us who controlled the account, and it may tell us nothing about the person whose transaction was actually being executed.
A CEX label is a lead, not a final attribution. Liquidity can be rented. Compliance accountability cannot.
Legal note: This article is for general informational purposes only. It is not legal advice, and legal obligations and liability vary by jurisdiction and the facts of a particular matter.
Sources
[1] Financial Action Task Force, Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers (October 2021). See especially paragraphs 164-169 on VASP correspondent and nested relationships, counterparty due diligence, and access to downstream CDD information.
[2] Financial Action Task Force, Understanding and Mitigating the Risks of Offshore Virtual Asset Service Providers (oVASPs) (March 11, 2026). Cited for nested-service risk, commercial-account indicators, investigative case studies, marketing channels, international-cooperation practices, the activity-based regulation statistic, and private-sector recommendations.
[3] Financial Crimes Enforcement Network, Consent Order No. 2023-04, In the Matter of Binance Holdings Limited et al. (November 21, 2023). See Section II.E.3 (approximately pages 34-37) on subaccounts and nested exchanges, including Suex, Garantex, and BestMixer.
[4] U.S. Department of the Treasury, Office of Foreign Assets Control, Frequently Asked Question 65. Cited for OFAC's statement that civil penalties may be imposed on a strict-liability basis.
Links verified against primary sources: August 24, 2026.
