Real-time fraud, on a rail built for batch.
A Tier-1 bank was defending a real-time payments rail with a fraud system that ran overnight. We re-engineered the gap — and proved the number before we built.
The threat was real-time. The defence was not.
The bank had moved its payments rail to real time. Fraud detection had not. Risk models ran in overnight batches, which meant fraudulent transactions cleared and were only flagged the next morning — by which point the money was gone and the recovery process, not the prevention process, was running.
Two previous attempts to fix this had stalled. Both had strong models. Neither had a credible path from model to a governed, sub-10ms production system the regulator would accept. The bank had stopped trusting AI proposals — reasonably.
PRISM, stage by stage.
We modelled the fraud loss before proposing a build.
Three weeks with the bank’s risk office and finance team. We quantified annual fraud clearing the batch window, the cost of false-positive reviews, and the headcount tied to manual investigation. The case was credible — and we said so in writing, with the number the bank’s CFO signed.
- Fraud-loss model, signed by the bank’s finance lead
- Hypothesis register: what we believed, and the kill criteria
- Go recommendation with a defined target: 95%+ accuracy, sub-10ms
Architecture designed backwards from the regulator.
Explainability was the binding constraint, not accuracy. We designed a streaming decisioning architecture where every decision produces an audit-trailed, defensible reason. The bank’s architects challenged every decision record — which was the point.
Eighteen sprints. QA and audit in from sprint one.
The first production-grade increment shipped in sprint 4 — small, real, measured against the Proof target. Evaluation harnesses, security scanning and the audit trail were part of the pipeline, not a pre-launch phase. The bank could see the scorecard move every sprint.
- Working increments demoed against Proof metrics each sprint
- Offline evaluation + shadow-mode production validation
- Audit trail and explainability tested with the bank’s compliance team
The system that proved the case is the system that scaled.
Because the architecture was designed for production load in Roadmap, scaling was an operation, not a rebuild. Load-validated at peak payment volumes, cost-modelled, with a runbook handed to the bank’s platform team.
- Validated at 2.4× projected peak transaction volume
- FinOps cost model and guardrails
- Capability transfer to the bank’s run team
The number we promised is the number we report.
A live dashboard tracks the exact metrics from the Proof model — fraud prevented, accuracy, false-positive cost — reviewed quarterly with the same finance lead who signed the case. The loop is now restarting at Proof for the next risk domain.
- Live impact dashboard on original Proof KPIs
- Quarterly outcome review with finance + risk
- Next-cycle hypotheses: AML and onboarding risk
They modelled the number before they asked us to commit. That’s why we said yes.
Have a risk number that’s bleeding?
Stage P is a conversation, not a contract. We’ll model it with your risk office first — and tell you honestly if it isn’t worth building.
Model my ROI →