Tracing through custodial services

Most traces end, at least for a while, at a custodial service: an exchange, broker, custodial wallet, payment processor or gambling site. That boundary is where the investigation often becomes winnable, because the service holds records and can freeze funds, and also where weak reports overreach. This lesson covers how to evidence that funds entered a service, what can and cannot be said about the inside, when to stop tracing and request records, and how to resume the trace from the withdrawal side.

Evidencing the service boundary

The IDFE-BA lesson Following value through exchanges and services explains deposit addresses, sweeps, hot wallets and omnibus addresses. The forensic question is narrower: on what basis do you say that an address is a deposit address of a particular service, and how strong is that basis?

Record the attribution basis as its own entry, with its source and the date it was retrieved, so that the hop record can cite it (see the lesson Attribution sources and their reliability). Using the grades from the lesson Tracing to an evidential standard, the flow into the address is usually grade A while the claim that the address belongs to a service is grade C until the service confirms it.

Inside the black box

Once funds are swept into a service's pooled wallets, the customer's money becomes an entry in a private ledger. Inside that ledger the customer can trade into other assets, transfer to another customer's account without any on-chain transaction, withdraw to a bank account, or withdraw crypto that came from somebody else's deposit. None of this is visible on chain. Applying FIFO or haircut through a hot wallet produces numbers, but they describe the rule, not the service's books.

The left column is what a forensic report states. The right column needs records.

When to stop and request records

Stopping on-chain work at a service is a decision, and the case notes should record when and why it was taken. Stop and request records when:

1. the funds have entered a custodial service on a stated basis, ideally grade B or C;
2. further on-chain work could only produce inferences about the inside;
3. the funds may still be in the account, so delay costs recovery;
4. the request package is ready: deposit addresses or tags, txids with output or log references, amounts in base units, UTC times, the path, the method and the grades.

Preservation and freeze requests go first, because a balance in a hot wallet can leave within minutes; analysis continues in parallel. Drafting the request is covered in the lesson Working with service providers. From a tracing point of view, ask for what you need to resume the trace: the account's complete internal ledger for the period (deposits, trades and conversions, internal transfers to other accounts, fiat and crypto withdrawals), and for every crypto withdrawal the asset, chain, amount, fee, destination address, txid and time with its time zone. Ask also for other deposit addresses assigned to the account, saved withdrawal addresses, and accounts linked by device, IP address or payment instrument. Request machine-readable exports.

Withdrawal-side analysis

When records arrive, the trace resumes from the withdrawals. Continuing the case: Exchange K reports that the 1.2 BTC deposit was credited, that the account also held other funds, and that it made these withdrawals:

Each reported withdrawal is first checked against the chain before anything is built on it:

-- Check reported Bitcoin withdrawals against on-chain outputs
SELECT r.record_id, r.txid, r.dest_address,
       r.amount_sat                AS reported_sat,
       o.value_sat                 AS onchain_sat,
       r.amount_sat - o.value_sat  AS difference_sat,
       b.block_time
FROM provider_withdrawals r
LEFT JOIN outputs o ON o.txid = r.txid AND o.address = r.dest_address
LEFT JOIN blocks  b ON b.block_hash = o.block_hash
WHERE r.chain = 'bitcoin'
ORDER BY r.requested_at;

The left joins keep every record even when no matching output exists. Suppose W-1 returns an on-chain value of 49,990,000 satoshis, a difference of 10,000 that matches the exchange's published withdrawal fee: the record reports the amount before the fee. Suppose W-3 returns no output: the txid exists but pays a different address. That is a discrepancy to put back to the service, not to fix silently. W-2 is checked the same way against Tron token transfers. Authenticating provider records more fully is covered in the lesson Exchange and cloud accounts as evidence.

Three points follow. First, a withdrawal confirmed by both record and chain is a grade B link between the account and the destination. Second, the conversion into USDT on Tron is visible only in the records; the trace has changed asset and chain inside the black box. Third, the internal ledger is itself a mixed account: the 1.2 BTC was credited to an account holding other funds, so how much of each withdrawal is victim value is again an allocation question, computed over the ledger entries with a declared method (see the lesson Tracing methods and their consequences).

Timing and amount correlation

Without records, or while waiting for them, examiners often look for a withdrawal that resembles the deposit. This is an inference, grade D, and its value depends on how many alternatives exist. In the case above, the service's hot wallet made 212 withdrawals in the hour after the deposit, nine of them between 1.15 and 1.20 BTC. A candidate set of nine is a lead to prioritize, not a link.

Correlation also fails in exactly the cases that matter. The records show withdrawals of 0.5 and 0.3 BTC and a conversion into a stablecoin withdrawn on another chain; an amount-and-time search for about 1.2 BTC would have pointed confidently at an unrelated customer. Use correlation to frame questions to the service ("please confirm the account behind deposit bc1q…dx7e and its withdrawals between 14:00 and 16:00 UTC"), and report it, if at all, with the size of the candidate set and the window used. The IDFE-BA lesson Confidence, uncertainty and language shows how to count candidates.

Pooled services and payment processors

Not every custodial service is an exchange, and some need more than one request.

• Nested services: a broker, swap desk or smaller exchange that holds an account at a large exchange. The large exchange's records return the nested service, and a second request to it is needed, often in another jurisdiction (see the lesson Legal authority and international cooperation).
• Payment processors: many generate a fresh address for each invoice and sweep to their own wallets. Their records identify the merchant and the order; the merchant may then hold the buyer's details, which means a second request.
• Custodial wallets, gambling sites and OTC desks: pooled like exchanges, with records that vary from detailed to thin. A service without identity checks can still hold IP addresses, device data, email addresses and withdrawal destinations.

For each, document the boundary in the same way: the basis for the service attribution, the exact deposits, the time-critical requests sent, and what the records later added. The trail is broken on chain, but it is not broken in the case file.

Exam focus: grading the claim that an address is a service's deposit address (records, self-published lists, forwarding to a well-attributed hot wallet, labels with and without provenance); which statements about funds inside a service are and are not supported by on-chain data; criteria for stopping on-chain work and requesting records, with preservation and freezing first; the ledger and withdrawal fields needed to resume a trace; checking reported withdrawals against the chain and handling fee differences and discrepancies; treating the internal ledger as a mixed account; amount-and-time correlation as a grade D lead with a stated candidate set; nested services and payment processors needing a second request.