What is fraud intelligence?
Fraud intelligence, in an Indian fintech, is the layer that decides — in sub-second time — whether the customer in front of you is who they claim to be, whether the transaction they are attempting is what it appears to be, and whether the device, network, and behaviour signals around them are consistent with a real customer or with a fraud operation. Where identity verification answers "is this person who they say they are", fraud intelligence answers the harder follow-up: "and is what they are doing with the account legitimate?"
The Indian fraud surface is unusually adversarial. UPI clears in seconds; IMPS clears in seconds; document forgery is cheap; SIM-swap and number-porting are commodity attacks; mule networks recruit through Telegram channels at scale; and the customer base spans urban smartphone-native users and rural feature-phone users with very different vulnerability profiles. A fraud stack that works in Western fintech does not automatically port to India — the rails are faster, the documents are more standardised (which both helps detection and gives forgers a fixed target), and the regulatory reporting expectations are stricter.
This guide walks the fraud surface in the order an Indian fintech actually meets it: regulators first (RBI fraud reporting, PMLA, FIU-IND, IT Act 66C/66D, NPCI fraud guidelines), the five fraud surfaces every fintech meets, the audit distinction between fraud and AML, the detection-vs-prevention framework that decides where you spend your budget, what continuous monitoring looks like after onboarding, and the five implementation pitfalls every fraud team trips on before they ship a defensible stack.
India fraud regulatory map
Five regulatory layers shape fraud intelligence in Indian fintech. None of them sit alone; a single fraud event typically triggers obligations under three of the five simultaneously.
The Reserve Bank of India sets the primary fraud-reporting framework for banks, NBFCs, and payment-system operators. The RBI fraud-monitoring circulars (Master Direction on Frauds, last amended 2024) prescribe the Central Fraud Registry (CFR) for fraud incidents above defined thresholds, and the Central Repository of Information on Large Credits (CRILC) where credit-related fraud surfaces. RBI also runs the Master Directions on Digital Payment Security, which set the minimum control set for fraud defense on digital rails.
The Financial Intelligence Unit India (FIU-IND) owns the PMLA-side overlay. Fraud events that look like money laundering, sanctions evasion, or terrorist financing trigger Suspicious Transaction Reports filed through FIU-IND's FINNet portal within 7 working days of forming the suspicion. The fraud and AML pipelines share signals but produce different artifacts — fraud produces a block/step-up decision; AML produces a STR.
The Information Technology Act, 2000 (as amended) criminalises identity theft (Section 66C) and cheating by personation using computer resources (Section 66D). For fraud teams, these are the sections under which the cyber cell registers the FIR when a confirmed-fraud event is referred. The evidence package — device fingerprints, IP logs, transaction trail, identity-mismatch markers — feeds directly into the FIR. Build the evidence-export pipeline to match the cyber-cell intake template; retrofit is painful.
The NPCI fraud-management framework governs UPI, IMPS, AePS, and the broader instant-payment rails. NPCI publishes fraud typologies, mandates merchant-side defenses, and runs the customer-protection rules that decide how chargebacks and dispute reversals flow. Any fintech on UPI must align to NPCI's fraud-detection guidelines as a precondition for rail access.
And on the meta-layer, the Financial Action Task Force (FATF) 2024 Mutual Evaluation of India set elevated expectations on monitoring effectiveness — fraud + AML together — through 2026–27. Coverage is no longer enough; the audit asks what you actually caught.
The 5 fraud surfaces Indian fintechs meet
Every fintech meets the same five surfaces. The labels vary; the underlying attacks do not.
1. Synthetic identity at onboarding
Constructed identities — real PAN paired with a fabricated name, real Aadhaar with a doctored address, real mobile bound to a fictional person. Each element passes its individual check; the combination is fictitious. Defense lives in cross-element consistency: does this PAN belong to this name? Does this mobile belong to this person? Does this address match the OVD address? Identity fraud defeats single-element verification; it loses to fused decisioning.
2. Account takeover (ATO)
Credential stuffing, phishing-driven password reuse, SIM-swap, OTP interception. The attacker controls the channel briefly and drains or rebases the account. ATO defense is layered: device fingerprint at every authenticated session, behavioural baseline over 30 days, step-up to liveness + face match when divergence crosses threshold. The minimum viable stack is three signals — device, behaviour, network — combined into one continuous score.
3. Mule accounts
Real accounts opened by real (or stolen-identity) people, used to receive proceeds of fraud and route them onward via UPI/IMPS/P2P transfer before recall is possible. Mule accounts often dwell quietly post-onboarding before the first laundering pulse; the detection window is at onboarding (combined identity + device + network + history score) and continuously thereafter (velocity, beneficiary-graph density, geo-mismatch). Pure identity verification does not catch mules — the identity is real.
4. Document fraud
Forged Aadhaar, PAN, voter ID, driving licence — usually photo-edited rather than structurally fabricated, because the underlying format is standardised and well-known. Document fraud detection combines OCR (does the text parse cleanly?), structural validation (does the layout match the issuing authority's template?), and tamper-evidence (copy-paste artifacts, font inconsistencies, JPEG double-compression markers, signature splicing). Catch at upload, not after the document is trusted downstream.
5. Transaction laundering / social-engineering
The customer is real, the account is real, the authentication is genuine — but the customer has been manipulated into a transfer they would not have made absent the deception. Social engineering patterns: distress messaging (fake hospital/family emergency), OTP-share prompts ("your account is being verified, share the OTP"), beneficiary-add-then-immediate-transfer with atypical amount. Defense is behavioural: flag the high-risk pattern before the transfer clears, and step up to a verified-channel confirmation. The customer's authentication is not the question; the customer's intent is.
Fraud vs AML — what the auditor distinguishes
Engineers conflate fraud and AML; auditors keep them on separate review tracks. They share signals (identity, device, network) but produce different artifacts, run at different cadences, and answer to different regulators.
| Dimension | Fraud intelligence | AML monitoring |
|---|---|---|
| Question it answers | Is this customer + transaction what it appears to be? | Does the pattern look like laundering, sanctions evasion, or TF? |
| Cadence | Sub-second at decision time | Minute-to-hour, continuous against rule + model set |
| Signals used | Identity, device, network, behaviour, velocity, beneficiary graph | Transaction patterns, sanctions/PEP lists, geography, typologies |
| Owner team | Fraud risk management (FRM) | Compliance / FIU-reporting |
| Output artifact | Block / allow / step-up decision, logged with rationale | Alert → case → close-with-rationale or STR to FIU-IND |
| Failure cost | Loss event + customer-trust hit + RBI fraud report | Regulatory penalty + license risk + PMLA exposure |
Build them as one stack with two views. The same identity infrastructure — face match, sanctions screening, device fingerprint, behavioural baseline — feeds both pipelines. The difference is the decision contract: fraud produces a synchronous block/allow at the rail; AML produces an asynchronous investigation workflow that lands in either a closed case (rationale captured, retained 5 years) or an STR filed within 7 working days. The auditor samples both — fraud through the RBI fraud-incident registry, AML through the FIU-IND FINNet portal.
Detection vs prevention — the framework that decides where budget goes
Fraud teams burn budget on the wrong layer when they conflate detection with prevention. Detection asks "what fraction of fraud events did we catch?" Prevention asks "what fraction of fraud events did we stop before loss?" The metrics differ, the architecture differs, and the tradeoff against customer experience differs.
Detection-only stacks see fraud after the fact: post-clearance review, chargeback analysis, customer-reported incidents reconciled to logs. The cost is the loss itself; the value is the learning loop that improves prevention next quarter. Detection-only is necessary but never sufficient — the loss has already cleared.
Prevention stacks decide at the rail, in sub-second time, with the customer waiting. The signal set is what is available at decision time: device, network, behaviour baseline, velocity, beneficiary history, identity-coherence score. Prevention inherits a hard tradeoff against customer friction — every step-up is a customer-completion tax. The point of the layered decisioning approach is that low-risk events skip step-up entirely (sub-200ms verify-only path), high-risk events get challenged hard (liveness + face match), and the threshold tuning is the product.
The framework that holds: spend prevention budget on the surfaces where loss is irrecoverable (UPI/IMPS/AePS — funds gone in seconds, recall window minimal); spend detection budget on the surfaces where loss is recoverable (cards with chargeback, delayed-settlement rails); and spend the rest on the learning loop that closes the gap between the two.
Continuous monitoring + post-onboarding signals
Fraud teams that ship onboarding controls and stop there miss the dwelling-mule problem. Mule accounts often clear onboarding cleanly — the identity is real, the documents are valid, the device is unremarkable — and then sit quietly for days or weeks before the first laundering pulse. The detection window is post-onboarding, not at the gate.
The signal set that runs continuously, not just at onboarding:
1. Velocity. Transaction count and value, beneficiary-add count, login frequency — each compared to the customer's 30-day baseline. Sudden velocity jumps from a previously dormant account are the classic mule signal.
2. Beneficiary-graph density. The set of accounts the customer transacts with, viewed as a graph. Mule accounts cluster into dense subgraphs (the same set of beneficiaries appears across multiple accounts); legitimate accounts don't.
3. Device + behaviour drift. Has the device fingerprint changed? Has the typing cadence shifted? Has the IP geolocation moved unusually? Drift from baseline is the strongest ATO signal, and it accumulates continuously rather than triggering at one event.
4. Adverse-media monitoring. Court records, FIRs, regulatory orders, fraud allegations — run as continuous monitoring against your customer base, not as a point-in-time check at onboarding. The most material fraud signals (a director charged with cheating, a business named in a fraud FIR) surface as news before they ever show up in MCA filings or court registries.
5. MNRL refresh. Mobile Number Revocation List polled at every refresh trigger — large transaction, product upgrade, dormancy break, periodic-review cadence. MNRL hits close the most common ATO vector before it can be exploited.
Continuous monitoring requires a case-management layer to investigate the alerts that surface. Teams that ship monitoring without the case-management tool create a queue nobody works — alerts pile up, the 7-day STR window slips on the AML side, the loss window opens on the fraud side, and the audit observation lands. Build monitoring and case management at the same time; they're half a product, not two.
Implementation pitfalls — the 5 that bite
Every fraud team hits the same five.
1. Trusting MNRL only at onboarding. Mobile-number revocation is a rolling event — a number clean at account opening can be ported, surrendered, or reissued three months later. Run MNRL as a hard gate at every refresh trigger, not as a one-time check. The audit asks for the rolling logs.
2. ATO defense without device fingerprinting. Cookies alone fail the moment a customer clears their browser. The minimum viable device layer is cookies plus a browser canvas/font/audio fingerprint at minimum (and an app install ID on mobile). Skip the fingerprint and the ATO defense is a thin facade — credential stuffers will defeat it in week one.
3. Document-fraud detection without tamper-evidence on the OCR pipeline. OCR alone confirms a document parses; it does not confirm the document is genuine. Forged OVDs are usually photo-edited rather than structurally fabricated, so OCR clears them. Tamper-evidence (copy-paste artifacts, font inconsistencies, JPEG double-compression markers, signature splicing) is the layer that catches them. Build it into the OCR pipeline, not as a bolt-on review queue.
4. Treating "no court record" as proof of clean intent. Court records and FIRs catch the population that has been formally accused or charged. They miss the population whose fraud has not yet been reported, and they lag by weeks or months between event and registry update. Use adverse-record checks as a layered signal, not as proof of honesty — and combine with adverse-media monitoring to close the lag.
5. Building fraud monitoring without a case-management investigation tool. Continuous monitoring produces alerts; alerts require analysts to investigate; analysts require a tool that surfaces the customer's full history (KYC, transaction trail, device + behaviour, prior alerts) in one workspace. Teams that ship monitoring without the case tool create a queue nobody works. Build the case-management layer at the same time as monitoring; they are half a product.
How Deepvue ships fraud intelligence
Every API in the catalog below sits on the same auth, the same SLA, the same decisioning layer underneath. Identity, MNRL, document OCR with tamper-evidence, face match, liveness, court records, FIR checks — one contract, one audit log. Mule scoring, device fingerprinting, behavioural baselining, and adverse-record continuous monitoring run on the same layer.
The audit trail is the load-bearing layer. Every check, every step-up, every block, every override — logged per-customer with rationale captured at decision time. RBI fraud reporting, FIU-IND STR filing, and the IT Act 66C/66D evidence package all draw from the same source of truth, retained for the regulatory window.
Sub-200ms latency on the verify-only path; step-up to liveness + face match at the rail when divergence crosses threshold. RBI-aligned, NPCI-compliant, FIU-ready, DPDP-built-in. Live in production catching 12M+ fraud-relevant events across 60+ Indian fintechs.