Financial technology
Fraud detection that took $2M a year off the loss line
A payments start-up was losing money to fraud faster than its rules engine could be updated. Every new pattern meant a developer writing another rule, and by the time it shipped the pattern had moved on.
- Client
- Payments start-up, Series B
- Timeline
- 11 weeks to production
- Built with
- Python, Kafka, Postgres, feature store
The problem
Writing rules faster than the fraud changed was not working.
Every new fraud pattern meant a hand-written rule, a release and a wait. The engine was always describing last month.
Rules were tuned to catch more, which caught more legitimate customers too. The manual review queue grew until decisions were taking days.
Nobody could say why a particular transaction had been declined, which made both the customer conversation and the regulatory one uncomfortable.
The constraint
Scoring had to happen inside the payment.
A decision that arrives after the payment has completed is a report, not a control. The budget was forty milliseconds, agreed before any modelling started, and it shaped every choice that followed.
What we did
Score in the path, explain every decision.
-
01
Scoring on the payment path
A model scores each transaction inline, inside a hard latency budget, so a decision arrives before the payment completes rather than in a batch overnight.
-
02
Features computed once
Behavioural features are built in a feature store shared by training and serving, which removes the class of bug where a model performs well in testing and badly in production.
-
03
Every decision explained
Each score carries the factors that drove it, so a support agent can answer a customer and a compliance officer can answer a regulator.
-
04
Rules kept where they belong
Hard rules still exist for the things that should always be blocked. The model handles the patterns nobody thought to write down.
Outcome
What changed.
Roughly $2M a year in avoided loss
Calculated from the fraud rate before and after against the same transaction volume.
The review queue fell by 71%
Fewer legitimate customers were caught, so the team reviewed the cases that genuinely needed a person.
Under 40ms added to the payment
Well inside the budget agreed at the start, which was the condition for scoring inline at all.
We stopped trying to describe fraud in advance. The useful change was being able to explain a decision after it happened.
Services involved
More work
Next step
Talk to the engineer who would run your build.
No discovery call with a salesperson, no deck. A senior engineer reads what you send and replies with a real assessment, including when we think you shouldn’t build it.
