Fraud case management 0->1 | Topstep

Fraud case management 0->1 | Topstep

Unifying fraud operations & unlocking deeper automation

Phase 1 launched
Phase 1 launched

New cases moved into the new system

Measurable operations
Measurable operations

Enter password to view case study

Lifecycle measurable, decisions traceable

Built to scale
Built to scale

Expanding to adjacent workflows

SKILLS

Product strategy

Product design

User research

Systems design

Workflow automation

Design QA

role

Lead product designer

Timeline

Jan - Aug 26

SKILLS

Product strategy

Product design

User research

Systems design

Workflow automation

Design QA

role

Lead product designer

Timeline

Jan - Aug 26

I led the 01 design of Investigation & Ban Case Management for Topsteps Fraud Prevention team, taking a complex, high-stakes operational problem from workflow strategy through launch. By unifying fragmented operations and enabling deeper automation, the work created a scalable foundation for the business to identify and act on fraud more effectively, ultimately helping reduce its exposure to fraud-related losses.

PROBLEM

Fragmented, manual workflows made high-stakes fraud operations inefficient, difficult to audit, and vulnerable to manual error

Fraud Prevention at Topstep spanned two connected workflows: Investigation, where suspicious activity involving one or multiple traders was reviewed and decisions were made, and Ban, where escalated traders underwent final review and enforcement.

Neither workflow was managed end to end within Topsteps existing internal tool, so the teams relied on disconnected tools to investigate and ban. The result was constant context switching, inconsistent data, limited auditability, and greater risk of missed enforcement or human error in consequential actions.

I mapped the Investigation and Ban workflows end to end, revealing that Investigation alone involved 10+ tools. This helped identify where the workflow was breaking down and where the biggest opportunities lay.

REFRAME

The initial direction centered on individual traders. I shifted the product to a case-level model

The initial PRD centered on trader-level statuses and actions. But discovery showed that the real unit of work was the case: a case could involve one or multiple traders, move between teams, and carry its own context, ownership, decisions, and history.

I reframed the product around a case-level model, creating a shared operational structure that connected the two workflows from case creation through resolution.

I used the case-level model to align Product, Engineering, and Fraud Prevention team on the product direction and how the system should work.

strategy

Building the operational foundation first, then automating deeper

Automating the entire workflow at once wasnt realistic or desirable. Some work could be system-driven, while higher-judgment decisions still needed human review.

I created a phased automation strategy that first established the structure for managing cases end to end, then progressively automated more of the operational work, and ultimately moved toward proactive detection. I iterated on the strategy with Fraud, Product, and Engineering as we shaped each phase.

The automation plan became an ongoing reference in the product definition, shaping Phase 1 scope and the roadmap for deeper automation.

Solution HIGHLIGHTS

Turning fragmented work into a visible, manageable operation

Establishing a case-level model wasn't enough. For the internal platform to become the operational home for Fraud Prevention, teams needed to see what work was waiting, what was already underway, and who was responsible for it.

I translated the case model into a shared operational queue, making workload, lifecycle state, and ownership visible inside the system.

I structured the queue around how teams managed work: New surfaced unclaimed cases, In Progress showed active work, and My Cases made individual ownership clear.

Helping internal teams turn suspicious activity into actionable fraud cases

Cases could originate across internal teams with different levels of fraud expertise. The creation experience needed to make suspicious activity easy to report while capturing enough structured context for Investigation to act on.

I designed case creation to scale from a single trader to larger groups while capturing the structured context Investigation needed to begin review.

Letting investigators review the whole case before committing consequential decisions

In an early design exploration, review decisions (Clear, Warning, or Submit for Ban Review) took effect once they were made for a trader. But stakeholder reviews showed that decisions could evolve as investigators worked through the case: evidence uncovered while reviewing one trader could change an earlier decision about another.

I shifted review decisions into pending states until case closure, giving investigators room to revise decisions while preventing cases from closing with unresolved traders.

Turning a status change into a true cross-team handoff

When a trader needed to be escalated for Ban Review, responsibility shifted from Investigation to Banning. The receiving team needed a clear way to see incoming work, understand why the trader had been escalated, and continue the review with the Investigation context.

I designed the handoff so escalated traders moved directly into a linked Ban case, carrying the Investigation context forward and eliminating the need for a separate manual handoff between teams.

Connecting final decisions to automation while keeping human actions clear

Once a trader was submitted for Ban Review, Banning took over the case with the Investigation context already in place, conducted its own review, and made the final decision to ban, clear, or warn. For a final ban, that decision triggered a series of actions across the system and external tools.

In Phase 1, I focused automation on the actions the system could reliably control, while making the remaining manual responsibilities explicit.

I extended the staged-decision model from Investigation to Banning, allowing reviewers to evaluate escalated traders and confirm final outcomes before closing the case.

I separated automated and manual actions at case completion, making it clear what the system had already handled and what Banning still needed to complete.

The result

Unified case management for Fraud Prevention

Investigation and Banning moved from fragmented workflows into a shared case management system that structured the end-to-end lifecycle, from case creation and review to cross-team handoff and final resolution, with clear ownership throughout.

Operations became measurable and auditable

For the first time, lifecycle data made case handling measurable, while a persistent audit trail made consequential decisions traceable. The team could now analyze how work moved through the system, identify bottlenecks, and decide where deeper automation could have the greatest impact.

Scaling case management across the internal platform

Phase 1 established a reusable case-management foundation for the broader internal platform. The model was already being adapted to adjacent operational workflows, creating a scalable path to structure more complex operations while preserving the flexibility each domain needed.

Takeaways

Complex systems demand more than simplification. They require judgment about risk, structure, and how decisions become durable system behavior

  • Simplify what we can. Structure what we cant. Fraud Prevention operations were inherently complex. The goal was to remove unnecessary complexity and make what remained easier to manage.

  • Design for the cost of being wrong. High-stakes decisions need greater rigor and stronger safeguards, especially when their consequences are difficult to reverse.