UPI Fraud Detection in Server Logs: Forensic Rules for Investigators

By the time a UPI fraud complaint reaches an investigator, the money has moved. The wallet is drained, the VPA is deactivated, and the attacker's device is off the network.

What remains is the server log.

Every payment API call, every failed authentication attempt, every VPA lookup that preceded the fraud: it's all there, timestamped to the millisecond, sitting in an Nginx or IIS access log that nobody has looked at yet. The question isn't whether the evidence exists. It's whether the investigator knows what to look for before the log rotation window closes.

This is a practical ruleset for UPI fraud detection in server logs. Built for forensic investigators, SOC analysts, and law enforcement teams working active cases.

What UPI Fraud Actually Looks Like in Logs

UPI fraud isn't random. Attackers follow patterns, and those patterns have distinct log signatures.

Pattern 1: VPA Enumeration

The attacker probes a payment API to discover valid VPAs. They submit variations of a target's likely VPA handle (firstname.lastname@upi, mobile@paytm, mobile@gpay) and watch for response codes that differ between valid and invalid addresses. A 200 response with a name field populated means the VPA exists. A 404 or empty response means it doesn't.

In logs this looks like: rapid sequential POST requests to /api/verify-vpa or /api/check-payee from the same IP or rotating IPs within a narrow time window, with mixed response codes. The key tell is the query density: legitimate users verify one payee before transacting. An attacker verifying 200 VPAs in 4 minutes is not a legitimate user.

Pattern 2: Credential Stuffing on Payment Endpoints

Stolen credential pairs from unrelated breaches are tested against UPI-linked accounts. The attacker is looking for accounts where the user reused a password, and where that account has a linked bank account or wallet balance.

In logs: high-volume POST requests to /login or /api/auth with different username/password combinations, mostly returning 401, with occasional 200s followed immediately by requests to /api/balance or /api/transfer. The 200-then-balance-check sequence is the pivot point.

Pattern 3: Ghost Merchant Flows

A fraudulent merchant account receives a payment, the transaction settles, and then the merchant disputes or the account disappears. The log trail here is subtler: it shows a legitimate-looking payment flow with anomalous merchant VPA characteristics.

In logs: transactions routing to VPAs with PSP handles that don't match the merchant's registered payment gateway, or merchant VPAs that appear only within a short burst window and never again.

The Forensic Regex Ruleset

These are the core detection patterns. Each one is paired with an explanation of why it's structured the way it is, because regex without context is just noise.

Aadhaar Number Detection

\b[2-9]{1}[0-9]{3}\s*[0-9]{4}\s*[0-9]{4}\b

Aadhaar numbers begin with digits 2-9 (never 0 or 1). The \s* allows for space-separated formats (2345 6789 0123) that appear in form submissions. Every match must be run through Verhoeff checksum validation, as without it you'll flag every 12-digit transaction reference in your dataset.

UPI VPA Detection

\b[a-zA-Z0-9.\-_]{3,256}@(gpay|paytm|okaxis|ybl|ibl|axl|okicici|oksbi|okhdfcbank|upi|phonepe|apl)\b

The PSP suffix list is the critical element here. A generic \w+@\w+ pattern matches email addresses, transaction IDs, and API keys alongside VPAs. Anchoring to registered PSP handles eliminates the majority of false positives. Update this list periodically. We maintain an updated PSP handle list in the LEAP rule engine, as NPCI approves new PSP handles on a rolling basis.

Auth Token Leak Detection

(Bearer\s[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+)

JWT tokens follow a three-part base64url structure separated by dots. When they appear in Nginx access logs, it means they leaked into a GET request URL parameter, a serious misconfiguration. A JWT in a log line is an active credential, valid until its expiry timestamp. In a fraud investigation, a leaked JWT found in logs within the attack window is direct evidence of session hijacking.

Mobile Number Detection

\b[6-9][0-9]{9}\b

Indian mobile numbers are 10 digits beginning with 6, 7, 8, or 9. Simple but effective when combined with surrounding context, a mobile number appearing in a POST body to /api/verify-identity is more significant than the same number in a marketing analytics ping.

Reading Burst Patterns vs Legitimate Traffic

Individual regex hits tell you what data was exposed. Burst pattern analysis tells you whether you're looking at a breach or a background noise hit.

The baseline for legitimate UPI transaction flows:

• A real user authenticates once, verifies a payee once, initiates one transaction, and receives one confirmation. That's 4-6 API calls per session, spread across 30-120 seconds.
• A real merchant receiving payments sees inbound transaction notifications at irregular intervals matching their business hours.

The signature of automated fraud:

• VPA verification calls: 50+ requests per minute from the same session token or rotating within the same /24 subnet
• Auth attempts: 200+ requests per minute to login endpoints with sequential username variations
• Balance checks immediately following successful auth: the 200-then-balance pattern appearing within 2 seconds of authentication

Group your log hits into 5-minute windows. Any window showing more than 30 VPA verification requests from a single source, or more than 15 successful auths followed by immediate balance checks, warrants escalation.

The specific thresholds matter less than the methodology: document your baseline, document the anomaly, and express the delta. "This IP made 847 VPA verification requests in 11 minutes, compared to a platform average of 3 per user session" is court-ready language. "We found suspicious activity" is not.

Building a Defensible Evidence Package

Forensic findings are only as useful as their presentation in proceedings: FIR documentation, cybercrime court submissions, or DPDP Board breach notifications.

A defensible evidence package from log analysis contains four elements:

1. Timeline reconstruction, not a raw log dump. A chronological narrative: first observed anomalous request, escalation pattern, pivot point (the moment the attack succeeded or failed), and termination. Timestamps in IST, not UTC. Indian courts and the DPDP Board operate in IST. We've seen FIRs rejected for this exact reason.
2. Indicator inventory, every VPA, mobile number, IP address, session token, and device fingerprint extracted from the log window, with the regex rule that identified it and its Verhoeff/PSP validation status. Unvalidated hits go in a separate appendix marked "candidates for further verification."
3. Blast radius estimate, how many unique Data Principals were affected. This is not the total number of PII hits. It's the deduplicated count of unique identifiers. 847 Aadhaar hits involving 12 unique numbers is a very different breach scope than 847 hits involving 847 unique numbers. This distinction is critical for DPDP Board breach notifications, where the severity assessment depends directly on the unique individual count rather than raw event volume.
4. Chain of custody statement, how the log file was obtained, where it was stored, what tool was used to analyze it, and critically, whether the analysis tool processed the data locally or uploaded it externally. For LEAP-analyzed evidence, this statement can confirm that the raw log file never left the investigator's machine, which matters for evidence integrity under Indian digital evidence standards.

The fraud already happened. The log is the only witness left. How you read it determines whether that witness holds up.