Transaction Monitoring in India: Rules, Reports, Red Flags

Defining transaction monitoring takes one sentence. The harder question for an Indian compliance lead is what happens next: once your monitoring throws something up, what does an RBI-regulated entity actually have to do with it, what does it have to file, by when, and under which rule. That last part is where most guides go quiet.

Transaction monitoring is the ongoing-due-diligence half of your AML programme. Onboarding closes, and then it keeps watching how an account behaves across weeks and months, flagging activity that doesn't match the customer you signed up. In India none of this is optional, and none of it is generic. Two instruments govern it, the RBI's KYC Master Direction and the Prevention of Money Laundering Act, and the whole thing feeds a defined set of reports into the Financial Intelligence Unit, FIU-IND.

Both halves matter, so we'll cover both. The discipline first. Then the Indian machinery a global explainer leaves out: the RBI paragraphs that mandate monitoring, the PMLA rules behind record-keeping and reporting, and the STR/CTR thresholds and timelines you're personally on the hook for.

What is transaction monitoring? (and where it sits in AML)

Transaction monitoring is the ongoing review of customer transactions, real-time and over time, to catch activity that doesn't square with the customer's known profile and to spot funds that might be tied to money laundering or terror financing. It surfaces suspicion for a human to investigate. Proving innocence or guilt isn't the job.

Where it sits in your AML programme matters, mainly because people muddle the three core controls all the time.

• KYC settles who the customer is at onboarding: identity, beneficial ownership, expected activity. A point-in-time exercise, refreshed on a periodic-updation cycle.
• Screening runs a name against sanctions, PEP and watchlist data, plus adverse media. Point-in-time again, a match against a list at one moment.
• Transaction monitoring watches behaviour. Of the three, it's the only one that observes the customer over time, weighing what they actually do against what you expected.

KYC tells you the account belongs to a salaried professional in Pune who declared a monthly inflow in the low lakhs. Screening tells you they're not on a sanctions list. Monitoring is the control that notices when ₹40 lakh moves through that account in nine days and exits to twelve unrelated payees. The first two open the account. Monitoring is what watches it after.

Why transaction monitoring is mandatory in India: the RBI–PMLA–FIU-IND framework

Most ranking guides frame monitoring against FATF principles or the US Bank Secrecy Act. Useful background, wrong rulebook. As a regulated entity in India you answer to three instruments, and an audit measures you against them.

The PMLA and its Rules sit at the top. The Prevention of Money Laundering Act, 2002, together with the PMLA (Maintenance of Records) Rules, 2005, requires every reporting entity to keep records of transactions and furnish prescribed reports to FIU-IND. In the Act's own language a reporting entity is a banking company, financial institution, intermediary, or a person carrying on a designated business or profession. Banks, NBFCs, payment companies, brokers, and a long tail of others.

The RBI KYC Master Direction, 2016 takes that statute and turns it into operational obligation for the entities RBI regulates. The ongoing-monitoring requirements get specific:

• Regulated entities have to conduct regular monitoring of transactions so they stay consistent with the RE's knowledge of the customer, their business and risk profile, and the source of funds or wealth (para 35).
• REs are told to pay close attention to large and complex transactions, RTGS included, that show unusual patterns inconsistent with normal expected activity and carry no apparent economic rationale or legitimate purpose; also to high account turnover inconsistent with the balance maintained; and to the deposit of third-party cheques and drafts followed by large cash withdrawals (para 36).
• How far the monitoring goes is aligned to the customer's risk category (para 37).
• REs must put in use robust software that throws up alerts when transactions are inconsistent with a customer's risk categorisation and updated profile (para 50).

Para 50 is the line that converts monitoring from policy into a system requirement. RBI isn't merely asking you to monitor. It wants software generating alerts.

FIU-IND is where all of it lands. The Financial Intelligence Unit of India receives, analyses and disseminates the reports the PMLA Rules demand, then shares intelligence with enforcement and regulators. In the regulator's eyes, your monitoring exists to produce those filings accurately and on time. So AML transaction monitoring in India is, practically, what keeps an RE current on para 35 and keeps the FIU-IND reports flowing.

That chain is what makes monitoring mandatory rather than just sensible, and it lands as squarely on transaction monitoring in banking as on any fintech or broker. A miss here isn't a quality lapse. It's a regulatory one.

STR vs CTR vs the other FIU-IND reports: India thresholds and timelines

This is the section the global guides can't write, since they're keyed to SAR/CTR in the US. India runs its own report set, its own thresholds, its own clock. Getting them exact is the line between a compliant filing and a regulatory finding.

Two distinctions carry most of the weight.

STR is value-blind and fast. There's no rupee floor. Even a ₹40,000 transaction can warrant an STR when the pattern around it gives reasonable grounds to suspect proceeds of crime, and the clock is seven working days from the moment you're satisfied it's suspicious, not from the transaction date. Closing that gap, between the transaction landing and the point you become "satisfied," is exactly what your monitoring and investigation process is for.

CTR is mechanical and value-driven. It fires when cash crosses ₹10 lakh, single or connected within the month, and it fires whether or not anything looks off. A volume report, not a suspicion report, batched to the 15th of the following month.

Treat these as one report, or bolt US SAR logic onto an Indian filing, and you've reproduced one of the most common ways monitoring programmes come apart on audit. Different reports, different triggers, different clocks.

The transaction monitoring process, step by step

The transaction monitoring process is the same loop everywhere. In India, though, each step ties back to a specific obligation and a specific data source. Here's the end-to-end flow.

1. Build the customer risk profile. Monitoring can only ever be as good as the profile it compares against, and that profile gets built at onboarding. This is where Indian programmes connect to the identity layer: PAN, the CKYC record, Aadhaar-based verification or Video-based Customer Identification (VCIP), declared occupation, expected turnover, source of funds. Para 35 makes "consistency with the customer's profile and source of funds" the test, which means the profile is the baseline. Build it thin at onboarding and every downstream alert is noise.

2. Define scenarios and thresholds. Now you translate risk policy into detection logic, rules and scenarios that fire when behaviour drifts: cash above CTR limits, structuring just under a threshold, velocity spikes, dormant-then-active accounts, transactions touching high-risk geographies. Thresholds get tuned to risk category, per para 37.

3. Generate alerts. The "robust software" of para 50 scores transactions against those scenarios and raises alerts, in real time or in batch depending on the rule.

4. Investigate and manage the case. An analyst opens the alert, pulls the customer history, the KYC record and the screening results, and works out whether the activity has a legitimate explanation. Most analyst time goes here. And this is where a connected case file, rather than data scattered across a handful of tools, decides how fast you reach the truth.

5. Decide and file. Close the suspicion and the alert gets dispositioned and documented. Otherwise you file: an STR within 7 working days of being satisfied it's suspicious, a CTR for qualifying cash by the 15th of the next month, and whatever other FIU-IND report the activity triggers.

6. Tune the rules. Monitor the monitors. Review false-positive rates, retire scenarios that only generate noise, add scenarios for typologies you've started to see in the wild. Tuning isn't housekeeping. It's how the programme stays effective and defensible.

Profile, alert, investigation, filing, tuning. That loop is the transaction monitoring process in KYC, and it keeps running for the entire life of the relationship.

Types of transaction monitoring: rules vs AI, real-time vs batch

Two design choices shape every monitoring system. Neither is an either/or, and the honest answer is almost always "both, deployed where each one is strong."

Rule-based vs AI/ML. Rule-based monitoring fires on explicit conditions: cash over ₹10 lakh, more than N transfers in an hour, a transaction to a flagged country. Transparent, easy to explain to an auditor, and that explainability genuinely matters. It's also rigid. A fixed threshold catches the customer at ₹10.1 lakh, misses the one structuring at ₹9.8 lakh, and throws off a lot of false positives along the way.

Machine-learning models work from behaviour instead of fixed lines. They learn what normal looks like for a segment of customers and flag deviation, which picks up subtler and newer patterns and, tuned well, cuts false positives. The price you pay for that is governance. A model needs explainability, validation and documentation, because at some point you'll be justifying its decisions to a regulator. Nothing in the Master Direction prohibits AI or ML, and para 50 still wants software throwing auditable alerts. The working answer ends up layered: rules for the bright-line, reportable triggers you can never afford to miss, and models for the patterns no rule can quite express.

Real-time vs batch. Real-time monitoring evaluates a transaction as it happens and can block or hold it, which is exactly what instant rails like UPI and RTGS demand, since the money is gone in seconds. Batch monitoring runs over a window of activity and is built to surface patterns that only emerge with time, the slow structuring, the account that wakes up after months of silence. Real-time catches the single bad transaction. Batch catches the campaign no single transaction reveals. In practice you run both.

Money-laundering red flags and India-relevant typologies

Every guide carries a red-flag list, and nearly all of them are generic and US-shaped. What follows is localised to how laundering actually moves through Indian accounts, with the patterns RBI itself calls out.

• Structuring below ₹10 lakh. Cash deposits deliberately kept just under the CTR threshold, ₹9.5 lakh, ₹9.8 lakh, repeated across days or branches to dodge the report.
• Third-party cheque deposits followed by large cash withdrawals. The exact pattern para 36 of the Master Direction names. Cheques or drafts from unrelated parties land in an account, then come out as cash.
• High turnover inconsistent with the balance. An account running crores through it while never holding much, the pass-through signature of layering. Straight from para 36 as well.
• Rapid in-and-out / pass-through activity. Funds arrive and leave inside hours or days, the account serving as a conduit rather than a destination.
• Mule-account fan-out over UPI. A sudden inflow split instantly across many small UPI transfers to unrelated payees, layering rebuilt for instant rails.
• Transactions with high-risk jurisdictions. Flows to or from geographies with weak AML controls, out of step with the customer's declared business.
• Trade-based laundering, over- and under-invoicing. Goods invoiced well above or below market value to push value across borders under cover of legitimate trade, a recurring vector in Indian trade-finance flows.
• Hawala-style value transfer. Value moving through informal networks with offsetting domestic transactions and no matching formal cross-border leg.
• Crypto layering. Funds cycled through virtual digital assets and multiple wallets to break the trail before they re-enter the banking system.

A red flag opens an investigation. It isn't a verdict, and most carry an innocent explanation. The work of the process is separating out the ones that don't.

The false-positive problem (and risk-based tuning)

Here's the unglamorous truth of transaction monitoring: most alerts are false. Naive rules running one-size-fits-all thresholds flag huge volumes of perfectly legitimate activity, and analysts spend their days clearing noise instead of working real risk. Pile on too many overlapping scenarios in the name of caution and you've made it worse, because the genuine alert drowns in the flood.

The fix is risk-based segmentation, the very principle para 37 already requires. You wouldn't monitor a low-risk salaried customer with the same scenarios and thresholds as a cash-intensive business carrying real risk. Segment by risk category. Apply lighter, broader rules to low-risk cohorts so they aren't over-flagged, and reserve the tighter, enhanced monitoring for the segments that warrant it. Then tune continuously against actual false-positive rates, rather than setting thresholds once and walking away.

A good chunk of false positives is duplication too: the same underlying entity alerting under several near-miss identities, or one network tripping five rules at once. Resolve the entity before the alert fires, see the relationships around it, and a lot of that noise disappears at the source. That's the design idea behind connected transaction monitoring software: resolving the entity and seeing the network across onboarding, screening and monitoring, all before an alert fires, collapses the duplicate and near-miss hits. On our platform, that's a 62% reduction in alert volume. Fewer, better alerts, and analyst hours move to the cases that actually matter.

Building a transaction monitoring programme that survives an audit

Monitoring isn't a standalone box you bolt on at the end. It reads the risk profile that onboarding and KYC created, the data screening enriched, and the activity flowing in live, and its strength comes entirely from the connections between those stages. Financial crime tends to hide right in the seams between them. The UBO surfaced at onboarding that nobody ever linked to the counterparty in a later transaction. The adverse-media hit from screening that never reached the analyst clearing the alert.

Let those stages live in separate tools and the seams turn into real gaps. Analysts re-key data, signals fail to carry forward, and at audit you're reassembling the trail from several systems and hoping it reconciles. Run them on one connected data model instead and a signal captured at onboarding is immediately usable in monitoring, while every step, the alert through the investigation through the disposition through the filing, writes to a single regulator-ready audit trail. When FIU-IND or RBI asks why an STR was or wasn't filed, you hand over one coherent record rather than a stitched-together reconstruction.

That's the test a programme has to pass. Not "did we have a monitoring tool," but "can we show, end to end, why each decision was made, against the right rule, on the right clock."

Conclusion

In India, transaction monitoring is the ongoing-due-diligence engine sitting behind your PMLA obligations. Define the term however you like; what counts is mapping it correctly to the RBI Master Direction's monitoring paragraphs and getting the FIU-IND mechanics right, an STR within 7 working days whatever the value, a CTR for cash over ₹10 lakh by the 15th of the next month. After that the work is making the system smart enough that your analysts spend their hours on real risk instead of clearing noise. Start from the framework, localise the red flags, and build the kind of audit trail a regulator can follow in a single pass.