c

CAB CALLING

October-December, 2008

Using Computer Assisted Audit Tools (CAATs) for Audit and Inspection of Banks in India
Jairam Rajshekhar*
Introduction
Arjun Singh, GM (Inspection and Audit) of a medium size bank Bank Premier who had recently implemented a Core Banking Software (CBS) was presenting on the role of Inspection and Audit in the changed environment to the Audit Committee. The question most commonly faced after any operational integrated software implementation faced by an internal auditor is Given that we now have an ERP an internal auditor's job is greatly reduced. Arjun Singh presented the role of the auditor in the changed environment in terms of IT general control reviews and assurance services, physical document based audits apart from compliance to various directives of RBI, SEBI, BSE, NSE, NSDL and other regulatory authorities. While various reports as required by operations and the regulatory authorities were customized and available as a menu option in the CBS, there was a regular requirement for trend analyses, adherence to KYC norms, AML compliances and various other audit objectives. New audit objectives were being defined in line with the new environment considering the criticality of people input in the new system. Further, as a means of increasing the extent of substantive testing by departmental staff and reducing cost of audit, Arjun Singh also proposed the implementation of a Generalised Audit Software(GAS) which could help the team query the system for better results.
* Head, Client Relations, Sama Audit Systems and Softwares Pvt. Ltd., Mumbai

38

CAB CALLING

October-December, 2008

GAS form part of Computer Assisted Audit Tools (CAATs). CAATs are computer programs and data the auditors use as a part of the audit procedures to process the data of audit significance contained in an entity's information system. The auditors can use CAATs to review those files to gain evidence of the existence and operation of those controls. CAATs may consist of package programs, purpose-written programs, utility programs or system management programs. CAATs may be used in performing various auditing procedures like tests of details, transactions and balances, analytical procedures, general controls, sampling, application controls and reperforming calculations undertaken by the entity's accounting system. The Audit Committee was happy with the presentation made by Arjun Singh and asked him to implement the GAS and present the changes effected as a result of the implementation in the next quarter meeting. Bank Premier has around 1500 branches in India and 50 branches in foreign countries. 700 domestic branches have been migrated from the legacy TBA banking application to the CBS till date.

1. Request IT Department for Data

Electronic KYC Audit The team selected an objective to test compliance to KYC norms on current account customer master data. To test this objective the team issued a 'data request' to IT department in the following format: Data required: Current account customer master information. Period: As of the date of audit. Fields of reference: Branch ID, Customer ID, Account ID, First Holder & Joint Holder/s Name, Address, PAN No., Mobile No., Residence No., Office No., Mode of Operation and Clear Balance. Format of data: Text form. IT department in turn ran an SQL query on the production database and generated a text file dump which was saved in a secure folder with special access to the audit team only. The audit team imported the text file using the text report import option within the GAS. Post import, the team used the 'duplicate key' test within the GAS to identify fictitious accounts opened with similar PAN No., or Mobile No., or Address, or Office No., or Residence No., but different customer ID. Fifty cases out of 65,000 were identified where account opening attributes (PAN No., Mobile No., etc.) were similar for different customer IDs. These cases have been taken up for further substantive checking with the account opening forms from the respective branch to ascertain the validity of the accounts opened.

Methodology
The GM (I & A) set up a small team within the department to take the initiative of implementing the GAS in the bank. The team comprised of two senior audit officials (who among them had a wide range of experience in various activities of the bank), an IT professional (who understood the software implemented) and an IT auditor (CISA). The entire audit manual was reviewed and audit objectives were mapped to possible audit tests that could be conducted using a GAS and otherwise. The method of using the GAS was debated and discussed by the group in a way that data integrity, confidentiality and availability of the production server was not compromised and the objectives were also met. While it was not possible to log onto the production server due to access restrictions maintained by the IT security administrator, the team was faced with a challenge to import data for further analysis. The team laid down three approaches of retrieving data from the bank's central database for further analysis within the GAS. Each approach catered to a specific audit objective and was met through a specific extraction and interrogation function within the GAS.

39

CAB CALLING

October-December, 2008 March 31, 2008 respectively. These reports were a part of the EOD suite of reports. These reports were generated as a part of the end of the day routine at branch X and by default saved in a compressed print report format. The team uncompressed the reports using WIN-ZIP. Then both the print report files were imported using the text report import option within the GAS. Post import, the team linked the report on inoperative accounts as on April 1, 2007 and March 31, 2008 using the COMPARE function within the GAS. The two data files were linked based on the customer ID available in both the files. Post compare, a new file was created with differences in the clear inoperative balances. The team finally queried the difference field for non-zero data. Accounts where there was a reduction in the inoperative account balances (non-zero data) were identified through the above approach. These accounts were taken up for further substantive testing with EOD exception reports to ensure that the movement on the inoperative account was authorized by the branch manager. Audit of Loans and Advances: MIS from Business Warehouse (BW) for Approval Verification In this case, the team decided to audit the MIS report on loans and advances generated from the Business Warehouse (BW) for approval verification. The MIS report is a comprehensive listing of account ID, type of loan, type of security, type of industry, sanction limit, drawing power, rate of interest, due date of loan, and approval officer. To complete this test, the team sought assistance from the merchant banking wing of the bank. The loan officer for branch X generated the MIS report for the period April 1, 2007 to March 31, 2008. This report was saved as a Microsoft Excel file and provided to the team on a CD. The team imported the Excel file using the MS-Excel option for import within the GAS. Post import, the team entered a conditional criteria/query on the file, identifying non-compliances with the sanction limitapproval officer. The CM, DGM, AGM-HO and AGM-ZO of the bank were all vested with specific approval sanction limits. The team tested the file for cases where loans were sanctioned by officers not in accordance with their financial sanction limit powers. A few cases were identified where the loans approved were not within the approval officer's sanctioning limit. These cases were noted and taken up for review with the respective officer and the branch manager.

Data Migration Audit

The team then decided to check the integrity of loan data migrated from the legacy TBA application to the CBS. To test this objective the team issued a data request to IT department in the following format: Data required: Cash Credit master information for large scale branch X Period: Data immediately post-migration Fields of reference: Customer ID, Sanction Limit, Drawing Power, and Rate of Interest Format of data: Text form

IT department in turn ran an SQL query on the production database and generated a text file dump which was saved in a secure folder with special access to the audit team only. The corresponding data from the TBA legacy system immediately pre-migration was available with the migration team. IT department sourced the text data from the migration team through a formal email request and placed the data in the secure folder. The audit team imported both the text files using the text report import option within the GAS. Post import, the team linked the pre-migration and postmigration data through the JOIN function in the GAS. The two data files were linked based on the customer ID available in both the files. Post join, three new fields were created by the team containing the differences in the Sanction Limit, Drawing Power and Rate of Interest in each field. The team finally queried each of the fields for non-zero data. Those accounts with a difference in the masters migrated (non-zero data) were identified through the above approach. These accounts were taken up for further substantive testing with the legacy system data and the loan appraisal forms to ascertain their accuracy.

2. Use Existing End of the Day (EOD) Reports or Existing Business Warehouse (BW) Solution Reports
Audit of Movement on In-operative Accounts In the second data retrieval approach, the team decided to audit the movement on inoperative accounts over a period of one financial year. To test this objective, the team identified the report on inoperative accounts as on April 1, 2007 and

40

CAB CALLING
3. Access to Disaster Recovery (DR) Site Databases or Mirror Databases
The team with the help of the IT wing set up connectivity between the GAS and the DR site server. This connectivity was the third and final mode of data retrieval, which gave the team direct access to raw data tables residing on the DR site server.

October-December, 2008

Isolating loan accounts where drawing power was greater than sanction limit
The team connected to the DR site server using the GAS and identified the data table containing the account masters. At the import stage, the team selected four fields Account ID, Account Name, Sanction Limit, and Drawing Power from the table containing 35 different fields. The team also entered an SQL query in the GAS, filtering the data for branch X. Post import, the team applied criteria to the file identifying instances where the drawing power was greater than the sanction limit. The result was exported from the GAS back to MS-Excel, printed and taken up for discussion with the branch manager and the Head, Loans & Advances.

Identifying term deposit accounts where the deposit was accepted for a period greater than 120 months
As per the bank-rules for acceptance of term deposits and guidelines of the regulator, the bank cannot solicit term deposits in excess of a period of 120 months. This test was undertaken to identify non-compliances with the rule. The team connected to the DR site server using the GAS and identified the data table containing the term deposit account masters. At the import stage, the team selected three fields Account ID, Account Name and Deposit Period in Months from the table containing 15 different fields. The team also entered an SQL query in the GAS, filtering the data for branch X. The import of data of 1 Lakh rows/lines was initiated and duly completed within one minute. This was faster in comparison to writing an SQL query which would take 3-4 hours to run in the past. Post import, the team queried the data to identify accounts where the 'Deposit Period in Months' was greater than 120. The result was exported from the GAS back to MS-Excel, printed and taken up for discussion with the branch manager and the 'Head -Term Deposits'.

Conclusion
While specific audit reports gave regular requirements for the operating team, the audit objectives were greatly met using the GAS which went beyond the set norms. Further, it allowed the audit team to move beyond the priority set by the IT department and were able to complete their audits within time. The IT department was also excited about the possibilities which such a tool could have for their security reviews also on a regular basis and initiated a review of the same. Further, the GM (I & D) also made it mandatory for the bank's concurrent auditors to use a GAS for their audit using similar methodologies as them.

41