Fraud Decisioning in 12ms

Blog

March 18, 2026

2 Comments

A fraud model is only as good as the budget it answers in. Ours had 15 milliseconds, end to end, and every millisecond spent fetching a feature was a millisecond the authorization could not have. So we designed the engine around the deadline first and the model second. Features are computed on the event stream as transactions arrive, not looked up at scoring time, and the model reads state that is already resident. That one constraint shaped the topology, the feature store and the rollback path from day one.

The rebuild ran in three passes. First we instrumented the existing stack and measured where the latency actually went, stage by stage, under real load — that data settles arguments no design review can. Second we moved scoring onto the stream, holding every stage to its own slice of the budget. Third we shipped behind a flag, scoring live traffic in shadow before a single decision was ours.

“ A fraud decision has to be right, explainable and inside the authorization window at once. Miss the deadline and the other two never reach the customer, because the payment already went through. ”

Instrumentation comes first, because opinions about latency are cheap and per-stage timings are not. The budget comes second — a model that is right at 40ms is wrong. The flag comes last, and it comes off slowly: shadow, then a slice, then 40M transactions a day at 12ms.

The pattern holds across our work. A clinical copilot only got used once its drafts appeared inside the EHR clinicians already had open. Support agents only scaled once every automated resolution stayed reviewable by a human. Design the seam between the model and the system around it, and the model stops being the hard part.

Comments

Davies

March 19, 2026 at 9:04 am

“ The instrumentation-first order is the part most teams skip. We spent a quarter arguing about model choice when our own per-stage timings would have settled it in a week. “