What makes a crypto Source of Wealth file reviewable

A crypto Source of Wealth file is reviewable when two things are true:

• Customer claim. The customer has stated what they say happened, before the data arrives.
• Supporting evidence. Every figure in that claim can be tested against something the institution can pull for itself.

That last phrase carries the weight: customer due diligence asks for a reliable and independent source, and a customer’s own export is not independent, however accurate it is.

Most crypto-related files that cannot be closed are not suspicious. They fail on one half of the pair or the other.

• No claim. Several thousand exported rows arrive with nothing stating what they are meant to establish, and without the list of addresses the customer asserts are theirs, which is itself a claim and the one the rest rests on. Evidence with no claim in front of it cannot be tested: there is nothing for it to confirm or contradict.
• Evidence that cannot carry the claim. Sometimes it is all there and the file still fails, for two reasons. Not independent. The data reached the institution through the customer, the one path that cannot corroborate itself.
• Too much, in too many places. Its volume and its spread across sources put it past what anyone can hold in their head and reconcile line by line. AI included.

The file goes back, more is requested, and both halves get worse: the claim is still missing and the evidence is larger.

The distributed data problem

A ten-year history spread across four exchanges, two of which have since closed, a hardware wallet, a period of DeFi activity and holdings on several blockchains with five addresses on each is not an unusual customer. In crypto it is mainstream.

That is one person, and something like thirty separate places where part of the answer is kept. No two of them record it the same way: different columns and date formats, different names for the same asset, different treatment of the fee, and different transaction types and sub-types for what turns out to be the same event.

The wealth behind it is frequently ordinary: salary saved, an asset bought early, held through two cycles, now being moved into the banking system for a house or a retirement.

A file that takes a week to even understand is competing for attention with mortgages, salary accounts and a business current account. It rarely loses on its merits. It loses because declining is cheaper than understanding it.

Why the claim is usually missing

Two reasons, and neither of them is the customer being evasive.

1. No clear ask

Source of wealth is a private banking discipline, and there it was never really a question. A relationship manager assembled it over years from a client they already knew, so by the time it had to be written down the answer had already accumulated. It has since arrived everywhere else, crypto included, as a request, which is a different instrument entirely: one message, sent cold, expected to return ten years. And the officer sending it is unlikely to know the mechanics of the asset being asked about, or that the answer is not held anywhere as a single thing. Private banking has the relationship and the process and is no further ahead on this than anyone else. The same goes for the person at the other end of the message: they have never been asked this before either, and nothing in the request tells them what a sufficient answer looks like. Ask a customer for proof of source of funds and they send the last transaction, correctly, because that is what was asked.

Very few requests say plainly: write down, in your own words, how this position was built.

2. The customer cannot see their own story

A Chinese proverb says you cannot see the true shape of the mountain while you are standing on it. The customer is the only source of the claim and, at the same time, the person least able to state it. No platform records which addresses belong to one person, why a transfer was made or what a payment was for, so the claim exists nowhere except in the customer’s own account of it. But they lived it as one continuous thing, a little here and a little there across ten years, and from the inside there is no main thread, only events. It takes an outside eye to see which of those events are the story and which are noise.

Why the evidence is rarely independent

The usual first response to a Source of Wealth request is a full transaction export from every platform the customer used, and, unfortunately, often enough that is what the request itself asked for. Either way it arrives in good faith, and either way it is the least useful thing in the file: the data reached the institution through the customer, so it cannot serve as its own verification, and eighty thousand rows with no claim attached is raw material rather than evidence. When the request names the export, that is the worse case of the two, because the file is shaped wrong before anyone starts and the institution has asked for the one thing it cannot rely on.

What independence takes differs sharply between the two kinds of source.

On-chain, it is straightforward. Addresses can be queried directly, on a public block explorer or through a node, so the institution retrieves the movements itself and never has to rely on what was handed over. The difficulty is not access, it is shape: every chain records transactions differently, transaction types do not correspond between them, and all of it still has to be fitted into one story alongside the exchange activity.

At the exchanges it is harder, because the export is the only artefact and the customer is the one producing it. There are two ways out. The institution can witness the extraction, asking the customer to pull the file in front of them, or to demonstrate on the platform that a given transaction is really there. That works, and it is sometimes the only option, but it is laborious for both sides and it does not scale past a handful of checks.

The better route is a read-only API key: the customer generates a key on the exchange that can read the account and nothing else (it cannot trade and it cannot withdraw), and the institution pulls the history through it. Access can be revoked by the customer at any point. The path changes, and the independence comes with it.

What handling crypto data takes: three jobs

Long before any of this becomes a problem of judgement, it is a problem of processing large data volumes from many places. Handling that data is not one job but three.

• Extraction. The one that looks like engineering, and the easiest of the three, though easiest is relative: useful coverage starts at around fifty blockchains and fifty exchanges, and each of them has to be built and then kept working.
• Digestion. Where an in-house build stalls. The data arrives in as many formats as there were sources, and until it has been normalised into one structure nothing can be reconciled against anything else.
• Interpretation. Harder again, and the one that has to hold up when the figure is questioned a year later.

Few institutions are in a position to build all three, and two out of three is of no use.

Data sets this size have to be handled the way any other regulated calculation is handled: by software that applies the same rules to the same inputs and returns the same answer every time, with the working available for anyone who asks how a figure was reached. Deterministic, in other words, and reproducible on demand. A reviewer cannot defend a number they cannot reproduce, whoever or whatever produced it.

Whether a language model can stand in for that is a question of its own, taken up in what AI can and cannot do in a Source of Wealth review.

What a reviewable customer claim contains

A five-page executive summary, with a cover in front of it and an annex behind it, its pages in the order a reviewer reads them. What is held, what is being asked for, and the customer claim in their own words. The wallets, accounts and movements: which addresses and which platform accounts the customer asserts are theirs. The origin of the wealth. How the wealth was created. Significant events and open points, including the illicit activity screening already run and whatever the customer cannot prove.

The last of those five is the one that distinguishes a considered file from a defensive one. A gap the customer identifies is a conversation. The same gap found by the reviewer is a different file entirely.

Customers who ask what to submit can be pointed at a worked example of those five pages, published openly by CashoutReady, the consumer service ChainComply runs, which shows the structure with model wording for each part.

Five things the accompanying evidence has to let you test

Assume the customer claim is on the table and the data has been interpreted. Only now can the analysis start, and these are the areas it has to cover before a judgement can be reached, in the order they are usually needed.

• The scope. Whether the claim covers all of it: every address, every wallet, every platform account. Without this, completeness cannot be assessed at all, because an incomplete history and a complete one look identical on the page. Only one of them balances.
• The reconciliation. Two passes, in this order. First the balances against the transactions: what each address and account holds today has to be what the movements produce. Then the fiat: every amount that crossed between the banking system and the crypto holdings, in both directions, matched against a statement.
• The gain, and anything the holdings earned. In most files the larger part of the position was never paid in. It is appreciation on what was bought, together with whatever the holdings produced while they were held: staking and mining rewards, lending yield, airdrops.
• The origin of external arrivals. Value that entered from outside that scope, rather than from the customer’s own money: a transfer from a third party, an inheritance, the proceeds of a sale. Each one needs a named basis rather than a category.
• The screening result. Run by the institution itself, against one of the established blockchain analysis tools. A customer cannot produce this and should not be asked to.

Then the conclusion

The five answers only mean something added back together. Contributions in, plus the gain and whatever the holdings earned, plus every external arrival with a named basis, has to account for the position in front of you, with no unresolved screening hit standing against any part of it. Where it does, the claim is supported and the file closes on what the customer said. Where it does not, the unexplained difference is the finding, and its size is what decides whether the file closes with a note against it or does not close at all.

Where collection is not enough

The main question the financial institutions ask: which addresses belonged to the customer, and what each transfer was.

That is a reconstruction problem rather than a collection problem. Ownership itself is easier to confirm than it first looks, once the set of wallets is complete, because a complete set is interlinked and the pieces check each other. Where they do not, that is itself the signal that something is still outside the list.

The main value of a good Source of Wealth document is to be able to ask good questions: it reduces a ten-year history to the few points where an answer is still needed. And a customer who cannot answer one of them is not necessarily choosing not to disclose something. Ten years is long enough to have genuinely forgotten.

Reconstructing a crypto history deterministically, at that volume, and showing the working behind every figure, is what ChainComply was built to do.