Papers
Topics
Authors
Recent
Search
2000 character limit reached

RiskTagger: LLM-Driven Crypto AML Annotation

Updated 5 July 2026
  • RiskTagger is a large-language-model-based agent that automatically annotates crypto money-laundering behaviors in Web3 by extracting clues, tracing multi-chain flows, and generating audit-ready risk tags.
  • It processes heterogeneous incident reports and raw on-chain data through a modular pipeline—clue extraction, multi-chain transaction tracing, and narrative explanation for forensic analysis.
  • RiskTagger produces auditor-ready outputs with FATF-aligned evidence dimensions, enabling transparent, scalable AML detection and forensic investigations.

RiskTagger is a large-language-model-based agent for the automatic annotation of crypto money-laundering behaviors in Web3. It transforms open-source incident narratives and raw on-chain traces into structured anti-money laundering datasets with auditor-ready explanations, and is designed to replace or complement human annotators by addressing three linked difficulties: extracting key clues from heterogeneous unstructured reports, reasoning over multichain transaction paths, and producing outputs that remain traceable for compliance and forensic analysis (Lin et al., 12 Oct 2025).

1. Problem setting and operational objective

RiskTagger is situated in the anti-money-laundering problem created by decentralized finance, pseudonymous addresses, multi-hop decentralized exchange flows, and cross-chain bridges or mixers. In this setting, laundering behavior is both covert and topologically distributed: assets move across chains, tokens, and intermediaries, while publicly available labels often remain shallow, marking only source addresses and lagging rapidly changing laundering tactics. The immediate consequence is that high-quality AML datasets are difficult to construct at scale, even though such datasets are foundational for risk-control systems and on-chain forensic analysis (Lin et al., 12 Oct 2025).

The system defines annotation as a three-part task. First, it must extract key clues from unstructured reports, such as seed addresses, stolen assets and amounts, and timeframe. Second, it must fetch and reason over multichain transaction data in order to label suspicious addresses and paths. Third, it must generate auditor-friendly explanations linking those labels to concrete evidence. This operationalization is narrower than general financial crime detection: it focuses on on-chain criminal incidents and laundering tied to known illicit origins, rather than fiat on/off-ramps, darknet-only activity, or NFT wash trading.

RiskTagger’s target outputs are explicitly structured. At the account level it emits risk tags in the set {High,Medium,Low,None}\{\text{High}, \text{Medium}, \text{Low}, \text{None}\}. It also emits behavior evidence as JSON fields organized along four FATF-aligned dimensions—transaction patterns, fund flows, associated addresses, and temporal or behavioral signs—each containing both a result and supporting evidence. Finally, it produces a human-readable report linking the assigned tag to transaction hashes, timestamps, token amounts, addresses, chain names, and bridge names. The design therefore treats annotation not as a bare classification problem, but as a dataset-construction pipeline with evidentiary traceability.

2. End-to-end architecture

RiskTagger is organized as a modular pipeline comprising a Key-clue Extractor, a Laundering Tracer, and a Dataset Explainer. The Laundering Tracer itself alternates among a Fetcher, a Translator, and a Reasoner, expanding suspicious paths hop by hop until convergence or a depth limit is reached (Lin et al., 12 Oct 2025).

Module Primary function Main output
Key-clue Extractor Converts unstructured reports and posts into normalized clues JSON schema of incident clues
Laundering Tracer Fetches multichain data, prunes subgraphs, reasons over suspicious paths Account labels plus dimension-wise evidence
Dataset Explainer Converts annotations into audit-ready narrative form Human-readable investigative report

The Key-clue Extractor ingests heterogeneous materials, including PDF and HTML reports and incident posts. It normalizes them into a JSON schema containing items such as affected chain, attacker and victim addresses, and stolen token and amount fields. The Laundering Tracer then uses those clues as seeds. Its Fetcher retrieves intra-chain data with BlockchainSpider and cross-chain associations with Connector; its Translator converts raw transaction data into a pruned and statistically summarized JSON representation suitable for LLM consumption; and its Reasoner applies chain-of-thought prompts and a self-reflection prompt to assign suspicion levels and extract evidence across the four FATF-aligned dimensions. The Dataset Explainer then composes these outputs into an audit-oriented report with an incident overview, dataset summary, risk account analyses, typical laundering patterns, temporal behaviors, and recommendations for audit triage.

This architecture is significant because it binds document understanding, transaction tracing, and narrative explanation into a single annotation loop. Manual workflows often separate these activities; RiskTagger instead treats them as coupled stages in a common evidence pipeline. A plausible implication is that the quality of later stages depends directly on how well early-stage clue normalization constrains the tracer’s frontier and the explainer’s evidentiary references.

3. Clue extraction and multichain reasoning methodology

The clue-extraction subsystem uses prompting rather than task-specific fine-tuning. Its procedure is two-stage. Documents are first split by pages, paragraphs, or semantic boundaries into chunks with identifiers and locations. A fixed LLM prompt then performs per-chunk summarization to extract candidate clues such as chain, attack vector, attacker or victim addresses, stolen USD value, and token breakdown. A second LLM call performs global consolidation, resolving conflicts, de-duplicating entries, and normalizing the output to a predefined schema. The authors report the use of Qwen3-Max with temperature $0.3$ for determinism (Lin et al., 12 Oct 2025).

The tracing subsystem formalizes each chain cc as an address-centric transaction subgraph

Gc=(Vc,Ec),G_c = (V_c, E_c),

where VcV_c are addresses or contracts and EcE_c are edges typed by transaction or event semantics, including simple transfers, token transfers, and contract calls. Raw records include hash, from, to, value, timeStamp, blockNumber, tokenSymbol, contractAddress, and isError/input/nonce/gas-related fields. Cross-chain continuity is modeled through Connector, which links deposit-side and withdrawal-side transactions into tuples

(txsrc,txdst,meta),(tx_{src}, tx_{dst}, meta),

with token, amount, and timestamp metadata.

The Translator is a context-management layer. It constructs and prunes transaction subgraphs, retaining up to kk representative transactions prioritized by value sensitivity and temporal recency, extracts summary statistics such as in/out counts and amount aggregates, and serializes the result as compact JSON. The Reasoner then executes the main iterative loop. Starting from seed candidates CinitialC_{initial} and maximum depth DD, it fetches intra-chain and cross-chain linkages, translates them into JSON with top-$0.3$0 records and statistics, applies chain-of-thought prompts across the four evidence dimensions, triggers self-reflection to check logical consistency and mitigate hallucinations, and propagates out-neighbor addresses of risky nodes to the next frontier while filtering duplicates, loops, and low-signal nodes. In the Bybit case, the process converges by 20 layers.

A central technical point is that RiskTagger is not described as a supervised classifier. The paper states that classification is rule-guided by the chain-of-thought prompt and that no supervised classifier is trained. This places the system closer to a prompt-mediated reasoning agent over curated graph evidence than to a conventional graph neural network or labeled-sequence predictor.

4. Risk taxonomy, evidence model, and explanation layer

RiskTagger’s account-level taxonomy consists of four labels: High, Medium, Low, and None. These labels are justified through four FATF-aligned evidence dimensions represented as JSON fields. The first, a_transaction_patterns, captures anomalies such as high-frequency bursts, large-value aggregates, near-threshold or round-number transfers, and self-transfers or reversals. The second, b_fund_flows, captures aggregation-to-dispersion patterns, layering through intermediaries, DEX swaps, and stablecoin conversions. The third, c_associated_addresses, records links to mixers, darknet, sanctioned, or other high-risk addresses, stealth or zero-history wallets, and externally labeled exploit addresses. The fourth, d_temporal_behavioral_signs, captures off-hours spikes and abrupt regime shifts in activity (Lin et al., 12 Oct 2025).

The explanations surface a more concrete behavioral vocabulary, including cross-chain bridging, mixing, stablecoin aggregation, and token swaps. These behavior classes are highlighted by the Explainer and linked directly to evidence references. The report generation prompt directs the LLM to produce an incident overview, a dataset summary, analyses of risky accounts, characteristic laundering patterns, temporal behaviors, bridge and DEX usage, and recommendations for audit triage. Narrative evidence includes transaction hashes, timestamps, asset amounts, addresses, and chain or bridge names; the paper explicitly notes references such as “THORChain” accompanied by concrete transaction hashes.

This evidence model addresses a common misconception about automated AML annotation: the system is not merely assigning a score. It is also producing dimension-wise evidence and a narrative explanation that can be audited against the underlying transactions. The distinction matters because the stated objective is not just detection, but dataset construction with transparency. The JSON evidence fields and generated report together form an auditable intermediate artifact between raw blockchain events and downstream compliance analysis.

5. Bybit Hack case study and empirical evaluation

RiskTagger is evaluated on the Bybit Hack, described in the paper as one of the largest exchange-theft cases, with approximately $0.3$1 stolen on February 21, 2025, across ETH and liquid staking derivatives. The incident summary states that attackers compromised the Safe{Wallet} frontend via malicious JS injection, then hijacked contract logic with DELEGATECALL to drain the cold wallet. The stolen assets are listed as 401,000 ETH, 90,000 stETH, 15,000 cmETH, and 8,000 mETH. Ethereum is the primary chain, with cross-chain movement through bridges such as THORChain (Lin et al., 12 Oct 2025).

The evaluation reports three headline metrics. Clue extraction accuracy is measured against a gold set annotated by two authors with arbitration on disagreements, and is reported as 100% for all mandatory fields in Table 1. The generic formalization is

$0.3$2

Consistency with expert judgment is evaluated on a stratified 5% sample from 2,246 total accounts, comprising 1,246 suspected and 1,000 normal accounts, yielding $0.3$3. Two expert annotators label risk levels, with majority vote determining the final gold label and Etherscan “Bybit Hack” tags mapped to High risk. Agreement is reported as

$0.3$4

with the generic form

$0.3$5

The confusion matrix diagonal reported in Table 3 is High = 10, Medium = 7, Low = 33, None = 45, and the errors are said to be conservative near class boundaries. Explanation generation coverage is defined as

$0.3$6

and the average result is 90%.

The label distribution on the Bybit data consists of 1,246 suspicious accounts and 1,000 normal controls. Among the suspicious accounts, 59.3% are Low risk (741), 22.7% are Medium risk (284), and 17.7% are High risk (221). The paper also provides a concrete traced example: address 0xa44d… is labeled Medium risk, with a path showing aggregation and layering across multiple intermediaries, followed by a THORChain bridge transfer through transaction 0x0c284…, converting Ethereum assets into BTC/RUNE. This example clarifies that the system is not restricted to source-adjacent addresses; it tracks downstream laundering structure across multiple hops and chains.

The comparison baseline is primarily manual tagging. Public Etherscan tags mark more than 70 addresses as “Bybit Exploit,” but mostly only at the source or near-source level, yielding shallow coverage and limited downstream traceability. RiskTagger’s quantitative head-to-head time or cost baselines are not reported, but its iterative expansion to 20 layers, breadth of 1,246 suspicious addresses, and 90% explanation coverage are presented as evidence of broader coverage and higher auditability than manual-only workflows.

6. Reliability, limitations, reproducibility, and broader significance

RiskTagger includes several reliability mechanisms. Chain-of-thought prompts are aligned to FATF red flags, and a self-reflection stage checks logical coverage, resolves conflicts, and reduces hallucinations and over- or under-classification. The Translator enforces evidence discipline by curating concrete on-chain records, while the Reasoner is required to cite specific transaction evidence per dimension. Search control is handled by a filter module that curbs frontier explosion through de-duplication, loop breaking, and prioritization by recency, value salience, and red-flag consistency (Lin et al., 12 Oct 2025).

Its limitations are explicit. The current implementation targets EVM chains; extending it to Solana or Bitcoin requires new parsers, normalizers, and templates. It depends on BlockchainSpider and Connector, so coverage is constrained by public APIs, event schemas, and bridge observability. Reported failure cases include false negatives arising from conservative treatment of small-value micro-transfers and a misclassification of a Bybit exchange address as High risk because authoritative exchange labels were not integrated. Cost, latency, and bias are not reported. Cross-chain opacity and novel laundering tactics are also identified as challenges for generalization.

The system is reproducible in an operational sense. The paper provides an open-source repository at https://github.com/Connector-Tool/RiskTagger, and outlines a four-step reproduction path: run the Extractor on the Rekt Bybit report, seed the Laundering Tracer with extracted attacker and victim addresses, set $0.3$7 and run BlockchainSpider and Connector, sample 5% for manual evaluation to match Table 3, and run the Explainer to generate the report and compute $0.3$8. Future work includes multi-agent reasoning and reflection, temporal reasoning, lifelong adaptation to new laundering typologies, incorporation of authoritative labels such as Etherscan and SlowMist, integration of regulatory blacklists, construction of a gold-standard AML benchmarking corpus, and deployment for real-time forensic assistance and interactive audit tooling.

In adjacent arXiv work, risk tagging has also been operationalized for EU AI Act self-assessment (Davvetas et al., 23 Jul 2025), radiography triage (Kougia et al., 2020), and taxonomy-aligned extraction from 10-K filings (Dolphin et al., 21 Jan 2026). This suggests that RiskTagger is best understood not only as a Web3 AML agent, but also as an instance of a broader technical pattern: structured, explainable risk annotation over heterogeneous inputs. Within that broader pattern, the distinctive contribution of the Web3 system is its combination of unstructured incident parsing, multichain graph tracing, FATF-aligned evidence extraction, and audit-ready explanation in a single end-to-end AML annotation pipeline.

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to RiskTagger.