End-to-end • Internal operations • AI-Assisted Workflows
Financial crime investigation platform
What is it:
OKX's compliance operations team reviews thousands of flagged accounts every week for signs of financial crime. Every case ends in a regulated decision: freeze, file, or clear. The tools they use to get there determine both how fast they can work and whether those decisions hold up to scrutiny.
Investigation at scale.
Then investigation at speed.
What I did:
I led UX design for OKX's internal case management system across two versions.
CMS 1.0 tackled scale: investigators were managing complex multi-user cases with no tools to support them. CMS 2.0 tackled speed: even after the structure was right, analysts were still spending most of their time collecting data instead of making decisions.
The multi-user patterns from 1.0 carry forward into 2.0. These are two layers of the same platform, solving different problems at different depths.
Related users per master case
30+
Reduction in manual verification effort
Significant
Roles across the investigation chain
4
Typology categories supported in the AI investigation model
25
Objectives
Compliance effectiveness
Every case reviewed to the right depth, every decision traceable, every filing defensible to a regulator.
Auditability: every decision traceable to who made it
Granularity: decisions made per account, not per case
Evidence: captured in the system, not in spreadsheets
Defensibility: full trail ready if a decision is ever challenged
Operational efficiency
Analysts spending time on judgment, not data collection. Queue clearing at scale.
Speed: significant reduction in manual data collection
Consistency: same investigation quality regardless of analyst seniority
Scale: backlog clearing without adding headcount
// The problem
The system was only built for one analyst, one account, one form.
Financial crime investigations had evolved. Cases now involved networks of multi-related accounts, cross-jurisdiction patterns, and layered risk signals.
But the system was still built for one reviewer on one account. The queue wasn't clearing.
Scale was the first problem. Speed was the second. The second only became visible after the first was solved.
// Who we designed for
Four roles. One investigation chain. Very different failure modes.
L1 investigator
Alert Reviewer
High-volume triage. 7,800+ cases per week. Initial risk assessment, account activity, onboarding. Escalates when patterns emerge. Single-account focus.
L2 investigator
Case Analyst
Complex network patterns: Multi-related accounts, high-velocity transfers, layering activity across jurisdictions. Files suspicious activity reports. Per-user decisions required. Before CMS 1.0: pivot tables, Google Sheets, manual know-your-customer (KYC) review, all outside the system.
Team lead
Quality Gate
Reviews analyst dismissals for new joiners and severe cases. Confirms or sends back. Needs full narrative context on arrival, no capacity to re-investigate or chase clarification.
Reporting Officer
Final Regulatory Authority
Final call on suspicious activity report filing and account offboarding. Accountable to regulators if a decision is challenged. Cannot afford a second pass. Every decision, rationale, and evidence trail must be ready in one view.
Understanding how it comes together
// Single-account case
How the platform works
Case arrives with a composite risk score, built from customer, transaction, and jurisdiction signals
Analyst reviews the trigger, subject profile, and evidence
Works through five investigation sections in the checklist
Submits a recommendation, file, dismiss, or escalate
// Learning their workflows
Research & issues found
We ran focused investigation workshops with L1 analysts, L2 case analysts, team leads, across Singapore, Europe, and Malta financial intelligence unit teams. Sessions covered live case walkthroughs, evidence packaging mapping, and decision failure point mapping. What we thought was a data problem turned out to be a decision accountability problem. the research changed the design direction entirely.
Use of external documentation
Evidence collection, KYC comparison, and pattern tracking all happened in spreadsheets, creating audit gaps, version conflicts, and duplicated effort across investigators.
Over 30 accounts at one time
Multi-user cases existed only as a dropdown. No shared surface for comparison, risk clustering, or cross-user pattern detection.
Decision not on case but on individual level
Regulatory decisions are made per user but the system only supported a single case-level outcome. Accountability gaps at every TL and Reporting Officer review.
Requiring more evidence
Investigators assessed identity consistency but KYC documents were not accessible during case evaluation. Manual tab-switching to a separate system, every time.
// CMS 1.0 - Design to scale
Three solutions to scale
Scoped with PM. Each solution directly addresses a workflow breakdown identified in research.
Solution 1 • Case Info Page
Multi-accounts comparision table
Each account was its own isolated view. No way to compare across them.
Before: One account at a time, no shared surface, pattern detection impossible at scale
After: Risk score, KYC status, freeze history, CRR score scannable across 30+ accounts at once
Solution 2 • Evidence in-flow
Bulk KYC Viewer & progressive disclosure
Identity documents lived in a separate system. Investigators were switching tabs to verify each account manually.
Before: KYC accessed outside the case, manual tab-switching per account, no cross-account visual comparison
After: front, back, and selfie for all accounts in one view, surfaced on demand without cluttering the main investigation surface
Solution 3 • Decision layer
Per-account decision table
The system had one outcome for the whole case. But SAR filings and offboarding decisions are made per account, and accountability needed to follow.
Before: Single case-level conclusion, ambiguous ownership across the review chain, no structured rationale per account
After: SAR recommendation, SAR decision, and offboarding outcome per account, role-gated edit access, bulk apply with individual traceability
// Phase 1 checkpoint
We solved the complexity problem.
The efficiency problem was next.
Compliance effectiveness resolved
Investigation happens inside the system, Google Sheets dependency eliminated
Per-user decisions with clear role ownership across the full review chain
Identity documents surfaced at the decision point
Evidence in the case record, traceable and auditable
Operational efficiency unsolved
Average handling time still high
Investigation quality varied between analysts, same case type, different outcomes
No guarantee every case received the same analytical rigour
AI assistance limited to output, the bottleneck was at the input, not the summary
// The first AI attempt
We added AI at the output.
Analysts still had to verify everything from scratch.
V1. A generative AI popup embedded in the main case page.
Surfaced AI-generated summaries per investigation section. But analysts still had to collect all the underlying data manually first. The AI summarised work that had already been done, it did not reduce it.
Gap: We added AI at the output. The bottleneck was at the input.
V2. An QA AI Agent: automated quality review on every submitted case
Scored each investigation across compliance checks after submission. It caught gaps, but after investigation time was already spent. And when senior reviewers disagreed with a finding, there was no structured way to record it.
Gap: Post-submission review does not improve the investigation. Unstructured override leaves no trail.
// New CMS 2.0
A new investigation experience.
AI-first, analyst-owned.
CMS 2.0 is a ground-up redesign of the investigation experience. The system pre-analyses each case before the analyst opens it — they arrive to structured findings, not a blank form.
The multi-account patterns from CMS 1.0 carry forward. The core design challenge wasn't building AI features. It was designing the right relationship between AI output and human judgment in a context where every decision must be defensible.
Step 1
AI pre-analysis
Before the analyst opens a case, the system has already worked through it. Facts extracted, signals flagged, attention points surfaced. The analyst arrives to a structured view, not a blank form.
Step 2
Typology and evidence selection
The analyst selects the risk typology and links specific facts as evidence. This shapes what the AI generates, the analyst is directing the investigation, not just reviewing it. The AI drafts. The analyst owns.
Step 3
Confirm or modify
The AI recommends an action. The analyst reviews it. If they agree, they submit. If not, they modify. The system suggests. The analyst calls it.
// CMS 2.0: Zero-to-one
Post-AI launch behaviour
After launch, we tracked where the AI narrative broke down. The failures weren't random, they were structural, and they shaped how we designed around the model.
Data attribution
When two sections showed different figures, investigators didn't know which to trust. We added source labels and surfaced conflicts explicitly.
Contextual gaps
The AI flagged an account as suspicious. It was the user's own onshore account. Fixed attributes now render independently of AI, so critical context is never left to the model to mention.
Silent state changes
An investigator changed the review period. The narrative didn't update. No warning. They nearly filed on the wrong scope. Every transition now surfaces a confirmation or status signal.
// Layers of the systems
Config for the config
Risk rules are not static. Regulatory guidance changes, new typologies emerge, and compliance teams need to adjust attribute weights and tier thresholds without engineering involvement.
But getting a weight wrong doesn't produce a UI error. It produces the wrong cases reviewed at the wrong depth. I designed a configuration matrix with impact preview, role-gated access, and full audit trail, so compliance teams own the rules, and every change is defensible.
Outcomes
〰️
Outcomes 〰️
CMS 1.0 multi-user case
Investigation fully inside the system, external spreadsheet dependency eliminated
Clear role ownership across the full review chain
Significant reduction in manual verification effort and report preparation time
CMS 2.0 AI-native
Targeting meaningful reduction in average case handling time
Quality and AI engagement instrumented and tracked from launch
CRR Configuration
Safety: Grayscale rollout with approval gates and full audit trail.
Speed: Config changes in 10–20 minutes versus weeks.
Scale: Standardised scoring across entities with local overrides.
// Closing
Financial crime investigation is not a data problem.
It is a decision quality problem.
We built for scale first, so investigators could handle the complexity of connected cases together.
Then for speed, so the system does the groundwork, and analysts focus on the judgement.
The hardest challenge across both was not building the features. It was making sure every decision stayed traceable to the person who made it.