TLDR:
- Transaction-level rules are highly effective at stopping known fraud patterns, but they have a structural blind spot: they cannot catch novel, emergent coordination where every account looks legitimate by itself.
- Network Detection finds coordinated accounts proactively by continuously analyzing transaction data for shared signals, assigning strength categories, and surfacing suspicious groups automatically.
- This is for any fraud professional who wants to move from reactive investigations (finding the ring after the damage is done) to proactive detection (stopping the ring as it forms)
- You’ll walk away knowing what coordinated fraud actually looks like, how it evades rules, and how to triage networks effectively.
The Problem: Approved Accounts, Coordinated Theft
Last year, a Buy Now, Pay Later (BNPL) platform approved a slightly higher number of account registrations over a two-week period. Every single one passed their fraud rules. Clean email domains from established providers. Residential IP addresses with proper geolocation. Phone numbers verified and validated. The transaction patterns looked normal: $200 here, $150 there, never tripping an amount threshold or velocity limit.
By the time the team noticed the pattern, the accounts had collectively taken $1.2 million in cash advances. They coordinated perfectly: one account would move money, disappear for three days, then resurface with a different email but the same device. Another would withdraw from a new IP paired with a phone number that appeared elsewhere in the cohort. The attacks were distributed across transactions and accounts in a way that defeated every rule in place.
When the analyst described how she finally caught it, she said, “I noticed the approval velocity looked off that week. I pulled a sample of transactions, started seeing the same device fingerprint across different emails, then traced the phone numbers. It took three hours to confirm we had a group. By then, the damage was done.”
This is not a rare scenario. It’s the structural gap between what rules are designed to do and how fraud rings actually operate.
The Questions Rules Don’t Ask
Rules ask:Does this transaction violate a threshold? They don’t ask: Are these accounts suspicious together?
A sophisticated rule stack — combining device velocity, email domain checks, and IP subnet limits — is highly effective at stopping attacks you have seen before. But rules require prior knowledge. You have to know the pattern to write the rule. If 30 fraudsters each use a shared device once or twice, and deliberately stay under your velocity thresholds, no single account violates the rule. Individually, the accounts appear clean. The network is the problem, and rules aren’t designed to see novel networks.
This is the limitation that transaction-level decisioning can’t solve on its own. No threshold tuning closes the gap. The approach that catches rings requires looking across your customer base, continuously, to find emergent coordination.
How Fraud Teams Detect Fraud Rings Today
The traditional investigation process works, eventually, but it’s also built on friction and is entirely reactive.
The analyst opens a flagged account and starts pulling dimensions: device fingerprints from one system, emails from a second, customer risk scoring from a third. She cross-references dates, notes overlaps and manually expands the network. If she finds ten connected accounts, she repeats the process for each one, looking for the thread. One shared device across two accounts. One shared IP across three. One shared email pattern connects a fourth.
But what if the real connection runs through a dimension she didn’t think to check? What if the ring is connected through browser fingerprints instead of device IDs, or through payment card metadata outside her immediate workflow?
Three hours later, she has a network of 30 accounts and a clear picture of coordinated fraud — caught after the damage is done. The next ring, the next analyst, will start from scratch.
This is how most fraud teams investigate rings today. It works, but it scales on analyst expertise, not on infrastructure. And it misses connections that exist outside the manually checked dimensions.
What Network Detection Shows Instead
Imagine the same scenario, but the cross-referencing happens continuously in the background.
You log in the morning after those 34 accounts generated transactions. A coordinated network surfaces automatically. You don’t have to hunt for it; the system has already grouped the accounts by shared signals.
You see a High-strength network of 34 customers. The system shows you exactly which signals connected them — perhaps a combination of device fingerprints, email domain patterns and phone registration overlaps. You can immediately see the total monetary amount affected and the initial decline rate of the transactions in the group.
Below that, you might see a Medium-strength network of 8 customers connected by IP address, email provider and browser fingerprint. The shared IP could legitimately come from a corporate office or a coworking space — but paired with the matching email provider and browser, it warrants investigation. The analyst examines transaction patterns, approval dates, and behavioral signals. Two accounts look legitimate (employees at the same company). Six accounts look coordinated.
The difference between the manual investigation and Network Detection comes down to four things:
- Proactivity: You see the networks as they form, not after a three-hour reactive investigation.
- Completeness: All configured signal dimensions are checked simultaneously, not just the ones the analyst thinks to check.
- Explainability: Every network shows exactly which signals connected the accounts. No guesswork.
- Prioritization: Strength categories (High, Medium, Low) tell you which networks need urgent action and which need judgment.
Why Signal Quality Matters
Not all shared signals carry equal fraud risk, and teams running Network Detection in production learn this quickly.
One team investigated networks formed solely by shared IP addresses. Most were noise with legitimate users on the same ISP or people in the same office. The same team investigated networks formed through device fingerprints. The signals had wildly different predictive power, but the system had weighted them equally. This is why configurable matching fields and signal weighting exist.
When you deploy Network Detection, you choose which signals matter in your environment. If shared IP addresses generate too much noise because your market has a high concentration of corporate or residential shared networks, you can exclude IP addresses from grouping, or lower their weight. If device fingerprints are your strongest coordinated fraud indicator, you can weight them higher.
Every network shows which signals are connected to the account. If a user appears in a network connected only through date of birth, a weak and relatively common signal, you see that immediately and make a judgment call. The system doesn’t hide the reasoning.
The False Positive Reality
In environments where the dominant shared signals are weak (shared IP addresses, shared browser types, shared email providers), a meaningful percentage of grouped accounts may appear legitimate when investigated manually. This isn’t a failure of Network Detection. It’s the system working correctly, grouping accounts that share attributes. Your job is to determine which networks represent real coordination.
Strength scoring, signal weighting and explainability are what make that judgment fast. A High-strength network connected via hardware fingerprints warrants immediate investigation. A Low-strength network connected only through shared IP warrants a look at transaction patterns and behavioral signals before action. The analyst isn’t overwhelmed by noise. They see the most likely fraud first and have the information to make informed checks about everything else.
Why Rules And Network Detection Are Complementary
Rules and Network Detection ask different questions. Rules operate at transaction-level decisioning — fast, precise, synchronous. They stop individual attacks and known patterns.
Network Detection operates at the portfolio level. It looks across your entire customer base, groups accounts by shared signals and categorizes the likelihood that those groups represent coordinated fraud. It identifies the cohorts that warrant deeper investigation.
These two approaches are complementary, not competitive. Rules stop the attacks you know about. Network Detection surfaces the coordination you haven’t seen yet.
From Detection to Investigation
Network Detection surfaces groups. What you do next is where operational efficiency compounds.
- Morning Network Review: Many teams review networks as part of the daily briefing, looking at new High-strength networks that surfaced overnight, assessing the total exposure and prioritizing investigation. Medium- and Low-level networks are triaged based on exposure or behavioral signals.
- Investigation Workflows: Instead of pulling individual accounts, your workflow builds around networks. You pull a flagged group, examine the shared signals, then layer in behavioral signals — approval velocity, transaction timing, settlement patterns, shipping address concentrations. Does the network show behavioral coordination, or are the shared devices coincidental?
- Scaling Across Teams: If you have multiple fraud analysts, you can build skills that automate morning network review, alert on high-risk patterns, and prepare investigation summaries. The barrier to investigation is lower. The consistency is higher.
The Starting Point, Not the Ceiling
Network Detection doesn’t automatically block new networks. It doesn’t predict which accounts within a network are the primary actors. It doesn’t detect sophisticated rings where fraudsters deliberately avoid shared signals. It doesn’t replace analyst judgment.
What it does is give you the thread. One team using Network Detection identified a large fraud ring — coordinated across 50+ accounts and multiple shared device IDs, email domains, and IP subnets. Expanding beyond the initial group (by following secondary connections between grouped accounts using reactive tools like Graph and Data Explorer) revealed an even wider network, connected to thousands of cards and half a dozen merchant storefronts.
Network Detection surfaced the entry point. Manual network expansion revealed the scope. That’s the typical pattern. Network Detection shows you the obvious coordinated accounts proactively. Your analysts expand from there using domain knowledge, transaction patterns, and external data.
Practitioner Takeaway: The Triage Framework
To operationalize Network Detection without getting buried in noise, adopt a strict triage framework:
- High-Strength Networks: Treat as active incidents. If the connecting signals are strong (e.g., device fingerprints, card hashes), investigate immediately. Look for the “patient zero” account to understand the entry vector.
- Medium-Strength Networks: Filter by exposure. If the total monetary amount or declined transaction percentage is high, escalate. If low, monitor for 48 hours to see if the network expands.
- Low-Strength Networks: Use as feedback for your rules. If a Low-strength network (e.g., connected only by IP and browser) turns out to be fraud, your rules missed it and your Network Detection weights might need tuning. If it’s legitimate, use the exclusion list to suppress those specific shared values in the future.
The question worth sitting with: how many fraud rings has your team missed because you were looking at transactions one at a time? Transaction-level rules are fast, precise, and necessary, but they only catch what you already know to look for. Network Detection runs continuously in the background, groups accounts by shared signals, and surfaces the networks that individual account reviews will never catch — before the damage is done.
