Unifying fraud operations & unlocking deeper automation
New cases moved into the new system
Enter password to view case study
Lifecycle measurable, decisions traceable
Expanding to adjacent workflows
I led the 0→1 design of Investigation & Ban Case Management for Topstep’s 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 Topstep’s 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 wasn’t 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 can’t. 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.




