Blockchain Analytics and Tracing Suspicious Flows

Blockchain analytics is useful because many public blockchains preserve a durable transaction history that investigators can query long after a transfer has settled. It is also easy to misunderstand. A graph can show that value moved from one address to another, through a smart contract, bridge, exchange deposit address or cluster of addresses. The graph does not, by itself, prove who controlled every address, why the transfer occurred, whether the assets were criminal proceeds, or whether a legal reporting or sanctions obligation has been triggered.

That distinction is the foundation of good bank practice. On-chain facts, analytic inferences and real-world identity are different evidence layers. A strong investigation keeps them separate until other information connects them. A weak investigation collapses them into one vendor risk score and treats the result as a decision.

FATF’s virtual-asset standards and red-flag material consistently support a risk-based approach. FATF’s July 2026 targeted update also stresses that virtual-asset-enabled crime has become more complex and interconnected, with continuing risks from organised fraud, stablecoins, peer-to-peer activity through unhosted wallets, offshore providers and DeFi. Those developments make analytics more important, but they do not make analytics infallible. The bank still needs customer due diligence, transfer information, counterparty context, sanctions data, source-of-funds reasoning, investigation judgement and jurisdiction-specific legal interpretation.

The simplest mental model: facts, inference and attribution

Start with the facts the ledger actually gives you. Depending on the chain, these can include transaction hashes, sender and receiver addresses, transaction inputs and outputs, token-contract addresses, amounts, timestamps or block heights, fees, smart-contract calls and public events. These are machine-observable records. They may need technical interpretation, but they are not the same thing as an allegation.

The second layer is analytic inference. A tool may cluster multiple addresses into a probable wallet or service, label an address as belonging to an exchange, identify a bridge interaction, calculate proximity to a known illicit service, or infer that a transaction pattern resembles layering. Those outputs can be extremely useful, but they are produced through rules, heuristics, proprietary datasets and attribution research. Different providers can reach different conclusions because their data, clustering logic, coverage and update cycles differ.

The third layer is attribution to a person, organisation or customer relationship. That normally requires off-chain evidence: KYC records, a customer’s wallet-ownership proof, exchange account data, Travel Rule information, payment references, device and IP data, bank funding records, information obtained from another institution, law-enforcement information, reliable open-source material, or records supplied under legal process. A bank investigator should be able to say which layer supports each conclusion.

This model prevents two opposite errors. The first is excessive confidence: “the tool says this wallet is criminal, so the customer is criminal.” The second is excessive scepticism: “blockchain addresses are pseudonymous, so tracing tells us nothing.” Neither is sound. Analytics can materially strengthen an investigation when its evidential limits are understood and corroborating information is sought.

Why banks need blockchain tracing even when they do not run a crypto exchange

A traditional bank can encounter virtual-asset risk without offering custody or exchange services itself. Customers fund or receive money from crypto-asset service providers, merchants may accept digital assets, wealth clients may hold digital assets elsewhere, fraud victims may convert bank deposits to virtual assets, corporate customers may operate in the sector, and payment flows may connect to exchanges or brokers. A bank that treats all virtual-asset activity as somebody else’s problem can miss the point where fiat and digital-asset evidence meet.

Tracing is especially valuable when the bank needs to understand where a customer’s funds came from or went after leaving the bank. A bank statement may show only that a payment was sent to an exchange. On-chain information can sometimes show whether the customer’s declared wallet subsequently interacted with another exchange, a mixer, a scam-related cluster, a ransomware address, a high-risk service, a DeFi protocol or a bridge. Conversely, a deposit from an exchange to the bank may require an explanation of the customer’s source of wealth or source of funds that on-chain history can help test.

The key word is help. Blockchain tracing extends visibility; it does not remove the need for ordinary AML analysis. A customer receiving assets from a high-volume exchange wallet may have no direct relationship with the other customers whose funds passed through the same omnibus wallet. A customer using a privacy-enhancing service may have a legitimate reason for doing so. A newly attributed illicit address may create a need for a historical lookback, but the fact that a label was added today does not mean the bank knew or reasonably could have known that label years earlier.

What “tracing” actually means

Tracing is the structured reconstruction of transaction paths relevant to a question. The question might be “Did the customer’s withdrawal reach a sanctioned address?”, “Where did the proceeds of an account-takeover scam move?”, “Is the claimed source of funds consistent with the on-chain history?”, or “Does this deposit have recent exposure to a known theft cluster?”

A good trace starts with a defined anchor. That anchor may be a transaction hash supplied by a customer, a wallet address the bank has verified, a deposit address associated with a regulated exchange, an address published by a sanctions authority, or an address identified in a law-enforcement request. The analyst records the chain, asset, time, amount and confidence that the anchor belongs to the relevant person or service.

From that anchor, the analyst follows relevant flows. “Relevant” matters because public ledgers can create enormous graphs. Following every branch indefinitely produces noise, not insight. The investigation should define a lookback or look-forward window, a number of hops where appropriate, materiality criteria, known services to recognise, and rules for when a path should be escalated for deeper analysis.

The result should not be a colourful picture alone. It should be a reproducible explanation: the starting evidence, the path followed, material transformations, services encountered, attribution sources, uncertainty, and the reason the path changes the case decision.

Different chains create different analytic problems

Bitcoin-style UTXO chains and account-based chains such as Ethereum do not behave the same way. On a UTXO chain, transactions consume previous outputs and create new outputs. Analysts may use heuristics such as common-input ownership or change-address identification to infer clusters. These heuristics can be useful, but collaborative transactions, CoinJoin-type techniques and service architecture can undermine naive assumptions. A cluster should therefore be treated as an inference with an understood method, not a permanent truth.

On account-based chains, value can move through externally owned accounts, token contracts, decentralised exchanges, lending protocols, routers, bridges and other smart contracts. A simple “address A sent to address B” model can miss internal calls, token-transfer events or the economic effect of a contract interaction. One wallet can interact with many protocols while remaining under the same user’s control; one contract can serve thousands of unrelated users.

Tokens add another layer. The transaction may pay network fees in one asset while transferring another token. Stablecoins may be issued on several chains. Wrapped assets may represent value locked elsewhere. A bridge can move economic value between chains without creating a single cross-chain transaction that a ledger can follow end to end. The investigation therefore needs an asset-aware and chain-aware data model.

Attribution is a confidence judgement, not a label lookup

Analytics providers commonly label addresses or clusters as exchanges, mixers, gambling services, darknet markets, scam infrastructure, sanctioned entities or other categories. Banks should ask how those labels are established. Some can be high confidence because the service published the address, the address appears in a regulator or court record, or the provider has confirmed it through a controlled interaction. Others may be inferred from transaction behaviour, counterparties or clustering.

A useful control records at least four attributes: the label, the source, the confidence or evidence basis, and the effective time. If a label changes, the old state should remain reconstructable. Investigators must be able to answer, “What did the system believe on the date of the decision, and why?”

Confidence should also travel with derived relationships. If address A is conclusively attributed to a service, and address B is clustered with A using a heuristic that is only moderately reliable in that context, B should not inherit the same certainty automatically. The bank’s interface should make that distinction visible rather than flattening every node into a red or green category.

Direct and indirect exposure

“Exposure” is one of the most abused words in blockchain investigations. Direct exposure normally means a transaction is immediately between the address being reviewed and another identified address or service. Indirect exposure means one or more intermediate transactions exist. As distance increases, the evidential meaning often weakens because unrelated activity, service wallets and aggregation can enter the path.

A bank should therefore define exposure operationally. Useful dimensions include direction, hop count, time elapsed, amount, proportion of value, intervening service type, confidence in attribution and whether the path reflects traceable economic continuity. A fixed rule such as “three hops from illicit equals illicit” is rarely defensible across all chains and products.

Amount matters too. A wallet can receive many sources of value and spend from a combined balance. Some analytics tools apply tracing methods or attribution rules to estimate how much value is connected to a source. Different methods can produce different exposure calculations. The bank should understand which method its provider uses and avoid presenting a modelled exposure percentage as a physical fact.

Blockchain analytics and the Travel Rule answer different questions

The Travel Rule is about information accompanying qualifying transfers between regulated providers under the applicable framework. FATF Recommendation 16 and jurisdictional implementations seek originator and beneficiary transparency. Blockchain analytics examines the transaction history and relationships visible on-chain. These controls complement each other.

Travel Rule information can tell a receiving provider who the originating customer is, subject to the data and verification requirements of the relevant regime. Blockchain analytics can show the sending wallet’s transaction history and relationships. The first improves party transparency; the second improves transactional context. Neither automatically replaces the other.

The European Union’s Regulation (EU) 2023/1113 and EBA guidelines are one jurisdiction-specific example. They set information and handling expectations for transfers involving crypto-assets and include provisions for transfers to or from self-hosted addresses. Those EU rules should not be presented as a universal global threshold. A global bank needs a jurisdiction and legal-entity map that determines which transfer-information rules apply to which service.

Sanctions screening and blockchain analytics

Sanctions introduce a different decision standard from general AML suspicion. OFAC, for example, has included certain virtual-currency addresses as identifying information for listed persons and has issued virtual-currency industry guidance for U.S. sanctions compliance. OFAC’s guidance encourages risk-based controls, including screening relevant transaction data and using monitoring or investigation tools where appropriate. That is U.S.-specific guidance and must be interpreted with the applicable sanctions programme and legal nexus.

A crucial operational distinction is between a listed address, an address attributed to a blocked person, and an address that merely has transactional proximity to one. They are not automatically equivalent legal categories. The bank may need to hold or stop activity while specialists determine whether a blocked person has an interest, but the analytics relationship itself is not the legal conclusion.

Point-in-time data is essential. Sanctions lists change, addresses can be added as identifiers, entities can be designated or delisted, and ownership/control facts can change. A case record should preserve the list version, screening timestamp, attribution source and reasoning used at the time of the decision.

From signal to alert

A bank should not alert on every virtual-asset transfer. Detection works better when blockchain intelligence is combined with customer and transaction context. Relevant dimensions can include the customer’s stated activity, source of funds, destination or origin service, geography, transaction velocity, recent account changes, fraud indicators, sanctions exposure, counterparty type, direct or indirect exposure, and previous case history.

A well-designed alert tells the reviewer why the case exists. “Crypto risk score 82” is not enough. A useful alert might say that a previously low-activity retail customer sent three large payments to a VASP, withdrew assets to a newly observed self-hosted address, and that address then sent most of the value directly to a cluster newly attributed to a scam cash-out service. The reviewer can test each proposition.

Thresholds should be calibrated by use case. A sanctions-screening control may need a different response from a general AML proximity rule. A fraud-prevention decision before an irreversible customer transfer has a different time budget from a post-event source-of-funds investigation. Governance should make those purposes explicit.

The evidence package an investigator should preserve

Blockchain evidence can change in presentation even if the underlying ledger does not. Vendor labels, clusters and risk scores are dynamic. For that reason, a defensible case should preserve enough detail to reconstruct what the analyst saw.

At minimum, record the chain, address or transaction hash, asset and token contract where relevant, block height or timestamp, amount, direction, relevant counterparties, path or hops reviewed, attribution label, attribution source, confidence, analytics-provider version or query timestamp, and the analyst’s interpretation. If the bank exports a graph or report, retain the export and, where practical, a hash or immutable reference to the evidence artifact.

Also preserve off-chain evidence: the customer’s explanation, exchange statements, wallet ownership evidence, Travel Rule data, KYC profile, bank transaction history, device or fraud indicators, RFIs and responses. The conclusion should show how these sources agree or conflict.

This is not documentation theatre. Months later, an auditor, FIU liaison, sanctions specialist or law-enforcement partner may need to understand why the bank acted. “The screen was red at the time” is not enough.

Customer impact and proportionality

Blockchain tools can create customer harm when uncertain attribution is converted into automatic denial, account restriction or exit. Service clusters can contain activity from many unrelated users. Exchange omnibus wallets can create apparent proximity to risky funds. Privacy tools may have lawful uses. False attribution can occur.

Banks therefore need staged responses. A low-confidence indirect exposure may justify enhanced monitoring or an RFI rather than immediate exit. A direct transfer to a clearly attributed sanctioned address may require immediate sanctions escalation under the applicable regime. A fraud victim sending funds to a scam-linked wallet needs customer protection and fraud intervention, not an assumption that the victim is laundering money.

The decision should fit the risk, legal obligation and evidence. That principle matters as much in digital assets as it does in traditional payments.

Roles across the bank

The first line owns customer and product context. Financial-crime operations investigate alerts and connect on-chain and off-chain evidence. Sanctions specialists determine sanctions applicability. Fraud teams contribute device, scam, mule and account-takeover intelligence. Data and technology teams maintain feeds, vendor integrations, chain coverage and lineage. Model or analytics governance challenges scoring and clustering methodology where those outputs materially influence decisions. Legal interprets jurisdiction-specific obligations. Internal audit tests whether the control works as designed.

For business analysts and product owners, the job is to make those responsibilities visible in requirements. A requirement that says “screen crypto transactions using blockchain analytics” is incomplete. It must say what transaction is screened, when, against what data, how the score or label is interpreted, what happens when the service is unavailable, who owns exceptions, what evidence is persisted, and which downstream workflow receives the result.

Architecture: treat analytics as an evidence service

A sound architecture normally separates raw blockchain data, attribution or analytics services, bank context, decisioning and case management. This reduces the risk that a vendor score becomes the only source of truth.

The analytics layer may ingest blockchain nodes or third-party data, entity tags, risk categories and graph-derived features. The bank context layer supplies customer identity, accounts, product, KYC risk, fiat funding, Travel Rule information, fraud intelligence and previous cases. Decisioning combines those inputs according to the use case. Case management preserves evidence and human judgement.

The interface should expose provenance. If a field says counterparty_type = mixer, the downstream system should know the source, timestamp and confidence, not only the label. If a risk score changes after a vendor model update, the bank should be able to distinguish the historical decision from the new assessment.

What good looks like

A mature blockchain analytics control does not promise perfect deanonymisation. It gives the bank a disciplined way to turn public-ledger information into useful evidence. Analysts can reproduce a trace. They know which observations are facts and which are inferences. They can explain attribution confidence. They combine on-chain evidence with customer and payment context. They know when sanctions, fraud, AML or law-enforcement processes require different action.

Most importantly, the bank can explain why a case outcome was reasonable at the time it was made. That is the standard the rest of this chapter builds toward.

Operational deep dive: how graph tracing really works

The useful part of blockchain analytics begins when the bank stops thinking in terms of a single “wallet score” and starts thinking in terms of a graph. A graph represents addresses, transactions, contracts and attributed entities as connected objects. The purpose is not to draw a complicated picture; it is to answer a financial-crime question while preserving the difference between observed data and inferred relationships.

Nodes, edges and the meaning of a path

In a simple account-based model, an address can be represented as a node and a transfer as a directed edge. The edge carries attributes such as asset, amount, timestamp, transaction hash and chain. That model works for a basic native-asset transfer but becomes incomplete when tokens and smart contracts are involved. A decentralised exchange trade can include approvals, router calls, liquidity-pool interactions and token-transfer events. The economic flow may therefore require several on-chain events to reconstruct.

UTXO chains require a different representation. A transaction consumes one or more prior outputs and creates new outputs. Analysts may infer that several inputs were controlled by the same party, or infer which output is change. Those techniques are heuristics, not universal rules. Collaborative transactions can deliberately combine inputs from unrelated parties; exchanges and custodians can use wallet-management patterns that make simple clustering misleading.

This is why the bank’s investigation tooling needs chain-specific logic. A generic graph database can store the relationships, but the parser and analytic interpretation must understand the transaction model of the chain being analysed.

Clustering without creating false certainty

Address clustering is valuable because a service can operate thousands of addresses. If every address is treated independently, the bank loses the ability to recognise an exchange, merchant processor or criminal infrastructure as one operational entity. Clustering can therefore make a huge graph usable.

The danger is inherited certainty. Suppose address A is confirmed as an exchange deposit address and an algorithm groups address B with A based on transaction behaviour. It is tempting to label B “confirmed exchange.” That statement goes further than the evidence. A better representation says that A has high-confidence attribution while B is analytically linked to the same cluster under a named method and confidence level.

The control should store the reason for the cluster where the analytics provider exposes it. At minimum, the bank should know whether the label is directly sourced, behaviourally inferred, identified through service interaction, derived from public records, or received from another trusted intelligence source. Vendor opacity does not remove the bank’s responsibility to understand material limitations.

Omnibus wallets and service infrastructure

Hosted exchanges and custodians complicate traces because they often pool customer assets. A customer may deposit to an address uniquely assigned for routing purposes, after which the assets move into a larger service wallet. Withdrawals may come from an omnibus hot wallet unrelated to the original deposit address.

A graph that shows the customer receiving from a wallet that also paid a risky address does not prove that the customer transacted with that risky party. They can simply share the same service infrastructure. The relevant question becomes whether the service itself is high risk, whether the customer’s account within that service can be identified, and whether off-chain records can connect the customer to a specific source or destination.

This is one reason RFIs and Travel Rule data matter. On-chain proximity can identify the service; provider-held customer records may be needed to identify the person.

Mixers, collaborative transactions and privacy techniques

A mixer or privacy-enhancing pattern can make tracing harder by breaking the intuitive one-input-to-one-output narrative. Yet difficulty of tracing is not proof of crime. The bank should distinguish use of a privacy mechanism from corroborated exposure to illicit activity.

For an investigator, the right question is often: what can still be established? Entry to a mixer may be clear even if specific output attribution is probabilistic. Timing, denominations, subsequent service interactions and other data can add context. Some analytics providers may offer probabilistic or heuristic links across mixing activity. Those links should carry their uncertainty explicitly.

The same caution applies to collaborative transactions. A CoinJoin-like transaction can contain multiple unrelated participants. A common-input heuristic that would normally imply joint control may fail in that context. Tooling should recognise transaction types known to invalidate particular heuristics.

Smart contracts and protocol interactions

On account-based chains, a smart contract can be a service, a pool, a router, a bridge or an application component rather than a customer. Analysts need to know whether an address represents a contract and what role it played.

Consider a decentralised exchange. The customer may send tokens to a router contract; the router interacts with one or more liquidity pools; different tokens return to the customer. If an investigator treats every intermediate contract as a counterparty, the graph becomes misleading. The economic counterparties may be a protocol and pooled liquidity rather than a named individual.

Contract labels can also change. A proxy contract may point to upgradeable logic. A protocol can migrate. Attackers can deploy look-alike contracts. Architecture therefore needs contract metadata, token metadata and event decoding rather than relying only on raw value transfers.

Bridges and cross-chain tracing

A bridge is a major boundary for analytics because the source-chain transaction and destination-chain transaction are not the same ledger event. Some bridges lock assets on one chain and mint a representation on another; others use liquidity pools, messaging protocols or custodial mechanisms. The economic value continues, but direct transaction identity may not.

A cross-chain trace needs a bridge-specific linking method. That can use bridge events, message identifiers, amount and timing correlations, service-provided data or vendor intelligence. Confidence should be recorded. The analyst should not state that the same person controlled the destination wallet merely because similar value appeared on another chain after a bridge interaction.

Chain hopping can be legitimate portfolio activity, but it can also be used to complicate tracing. The risk conclusion depends on the wider case: speed, repeated use of multiple bridges, subsequent interaction with high-risk services, customer profile, source of funds, device activity and other evidence.

Stablecoins and issuer controls

Stablecoins matter because they combine on-chain transferability with, in some models, an identifiable issuer that may have administrative capabilities such as freezing or blacklisting addresses. Those capabilities differ by token and should never be assumed.

For the bank, stablecoin tracing has practical advantages and complications. Token-transfer events can make flows visible across addresses, but the token may exist on several chains and move through bridges. A customer can receive a token on one network and convert it elsewhere. Issuer actions can also change the status of an address independently of the bank’s controls.

FATF’s 2026 work highlights the growing illicit-finance relevance of stablecoins and peer-to-peer transactions. A bank should use that current risk context to inform monitoring, not to treat stablecoin usage itself as suspicious.

Risk scores are compressed evidence

Analytics providers often produce numerical or categorical risk scores. A score can combine proximity to tagged entities, transaction history, service types, typologies and other features. The value of the score is speed: it compresses a complex graph into a signal that can be used in screening or monitoring.

Compression also hides detail. Two wallets can have the same score for very different reasons. One may have a direct transfer to a sanctioned address; another may have small indirect exposure several hops away through an exchange. Those are not equivalent facts, and they may not have the same legal or investigative consequences.

The bank should therefore store both the score and its principal drivers. Material actions should be explainable from underlying evidence. If a score is used for automated interdiction, customer restriction or case prioritisation, model governance should understand the feature logic, data coverage, threshold calibration, false-positive behaviour and change process.

Temporal validity and lookbacks

Attribution is time-sensitive. A wallet can be labelled after a law-enforcement announcement. A service can change owners. A sanctions designation can be added or removed. A vendor can correct a mistaken tag. The bank needs to distinguish the transaction time, the decision time and the time the intelligence became available.

This produces an important lookback pattern. Suppose an address is newly attributed to a ransomware group. The bank may search historical transactions to identify customers who interacted with it before the label existed. That exercise can be valuable for risk understanding and regulatory obligations, but the bank should not rewrite the historical record as though the original analyst had access to information that did not yet exist.

The case should preserve both states: what was known then and what is known now.

From blockchain event to bank case

A useful end-to-end flow begins with a bank event: customer funding to a VASP, incoming proceeds from a VASP, a digital-asset custody transfer, a fraud report, a sanctions alert or an RFI. The bank resolves the relevant blockchain address or transaction where possible. Analytics enriches the event with counterparty labels, direct and indirect exposure, path information and typology indicators.

Decisioning then combines that enrichment with customer context. Low-risk activity can continue without a case. Borderline activity may generate an alert. High-confidence sanctions or fraud signals may trigger immediate specialist action. The case system should receive the evidence, not merely the final score.

During investigation, the analyst may expand the graph, request customer evidence, contact another institution, obtain Travel Rule information, review prior bank activity and compare the customer’s explanation with the observed flow. The outcome can include closure, enhanced monitoring, fraud intervention, sanctions action, customer restriction, relationship review or a suspicious transaction/activity reporting decision under the applicable jurisdiction.

Failure modes that experienced reviewers should challenge

The first failure is treating all analytics outputs as facts. The second is using a universal hop threshold without recognising service wallets and transaction models. The third is failing to record the version and timing of attribution. The fourth is allowing unsupported wallet labels to drive irreversible customer outcomes. The fifth is poor chain coverage: the control claims to monitor virtual assets but the provider does not support a newly used chain or token.

Another failure is a broken join between the bank and blockchain worlds. The bank knows a customer paid an exchange but cannot identify the relevant on-chain withdrawal; or the analytics system detects a risky wallet but cannot link it back to the bank customer. Requirements should explicitly define those joins and what evidence establishes them.

Finally, some teams confuse an impressive graph with a complete investigation. A graph without customer context, legal interpretation and a documented decision is intelligence, not a finished case.

Advanced practice: calibration, governance and production control

A production blockchain-analytics capability is not finished when the API returns a score. It is finished when the bank can show that the right events are analysed, the right evidence reaches the right workflow, thresholds are calibrated to the decision being made, vendor and model changes are controlled, and investigators can reproduce an outcome months later.

Design detection around the decision, not the tool

Start with the decision the bank needs to make. A pre-transfer fraud control asks whether an outgoing payment should be interrupted before value becomes hard to recover. An AML monitoring control asks whether behaviour is sufficiently unusual or suspicious to investigate. A sanctions control asks whether applicable restrictions may prohibit or require action on the transaction or property. A source-of-funds review asks whether the customer’s explanation is consistent with evidence.

Those purposes should not share one undifferentiated threshold. A sanctions alert may require high sensitivity to specific identifiers and specialist legal review. An AML scenario may accept more false positives if the risk is material but should still be calibrated against customer context. A fraud control operates within a much tighter latency budget and needs clear customer-intervention logic.

Business requirements should therefore identify the use case, event timing, required inputs, maximum decision latency, threshold or rule logic, fallback if analytics is unavailable, outcome owner and evidence-retention requirement.

Direct exposure rules need an ontology

Terms such as exchange, mixer, darknet market, scam, gambling, sanctioned entity, ransomware, bridge and DeFi should have governed definitions. If one vendor calls a protocol a “mixer” and another calls it “privacy infrastructure,” downstream rules can behave differently even when both are looking at the same address.

The bank should maintain a mapping between vendor categories and its internal risk taxonomy. Changes to that mapping are control changes. They should be versioned, tested and approved.

Direct exposure can then be expressed clearly: for example, a customer-controlled address transferred value directly to an address attributed with high confidence to a particular service category during a defined period. That statement is more auditable than “wallet high risk.”

Indirect exposure needs decay and context

Indirect exposure should become less decisive as the graph passes through neutral or high-volume infrastructure. A one-hop relationship through a personal wallet is different from a two-hop relationship through a major exchange omnibus wallet. Time matters as well; an exposure occurring minutes before a customer deposit is more informative than a remote historical connection in a high-turnover service.

Banks can encode these ideas in a scoring framework, but the score should remain explainable. Useful features include number of hops, time since risky activity, value or proportion of traced funds, intervening service types, confidence in labels, transaction velocity and whether the path is consistent with the customer’s declared activity.

No universal formula fits every chain. Calibration must be empirical and governed.

Vendor due diligence and model risk

A blockchain-analytics provider is a critical data and decision dependency when its outputs drive customer or regulatory outcomes. Due diligence should cover supported chains and assets, attribution methodology, update frequency, sanctions-list handling, data retention, resilience, service levels, security, explainability and change notification.

The bank should know which parts of the service are deterministic and which are model-based. If clustering or risk scoring uses proprietary heuristics or machine learning, governance should assess limitations proportionate to the materiality of those outputs. The objective is not to demand disclosure of intellectual property; it is to understand enough to use the result safely.

Regression testing is particularly important after provider changes. A new attribution dataset or scoring model can suddenly reclassify large customer populations. The bank should compare old and new outputs on representative historical samples before allowing the change to drive production decisions.

Data lineage from transaction to case

The minimum production lineage can be described as:

bank event → blockchain identifier resolution → analytics request → analytics response → decision rule → alert or action → case evidence → final disposition.

Every arrow can fail. The bank event may carry the wrong asset. The address may be copied incorrectly. A token contract can be confused with an account. The provider may time out. The response may be mapped to the wrong risk category. The case system may receive the score but not the underlying drivers.

Good technical design assigns a correlation ID across the flow. It records request and response timestamps, provider version where available, chain, transaction hash or address, rule version, outcome and case identifier. Sensitive data should be protected according to the bank’s data policies, but traceability should not be sacrificed.

Service failure and degraded mode

Analytics services can fail during a customer journey. A bank that has not decided what happens during an outage will improvise under pressure.

The fallback depends on risk and product. A custody withdrawal to a new external wallet may be queued for later review, subject to contractual and legal constraints. A low-risk historical AML enrichment job can retry asynchronously. A sanctions-related real-time control may need a more conservative fallback. The bank should not invent a single “fail open” or “fail closed” rule for every use case.

Testing should cover timeouts, partial responses, stale tags, unavailable chains and delayed provider updates. Operational runbooks should define escalation and how events processed during degraded mode are replayed or reviewed after recovery.

Quality assurance for investigators

Case QA should examine reasoning, not just completion of mandatory fields. Reviewers should ask whether the analyst identified the correct anchor, distinguished facts from inference, understood intervening services, preserved attribution confidence, considered contrary evidence, and connected the trace to the customer’s activity.

Sampling should include both escalations and closures. If QA reviews only suspicious cases, it cannot detect a systematic tendency to close risky activity because a score fell just below a threshold. If it reviews only high-value customers, it can miss poor performance in retail or small-business segments.

Feedback from QA should reach detection and data teams. Repeated analyst workarounds often reveal missing fields or badly calibrated rules.

Lookback governance

New intelligence can justify a historical search. Triggers can include a newly designated address, a newly attributed criminal service, law-enforcement intelligence, a material vendor correction or a newly identified typology.

A lookback should define the population, period, chains, matching logic, materiality and case-opening criteria. It should also record why the lookback was initiated and what intelligence became available. This prevents retrospective overstatement.

Where a legal requirement imposes a specific reporting or blocking duty, legal and sanctions teams should define the obligation. Analytics operations should not assume that every retrospective link creates the same regulatory consequence.

Management information that reveals control quality

Useful MI goes beyond the number of alerts. It can show direct versus indirect exposure, top risk categories, chain and asset coverage, percentage of alerts caused by low-confidence attribution, case conversion, time to decision, provider outage duration, stale-tag incidents, reopened cases after new intelligence, QA error themes and customer-impact outcomes.

Trend analysis can reveal changes in criminal behaviour or control performance. A sudden drop in alerts may mean risk is falling, but it can also mean a data feed failed or customers moved to an unsupported chain. Management should see coverage and data-health metrics alongside risk volumes.

Privacy, legal basis and proportionality

Blockchain data may be public, but combining it with customer identity creates a bank-held profile that can be subject to privacy and data-protection requirements. The bank needs a lawful and proportionate basis for collection, enrichment, retention and sharing under the jurisdictions in which it operates.

The control should avoid unnecessary graph expansion into unrelated third parties. Data minimisation and purpose limitation can coexist with effective AML investigations. Access should be role-based, and exports containing customer-linked addresses should be controlled.

Acceptance criteria for a bank-grade implementation

A strong set of acceptance criteria is testable. For a supported chain, a valid transaction hash should return the correct asset, time and counterparties. A high-confidence direct exposure should carry its attribution source and timestamp into the case. An indirect path through an exchange should be distinguishable from a direct transfer. A provider timeout should follow the approved fallback. A label change should be auditable. A case should retain the evidence state used for the original decision even if the provider’s current label later changes.

Negative tests matter just as much. A clean customer transfer should not be escalated merely because an unrelated user of the same exchange interacted with a risky address. A CoinJoin-style transaction should not be clustered using a heuristic known to be invalid for that pattern. A bridge transfer should not assert destination ownership without a supported cross-chain link.

The mature control

The mature bank treats blockchain analytics as a specialised financial-intelligence capability inside the wider financial-crime framework. It is technically sophisticated but operationally disciplined. It does not outsource judgement to a provider, and it does not dismiss on-chain evidence because attribution can be uncertain.

That balance is what makes the capability useful: evidence strong enough to change a decision, uncertainty visible enough to prevent overclaiming, and governance strong enough to explain the result.

Practice close: requirements, testing and investigation discipline

Blockchain analytics becomes bank-grade only when the control can be expressed as requirements, tested against realistic cases and challenged by people who were not involved in building it. This close turns the chapter into practical delivery artefacts.

Business analyst requirement model

A useful requirement starts with the event. Define whether the trigger is a customer deposit from a VASP, a withdrawal to an external wallet, a hosted-custody transfer, a fraud report, a sanctions hit, a source-of-funds review or a periodic lookback. The same analytics platform can support all of them, but the required response is different.

For each event, specify the minimum identifiers. Those can include chain, asset, token contract, transaction hash, customer-linked address, counterparty address, amount and event time. Define how the bank proves that the address belongs to or is relevant to the customer. A field containing an address is not enough if its origin is unknown.

Then specify enrichment. The response should expose the underlying drivers needed for the decision: entity label, entity category, attribution source, confidence, direct or indirect relationship, hop count where used, value or exposure measure, timestamp, provider query time and relevant path information. A single score without drivers is insufficient for high-impact decisions.

Finally, define workflow and evidence. State which rule creates an alert, which team owns it, which situations require sanctions or fraud escalation, what the service does during an outage, what is persisted to the case, and how a later label or model change is distinguished from the original decision.

Test scenarios that matter

A clean test should verify that a customer sends assets from a verified wallet to a well-known regulated exchange and the event completes without unnecessary escalation. This proves the system can recognise legitimate infrastructure rather than merely detect risk.

A direct-risk test should use controlled synthetic data in which a customer-linked wallet transfers to a test address tagged as a designated or prohibited counterparty under the test regime. The expected outcome is the approved sanctions workflow, with the tag source, timestamp and legal-review route preserved. The test must not use live prohibited transfers.

An indirect-exposure test should place a major exchange wallet between the customer and a risky source. The system should avoid treating the customer as though they directly transacted with the risky source. The case should show the intervening service and reduced evidential strength.

A cross-chain test should move synthetic value through a bridge. The system should prove that it can link the source and destination only when the bridge logic supports that link. It should not infer common ownership merely from similar amounts and timing.

A privacy-technique test should include a collaborative transaction or mixer-like pattern. The expected result is uncertainty-aware handling, not automatic criminal attribution.

A stale-data test should simulate an attribution change after the original case. The historical case must still show the label and version used when the decision was made, while a new lookback can use the updated intelligence.

An outage test should verify the approved degraded-mode behaviour. The result should be deterministic and traceable, not dependent on an operator improvising.

Data reconciliation tests

The bank should reconcile three worlds: the core banking event, the virtual-asset event and the case-management record. Amounts may differ because of exchange rates or fees, so reconciliation should not depend on naive equality.

For a known transaction, testers should be able to trace the customer payment to the exchange or custody event, the relevant blockchain identifier to the analytics request, and the analytics result to the alert or case. Missing joins should be treated as control defects because they can create invisible activity.

Coverage tests should enumerate supported chains, assets and token contracts. A product must not claim to monitor a chain that is not technically parsed or enriched. When new assets are launched, the onboarding process should include analytics coverage as an explicit control dependency.

Investigator checklist

Before closing or escalating a case, the investigator should be able to answer a small set of hard questions in plain language:

• What is the anchor transaction or address, and why is it connected to this customer?
• Which conclusions are direct on-chain facts?
• Which conclusions come from analytics inference or clustering?
• Which real-world identity claims are supported by off-chain evidence?
• Is the exposure direct, indirect or interrupted by a service?
• Which attribution source and confidence level were used?
• What evidence weakens the suspicious interpretation?
• Does a sanctions, fraud or AML decision require a different specialist owner?
• What did the customer say, and is the explanation consistent with the evidence?
• Could another reviewer reproduce the path and understand the decision?

The checklist should support judgement rather than replace it.

Common defects and the expected remediation

If a case contains only a screenshot of a coloured graph, remediation is to capture machine-readable identifiers, attribution details and a written evidential narrative. If a rule uses a fixed hop count across every chain, remediation is to introduce service-aware and confidence-aware logic. If all virtual-asset activity is sent to one queue, remediation is to separate use cases and priorities.

If analysts cannot tell when a tag was last updated, the data model needs temporal metadata. If a provider change causes unexplained alert spikes, change governance and regression testing need strengthening. If the bank cannot reproduce a historical decision after a tag changes, evidence retention is inadequate.

If legitimate exchange activity generates persistent false positives, calibration should examine omnibus wallet handling and entity attribution rather than simply raising thresholds. Raising a threshold can hide genuine risk while leaving the root cause untouched.

Governance questions for a design review

Architecture and compliance forums should challenge the capability together. Useful questions include whether raw chain data and provider inference are stored separately, whether high-impact rules are explainable, how cross-chain links are established, how unsupported assets are handled, how list and tag updates trigger lookbacks, and whether the bank can operate safely during a provider outage.

Model or analytics governance should ask what validation is appropriate for scoring and clustering. Operations should ask whether investigators can understand the evidence without specialist blockchain engineering skills. Legal and privacy teams should ask whether data use and retention are proportionate in each jurisdiction. Product teams should ask how legitimate customers are protected from opaque automated restrictions.

Knowledge check

A vendor labels a customer wallet “high risk.” Is that enough to file a suspicious report? No. It is a signal. The reporting decision depends on the applicable law and the institution’s threshold, supported by the full facts and investigation.

A wallet is three hops from a sanctioned address. Is the wallet sanctioned? Not merely because of transactional distance. The bank needs applicable legal analysis, attribution and any relevant ownership or property-interest facts. Proximity can justify investigation without being the legal conclusion.

Why store the analytics query time? Because entity tags, clusters, list data and risk scores can change. The query time helps reconstruct what the bank knew when it acted.

Why is Travel Rule data still useful if the blockchain is public? Because the blockchain mainly shows addresses and transactions; transfer-information rules can provide originator and beneficiary information from regulated providers. They answer different questions.

Can an exchange wallet break the meaning of an indirect path? It can materially weaken the inference that two end users dealt with each other because pooled service infrastructure can aggregate unrelated customers.

Should every mixer interaction be treated as criminal? No. Privacy-enhancing activity is a risk indicator that needs context. Suspicion depends on the wider facts, applicable rules and corroborating evidence.

Final takeaway

The best blockchain-analytics control is not the one with the most labels or the highest number of alerts. It is the one that turns on-chain transparency into proportionate, reproducible evidence.

Banks need to know what the ledger proves, what the analytics provider infers, what off-chain data establishes, and where uncertainty remains. They need use-case-specific thresholds, chain-aware tracing, point-in-time attribution, controlled vendor changes, strong data lineage and investigators who can explain the story without hiding behind a score.

When those elements are present, blockchain analytics becomes a powerful extension of ordinary financial-crime investigation. When they are absent, sophisticated technology can simply produce sophisticated-looking mistakes.

Masterclass: tracing a suspicious stablecoin flow without overclaiming

This case is fictional but built from patterns a bank can realistically encounter. The purpose is to show how an investigator moves from a bank transaction to on-chain evidence, how uncertainty is handled, and how the case changes when new information appears.

The trigger

A long-standing small-business customer receives the equivalent of EUR 185,000 from a regulated virtual-asset service provider. The payment reference says “crypto proceeds.” The customer’s KYC profile describes an online design consultancy with annual turnover of roughly EUR 320,000 and no recorded investment business. Previous account activity includes occasional transfers to well-known exchanges, but nothing of this size.

The bank’s transaction-monitoring system creates an alert because the amount is unusual relative to the customer profile, the funds came from a VASP, and most of the credit is scheduled for an outgoing international payment the next morning.

The analyst does not start by assuming the crypto proceeds are illicit. The first questions are ordinary AML questions: what generated the value, who owns it, and does the explanation fit the customer’s known activity?

Establishing the anchor

The customer responds that the funds came from the sale of stablecoins accumulated through consulting work for technology clients. The customer provides an exchange statement showing the sale and a wallet address said to be their self-hosted wallet.

The analyst needs to establish that the supplied wallet is relevant. The exchange statement contains a deposit transaction hash that can be matched to the wallet’s outgoing transfer to the exchange. The chain, token contract, amount and time align. This is strong evidence that the supplied address participated in the deposit, but it is not yet proof that the customer had controlled that wallet throughout its history.

The bank asks for a signed-message or small verification transfer according to its approved procedure. The customer completes the verification. The bank can now treat the wallet as customer-controlled at the verification time, while retaining the narrower wording that control of historic activity is inferred from the evidence rather than absolutely proven for every prior date.

The first trace

The analytics platform shows that the wallet received stablecoins from several sources during the previous six months. Most sources are labelled as major VASPs. One incoming path is different: EUR-equivalent 70,000 arrived from an address with no direct label. Two transactions earlier, that address received assets from a cross-chain bridge. Before the bridge, the source-chain address had received funds from a cluster associated with a large investment-scam investigation.

The vendor shows “high risk” and reports two-hop scam exposure. A weak process would stop there. The analyst expands the path.

The scam cluster attribution is high confidence and supported by a public law-enforcement notice. The first hop from that cluster goes to a busy exchange deposit cluster, and the next apparent hop is the customer-related path. That changes the meaning. The service wallet can aggregate unrelated users. The graph does not prove that the customer received scam proceeds from a scammer.

The analyst records this as an indirect relationship interrupted by hosted-service infrastructure, not as direct scam exposure.

A second path changes the case

Another incoming amount, roughly EUR-equivalent 52,000, has a clearer path. A wallet sends stablecoins to a decentralised exchange, swaps into another asset, crosses a bridge and, within twenty minutes, converts back into the same stablecoin before sending almost the entire amount to the customer-controlled wallet. The source wallet is not labelled, but it received multiple credits from newly created addresses that had themselves received money from accounts associated with fraud victims at another financial institution.

The on-chain data alone cannot tell the bank who controlled the source wallet. But the rapid sequence, near-total value continuity and fraud intelligence create a stronger investigative lead than the earlier generic two-hop score.

The bank’s fraud team checks internal and shared intelligence. It finds an earlier RFI from another bank asking about a beneficiary with a name matching one of the customer’s clients. The amounts and dates overlap with the consulting invoices the customer has now supplied.

The case has moved from “unusual crypto proceeds” to a plausible laundering or mule concern requiring deeper investigation.

Customer explanation and contradictory evidence

The customer says the EUR-equivalent 52,000 was payment for a software-design project and provides an invoice. The invoice is dated three weeks after the on-chain payment. Its description is generic, and the supposed client has no meaningful public business presence.

That inconsistency does not prove the invoice is false, but it weakens the explanation. The bank asks targeted questions: contract date, work product, client contact details, how the fee was agreed, why payment was received through a self-hosted wallet, and why the client used multiple addresses and a bridge.

The customer supplies a contract created shortly before the bank’s RFI but cannot produce correspondence showing the work was commissioned. The customer also asks whether the bank can “just ignore the crypto path because the exchange already approved it.” That statement has no evidential value by itself, but it shows why banks cannot outsource their own risk assessment to an exchange.

The investigation record

The analyst preserves the exact transaction hashes, chain, stablecoin contract, amounts, timestamps and bridge events. The case file records the vendor’s labels and confidence, the query date, the fraud-team intelligence, the customer’s wallet verification, exchange statement, invoices, contract and responses.

The narrative distinguishes four propositions:

1. The customer controlled the receiving wallet at the relevant review point, supported by wallet verification and exchange evidence.
2. One large incoming flow had only indirect scam proximity interrupted by an exchange and is not treated as proof of illicit origin.
3. A separate incoming flow shows strong value and timing continuity from wallets linked through fraud intelligence, DEX activity and a bridge to the customer-controlled wallet.
4. The customer’s commercial explanation contains documentary and timing inconsistencies that remain unresolved.

This separation makes the case defensible. It shows what evidence materially drives suspicion and what evidence was considered but discounted.

Outcome

Under the bank’s applicable local AML framework, the nominated reporting officer decides that the combined facts meet the institution’s threshold for filing a suspicious transaction or activity report. The filing decision is based on the full case, not the vendor score. The bank follows local confidentiality rules and does not tell the customer that a report was filed.

Separately, the relationship-risk team reviews whether restrictions, enhanced monitoring or exit are appropriate. That is a different decision. The bank considers customer impact, legal constraints, residual risk, ongoing cooperation and the possibility that the customer is being used by others.

No sanctions conclusion is made because no applicable designated person or blocked-property interest has been established. The analytics tool’s generic “high risk” category does not create a sanctions event.

What the case teaches

The most important lesson is that deeper tracing can reduce as well as increase suspicion. The first two-hop scam connection looked concerning until the analyst recognised an exchange omnibus wallet. The second path became more concerning because on-chain continuity aligned with independent fraud intelligence and weak commercial evidence.

Good blockchain investigations therefore do not ask, “Is this wallet red?” They ask, “What can we establish, how confident are we, what other evidence confirms or contradicts it, and what decision standard applies?”

That is the difference between using analytics as a forensic capability and using it as a colour-coded shortcut.

References and further reading

Global standards and virtual-asset risk

Financial Action Task Force (FATF), Updated Guidance for a Risk-Based Approach to Virtual Assets and Virtual Asset Service Providers, 28 October 2021
https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html

Financial Action Task Force (FATF), Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing, 14 September 2020
https://www.fatf-gafi.org/en/publications/Methodsandtrends/Virtual-assets-red-flag-indicators.html

Financial Action Task Force (FATF), Seventh Targeted Update on Implementation of the FATF Standards on Virtual Assets/VASPs, 16 July 2026
https://www.fatf-gafi.org/en/publications/Fatfrecommendations/targeted-updated-virtualassets-vasps-2026.html

Financial Action Task Force (FATF), Targeted Report on Stablecoins and Unhosted Wallets — Peer-to-Peer Transactions, 3 March 2026
https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-stablecoins-unhosted-wallets.html

Financial Action Task Force (FATF), Targeted Report on Regulatory Challenges from Decentralised Finance, 21 July 2026
https://www.fatf-gafi.org/en/publications/Virtualassets/targeted-report-decentralised-finance-2026.html

Sanctions and U.S. virtual-currency controls

U.S. Department of the Treasury, Office of Foreign Assets Control (OFAC), Sanctions Compliance Guidance for the Virtual Currency Industry, issued 15 October 2021
https://ofac.treasury.gov/recent-actions/20211015

OFAC, Sanctions Compliance Best Practices for the Virtual Currency Industry
https://ofac.treasury.gov/system/files/126/virtual_currency_guidance_brochure.pdf

Financial Crimes Enforcement Network (FinCEN), Advisory on Illicit Activity Involving Convertible Virtual Currency, FIN-2019-A003, 9 May 2019
https://www.fincen.gov/resources/advisories/fincen-advisory-fin-2019-a003

U.S. Department of the Treasury, 2023 DeFi Illicit Finance Risk Assessment, 6 April 2023
https://home.treasury.gov/news/press-releases/jy1391

U.S. Department of the Treasury, Report to Congress on Innovative Technologies to Counter Illicit Finance Involving Digital Assets, March 2026
https://home.treasury.gov/system/files/246/GENIUS-Act-Illicit-Finance-Innovation-Congressional-Report-March-2026.pdf

Transfer transparency and supervisory indicators

European Banking Authority, Guidelines on information requirements in relation to transfers of funds and certain crypto-assets under Regulation (EU) 2023/1113, published 4 July 2024, applicable from 30 December 2024
https://www.eba.europa.eu/publications-and-media/press-releases/eba-issues-travel-rule-guidance-tackle-money-laundering-and-terrorist-financing-transfers-funds-and

EUR-Lex, Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets
https://eur-lex.europa.eu/eli/reg/2023/1113/oj

AUSTRAC, Indicators of suspicious activity for virtual asset service providers
https://www.austrac.gov.au/industry-and-business/education-and-resources/publications-and-resources/indicators-suspicious-activity-virtual-asset-service-providers

Investigation and asset-tracing context

United Nations Office on Drugs and Crime, CTOC/COP/WG.3/2025/4 — international cooperation and tracing of proceeds involving virtual assets, 2025
https://www.unodc.org/documents/treaties/International_Cooperation_2025/4/CTOC_COP_WG.3_2025_4_E.pdf