India's Reserve Bank of India has steadily tightened its expectations on digital fraud risk management over the past three years. The cumulative effect of the 2021 framework on outsourcing of IT services, the 2023 Master Direction on Information Technology Governance, and the more recent guidance on fraud risk monitoring creates a set of implementation obligations that every scheduled commercial bank and payments institution operating in India must address.
This article distills the core operational requirements, maps them to implementation decisions, and highlights the specific areas where examiners from RBI's Department of Supervision have been asking the hardest questions during recent inspections.
Disclaimer: This article is for informational purposes only and does not constitute legal or regulatory advice. Always consult your legal and compliance team for definitive interpretation of RBI circulars and Master Directions.
1. Real-Time Transaction Monitoring: The 50ms Expectation
The most operationally demanding shift in recent RBI guidance is the expectation that fraud scoring must occur before the transaction is authorised — not after. The phrase "real-time detection" appears repeatedly in inspection checklists, and examiners have interpreted this as a maximum acceptable latency of roughly 50ms for a scoring decision.
For most legacy fraud engines that rely on overnight batch processing, this is a fundamental architecture change. The key requirements break down as follows:
- Pre-authorization scoring: Fraud assessment must complete before the transaction authorization response is sent to the customer or merchant. Post-authorization flagging is insufficient for compliance.
- Rule engine availability SLA: The fraud scoring system must maintain 99.95%+ uptime. Documented fallback behavior (fail-open vs. fail-closed) must exist and be tested quarterly.
- Audit trail: Every transaction must have a corresponding scoring log — the rule that fired, the features evaluated, the decision made, and the timestamp — retained for a minimum of 5 years.
2. Mule Account Detection Obligations
India's Ministry of Home Affairs classified mule account recruitment as a primary enabler of cyber fraud in its 2023 report on the Cyber Crime Portal. RBI has since incorporated mule detection into its examination framework, with specific questions around:
Account-opening velocity controls
Banks must be able to detect when a mobile number, Aadhaar, or PAN is being used to open multiple accounts in rapid succession. The threshold for investigation is typically 3 or more accounts linked to the same identity within 30 days.
Inbound flow concentration
Any account receiving funds from more than 10 unique senders in a 24-hour window — without a corresponding business justification — must be reviewed. Accounts in the MHA Cyber Crime Portal's flagged districts are subject to a lower threshold of 5 unique senders.
SIM-swap linkage
Banks must subscribe to telco SIM-swap event feeds and cross-reference them against account activity. An account where the linked mobile number underwent a SIM-swap in the previous 7 days must not allow outbound UPI transactions above ₹5,000 without step-up authentication.
| Requirement | Minimum Standard | Inspection Finding (2024) |
|---|---|---|
| Account velocity monitoring | 3 accounts / 30 days per identity | Most banks pass |
| Inbound flow concentration | 10 unique senders / 24h | Partial compliance — many banks monitor count, not network topology |
| SIM-swap integration | 7-day lookback on all UPI transactions | Common gap — telco integration missing at ~40% of inspected banks |
| MHA district overlay | 34 flagged districts in scoring model | Common gap — most FRM systems lack geographic risk layers |
| Transaction graph analysis | Network-based mule scoring | Emerging expectation — not yet mandatory but cited as best practice |
3. CERT-In Incident Reporting: Timelines and Format
Under CERT-In's Directions of 2022 (amended 2023), any cyber security incident — including UPI fraud that meets the threshold — must be reported within 6 hours of detection. Key points:
- Reportable threshold: Individual fraud event above ₹1 lakh, or any cluster of 50+ fraud transactions within 24 hours from the same attack vector.
- Reporting channel: CERT-In's online incident reporting portal. Email backup accepted only when the portal is unavailable.
- Minimum fields required: Attack vector, affected VPA/account count, estimated loss amount, detection timestamp, remediation actions taken.
- Follow-up report: Full forensic report within 30 days, including root cause analysis and controls implemented to prevent recurrence.
Practical implication: You cannot meet the 6-hour reporting deadline without automated detection. A fraud cluster that is discovered in the morning review of overnight transactions has already missed the window. Real-time alerting is not just a fraud-reduction tool — it is a regulatory reporting prerequisite.
4. Customer Communication Requirements
RBI requires that customers be notified of blocked transactions in real-time via SMS or push notification — not just in account statements. For flagged (not blocked) transactions, the bank must provide a resolution mechanism within 4 hours during business hours.
The audit question examiners ask: "Show me the customer communication log for your last 10 blocked transactions, and show me the case resolution timestamps." Banks that cannot produce this in under 5 minutes during an inspection typically receive an adverse finding.
5. Model Governance for ML-Based Fraud Detection
If your institution uses a machine learning model for fraud scoring — and most now do — RBI's model risk management guidance (drawn from principles established in its 2023 IT governance directions) requires:
- Model documentation: Training data lineage, feature descriptions, validation results, and known limitations must be documented and version-controlled.
- Explainability: For any ML-based block decision, the system must be able to produce a human-readable reason. "The model said so" is not an acceptable explanation to an examiner or to a customer disputing a block.
- Regular validation: Model performance must be evaluated against live data at least quarterly. The PSI (Population Stability Index) and KS statistic are the standard metrics cited in inspections.
- Champion-challenger framework: Production models must be tested against challenger models continuously. A bank cannot deploy the same model for more than 18 months without documented re-validation.
How vcurd Addresses These Requirements
vcurd's platform was designed with these obligations as first-class requirements, not afterthoughts:
- Rule engine delivers scoring decisions in under 5ms — well within the real-time pre-authorization window.
- Mule Score integrates high in-degree / out-degree graph analysis, MHA district overlay, SIM-swap events, and bureau velocity in a single 0–100 score computed from NetworkX transaction graphs.
- Every scored transaction produces an audit log row with rule ID, features evaluated, decision, and timestamp — accessible via API and exportable for regulatory submissions.
- The LLM explanation layer generates a human-readable reason for every flagged or blocked transaction, satisfying the explainability requirement for ML models.
- CERT-In incident reports can be generated directly from vcurd's alert export, pre-formatted with the required fields.
The compliance checklist on our RBI & CERT-In compliance page maps each of these requirements to specific vcurd features.