Conducting Bank Branch Audit in CBS Environment


Most of the banks have moved to CBS environment. What was earlier the prerogative of the private sector banks and large public sector banks is filtered down to the large co-operative banks, district level co-operative banks and small co-operative banks. Sometimes mere payment/clearing system of the clearing house becomes a trigger move to a CBS environment to ensure that electronic transfer by the clearing house automatically reaches the account holder. All persons exposed to the branch like its depositors, borrowers and the auditors are affected by this. Information technology implications should not be seen only in isolation to report under Jilani Committee Recommendations since technology is all pervasive affecting the branch auditor’s opinion in most critical manner.

Core Banking Defined

Core banking is a system in which a centrally shared database supports the entire banking application. In other words, instead of an individual server at each branch of the bank, there is one common server for all the branches. This server is kept at a location called the Data Centre (DC). However, there exists a risk of failure of the common server. A backup site is maintained to aid such failure and when this site is at distant location (another city), preferably in a different seismic zone, it is called the Disaster Recovery Centre (DRC). It is not uncommon to see the DRCs to be located in different continents in case of multinational banks. A lot of care, therefore, has to be taken at the data centre but that not being in the scope of the branch auditor, it is not a subject matter of discussion here. Traditionally, the networking was done by way of leased lines as the primary network. In case of failure of such network, the connection was automatically dialed up to the other back-up network i.e. dial up Integrated Services Digital Network (ISDN). Later, other modes such as wireless network (radio frequency), VSAT (Very Small Aperture Terminal), VPN (Virtual Private Network) over the internet and cloud, came into popularity.

Branch Statutory Auditor and System Auditor

The branch auditor is not expected to be a technical expert to understand the IT system or the software. But, it is a fact that most of the banking operations are done through the computer. Since CBS is the neurological network of the bank, the branch auditor can ill afford to ignore the existence of the system. On the contrary, if the auditor is able to use the system, he/she will be able to improve his/her own efficiency. If the branch has been subjected to a Systems Audit, the branch auditor can peruse the report to gain insight. He must ensure that any reliance on such report is only as per the guidelines given by the Institute of Chartered Accountants of India (ICAI) on dependence of work of an expert, because some system audits are known to be executed by non chartered accountant firms.

Critical Issues in CBS Branch Audit

A Branch Auditor may be complacent at his own peril if he mistakes presence of computer or the brand of the application software for accuracy and the desired results, since the following issues have been noted:

1. Final accounts may not be representative of the books of accounts:

An unbelievable alarming statement is unfortunately true. This issue would fall more into the realm of fundamental duty of the auditor. This issue is often neglected as the statutory auditor dives into the matters of Borrower classification and items of Long Form Audit Report (LFAR). Once this issue is revealed post audit, it would be quite difficult for any auditor to defend himself. This complex situation can be simplified on the basis of the plausible reasons, also being the areas that branch auditor should concentrate:

  • When all departments are not computerised:

Where some departments are not computerised, the vouchers are manually fed into the core system. Such departments may range from Lockers to Treasury and Foreign Exchange. In such cases, the vouchers are entered at the end of the day. If any of the day’s vouchers are not entered resulting in a compensating error, no one is wiser since the trial balance tallies.

  • When most departments are computerised but by different applications:

This is not an uncommon situation. But, different applications does not always mean problem. How the different applications feed their data into the core system is the crux of the issue. System auditors are better placed in the evaluation of such matters. Reference to the System Audit report is therefore recommended. Sometimes, the communication between the application and the core system is affected preventing entry upload. No warning is given even though it should be there. The books of that department show a figure quite different from that shown in the general ledger leading to the crucial situation of final accounts not being in agreement with the books of accounts.

  • When new channels like Automated Teller Machine (ATM) are added:

New channels linked recently are sometimes not tested substantially. An example of ATM itself will clear the point. In any bank, the books are closed for the day and re-opened almost immediately. Day closure is done any time from 5 pm to 10 pm. Assume that a customer has withdrawn cash on 31st March at 7 pm when the books were closed at 5 pm. This withdrawal is shown on 2nd April. If you had verified the cash at 5 pm on 31st March, even of the ATM you would find such a situation as correct. But when the posting is done on 2nd  April, there is implication on revenue since the savings accounts are paid interest on daily basis. The customer gains interest of two days in this situation and more during long bank holidays. If the application has interest calculation on ‘as of’ basis then perhaps the interest loss will not occur.

2. Borrower health classification:

Accurate classification of health of the borrowers of the branch has become the most important aspect of statutory branch audit. This has serious implications on the balance sheet of the bank in terms of provisions. Many application systems have a special routine or report or even separate software which does the work of classification of borrowers. Blind acceptance of such report will be tantamount to non-performance by the branch auditor. It is preferable for the branch auditor to test the system. What the system skips for classification of non-performing accounts (NPA) or what is incorrectly classified as NPA is of concern to the branch auditor. Branch auditor will thus have to sample test the system to assure him the accuracy of the classification as detailed below:

  • Compare the previous year’s NPA list with the current list. Identify and seek reasons for why the accounts are upgraded and whether the reasons are justified as per rules permitted by the regulatory authority i.e. the Reserve Bank of India (RBI).
  • Take the report from CBS system (as opposed to the borrower classification system which is a different application in some banks) which gives indications of nonperforming accounts in form of a few combination of reports like:

a) List of loan accounts in arrears – if the report permits, get those accounts where more than two installments are in arrears (since three installments in arrears is defined as NPA). This will permit you to study the borderline cases and identify some which the system may not have downgraded.

b) The above report does not include Cash Credit (CC) and Overdraft (OD) accounts. This is because these accounts are continuous and there is no concept of ‘installment’. What most systems will report will be CC and OD accounts which are overdrawn. Branch auditor will be able to identify the accounts which are overdrawn as on 31st March and a scrutiny of the accounts will confirm the date from which these accounts were ‘continuously’ overdrawn. If this period exceeds ninety days then the account needs to be classified as NPA. A check on classification of accounts to confirm such accounts are classified as non-performing will be adequate. A random check of earlier months will help isolate cases where accounts are continuously overdrawn but brought in order artificially for the year end.

c) Report of accounts not renewed/reviewed for more than a year is one of the statements to be submitted in LFAR. This list helps in confirming whether these accounts are included in the NPA list.

d) Report of stock statements in arrears: A report of Stock/Debtors statements not submitted to the bank for a period exceeding a user specified number of months should be generated and reviewed. If you specify the period of three months which is the trigger to downgrade the borrower’s account, thiswill be a ready list to validate the NPA list of the branch.

e) Report on overdue Bills Purchased and Bills Discounted: This is another powerful report for verification of classification. The importance of this report is that while the other facility of the borrower may be in order, this department may be accidentally ignored. Since one NPA account forces all facilities to the borrower to be downgraded, this oft-ignored feature should be emphasised by the branch auditor.

Intervention of the Bank’s Data Centre and their professionals to make a customised query is not always needed.

3. Anti Money Laundering (AML) application and its accurate representation:

The branch auditor is the last sentinel to protect the bank from abuse of this aspect. As the governing body – the Reserve Bank of India has amply reminded by issuance of various circulars, the statutory auditor needs to cover this aspect. Most CBS banks have resorted to software application for AML reporting. This software application may be from the CBS application provider or a third party software. Whatever be the case, the common feature of concern is that this module or application is an ‘afterthought’ as the AML guidelines came in force more than two decades after CBS. The fundamental feature of this module/application is that it ‘reads’ data from CBS and processes it for its report. This feature of ‘reading’ is important because many banks boast NIL cases. This is usually because of ‘mapping’ error. This module looks at the wrong places and comes back with no cases to report which is misconstrued as NIL returns. Auditor can also scrutinise the ‘white listing’ of cases where the branch is better suited to remove the cases of suspicious transactions based on some rules of deposit and withdrawal which are also specified by the Reserve Bank of India. The reasons for not considering the transaction as suspicious is within the realm of the branch, by identifying retail cash business of account holder like petrol service station or grocer, etc. The classification rules are set normally at the data centre which the branch auditor need not concern with. But the reasons and replies definitely are of his concern to ensure these are logical and do not undermine the objectives of AML. Low AML training of bank staff emphasises the intervention of the branch auditor for AML audit.

4. Revenue accuracy assurance:

When most banks, even the co-operative banks have evolved to CBS, a topic of discussion like revenue leakages seems prima-facie redundant because the involved computer servers are the latest generation of machines having fourteen floating decimal point! Perhaps one may have to reconcile time period of this discussion being that of transitory to the destination of perfection, until which, we shall have to recognise the feature of imperfection, thus adjusting our audit plan to the inevitable verification of revenue accuracy even in the presence of the formidable machines and their magnificent chips. If one were to attempt a classification of the revenue errors, one might see a range of errors with severity to make most of us lose sleep or re-calculate every computer print. Analysis will show that operational or user error is the major cause and in very few cases, the software coding may be the cause of the error.

  • Interest not levied on a particular product of the bank: For example, advance against mutual funds. All advances made under the new product will suffer the same fate. Since interest and all charges run are executed at the data centre, if one account is skipped, all accounts will be skipped at least for the branch. The source of the error is most likely at the time when new product is set up by the data centre. Mapping of the account (technical jargon) may not be done to the interest procedure. This means that the interest or charges procedure which is activated manually by the data centre does not have this product in its list.
  • Non responsiveness of rate to increase in PLR/TLPLR/ WCPLR, etc.: When the rate sanctioned for an account are linked to prime lending rates – PLR (say 1% over PLR), then the intention and expectation is that any change in the PLR will change the rates of ALL such accounts. Some accounts or group of accounts do not respond to the changes in the rates leading to under/ over recovery of interest. Two possible reasons causing such a situation may be:

a. The user has not opened the account [row][third_paragraph] Left Side Content [/third_paragraph][paragraph_right] Right Side Content [/paragraph_right][/row]correctly in the interest section.

b. Account converted from legacy system may not carry the PLR link feature of the new system. Ideally, this should have been detected and corrected under conversion audit.

  • Installment holiday miscalculates the total equal monthly Installments (EMI): Where the borrower is eligible for EMI holiday (for example, housing loan under construction or education loan) and the calculation of EMI is done manually, there is a possibility of over or under recovery. Under recovery in such cases lead to ‘self caused’ NPAs. It is also not uncommon to note over-recovery where the loan accounts reach credit balances. This is usually a manual error caused by lackadaisical supervision at the time of account opening which is the time of EMI calculation.
  • Error in varying interest rate in a single advance account: OD against bank’s own fixed deposits may not always be right, for example, 12% upto R2 lakh & 14% between R2 lakh to 4 lakh. Since the manual calculation is a simple procedure, one expects it to be in the software with ease. Reality however dictates its success contingent on the caliber of the programmers. A sample audit will be in good stead. Under or over recovery is the result. Normally, the borrower would be the first to object in case of over recovery.


One hopes to reach the level of perfection until which this transitory phase shall be the irony of our audit activity where we have to re-check on our rupees two hundred worth calculator whether the computer worth rupees twenty lacs has done its calculation correctly! In conclusion, though computers deliver accurate results, it is only because of a combination of user accuracy with that of the programmer. Auditors may be able to manage with the right reports of the system itself and a bit of sample testing to perform their given task.





























Be the first to comment

Leave a Reply