How can organisations detect coordinated networks of fraudulent merchants?

How to spot the same fraud pattern across many merchant accounts

The key is to stop reviewing merchants one by one and instead treat them as a linked population. A single bad merchant can look noisy, but coordinated fraud usually leaves repetition: shared onboarding artefacts, reused payout routes, matching device and IP fingerprints, and transaction behaviour that changes in the same way across accounts.

That is why graph-style analysis is so effective. It turns isolated events into relationships, letting analysts see whether merchants share common controllers, infrastructure, or payment endpoints rather than merely having similar business models. The strongest signals are the ones that recur across otherwise unrelated merchants, not the ones that appear once.

Manual review still matters because network detection can surface false clusters. A legitimate franchise, aggregator, or marketplace seller group may share many attributes, so investigators need to test whether the similarity is operationally explained or whether it points to hidden common ownership, collusion, or account farming. The practical question is whether the shared pattern is normal for that segment or too tight to be incidental.

Which signals are most useful for clustering fraudulent merchants?

Shared identity and infrastructure signals are usually the most reliable starting point. Reused bank details, payout destinations, registered addresses, phone numbers, tax identifiers, devices, cookies, browser fingerprints, IP ranges, and onboarding documents can all create a visible network when they are correlated over time. One signal alone is rarely decisive, but multiple weak links often become strong evidence when they stack together.

Transaction behaviour adds another layer. Coordinated merchants often show similar ticket sizes, timing, refund or chargeback patterns, dispute frequency, velocity changes after onboarding, or abrupt shifts in product mix. These are especially useful when they move in sync across accounts, because synchrony is harder to explain away as coincidence.

Analysts should also watch for repeated operational artefacts, such as nearly identical registration data, templated website content, duplicated support contacts, or the same sequence of changes after approval. A good detection model should be built to join these fragments into a cluster, then score the cluster for common control points, not just individual anomalies. NIST Cybersecurity Framework 2.0 is a useful way to organise the workflow from identification through detection and response, while MITRE ATT&CK Enterprise Matrix helps investigators think in terms of repeated behaviour, credential abuse, and linked activity rather than isolated alerts.

How should organisations validate a suspected fraud network?

Validation should combine automation with casework. Graph analysis can surface the cluster, but an investigator should still ask whether the links are mechanically real, commercially normal, or deliberately engineered to blend in. That means checking whether the same person, device family, or payout route appears behind multiple merchants, and whether the businesses share onboarding artefacts or administrative control.

Once a cluster is identified, the next step is to measure whether the suspected network is driving loss through chargebacks, refunds, disputes, or downstream partner complaints. Patterns that are consistent across the cluster are more important than the severity of any one merchant, because coordinated fraud often scales by repeating a modest abuse pattern many times. Fraud operations also often reuse infrastructure, so security teams can benefit from threat-centric correlation across access and infrastructure evidence, not just payments data. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it anchors strong audit, access, and integrity controls that support investigation quality.

When the evidence is mixed, treat the result as a tiered decision rather than a binary one. Strong clusters can be actioned quickly, while weaker clusters may need enhanced monitoring, manual review holds, or additional identity and payout verification before a final enforcement decision. SANS Security Resources are useful for building investigator workflows that combine detection engineering with incident handling discipline.

Risk and Threat Considerations

Coordinated merchant fraud is dangerous because the network effect hides scale. A single merchant may look tolerable, but a linked set can spread losses, reuse compromised or synthetic details, and reappear after one account is closed. The main threat is not just bad transactions, it is repeatable abuse of onboarding, payout, and dispute controls across many accounts.

Failure mechanism: Fraudsters reuse shared identity artefacts, infrastructure, or payout destinations to create multiple merchant accounts that appear separate but behave like one operation.

Impact: Organisations can miss the pattern until chargebacks, losses, or partner complaints accumulate, and enforcement on one merchant may have little effect if the rest of the cluster remains active.

Practitioner Guidance

What to prioritise: Build your first detection rules around relationships, not single-merchant thresholds. Shared bank details, payout destinations, device fingerprints, IP ranges, and onboarding artefacts usually produce faster value than trying to score every merchant in isolation.

What to verify: Before acting on a cluster, verify that the linkage is not explained by a franchise model, shared processor, managed service provider, or other legitimate operating structure. False positives are common when the business model itself creates repeated data.

Practitioner takeaway: The best detection programmes look for coordinated behaviour that survives account boundaries, because fraud networks are built to stay just below the line of any single merchant alert.

Related resources from NHI Mgmt Group

• What breaks when organisations rely only on transaction volume thresholds to detect crypto laundering networks?
• How should security teams detect and disrupt coordinated disinformation networks that target diaspora voters before an election?
• How should organisations detect and disrupt fraudulent IT worker schemes before they move money or data out of the business?
• How should merchants detect coordinated fraud rings without blocking legitimate customers?