Fraud and anomaly detection for fintech and e-commerce

Fraud detection machine learning is not one model. It is a scoring service in the payment path, a rules layer for the obvious cases, a review queue for the uncertain ones, and a feedback loop that turns chargebacks and analyst decisions into labels. The model is the smallest part. Projects fail because the surrounding system was never designed: labels arrived too late, the threshold annoyed every good customer, or validation on a random split hid how quickly fraud patterns move. This article sets out how we build fraud and anomaly detection for fintech and e-commerce clients, and what it costs.

What fraud detection machine learning does and why it matters

A fraud model takes a transaction, or a login, or a refund request, and returns a score in a few tens of milliseconds. Above one threshold the event is blocked or stepped up to a second factor; below another it passes; in between it goes to a human. The score is learned from history: transactions that were later charged back, accounts that were later confirmed as mule accounts, refunds that were later found to be abuse. Anomaly detection AI is the sibling problem where you have very few confirmed labels and instead learn what normal looks like, then flag departures from it. Most production systems use both: a supervised model for known fraud types and an unsupervised layer for the new ones.

Why it matters is not only the direct loss. In India, the Reserve Bank of India has steadily raised expectations for real-time transaction monitoring, and card networks penalise merchants whose chargeback ratios drift up. A fraud model India teams can trust also protects the customer experience: every false positive is a good customer whose UPI payment or card checkout failed for no reason they can see.

Rules, supervised models and anomaly detection compared

Labels arrive late, and that shapes everything

A chargeback can take weeks to land. That means the most recent weeks of data are systematically under-labelled: transactions that will turn out to be fraud still look clean, and a model trained on them learns that recent fraud is fine. We handle this with a label maturity window: only events old enough for their labels to have settled are used for training and evaluation. The window depends on your dispute cycle, and it is one of the first questions in a discovery sprint.

Analyst decisions as labels

The review queue is a label factory if you design it that way. Store every analyst decision with the score, features and reason code. Cases where the model was confident and the analyst overruled it are the most valuable training examples you will collect.

Validate on time, never on a random split

Fraud is adversarial. The pattern you catch this month is the one fraudsters abandon next month. A model validated on a random shuffle of the last year looks far better than it will ever perform, because it has seen the future. We validate on a hold-out period: train on everything before a date, test on the weeks after it, then roll the window forward and repeat. The performance you report to the business is the average over those forward windows, not the best one. We have a longer treatment of why this matters in data leakage: the silent killer of ML projects.

Precision, recall and the cost of a false positive

The threshold is a business decision dressed up as a technical one. The right setting comes from two numbers finance can estimate: the average loss from a missed fraud, and the cost of a blocked good transaction, including the lost order, the support contact and some chance the customer does not return. Once those are agreed, the threshold falls out of the precision-recall curve rather than out of an argument.

• Report precision and recall at the operating threshold, per segment (new customers, high-value orders, international cards), never as one number
• Track the review queue size; a model that sends ten times more cases to analysts than they can handle is not deployed, whatever the metrics say
• Measure false positive rate on your best customers separately; they are the ones you cannot afford to annoy
• Keep a small holdout of transactions that bypass the model entirely so you can measure what it is actually preventing

Features that carry the signal

Most of the lift in transaction fraud ML comes from features rather than model choice. Velocity features (transactions from this card, device or address in the last hour, day and week) are the workhorses. Consistency features compare the event to the account's own history: usual amount, hour and merchant category. Graph features, computed in batch, find clusters of accounts sharing phone numbers, bank accounts or delivery addresses. A gradient-boosted tree model over a few hundred such features remains the standard: fast to serve, explainable per decision, robust to messy data. Per-decision attributions (new device, unusual amount, three attempts in ten minutes) go into the case record and, softened, into the customer message.

Serving in the payment path

The scoring service has a latency budget set by whoever owns checkout, usually tighter than the data science team assumes. Features that need a database round trip are precomputed into a feature store keyed by card, device and account. Every decision is logged with the full feature vector, so analysts can see why a transaction was flagged and the training set can be rebuilt exactly. This is the discipline we apply to any AI/ML development engagement: the serving path is designed before the model is trained, because the model has to fit it.

Monitoring and retraining

A fraud model degrades faster than almost any other kind, because the opponent adapts. We monitor score distribution drift daily, the rate of analyst overrides weekly, and precision at the operating threshold as labels mature. Retraining is scheduled, typically monthly, with a challenger model evaluated on the forward window before it replaces the champion. New fraud types found by the anomaly layer or by analysts become new labels and sometimes new features. The MLOps loop is where most of the ongoing engineering effort goes.

A worked example

A lending platform came to us with a rules engine of several hundred rules and a review team that spent most of its day clearing false positives. The first step was not a model. We rebuilt the case record so every analyst decision was stored with its reason and features, set the label maturity window from the platform's own dispute data, and agreed the cost of a false positive with finance. The supervised model was validated on rolling forward windows and shadowed the rules engine for a month without acting. Only when forward-window precision held steady did it take over the mid-band decisions, with rules kept for hard blocks. The review queue shrank to cases that needed judgement, and the team began contributing labels rather than clearing noise. The same NBFC context shaped our KYC document intelligence case study.

Team and timeline

A fraud model needs a data engineer for the feature pipeline and feature store, an ML engineer for the model, validation and serving, and someone from your fraud operations team who owns thresholds and the review queue. We start with a Sprint Zero discovery sprint (10 working days, $3,250 / ₹2,00,000, credited to the build) to assess label quality, the maturity window and the latency budget. A first production model with serving, monitoring and a retraining loop typically runs eight to twelve weeks as an AI/ML development engagement, from $17,500 / ₹11.2L, with a Care Plan for the monthly retraining cycle. Full price bands are on the pricing page.

Before you start: a checklist

• Confirm how chargebacks, disputes and confirmed fraud are recorded and how long labels take to settle
• Agree the cost of a missed fraud and of a blocked good transaction with finance
• Get the latency budget from whoever owns checkout or the payment gateway
• Inventory the existing rules and decide which stay as hard blocks
• Check that device, session and address data are captured at the time of the transaction, not reconstructed later
• Name the fraud operations owner for thresholds and the review queue
• Decide where the model runs and who can see the feature data, given DPDP obligations

Glossary

• Chargeback: a card transaction reversed by the issuer after a customer dispute; the main source of fraud labels
• Label maturity: the time after an event before its fraud label can be trusted
• Precision: of the transactions flagged, the share that were fraud
• Recall: of the fraud that occurred, the share that was flagged
• Feature store: a low-latency store of precomputed features keyed by card, device or account
• Mule account: an account used to move stolen funds, often detected by graph features

Related reading

Start with LLM or ML: choosing the right tool for the problem, then how much data do you need to train a model, and the fintech industry page. For the regulatory context, the RBI's circulars on digital payment security are the primary source.

Build the label loop and the serving path first; the model is the easy part, and it will be replaced many times.