Crypto-asset transaction monitoring & blockchain forensics

Public blockchains record every transfer, but addresses are pseudonymous and funds can be split, bridged between chains and mixed within minutes. Specialist analytics platforms attribute addresses to real-world entities, score the risk of each deposit or withdrawal in real time and let investigators trace funds across chains; machine learning and, increasingly, LLM agents triage alerts and draft case files. For regulated crypto-asset service providers (CASPs), banks with crypto exposure and authorities, this is the crypto equivalent of AML transaction monitoring (ANOM-002).

Problem & value

• Today: CASPs, exchanges, custodians and banks must screen counterparties and detect suspicious flows. Manually following funds through explorers does not scale, and obfuscation (peel chains, mixers, cross-chain bridges, stablecoin hopping) defeats simple rules.
• AI value: attribution-based risk scoring (direct and indirect exposure), graph analytics for clustering and flow tracing, supervised models for illicit-pattern detection, and LLM assistants that summarise a case and draft the report. Vendors position AI agents as taking over routine screening and investigation steps while humans approve material decisions [1][2][3].
• Regulatory pull in the EU: MiCA is fully applicable since December 2024 with CASP authorisation (national grandfathering ended at the latest on 1 July 2026) [4]; Regulation (EU) 2023/1113 extends the "Travel Rule" to crypto transfers; the AML Regulation (EU) 2024/1624 applies from July 2027 and AMLA (Frankfurt) is building its supervisory role [5][6]. Authorised CASPs therefore need documented, auditable transaction monitoring.
• No reliable public figure for the share of illicit volume is quoted here; use vendor annual crime reports as a starting point and treat their numbers as vendor estimates.

Variants

• CASP / exchange compliance (core): pre- and post-transaction screening of deposits, withdrawals and Travel-Rule counterparties.
• Bank / payment-institution exposure: screening of fiat on/off-ramp flows and customers with crypto activity (links to ANOM-002, ANOM-022).
• Investigations (corporate and authorities): case-driven tracing for hacks, ransomware, investment scams; for authorities this is law-enforcement work and is documented here only at policy and architecture level.
• DeFi / smart-contract protocol monitoring: screening of wallets interacting with protocols, detecting exploits in progress.
• Sanctions compliance: wallet-level screening against designated addresses (see ANOM-016).
• Private use: not a consumer use case; individuals can use free explorers and the scam-check features of wallet apps.

How it works

1. chain nodes / indexers (Bitcoin, EVM, Solana, Tron, ...)
2. normalisation into transaction + entity graph
3. address attribution & clustering (exchanges, services, mixers, sanctioned, scams)
4. real-time screening: direct + indirect exposure, rule + ML risk score
5. alert triage (ML ranking, LLM case summary)
6. investigator workbench (graph tracing, cross-chain, Travel-Rule data)
7. human decision (hold / release / offboard)
8. STR/SAR filing, audit log

• Attribution is the moat: curated, evidence-backed labels on millions of addresses; models alone cannot recover identities.
• ML: graph neural networks and tree ensembles classify transactions or addresses; the public Elliptic dataset (200k+ Bitcoin transactions, 166 features, labelled illicit/licit) is the standard benchmark, where Random Forest outperformed GCN in the original paper [7].
• LLM/agents: summarising fund flows, querying the attribution graph in natural language, drafting reports; grounded in vendor attribution data to limit hallucination [1].
• Human-in-the-loop: every freeze, offboarding or SAR/STR decision is made by a compliance officer; models only rank and explain.

Data preparation

Needed data: the institution's own customer, wallet and transaction records, deposit and withdrawal addresses, Travel-Rule messages, KYC files and past alert and SAR outcomes. Blockchain data are public, but attribution data come from vendors. Internally the data sit in the exchange or custody platform, the KYC system, a case tool and spreadsheets of manual investigations.

Typical gaps: customer records not linked to wallet addresses, inconsistent address formats across chains, missing links between alerts and outcomes, scattered investigation notes, and no clear data owner for compliance decisions.

Preparation steps: build a clean mapping of customers to addresses and transactions (see PREP-005, PREP-011), harvest alert dispositions as labels (PREP-020), define a category scheme for risk types such as mixer, sanctions or scam (PREP-019), and collect past SAR cases as a test set (PREP-018). Pseudonymise exports for model development (PREP-022). For own analytics, use Ethereum-ETL or node providers plus a graph database. Vendor APIs handle most chain data, so the effort is mainly integration and label hygiene: about 30 to 40 percent of the project. GUIDE-003 provides a readiness check.

Implementation paths

Which path for whom

• enterprise (CASPs, banks): A, because regulator-accepted attribution labels on millions of addresses are the moat and cannot be built in-house; B adds custom workflow on top.
• developer: C, because open-source extraction and graph tooling allow research and complementary analytics, though without attribution labels.
• public (law enforcement, supervisors): A, because certified investigation platforms with evidence-grade attribution are the practical route; check EU hosting and procurement rules.

Path A — Buy (recommended)

• Global blockchain-analytics platforms: Chainalysis (KYT for transaction monitoring, Reactor for investigation, Alterya for AI fraud prevention, agents) [2]; Elliptic (Lens screening, Investigator, Discovery for VASP due diligence, copilot) [1]; TRM Labs (monitoring, forensics, Ardence AI investigations platform, strong law-enforcement focus) [3]. Other relevant vendors: Crystal Intelligence (Crystal Blockchain), Merkle Science, Scorechain (Luxembourg, EU), Coinfirm/Lukka, Sumsub and Notabene for Travel-Rule messaging.
• Choose A when: you are a CASP or bank and need defensible, regulator-accepted attribution and coverage of many chains. Check: chain coverage, latency, EU data hosting, explainability of scores, API and case-management integration, Travel-Rule support.

Path B — Build on cloud APIs

• Use vendor screening/KYT APIs inside your own onboarding and withdrawal flow, plus an LLM (EU region of a frontier model provider, or Mistral) for case summaries and STR drafting, orchestrated with n8n or a custom service.
• Public chain data via node providers or BigQuery public datasets (Ethereum-ETL schemas) [8] for own analytics.
• Choose B when: you need custom workflow, scoring blends or reporting on top of purchased attribution.

Path C — Self-host (open source)

• Data layer: own full nodes; Ethereum-ETL (MIT) for extraction [8]; mempool (AGPL, Bitcoin) as self-hosted explorer [9]; graph store such as Neo4j Community (GPLv3) [10] or another graph database.
• Models: PyTorch Geometric (MIT) for GNNs [11], gradient boosting for tabular features; open-weight LLM (e.g. Qwen, Llama, Mistral families) for summaries.
• Limit: open source gives no attribution labels; without a commercial or in-house label set you can detect structure but not identify entities. Suitable for research, small-chain monitoring or as a complement. HW2 is enough for models; nodes need large disks (multi-TB for archive nodes).

Path D — Custom training

Worthwhile only for large operators with proprietary labelled cases (confirmed SARs, offboardings): train GNNs/sequence models on own transaction graph and fine-tune alert-ranking models. Needs thousands of confirmed outcomes; labels from compliance decisions are biased towards what rules already caught, so evaluate carefully.

State of the art (2026)

• Cross-chain tracing and real-time KYT are standard in commercial platforms; vendors now advertise agentic AI that runs routine screening and investigation and asks humans to approve decisions [1][2][3].
• Research: graph learning on the Elliptic dataset remains the reference benchmark, but it is Bitcoin-only, old and small relative to production scale; results often do not transfer to other chains or to adversarial, adapting actors [7].
• Limits and failure modes: attribution gaps and false clustering (shared services, custodial wallets) cause false positives; privacy tools and new chains lag behind coverage; "guilt by association" through indirect exposure can wrongly penalise innocent customers; LLM summaries can misstate flows, so every figure must link to the underlying transactions.

Shared resources & combinations

• Same stack as ANOM-002 (AML transaction monitoring): alert management, case management, STR/SAR workflow, graph analytics; ANOM-016 (sanctions/PEP screening) supplies list matching, ANOM-022 (APP scams and mule accounts) covers the fiat side of scam cash-out, ANOM-001 shares real-time scoring infrastructure, ANOM-014 (ID and liveness) covers onboarding KYC.
• Building blocks: graph database + graph-ml, streaming ingestion, tabular-ml scoring service, LLM case-summary agent (AGENT-006-style workflow); one HW2 GPU server can host models for several ANOM use cases.

Effort, cost & KPIs

• Path A: weeks to a few months (integration, rule tuning, regulator documentation); licence cost scales with volume and chain coverage and is usually quote-based.
• Path B: 3–6 months for integrated workflow plus LLM tooling.
• Path C/D: 6–12+ months and a specialised team; attribution data remains the bottleneck.
• KPIs: alert precision and false-positive rate, time to triage and to SAR filing, screening latency (ms), share of volume with indirect-exposure coverage, confirmed illicit volume prevented, regulator audit findings.

People & change

Involve management, the money-laundering reporting officer and compliance first, since they own risk appetite and SAR decisions. IT and IT security integrate the screening API into onboarding and withdrawal flows; the data protection officer and legal review the vendor contract (Art. 28 GDPR) and the handling of wallet addresses that are linked to identifiable persons, which are personal data. A DPIA is likely where customers are systematically evaluated.

Works council: depends. If the company has one, it is relevant where analyst tools log individual case handling (§87(1) no. 6 BetrVG), but the screening itself monitors customers, not staff; inform it under §90(1) no. 3 anyway. Public authorities involve the staff council.

AI literacy measures (AI Act Art. 4) should support investigators in understanding attribution confidence, indirect exposure and the limits of LLM case summaries. Run a pilot on one product or chain in parallel with the current process and compare alert quality. Typical concerns are false positives that block honest customers and regulatory scrutiny; address them with documented thresholds, a human decision on every freeze, offboarding or SAR, and an audit log. See GUIDE-005, GUIDE-009 and GUIDE-010.

Risks, regulation & compliance

• EU AI Act: typically minimal risk; transaction monitoring for AML is not an Annex III category. Becomes sensitive if scores feed into decisions on access to essential services for natural persons (e.g. creditworthiness, Annex III 5(b)) or if profiling of individuals approaches Art. 5 limits; law-enforcement use falls under separate high-risk and prohibition rules (Art. 5, Annex III 6) and is outside the scope of this entry beyond policy level [12].
• GDPR: addresses linked to identifiable persons are personal data; blockchain immutability conflicts with erasure, so avoid writing personal data on-chain; Art. 22 for solely automated blocking; DPIA recommended; lawful basis typically legal obligation (Art. 6(1)(c)).
• Sector law: MiCA authorisation [4]; Transfer of Funds Regulation (EU) 2023/1113 (Travel Rule, in application since 30 Dec 2024); AMLR (EU) 2024/1624 from July 2027, including restrictions on anonymous crypto accounts and privacy-enhancing coins at CASPs [5]; DORA for ICT resilience of vendors; sanctions regimes (EU lists) are strict-liability in practice [6].
• Mitigations: human decisions on freezes, appeal process for customers, documented model governance, vendor due diligence, evidence trail for each alert.

Getting started

1. Determine your regulatory status (MiCA CASP, bank, other) and the Travel-Rule and monitoring duties that follow.
2. Request demos from 2–3 vendors (e.g. Chainalysis, Elliptic, TRM, Scorechain) and test them on your own historical flagged cases.
3. Integrate screening at deposit, withdrawal and onboarding; define risk thresholds and a four-eyes review for holds.
4. Add case management and an LLM summariser with strict citation of transaction hashes.
5. Track false-positive and time-to-decision KPIs monthly and document the model governance for supervisors.

Sources

1. Elliptic — platform and AI copilot/agent overview — https://www.elliptic.co/
2. Chainalysis — KYT, Reactor, Alterya and AI agents — https://www.chainalysis.com/
3. TRM Labs — Ardence AI investigations platform — https://www.trmlabs.com/
4. ESMA — Markets in Crypto-Assets Regulation (MiCA), application dates and transitional measures — https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica
5. Regulation (EU) 2024/1624 (AML Regulation) — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1624
6. AMLA — EU Anti-Money Laundering Authority — https://www.amla.europa.eu/index_en
7. Weber et al. — Anti-Money Laundering in Bitcoin (Elliptic data set) — https://arxiv.org/abs/1908.02591
8. Ethereum ETL (MIT) — https://github.com/blockchain-etl/ethereum-etl
9. mempool (AGPL-3.0) — https://github.com/mempool/mempool
10. Neo4j Community Edition (GPLv3) — https://github.com/neo4j/neo4j
11. PyTorch Geometric (MIT) — https://github.com/pyg-team/pytorch_geometric
12. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj