Automation of Income Recognition, Asset Classification and Provisioning processes in banks

Reserve Bank of India

RBI/2020-21/37
Ref. No. DoS.CO.PPG./SEC.03/11.01.005/2020-21

September 14, 2020

The Chairman / Managing Director / Chief Executive Officer
All Scheduled Commercial Banks (Excluding RRBs) and
All Small Finance Banks

Madam / Dear Sir,

Automation of Income Recognition, Asset Classification and Provisioning processes in banks

We invite a reference to our circular DBS.CO.PPD.No.1950/11.01.005/2011-12 dated August 04, 2011, in terms of which banks were advised, inter alia, to have appropriate IT system in place for identification of Non-Performing Assets (NPA) and generation of related data/returns, both for regulatory reporting and bank’s own MIS requirements. It is, however, observed that the processes for NPA identification, income recognition, provisioning and generation of related returns in many banks are not yet fully automated. Banks are still found to be resorting to manual identification of NPA and also over-riding the system generated asset classification by manual intervention in a routine manner.

2. In order to ensure the completeness and integrity of the automated Asset Classification (classification of advances/investments as NPA/NPI and their upgradation), Provisioning calculation and Income Recognition processes, banks are advised to put in place / upgrade their systems to conform to the following guidelines latest by June 30, 2021.

Coverage:

2.1 All borrowal accounts, including temporary overdrafts, irrespective of size, sector or types of limits, shall be covered in the automated IT based system (System) for asset classification, upgradation, and provisioning processes. Banks’ investments shall also be covered under the System.

2.2 Asset classification rules shall be configured in the System, in compliance with the regulatory stipulations.

2.3 Calculation of provisioning requirement shall also be System based as per pre-set rules for various categories of assets, value of security as captured in the System and any other regulatory stipulations issued from time to time on provisioning requirements.

2.4 In addition, income recognition/derecognition in case of impaired assets (NPAs/NPIs) shall be system driven and amount required to be reversed from the income account should be obtained from the System without any manual intervention.

2.5 The System shall handle both down-grade and upgrade of accounts through Straight Through Process (STP) without manual intervention.

Frequency:

2.6 The System based asset classification shall be an ongoing exercise for both down-gradation and up-gradation of accounts. Banks should ensure that the asset classification status is updated as part of day end process. Banks should also be able to generate classification status report at any given point of time with actual date of classification of assets as NPAs/NPIs.

Exceptions:

2.7 Exceptions may be granted from System driven classification in certain circumstances, which are expected to be minimum and temporary. It may be emphasised that these exceptions are from automated classification and not from IRAC norms and shall be subject to the conditions as explained below.

2.8 Banks shall not resort to manual intervention / over-ride in the System based asset classification process. In any exceptional circumstance where manual intervention is required to override the System classification, it must have at least two level authorisation. Such delegation of powers for authorising the exceptions should be as per the Board approved policy of the bank (by CEO, in case of unavailability of Board) and preferably should be done from the centralised location and suitably documented. Further, any such intervention shall have appropriate audit trails and subjected to audit by concurrent and statutory auditors. Detail reports of such manual intervention shall be placed before the Audit Committee / Audit Head (banks having no Board) regularly.

2.9 Banks shall maintain logs for all exceptions i.e. manual interventions / over-rides including, but not limited to, the date and time stamp; purpose/reason; user-IDs, name and designation of those making such manual intervention and necessary account details. These logs shall also be stored for a minimum period of three years and not be tampered with during the storage period. These logs shall be system generated.

System Requirements and System Audit:

2.10 In case a separate application outside the CBS is used as the System for NPA/NPI identification and/or classification, the System must have access to the required data from the CBS and/or other relevant applications of the bank and the borrower/investment accounts shall be updated back into the CBS automatically, wherever applicable, through STP.

2.11 Banks shall keep the business logic and other parameters/configurations of the System updated to ensure that the System based identification, classification, provisioning and income recognition are strictly in compliance with the regulatory guidelines on an ongoing basis. There should be periodic system audit, at least once in a year, by Internal / External Auditors who are well versed with the system audit both on system parameters as also from the perspective of compliance to Income Recognition, Asset Classification and Provisioning guidelines.

General:

2.12 Banks may draw up their standard operating procedure (SOP) for System based NPA classification for usage by the operating staff.

2.13 Baseline requirements for the NPA classification have been provided in the Annex. Banks are required to adhere to these instructions while designing and maintaining the System.

3. The adherence to these instructions will be examined as part of supervisory assessment of the banks and in case of non-compliance, suitable supervisory / enforcement action shall be initiated against the concerned bank.

Yours faithfully,

(Ajay Kumar Choudhary)
Chief General Manager

Encl: As above (Annex)

Annex

Baseline Requirements for the NPA classification Solution

I. Data Input

1. Data Input in the system by any means should be fully captured and stored without truncation [For example, time stamp – with date and time, narration field, or any other text data captured].

2. Ensure presence of necessary validation/verification checks in the solution for the user inputs, wherever applicable. Such validations, among other things should check for data type validations, min/max value, exceptions, etc.

3. Ensure necessary data validation/checks in the system for the data keyed in manually, wherever applicable. For example, such validations with master data (or parameters used in asset classification fed into the system as per the internal policy of the bank) could prevent issues related to incorrect entries generally seen (illustrative but not exhaustive list) in margin setting, moratorium period, security valuation, repayment schedule, products mapped/linked to different categories of account holders (as per applicability) etc.

4. Data input shall be effected only after authentication and authorisation.

II. User Access Management

5. Ensure that all “user-ids” in the solution have unique identification. If there are any generic user-ids used, it should only be used under exceptional circumstances and such ids should be mandatorily mapped to the employee ID of the user to fix accountability of the activities carried-out under the generic ID.

6. Provide for two-factor or higher level of authentication for the users of the application.

7. Restrict the access to the solution on “need to have/least privilege” basis for all users.

8. Provide for maker checker authorisation /control for transactions (an illustrative list of transactions includes updating/modifying the internal accounts, customer accounts, parameters – both financial and non-financial that affect the status of the credit portfolio/loan/asset.) entered in the solution. This shall also include transactions/activities carried out by administrator accounts in the application. (For example: Activities such as create/update/modify user-ids, roles, privileges including access rights to various modules; system related activities including updates to master data, etc. should have at least two individuals to complete the activity).

III. Straight Through Processing (STP)

9. Provide for straight-through processing (STP) and support for STP integration with all critical systems/add-on sub-systems/modules etc., in a seamless and secure manner for NPA/NPI classification as per extant guidelines on IRAC. Such STP mechanism shall seamlessly take into account all the facilities availed by a given customer (in case of advances) and all the instruments of an entity (where bank has made investments in an entity), maintained across multiple systems of the bank without any manual intervention. Further, banks shall also ensure that the updated account status, including asset classification of the customer accounts, flow to the CBS automatically, if NPA classification process is performed outside CBS.

IV. Back-end Data Access Restriction

10. Any changes to the data, parameters from backend shall be avoided. The solution should provide for changes to the data items only through front end (from the application (Ex: CBS) itself and not through the backend database update) after requisite authorisation. Audit trails/logs of access, changes to any data, parameters, if any, should be captured with specific user details in the system.

11. In case of exceptions in rare circumstances, such changes should be duly approved at an appropriate level and documented. Provision for MIS report should be available to auditors to generate complete list of back-end access and changes made.

V. Audit Logs

12. Provisions of audit trails/logs to capture details of mandatory fields (that are essential to complete the transaction and essential to identify the transaction for audit/forensic purpose in the future) of all the transactions (financial and non-financial) shall be made.

13. Logs should be maintained for changing the master data. System generated activity logs of the users with administrative privileges should also be maintained.

14. Secure storage and retention of logs in encrypted format with access controls in an archival solution.

VI. System Generated NPAs

15. All parameters required for NPA/NPI identification shall be captured in the CBS or associated sub-system(s)/module(s) meant for NPA/NPI identification/classification of asset codes as per Income Recognition and Asset Classification (IRAC) norms and extant instructions. It should provide for separate MIS report capturing all parameters for NPA/NPI identification. Such parameters could either be configured in database or application itself as per the architecture of the solution/sub-system.

VII. Test Environment

16. The existing test environment in the bank with dummy data and functional logic similar to that of the product environment of the solution shall be made available to the supervisors during their onsite supervisory visit(s) as per the requirements. This shall be required, inter alia, to perform sample transactions review to assess whether the solution adheres in complying with regulatory prescriptions in the extant environment for NPA/NPI identification as per applicability.