Exchange and cloud accounts as evidence

Most investigations that start on-chain end at a service: an exchange that knows who withdrew the funds, a cloud account that holds the backup, an email inbox full of deposit confirmations. Records from these providers often carry the identity and the intent that the blockchain cannot show. But a spreadsheet from an exchange is not self-proving: the examiner must know where it came from, whether it is complete, what each column means and whether it agrees with the chain. This lesson covers what provider records contain, how to authenticate them, how to handle live account access, and how to reconcile provider data with on-chain data.

What exchange and custodial records contain

How to request records is covered in the lesson Working with service providers; this lesson starts when the response arrives. A typical production from an exchange or custodian holds:

Records can arrive in three ways, with different evidential weight. Provider productions answer legal process and come with the provider's provenance. User exports, such as statements a suspect downloaded or a victim provides, are found on devices or handed over and must be checked against the provider. Live captures are records an investigator collects by logging in under authority or consent. A finding should say which kind it rests on.

Authenticating provider records

Authentication means showing that a record is what it claims to be and has not changed since it was produced.

1. Provenance. Record who requested the data, under which authority, through which channel (a law-enforcement portal, secure transfer, physical media), who received it and when.
2. Integrity on receipt. Hash each delivered file immediately, store the original unmodified and work on copies. If the provider supplies its own hashes, compare them.
3. Attestation. Many providers can supply a declaration from a records custodian describing how the records are created and kept in the ordinary course of business. Whether one is needed, and in what form, depends on the jurisdiction; asking for it costs little.
4. Meaning. Obtain a data dictionary: which time zone timestamps use, whether amounts are gross or net of fees, what each status code means, how internal transfers are shown.
5. Completeness. Check that the period, accounts, assets and record types requested were all delivered, and that opening balance plus movements equals closing balance.

Spreadsheet software causes avoidable errors. Long numeric identifiers can be converted to scientific notation, leading zeros dropped, amounts rounded and dates reinterpreted in local formats. Import provider files into an analysis tool or database as text, convert deliberately, and keep the conversion steps.

Live account access and API records

Sometimes investigators access an account directly: with a victim's consent, with credentials found during a lawful search, or through an exchange's API. Data reached this way may be stored abroad. The Budapest Convention, Article 32, allows a party to access stored data located in another party with the lawful and voluntary consent of the person who has lawful authority to disclose it, and to access publicly available data; beyond that, the routes in the lesson Legal authority and international cooperation apply. Where a production order is available, it usually gives stronger provenance than a login.

If live access is used, document it as a live action: screen recording of the session, the time, the account, every export downloaded with its hash, and for API calls the endpoint, parameters and raw response saved unaltered. Take care not to change the account: no trades, no setting changes, no password reset that alerts the holder, and no actions that would breach a provider's non-disclosure arrangements.

Reconciling provider records with on-chain data

A provider record and the blockchain are two independent sources about the same events. Reconciling them tests both, and a reconciled record is far harder to challenge than either source alone. The core check for withdrawals joins the provider's rows to the unit's own chain data:

-- Reconcile provider withdrawals with on-chain outputs (UTXO-style tables)
SELECT w.withdrawal_id, w.txid, w.to_address, w.net_amount_btc,
       o.value_btc, b.block_time_utc,
       CASE
         WHEN w.txid IS NULL THEN 'NO_TXID'
         WHEN t.txid IS NULL THEN 'TXID_NOT_ON_CHAIN'
         WHEN o.txid IS NULL THEN 'ADDRESS_NOT_IN_TX'
         WHEN o.value_btc <> w.net_amount_btc THEN 'AMOUNT_DIFFERS'
         ELSE 'MATCHED'
       END AS status
FROM provider_withdrawals w
LEFT JOIN transactions t ON t.txid = w.txid
LEFT JOIN outputs o ON o.txid = t.txid AND o.address = w.to_address
LEFT JOIN blocks b ON b.block_height = t.block_height
ORDER BY w.requested_utc;

Each withdrawal row is matched first to the transaction by txid, then to the output paying the stated address, then to its block for the confirmed time. Left joins keep provider rows that do not match, and the CASE expression sorts them into explainable categories instead of dropping them. Amounts are compared net of the provider's withdrawal fee, which is why the data dictionary matters. On account-model chains the output join becomes a join to transfers or token-transfer logs, with a log index in place of the output.

A worked reconciliation of five withdrawals from one account:

Every row ends either matched or explained. W-103 is typical: internal transfers between customers of the same service are entries in the provider's ledger, so the provider's records are the only evidence of them (see the lesson Tracing through custodial services). W-104 shows why a batch transaction must not be attributed wholesale to one customer. Deposits are reconciled the same way, remembering that providers later sweep deposits to hot wallets. Time differences should be explained by the provider's time zone and the gap between request, broadcast and confirmation.

Cloud accounts as evidence

Cloud services hold what users want to keep safe or in sync: photos of seed phrases, wallet backups, spreadsheets of addresses, password-manager vaults, notes, and email with exchange notifications for deposits, withdrawals, logins and KYC steps. These records are obtained and authenticated like exchange records: preserved early, produced under authority, hashed on receipt and checked for completeness.

The 2016 Bitfinex hack shows the value of combining them with chain data. Under a search warrant, investigators obtained a file from a cloud storage account and decrypted it. It listed about 2,000 virtual currency addresses with their private keys. Blockchain analysis tied almost all of those addresses to the theft, and on January 31 and February 1, 2022, authorities seized about 94,636 BTC from them. The cloud file supplied control and a link to its holder; the chain confirmed that the addresses were the stolen funds. Neither source alone would have carried the same weight.

Exam focus: what exchange records contain (KYC, ledger, deposits, withdrawals, trades, access logs, fiat rails) and the forensic use of each; provider productions vs user exports vs live captures; the five authentication steps (provenance, integrity on receipt, attestation, meaning, completeness) and spreadsheet pitfalls; documenting live and API access and the consent route of Budapest Convention Article 32; reconciling withdrawals by txid, address, net amount and time; explaining internal transfers, fees, batches and canceled requests; cloud accounts as sources of keys, backups and notifications; the Bitfinex case as an example of cloud and chain evidence combined.