Working with service providers

On-chain tracing usually ends at a service: an exchange, a custodian, a stablecoin issuer, a payment processor. From there, the evidence that identifies people and shows where value went next sits in the provider's own systems. Getting it depends on asking the right provider, at the right time, for exactly the right records, and then reading the answer with the same skepticism applied to any other source.

What providers can hold

Different providers see different parts of a transaction. Knowing who holds what avoids wasted requests and missed sources.

The legal threshold usually rises with sensitivity: subscriber data is easier to obtain than traffic data, which is easier than content. The lesson Legal authority and international cooperation covers the instruments.

Preservation first

Providers keep logs for limited periods, and some purge closed accounts. A preservation request asks the provider to freeze a copy of specified records until a production order arrives. It is cheap, fast and often the only way to stop data from disappearing while the formal request is prepared.

Send preservation as soon as an account is identified, not when the production order is ready. Ask the provider to confirm in writing what has been preserved and until when, and diarize the expiry date. If the case needs the funds stopped as well as the records kept, send a separate voluntary freeze request citing the evidence that the funds are proceeds of crime; providers decide freezes under their own terms of service and legal duties.

Drafting a precise request

Providers search their systems by identifier. Vague requests produce delays, partial answers or refusals. A good request has three parts.

• Identifiers: every address with its chain and asset, every txid with its timestamp and amount, account IDs, email addresses or usernames if known.
• Period: start and end in UTC, wide enough to capture account opening and later activity.
• Fields: the specific records wanted, rather than "all information".

PRESERVATION REQUEST  ref CF-2026-0147/P-01  sent 2026-03-04 11:02 UTC
To: Exchange K, law-enforcement response team
Legal basis: [order or power, with reference]   Non-disclosure requested: yes
Identifiers:
  - Deposit address TQx7…4mPa (Tron network, USDT TRC-20)
  - Incoming txid 7b2f…d9e0, 2026-03-04 07:13:52 UTC, 9,800.00 USDT
Period: 2026-02-01 00:00 UTC to date of response
Preserve, for every account linked to these identifiers:
  - KYC record and documents; registration and login IP logs with ports
  - Device and session identifiers; linked bank accounts and cards
  - Internal ledger: deposits, trades, internal transfers, withdrawals
  - Withdrawal addresses and txids; Travel Rule data sent or received
  - Communications with the account holder
Contact: [name, role, official phone and email]

The request names the network as well as the address, because the same address format can exist on several chains, and gives the incoming txid so the provider can find the account even if the address was reassigned. It asks for IP logs with source ports, which shared addresses at the internet provider may need. It asks for every linked account, since one person often holds several. It states non-disclosure explicitly and gives an official contact, so the provider can verify the requester.

Common errors include wrong or truncated addresses, local times without a time zone, missing chain names, and requests for "all transactions" that return a summary instead of the internal ledger.

Portals, verification and emergencies

Many large providers run law-enforcement portals or dedicated mailboxes and publish guidelines on what they need. Using the published channel is faster than general support addresses and creates an auditable record. Providers verify that a request comes from a genuine authority; criminals have impersonated police with forged emergency requests, so expect checks and send requests from official accounts.

Most providers have an emergency disclosure procedure for imminent risk to life or serious harm, and the Second Additional Protocol adds direct orders for subscriber data and an emergency channel between states where it applies. In most other cases, a formal order or request is needed before records are produced.

Non-disclosure and tipping off

Some providers notify customers of law-enforcement requests unless prohibited, and a frozen account tells its holder that something has happened. Ask for non-disclosure in every request, cite any legal basis for it, and ask the provider to say if it cannot comply. Time freezes and requests so they do not alert a subject before devices are seized or other accounts are preserved. Providers have their own duties not to tip off customers about reports they file, covered in the IDFE-CC lesson Suspicious transaction reporting obligations.

Reading the response critically

A provider return is a source to be tested, not a conclusion.

• Authenticate it. Record how it arrived, hash each file on receipt and keep any certificate or declaration from the provider's records custodian. The lesson Exchange and cloud accounts as evidence covers authentication in depth.
• Check time zones and units. Exports mix local time and UTC, and amounts may be rounded or shown net of fees.
• Check completeness. Compare row counts and date ranges with what was asked for; note what is missing and ask.
• Treat identity as a claim. KYC data may belong to a money mule, a stolen identity or a purchased account. An IP address may belong to a VPN or Tor exit.
• Reconcile with the chain. Every on-chain deposit and withdrawal in the return should match a real transaction.

-- Provider withdrawals with no matching on-chain transfer
SELECT w.withdrawal_id, w.txid, w.to_address, w.amount, w.completed_utc
FROM provider_withdrawals AS w
LEFT JOIN chain_transfers AS c
  ON  c.txid = w.txid
  AND c.to_address = w.to_address
  AND c.amount = w.amount
WHERE c.txid IS NULL;   -- unmatched rows need an explanation

The query joins the withdrawals listed by the provider to transfers decoded from the examiner's own node data, on txid, destination and amount. Rows with no match need an explanation. Common reasons are internal transfers to another customer, which have no txid at all, amounts recorded gross of the network fee, or a withdrawal on a different chain from the one queried. Amounts must be in the same units on both sides; some engines need an explicit decimal type or a small tolerance for this comparison to work. An unexplained mismatch is itself a finding and should be put to the provider.

A worked return

Exchange K answers the production order for case CF-2026-0147 three weeks later. The examiner reads it against the questions in the scope statement.

1. KYC. The account was opened eight days before the first victim payment by a 20-year-old student living in another country. The identity may be genuine and still not belong to the person running the scam: the profile fits a recruited money mule. Recorded as "account holder of record", not "suspect".
2. IP logs. Registration came from a residential address in the holder's country; almost all later logins came from addresses in a commercial hosting range. That suggests a VPN or a remote operator and is a new lead for a request to the hosting company.
3. Ledger. The 9,800 USDT was frozen after the preservation request, but 31,200 USDT from earlier payments left in four withdrawals. Three match on-chain transfers to new addresses; the fourth was an internal transfer to another Exchange K account, invisible on-chain.
4. Next steps. A second request for the receiving account, a new trace from the three withdrawal addresses and a request to the hosting provider go into the plan.

The return answered one question and opened three. That is normal, and the case file should show each new lead and where it came from.

Exam focus: which records exchanges, custodians, stablecoin issuers, hosting, telecom and other providers can hold, and their limits; preservation first and confirming its expiry; separate voluntary freeze requests; the three parts of a precise request (identifiers with chain and timestamps, period in UTC, specific fields); law-enforcement portals, requester verification and emergency procedures; requesting non-disclosure and avoiding tipping off; authenticating returns, checking time zones and completeness, treating KYC and IP data as claims; reconciling provider records with on-chain data; turning a return into new leads.