AML & Financial Crime Detection

Anti-money-laundering (AML) and financial-crime investigation is a graph problem: sanctions screening, PEP status, prior SAR filings, and transaction-ring topology all live on the same set of connected entities. Purple8 Graph runs all of it — storage, vector search, and graph analytics — in a single embedded engine, so the investigation platform is one query away instead of a pipeline across a case-management tool, a separate graph database, and a batch fraud-scoring job.

✅ Live today

Capability	Built on	Guide
Ring / cycle detection (circular transfer patterns)	Cypher pattern matching	Fraud & Anomaly Detection
Dense-community / ring scoring	Louvain community detection	Graph Analytics — Community Detection
Money-mule / hub identification	PageRank, Betweenness Centrality	Graph Analytics
Structuring / layering path tracing	Shortest Path (Dijkstra)	Graph Analytics — Shortest Path
Sanctions / PEP / prior-SAR hard-veto escalation	Node property flags + edge traversal (SAR_FILED)	this page
Self-tuning detection thresholds	Built-in evolutionary optimization framework	this page
Case lifecycle, SLA, and human-in-the-loop review	Journey Engine	Journey Engine
Encryption at rest for entity/transaction data	AES-256-GCM envelope encryption (local, AWS, GCP, Azure, Vault)	Encryption & KMS
Per-tenant data isolation for multi-institution deployments	Shared-key or dedicated-DB tenancy	Multi-tenancy

Hard-veto risk scoring pattern

A common pitfall in additive risk scoring (score = base + sanctions_weight + community_weight + typology_weight + ...) is that an entity with only a typology signal — no sanctions hit, no PEP flag, no prior SAR — can score low enough to fast-path through review even though a single strong signal should mandate escalation on its own.

Purple8-based AML pipelines pair the weighted score with an independent hard-veto check: if any of sanctions hit, PEP status, prior SAR filed, or a matched laundering typology fires, the case is floored at a minimum risk label regardless of the additive total.

MATCH (e:Entity {id: $entity_id})
OPTIONAL MATCH (e)-[:SAR_FILED]->(prior:SAR)
RETURN
  e.sanctions_hit AS sanctions_hit,
  e.pep_status AS pep_status,
  count(prior) > 0 AS prior_sar_filed

hard_veto = sanctions_hit OR pep_status OR prior_sar_filed OR typology_matched
risk_label = max(additive_risk_label, "medium") if hard_veto else additive_risk_label

Ring / transaction-cycle detection

MATCH (a:Account)-[:SENT]->(t:Transaction)-[:RECEIVED_BY]->(b:Account)
WHERE t.amount > 10000
  AND (b)-[:SENT]->(:Transaction)-[:RECEIVED_BY]->(a)
RETURN a.id, b.id, count(t) AS suspicious_transfers
ORDER BY suspicious_transfers DESC

Dense-ring community scoring

GET /algorithms/communities?top_k=20

result = engine.detect_communities()
rings = {cid: sz for cid, sz in result.community_sizes.items() if sz > 3}

Community density and modularity scores from the same label-propagation pass are the input to the "dense-ring" flag — no separate ML model is required for this signal today. Filter to the relevant subgraph (e.g. Account nodes connected by TRANSFERRED_TO edges) upstream by scoping which nodes/edges you write into the graph, since detect_communities() operates on the full graph.

Self-tuning detection thresholds

Static, hand-tuned risk-scoring thresholds drift out of date as transaction patterns evolve — a threshold set that hits the right precision/recall balance at launch quietly degrades as new typologies emerge and investigator alert-capacity constraints change.

Purple8 Graph includes a built-in evolutionary optimization framework that AML deployments can use to continuously calibrate detection sensitivity against multiple competing objectives at once — precision, recall, investigator alert-volume capacity, and SLA — rather than optimizing a single metric in isolation. Key characteristics:

• Multi-objective, not single-score. Threshold and weighting configurations are evaluated across several objectives simultaneously, surfacing the trade-off frontier (e.g. "higher recall configurations that stay within alert-capacity limits") instead of collapsing everything into one composite score.
• Novelty-aware. The framework can reward configurations that surface previously unseen alerting patterns, helping catch emerging typologies that a fixed rule set would otherwise miss.
• Safe promotion path. Candidate configurations are validated in shadow mode against historical and live traffic before being promoted to production — no configuration change reaches live scoring without being evaluated first.
• Adversarial robustness testing. The same framework can pit a detection configuration against an evolving adversarial strategy to stress-test how well thresholds hold up against adaptive evasion attempts, rather than assuming static thresholds are permanently robust.

This runs as a background tuning process on top of the scoring pipeline described above — it changes which thresholds and weights the hard-veto and additive scoring logic use, not the underlying graph algorithms themselves. See Evolutionary Optimization for the core engine and Sentinel (POST /sentinel/soc/evolve-thresholds and POST /sentinel/soc/discover-threats) for human-gated threshold promotion.

Related guides

• Graph Analytics — PageRank, Community Detection, Betweenness Centrality, Shortest Path
• Evolutionary Optimization & Sentinel — multi-objective threshold calibration with human-in-the-loop approval
• Fraud & Anomaly Detection use case
• Journey Engine — case management, SLA, human-in-the-loop review
• Encryption & KMS
• Multi-tenancy
• SOC & Anomaly Detection