Settlement Duplicate Claim & Fraud UI

Quick answer

Duplicate and fraud UI protects settlement funds without accusing claimants in public copy or leaking match details across CLM- records.* Design DUP- match alerts* for admins (same SSN, address, bank account, device fingerprint), FRD- hold states* that pause PAY-* without telling claimants “fraud detected,” and an investigator console that merges eligibility files, documents, and payment history. Claimants see neutral “under review” messaging; investigators see match scores and side-by-side CLM-* diffs. Connect to settlement claims, payment disbursement, eligibility portal, and audit log. Start from the Figma guides hub and pair with forms, tables, and Dev Mode handoff.

Who this is for

Product designers building fraud operations UI for settlement administrators—not consumer banking fraud apps with hard declines.
Investigators and QA teams resolving duplicate filings, synthetic identities, and coordinated abuse before disbursement.
Class counsel who need defensible holds, audit trails, and claimant communications that do not prejudice legitimate claims.

Fraud and duplicate lifecycle overview

FraudCase — FRD-992-0041 · Primary CLM-992-44102 · Status: Under investigation
├── Detection triggers:
│   ├── DUP-* match: same SSN/DOB on two CLM-* records
│   ├── DUP-* match: shared bank account across unrelated claimants
│   ├── Velocity: 50 CLM-* from one IP in 24 hours
│   ├── Eligibility file mismatch vs self-reported identity
│   ├── [Document](/designing-breach-settlement-claim-document-upload-and-evidence-management-ui-in-figma/) reuse hash across CLM-*
│   └── Manual flag from [call center](/designing-breach-call-center-and-agent-script-ui-in-figma/) or REV-* reviewer
├── ID namespace:
│   ├── DUP-* (duplicate match record) · FRD-* (investigation case)
│   ├── CLM-* (claims involved) · PAY-* (blocked when hold active)
│   └── INV-* (investigator notes—internal only)
├── Outcomes:
│   ├── Cleared → Release hold · Resume PAY-*
│   ├── Merged → Close duplicate CLM-* · Single payment
│   ├── Denied → CLM-* rejected · Counsel notification
│   └── Referred → Law enforcement or special counsel (out of UI scope)
└── Claimant messaging: Neutral review language only

Signal strength	Typical action	Claimant sees
Weak (same last name, different SSN)	Queue for batch review	No change
Medium (shared address, different unit)	FRD-* hold · manual compare	”Additional review required”
Strong (duplicate SSN + bank)	Auto hold PAY-* · urgent queue	”Processing delayed”
Confirmed fraud	Deny CLM-* · no “fraud” label to claimant	”Claim not approved”

Verdict: Investigators see matches; claimants see process delays—never “you are a fraudster” in the portal.

Duplicate match types and DUP-* records

DuplicateMatch — DUP-992-0188 · Type: ssn_exact · CLM-A vs CLM-B
├── Match types (configurable weights):
│   ├── ssn_exact · ssn_fuzzy (transposition typo)
│   ├── dob_name_combo · email_exact · phone_exact
│   ├── mailing_address_normalized · bank_account_last4
│   ├── device_fingerprint · ip_subnet_cluster
│   └── doc_file_hash (same [DOC-* upload](/designing-breach-settlement-claim-document-upload-and-evidence-management-ui-in-figma/))
├── DUP-* record fields:
│   ├── match_type · confidence_score (internal)
│   ├── clm_ids[] · detected_at · detection_source
│   └── status: open · linked_to_frd · cleared · merged
├── Auto-actions by score:
│   ├── Score ≥ 90 → Create FRD-* · Hold all PAY-* on involved CLM-*
│   ├── Score 70–89 → DUP-* queue for human triage
│   └── Score < 70 → Log only · batch weekly review
└── False positive handling:
    ├── Household legitimate duplicates (spouse filings) → Merge or link
    └── [Minor/guardian](/designing-breach-settlement-minor-claimant-and-guardian-designation-ui-in-figma/) shared address expected

Publish match type legend in admin docs—designers label investigator UI with match type badges, not raw algorithm names.

FRD-* hold states and payment blocks

FraudHold — FRD-992-0041 · CLM-992-44102 · PAY-* blocked
├── Hold effects:
│   ├── Block new PAY-* initiation
│   ├── Pause in-flight PAY-* if status allows recall
│   ├── Block [amendment](/designing-breach-settlement-claim-amendment-and-correction-ui-in-figma/) that changes payee
│   └── Allow contact info updates (optional—configurable)
├── Hold reasons (internal enum):
│   ├── duplicate_claim · identity_mismatch · document_fraud
│   ├── velocity_abuse · bank_risk · manual_referral
│   └── eligibility_dispute (may route to [disputes](/designing-breach-settlement-claims-dispute-and-appeals-ui-in-figma/) instead)
├── Release workflow:
│   ├── Investigator marks cleared → FRD-* closed · AUD-* entry
│   ├── PAY-* queue resumes · Claimant optional notification
│   └── Partial release: clear one CLM-* · keep hold on linked duplicate
└── Status portal (claimant):
    ├── Banner: "Your claim requires additional verification"
    ├── No mention of DUP-* · FRD-* · or other CLM-* IDs
    └── CTA: Upload requested docs · Contact support

Integrate hold flags with payment disbursement—PAY-* components read frd_hold_active.

Investigator console layout

InvestigatorConsole — FRD-992-0041 · Priority: High · 2 linked CLM-*
├── Queue list (sortable):
│   ├── FRD-* ID · Match type · Score · Age · PAY-* $ at risk
│   ├── Assigned investigator · SLA breach flag
│   └── Bulk: Assign · Export for counsel
├── Case detail — split view:
│   ├── Left: CLM-* A vs CLM-* B side-by-side
│   │   ├── Identity fields · Address · Bank · Filed date · IP/device
│   │   └── Highlight diffs in yellow
│   ├── Center: Timeline (AMD-*, DOC-*, PAY-*, login events)
│   └── Right: Actions + INV-* notes (append-only)
├── Evidence panel:
│   ├── [DOC-* viewer](/designing-breach-settlement-claim-document-upload-and-evidence-management-ui-in-figma/) for both claims
│   ├── Eligibility file row match/mismatch
│   └── [Eligibility portal](/designing-breach-victim-eligibility-verification-portal-ui-in-figma/) verification status
├── Decision actions:
│   ├── Clear FRD-* · Release holds
│   ├── Merge CLM-* → Keep primary · Close duplicate with reason
│   ├── Deny CLM-* → Denial reason code · Counsel flag
│   ├── Request evidence → ACT-* on both portals
│   └── Escalate → Senior review · Legal
└── Audit: frd_id · inv_id · decision · clm_ids · pay_amount_held · decided_at

Use tables for queue lists and side-by-side comparison cards for CLM-* diff—critical for investigator speed.

Claimant-safe messaging matrix

MessagingRules — Never expose investigation details to claimants
├── Allowed copy:
│   ├── "We need additional time to verify your claim"
│   ├── "Please upload the requested documents"
│   ├── "Your claim is under review"
│   └── "We could not approve this claim" (denial—no fraud accusation)
├── Forbidden in claimant UI:
│   ├── "Duplicate claim detected"
│   ├── "Fraud hold" · "Suspicious activity"
│   ├── Other claimants' names · CLM-* IDs · Match scores
│   └── "SSN matches another filer"
├── Email/letter templates:
│   ├── Counsel-approved neutral language
│   └── Separate fraud denial template (legal review)
└── Call center:
    ├── [Agent script](/designing-breach-call-center-and-agent-script-ui-in-figma/) references FRD-* internally
    └── Claimant hears verification language only

Prototype claimant portal + email in the same Figma file with a “public safe” component variant.

Comparison: fraud UI vs adjacent settlement surfaces

Surface	Focus	This UI adds
Settlement claims	Intake validation	Post-file duplicate detection
Eligibility portal	Am I in the class?	Identity cross-check signals
Payment disbursement	PAY-* execution	Hold before send
Disputes	Claimant-initiated fights	Admin-initiated integrity holds
Audit log	Event history	FRD-* / DUP-* decisions

Handoff checklist (Dev Mode)

DuplicateMatch — dup_id (DUP-*), match_type_enum, confidence_score, clm_ids[], status_enum, detected_at.
FraudCase — frd_id (FRD-*), primary_clm_id, linked_clm_ids[], hold_reason_enum, pay_block_active, investigator_id.
InvestigatorConsole — frd_id, side_by_side_field_map[], timeline_events[], decision_enum, inv_notes[].
FraudHold — clm_id, frd_id, pay_ids_blocked[], hold_started_at, release_at, claimant_message_key.
MessagingRules — surface_enum (portal/email/call), safe_copy_key, forbidden_terms[].

Common mistakes

Mistake	Why it hurts	Fix
Show “fraud detected” to claimants	Defamation · litigation	Neutral review copy
Display other CLM-* PII in compare	Privacy violation	Investigator role only
Auto-deny on weak match	Legitimate claim loss	Score tiers + human review
No PAY-* block on strong match	Double payout	Auto hold ≥ threshold
Investigator notes editable/deletable	Audit failure	Append-only INV-*
Skip household duplicate rules	False FRD-* on families	Configurable exceptions
Same queue as disputes	Wrong SLA · training	Separate FRD-* queue
Leak match score in API	Gaming · privacy	Internal API only
Clear hold without AUD-*	Court accounting gap	Log every release/deny
Block all portal access on hold	Claimant can’t upload proof	Allow ACT-* doc uploads

Recommended workflow

Define match types and score thresholds with counsel and fraud vendor before UI.
Design investigator console with side-by-side CLM-* diff and DOC-* viewer embed.
Map FRD- hold to PAY- block** states in disbursement flows.
Prototype claimant-safe messaging for hold, request, and denial paths.
Connect call center scripts to FRD-* lookup without exposing details to claimants.
Export FRD- decision log* for final accounting and counsel.

FAQ

Legitimate duplicate (user filed twice by mistake)?

Merge workflow · Keep earliest CLM-* · Close duplicate · Single PAY-* · Neutral email: “We consolidated your submissions.”

Shared bank account (joint household)?

Household exception rule · Investigator clears · Link CLM-* notes · Do not auto-deny.

Fraud confirmed—what does claimant see?

Denial with generic reason · Appeal path if order allows · Never “fraud” in UI copy without counsel approval.

DUP-* from foreign claimant address formats?

Normalize addresses before match · Reduce false DUP-* on formatting differences.

Integration with tax reporting?

Hold TAX- generation* when FRD-* active on paid-bound CLM-* · Release triggers W-9 regen if identity changed.

Next steps

Design breach settlement claim document upload and evidence management UI in Figma — Document hash and ID review
Design breach settlement payment disbursement and payout tracking UI in Figma — PAY-* hold integration
Design breach victim eligibility verification portal UI in Figma — Upstream identity checks
Design breach settlement claims dispute and appeals UI in Figma — Claimant-initiated challenges
Design audit log and security activity UI in Figma — FRD-* decision audit trail

Designing breach settlement duplicate claim detection and fraud prevention UI in Figma: DUP-* alerts, hold queues, and investigator console