Skip to content
All projects
Case studyCS/03
StatusPersonal project
TypeAI
Year2026

FraudShield

Real-time UPI fraud and money-mule detection, with an AI copilot for investigators

FraudShield scores every UPI payment in a few milliseconds, before the money moves, with a plain-English reason for each decision. It spots the mule networks that move stolen money, opens one case per suspicious account, and gives investigators a copilot that drafts case briefs grounded in RBI and FIU-IND guidance, with citations.

GitHub
  • Scoring ~1–5 ms
  • ROC AUC 0.998
  • 99.7% genuine approved
  • False positives 0.4%

§1

The problem

RBI data shows cyber-fraud losses grew from ₹421 crore in FY23 to ₹2,055 crore in FY24. Mule accounts carry the money for almost every scam, new scams like 'digital arrest' pass device and location checks, and investigators drown in alerts with regulatory deadlines.

§2

My role

Personal project, end to end: payment intake, the Lua feature store and explainable model, the mule-graph analyser, case management with the RAG copilot, the React console, Testcontainers and Playwright tests, and Kubernetes manifests.

§3

Architecture

Fig. 1 · FraudShield architecture
score ≤ 300 msoutboxANALYST CONSOLEReact · SSEGATEWAYJWT · rate limitsCASE-SERVICEcases · RAG copilotTXN-SERVICEidempotency · outboxRISK-ENGINEmodel · mule graphPOSTGRESpgvector · casesKAFKApayments.scoredREDISLua feature store
clientservicedataevent

§4

Key decisions

  1. D/01

    Synchronous scoring with a 300 ms budget

    A Resilience4j circuit breaker guards the risk engine. If it struggles, small payments fail open and large ones fail closed, marked degraded and replayed into the feature store from Kafka later.

  2. D/02

    One Lua script per payment

    The whole feature read and write is a single atomic Redis round trip: sorted sets for velocity, HyperLogLog for distinct counterparties, Welford's online variance for the usual amount.

  3. D/03

    Logistic regression, not a black box

    Each feature's contribution is exactly weight × value, so every decision explains itself to the customer, the analyst and the regulator.

  4. D/04

    Champion/challenger retraining

    Every analyst verdict becomes a label. A retrained model is promoted only if AUC is no worse and false positives don't rise; replicas hot-swap it through Redis.

  5. D/05

    Hybrid RAG in the database it already uses

    pgvector and Postgres full-text are fused with Reciprocal Rank Fusion in one SQL query, with in-process ONNX embeddings, so retrieval works with no API key and no customer data leaving.

  6. D/06

    Transactional outbox

    The payment row and its event commit together; a FOR UPDATE SKIP LOCKED relay lets replicas publish in parallel, and consumers de-duplicate on the transaction id.

§5

Challenges

  • Testing showed repeated stolen-phone attempts drifting from BLOCK to APPROVE: blocked attacks were teaching the trusted profile. A second script now learns usual amount, location and devices from approved payments only, which lifted recall from 74–80% to 98%.
  • Fan-in is normal for a chai shop. Counting it only when the account also behaves like a conduit cut mule false positives from about 3% to 0.2%.
  • A consumer that started first auto-created a 1-partition Kafka topic and missed messages. Every service now declares its topics and broker auto-create is off.
  • Fully balancing a 2% fraud rate pushed false positives to 2.2%. √imbalance class weights kept the recall gains at about 0.4%.

§6

Stack

  • Java 21
  • Spring Boot 4
  • Spring Cloud Gateway
  • Kafka
  • Redis (Lua)
  • PostgreSQL
  • pgvector
  • LangChain4j
  • React
  • Kubernetes

Next case study

GigPay

Instant earned-wage payouts for gig workers, on a double-entry ledger