Chain Analysis From the Reviewer’s Side: What a DD Analyst Actually Sees

An applicant usually imagines a due-diligence analyst reading a block explorer the way the applicant does: transaction by transaction, input by input, with a coffee and a growing collection of browser tabs.

That is rarely the first view.

A commercial blockchain-analytics platform can turn addresses and transaction identifiers into a graph, group addresses into clusters, attach entity or service labels, calculate forms of exposure, apply an institution’s alert rules, and place the result in a case queue before a human analyst writes the first note.

That interface is powerful. It is also not the chain itself.

The public ledger records transactions. The platform adds structure, attribution, categories, confidence, and risk logic. The institution adds its own tolerance and escalation rules. The analyst then has to decide which facts are direct, which are inferred, and which questions the applicant must answer.

For a Citizenship by Investment (CBI) file, a legal route through which a sovereign state may grant citizenship after screening and a qualifying contribution or investment, the practical goal is not to make the graph look pretty. It is to make the lawful origin, control, purpose, and route of the specific funds legible when the graph raises a question.

The First Screen Is A Filter

The first result is designed to sort work, not finish it.

Depending on the platform and configuration, the reviewer may begin with a wallet, transaction, customer, entity, or alert. The screen can show balances and flows, incoming and outgoing counterparties, attributed services, risk categories, transaction amounts, dates, direction, direct or indirect exposure, cross-chain movement, and prior alerts.

Chainalysis Reactor describes a graph-based investigation workflow that follows funds, connects on-chain activity with attributed real-world entities, and carries alerts, risk scores, and entity context from transaction monitoring into deeper review. TRM Wallet Screening describes categories for ownership, counterparty, and indirect risk, with attribution sources and confidence visible to the reviewer. Elliptic Lens describes wallet and transaction screening with configurable rules, explainable risk scores, continuous monitoring, and a logged case queue.

Those are vendor descriptions of their current products, not proof that a particular CBI authority uses any named tool or setting. Programs, banks, due-diligence firms, and settlement providers choose their own vendors and workflows. Some use more than one data source. Some receive a report rather than direct platform access.

The shared point is the operating model. Automated analysis finds patterns and prioritises questions. A reviewer still needs a documented basis for clearing, escalating, or refusing the case.

Labels Come From Different Kinds Of Claim

A label can feel definitive because it appears inside a polished interface. Ask what kind of claim created it.

An exact transaction identifier or address is a ledger fact. A grouping of addresses into one cluster may come from a heuristic or service-specific pattern. An assertion that a cluster belongs to a named exchange, merchant, service, threat actor, or person adds attribution data. An assertion that a person operated the service adds another layer.

Chainalysis now makes this separation explicit in its public paper Defining the Cluster. It distinguishes address grouping, entity attribution, and operator determination because each operation has a different evidence standard and a different consequence when wrong. It also separates reproducible structural claims from intelligence claims that require source characterisation and confidence.

That distinction belongs in the applicant’s file.

“Address A paid Address B” may be directly visible. “Addresses A through F are controlled together” may depend on a clustering method. “The cluster is Exchange X” may depend on ground-truth data, open-source information, customer submissions, or another source. “The applicant knowingly dealt with a prohibited person” requires identity, timing, applicable law, and evidence of the relationship. The graph cannot skip those steps.

The screen is a map of claims. The analyst’s job is to identify which roads are ledger facts and which are attribution.

Do not challenge every label merely because it comes from a commercial tool. Do not accept every label merely because the tool is widely used. Ask for the address, cluster, transaction path, category, source level, confidence where available, and rule that caused the alert.

Exposure Is Configured, Not Universal

Applicants often ask for the acceptable exposure percentage. There is no single number.

A tool can distinguish direct ownership, a direct counterparty, and indirect exposure. It can look backward to sources of funds or forward to destinations. An institution can set conditions using amount, proportion, transaction count, category, distance, recency, velocity, chain, counterparty indicator, or several variables together.

TRM’s current public transaction-monitoring page says its customers can create multi-condition rules using amounts, aggregation to a category, velocity, blockchain, and counterparty indicators. Elliptic says institutions configure their own thresholds and alert logic rather than use one fixed risk model. The same wallet can therefore produce different alerts under two institutions’ policies even when both platforms read the underlying transactions accurately.

Direct receipt from a listed address is a different fact from three-hop exposure to a large exchange cluster that once received funds from a flagged service. A small historic exposure is different from routing the proposed settlement amount through a newly designated service. Incoming exposure differs from where the applicant later sent funds. A transaction before a designation differs from one after it, though timing alone does not decide every legal or reputational issue.

Risk categories also differ. Sanctions, scams, ransomware, darknet markets, stolen funds, terrorism financing, mixers, gambling, unlicensed services, and high-risk exchanges are not one legal bucket. A platform category can cover behavior that is prohibited in one jurisdiction, restricted by institutional policy in another, or lawful but subject to enhanced review elsewhere.

Never copy a threshold from another bank, exchange, or prior application and present it as the program standard. Ask what the alert means in this file and what evidence can resolve it.

The Graph Is A LEAD, Not A Verdict

The Financial Action Task Force has described blockchain analytics as probabilistic and carrying inherent uncertainty. Its virtual-asset red-flag indicators are designed to be considered in context across transactions, geography, customer profile, source of funds, and anonymity features. One indicator does not establish criminal activity.

That does not make analytics optional or useless. It makes evidence classification essential.

An analyst can use a graph to identify an undisclosed exchange, a wallet consolidation, a privacy transaction, a cross-chain bridge, a service deposit, a risky counterparty, or a gap between the declared path and the visible movement. The same graph may also inherit a clustering error or an outdated attribution, a misidentified change output, or a label that does not establish applicant control.

The correct response is reproducibility. Can the analyst identify the exact transaction path? Can the applicant show which addresses were controlled? Does the service record agree with the ledger? Does the timing agree with the economic narrative? Is the label’s source direct, inferred, or unknown? What fact would change the conclusion?

A reviewer should preserve the original alert and the resolution. If a vendor corrects an attribution, keep the first report, correction request, supporting evidence, and revised result. If the institution clears a risk without a vendor correction, record its reasoning. A quiet deletion destroys the audit trail.

What The Reviewer Cannot See

The graph has limits that an applicant must fill with off-chain evidence.

It does not reveal a seed phrase or private key. It does not automatically prove the legal or beneficial owner of every address. It does not know whether an exchange subaccount belongs to the applicant, a company, a trust, or another person. It does not read an employment contract, sale agreement, inheritance record, loan document, tax return, invoice, board approval, or custody agreement.

It does not know why a transaction occurred. A transfer can be an internal wallet move, merchant payment, collateral deposit, loan repayment, gift, distribution, test transaction, exchange withdrawal, or third-party payment. The pattern may suggest a hypothesis. The records establish the economic event.

It may not distinguish gross assets from liabilities. A wallet balance can include borrowed value, encumbered collateral, assets held for another beneficial owner, or tokens that cannot be liquidated at the displayed price. A current balance is not the same as net wealth.

It cannot infer applicant knowledge from path length alone. If a customer paid the applicant from coins that previously touched a service, the applicant’s role differs from direct intentional use. Identity, relationship, control, timing, and purpose must be tested.

This is why the best response packet combines public transaction evidence with private records. The chain proves movement. The supporting file connects movement to person, contract, and lawful economic origin.

How A Human Analyst Tests The Alert

A disciplined analyst begins by defining the proposition. Is the concern ownership of a flagged address, direct interaction with an attributed service, indirect exposure, transaction behavior, source-of-funds inconsistency, or an undisclosed counterparty?

Next comes scope. Which transactions, amounts, dates, assets, networks, and wallets matter to the proposed settlement? Is the alert attached to the whole cluster or one address? Does it concern funds entering the wallet, leaving it, or both?

Then comes attribution. What evidence groups the addresses? What source names the entity? What confidence or source type is available? Has the label changed? Does another reputable data source agree?

Then comes chronology. Did the transaction occur before or after a public designation, theft, service closure, or relevant policy change? When did the applicant control the wallet? When did the economic event occur? When was the current label applied?

Finally comes context. What generated the funds? Who were the parties? What was the purpose? What records corroborate the explanation? Does the narrative reconcile in native asset units as well as fiat value?

The analyst can then clear the alert, request information, escalate it for enhanced review, restrict a transaction, or recommend an adverse decision under the institution’s procedure. A red screen does not choose among those outcomes. The evidence and policy do.

Build The Packet That Answers The Interface

Start with a one-page narrative. Identify the applicant, lawful economic origin, proposed settlement source, material wallets, material counterparties, and the alert being addressed.

Add a wallet register with public identifier, chain, period of use, controller, purpose, proof method, and exhibit. Separate personal, company, trust, exchange, smart-contract, and third-party wallets.

Add a transaction schedule that begins before the questioned exposure and ends at the proposed payment wallet. Record transaction identifier, date, asset, native amount, direction, controlled address, attributed counterparty, economic purpose, and supporting record. Reconcile fees, change, swaps, bridges, and consolidations.

Add a claim table. Mark each material proposition as ledger fact, ownership evidence, clustering inference, entity attribution, applicant explanation, or unresolved. This prevents a vendor label from being repeated through the packet until it looks like a primary fact.

Add the off-chain exhibits: acquisition records, exchange or broker statements, contracts, invoices, company books, tax or accounting support where relevant, proof of control, and correspondence. Do not include private keys or seed phrases.

Add a gap and correction register. State what is missing, what recovery was attempted, what corroboration remains, which attribution is disputed, and what uncertainty survives. The workflows for CoinJoin and mixer disclosure and DeFi and self-custody trails show how to handle two common graph patterns without concealment.

Finally, have a non-specialist follow the packet. The reviewer should be able to answer who controlled the paying assets, what created the wealth, how the assets moved, what caused the alert, and why the proposed resolution follows.

Decide Whether The File Is Ready

Proceed when the relevant wallets are identified, control evidence is proportionate, native-unit reconciliation works, the economic origin is supported, the alert has been reproduced, and every material inference is labelled honestly.

Pause when ownership is disputed, the applicant’s schedule omits a material wallet, gross borrowed value is presented as wealth, the path cannot be reconciled across a bridge or service, a vendor label has been challenged without evidence, or the explanation depends on an invented universal exposure threshold.

Do not move assets merely to make the graph look cleaner. Movement does not erase provenance. It may add an unexplained intermediary, a new counterparty, and an apparent attempt to defeat screening.

A paid Sovereignty Strategy Session gives you one hour with Adam Juchniewicz, CEO, to read a wallet history from the reviewer’s side and map the evidence before submission. It is $475 through BitSettle or $500 through Stripe, and the amount paid credits toward professional fees if you retain 21 CBI within 90 days. Book through advisory; there is no obligation to proceed.

Reproduce the alert. Separate fact from inference. Build the Record.

This article is general information, not legal, tax, forensic, sanctions, immigration, investment, or compliance advice. Analytics products, clustering methods, attribution sources, confidence levels, risk categories, alert rules, evidence standards, and program procedures vary and change. Confirm the specific concern with the parties reviewing the file, do not disclose private keys or seed phrases, and obtain qualified advice before moving assets or responding to a formal alert.