Real-Time Fraud Detection — Case Study

Real-Time Fraud

Detection

A streaming ML risk engine scoring 40M transactions a day for a top-10 retail bank
— 63% less fraud loss, every decision returned in 12ms.

Project Details

Axiom Bank, a top-10 retail bank, was detecting card fraud in overnight batches — accurate often enough, but always after settlement and at a false-positive rate its customers felt. Cryptonic rebuilt the stack as a real-time decisioning engine that scores every card and transfer inline, before the transaction is authorized. Kafka streams 40M events a day into a low-latency feature store; PyTorch models score behavioral, device and network signals in a single pass; a policy layer applies the bank’s own rules on top of the model output. The engine sits beside the existing authorization path rather than inside it, so nothing in core banking had to change to go live. Every decision returns in 12ms with the features, model version and policy trace that produced it attached.

Delivery took ten weeks end to end. A shadow phase replayed historical transactions so the bank could compare engine decisions against its live rules before a single customer was affected. Traffic then moved across in stages, with a one-command rollback at every step. Models retrain against labeled outcomes and analyst dispositions, so new attack patterns are absorbed without a release. Everything runs on AWS inside the bank’s own VPC, under the SOC 2 Type II and ISO 27001 controls Cryptonic applies to every engagement, with a 99.99% uptime SLA on the decisioning path.

DELIVERABLES

INDUSTRY

Project Research

Nothing was built at first. The team replayed the bank’s authorization logs, chargebacks and analyst case notes to establish what was actually being lost and where — by channel, by merchant category, by hour. The baseline was uncomfortable but clarifying: the existing rules caught most confirmed fraud, and paid for it in legitimate payments declined. Each of those declines carried a support call, and a measurable share carried a lost customer. Accuracy alone was never going to be the story. Timing was the real defect: the batch ran after settlement, so the models were often right and always too late to act on.

That single finding set the constraint the rest of the build answered to: a decision had to land inside the authorization window, leaving a 15ms budget for feature lookup, inference and policy evaluation combined. Features are precomputed in the stream rather than joined at request time, models are quantized and served next to the broker, and the policy layer is editable by the bank’s own fraud team without a deployment. Candidate models were ranked on loss prevented per false positive — the number the business actually pays — rather than on AUC.

Project Results

Ten weeks after kickoff the engine was decisioning 100% of card and transfer traffic. Fraud loss fell 63%. Wrongly declined payments halved — worth as much to the business, since each one had been costing a support call and sometimes a customer. Decisions return in 12ms and stay inside the 15ms authorization budget across 40M transactions a day, with no measurable effect on authorization times. Analyst workload changed shape rather than disappearing: the queue is smaller, and each case now arrives with the features and model reasoning that triggered it, so dispositions close faster. The bank’s fraud team now ships policy changes itself in hours rather than filing a quarterly change request.