Fraud Detection at UPI Scale: GPU Sizing for Sub-100 ms Decisions

Overview

UPI is the largest real-time payment system in the world, and its scale sets the engineering problem. Reported figures put FY 2025-26 at 24,162 crore transactions worth about Rs 314 lakh crore, with over 66 crore transactions on a typical day and 23.2 billion in the month of May 2026 alone. Fraud engines must score a large share of that inline, inside a latency budget measured in tens of milliseconds. That combination — extreme throughput with a hard tail-latency ceiling — is what makes GPU sizing for fraud detection different from ordinary inference sizing.

From transaction volume to inference throughput

Start with the arithmetic. Roughly 66 crore transactions per day is about 660 million, or an average near 7,600 transactions per second. Payment traffic is not uniform: intraday peaks, month-end salary cycles and festive periods produce multiples of the average, and a peak-to-average ratio of three to five is a reasonable planning assumption. That puts peak scoring demand in the range of 25,000 to 40,000 transactions per second for a system handling national-scale volume, and proportionally less for a single bank’s share.

Not every transaction needs the heaviest model. A well-designed pipeline scores everything with something cheap and escalates only ambiguous cases. But the cheap tier still has to run at full line rate, and the escalation tier has to handle a percentage of peak, so both need explicit sizing rather than a single blended number.

Why tail latency is the real constraint

A fraud decision sits inside a payment authorisation with an end-to-end budget. If the model returns in 20 ms on average but occasionally takes 400 ms, those slow requests either time out or force a fail-open decision that defeats the control. The specification that matters is therefore p99 and p999 latency under peak load, not the mean.

Tail latency in GPU inference comes from queuing, batch formation waits, memory allocation stalls and contention with other tenants. The practical mitigations are: fixed small batch sizes with a hard timeout rather than large dynamic batching; dedicated GPUs or MIG partitions for the scoring service rather than sharing with training or analytics; and pre-allocated buffers. Each trades some throughput for predictability, which is the right trade in this workload.

The PCIe problem

Fraud inference has an unusual profile: small payloads, enormous request counts. A transaction feature vector is a few kilobytes. Moving millions of those per second across the PCIe bus, one small transfer at a time, produces overhead that can exceed the compute time. Industry analysis of UPI fraud detection latency identifies the PCIe bus as a distinct source of latency introduced by the shift from CPU-only to GPU-accelerated scoring.

Three mitigations work. Batch aggressively at the host before transfer, accepting a small queuing delay to amortise transfer cost. Use pinned host memory and asynchronous copies so transfer overlaps compute. And keep feature engineering on the GPU where possible so intermediate results do not round-trip. Where these are insufficient, a CPU-only tier for the cheap model with GPU reserved for the deep tier is often the more economical architecture.

A tiered scoring pipeline

Published research on UPI fraud detection has explored hybrid CNN-BiLSTM architectures that combine convolutional feature extraction with bidirectional sequence learning, with reported inference latency under 50 ms making them viable for real-time use. That figure is workable but tight — it consumes most of a typical budget, which is why tier 3 should see a minority of traffic rather than all of it.

Sizing the GPU tier

Work from measured throughput, not datasheet figures. Benchmark your actual model at your actual batch size and precision, record sustained transactions per second per GPU at the p99 latency you require, then divide peak demand by that number and add redundancy. Two operational points are commonly missed: the p99 figure degrades as utilisation rises, so size for perhaps 60-70 percent target utilisation rather than 90; and the graph tier has a very different memory profile because the entity graph must be resident.

Redundancy is not optional here. A fraud engine that goes down forces a fail-open or a payments outage, both unacceptable. Plan for N+1 at minimum across separate failure domains, and rehearse the degraded mode — which tier you fall back to when the deep tier is unavailable, and what risk that accepts. The general method is in the GPU server sizing checklist for AI inference.

Governance and residency

Fraud models consume transaction and customer data, which places them squarely inside DPDP and RBI expectations. Under DPDP, penalties reach up to Rs 250 crore per violation, and payment system data has long attracted localisation expectations. Practically, the scoring infrastructure, the feature store and the model artefacts should all sit in-country under the institution’s control.

FREE-AI adds a model-risk dimension: model inventory, monitoring against a baseline, and explainability for adverse decisions. A declined transaction is an adverse action, so the system must be able to say why. That argues for keeping an interpretable tier in the decision path even where a deep model provides most of the signal — the controls detail is in BFSI private AI controls and auditability, and the wider planning frame in on-prem AI for BFSI.

Frequently asked questions