AI fraud detection that cut false positives 60% while catching 3x more genuine fraud

Industry

Payments

Market

India

Client

Payments company in India

Sponsor

VP Engineering

What we built

AI fraud detection

The situation

Every payments company has a fraud rules engine, and every rules engine eventually faces the same trade-off. Tighten the rules and good customers get blocked. Loosen them and fraud gets through. The client, a payments company in India, had reached the point where its rules engine was costing as much in false positives as fraud itself was costing in losses, in the words of its VP Engineering.

False positives are expensive in ways that do not show up on a fraud report: blocked legitimate transactions, merchants who lose sales, customers who call support or simply leave, and a review team spending its day clearing transactions that were fine all along. Meanwhile the fraud that did get through was, by definition, the fraud the rules could not see.

What we built

A detection system that scores every transaction on risk and works alongside the existing rules rather than ripping them out.

Scoring on behaviour, not thresholds. Rules ask fixed questions: is the amount above X, is the location new. The model looks at the transaction in context: how it compares with this customer's and this merchant's normal patterns, the device and session signals available, velocity across related accounts, and combinations of factors no single rule captures. The output is a risk score with the main contributing factors, so an analyst can see why a transaction was flagged.

Rules and model together. Hard rules that reflect policy or regulatory requirements stay in place. The model decides the large grey zone where rules were either over-blocking or under-catching. That combination is what lets false positives fall without letting fraud rise.

A review queue that ranks by risk. Transactions that need a human go to analysts ordered by score, with the explanation attached, so the team spends its time on the cases most likely to be fraud.

A feedback loop. Confirmed fraud, chargebacks and cleared false positives flow back as labelled outcomes, so the model keeps learning what fraud looks like on this company's traffic as patterns shift.

How it went live

The model ran in shadow mode first, scoring live transactions without affecting decisions, so the team could compare what it would have blocked and allowed against what the rules actually did and what later proved to be fraud. Only when that comparison was clear did the model begin influencing decisions, starting in the segments where the rules were generating the most false positives.

Results

In the first month, the system cut false positives by 60% while catching three times more genuine fraud than the rules engine alone. The VP Engineering described the ROI as immediate: fewer good customers blocked, less analyst time spent clearing them, and less fraud getting through.

What made the difference

Augmenting the rules instead of replacing them. Keeping policy rules in place made the system easy to approve and safe to run.

Shadow mode as proof. Showing the model's decisions against real outcomes before it made any is what turned a debate into a decision.

Explanations on every flag. Analysts trust scores they can understand, and their confirmed decisions are what keep the model improving.