OKX AML Multi-User Case Management
Designing a collaborative investigation workflow for compliance teams reviewing high-risk cases.
Project Snapshot
Role
Senior Product Designer
Team
PM, 2 engineers, Compliance Ops stakeholders
Scope
Internal AML investigation tool
Focus
Designing a multi-reviewer case workflow
Context
AML investigations are rarely a single-person task.
High-risk cases often involve multiple roles — analysts, investigators, team leads, and compliance officers — reviewing evidence, requesting information, and making escalation decisions.
At OKX, our internal case tool was originally designed around single-analyst workflows. As investigation complexity grew, multiple reviewers frequently had to collaborate on the same case.
The system was not designed for that.
Problem
This created operational friction across the investigation process:
• Unclear ownership of decisions
• Reviewers repeating the same checks
• Difficulty tracking case progress
• Fragmented communication between reviewers
• Limited visibility of what had already been reviewed
Investigators often had to reconstruct the case context before they could continue the investigation.
As case volume increased, these inefficiencies slowed down compliance operations.
Design Goal
Design a case workflow that allows multiple investigators to collaborate on the same AML case while maintaining clarity, accountability, and auditability.
The solution needed to:
• Make reviewer ownership clear
• Show investigation progress across roles
• Preserve decision history for audits
• Reduce duplicated work between investigators
Constraints
AML workflows come with several operational constraints:
1. Role hierarchy
Different investigators are responsible for different stages of review.
Example roles:
L1 analyst → initial investigation
L2 investigator → deeper review
Team lead / MLRO → approval or escalation
2. Auditability
Every action must be traceable:
• who reviewed the case
• what decision was made
• what evidence supported it
3. Operational scale
Investigators often handle large case queues, so workflows must support fast context switching.
Design Approach
I redesigned the investigation experience around three key principles.
1. Role-aware workflow
The case lifecycle was structured around investigation stages instead of static screens.
Example flow:
Alert triggered
→ L1 investigation
→ escalation review
→ senior approval
→ case closure
Each role clearly understands what they are responsible for next.
2. Shared investigation context
Every reviewer should immediately understand:
• what signals triggered the case
• what evidence has been reviewed
• what decisions were already made
• what actions remain
This reduces duplicated investigation work.
3. Action-driven interface
Instead of passive data displays, the interface highlights the next investigation actions:
Examples:
Request additional information
Escalate case
Assign reviewer
Close investigation
Key Design Solutions
Case overview
A unified view surfaces the most important case information:
Structured investigation checklist
A guided checklist helps analysts review risk indicators consistently.
Reviewer collaboration
The workflow supports collaboration across investigators:
Success
4.2 days
The payment risk team was able to bring down their average handling time of 11.7 days to 7.5 days. That’s time saving of 35% for each investigation case.
4.2 days
The payment risk team was able to bring down their average handling time of 11.7 days to 7.5 days. That’s time saving of 35% for each investigation case.
10+ minutes saved
From an average time per user takes to send information to operations team drop from 15.1minutes to 5.4minutes. Thats 3X the time saved.
10+ minutes saved
From an average time per user takes to send information to operations team drop from 15.1minutes to 5.4minutes. Thats 3X the time saved.
Design that scales
“Worldcheck” Operational Panel 2.0
Display all relevant information from Worldcheck to enable agent to review all at once
Build proper functionality on BOSS to allow agents to resolve alerts based on specific alert types (e.g., True PEP, True LE).
Ensure that true matches, false matches, and possible matches are categorized and recorded accurately for each alert type.
Enable auditors to easily extract and analyze data through standardized reporting.