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
c
k

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.
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.
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.

39
c
k
CAB CALLING October-December, 2008
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 post-
migration 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
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 limit-
approval 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.
c
k
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.
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'.
CAB CALLING 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.
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