fraud agent merged unrelated chargebacks into one fraud ring

TL;DR

Merging is the most expensive mistake in ring work because it contaminates every case it touches: evidence, customer contacts, and representment narratives all inherit the false link. An agent merges unrelated chargebacks when it treats weak similarities, same BIN, same product, same week, as linkage. Set a merge bar: at least one strong shared identifier, card fingerprint, device, account, exact address, or two independent medium identifiers, before cases can merge, and keep sub case identity inside a merged case so an unmerge restores the originals cleanly.

fraud agent merged unrelated chargebacks into one fraud ring

Use this when

• A ring case contains chargebacks with no identifier in common.
• Analysts repeatedly split agent merged cases.
• One merge pulled in a legitimate customer whose only similarity was product and timing.

Not for this skill when

• A card testing burst shares BIN, IP, and timing tightly. That burst is one event; handle it as an attack case, not a ring merge dispute.
• Cases share a strong identifier and analysts disagree on intent. That is judgment, and the merge should stand with the disagreement noted.

Steps

1. Audit the suspect merged case: list every chargeback and the identifier evidence for its inclusion, marking which inclusions rest only on weak similarity. Verify: the inclusions without strong evidence are named.
2. Define identifier strength tiers with the fraud team: strong, medium, and weak, written down with examples from your own data. Verify: the tier list exists and analysts and the agent config share it.
3. Enforce the merge rule in the agent: merge only on one strong or two medium independent identifiers, otherwise create a linked but separate case with a possible relation note. Verify: a staged pair sharing only BIN and product stays separate with a relation note.
4. Split the contaminated case back into its originals, restoring per case evidence and statuses, and note the bad merge and its cause on each. Verify: every affected chargeback sits in its own correct case again.
5. Track merge precision: sample merged cases monthly for analyst confirmation and report the rate next to ring volume. Verify: the monthly sample shows merge precision at or above the team target.

Variant phrasings

agent merged chargebacks wrongly one case

Wrong merge phrasing.

unrelated disputes grouped as fraud ring

Grouping phrasing.

fraud ring merge criteria too loose

Criteria phrasing.

Compatibility: Any case management or graph investigation tool fed by an agent. Identifier tiers should be tuned per business; a digital goods store and a travel merchant have different strong signals.

Why it happens

Agents optimize for coherence and coverage, and a single big case looks like a better outcome than five small ones. Weak similarities are abundant in payment data because BINs, popular products, and sale weeks are shared by thousands of strangers. Without an explicit merge bar priced in identifier strength, the agent will keep finding those coincidences and calling them structure.

Edge cases / pitfalls

• Merges made before this fix may hide inside closed cases. Sample closed ring cases too, not just open ones.
• An unmerge must not delete the merge history. Auditors and analysts need to see that the cases were once joined and why they were split.
• Household and office sharing creates true strong identifier matches between unrelated buyers. Strong evidence justifies one case file for investigation, not automatic action against every member.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mrLizo9zaX7EnKTau8wNfw