RBI transaction monitoring compliance for commercial banks now sits in one consolidated instrument. On 28 November 2025 the Reserve Bank of India issued the Reserve Bank of India (Commercial Banks – Know Your Customer) Directions, 2025, alongside separate KYC Directions for other categories of regulated entity. The Commercial Banks Directions were last updated on 1 October 2026.
This article covers the Commercial Banks Directions only. Small finance banks, for example, and other categories of regulated entity have their own Directions issued the same day, and those should be read from their own texts.
The pattern across the Directions is consistent. A customer is categorised, the category sets how closely the account is watched, and alerts are meant to fire when activity departs from the category and a current profile. The control holds only if the category is current, which is why the Directions also run clocks for review and updation.
The customer’s risk category sets monitoring intensity and alert logic, and the review and updation clocks keep the category and profile current.
The Reserve Bank of India (Commercial Banks – Know Your Customer) Directions, 2025 require banks to categorise customers as low, medium or high risk (paragraph 20), undertake ongoing due diligence so that transactions stay consistent with what the bank knows about the customer (paragraph 39), align the extent of monitoring with the risk category and review the categorisation at least every six months (paragraph 41), and run software that alerts on transactions inconsistent with the customer’s risk categorisation and updated profile (paragraph 55).
What the Directions require of monitoring
Paragraph 6 requires a Board-approved KYC policy with four elements: customer acceptance, risk management, customer identification and monitoring of transactions. Paragraph 39 defines the monitoring duty as ongoing due diligence, so that transactions are consistent with the bank’s knowledge of the customer, the customer’s business and risk profile and the source of funds or wealth. Paragraph 40 names transaction types that must be monitored and says a bank may consider adopting AI and machine learning technologies to support effective monitoring.
| Paragraph | What it requires | Evidence to hold |
|---|---|---|
| 20 | Categorise customers as low, medium or high risk using parameters such as identity, business, geography, products, channel and transaction types | Written categorisation logic and the reasons for each customer’s category, kept confidential from the customer |
| 39 and 40 | Ongoing due diligence; monitor large and complex transactions, threshold breaches, high turnover against balance, and third-party cheque deposits followed by large cash withdrawals | Scenario coverage mapped to the paragraph 40 categories |
| 41 | Align the extent of monitoring with the risk category; review categorisation at least every six months; intensify monitoring of high-risk accounts | Review records and the monitoring rules applied to each category |
| 55 | Software that generates alerts when transactions are inconsistent with the customer’s risk categorisation and updated profile | Alert logic showing category and profile as inputs |
Why the risk category has to drive alert logic
Paragraph 55 makes the link explicit. Alerts are to be generated when transactions are inconsistent with the customer’s risk categorisation and updated profile, so two inputs have to be live: the category and the profile. One threshold applied to every customer cannot satisfy it, and neither can a category set at onboarding and never moved.
Paragraph 41 adds that the extent of monitoring follows the category, with more intensified monitoring for high-risk accounts. The Directions also treat some groups as high risk by design: customers onboarded non-face-to-face, other than through the Aadhaar OTP route in paragraph 25, are to be categorised as high risk and subject to enhanced monitoring until their identity is verified in person or through video-based identification (paragraph 44), and accounts of politically exposed persons are under enhanced monitoring on an ongoing basis (paragraph 45).
Low
Monitoring aligned to the category; KYC updation at least every 10 years.
Medium
Monitoring aligned to the category; KYC updation at least every eight years.
High
More intensified monitoring; KYC updation at least every two years.
Set by rule
Non-face-to-face onboarding and PEP accounts carry enhanced monitoring.
Three clocks the Directions run on
The Directions run three separate clocks. A change in one should reach the others: a re-categorisation changes monitoring intensity at once, and a KYC update changes the profile that alerts compare against.
For customers that are legal entities, paragraph 42 requires the bank, when it updates their KYC, to make sure beneficial ownership information is accurate and to update it where needed. The Directions define a controlling ownership interest in a company as more than 10% of the shares, capital or profits (paragraph 5), so ownership changes should reach monitoring as profile changes.
Continuous
Transaction monitoring and alert generation (paragraphs 39 to 41 and 55).
At least every six months
Review of risk categorisation and the need for enhanced due diligence (paragraph 41).
Two, eight or ten years
Periodic updation of KYC for high, medium and low-risk customers (paragraph 42).
Where identity and fraud events should change the category
The Directions do not use the language of fraud and AML integration, but several paragraphs create the data for it. Banks must report a detected case of forged identity through video-based customer identification as a cyber event (paragraph 27), must have systems that alert on breaches of the conditions applied to accounts opened through Aadhaar OTP based e-KYC (paragraph 25), and must treat non-face-to-face accounts as high risk until identity is verified (paragraph 44). Each is an identity or fraud signal that bears on the customer’s risk category.
The Directions require the alerts and the reporting. They do not say how an identity or fraud event must change a risk category. That design decision sits with the bank and should be recorded in its Board-approved policy.
What Boards and auditors will ask for
The Directions make responsibility visible. The Board or a delegated committee approves the KYC policy (paragraph 6). Banks must allocate responsibility, arrange independent evaluation and concurrent audit, and submit quarterly audit notes and compliance to the Audit Committee (paragraph 12). The ML/TF risk assessment is reviewed at least annually and presented to the Board (paragraph 10). A bank may not outsource decision-making on determining compliance with KYC norms (paragraph 13), and filing a suspicious transaction report does not by itself justify restricting operations in the account (paragraph 54).
Show the category logic
Written rules, reasons and the date each customer was last categorised.
Show the clocks working together
Evidence that a re-categorisation or KYC update changed monitoring or the profile.
Show the alert inputs
Alert logic that uses category and updated profile, with threshold changes recorded.
Show decisions stayed in-house
Records that determinations of KYC compliance were made by the bank’s own staff.
How Nexiant supports category-driven monitoring
FraudShield, Nexiant’s specialist transaction-monitoring brand, is built around real-time detection, configurable rule logic and case-management workflows. For category-driven monitoring, the useful tests of any capability are whether the customer’s risk category is an input to rule logic, whether a category change takes effect in monitoring immediately, and whether the reason for a change stays in the case record. Nexiant brings these questions together across KYC, fraud and monitoring as a design discipline, not as a claim about one integrated system.
Frequently Asked Questions
Make the risk category drive monitoring
Speak with a Nexiant expert about connecting KYC risk categorisation to monitoring and case management, or explore FraudShield’s case-management and rule-configuration capability.
Speak with an expertThis article was accurate at the time of publication in October 2026 and is intended for general informational purposes only. It does not constitute legal, regulatory or compliance advice. Organisations should seek qualified professional guidance in relation to their specific obligations.


