A request goes out for source of funds or source of wealth documentation. What comes back is a folder: screenshots of an exchange dashboard, a PDF of a portfolio page, four CSV files in three different shapes, and a covering e-mail that explains none of it. Nobody did anything wrong. The customer sent what was asked for.
When the question is weak, the answer is usually weak too. In most cases the quality of the question determines the quality of the answer, and in a crypto file that is not a rhetorical point. The request letter decides how much of the case can be verified at all.
Two questions, and only one of them is the letter’s job
Screening answers where the coins moved and whether an address carries exposure worth acting on. Source of wealth answers where the first money came from and how the balance was built. Both belong in the file, neither substitutes for the other, and only the second is something a request letter can obtain, because the first runs inside the institution against data it already holds.
Merging them produces the two failure modes that show up on review. A clean screening result read as an answer, no flags so approve, when the absence of a flag is evidence of nothing. And a flagged address read as a verdict, when a flag is an opening position to be worked down with evidence rather than a conclusion.
So keep them apart in the letter. Ask the customer only for what the customer alone can supply, run the screening yourself, and let the file record both and say which is which.
Ask for source-authenticated history, not files
An export the customer produced is an artefact of the customer. It can be edited, it arrives in whatever shape that platform happened to use that year, and nothing in it can be checked against the venue it claims to describe.
A client-authorised connection does two things in one move. Setting it up is strong evidence that the customer controls the account, because nobody else can authorise it. And it delivers the history from the venue rather than from the customer: all trades, but most importantly all deposits and withdrawals, both fiat and crypto. Read-only by construction, granted for the review and withdrawn at the end.
The security design matters as much as the data, and it is the institution’s to own rather than the customer’s to improvise. Ask the customer to confirm that source-authenticated access can be provided, then name the channel it comes through when you want it. A letter that invites credentials to arrive by e-mail has created a second problem while solving the first, and the customer who obliges has done nothing wrong.
Ask for the list, not the data
For self-custody the request is a list of addresses, including the ones that are empty and the ones the customer stopped using. Ask for the network alongside each address rather than the address alone: a bare list makes whoever opens it work out which chain every entry belongs to before anything can be looked at, and customers will supply the pair without complaint if the letter asks for it.
The chain is public, so with those pairs in hand the history is reconstructed independently, from a source no party to the review controls and nobody can edit after the fact.
Where the surrounding history does not establish control well enough for policy, that is the moment to ask for a signed message, a small verification transaction or whatever method the institution accepts. It is a fallback, not an opening request: asking every customer to sign every address turns a five minute answer into a fortnight.
Worth asking for and worth not insisting on: a wallet’s extended public key, which exposes every address it has generated and is what makes a proper look at the counterparties possible. A customer who declines it for privacy and offers named addresses instead has given a reasonable answer, and where the part held back does not bear on the conclusion, taking it is the proportionate call.
Asking a customer to export their blockchain history is asking for a worse copy of something already freely available, and it introduces a document that can disagree with the chain it was copied from.
Ask for the whole set, or the arithmetic breaks
There is a reason the request has to cover every account and every address rather than the ones the transfer touched. In crypto, funds move constantly between the customer’s own venues: exchange to wallet, wallet to exchange, exchange to exchange. Treat those as external inflows and outflows and the case becomes confusing very quickly, and confusing in a specific direction. Wealth appears to arrive from nowhere, disposals appear that never happened, and the totals stop meaning anything.
A partial list does not produce a partial answer. It produces a wrong one, and the error is invisible until somebody adds the missing account. That is the practical argument for asking about the empty wallet and the closed account: not completeness for its own sake, but because every movement left outside the set is counted as something it was not.
Ask for what the data cannot show
Some things no key and no address will ever produce, and these are the documents worth assembling carefully: a loan agreement, a deed of inheritance, a written gift record with the giver’s own trail behind it, an OTC contract naming the counterparty, an invoice where the customer was paid in crypto.
Fiat that never crossed a bank rail belongs in the same category and is the one most often left out of a letter. Crypto ATMs, card purchases, prepaid vouchers and cash all put value on chain without producing a statement anybody can pull. What survives is an ATM receipt, a line on a card statement, a voucher record, or nothing at all, and a customer who is not asked about these will not think to mention them.
Three areas deserve their own question rather than a general one.
Leveraged trading, because margin and futures data is thin or absent in most exchange feeds and reconciles against nothing. Only a handful of platforms return it whole. Where it is material, expect it to be worked by hand and price that into the file rather than into the customer’s patience.
Anything that went into a contract. Documenting a DeFi history is awkward every time, and not because of the swaps, which are legible enough. It is the stretches where value left the customer’s wallets and sat somewhere else: staked, lent, supplied to a pool. The rewards surface when they are paid; what was committed, where, and for how long does not, and that is the part that has to be reconstructed rather than read.
Any platform that has since closed, where nothing can be connected to and the surviving evidence is a bank statement, an e-mail and an on-chain arrival. For those, ask the customer to build the two lists that can still be built:
- Fiat movements in and out: date, bank, amount.
- Crypto movements in and out: date, network, the address at the other end, amount.
Those lists are the reconstruction, and a customer who produces them has done work no request for an export could have obtained.
Ask about tax where it answers a question you have to ask anyway
The reason for asking is not curiosity about the customer’s tax affairs. Tax crime is a predicate offence, so wealth that was never declared is, on that reading, proceeds. An institution that documents everything else and never looks at this has left one of the commoner predicate offences unexamined.
That makes the question narrow. Does what the customer declared line up with what the reconstruction shows they held and realised? A return is not evidence of provenance, since it shows only that a figure was declared, which is a different claim. But it is a statement the customer already made to somebody else, with consequences attached. Agreement corroborates the reconstruction from a party with no interest in flattering anyone. Disagreement is the most useful finding in the file, and which of the two is wrong is worth settling before a conclusion is written.
Ask conditionally and say so in the letter, because an absent return is not an absent answer. A holder who bought and never sold may have had nothing to declare, and in several jurisdictions a long enough holding period means nothing is owed at all. An absent return with nothing written beside it is the different case, and a customer who reads a flat demand for tax returns will either send something irrelevant or go quiet.
One thing belongs in the process rather than the letter. The same connected data that produces the reconstruction can produce the tax computation, and where both come out of one set of inputs the two documents in the file cannot disagree about what happened.
And one boundary, because the two sit close together. Testing whether the declared position is consistent with the evidence is squarely inside the remit. Adjudicating the tax position is not, and a letter that drifts into it has taken on a liability nobody asked it to carry.
Ask where it went, not only where it came from
Requests of this kind are written almost entirely about value arriving. The duty is not. Material transfers out to an address or an account the customer does not control are a separate question, and the one most often missing from a letter that is otherwise thorough: what left, to where, and on what basis.
It is not a source of wealth question and it should not be dressed as one, which is also how to ask it without the customer hearing an accusation. It is the destination side of the same file, it is routine, and a large payment out with nothing written beside it becomes a late question in a case that was otherwise finished.
Two related things belong in the same paragraph of the letter. The exit itself: which assets were sold, where, on what date, and the instruction that follows, including whose account receives it. And the route, because proceeds arriving by a path nobody can follow - a peer to peer platform, a card, someone else’s account, or a run of small transfers where one would have done - changes the shape of the review whatever the underlying story turns out to be.
Ask whose accounts these actually are
An account opened by a partner, a parent or a friend because they already had one is a common and usually innocent arrangement, and it is not one file. Each person whose account carried the value has their own position to explain, and discovering that late means reopening a case that had reached a conclusion. One line in the letter settles it at the start.
Ask for the claim, and ask for it first
Customers forget wallets and exchange accounts, deliberately or not, including ones that still hold funds. The fastest route to a complete picture is not a better tool. It is a question asked early, because the customer either clarifies the position or reveals the inconsistency, and both outcomes move the file.
What matters afterwards is where the answer goes. It should not stay in an e-mail thread. It belongs in the file, attached to the transaction it explains and marked as verified or not verified, because that is what makes the reasoning survive the analyst who wrote it.
The duty is not new. The date is.
Higher-risk cases already require enhanced due diligence, in the EU, the UK and the United States alike. What is changing is how much room is left for a conclusion nobody can retrace.
From 10 July 2027 one directly applicable EU rulebook replaces much of the national variation, and Article 34(2) requires obliged entities to examine the origin and destination of funds involved in, and the purpose of, any transaction that is complex, unusually large, conducted in an unusual pattern, or without apparent economic or lawful purpose. The UK and the US frame the same obligation in their own terms. What is common to all three is the expectation that an institution can show how it reached its conclusion.
For crypto that is where the work sits. Screening the final wallet, or the transaction that reaches the bank, does not explain where the wealth came from. Answering that takes the activity across exchanges, wallets and years, which is a question about the request letter before it is ever a question about the analysis.
What the wrong request costs
A medium-risk crypto client requiring manual review takes between 4 and 20 hours of analyst time. A high-risk one takes between 20 and 200. None of that budget is saved by a request letter that produces an unusable answer; it is spent twice, once on the folder that arrived and once on the follow-up that should have been the first letter.
What the file has to answer at the end
Four questions, for a manager, for internal audit, for a supervisor, or for the next analyst who opens the file in six months. What was reviewed. What was explained. What was still uncertain. And why the decision was reasonable.
A request letter that cannot produce answers to those four is where the problem starts, and it is cheaper to fix there than anywhere downstream.
One practical note. Holders who prepare their own evidence meet this list from the other side, and what they are advised to offer, and advised not to send unasked, is published openly in the 12 documents your bank will ask for, by CashoutReady, the consumer service ChainComply runs. A letter that asks for something the customer has already been told to prepare is a shorter conversation than one that does not.