Graph Analytics
Modeling accounts, devices, instruments, payout destinations and transactions as a connected graph to expose rings, mule networks, farms and collusion invisible at the single-account level.
What it is
Single-account detection asks "is this account bad?" Graph analytics asks "who is this account connected to, and what does the neighborhood look like?" Organized transaction fraud scales by reusing scarce resources: devices, payout destinations, identity elements, phone numbers, proxies and people. Every reuse is an edge. Graph analytics turns those edges into detection, investigation and enforcement.
It works at three levels:
- Link lookups: one-hop questions at decision time ("has this payout destination been used by other accounts?"). See Entity Link Analysis.
- Graph features: computed properties of an entity's neighborhood (cluster size, distance to known-bad, density) fed into Machine Learning Models and the Rules Engine.
- Network investigation: analysts exploring clusters visually to scope a ring, gather evidence and coordinate a takedown (Playbook - Fraud Ring Investigation Members).
What it stops (and what it doesn't)
Stops well:
| Pattern | What the graph shows |
|---|---|
| Rings and farms | Clusters of accounts sharing devices, destinations or identity fragments, often with synchronized behavior |
| Mule networks | Fan-in and fan-out money flows, layered transfers and shared cash-out destinations (Money Mules, Fast In Fast Out Patterns) |
| Referral abuse | Cycles, deep chains and dense referral clusters (Referral Graph Patterns) |
| Collusion | Buyer-seller pairs that transact repeatedly and share infrastructure (Triangulation Fraud, marketplace collusion) |
| Coordinated trading | Many compromised accounts buying the same thin security in a narrow window (Ramp-and-Dump via Account Takeover) |
| Blast-radius scoping | Once one account is confirmed bad, the full set of accounts to review |
Doesn't stop:
- First-time lone actors with no connections.
- Disciplined rings that rotate every identifier. Graph pressure forces them to pay for fresh infrastructure on every account, which is still a win.
- Victim-authorized scams at the sender side. Graph analytics is more useful on the receiving or mule side.
Design considerations
Entity resolution first
Two records that are the same person but don't resolve leave a hole in the graph. Two different people wrongly merged create a false ring. Invest in normalization and resolution before graph algorithms (Fraud Data Architecture).
Edge types and weights
Choose edge types deliberately and weight them, because shared attributes vary a lot in what they prove:
| Edge type | Strength | Collision risk |
|---|---|---|
| Same payout destination (Payee and Counterparty Risk) | Strong | Low (but watch pooled accounts at payment platforms) |
| Same identity document or SSN | Strong | Low (identity theft victims excepted) |
| Same payment instrument | Strong | Low to medium (family cards) |
| Same device (high-quality fingerprint; see Device Reputation and Linkage) | Medium to strong | Medium (shared family devices) |
| Same phone or email | Medium | Medium (recycled numbers; shared family email) |
| Same physical address | Medium | High (apartments, dorms, forwarders) |
| Same IP | Weak | Very high (carrier NAT, VPN, campus networks) |
| Money flow between accounts | Strong for mule and collusion | Context-dependent |
| Referral relationship | Declared link | Low |
Supernodes
Some nodes connect to thousands of accounts: a corporate VPN exit, a popular freight forwarder, a default device fingerprint, a payment platform's pooled account. Unhandled, they collapse your graph into one giant component. Cap or exclude high-degree nodes, or down-weight edges through them.
Time
Edges should carry timestamps. A device shared five years ago means less than one shared today. Synchronized creation times and activity bursts are strong ring signals.
Useful patterns (conceptual)
- Connected components and community detection: clusters sharing infrastructure.
- Distance to known-bad: how many hops to a confirmed-fraud entity.
- Fan-in and fan-out: many senders to one receiver, or one sender to many receivers.
- Cycles: money or referrals that loop back.
- Structural similarity: clusters that look like previously confirmed rings.
Real-time versus batch
One-hop lookups and precomputed graph features can run in real time. Community detection and deep traversal usually run in batch, with results fed back as features or review cases. Most programs start with batch.
Victims and innocent links
Shared attributes don't prove guilt. ATO victims' identifiers, family devices and roommates' addresses all create edges. Graph-driven enforcement should require multiple strong edges or behavioral corroboration, and reviewers should confirm before mass action.
Coordinated takedowns
Taking down a ring one account at a time teaches the ring which accounts you found. Scope the cluster first, then act on all of it at once, including payouts, linked destinations and list entries (Negative Lists and Deny Lists).
Illustrative: four accounts that look independent one at a time form a single cluster through a shared device, a payout destination, a phone and a referral edge.
Implementation path
| Stage | What it looks like | Prerequisites |
|---|---|---|
| Crawl | SQL-based link lookups ("other accounts using this payout destination or device"); analyst-driven investigation with exports to a visualization tool | Clean identifiers on accounts, devices, instruments and destinations |
| Walk | Entity resolution service; batch graph build with weighted, timestamped edges; connected components and distance-to-bad features; cluster review queue; supernode handling | Fraud Data Architecture; Case Management Systems with cluster-level cases |
| Run | Graph database or graph-serving layer for real-time neighborhood features; community detection and structural similarity; graph ML features in production models; coordinated takedown workflows; consortium-enriched edges | Machine Learning Models; Consortium and Data Sharing; investigation team |
Customer friction and trade-offs
Graph analytics is invisible to customers until enforcement. The risk is guilt by association: a household, a shared office device or a roommate's address can link a good customer to a bad cluster. Require corroboration before enforcement. Prefer step-up or review over automated blocks for weak-edge links. Make sure support can see and explain a linkage-driven restriction internally.
Measuring effectiveness
| Metric | Definition |
|---|---|
| Cluster precision | Share of flagged clusters confirmed as fraud on review |
| Incremental catch | Accounts found through graph expansion that individual-account controls missed |
| Loss prevented per ring takedown | Includes pending payouts frozen |
| Recidivism | Share of takedown clusters that reappear with new accounts linked to old infrastructure |
| Time to scope | Time from first confirmed account to full cluster scoped |
| False-link rate | Good customers wrongly linked (from appeals and QA) |
Common failure modes
- Weak entity resolution, causing fragmented or wrongly merged graphs.
- Supernodes collapsing the graph.
- IP and address edges treated as strong evidence.
- Picking off ring accounts one at a time.
- Graph built for visualization but never wired into decisions or review queues.
- No timestamps on edges, so stale links count as current.
- Investigators without access to the graph, or without training to read it.
Regulatory and policy notes
- Privacy: graph analytics combines personal data across accounts. Ensure your privacy notice and data-use policies cover fraud prevention linkage, and apply retention limits (Privacy and Data Use in Fraud Prevention).
- SAR quality: network-level findings make stronger SARs. Graph exports and narratives help investigators describe relationships (BSA-AML and SAR Filing, Case Documentation Standards).
- Cross-institution graphs: linking your graph with other institutions' data requires a legal basis such as 314(b) for financial institutions (Consortium and Data Sharing).
- Regulatory expectation: FINRA's 2026 oversight report lists comparing new applications against existing accounts for shared emails, phones and addresses, and looking for similar accounts opened around the same time after an attempted fraudulent opening, as effective practices against new account fraud.
Mechanisms addressed
Fraud Rings and Collusion · Money Mules · Multi-Accounting · Referral Abuse · Account Farming and Resale · Synthetic Identity Fraud · Device Farms and Emulators · Triangulation Fraud · Ramp-and-Dump via Account Takeover · Receipt Fraud (Cashback) (shared receipts) · Sign-Up Bonus Abuse
Related controls
Machine Learning Models · Rules Engine · Negative Lists and Deny Lists · Referral Program Controls · Consortium and Data Sharing · Case Management Systems · Transaction Monitoring · Controls Index
See also Open Source Tools for Fraud Teams and Entity Resolution.
Sources and further reading
- FINRA 2026 Annual Regulatory Oversight Report: AML, Fraud and Sanctions: shared identifiers across seemingly unrelated accounts; finding similar accounts after a fraudulent opening
- MoFo: FinCEN Expands Section 314(b) Information-Sharing Guidance to Incorporate Fraud (June 2026): multiple accounts with the same identifying information as a shareable indicator; cross-institution linkage
- FinCEN Alert on Pig Butchering (FIN-2023-Alert005): network and money-flow red flags in investment scams