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.
Theory to review
UX principles for this brief
Use these as decision lenses, then validate the design with the people and context in the brief.
