Real-time fraud and risk decisioning, and who builds it

The latency budget sets the design

Start with the number. In a UPI transaction the end-to-end window is tight, and the fraud decision gets a slice of it, typically somewhere between 30 and 150 milliseconds depending on where it sits in the flow. In card authorisation the budget is similar. In lending application fraud it is seconds, which is a different problem entirely and should not be run on the same system.

Everything about the design is downstream of that number:

You cannot query the transaction database. A scan over historical transactions to compute "how many transactions has this device made in the last hour" will not return in time. The aggregate has to be precomputed and kept hot.

You cannot call three external services serially. A device reputation lookup, a bureau check and an internal score at 40ms each do not fit. Either they run in parallel with a hard deadline, or some of them run out of band and their results are used on the next transaction rather than this one.

Degradation has to be designed. When the feature store is slow, the system either fails open (allow, accept the fraud risk) or fails closed (block, accept the customer impact). This is a business decision with a large revenue consequence and it should be made deliberately and documented, not discovered during an incident.

Model complexity is bounded by inference time. A gradient-boosted tree ensemble scoring in 5ms is usable. A model that needs 200ms is not, however much better it is offline. This is the single most common disappointment when a data science team moves a model toward production.

Rules and models, together

The recurring argument inside fraud teams is whether rules or models should drive decisions. The answer in every mature system is both, because they solve different problems.

A working architecture usually looks like: a hard rules layer for absolute prohibitions and regulatory blocks, a model score for the probabilistic middle, and a soft rules layer that can override the model in either direction for patterns observed in the last few days. The soft layer is the pressure valve. Without it, a fraud team watching a new attack unfold has no way to respond until the next model cycle.

The discipline that distinguishes a good team is rule retirement. Rule estates accumulate: a rule written for a 2023 attack is still firing in 2026, blocking legitimate customers nobody has measured. Every rule needs an owner, a hit rate, a precision measurement and a review date. Teams that do not do this discover that half their false positives come from rules nobody remembers writing.

The feature store

The feature store is the piece most often underestimated when hiring, and the piece that most often determines whether the system works.

Its job is to serve precomputed aggregates at single-digit millisecond latency: velocity counts across multiple windows, device and IP history, behavioural baselines per customer, beneficiary relationship age, merchant risk scores. These are computed from a stream and read at decision time.

The hard parts are not the serving layer, which is a well-understood key-value problem. They are:

Training and serving skew. The feature computed in the offline training pipeline and the feature computed in the online path must be identical. They very often are not, because they were written by different people in different languages against different data. The model then performs worse in production than in backtest, and the team spends months looking for the cause in the model. Shared feature definitions, generated into both paths, are the only reliable fix.

Point-in-time correctness. When building training data, the features must be as they stood at the moment of the historical transaction, not as they stand now. Leaking future information into training is the most common silent error in fraud modelling and it produces a model that looks excellent and performs poorly.

Late and out-of-order events. Streams deliver out of order. An aggregate that assumed ordering will be wrong, and wrong in a way that is hard to detect.

Cold start. A new customer, a new device, a new merchant has no history. The system has to behave sensibly, and "no features, therefore low risk" is an exploitable default that fraudsters find quickly.

False-positive economics

This is where engineering and the business most often fail to communicate, and it is worth making explicit in any brief.

Every fraud system has an operating point. Move it one way and you catch more fraud and block more legitimate customers. Move it the other way and the reverse. There is no setting that avoids the trade, and pretending otherwise produces an organisation where the fraud team is measured on losses and the growth team is measured on conversion, with nobody accountable for the point between them.

The arithmetic a serious team keeps current:

• The cost of a false negative: fraud loss, plus investigation cost, plus the customer remediation obligation.
• The cost of a false positive: the immediate failed transaction, the support contact, the probability of the customer not returning, and the lifetime value lost if they do not. In Indian consumer fintech the last term usually dominates, and it is the one most often left out.
• The review queue capacity: a challenge or review decision is only useful if someone can act on it inside a meaningful window.

A fraud leader who cannot state their current operating point and what it costs in both directions is managing by anecdote. This is a good interview question and a revealing one.

The regulatory layer in India

Fraud decisioning in Indian fintech is no longer purely a commercial risk function. Supervisory expectations have hardened over the last two years.

Real-time monitoring is expected, not optional. The RBI's position is that regulated entities should deploy robust software for real-time transaction monitoring and use AI and ML tooling to detect suspicious patterns.

The liability framework has been finalised, and it moves the loss. The RBI finalised its framework on unauthorised electronic banking transactions on 24 June 2026, with effect from 1 January 2027 after a deferral from 1 July 2026. It introduces a compensation mechanism for small-value fraud, capped at ₹25,000 for losses up to ₹50,000, where the customer reports within five calendar days to both the bank and the National Cyber Crime Reporting Portal or helpline 1930. Critically for system design, the burden of proving customer liability rests on the bank, and the framework requires 24/7 reporting channels, instant alerts on transactions above ₹500, and resolution within 45 days domestically or 60 days cross-border.

The engineering consequence is that detection timestamps, alert delivery and customer report timestamps are now evidence in a liability determination the institution has to win. A fraud system that detects well but cannot prove when it detected, when it alerted and what the customer was told will lose cases it should have won.

Authentication requirements changed in parallel. The Authentication Mechanisms for Digital Payment Transactions Directions, 2025, issued 25 September 2025 and applying from 1 April 2026, require two-factor authentication with at least one dynamic factor for digital payment transactions other than card-present, and expect risk-based fraud management on suspicious transactions. This interacts directly with the operating point discussed above: a step-up challenge is now both a fraud control and a compliance mechanism.

Mule account detection has become a supervisory theme. MuleHunter.AI, the RBI's machine-learning solution for identifying mule accounts, has been deployed across a growing number of banks, with the Ministry of Finance pressing for wider adoption. For a fintech operating with sponsor banks, this matters directly: the bank's mule detection will act on your customers, and you need a position on what happens when it does.

Industry-level intelligence sharing is being institutionalised. The Indian Digital Payment Intelligence Corporation was incorporated on 16 October 2025 to run real-time fraud detection infrastructure across the ecosystem. Participation will bring both a data feed to consume and an obligation to contribute.

Customer liability rules shape the review process. The liability framework for unauthorised transactions sets reporting windows and liability allocation that depend on how quickly a customer reports and whether the institution was at fault. The engineering consequence is that detection timestamps, notification timestamps and customer response timestamps all need to be precise and defensible, because they determine who bears the loss.

Where fraud systems break

The rules estate nobody owns. Covered above, and the most common failure by a wide margin.

The model nobody is monitoring. A model deployed and then left alone. Fraud is adversarial, so drift is not a slow degradation but a step change when attackers find the boundary. Monitoring needs to cover score distribution, feature distribution, precision on the reviewed sample and the fraud rate among approved transactions, and someone needs to look at it.

The gap between fraud and security. Account takeover is both a security incident and a fraud event. Organisations that put them in different teams with different tooling discover a seam that attackers exploit. Resolving the seam is usually a joint responsibility of the CISO and the risk function, and it is worth settling before the incident rather than during it.

Review queue starvation. A system that flags more than the operations team can review is producing decisions nobody makes. Queue capacity is part of the system design, not an operational afterthought.

The first-party fraud blind spot. Systems built to detect an attacker impersonating a customer perform badly against a customer defrauding the institution, which in Indian lending is a material share of losses. The signals are different and the models usually have to be separate.

Shared infrastructure with the lending decision. Application fraud and transaction fraud are different problems with different latency budgets and different data. Running them on one system because they are both "risk" produces a system that is badly suited to each. The lending side is covered in lending decision infrastructure.

Who builds this

The genuinely scarce profile is the engineer who has owned a production inline decisioning service under a hard latency budget in a regulated Indian entity. Streaming engineers are available. Fraud analysts are available. The intersection, with production accountability and regulatory exposure, is a pool of a few hundred people nationally, and most of them sit in the large payment companies, the big private banks and three or four lenders.

How to assess

Ask for the latency budget. "What was your p99, and what did you cut to get there?" A candidate who has owned the service answers immediately and specifically. One who has not will talk about the model.

Ask what happens when the feature store is down. The answer reveals whether degradation was designed or discovered.

Ask about a false positive incident. A block on a legitimate high-value customer, or a rule that took out a segment. How it was found, how long it ran, what it cost, what changed. Teams that do not measure false positives cannot answer this.

Ask how they retired a rule. This is a small question that reliably separates mature teams from teams that only add.

Test the adversarial frame. "Fraud rate drops 40% in a week. What is your first hypothesis?" The good answer is that something broke in the detection or the reporting, not that the problem is solved.