Ring detection · graph analysis 2026

Making fraud rings visible in a whole population

A seedless graph that loads an entire account population and lets coordinated rings fall out as clusters — without dragging legitimate customers in with them.

Business Analyst — AWS Payments & Fraud Prevention

Impact

Coordinated rings that were invisible one account at a time became visually obvious clusters an analyst could action in minutes. On a ground-truth ring the graph hit 100% recall in a single component while the key-reliability audit kept legitimate look-alikes out — and the engine scaled from a region cluster to the multi-million-account global population.

Whole-population relations graph
100% of a known ring in one cluster
flagged ring legitimate broker
Hover a node to isolate its component; toggle to strip the legitimate population and leave only the rings. Representative shape — the live graph runs on confidential data.

Edges are hard shared signals weighted by excess-purity-over-base-rate × IDF; brokers are high-betweenness accounts bridging two rings.

Known-ring recall
100%
Every member of a ground-truth ring landed in one rendered cluster.
Re-scoped to
Millions accounts
Ported from a region cluster to the global payments-fraud population.
Context

Coordinated abuse hides in the gaps between accounts. Looked at one at a time, a ring is invisible; looked at as a graph, it's a dense knot in an otherwise sparse field. The catch is that naive linking — share an IP, share a phone format — also ties together thousands of unrelated legitimate customers, so a careless graph just draws one giant useless blob.

What I did

I built a whole-population fraud-relations graph explorer: a Python backend that loads the full account population, builds a two-tier (hard/soft) relationship graph, and renders it client-side over WebGL. The part that makes it actually work is the edge-confidence model — an information-retrieval weighting (excess purity over base rate × IDF) tuned for a fraud-dense population where plain shared-attribute counting is worthless — plus a key-reliability audit that removed identifiers which would have falsely linked legitimate accounts. Connected components surface rings; community detection splits sub-rings; betweenness centrality flags the broker accounts bridging them.

Outcome

Rings render as visually obvious clusters an analyst can act on. On a known ring used as ground truth, the graph placed 100% of its members in a single component — and the same key-reliability audit kept legitimate look-alikes out of those clusters. I then re-pointed the whole engine at the global payments-fraud cluster via a windowed rebuild for multi-million-account scale.

Without this work

Rings stay hidden in pairwise queries — analysts chase members one at a time and miss the brokers bridging rings entirely. And any naive linking graph would have swept thousands of legitimate customers into the same clusters, trading invisible fraud for false accusations.

A ring is invisible one account at a time and obvious as a graph. The whole problem is getting from the first view to the second without building a graph so naive it links half the legitimate population together.

So the work wasn’t the rendering — it was the edges. In a fraud-dense population, “these two accounts share an attribute” is almost meaningless; plenty of legitimate customers share IP ranges, phone formats, and BIN ranges by chance. I weighted every candidate edge by how much more purely it predicts co-fraud than the base rate would, scaled by how rare (informative) the shared signal is — an IR-style excess-purity × IDF score. Then I ran a key-reliability audit and threw out the identifiers that looked linking but were actually shared by unrelated legitimate accounts. That audit is the part that keeps the clusters honest.

With trustworthy edges, the rest is graph mechanics: union-find connected components to surface rings, modularity and label-propagation community detection to split sub-rings, and sampled betweenness centrality to flag the broker accounts that bridge two rings — often the most important ones to action. The frontend renders the whole thing over WebGL with hover-isolation, a weighted shortest-path trace between any two accounts, and one-click legitimate-impact + bulk-close SQL per cluster.

Validation mattered more than visuals: on a ring I already had confirmed, the graph placed 100% of its members in a single component — and the key audit kept the legitimate look-alikes out. Then I re-pointed the same engine at the global payments-fraud cluster with a windowed population rebuild so it holds at multi-million-account scale.

  • Graph analysis
  • sigma.js / WebGL
  • Community detection
  • Betweenness
  • Ring detection