Investigate a Suspicious Payment Pattern
Design an analyst workspace for connecting transaction evidence, testing explanations, and authorizing a proportionate fraud response.
The brief
Understand the problem
Background
Fraud alerts can involve linked accounts, merchants, devices, and transfers. A dense graph may reveal connections but still fail to distinguish verified facts from model signals, analyst hypotheses, and customer-provided context.
User context
Nora investigates six card-not-present purchases across three accounts that share a device fingerprint. One customer is traveling and has confirmed two purchases, while another cannot be reached.
Product problem
An analyst needs to construct a defensible case, avoid contaminating evidence, and choose reversible protections before taking actions that may block legitimate customers.
Objective
Create alert triage, evidence analysis, action proposal, and review for one linked-payment fraud case.
What to design
Define the experience
Required experience
- Review alert basis, affected accounts, transactions, and current protections
- Explore links while distinguishing facts, signals, and hypotheses
- Record customer contact and contradictory evidence
- Propose and obtain approval for proportionate account actions
Screens and states
- Fraud alert queue
- Case evidence workspace
- Action proposal
- Second-review decision
Core user flow
Follow the critical path
- 01
Nora claims the alert and sees the shared-device signal plus transaction chronology
- 02
She confirms that two purchases belong to a traveling customer and separates them from the suspicious cluster
- 03
She records an unsuccessful contact attempt for the second account
- 04
She proposes a temporary card lock and step-up verification rather than closing the account
- 05
A second reviewer approves the action and the case records the evidence basis
Product rules
Requirements and constraints
Requirements
- Separate observed transaction facts, external data, system signals, and analyst conclusions
- Let analysts include and exclude links without deleting source evidence
- Show customer impact and reversibility for each proposed action
- Require reason codes, narrative rationale, and second review for severe restrictions
- Maintain an immutable timeline of evidence access, contact, decisions, and actions
Constraints
- Sensitive customer data must be limited by investigator role and case purpose
- A risk score cannot serve as the only basis for adverse action
- Investigation notes may later require compliance or dispute review
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Transactions
- $486.20 electronics order, Singapore
- $74.90 travel booking, Kuala Lumpur
- $512.00 electronics order, Jakarta
- $18.40 grocery order, Kuala Lumpur
Signals
- Shared device fingerprint
- New shipping address
- Travel notice on one account
- Two successful customer confirmations
Finish line
What to deliver
- Four desktop screens showing alert triage, contradictory evidence, and a reviewed temporary action
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.