MuleShield AI: Intercepting Cybercrime Cash-Outs Before the Trail Goes Cold

Sameer Singh — Mon, 31 Aug 2026 08:54:23 +0000

How a three-model AI pipeline helps Indian law enforcement get ahead of digital financial fraud — and the engineering decisions behind it.

India loses over ₹1.8 lakh crore annually to cybercrime. Behind nearly every UPI scam, fake loan fraud, and phishing attack is the same final step: stolen money is split across a chain of mule accounts and quietly withdrawn as untraceable cash from an ATM — often within 90 minutes of the original crime.

That last step is where investigations end. Once money becomes physical cash, there is no transaction to reverse, no account to freeze, and nothing left to trace.

MuleShield AI was built to interrupt that step.

The Problem: Detection Alone Is Not Enough

India already has robust mule-account detection infrastructure. The Reserve Bank of India's MuleHunter.AI (live since December 2024, deployed at Canara Bank, PNB, Bank of India, Bank of Baroda, and 20+ others) identifies suspicious accounts using 19 distinct behaviour patterns, reporting 95% accuracy. The I4C Suspect Registry has shared 32 lakh flagged mule accounts with banks and declined ₹25,698 crore in transactions.

These systems are excellent at what they do — but they operate exclusively inside the banking rails. They can flag an account, decline a transfer, or freeze a balance. Every one of them stops working the moment cash leaves an ATM.

No existing system answers the question law enforcement actually needs answered: which ATM will the money come out of, and how much time is left?

MuleShield AI starts exactly where existing solutions stop.

System Architecture: Three Models, Three Distinct Problems

We deliberately avoided building a single monolithic model. The task decomposes into three structurally different problems, each requiring a different approach.

Complaint filed → 1930 helpline
        │
        ▼
[1] BFS Graph Trace ──────────► identifies the terminal mule account
        │                        (deterministic graph traversal, no ML)
        ▼
[2] GraphSAGE Classifier ─────► scores accounts: mule probability
        │
        ▼
[3] Conditional Logit Ranker ─► ranks 25 nearby ATMs → top 5 + search zone
        │
        ▼
[4] XGBoost Regressor ────────► time-to-withdrawal with confidence band

This separation is an architectural choice with concrete benefits: each component can be tested, audited, and improved independently. If the classifier is retrained, the ranker is unaffected. If real transaction data becomes available (via RBI/NPCI inter-bank tracing infrastructure), only the trace layer needs updating.

Component 1: Graph-Based Mule Detection

A mule account — receiving ₹40,000 and forwarding ₹39,500 four minutes later — looks unremarkable in isolation. Embedded in a transaction graph where eight unrelated senders converge on one receiver whose neighbours are doing the same thing simultaneously, the pattern is obvious.

We quantified the isolated contribution of graph structure by holding all other variables constant:

Model	Test F1
Majority class baseline	0.057
Best single feature	0.497
Logistic regression (no graph)	0.684
Random forest (no graph)	0.842
GraphSAGE (graph + features)	0.895

The graph structure contributes +0.053 F1 over the best feature-based model — a measurable, reproducible improvement, not a claim. The GNN itself is 10,561 parameters and runs in under 10 ms per inference.

Component 2: ATM Location Prediction via Discrete Choice Theory

Predicting which ATM a criminal will use is a discrete-choice problem: one option is selected from a finite set of alternatives based on a weighted combination of factors (distance, surveillance risk, bank familiarity, crew habit patterns).

Standard gradient-boosted rankers model additive relationships. But criminal ATM selection is multiplicative — proximity × surveillance risk × bank affinity compose as a product, not a sum. A log transformation converts a product into a sum, making a linear model structurally correct where a tree-based model is structurally misspecified.

The solution is the conditional logit — McFadden's 1974 discrete-choice model (awarded the 2000 Nobel Prize in Economics). Applied here:

# Utility of each candidate ATM:
U(atm_i) = w₁·log(1/distance_i) + w₂·log(1 + risk_i) + w₃·same_bank_i

# Probability:
P(atm_i | candidates) = softmax_i( U(atm_i) )

Because our simulation has known generative parameters, we can verify model correctness directly:

Coefficient	Learned	Ground truth
Distance weight	0.9887	1.000
Surveillance risk	0.7558	1.000
Same-bank bonus	0.6847	log 2 = 0.693

The model recovered the real generative structure to within 1.5% — confirming the structural choice was correct, not just empirically competitive.

Component 3: Time-to-Withdrawal Forecasting

An XGBoost regressor estimates minutes until cash-out, trained on features including: network velocity, account age, transaction pattern recency, and mule archetype cluster.

Metric	Value
MAE	11.86 minutes
Mean-guess baseline MAE	14.98 minutes
Median lead time delivered	42 minutes
Cases actionable (≥15 min lead time)	85.4%

42 minutes of median lead time is enough for coordinated police response. 85.4% actionability means the system is useful in the overwhelming majority of cases, not just edge cases.

End-to-End Performance

The deliverable for law enforcement is not a ranked list of ATMs — it is a geographic search zone derived from the ranked probability distribution:

Strategy	Withdrawal contained	Median zone error
Mule's own location	75.2%	6.39 km
Nearest-3 ATM centroid	78.5%	5.68 km
MuleShield AI search zone	87.4%	5.49 km

87.4% containment at 5.49 km median error — reducing a district of 1,000+ ATMs down to a median of 8 candidates within a ~10 km search radius. Combined with the 42-minute lead time, this gives field teams a real and specific target.

The full pipeline inference time: 7.5 ms on a single CPU, ~1 GB RAM, no GPU required. The system is designed to run on standard government server infrastructure.

Interpretability as a Deployment Requirement

A system whose output directs police to a physical location must be explainable — not as a design preference, but as a practical requirement for operational and legal credibility.

The conditional logit ranker has three interpretable coefficients, readable out loud. GraphSAGE decisions can be traced back to specific neighbourhood structure. The trace layer is deterministic BFS — correct by construction, regardless of what the probabilistic components do.

This interpretability is a first-class engineering constraint, not an afterthought.

Honest Assessment of Current Limitations

On data: MuleShield AI is trained on synthetic data. This is a deliberate, necessary constraint — real NCRP transaction data is legally restricted. The synthetic generator was calibrated against known mule behaviour patterns from published I4C and CERT-In reports, and includes 2% label noise and overlapping class distributions to prevent overfit to clean simulated data.

On the intake dependency: A live complaint arrives at the 1930 helpline with no transaction chain attached. The victim knows what they lost; they don't know which mule accounts it passed through. That chain must come from the banking side via inter-bank tracing infrastructure (currently being developed by RBI and NPCI). MuleShield AI's demo synthesises this input honestly — on real graph accounts with real transaction patterns — and performs genuine inference on everything downstream.

These limitations are documented, not hidden. A system that overstates its deployment-readiness is more dangerous than one with honest boundaries.

Alignment with National Cybercrime Infrastructure

MuleShield AI is designed as a complement to, not a replacement for, existing government systems:

MuleHunter.AI (RBI): detects mule accounts inside banking rails → MuleShield AI picks up where it stops
I4C Suspect Registry: flags known mules → feeds the GraphSAGE feature layer as prior signal
NCRP / 1930 Helpline: complaint intake → the system's operational trigger point
NPCI / inter-bank tracing (in development): real transaction chain data → future input layer upgrade path

The architecture was designed with this integration roadmap in mind.

Technical Stack

Component	Technology
Graph construction	NetworkX, custom BFS engine
GNN classifier	PyTorch Geometric — GraphSAGE (2-layer, mean aggregation)
ATM ranker	Conditional logit via `statsmodels`
Time regressor	XGBoost
API layer	FastAPI
Frontend	React + TypeScript
Test suite	291 tests, including regression guards on all published figures

MuleShield AI was developed for Smart India Hackathon 2026, Problem Statement SIH26184, issued by the Ministry of Home Affairs / Indian Cybercrime Coordination Centre (I4C). All figures are held-out measurements on data not seen during training. The full implementation and methodology documentation are available in the project repository.

DEV Community: Sameer Singh