Core Banking PDF

CORE BANKING SOLUTION
Evaluation of Security and Controls
M. Revathy Sriram
Managing Director
P.K. Ramanan
Director
R. Chandrasekhar
Director
Tejas Brainware Systems
Chennai
Delhi-110092
2010
.
.
CORE BANKING SOLUTION: Evaluation of Security and Controls
M. Revathy Sriram, P.K. Ramanan and R. Chandrasekhar
© 2008 by PHI Learning Private Limited, Delhi. All rights reserved. No part of this book may be reproduced in any form, by
mimeograph or any other means, without permission in writing from the publisher.
ISBN-978-81-203-3535-6
The export rights of this book are vested solely with the publisher.
Third Printing...................................................................................November, 2010
Published by Asoke K. Ghosh, PHI Learning Private Limited, Rimjhim House, 111, Patparganj Industrial Estate, Delhi-110092 and
Printed by Mudrak, 30-A, Patparganj, Delhi-110091.
.
Contents
Foreword.........xiii
Introduction.........xv
Preface.........xvii
Acknowledgements.........xxi
PART 1: CORE BANKING SOLUTION: ITS FUNCTIONS,

APPLICATIONS AND MANAGING SYSTEM
1. WHAT IS CORE BANKING SOLUTION (CBS)?.........3–9
1.1 Introduction.........3
1.1.1 Advantages of Total Branch Automation (TBA).........4
1.1.2 Disadvantages of Total Branch Automation (TBA).........5
1.2 What is Core Banking Solution?.........6
2. TECHNOLOGY BEHIND CORE BANKING SOLUTION (CBS).........10–16
2.1.1 Requirements.........11
2.1.2 Servers at the Data Center.........11
2.1.3 Network Connectivity.........14
2.1.4 Network Security.........14
2.1.5 Operations from the Branch.........15
2.1.6 Automated Teller Machine (ATM) Operations.........15
2.1.7 Internet Banking Operations.........16
3. IMPLEMENTATION OF CORE BANKING SOLUTION (CBS).........17–18
3.1.1 Auditor’s Responsibility and Scope .........17
4. FUNCTIONS OF THE INFORMATION TECHNOLOGY DEPARTMENT.........19–22
4.2 Help Desk—Roles and Responsibilities.........19
4.3 Security Administration.........20
4.4 System Administration.........20
4.5 Database Administration.........21
4.6 Network Administration.........21
4.7 Librarian.........21
4.7.1 Change Management Procedures.........21
5. SYSTEMS AND PROCEDURES FOR EFFECTIVE IMPLEMENTATION OF CBS.........23–
57
5.2 Data Center Security Process.........23
5.2.1 Introduction to Manual.........23
5.2.2 Asset Classification and Control.........24
5.2.3 Physical and Environmental Security.........25
5.2.4 Communications and Operations Management.........27
5.2.5 Systems Planning and Acceptance .........29
5.2.6 Network Management .........30
5.2.7 Media Handling and Security.........32
5.2.8 Access Control Policy.........33
5.3 Data Center Server Procedures Manual.........36
5.3.1 Hardware Platform.........37
5.3.2 Server Operating System.........37
5.3.3 Server Role.........37
5.3.4 Server Operations Procedure.........37
5.3.5 Patch Management Process.........38
5.3.6 Password Management.........38
5.3.7 Hardware Procurement Process.........38
5.3.8 Hardening Procedure.........38
5.3.9 Escalation Process.........38
5.4 Network and Security Procedures and Operations Manual.........39
5.4.1 Network and Security Administration.........39
5.5 Data Center Operations Manual.........41
5.5.1 Introduction.........42
5.5.2 Hardware Platform.........42
5.5.3 Network.........45
5.5.4 Storage Array Network.........49
5.5.5 Tape Library.........51
5.6 Data Center Backup Processes and Procedures.........51
5.6.1 Introduction.........51
5.6.2 Backup Policy.........52
5.6.3 Tape Management.........53
5.6.4 Backup Procedures.........55
5.6.5 Recovery.........57
5.7 Antivirus Procedures Manual.........57
5.7.1 Server Deployment.........57
5.7.2 Virus Scanning .........57
5.7.3 Antivirus Update Management.........57
6. APPLICATION PROGRAM MODULES AND THEIR FUNCTIONALITY.........58–74
6.2 Customer Introduction.........60
6.3 Accounts Management.........60
6.3.1 Savings Accounts.........60
6.3.2 Current Accounts.........61
6.3.3 Cash Credit.........62
6.3.4 Overdraft.........62
6.4 Cash Operations.........63
6.5 Clearing.........64
6.5.1 Outward Clearing .........64
6.5.2 Inward Clearing.........64
6.6 Master Maintenance.........65
6.7 Log Maintenance.........66
6.8 Bank Guarantee.........67
6.8.1 Performance Guarantees.........67
6.8.2 Deferred Payment Guarantees.........67
6.9 Bills.........68
6.9.1 Outward Bills (Cheques).........69
6.9.2 Inward Bills.........69
6.10 Letter of Credit.........69
6.11 Remittances.........70
6.12 Stock Maintenance of Negotiable Instruments and Other Numbered Inventory.........71
6.13 Deposits.........71
6.14 Advances.........73
7. ACTIVATING THE BRANCHES.........75–83
7.2 Cleaning the Branch Data.........76
7.2.1.........Database Requirements.........76
7.3 Branch to Ensure Correctness of Migration.........79
7.4 Additional Migration Checklist.........79
Annexure A: Branch Activity Acceptance Report.........80
Annexure B: Response Time Tests—Next Hop Router.........82
8. ATM FUNCTIONALITY—HOW IT WORKS .........84–91
8.2 ATM Card Issue Process.........84
8.2.1 Procedures for Issuing ATM Card.........84
8.2.2 ATM Operations.........86
8.2.3 Monitoring Process at the Central Office.........90
8.2.4 Other Procedures at the ATM.........91
9. INTERNET BANKING, REAL TIME GROSS SETTLEMENT AND CASH
MANAGEMENT SYSTEM.........92–99
9.2 Internet Banking—Process.........92
9.3 Objective of Utilizing RTGS.........94
9.4 Cash Management System.........99
10. SECURITY POLICY.........100–111
10.2 Security Policy: XXX Bank Limited.........100
10.2.1 Introduction.........101
10.2.2 Objective.........101
10.2.3 Scope.........101
10.2.4 Enforcement.........102
10.2.5 Exception.........102
10.3 Organization of Information Security Committee.........102
10.3.1 External Parties.........102
10.4 Asset Management.........102
10.4.1 Responsibility for Assets.........102
10.4.2 Information Classification.........103
10.5 Human Resources.........103
10.5.1 Prior to Employment.........103
10.5.2 During Employment.........103
10.5.3 Termination or Change of Employment.........104
10.6 Physical and Environmental Security.........104
10.6.1 Secure Areas.........104
10.6.2 Equipment Security.........104
10.7 Communications and Operations Management.........104
10.7.1 Operational Procedure and Responsibilities.........104
10.7.2 Third Party Service Delivery Management.........105
10.7.3 System Planning and Acceptance.........105
10.7.4 Protection against Malicious and Mobile Code.........105
10.7.5 Backup.........105
10.7.6 Network Security Management Policy.........105
10.7.7 Media Handling and Security Policy.........106
10.8 Access Control.........106
10.8.1 Access Control Policy.........106
10.8.2 User Access Management Policy.........106
10.8.3 User’s Responsibilities.........107
10.8.4 Network Access Control Policy.........107
10.8.5 Operating System Access Control.........107
10.8.6 Application and Information Access Control.........108
10.8.7 Mobile Computing .........108
10.8.8 Monitoring.........108
10.9 Information Systems Acquisition, Development and Maintenance.........108
10.9.1 Security Requirement of Information System.........108
10.9.2 Correct Processing in Applications.........108
10.9.3 Security of System Files and Database.........109
10.9.4 Security in Development and Support Process.........109
10.9.5 Technical Vulnerability Management.........109
10.10 Information Security Incident Management.........109
10.10.1 Reporting Information Security Events and Weaknesses.........109
10.10.2 Management of Information Security Incidents and Improvements.........110
10.11 Business Continuity Management.........110
10.11.1 Information Security Aspects of Business Continuity Management.........110
10.12 Compliance.........110
10.12.1 Compliance with Legal Requirements.........110
10.12.2 Compliance with Security Policies and Standards, and Technical Compliance.........111
10.12.3 Information Systems Audit Consideration.........111
11. BUSINESS CONTINUITY PLANNING (BCP) AND
RECOVERY PLANNING (DRP).........112–122
11.2 BCP and DR Planning Process of Banks.........112
11.2.1 Type of Risks.........114
11.3 Risk Management.........117
11.3.1.........Activating BCP/DRP.........117
Annexure.........121
PART 2 EVALUATION OF SECURITY AND CONTROL

12. SCOPE OF EVALUATION OF SECURITY AND
CONTROLS IN A CORE BANKING SOLUTION.........125–133
12.2 Functionality Perspective.........125
12.3 Controls Perspective.........127
12.3.1.........Application, Operating System and Database Control.........127
12.4 Internet Banking .........129
12.4.1 Compliance to RBI Standards .........129
12.4.2 Deliverables for CBS.........132
12.4.3 Deliverables: Internet Banking.........133
13. REVIEW OF SECURITY POLICY IMPLEMENTATION.........134–140
13.1 Implementation.........134
13.2 Security Policy Implementation.........134
14. REVIEW OF BUSINESS CONTINUITY PLANNING
AND DISASTER RECOVERY PLANNING.........141–146
14.2 Evaluation of Business Continuity Planning.........141
14.3 Evaluation of Business Continuity and Disaster Recovery Planning of CBS.........142
14.3.1 Objective.........142
14.4 Evaluation of Business Continuity Planning of ATM.........143
14.4.1 Objective.........143
14.4.2 Evaluation of Disaster Recovery of ATM.........144
14.5 Verification of Business Continuity Planning and Disaster Recovery Planning for Internet
Banking Process.........145
14.6 Evaluation of Business Continuity Planning and Disaster Recovery Planning of Integrated
Cash Management Systems.........146
15. SYSTEMS DEVELOPMENT AND CHANGE MANAGEMENT.........147–152
15.1 Evaluation of Controls in Systems Development and Change Management.........147
15.1.1 Evaluation of Controls in System Development Methodology Prevalent in the
Banks.........148
15.1.2 Process of Moving a Tested Program from a Test Environment to a Production
Environment.........150
16. NETWORK SECURITY.........153–158
16.2 Network Vulnerability Assessment.........153
16.2.1 Sample Vulnerability Assessment Report.........154
17. EVALUATION OF CONTROLS IN OPERATING SYSTEM.........159–170
17.2 Audit of Operating System.........160
17.3 Policies of Operating Systems.........160
17.3.1 Hardening Mechanism.........160
17.3.2 Domain Policy.........161
17.3.3 Member Server Baseline Policy.........162
17.3.4 The Domain Controller Baseline Policy.........164
17.4 Procedure for Evaluating the Security Settings of Operating System.........165
17.4.1 Audit Account Logon Events.........166
17.4.2 Audit Account Management.........166
17.4.3 Audit Log on Events.........167
17.4.4 Audit Object Access.........168
17.4.5 Audit Policy Change.........168
17.4.6 Audit Privilege Use.........169
17.4.7 Audit Process Tracking.........170
17.4.8 Audit System Events.........170
18. TESTING OF APPLICATION MODULES OF
CORE BANKING SOLUTION.........171–184
18.2 Customer ID Generation.........172
18.3 Accounts Management.........173
18.4 Cash Operations.........175
18.5 Clearing..................176
18.6 Master Maintenance.........176
18.7 Log Maintenance.........177
18.8 Bank Guarantee.........177
18.9 Bills.........178
18.10 Letter of Credit.........179
18.11 Remittances.........180
18.12 Stock Maintenance of Negotiable Instruments.........181
18.13 Deposits..................182
18.14 Advances.........183
19. EVALUATION OF CONTROLS IN ATM OPERATIONS.........185–191
19.2.1 Card and PIN Production.........185
19.2.2 Surrendered and Captured Cards.........186
19.2.3 PIN Security.........187
19.2.4 Cash Control and Balancing.........188
19.2.5 Transaction Records.........189
19.2.6 Lost and Stolen Cards.........189
19.2.7 Evaluation of Controls at the ATM Switch.........190
20. EVALUATION OF CONTROLS IN INTERNET BANKING.........192–199
21. EVALUATION OF CONTROLS AND AUDIT OF BRANCHES.........200–205
21.2 Generation of Reports in CBS.........200
21.3 Methods of Operation in a CBS Branch.........201
21.4 Evaluation of Security Controls in Real Time Gross Settlement (RTGS) System.........204
21.5 Audit of Cash Management System.........204
22. REVIEW OF SYSTEM LOGS.........206–215
22.2 Application Logs and Exceptional Reports.........206
22.2.1 Contents of Audit Log.........206
22.2.2 CBS Exception Report.........207
22.3 Database Logs.........207
22.3.1 Standard Application Audit .........208
22.3.2 Application Level Audit Trail .........208
22.3.3 Database Event Auditing.........208
22.3.4 Database Triggered Auditing.........208
22.3.5 External Auditing.........208
23. AUDIT TOOLS.........216–224
23.2 Usage of Audit Tools.........216
23.2.1 ODBC Compliant.........217
23.2.2 ACL Windows.........218
24. INSTANCES OF FRAUDS, ITS CAUSES AND CONTROLS.........225–233
Case Study 1 Non-Core Banking Case Study.........227
Case Study 2 Vulnerability in Account Mapping.........229
Case Study 3 Violation of Security Principals.........229
Case Study 4 Core Banking Solution.........230
Case Study 5 ATM Fraud.........230
Case Study 6 Parameterization.........231
Case Study 7 Application Program Error.........232
Case Study 8 Anywhere Banking.........232
25. RELEVANT ISACA STANDARDS, GUIDELINES AND PROCEDURES.........234–253
25.1.1 Standards.........234
25.1.2 Guidelines.........235
25.1.3 Procedures.........235
Appendix: Relevant RBI Circulars and Notifications.........255
Glossary of Terms.........257–271
Web References.........273–274
Index.........275–277
FOREWORD
I am quite happy to write a foreword to a book on Core Banking Solution (CBS). As an ex-banker,
who spent more than two decades in India’s biggest bank even before the introduction of basic
computerization, leave alone more advanced applications such as core banking solution made its
presence, I am able to appreciate the advantages today’s bank manager enjoys. Yesterday’s chores—
balancing of books, generating reports for the head office, customers’ statements and so on—can be
completed in no time. The book covers exhaustively and lucidly the areas such as audit and security
policies besides explaining CBS. These are big issues today waiting to be disseminated to all those
who are connected with a bank, as a customer manager or as any other stakeholder.
My second stint as a journalist with the Hindu has given me a ringside view of the developments
that have vastly enhanced consumer convenience. At the same time I, like any other consumer of a
bank, am also made aware of the fact that technology alone cannot fully exploit the potential that the
financial system is capable of.
Arguably, one of the most important developments in today’s financial sector, the adoption of CBS
by banks, marks the beginning of a phase in which ‘a customer (of a bank) no longer belongs to a
particular branch. He belongs to the bank’. In practice, as anyone having an account with a bank today
will vouch, that has meant a complete change in the ways traditional banker-customer relationships
were defined. Simply stated, a customer need not physically go to his bank branch for most types of
banking services. Nor is there a constraint of time to undertake those transactions. Now-a-days, 24-
hour banking is possible, though of course only the basic transactions—cash withdrawal, cash/cheque
deposits, requests for remittance, chequebook, statement of account—can be undertaken through an
ATM. The phone banking, Internet banking and other forms of delivering bank services are the
outcomes of CBS. Of course “Anywhere banking” made possible by CBS has shrunk distances,
between customers and bank branches and between branches themselves.
The nomenclature, CBS might be misleading as it seems to refer to something that influences banks
and their internal processes only. In any case, it makes no reference to the immense benefits it confers
on its customers as well as to the banks themselves. There are many tangible benefits to the banks
implementing the CBS. Besides making it possible for vastly superior customer services, it saves
costs and provides ready-made data, which can then be easily ‘mined’ for product innovation, cross
selling and market research. CBS is extremely relevant in the context of developing superior
management information systems. Risk assessments and profitability analyses can be undertaken
almost instantaneously and on an ongoing basis. CBS is the outcome of technological adulteration by
the banks. Given the obvious benefits it confers all round—CBS is but one of the several significant
outcomes—it is surprising that technology in general and CBS in particular should have taken so long
to arrive. Public memory might be short but computerization-mechanization as it was then called—
was both misunderstood and actively resisted by the bank unions and political parties. A generation
ago bank staff had the access to rudimentary devices such as calculators only. From those days to the
introduction of ledger posting machines, to Total Branch Automation (TBA) to Core Banking Solution
(CBS) has been a long way. It is important to remember that the move from one stage to another was
not as smooth as the present universal acceptance of technology would suggest. Dr. Revathy Sriram
and her team have done a commendable job in tracing the technological milestones leading unto the
introduction of CBS. Even those working in a bank were not fully aware of what each of them were to
portend.
The book would not have been possible but for the strong grasp of banking practices as well as
technological developments that its author and her team have. It also helps immensely that she is a
leading member of the accountancy profession.
C.R.L. Narasimhan
Business Editor
The Hindu
Introduction
Banks are facing new challenges with the implementation of Core Banking Solution. The BASEL
committee report of banking supervision builds on an evolving framework for managing risks in
financial services transactions. Operational and information risk management and IT controls are
essential in good corporate governance. Senior management oversight and good governance over the
financial system require that operational and information risk management and IT controls merge in a
seamless model. Governance, risk management and compliance are top business priorities. An
improved corporate governance requires many initiatives including
Protecting corporate reputation

Meeting increased demand and expectations of the key stakeholders like investors, regulators,
customers and others
Exercising good corporate stewardship and discharging fiduciary duties in a transparent
manner
While governance, risk management and compliance are the primary responsibility of the Board of
Directors, all units are expected to implement the principles set by the management. A good
governance is about setting strategy, managing risks and delivering value.
Within banking services, risk categories include the following:
Credit risks
Market risks
Operational risks
Legal risks
Reputational risks
Operational risks cover the areas associated with potential failures in the overall operation of
financial services and specifically the underlying technology and infrastructures. Given the
complexity and scope of operational risks, governance, risk management and compliance need to
include all areas of an organization not directly linked to the other risk areas.
Information technology implementation requires additional emphasis on business alignment, roles
and responsibilities and technical competence. The internal environment component as discussed in
BASEL II principles, highlights certain important aspects:
Information technology is often mistakenly regarded as a separate organization of the business

and as a separate control environment.
Information technology is complex. It is important to know how the technical components
integrate into the organization’s overall system of internal control. Information technology may
require reliance on third party when significant processes are outsourced. Finally, and most
importantly, ownership of information technology controls may not be clear.
Core Banking Solution: Evaluation of Security and Controls authored by

Dr. M. Revathy Sriram, Mr. P.K. Ramanan and Mr. R. Chandrasekhar explains the various concepts
in a lucid and non-technical language.
This kind of book is the ‘need of the hour’. With advanced technology and centralized banking,
constant evaluation of security and controls has become inevitable and necessary ingredients.
The book which reflects the authors’ wide practical experience will be of immense value to
management of banks and auditors of banks, whether they be from Inspection and Audit Department or
from the Department of Banking Supervision or statutory and concurrent auditors.
S. Balasubramanian
Chairman
City Union Bank Limited
Preface
Implementation of technology in the banking industry is taking place at a very rapid pace. In the
beginning, it was originally a simple Advanced Ledger Posting Machine (ALPM). Then the banks
started computerizing their operation in bits and pieces. After that, Total Branch Automation (TBA)
was introduced. But this technology required a total makeover. So Core Banking Solution—a solution
to deal with all business processes of the bank with easy upgradability—became a necessity.
While the technology associated with the banking industry has been improving at a fast pace, the
steps that need to be taken to ensure that security concerns are paid attention to have not always been
considered either due to pressure of implementation or lack of adequate knowledge to evaluate the
security concerns. With every new technology, there will be new security concerns and therefore
require appropriate controls in place. The installed systems would not be able to protect themselves
and their data. There could be intrusive and destructive attacks.
This book is an attempt to bring various security aspects of core banking solution before the
technology experts and user communities, especially the professionals and regulatory boards who are
entrusted to ensure that controls are adequate and security concerns have been attended to.
Computer security issue, in the earlier years and sometimes even now, was understood as creating
in a computer system a group of access controls that would emulate or implement the processes of
prior paper world. The additional features, at the most considered, were those of protecting such
software against unauthorized change. Physical access to computers was supposedly taken care of by
cordoning off the computer area. The world has changed now. The Internet is flowing and the reality
of the World Wide Web is in place. Networking has exploded and communication among computer
systems is the rule rather than an exception. Many commercial transactions are web-based. All
financial institutions including banks have implemented web-based applications. The audit of various
branches of banks is no longer relevant excepting to review the reports that are furnished at the
branches—generated at the central office. The conventional audit methods have now become
irrelevant and misleading.
With branches being connected with each other by communication lines and through the Internet, the
evaluation of adequacy of security needs a greater understanding of the technology behind the core
banking solution. All the three authors, being basically chartered accountants, have taken utmost care
to write the book in a manner, which could be understood by the non-technical professionals who are
mostly statutory auditors officiating the Inspection and Audit Departments of various banks, officers
of Department of Banking Supervision of Reserve Bank of India, etc.
It needs to be mentioned that whenever configurations of systems are discussed, it is one of the
ways it could be done. We do not claim that this is the only way. There could be other different
methods of implementing the Core Banking Solution (CBS). We have considered one set-up and
discussed the same right through the book. Technology behind ATM, Internet Banking, RTGS, etc. has
been discussed. The methodology of generation of PIN Nos. has been explained. There could be other
methods too. We have explained the most commonly adopted methods. The methodology suggested
for testing the adequacy of security and suggested controls in place, are based on our experience and
knowledge in this area.
The book is the outcome of long cherished desire of the Tejas team to provide easily readable and
yet a comprehensive background material to understand the concept of Core Banking Solution (CBS)
in the proper perspective and be in a position to perform an effective systems audit. The book is
divided into two parts and five sections, A, B, C, D and E.
Section A containing 11 chapters deals with what core banking solution is and how it becomes an
inevitable technology alternative to most banks. Apart from the concepts of various modules in CBS,
its implementation procedure and best practices to be in place for a successful and effective
implementation are covered (Chapters 1 to 6).
Chapter 7 covers important aspects to be borne in mind while migrating existing branches with
earlier technology process of most of the modules in banking operation.
Business process and technology implications of ATM, Internet banking, RTGS, and Cash
Management Systems are discussed in Chapters 8 and 9.
Chapter 10 deals with security policy, and its importance for an organization. An abbreviated
version of a draft policy is provided.
Chapter 11 deals with Business Continuity Planning. It discusses broadly the methodology to be
adopted for evolving a Business Continuity Planning and Disaster Recovery Planning. The different
likely scenarios in a core banking solution implemented are considered.
Section B deals with audit approach in a bank which has implemented CBS. This section consists
of ten chapters and starts with what could be the scope of evaluation of security and controls in CBS
(Chapter 12). The scope is envisaged to be comprehensive.
Each of the chapters highlights the security concerns for Application software, Networks,
Operating Systems, etc. and the controls that need to be in place and their adequacy (Chapters 13 to
21).
The readers could pick up those chapters which may be appropriate.
Section C contains chapters on audit logs and usage of audit tools.
Chapter 22 on audit logs describes different types of logs, their importance and the auditor’s role in
reviewing the same. Chapter 23 on audit tools explains the need to use automated tools to perform
more effective and efficient audit in a technology environment. In particular, usage of Audit Command
Language (ACL) audit tool for a particular application, e.g. loan disbursement, is considered for
detailed explanation.
Section D dicsusses some instances of live case studies when lack of controls leads to frauds being
committed. The list of cases naturally is only illustrative but not necessarily exhaustive.
In section E a brief description of some of the standards, guidelines and procedures of ISACA
(Information Systems Audit and Control Association), USA has been included as they have relevance
to audit of Core Banking Solution (CBS). ISACA standards are internationally accepted and it would
be relevant to benchmark systems audit procedures against these.
Special permission has been obtained from ISACA who were kind enough to grant the same.
ISACA also provided similar support by permitting reproduction/summary reference to their
professional standards.
The Reserve Bank of India (RBI) has been periodically issuing circulars and notifications in the
area of performing systems audit in banks. Extracts of relevant Circulars of the Reserve Bank of India
have been provided in Appendix.
The book includes a glossary of terms with some pictorial representations for a better
understanding of the concepts discussed. A list of useful websites references has been given to enable
the readers to constantly update their knowledge and also look for useful audit programs.
The book would be useful to the bank officers who want to understand the CBS. It will also help
the inspection and audit department of banks to have a guideline for performing a systems audit. The
chartered accountants who are the auditors of the bank along with the external systems auditors who
are offered special assignments would find the book extremely useful. This book can also be used to
advantage by auditors who are required to perform concurrent systems audit of banks and by the
officers of the department of banking supervision of RBI and others who are responsible for
regulating security and controls in banks where CBS technology has been implemented.
Security is not a product but a process. Security is not a one time effort. It requires constant and
continuous attention.
It would be appropriate to quote Dr. Paul Doreas, Driector, Digital Business Security BP Ltd. in
this context. “Information security provides management processes, technology and assurance to
allow business management to ensure business transactions can be trusted, ensure IT services are
usable and can appropriately resist and recover from failures due to error, deliberate attacks or
disaster and ensure critical confidential information is withheld from those who should not have
access to it.”
Practicing strong information security is a non-negotiable requirement for all business
organizations including banking industry. However building security into an existing corporate culture
is a complex undertaking.
We welcome suggestions for improvement of the contents of the book. The authors could be
contacted at info@tejasbrainware.com
M. Revathy Sriram
P.K. Ramanan
R. Chandrasekhar
.
Acknowledgements
We offer our special thanks to Mr. S. Balasubramanian, Chairman, City Union Bank, for having so
kindly agreed to pen the “Introduction” to the book.
We are also indebted to Mr. C.R.L. Narasimhan, Business Editor,
The Hindu, who readily agreed to provide “The Foreword”.
We were not able to request Mr. N. Vittal, former Central Vigilance Commissioner, earlier, due to
his non-availability. Though we established contact rather late and had limited space to have him
express his views on our book, he was gracious enough to offer his comments, committed as he is to
security in a computerized environment.
We would be failing in our duty if we do not acknowledge our deep felt gratitude to the Senior
Management of City Union Bank, Chennai, more particularly the Senior General Manager Mr. S.
Sridharan, General Manager Mr. S. Sekar, the present team members of the Computer Systems
Department, Mr. K. Swaminathan, Mr. J. Ramaswami, Mr. G. Sankaran, Mr. V. Sivakumar, Mr. S.
Senthil, Mr. K. Venkatraghavan, Ms. B. Lakshmi, Mr. N. Bagavathy and also Mr. N.V. Nathan, for
their invaluable contributions in different ways. We had professional association with them during
performance of systems audit of their core banking solution.
We also express our gratitude to:
Mr. S. Chandran, Former General Manager of Bharat Overseas Bank (now Indian Overseas
Bank).
Mr. A. Vijayakumar, Assistant General Manager of Karur Vysya Bank, formerly the Assistant
General Manager of the IT Department of Bharat Overseas Bank and his team members
including Mr. Anand Sharma and Mr. Ramanathan.
Mrs. Jamuna Swamy, Head, Information Security, Hexaware Technologies.
Mr. Sai Sridhar, formerly General Manager of Bank of Madura.
Mr. Krishnakumar, General Manager, Information Security, of the State Bank of India.
Mr. S. Venkataraman, Mr. V. Rajendran, Mr. J. Venkatesan,
Mr. V. Desikan, Mr. R. Selvaraju, Mr. S. Ravi Auvudiappan and other members in the CPPD
and associated departments dealing with inhouse developed Core Banking Solution in Indian
Overseas Bank.
Senior members of the IT and Inspection Audit Department as also Disaster Recovery Team
of Corporation Bank, Mangalore.
The Information Systems Audit Control Association (ISACA) of USA which has so kindly
permitted us to refer to their Standards and Guidelines.
Mr. S. Ranganathan, Mr. Ramjee and Mr. Viswanathan who patiently provided excellent
secretarial support to complete the Herculean task.
Our thanks are due to our other team members of Tejas, Mr. S. Swaminathan,
Mr. B. Chandrasekhar, Mr. A. A. Raj, Mrs. B. Sathya Bhama who enthusiastically supported the
project by making useful contributions. Our special thanks to
Mr. S. Ganesh Ram, our former colleague, for proofreading the manuscript and also having patiently
drawn all the diagrams in the book which was fine- tuned several times before it was finally accepted
by all of us.
We have accessed public information available on websites and taken the essence of useful and
relevant knowledge. We express our gratitude to the concerned websites.
We would like to thank the Editorial and Production staff of PHI Learning, who made a neat
execution of the book.
There are many others also who have spared their time, shared their knowledge and experience to
make the completion of the book possible. We wish to thank them also.
M. Revathy Sriram
P.K. Ramanan
R. Chandrasekhar
PART 1 CORE BANKING SOLUTION: ITS FUNCTIONS, APPLICATIONS
AND MANAGEMENT SYSTEM
This part deals with the relevance of the Core Banking Solution in banking system. It explains what actually the core banking
solution is and how it has nowadays become indispensable to the banking system. This part discusses concepts of various
modules in Core Banking Solution (CBS), its implementation and security measures along with Business Continuity Planning
(BCP) and Disaster Recovery Planning (DRP).
SECTION A.........................................................CHAPTER 1
What is Core Banking Solution (CBS)?

1.1 INTRODUCTION
The Banking Industry has gone through various phases of ‘mechanization’. The Industry started with
Advance Ledger Posting Machine (ALPMs), and thereafter graduated to scenario of Total Branch
Automation (TBA). In most of the Banks where core banking solution has been implemented, the then
existing Information Technology (IT) environment was that of total Branch automation. In this
scenario, there was a Computer Planning and Policy
Department (CPPD) at the Head Office. In some cases, the team in the computer planning and policy
department (CPPD) developed inhouse banking software. In other cases the software was purchased
from a third party vendor. The set of programs under the total branch automation system consisted of a
group of programs capable of dealing with branch operations like savings bank, current account, CC,
OD, DD and other routine banking operations normally undertaken at the different branches of banks.
The technology implementation at the branch is represented in Figure 1.1.
At each branch, there was a server with necessary number of nodes being attached to the server. A
copy of the program developed and tested at the Computer Planning and Policy Department (CPPD)
was loaded in the server of the branch. This operation was done mostly by bringing a copy of the
program in a CD and loading the same in the server. The database of the branch was also located in
the server. The banking operations at the branch were performed by the members of staff entering
transactions in their respective nodes. The staff of the branch was given the rights to access those
modules of the program as was necessary. For example, the clerical staff dealing with fixed deposits
creation, closure, pre-closure etc. was in a position to access that module of the program. He was in a
position to view the relevant screen and input the data. The data were being updated in the database.
The creation of users, i.e. deciding on who would be the authorised users of the different applications
was done at the branch level. There were designated systems administrators at the branch who were
responsible for systems administration as also database administration. In some cases, he was also in
charge of network administration. The concerned person was reporting to the branch manager. The
systems administrator under appropriate authority of the branch manager would do such acts as were
necessary to keep the operations of the branch going. At the end of the day, all the activities at the
nodes would be closed and the systems administrator would perform the end of day operations
(EOD). This activity would enable the closing of the accounts for the branch for that day which would
include preparing the cash book, a list of transactions, journals, trial balance and the ledger.
Figure 1.1 Implementation of technology in branches.
1.1.1 Advantages of Total Branch Automation (TBA)

Compared to the very tedious manual operations of maintaining day book, ledgers and tallying
thereof, introduction of the total branch automation reduced the burden of maintaining manual ledgers
and day books at the end of the day. All of the day books that were necessary along with the totals
would be made available soon after the closing of transactions.
This information would be copied on to a CD or where direct linking was available sent through
communication line to the head office for consolidation purposes.
Further processing at the head office was simplified as again all the data were available in
computer media and the appropriate programs were used to do further processing.
1.1.2 Disadvantages of Total Branch Automation (TBA)

The above-mentioned benefits would have all been achieved if the programs were correct, data entry
complete, and the integrity was maintained. Many problems were faced due to the following reasons:
It was possible for different branches of the same bank to have different versions of the
programs. This situation arose due to the fact that while originally same copies of a single
program was loaded in the different branches, over a period of time, when some changes
required to be made to the computer program either due to change in functionality or a bug in
the programs brought to the notice of the Computer Planning and Policy Department (CPPD)
by some branches, different versions of the original program were available in different
branches. This, in turn, led to the associated problems.
Any time any changes were made in the Master Data like rate of interest for savings bank
account, for fixed deposits, loans etc., these changes had to be introduced by means of a
floppy being sent from the head office to the branches. Generally, the banks ensured that
correct copy of the floppy was taken personally by personnel of CPPD and loaded on to the
servers at the respective branches. However, due to paucity of personnel and due to certain
amount of complacency developed over a period of time, the floppies were sent to the
branches and the branch manager was requested to take the assistance of the systems
administrator to change the Master Data. This was in some cases leading to either the changed
interest rates not being implemented as expected, or wrong floppies being loaded either
inadvertantly or intentionally. The necessary procedures to ensure that the correct Master Data
was uploaded were not strictly adhered to, ostensibly due to the branch managers being busy
with operations and performance rather than paying attention to technology requirements.
As more and more branches were coming into the scheme of total branch automation, some
banks decided for operational reasons to have a small group of people from the CPPD to be
available at the regional offices of the bank. Decisions were also taken that those team
members would have a copy of the source code so that if branches experienced some
difficulties in the execution of the program which was leading to problems and delays in
operations, the necessary corrective actions could be taken by this group and could correct the
source code and load the modified executable of the program onto the server at the branches.
These decisions while it seemed to ease operational problems gave rise to the following
security concerns:
Copies of the Source Code were available at the regional offices which is in direct contrast to
best practices. The source code should be available only at the library in the CPPD at the head
office.
Different versions of the program running at different places also created problems at
consolidation.
As end of day operations have to be done and it would not be completed unless books tallied,
possibilities of creating suspense account and tallying trial balances became a routine rather
than an exception.
As the practice of maintaining manual cash scrolls was disconti-nued and as computer
operations were localized at the branches, the possibility of fraudulent employees to exploit
the weakness was heightened.
It was also becoming extremely difficult to upgrade the program functionality, for example
introduction of ATM, introduction of Anywhere Banking etc. The programs were already
precarious with great deal of patch work. In addition, it was just not possible any way to
provide additional products with the existing program.
1.2 WHAT IS CORE BANKING SOLUTION?
The banks were facing stiff competition. Markets were expanding. Costs had to be brought down. The
available technology was far more advanced. It was at this juncture, the concept of core banking
solution appeared on the horizon. In an increasingly competitive environment, banks took a reality
check on their technology environment to ensure that their Information Technology (IT) strategy is
aligned to their business objectives. Introduction of core banking was inevitable (see Figure 1.2).
Figure 1.2 Core banking system
The continually changing business dynamics in the new age economy required banks to respond
with a high degree of agility. Today technology has emerged as both the key enabler and driver of
change. This process was accelerated by the enhanced expectation of the regulatory body Reserve
Bank of India (RBI).
Products were not only functionally rich and technically robust and scalable, but their new
generation architecture based on the web paradigm, true 24X7 solutions was providing the facility to
gain and retain competitive leadership in the consumer banking space.
Core Baning Solution (CBS) empowers banks to transform their business, leveraging agile new
generation technologies.
This modular solution addresses the core banking, consumer and corporate e-banking, mobile
banking and web based cash management requirements. Products offer powerful and differentiating
features making them most comprehensive, flexible and scalable solutions.
Core banking solutions are leaving an indelible mark as banks embark on a total overhaul of their
legacy platforms.
Banks needed to take a holistic view while considering a replacement by core banking platform. A
packaged new generation core banking solution has its obvious benefits but the considerable risks
associated with the replacement need to be mitigated and managed carefully and successfully.
Core banking solution is a set of robust software components designed to meet the challenges of
today’s banking market. The advanced technology infrastructure supporting the core banking solution
and high standard of business functionality provides financial institutions a competitive advantage.
Core banking solution is a set of integrated core banking components, as mentioned earlier which
could be tailored to fit the Institution’s individual business requirements. Core banking solutions
bring significant benefits to the organization as follows:
It enables the organizations, customer relationship management by providing a robust

operational customer database and customer administration.
A customer no longer belongs to a branch. He belongs to the bank.
By means of a simplified account administration, it provides improved customer service and
cost saving. It provides support for portfolio growth with a fast track product field component.
It is capable of creating flexible financial products providing the capability of building
products in line with prevailing market conditions.
Initially, core banking solution could be implemented with basic modules like savings bank
account, current account, fixed deposits, loans, cash credit etc. Immediately thereafter,
additional delivery channels like ATM, Internet banking, etc. could be added.
It facilitates an increased productivity and reduction of errors.
It is capable of supporting multi-currency operations.
With online transactions being enabled and the servers being active all the 24 hours and seven
days a week, it is possible to perform banking transactions on the net any time, any day,
anywhere.
It is capable of generating accounting and management information from operational data for
compliance, risk management and profitability analysis.
It provides an opportunity to rationalize processing infrastructure. It results in cost reduction
and increased operational resilience.
It provides data structures to extend the core banking solution functionality to support bank’s
specific needs and reduce maintenance and upgrade costs.
However, sometimes due to rushed implementation without proper preparation and planning,
introduction of core banking solution becomes a nightmare and it is not uncommon to see notices
being put in front of bank branches reading as follows:
‘We have introduced core banking solution and hence, there would be hiccups and delays and the
customers are requested to bear with the inconvenience’.
In the initial stages of implementation it is also not uncommon for the customers to wait for long
periods as harassed bank staffs were trying to establish connectivity to put through a simple
transaction. Both the customers and the bank staff were made to believe that inconvenience and delay
and the mystery of the unknown had to be accepted as inevitable hazards of implementation of core
banking solution!
The initial frustrations also lead to sarcastic but humorous comments appearing in magazines.
One of them expressed the core banking solution implementation by means of a chemical equation
as follows:
T + 0 0 = C 0 0 + CC
The equation describes the scenario when core banking solution (CBS) is
implemented in a bank without proper planning and adequate training of staff.
The equation when translated into English meant that when new techno-logy (T) is implemented in
an old organization (OO) it transforms it into a costly old organization (COO) generating lots of
confusion and chaos (CC)!
These wry comments were justified as a great deal of money was spent on hardware, software and
networking. However, in view of the shortage of time for the implementation due to tight time
schedule, proper planning was not done. The bandwidth was initially, totally insufficient leading to
slow access speed or even non-accessibility of the server and the untrained staff being in the dark as
to how to face the new system.
However, after the banks got over the teething problems, they were able to derive all the benefits of
implementing CBS. Only the control objectives and audit procedures needed to be changed.
Technology behind
Core Banking Solution (CBS)
2.1 INTRODUCTION
In a core banking solution all the servers are centrally located, normally called as the central data
center. All the branches are connected to the data center through a leased line or any other network
connectivity with security and redundancy built in.
Figure 2.1 depicts the technology and connectivity details in the implementation of CBS.
Figure 2.1 Data center—network diagram.
Most of the servers like the application servers and database servers are placed behind the firewall
and protected from unauthorized access. In order to manage the load and also to build redundancy,
multiple servers performing the same function are clustered. All the servers are not in the same Local
Area Network (LAN). They are segregated using the concept of Virtual Local Area Network
(VLAN), which has its own built in security.
The following paragraphs describe the various servers, their functions and as to how they are
secured.
2.1.1 Requirements
Core banking environment consists of following:
Central database servers that store the data of the bank

Central application servers that run the core banking solution (CBS) application centrally
accessed by branches
Necessary infrastructure to be provided for internet banking and Automated Teller Machines
(ATMs).
Necessary infrastructure to provide security for data stored and transferred across the
network.
2.1.2 Servers at the Data Center

The following servers should generally be available at the Data center:
Application server
The application server hosts the core banking application. It is a powerful and robust system that
performs all the core banking operations. In the branches only a client version of the application that
merely collects data from the user and performs basic validations is installed. The application server
receives data from all the client machines installed at the branches and performs necessary operations
and updates the central database. Any patches or updation to the core banking application is done at
the application server after testing the same in a test environment.
Location: Application server is placed in the trusted inside zone in a separate Virtual Local Area
Network (VLAN).
Database server
The Database server of the bank contains the entire data of the bank. Database server is accessed by
the application server for processing. Apart from that, the Automated Teller Machine (ATM) server
and Internet Banking Application Server (IBAS) access the database server through their own channel
of middleware and firewall. All customer transactions performed from branches or internet or ATM
are updated at this central database.
Location: Database server is placed in the trusted inside zone in a separate VLAN.
Antivirus server
In a core banking setup, there is a centralized antivirus server. The advantage of setting up an
antivirus server is twofold:
The antivirus program updated with the latest virus signatures is pushed to all the systems in
the bank’s network from a central location.
It facilitates better administration as the antivirus software is updated in the central location
and becomes available to all the systems in the bank’s network unlike in the previous setup,
TBA, where antivirus updates have to be installed individually in each system.
Location: Antivirus server is placed in the trusted inside zone in a separate VLAN.
Automated Teller Machine (ATM) server
Automated Teller Machine (ATM) server contains the details of all ATM account holders. Also
ATM server temporarily holds data that is converted by the middleware as requested by the ATM
switch.
When the central database is not accessible a file containing account balances, referred to as
Positive Balance File (PBF) of the ATM customers is sent to the ATM switch. During this period, the
ATM transactions are based on the balance available in its server. Once the central database server
is restored, these transactions are updated in the central database.
Location: ATM server is placed in the trusted inside zone in a separate VLAN.
Web server
The web server hosts the bank’s website. There is a web host attached to the web server. The web
host has an operating system and runs the services from the web server. It accepts web page requests
from the customers and processes the same. The web host generates a dynamic web page for each
user while processing his services. It facilitates, when properly configured, secured (encrypted)
connection whenever confidential data are to be transferred.
Location: Web server is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, Internet Banking Application Server (IBAS) and Internet Banking Database
Server (IBDS).
Internet Banking Application Server (IBAS)
The internet banking application is hosted in the Internet Banking Application Server (IBAS). All
internet banking service requests are received by the IBAS from the web server. Internet Banking
Application Server works with the support of IBDS, middleware and central database server to
process the internet banking services requests. Internet Banking Application Server is placed inside
the de-militarized zone.
Location: IBAS is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, web server and IBDS.
Internet Banking Database Server (IBDS)
Internet Banking Database Server (IBDS) stores the user name and password of all the internet
banking customers. It also contains the home branch details of each internet banking customer.
Whenever an internet banking customer attempts to login to the bank’s website, the IBAS
authenticates the customer with the login details stored in IBDS. Also IBDS temporarily stores the
data requested by the customer while performing an internet banking transaction. IBDS retrieves this
data of the customer based on a request from IBAS. IBDS accesses the central database server
through a middleware and a firewall to retrieve the required customer details.
Location: IBDS is placed inside the de-militarized zone in a separate VLAN that contains the
proxy server, mail server, web server and IBAS.
Middleware
Middleware is a software that formats the data to make it compatible with different applications.
Thus, a middleware is required when more than one application with different data requirements
processes a common database.
Example: web based applications.
Location: Middleware is placed in the trusted inside zone in a separate VLAN.
Proxy server
A proxy server acts in conjunction with the firewall and provides network security by filtering
malicious data from entering the network. Also the proxy server secures the internal Internet Protocol
(IP) addresses of the Bank’s servers by performing a Network Address Translation (NAT) whenever
data are transferred from the bank’s network to a public network like internet.
Location: Proxy server is placed inside the de-militarized zone in a separate VLAN that contains
the mail server, web server, Internet Banking Application Server (IBAS) and Internet Banking
Database Server (IBDS).
Domain controller
Domain controller is primarily used for authentication. Access to a set of servers is controlled by the
domain controller.
Location: Domain name server is placed in the trusted inside zone in a separate VLAN.
Mail server
Mail server sends and receives mails across the network. Email security services are deployed in the
mail server to protect the users against spam mails and malicious attachments.
Location: Mail server is placed inside the de-militarized zone in a separate VLAN that contains
the proxy server, web server, IBAS and IBDS.
2.1.3 Network Connectivity

In a core banking set-up all the systems of the bank are connected in a network. The branches will not
be able to access the core banking application if the network connectivity is lost. Thus, there must be
a secondary line connecting to the data centre from the branches that can take over in case the primary
line is down. The bank should also ensure adequate bandwidth capacity to transfer all transactions
and data across the network.
Routers, switches and hubs should be strategically placed to transfer data seamlessly. In a CBS set-
up there are routers in all the branches. All the computers in the branch are connected to a switch
which in turn is connected to the branch router. The branch routers are in turn connected to a central
router which is at the data center.
Functions of routers
Routers facilitate data transmission over different networks. Routers make intelligent decisions to
route data across the network by choosing the best path.
Functions of switch
Switches have many ports that connect to different systems. Switches facilitate data transmission
within the network. Also virtual networks can be created only when devices are connected through a
switch.
2.1.4 Network Security

Considering the criticality of banking transactions and data, it is important that the network is
adequately secured with devices like firewalls, intrusion detection/prevention systems.
While going through the internet, the user first hits the firewall and only if the firewall allows, the
user proceeds to the web server.
Even the branches and the ATM switch access the data centre only through a firewall. Thus, all the
servers of the bank are protected by a firewall. However, the firewall is only as good as the rules
configured in it. The firewall decides whether to allow or deny access to a particular resource based
on the rules configured. These rules should be in line with the security policy of the bank. The
intrusion detection/prevention system acts parallely with the firewall. These devices look for
suspicious data patterns to identify a malicious activity.
2.1.5 Operations from the Branch

In a core banking setup, all the systems in the branches are connected to the data center. Usually, in a
CBS set-up, there will not be any servers in the branch (there are a few implementations of CBS with
branch level servers which are used for performance enhancements, storing of balances etc.). A
lower end version of the core banking application is installed in the client machines that merely
collects transaction data from the users and performs basic validation functions. These data are then
transferred to the application server at the data center where the actual transaction processing and
posting in the accounts happen. Thus even the data is not stored in the branches.
The branches cannot run any reports as they can be run only from the application server/report
server. After the banking operations are over, all the branches log out. After this process, the branch
is closed for that date and no further transactions will be accepted for that date. Day-end operations
are run from a centralized location form the CPPD. During day-end operations, the pre-programmed
activities in the application in the nature of interest posting and transaction posting take place.
After the day-end is run, day-begin operations are carried out. During this process, some pre-
programmed activities like application date flip, generation of reports and posting of latest account
balances take place. The branches will be able to access core banking application only after the day-
begin operations are run by CPPD.
In a core banking set-up, the customer, thus is a customer of the bank and is not tied to any
particular branch. The customer can access his account from any branch and perform his banking
transactions.
2.1.6 Automated Teller Machine (ATM) Operations

Automated Teller Machine (ATM) kiosks are connected to the bank’s ATM switch which in turn is
connected to other banks’ ATM switches and its own ATM server at the data center. ATM switch and
the kiosk have a Hardware Security Module (HSM) that stores its encryption key. All data transferred
between the ATM kiosk and the switch is encrypted.
The ATM switch performs the authentication function when a customer inserts his ATM card and
enters the PIN at the ATM kiosk. To perform any banking transactions, the ATM switch requests the
central database server which is accessed through a firewall, middleware and an ATM server.
Logs are generated for all ATM transactions at three places namely ATM kiosk, ATM switch and
the ATM server.
2.1.7 Internet Banking Operations

Internet banking operations are performed by the customers from a web browser. The customers
access the bank’s web server for this purpose via a firewall. The customers have to then login to the
web server.
Internet banking transactions are encrypted, providing security of data transmitted across the
network.
Implementation of
Core Banking Solution (CBS)
3.1 INTRODUCTION
Banks need to necessarily have had to implement core banking solution not only to meet growing
business needs but also to bring down costs. More importantly, they have to catch up with the current
technology which is fast growing and extremely useful for banking industry.
It is in this background of inevitable situation, that banks are implementing Core Banking Solution
(CBS).
As regards the implementation, responsibility of implementing could be given to:
An outside system integrator

Vendor of core banking solution software
Channel partner recommended by the vendor of core banking
solution; or
In-house team of individuals consisting of experienced bank officials and technology experts.
As the investment is very high and as the banking solution has to be viewed from a long term
perspective, the decision is that of the senior management of the Bank.
Auditor is not involved in this decision generally as he appears on the scene much later after the
decision has been taken and the solution has been implemented.
It is important to mention that auditors’ role vary depending upon the decision taken.
3.1.1 Auditor’s Responsibility and Scope

When implementation is by an outsider, whether he be the vendor or channel partner, the service level
agreement needs to be critically reviewed to understand the responsibility of the different parties.
The service level agreement may be to the effect that data center management which includes
systems administration, data base administration and network administration could be that of a third
party.
In the above scenario audit concerns are high. Generally, systems administration would not be
outsourced as it is a sensitive role and categorized as a ‘Super User’ role. However, when it is
outsourced, the non-disclosure agreements need to be reviewed.
There need to be logs to monitor activities and these logs need to be reviewed. Auditor would need
to verify the existence of such a log and the monitoring procedures.
If there is any slightest concern, auditor needs to review the same and report to management. Areas
of ‘access rights’ to individuals not belonging to bank are a major security concern and auditor needs
to review the same.
There needs to be a ‘systems auditability’ clause in all of the Service Level Agreements (SLA) so
as to enable the auditor of the bank to be able to perform an audit of the organization providing
software or any other third party or organization providing services to the bank, e.g. outsourced
network maintenance.
If, however, there is an in-house computer department, consisting of a team of executives with
banking knowledge and some with knowledge of technology, the bank may decide to have the in-
house team to take on the responsibility.
From the audit point of view, the method of implementation of Core Banking Solution (CBS) is of
importance.
The other points that management needs to pay attention to would be the acquisition of appropriate
hardware, software and communication links.
Necessary and appropriate hardware need to be acquired so as to ensure that performance and
accountability are assured.
As regards the software, if the solution is from outsider, bank needs to verify the credentials of the
vendor and more importantly, the after-sale support.
Auditor needs to verify whether any ‘escrow’ agreement has been entered into. The escrow
agreement would ensure that source code of the CBS would be available with a mutually agreed third
party in case the vendor of CBS goes out of business.
Customization is an important aspect. The software solution as made available would require some
changes to meet the specific needs of the bank.
There needs to be a systematic approach as regards customization. Each of the individual
requirements need to be logged and action taken need to be verified.
Functions of the Information

Technology Department
4.1 INTRODUCTION
In a core banking solution (CBS) environment, Information Technology (IT) functions are centralized
at a location generally called Centralized Data Center (CDC).
Figure 4.1 shows a normal organization structure in a bank which has implemented CBS. There
could be variations.
Figure 4.1 Information system department organization.
Some of the significant functions are discussed below

4.2 HELP DESK—ROLES AND RESPONSIBILITIES
In today’s environment it has become essential to have a help desk function. It is a unit which
responds to problems encountered by the users. Help desk should generally be manned by competent
people. There would be a procedure to record the problems reported and solved to the extent
possible. However, there would be a procedure to escalate the problems to higher ups within a
stipulated time. They need to determine the source of the problem with appropriate personnel in the
production environment and initiate corrective action.
A record of all queries is maintained. Application level queries are handled by the help desk,
while technical queries like system performance slowing down are forwarded to the administrator.
4.3 SECURITY ADMINISTRATION

Management needs to understand and evaluate security risks and enforce the written policy which
clearly lays down the policies and procedures to be followed.
Security administration would be an independent function discharged by a full time employee
reporting to senior management. It becomes his responsibility to control and prevent unauthorized
access to data, programs and equipment. The security administration functions include:
Maintaining access rule to data and other IT resources

Managing security and confidentiality over issuance and maintenance of user IDs and
passwords
Monitoring security violations
Constantly testing the security architecture to evaluate security strength and detect possible
threats
4.4 SYSTEM ADMINISTRATION

The systems administrator’s job is supersensitive. He is a superuser as he has the powers to create or
delete users and their access to the system. This job would normally be given to an individual who is
technically competent and also has a proven record of high integrity.
The job responsibility includes the following:
User creation
Branch creation
Products creation
Ø FD interest
Ø Charges etc.
Process of day-end and day-begin
Responsibility for deploying new version of the program
4.5 DATABASE ADMINISTRATION

The role of database administrator is to manage the core banking solution (CBS) database. The
database administrator acts as the custodian of the bank’s data and is responsible for giving access to
data in a secure manner as per valid business requirements.
The database administrator is in full control of all the data. Thus, the close monitoring of the
functions of database administrator must be in place through appropriate segregation of duties.
Functions of database administrator include:
Defining the database structure

Ensuring data availability
Ensuring data integrity
Ensuring security over access to data
Ensuring recoverability of data by taking regular backups
4.6 NETWORK ADMINISTRATION

Network administrator’s role requires establishing connectivity for new branches, providing for
failover line and constantly monitoring network performance. For this purpose, the network
administrator is required to place routers, switches and hubs at the appropriate places and configure
them securely. Also the security devices like firewalls and intrusion detection/prevention systems
need to be strategically placed to protect the network.
4.7 LIBRARIAN
Librarian is the person who is the custodian of the following:
Production version of the software

Licenses
User manuals
Other related documents
Librarian is required to maintain a register for all the above-mentioned items. Change management
is one of the most critical functions performed by the librarian that help in maintaining software
version control.
4.7.1 Change Management Procedures
In the normal course, it becomes essential to upgrade hardware, utility software, and also make
changes to application software. The changes are warranted either due to technological developments
or bugs in the program.
Change management procedure for application software
There needs to be a version control for the software. At the stage of implementation, a specific
version number would be provided. There needs to be a document containing details of the version
number, date of implementation etc. For all subsequent changes, the procedure would be that:
There would be a request from an authorized person like the manager of the user department.
The request would be approved by the person in charges of the systems department.
Changes to the programs would be made in the test environment.
The correct program would be handed over to the librarian who would then give a different
version number for the changed program.
The documentation would contain details of changes made and the date when made.
Best practices for an organization structure in a computer services department in any

organization more so, in a banking environment
Production environment should be totally different from the development environment. In the
development environment, all aspects of the program will be tested by the users as also by the
programmers and after being satisfied about the functionality and the controls, the software would be
handed over to a librarian, who after completing the necessary documentation, transfers the program
into the production server. None of the people associated with development and testing of the
program would have access to the production system. Also, there would be no connectivity
established between the test server and a production server. They should be segregated through
implementation of Virtual Local Area Networks (VLANs) or similar concepts.
Figure 4.2 is a brief matrix highlighting the functions, which cannot be combined.
Figure 4.2 Brief matrix showing the imcompatable functions.

Systems and Procedures for

Effective Implementation of CBS
5.1 INTRODUCTION
There is a necessity to have a comprehensive manual, outlining the tasks that are carried out by
various personnel at the data center. This document should also assign the responsibility for carrying
out the different tasks. This document needs to be supplemented by appendices dealing with lists of
forms and templates.
5.2 DATA CENTER SECURITY PROCESS

Reserve Bank of India in its Guidelines to banking and financial sector deals with various security
aspects which need the attention of the management. The Data Center Security Manual should deal
with the procedures for implementing the high level security policy adopted by the bank management:
5.2.1 Introduction to Manual

Brief description of the bank with the number of branches and the spread over geographical area
should be given.
Scope of the process manual
The processes contained in the document apply to the bank’s data center and are also applicable to all
associates and third parties having access to the bank’s IT system. Third parties should be equally
liable for any violation of the security procedures contained in the document. All activities of the
bank’s data center would be covered by the security process manual. All the security requirements
would need to be complied with irrespective of whether the data center is managed by the bank or
outsourced to a competent third party.
Documentation requirements
The data center would require to have the following documents with specific mention of version
number:
Asset register
Risk management process
Network and security operating procedures manual
Server operating procedures manual
Anti virus operating procedures manual
Business continuity planning for data center
Distribution, review, ownership and version control

Best procedures would need to be conformed to with regard to document control and change control
of all the above-mentioned documents. There needs to be a designated approver and authoriser for the
release of the documents and the same requires to be documented. Specimen for documentation is
shown in Table 5.1.
Table 5.1 Specimen for documentation
Minimum
Approved Authorised
Sl. No. Document Version No. Custodian period of
by by
review
01 Bank’s data center security process manual
02 Asset register for data centre
03 Risk management process for bank’s data center
04 BCP for bank’s data center
05 Network and security operating procedures manual
06 Server operating procedure manual
07 Capacity planning guidelines
5.2.2 Asset Classification and Control

Information classification and accountability of assets
All the information assets of the bank’s data center are to be maintained in the form of asset
register. The details of the owner, custodian and user of these assets are to be maintained in
the asset register.
Risk management is to be performed for all the information assets. The assets are to be valued
and threats are to be identified. The existing safeguard measures, the exposure to the threats,
and the possibility of occurrence of the threats are to be considered along with the controls to
be put in place.
Information sensitivity classification and inventory of assets
Owners of assets are to have total responsibility for the protection of the information under
their control.
The asset register is to be updated whenever there is a change.
Risk analysis
Risk management exercise is to be conducted for all the assets in the bank’s data center. The
assets would include servers, routers, firewall etc. The risk management is to be based on the
risk management manual prepared separately.
The bank’s project team responsible for the data center is to prepare the risk management
report after identifying all the threats/vulnerabilities to the assets, taking note of the existing
safeguard measures in place and the controls required to mitigate the perceived threats.
The risk management is to be reviewed by the manager in charge of security and any changes
as may be necessary are to be made by him.
This risk assessment would also be verified and audited by external competent party.
The final risk management report is to be submitted to the bank’s management.
5.2.3 Physical and Environmental Security

Site selection
The facility is not to be located in a flood, earthquake or tsunami-prone area. Emergency

services like police, fire etc. are to be within reasonable distance of the data center.
Building design and construction
The building should have acceptable fire rating.

Emergency exits are to be clearly marked.
Back-up alternate power is to be available.
Physical security perimeter
The physical security to exist around sensitive areas.

The access to the sensitive area is to be restricted to authorized personnel of the data center
and entry should only be by means of access cards issued.
No combustible materials are to be stored.
Data center security
Physical security guards are to be in place on all days through the year.
Access cards to be given only to authorized personnel of the data center.
Physical entry controls
The credentials of the security personnel posted at the bank’s data center should be verified.
The security guards should be trained to follow the physical security policy. Secure area at the
data center should be clearly defined and marked.
Personnel working on Sundays or holidays should enter their visit details in the register
maintained with the security personnel.
Checking of bags is to be done both at the time of entry and departure.
Carrying of bags inside should be permitted only if absolutely necessary.
Usage of photographic video or cellphones inside the data center should not be allowed.
Equipment security
Automatic fire detection, fire suppression systems and audible alarms should be installed at
the bank’s data center to identify any fire outbreak.
These equipments need to be tested periodically.
Temperature and humidity need to be controlled and monitored. Earth connections, circuit
breakers, air conditioners etc. need to be examined periodically and reports maintained by the
data center team.
Switches and controls which permit emergency shut-down of important systems are to be
physically protected to prevent unauthorized access.
Fire extinguishers are to be positioned throughout the premises and their locations clearly
highlighted.
Procedures to safely evacuate personnel out of the premises in case of emergency like fire etc.
need to be in place.
Power supply
It should be ensured that the electricity supply is protected by means of voltage stabilizer and
such other equipments.
There should be standby supply through UPS and diesel generators.
Cabling security
It is to be ensured that cables both for power and tele-communication are appropriately
protected and not left open.
Equipment maintenance
Manufacturers’ guidelines are to be strictly followed.

The infrastructure support equipment is to be regularly maintained.
Security of equipment off premises
Prior approval is absolutely essential for entry or removal of sensitive equipment from the
premises.
Critical assets should be properly covered by insurance policy.
Secure disposal of equipment
The data center team is responsible for the secure disposal of the information on computer
media.
There should be adequate back up for all information that may be in the machine to be
disposed off. The information should be thereafter deleted from the machine to be disposed
off.
Removal of property
All the properties like laptops, printers, CDs etc. entering or leaving the data center will have
to obtain prior approval and must be supported by properties movement pass, containing
details as mentioned in the security policy.
5.2.4 Communications and Operations Management

The bank should maintain the operating procedure for all the network equipments which would
include routers, switches, firewall and intrusion detection systems. The details of procedures to be
followed are to be separately mentioned in the network and security operating procedures manual.
The server procedure manual would cover all procedures connected with the servers in use. The
procedures to be followed will include patch management, hardware procurement etc. The bank also
should maintain the antivirus management procedures. There should be proper change management
procedures in place, to be strictly adhered to by the systems administrators and to make necessary
changes in the operating procedures whenever necessary. The network administrator should maintain
the network diagram and update the same as and when changes are made (refer network and security
procedures and operating manual Para 5.4).
Operational change control
All changes to the network infrastructure as also to the servers should be incorporated only through
the approved change management procedure.
Incident management procedures
Attempts of intrusion either internally or from external points need to be analyzed. To facilitate the
analysis, the following need to be performed:
Event log file analysis

Analysis of firewall logs
Analysis of Intrusion Detection System (IDS) logs
Review of changes to the Access Control List (ACL) of the privileged program
Review of the presence of any sniffer attack
It is the responsibility of the security officer to preserve all evidence, review the cause of the
incident and restore the system.
Segregation of duties
There should be clear segregation of duties and responsibilities to avoid/reduce opportunities for
unauthorized modification or misuse of information (see Table 5.2).
Table 5.2 Segregation of responsibilities
Name of
Responsibility
the person
Managing the IT infrastructure of the bank’s data center
Monitoring security of bank’s network
Monitoring security of the various systems of the bank
Developing, maintaining and testing of the bank’s applications
Administration of compliance procedures relating to access
control to the premises and general safety of the building
Approving of the changes in the bank’s infrastructure
Details are also to be contained in the network and security procedures manual.
Separation of development/test and operational facilities
It is important to separate the development/test and operational facilities, both physically and
logically. Proper authorization procedures should be in place to move IT assets (n.w., s.w. to
production/live area people etc.) from development/test area.
Patches and upgrades
A specific individual in the bank’s systems team is to be responsible for updation of the latest patches
for all of the systems like the servers, routers and Intrusion Detection System (IDS). The downloaded
patches should be run in a test machine to ensure that implementation of the patches do not adversely
impact the services. After satisfactory verification in the test environment and authorization by the
bank’s administrator, the patches should be implemented in the live environment.
5.2.5 Systems Planning and Acceptance

The bank’s data center should prepare the annual IT resource requirements. Any additional
requirements should be sent for approval to the appropriate authority. Systems administrator needs to
report on any overloading of the following IT systems:
Internet use
Storage space
Network
CPU utilization of servers
System acceptance
All new systems to be added to the bank’s data center should be done only after strictly adhering to
the change management procedure. The systems administrator is responsible for testing the new
system considering the following:
Compliance with network bandwidth requirement

Memory requirement
Capacity requirement
Training and change management in the operation or use of the system
Business continuity arrangements
Review of security controls in place
Protection against malicious software

All the systems of the bank’s data center should have a standard and well-accepted antivirus
software. Procedures are to be in place to make sure that all desktops are also updated with the latest
version of the antivirus software.
Housekeeping
Information backup—Regular backup needs to be maintained for all essential business data and
software and stored in an offsite bank location. The bank’s data center needs to maintain records of
backed up copies and documents relating to restoration procedures. Magnetic media located at the
data center and at the off-site need to be protected against heat and fire. Some level of physical and
environmental protection as prescribed for the primary data center need also to be in place at the
backup data center. Readability of the backup media is to be tested periodically. Restoration
procedures are to be checked and tested regularly for their effectiveness of performance and also
within the time span envisaged. Removal of storage media from computing facilities should be
carried out only under proper authorization and necessary documents are to be maintained for the
same.
Operator log
At a minimum, logs are to be maintained for the following activities:

• System backup starting and finishing time
• System backup errors and corrective action taken
• Confirmation of the correct handling of the data files and computer output
• Identifying the operator
System application and security logs on the server machine are to be enabled and monitored.
Log files are to be backed up fortnightly and backed up to an off-line storage before deletion.
Detailed logs for high risk application/servers are to be maintained.
Detailed logs for specific and identified applications and resources are to be maintained.
Backup logs are to be maintained for atleast one month.
Log files are to be reviewed periodically or before file reports are over-written.
Fault logging
The systems team of the bank should maintain logs of all the faults reported by the users regarding
problems faced in the area of data processing or communication systems. The bank’s data center team
should identify the cause of the problem and rectify the problems.
5.2.6 Network Management
Network management
Any unnecessary services are to be identified and disabled.

All servers, routers and firewalls are to be hardened as per the hardening guidelines.
To deter Transmission Control Protocol/Internet Protocol Synchronisation (TCP/IP SYN)
flood and other denial of service attacks, access control should be implemented at the router
and the router is also hardened.
Appropriate Intrusion Detection System (IDS) should be deployed to detect and identify
suspicious network activity.
Network should be monitored for violation.
Vulnerability assessments need to be performed at periodical intervals to ensure also that
unnecessary ports for all network components like switches and routers are disabled.
In all critical servers, external drives such as Universal Serial Bus (USB) should be disabled.
Internet services
Various internet services should be reviewed and those that are not needed should be disabled
with the approval of the bank’s management.
Only with the approval of the manager of the bank’s data center, should inbound Terminal
Emulation Network access from the internet be allowed.
In the absence of such an approval, such access should be denied.
If inbound Telnet access is to be permitted, the following procedures are to be complied with:
• Strong authentication mechanism is used.
• All outbound Telnet access is using Secure Shell (SSH).
• All Telnet sessions are logged.
• Telnet is allowed only into port designated for Telnet services.
• Use of Trivial File Transfer Protocol (TFTP) is prohibited on public network.
• File Transfer Protocol (FTP) access is denied to all the Bank’s servers.
Firewall standards
Natted IP address should be used to protect the internal network (network address translation)
wherever applicable.
Access to firewall needs to be constantly analysed.
If it is observed that the firewall is compromised, it should be reconfigured.
A formal change management process should always be followed in changing a firewall
policy.
All the users communicating through the firewall system should be identified and logged.
All non-essential networking or system services from the firewall should be removed.
There should be a weekly review of all the system logs generated from the firewall.
Strong authentication methodology is to be implemented to the firewall authentication server.
Firewall system indicated is to be verified on a regular basis.
Intrusion Detection System (IDS)

Standard intrusion detection systems should be used to perform real time analysis of network traffic
patterns. It is to enable detection of attempted attacks.
Publicly accessible systems (e.g. website used for internet banking) utilise systems monitoring
tools that provide real time alert whenever suspicious subscriber activity is detected.
5.2.7 Media Handling and Security
Removable computer media is to be stored in a safe and secure environment both offsite and
within the bank’s data center.
It has to be in accordance with the manufacturer’s specifications.
If any storage media is required to be reused, previous contents of the same should be erased
upon approval by the manager of the data center.
All removal of media should be done only with the approval of the appropriate authority and
records should be maintained for all such movements.
Disposal of media
All confidential and sensitive documents should be disposed of using appropriate shredders.
When a user leaves any position, the following procedure should be followed:
The immediate supervisor reviews both computer resident files and papers to decide on the
subsequent custodian of such files.
If the files need to be disposed of, appropriate methods are to be adopted.
Bank should maintain a log of disposal of sensitive data.
Security of media in transit

Information backup media should be transported outside the bank’s data center only after appropriate
authorization.
The transport or the courier service should be officially authorized.
There should be a non-disclosure agreement with the third party transporter.
Security of electronic office systems (Laptops, PDA-personal
Digital Assistants etc.)
Vulnerability assessments need to be performed on a periodical basis.

Access to electronic office systems remotely or over the internet is to be secured using Hyper
Text Transfer Protocol Secure (HTTPs).
The system should be subject to internal audit periodically.
Systems are to be backedup and stored in a remote location.
Specific owner should be identified for the system.
5.2.8 Access Control Policy
Access should be provided to computing facility on a need to know basis.

Access to network resources should be provided only after the identification and
authentication.
User access management

A specific register should be maintained for user registration and deregiztration giving full details of
the date and time.
Privilege management
Records should be maintained for all privileges allocated.

Privileges are to be granted only after completion of the authorization process.
There should be a tracking procedure for user assigned with high privileges for special
purposes, e.g. emergency situations.
Periodic review needs to be conducted to ensure that access rights are denied or updated for
those who have resigned or changed position respectively.
Similarly, review should be conducted to see whether all the existing users are having access
rights to ensure that no user is accessing the system under a different user’s login.
User password management
Password files should be stored separately from application systems data.
Review of user access rights
User access details for high risk and sensitive applications are to be reviewed at short
intervals.
Network share existence and Access Control List (ACL) for the users are to be periodically
reviewed.
Unattended user equipment
Terminals should be locked when users are away from the desk.
Screen savers should be set to activate within say five minutes of inactivity.
Network access control

Policy for usage of network services: Following are the policies for and usage of network
services:
a) The firewall policy should be such that only specifically authorized connections are allowed and
none else.
b) All default access passwords should be disabled.
c) Default passwords for all network equipments should be removed during installation.
d) All data communication as also internet traffic should be routed through a firewall properly
configured for that purpose.
e) Network services that are not required should be disabled.
f) File permissions should be checked.
g) Network services used for administrative purposes should not have remote access.
h) All systems administration tasks should be carried out only at the console of the server.
i) Vendor’s access should be permitted only after proper approval and the same should be permitted
under supervision.
Segregation in network: Segregation in network would involve the following:
a) Routers and firewalls should be hardened to prevent any compromise.
b) Network management like router and firewall is to be restricted to the specified IP address.
c) The access to the secure server room should be allowed only by means of access cards.
d) All network components should be uniquely identifiable and restricted only to the specified business
functions.
Network connection control: Following guidelines are to be taken care of while controlling the
network connection:
a) All infrastructure diagrams should be kept up-to-date showing internal and external connections
before allowing any new connections to them. This helps to identify the security, traffic and physical
impact of adding a new user(s) on the Local Area Network (LAN).
b) All the default accounts are to be removed. If the default accounts cannot be removed, then they are
to be disabled or renamed.
c) All default manufacturer passwords are to be changed.
d) User access control is to be implemented to access the network management and operations devices.
All communication devices are to be protected by the passwords.
e) The critical server/project servers, remote management consoles are to be assigned static Internet
Protocol (IP) Address. The servers should be configured in such a way that the remote management is
only possible from the identified administrative machines.
f) The remote management should be performed using Secure Shell to ensure session encryption and
authentication.
g) It should be ensured that log files are never overwritten or deleted until they are backedup to an off-
line storage medium.
h) The log files should be reviewed daily for any suspicious activity. Suspicious activities identified
are to be reported to the security officer who should initiate investigation to identify the source and
the reason of the attack.
Network routing control: Network routing control would include the following:
a) Static and dynamic routes should be defined for activity with other branches data centre.
b) Access Control Lists (ACLs) should be implemented at the router to control the type of traffic as
well as source and destination of the traffic.
Terminal identifiation
a) Automatic terminal identification should be used to authenticate connections with specific locations
and to portable equipment.
Terminal log on procedure: Procedures of terminal log include the following:
a) The number of unsuccessful attempts should be restricted to three. There should be no help messages
provided during login procedure.
b) The login procedure should be validated only on completion of all input data. Not providing
intermediary error messages help in not providing information on which part of input is wrongly
entered.
Use of system utilities: Following points are to be kept in mind while using system utilities:
a) Use of systems utilities should be restricted and controlled.
b) They are generally segregated from the application software.
c) The use of systems utilities should be restricted to minimum number of trusted users.
Terminal time out: Inactive terminals in the secure area should shut down after a pre-determined
period of inactivity.
Application/systems access control
Monitoring system access and use: The security parameters available in the operating system
should be enabled. The logging of such events would include success or failure of:
Account log on events

Account management
Directory service access
Log on events
Policy changes
Privileged use
Process tracking
System events
Clock synchronization: Clock synchronisation for all servers and nodes needs to be controlled
centrally from the data centre. (Using protocols like Network Time Protocol (NTP) and Simple
Network Time Protocol (SNTP).
5.3 DATA CENTER SERVER PROCEDURES MANUAL

This manual provides operational details for the various server resources that are managed at the
bank’s data center. The documents would include the following:
1. Hardware Platform
2. Server Operating System
3. Server Role
4. Server Operations Procedures
5. Patch Management Process
6. Password Management
7. Hardware Procurement Process
8. Hardening Procedure
9. Escalation Process
5.3.1 Hardware Platform

This section should deal with describing all the servers at the data center by providing an annexure, if
necessary, which would provide the complete hardware configuration.
5.3.2 Server Operating System
This should mention the details of the operating system including details of important features.
5.3.3 Server Role
This section should mention details of all the servers at the data center, e.g. web server, application
server, database server, antivirus server etc.
Patch updation: Method of updating and the source of availability of the patches are mentioned.
Hot fixes are released more frequently to deal with specific problems. The method of updations and
the source of availability need to be mentioned.
Application server
Broad details of the application and the technology on which it is based should be mentioned.
Patch updation: The Uniform Resource Locator (URL) of service patch and hot fixes should be
mentioned. It needs to be mentioned that before service patches are installed on a live system, they
should be installed on a test server, test the functionality to ensure that there are no fresh problems
arising due to the installation. The same applies to hot fixes also.
Database server
Mention is to be made of the query language which could be used to access the database available at
the server.
Patch updation: The source where service patch and hot fixes would be available needs to be
provided giving full details of the URL. In this instance also the patches need to be tested before
finally used for updation.
5.3.4 Server Operations Procedure
This section broadly covers various administrative activities of the administrators of the servers.
This would include the following:
Start up and shut down

Preventive maintenance
User management
Change management
Back up and restoration procedure
Server recovery procedure
Hardening
Incident management
Event logging
Each of the sections would describe in detail the operations undertaken under these heads.
5.3.5 Patch Management Process

A software, either application software or system software would be updated with patches. There
needs to be a well laid out procedure for patch management. Best practices would be for the banks to
register with the vendor website for a daily alert of latest patches.
This would enable automatic receipt of messages regarding updates instead of the bank having
to access the URL to find out whether there are any patches.
The data center administrators would test the patches on test servers and after satisfying
themselves would document the procedure for implementation.
The data center administrator would follow change management procedures and then only
implement the patches.
5.3.6 Password Management

This section deals with procedures for password selection as also changing of passwords. ‘Dos’ and
‘dont’s’ should clearly be laid down.
5.3.7 Hardware Procurement Process

This section should clearly lay down detailed procedures to be followed for acquisition of additional
hardware.
5.3.8 Hardening Procedure

Each of the Operating systems would itself have a well laid out hardening procedure. By strictly
adhering to the hardening procedure prescribed, known security issues would be minimized.
5.3.9 Escalation Process

There should be a well laid out procedure for escalating system problems.
5.4 NETWORK AND SECURITY PROCEDURES AND OPERATIONS MANUAL

Written procedures need to be recorded in the form of a manual, providing the operational details for
various network resources that are managed by the network and security administrator at the data
center of the bank. The document should provide details of configuration management, change
management, hardware details and utilization of various network components that are managed by the
bank’s data center network administrator.
Network and security administrators need to follow and carry out their operations connected with
the various network components managed by them as described in the document. A clear network
diagram needs to be provided giving details of local area network, internet, demilitarized zone and
wide area network. Levels of access controls implemented at perimeter where the internet link ends,
needs to be mentioned.
5.4.1 Network and Security Administration

Network administrator in a bank where core banking solution would have been implemented would
generally manage the following components:
1. Switches
2. Routers
3. Firewalls
4. Intrusion detection systems
5. Communication links
6. Hardware procurement process
7. Password management
Switches
Switches provide the Local Area Network (LAN) connectivity to all devices and servers in the data
center of the bank. Servers would be divided into public and private zones. The documentation
should specify the configuration management mentioning specific details about the switches,
communication lines etc.
Change management: The procedure for change management is expected to be in accordance with
the change management procedures as specified in the security process document of the bank’s data
center.
Routers
The location of the routers and usage of the same need to be documented.
Configuration management: The network administrator configures and maintains the routers.
Details of router hardware procedures need to be recorded. The hardware and software configuration
details need to be recorded. Access lists need to be implemented to filter and restrict the access to
network as also the router.
Change management: The change management procedures should again be in line with the bank’s
data center security process.
Back up of router configuration: The router configuration and Internetworking Operating Systems
(IOS) need to be documented and the backup procedures need to be formulated and complied with in
a systematic manner.
Firewalls
Firewall is an important part of a network. It plays the role of preventing unauthorized access to and
from a private network. Firewall may be implemented both as a hardware and a software or as a
combination of both. The details of the implementation of firewall need to be clearly documented.
Configuration management: Configuration of firewalls needs to be documented in a firewall
configuration sheet.
Change management: The procedure for change management needs to be in accordance with the
change management procedures documented in the data center security process manual.
Security log management: Procedures to generate firewall logs need to be put in place to enable
troubleshooting. More importantly, the logs should be enabled for the following:
All dropped connections other than broadcast

All incoming requests to the inside network
All incoming Hyper-Text-Transfer Protocol (HTTP) connections
The firewall logs need to be analyzed for the following:
Events of rejected attempts through firewall external interface.

Successful and unsuccessful connection attempts through certain ports
Standby firewall: It is advisable to have a standby firewall so that in case of failure of the primary
firewall, stateful failover mechanism could be implemented where the standby firewall can take over
the network without disconnecting the active zone.
Incident handling: Firewall logs need to be reviewed for established connections, as also for
reviewing any attempts for tracking any incidents through the firewall. There needs to be a procedure
to escalate to senior management any firewall incident detected by the firewall administrator.
Intrusion Detection System (IDS)
An intrusion detection system generally aids in detection and response for attack that may originate
from across the network. Configuration management of Intrusion Detection System (IDS) needs to be
documented. Change management should be in accordance with change management procedures of the
bank’s data centre security process manual.
Security log management: Logs should be analysed. Security administrator should monitor the log
file and alert the appropriate person in case of any suspicious activities. Logs should be retained for a
reasonable length of time, say, at least six months.
Communication links
Communication links would connect the bank’s data center to the bank’s disaster recovery site as also
to the bank’s branches. Configuration management details should be documented.
Hardware procurement process
Hardware procurement process should be documented and should be strictly adhered to. Also the
same should be monitored.
Password management
Policy on password management would be mentioned in the security
policy. Monitoring mechanism to ensure that recommended procedures
are strictly adhered to, need to be put in place. It is essential that default passwords should never be
assigned. Access to sensitive files should always be through complex password authentication. The
sensitive password should generally be maintained in a sealed envelope at the data center. A register
should be maintained in which each opening and sealing of the envelope is recorded.
Password selection: Set of Guidelines for password selection should be provided with ‘Dos’ and
‘Dont’s’. Password should be changed at least once a month.
5.5 DATA CENTER OPERATIONS MANUAL

The data center in a bank will house various server resources that are
managed by the server administrator, apart from network components like switches, routers, firewall,
intrusion detection system (IDS) and communication links.
The operations should be well documented and the contents of the documentation could be as
follows:
5.5.1 Introduction
This should contain operational details for various server resources that are managed by the server
administrators at the data center. This document should also mention details of the hardware
configuration of the server, network devices and storage details.
Purpose of the document
The purpose of the document is to provide guidance to the bank’s network administrators to follow
and carry out their operations. It should also provide guidance on the associated procedures for the
various network components managed by the system administrator
Intended audience of the document
Management of the bank as also service providers, if any.

Bank’s infrastructure head.
Bank administrator (includes head of the third party service provider, if any).
5.5.2 Hardware Platform

This should contain details of high end servers which would be located at the bank’s data center.
Hardware configuration: Hardware configuration of all the servers located in the data center
should be mentioned in detail.
Database server
Table 5.3 shows the details of a database server.
Table 5.3 Database server
Server Name IP address Sub Net Mask Service Running
DBS ……….. ……….. e.g. SQL server
Operating System—WINDOWS 2003: This service pack ‘X’ installed. ‘Y’ antivirus, scan
version ‘Z’ software is installed with updated _______ scan engine (see Table 5.4).
Table 5.4 Hotfix
Patch Name Description
RAID: Redundant Array of Inexpensive Disks (RAID) could normally be installed and a mention
should be made of the RAID level and also mention that the RAID level is configured for the hard
drive in the database server.
Application: Mention should be made of the database running on the database server, e.g. SQL ___
database server. Mention could also be made of the number of the service pack. Mention should be
made as to which is the active server and which is the passive server. Details should be available
and mentioned as to where the SQL INSTANCE is installed. Details of the file name and path should
be mentioned.
Application server
The document should contain the details, preferably as shown in Table 5.5.
Table 5.5 Application server
APP….. ……….. ……….. *
* Mention could be made of the core banking solution, e.g. FINNACLE, FLEXCUBE, QUARTZ.
The hardware configuration of all the servers should be mentioned in detail.

RAID: Mention should be made of the RAID level which is configured for the drive in the
application server.
Operating system: WINDOWS 2003 Server (Mention other operating system, if any).
Table 5.6 shows the details of patch name with description.

Table 5.6 Patch name with description
Details of the antivirus, e.g. McCafee antivirus, scan version no.

Application: Mention should be made of the core banking solution running on the application
server, e.g. FINNACLE, FLEXCUBE, QUARTZ. Mention should be made of the server which is an
active server accessed by the branches. The details of the servers hosted in the demilitarized zone
and security zone should also be mentioned.
Web server
Details should be available as shown in Table 5.7.
Table 5.7 Details of web server
WEB….. ……….. ……….. *
* e.g. IIS
Hardware configuration: The hardware configuration should be mentioned in detail.

RAID: Mention should be made of the RAID level which is configured for the drive in the web
server.
Operating system: WINDOWS 2003, this service pack no. ________ is installed (See Table 5.8).
Hotfix
Table 5.8 Patch name and description
Note: The name of the antivirus software with the status of updation should be mentioned.
Application: This should mention the process details. Internet Information Services (IIS). The
client accesses the pages hosted by the IIS and the web-server will interact with the application
server for processing the transactions and the information stored in the database server.
Backup server
Details should be available as shown in Table 5.9.
Table 5.9 Details of backup server
Veritas/Oracle
BKSRV ……….. ………..
Dataguard
Hardware configuration: The details of the backup server should be mentioned here.
RAID: Mention should be made of the RAID level which is configured for the drive in the back-up
server needs to be mentioned.
Operating system: WINDOWS 2003, this service pack no. ________ is installed (see Table
5.10).
Hotfix
Table 5.10 Patch name with description
Application: Mention should be made of how the back-up is done. For example, back-up tape,
library is connected with this server. A trust relationship is established with disaster recovery site.
The trust relationship is established with the active directory server of the disaster recovery site.
5.5.3 Network
Details of the router e.g. CISCO XXXX router
Configuration: Details may be recorded as shown in Table 5.11:
Table 5.11 Details of router
Router Sl. No. Description Quantity
………............................ ………............................ ………............................
Passwords: Details may recorded as shown in Table 5.12.

Table 5.12 Details of Password
Control Password Enable Password Secret Password TELNET Password
The password should never be entered in soft copy document for obvious reasons. Confidentiality
to be maintained.
SNMP configuration: SNMP configuration consists of following:
READ only
READ
WRITE
Slots/Ports details: The details should be in the following format as shown in Table 5.13.
TABLE 5.13 Details of slots/ports
Description Total Used Free
Serial (Sync) 4 3 1
IP and interface configuration: The details could be presented as shown in Table 5.14.
Table 5.14 Configuration of IP and interface
Sl. No. Interface Name IP Address Sub Net Mask Remarks
For each of the IP addresses details should be available regarding the connection.
OSPF (Open Shortest Path First)
Configuration details to enable OSPF routing to be mentioned.
Access List: WAN Access List No. ____. Applied at _____. Similarly for all application lists
should be mentioned. The rules need to be recorded, preferably as shown in Table 5.15.
Table 5.15 Recording of rules
Sl. No. Rule Remarks
1. *
2.
3.
* Remarks would contain narration as ‘allow all PING replies’ or ‘allow all PING requests’, ‘allow data from ‘x’ place’.
Router hardening configuration. This should contain details of global configuration and also
interface configuration and version of the Internetworking Operating System (IOS).
Firewall
A brief description of the firewall installed needs to be mentioned. e.g. CISCO PIX.
XXXX Firewall Primary
XXXX Firewall Secondary
For each of the firewalls the details should be available as shown in
Table 5.16.
Table 5.16 Details of firewall
Sl. Interface IP Sub Net Security
Remarks
No. Name Address Mask Level
.............. .............. .............. .............. .............. ..............
Static NAT (Network Address Translation)

The details should be represented as shown in Table 5.17.
Table 5.17 Details of NAT
Sl. No. Local Local IP Global Global IP
Interface Interface
.............. .............. .............. .............. ..............
Dynamic NAT
The details mentioned as shown in Table 5.18.
Table 5.18 Command with description
Command Description
................................................................ ................................................................
Routing: Details of routing done through the firewall need to be mentioned. It may be described as
shown in Table 5.19:
Table 5.19 Details of routing
Sl.No. Network Mask Gateway Interface
............... ............... ............... ............... ...............
Access list: Details of objects created for purposes of administrating access lists need to be
mentioned and a table needs to be created to record the following details as shown in Table 5.20.
Table 5.20 Access list
Sl. No. Network IP Mask Remarks
.................... .................... .................... ....................
Access list name: The rules applicable need to be contained in a proforma which could be
represented as shown in Table 5.21.
Table 5.21 Applicable rules
Sl. No. Rule Remarks
1 ............... ..................... ............... .....................

2
3
Access to firewall: Access to firewall should be documented as shown in Table 5.22.

Table 5.22 Access to firewall
Sl. Allowed
Access Type MASK Interface
No. network IP
...................... ............................. ........................ .........................
Intrusion detection system

The configuration details need to be mentioned as in Table 5.23 below:
Table 5.23 Intrusion detection system
Module Description Quantity
1 XXX Sensor ...................... ...................... ..................
2 .......................................................
3
Passwords
Administrator user name Xxxxxx
Administrator password ...................... ...................... .........................
Passwords should not be entered in the soft copy.

Slot/Port details: Table 5.24 shows the detailed presentation format of Slot/Port.
Table 5.24 Slot/Plot details
Description Total Used Free
.............................. .............................. .............................. ..............................
IP and Interface configuration: The data could be presented as in Table 5.25.

Table 5.25 IP and interface configuration
Sl. No. Interface Name IP Address Sub Net Mask Remarks
.......................... .................... ........................ .........................
Access list: The details of the host computer permitted to communicate with the intrusion detection
system need to be recorded in a tabular column as shown in Table 5.26.
Table 5.26 Intrusion detection system
Sl. No. Access Type Allowed Network/IP Mask
................ ................................. ................................... ...................................
Signature configuration: Signature is a pattern of an attack or malicious activity. There will be

new signatures coming up. An intrusion detection may have a list of signatures. These signatures
would be constantly updated and the latest updated information would be available at the IDS
providers’ website. The intrusion detection system should be configured so as to automatically update
the signatures by accessing the Internet.
Enabling/disabling signatures: As all the signatures would not be required for the network, only
some of them would be enabled based on the traffic pattern and usage. Details need to be mentioned
in the manual.
5.5.4 Storage Array Network
Storage array network
A brief description about the connectivity between the storage devices such as disk arrays, tape
libraries etc. should be documented in this section.
Configuration information: Following are the details of configuration information (see Table
5.27).
TABLE 5.27 Configuration information
Number of controllers
Number of arrays ...................... .................................................
Total number of logical drives
Number of drives
Drive capacity
Total number of bays available (slots)
Firmware version
NVSRAM version
Power supplies
Interface details: Details of all the available interfaces to be recorded in this section. For
example:
Fiber port: 1
Maximum data rate
Current data rate
World-wide port name
World-wide node name
Fiber port: 2
Maximum data rate
Current data rate
World-wide port name
World-wide node name
Ethernet port: 0
MAC address
Host name
IP address
Subnet mask
Gateway
RAID configuration: The RAID level and storage medium details are to be mentioned.
Performance details of the RAID level configured could also be mentioned (see Table 5.28).
Array 1
Table 5.28(a) Performance details of RAID configuration
Sl. No. Logical Drive Name Controller Size
...................... ................................ ...................... ...................... ...................
Array 2
Table 5.28(b) Performance details of RAID configuration
Sl. No. Logical Drive Name Controller Size
...................... ................................ ...................... ...................... ....................
Mapping storage partitioning: Logical drive names and its mappings may be mentioned in a
format as shown in Table 5.29.
Table 5.29 Mapping the storage partitioning
Sl. No. Logical Drive Name Host Group
...................... ................................ ...................... ...................... ....................
5.5.5 Tape Library

A brief description of tape library needs to be provided here highlighting the features.
Example: Tape library has ‘N’ cartridge removable magazine, a bar code reader etc.
5.6 DATA CENTER BACKUP PROCESSES AND PROCEDURES

5.6.1 Introduction
A backup process and procedures are to be documented in detail which would normally contain the
policies to be adhered to and procedures to be followed for backup and restoration. It should also
contain details about the tape labelling scheme, offsite tape management, data revision, frequency and
types of backup performed at the data center.
The purpose of documenting procedures is to enable recording of procedures for the bank’s data
center and to enable the data base administrators to carry out their operations and associated
procedures for data base backup and restoration.
5.6.2 Backup Policy

The objective of taking backup is to prevent the loss of data in case of systems failure or in the event
of accidental deletion of data.
Backup process
This should contain comprehensive details, for instance when a strong backup policy is implemented
for both systems data base and user data base, the details may be as follows:
Master data base............:............Full backup
Model data base.............:............Full backup
Msdb data base...............:............Full backup as also differential backup
Bank data base................:............Full backup, differential backup and
............ ............ ............ ............ ........transactions log backup
Information needs to be provided that regarding the media in which backup is stored, e.g., stored in
disc pool and then copied to the daily tape.
The production server system backup should be taken periodically, preferably once a fortnight at
least. In addition, backup should be taken when server configuration or settings are changed.
Frequency period
Data backup should be defined with frequency period to ensure minimal downtime and no data loss in
the event of failure. The details should preferably be recorded in a format as shown in Table 5.30.
Table 5.30 Frequency period to ensure minimal downtime
Database Backup Type Frequency Time
MASTER Full Weekly (Sunday) 9.00 PM
MODEL Full Weekly (Sunday) 9.00 PM
Full Weekly (Sunday) 9.00 PM

MSDB
Differential Daily (except Sunday) 11.35 PM
Full Weekly (Sunday) 9.00 PM
Daily 9.05 AM
Differential Daily 2.05 PM

BANK
Daily (except Sunday) 11.05 PM
Every 15 minutes between

Transaction log Daily
12.00 noon to 11.59 PM
Tape backup of database server should normally take place after the day end process. Weekly
backup of the production server system may be done with the weekly backup of database.
Backup verification
To ensure the integrity of the backup, test drill should be conducted at the end of every week. This
should be mentioned in the manual to ensure that both the tapes and the backup procedures were
properly adhered to.
Storage access and security
When it is not in use, the media should be stored in fire-proof safe and away from magnetic fields like
diesel generator and other motor rooms. All backup media should be stored in a secure area which is
accessible only to the bank’s data center staff and to the authorized personnel of the computer
department.
Offsite storage
Another copy of the backup in tape should be managed by the bank’s management staff. This may be
stored at the bank itself and this backup will normally be taken on a weekly basis. However, off-site
storage must be secured and available only to the bank’s data center staff and the computer systems
department staff.
Restore request
Request for restoration of data should be by proper authorization of a member of the bank staff duly
authorized to perform such function.
5.6.3 Tape Management

This should mention as to how many tapes are used for database backup and how many are stored at
the data center and in the off-site location. Details should also be available as to how many represent
daily, weekly and monthly backups. Systems state backup should be taken in a separate tape (see
Table 5.31).
Table 5.31 Tape management details
No. of tapes used No. of tapes stored
Backup
per month at D.C. per month in offsite
Daily ............ ............ ....................... ................. ............. ............. .............
Weekly
Monthly
Tape inventory
It is important to maintain inventory of tapes. This provides a clear picture of the backedup data
which could be used for restoration. The inventory should preferably be maintained in a register in
the following format as shown in Table 5.32.
Table 5.32 Maintaining inventory of tapes
Date of backup Backup start time Backup end time Duration of backup Backup tape’s name or tape label Size of backedup data Status of backup Scratch date*
........... ........... ........... ........... ........... ........... ........... ...........
........... ........... ........... ........... ........... ........... ........... ...........
........... ........... ........... ........... ........... ........... ........... ...........
........... ........... ........... ........... ........... ........... ........... ...........
* This column needs to be filled at a later date when the tape is used for a new back up—Recycling.
Tape retention
Mention should be made of the period of time the tapes will be retained. Generally after six months,
tapes would be demagnetized and new set of tapes would be used for backup. This would be the case
when the tapes are stored in the offsite location as well.
Tape labelling
Table 5.33 shows the tape labelling.
Table 5.33 Backup solution and labelling for daily backup
Scenario: 1. Per day __ GB of data to be backedup
2. ___ Copies need to be taken (onsite and offsite)
3. ___ Tape is used for this purpose
4. Data retention period is __ days for daily backup
5. Maximum tape usage period is ___ year
6. All ODD Nos. represent tapes at onsite
7. All EVEN Nos. represent tapes at offsite
8. At the end of 6th day the Monday tapes at offsite will be sent to onsite for overwriting the data
9. The above step is carried out for all days.
10. The labelling convention, CYYYMTZZZ is followed for labelling of backup media.
Where C denotes the backup generated
at the bank’s data center
YYY denotes the project name or
server name
F - floppy
M denotes the media type
C - CD
which can be
D - DAT
W - weekly
T denotes the type of backup M - monthly

which can be Q - quarterly
Y - yearly
ZZZ denotes the backup generation
number with respect to the type of backup
DAY LABELLING AT ONSITE LABELLING AT OFFSITE
XXX XXX
Monday
XXX XXX
XXX XXX
Tuesday
XXX XXX
XXX XXX
Wednesday
XXX XXX
XXX XXX
Thursday
XXX XXX
XXX XXX
Friday
XXX XXX
XXX XXX
Saturday
XXX XXX
XXX XXX
Sunday
XXX XXX
5.6.4 Backup Procedures

This portion of the manual should discuss the procedures followed in the bank to backup the database
as also the files in tape.
Data backup procedures
Usually database backups are taken online using T-SQL command. These commands are written in a
script and added to Structured Query Language (SQL) server job. The backup commands used for
taking different types of database may be recorded as follows:
Master full backup commands
xxx
xxx
xxx
xxx
xxx
xxx
Model full backup commands
xxx
xxx
xxx
xxx
xxx
xxx
MSDB differential backup commands
xxx
xxx
xxx
xxx
xxx
xxx
Bank full backup commands
xxx
xxx
xxx
xxx
xxx
Bank differential backup commands
xxx
xxx
xxx
xxx
xxx
xxx
Bank transaction log backup commands
xxx
xxx
xxx
xxx
xxx
xxx
End of day manual backup commands
xxx
xxx
xxx
xxx
xxx
xxx
All backup files should be stored in Storage Area Network (SAN) storage.
Location of the database backup and for log backups should be mentioned.
Tape backup procedure
The procedure followed to backup the data files to tape needs to be described in detail step by step.
5.6.5 Recovery
Recovery plan should be in place to provide all possible recovery options. This would facilitate
speeding up of the restoration and recovery process during a database crash. Recovery methods will
vary. However, the methods should be described in great detail in a methodic fashion step by step.
This procedure should cover each of the databases.
5.7 ANTIVIRUS PROCEDURES MANUAL

In a core banking solution environment, the need for antivirus software is immense since there is a lot
of dependency on critical servers.
Antivirus process should cover both the servers at the data center and the desktops at various
branches. In addition, it should also include mail security, proxy level security and client security.
5.7.1 Server Deployment

Data center has a repository antivirus server which updates all the virus definitions. It receives
updates regularly.
5.7.2 Virus Scanning

A scheduled virus scan for all the servers should be in place. The scan should be scheduled so as not
to affect the banking process as scanning can slow down system performance.
5.7.3 Antivirus Update Management

The antivirus server which is connected to the Net, receives updates of virus signatures periodically.
The bank should have a process of verifying that latest signatures are updated.
Application Program
Modules and their Functionality
6.1 INTRODUCTION
This chapter deals with business processes of the different modules of the banking functionality. It is
necessary to have clarity on the basic business requirements of each of the business functions.
Information technology is an enabler. It is envisaged to provide the support to achieve the business
objectives. After understanding the business objectives, one needs to look at the system to verify
whether these objectives are being achieved.
Banks in India have converted their total branch automation system computerization branches to
core banking solutions which enable the banks to have centralized control over the systems,
procedures and operations. This involves creation of a customer ID which will be unique and can be
accessed across all the branches for better and quick customer service.
Reserve Bank of India (RBI) has issued circulars and guidelines for effective implementation of
know your customer (KYC) norms and has laid down the following rules:
In order to prevent identity theft, identity fraud, money laundering, terrorist financing, etc., the
RBI had directed all banks and financial institutions to put in place a policy framework to
know their customers before opening any account.
This involves verifying customers’ identity and address by requiring them to submit
documents that are accepted as relevant proof.
Mandatory details required under know your customer (KYC) norms are
• proof of identity and
• proof of address.
Passport, voter’s ID card, PAN card or driving license are accepted as proof of identity, and
proof of residence can be a ration card, an electricity or telephone bill or a letter from the
employer or any recognised public authority certifying the address.
Some banks may even ask for introduction by an existing account holder. Though the standard
documents which are accepted as proof of identity and residence remain the same across
various banks, some deviations are permitted, which differ from bank to bank.
All documents shall be checked against banks requirements to ascertain whether they meet the
requirements or not before initiating an account opening process with any bank. Thus for
opening a new bank account a set of procedures need to be followed.
In 2004, the RBI had come up with more specific guidelines regarding KYC. These were divided
into four parts as follows:
Customer acceptance policy: All banks shall develop criteria for accepting a person as their
customer and to restrict any anonymous accounts and to ensure submission of documentation
mentioned in KYC.
Customer identification procedures: A customer needs to be identified not only while
opening the account, but also at the time when the bank has a doubt about their transactions.
Monitoring of transactions: Know Your Customer (KYC) can be made effective by regular
monitoring of transactions. Identifying an abnormal or unusual transaction and keeping a watch
on higher risk group of accounts is essential for this purpose.
Risk management: This is about managing internal work to reduce the risk of any unwanted
activity and also managing responsibilities, duties and performing audits in addition to regular
employee training for KYC procedures.
In this background it has become all the more important to ensure that the systems operate with
necessary application/access controls and as per the procedures and guidelines set forth by concerned
banks, during evaluation of controls.
Essentials of each of the processes are listed out so as to help the reader to get an overall view of
what should be expected in the process. An understanding of the flow of process helps the reader to
ensure that all of the features are built into the system. However, it should be noted that the business
process discussed may have variations in different banks. It is essential to understand the specific
requirements of the bank before verifying the functionality of the application.
6.2 CUSTOMER INTRODUCTION

Customer approaching a bank for a business relationship of having a savings, deposit, loan accounts
etc. is provided with an account opening form and the customer has to provide the following
particulars along with the necessary proof:
Name
Address
Age
Occupation
Constitution
Residential status (resident/non-resident)
Photo
Passport details (for non-residents)
Specimen signature
The introduction by an existing customer is mandatory for opening a new account. The bank
officials authorize the acceptance of the customer after satisfying themselves about his credentials and
compliance as per the norms and procedures laid down by Reserve Bank of India (RBI) under know
your customer (KYC) norms.
The details of the customers obtained are fed into the system which go through a process of
validating the above-mentioned details and generate the customer ID. The customer will be in a
position to avail of the various products and facilities offered by the bank after being accepted as a
customer. Banks can refuse to open the accounts for persons not eligible to contract or for persons
whose track record is not satisfactory.
System provides for verifying the existence for such details. The details manually presented are
acknowledged by the data entry operator by making an entry in the system and the same is endorsed
by a supervisory staff or officer.
6.3 ACCOUNTS MANAGEMENT

6.3.1 Savings Accounts
Customer once accepted by the bank, requests for opening a savings account to deposit his
savings in cash or cheques periodically and withdraw as and when he requires it for various
purposes.
The bank authorizes opening of the savings account after the customer furnishes the mode of
operation, viz. individually, jointly, either or survivor etc. The customer is issued a cheque
book on his request. The cheque numbers are entered in the system.
Savings account is mainly maintained for non-commercial purposes and also earns interest
which is payable on the monthly minimum balance, once in six months.
The banks stipulate a minimum balance to be maintained in the savings accounts and some
penalty is levied for not maintaining the required balance.
The banks cannot refuse payment even if the withdrawal causes the balance to come below the
minimum balance. They can only charge a levy.
Nomination facilities are available which can be registered at the time of opening an account
or even afterwards. This facility is more useful if customer chooses to open the account singly
and not in joint accounts.
Some banks restrict the number of withdrawals per quarter in the savings account.
Since minors can only be beneficiary to a contract, it requires the guardian (natural/court
appointed) to operate the account.
These procedures and guidelines are applicable in the case of the non-resident accounts also.
The NRIs can choose to have a separate non-resident ordinary account for the purpose of
depositing any dividends, rent or any other local credits.
In a core banking solution (CBS) environment these accounts can be opened and operated
from any core banking solution (CBS) branch—a feature called ‘anywhere banking’.
The customer can have the facility of having an ATM/Debit card issued in his name which can
be used to transact through the ATMs and merchant establishments. These facilities are
available only for the individual customers.
6.3.2 Current Accounts

The current accounts are for the purpose of commercial activities and no interest is payable on it. The
procedure for opening of current accounts are the same as that of the savings accounts except that
additional particulars/proof as mentioned here are required to be submitted.
In case of companies, memorandum and articles, certificate of incorporation, certificate for
commencement of business (public limited company), board resolution (opening of account
and authorized signatories).
In case of trust, trust deed and board resolution.
For clubs, association and societies, certificate from registrar of societies, by-laws, resolution
etc.
Partnership deed in case of partnership firms.
Declaration by the proprietor in case of sole proprietary concerns.
In CBS, there would be drop down menus to mark receipt of the above-mentioned documents.
6.3.3 Cash Credit
Procedures for opening of current accounts apply for cash credit accounts also.
Cash credit is a credit facility extended as working capital limit to customers whose
transactions are commercial in nature.
This working capital is funded by the banks, and a margin is to be provided by the customer.
The banks provide cash credit limits against hypothecation of raw materials, work in progress
and finished goods in case of manufacturing concerns and stock of goods in case of traders.
The stocks hypothecated to the bank are the primary security and banks may stipulate
additional securities on a case to case basis.
The customers are expected to submit details of paid-up stock held by them every fifteen days
or the period stipulated by the bank in the prescribed format.
The banks calculate the advance value, net of stipulated margin and fix the drawing limit up to
which the customer can avail the credit facility.
The drawing limit will be lower or equal to the limit sanctioned.
In case of high profile cash-credit accounts, the customers are required to furnish the
projections for the next year and their plan for quarterly targets.
The stocks hypothecated with the bank should be insured for all possible risks for the full
value. After manual verification of the insurance policy the data may be entered in the system.
6.3.4 Overdraft
Overdraft is a credit facility sanctioned to the customers against bank deposits, shares,
government and other securities.
Banks also allow clean overdraft facility on selective basis to their reputed customers.
Customers can avail overdraft against their bank term deposits up to the maximum limit fixed
by the bank. Instead of disbursing the entire amount, the bank fixes a limit upto which the
customer can operate in his overdraft account.
The banks mark lien over the term deposits against which the overdraft has been allowed and
unless the overdraft liability is cleared, banks will not release the deposit receipts as the lien
will be marked on the deposits and the system will not allow release.
In case of advances against shares, the stocks should be listed in the approved stock exchanges
and should be freely traded. As the trading in shares are governed by the rules of Security and
Exchange Board of India (SEBI) and most of the shares are held in demat form instead
physical form, banks stipulate higher margin and also take care to register their interests (lien)
with the depositories who maintain the demat accounts.
6.4 CASH OPERATIONS
The banks accept/dispense cash in respect of their customers for different types of transactions
like savings, current and deposit accounts and also for purchase of demand drafts, gift cheques
etc.
Banks follow different methods of recording cash entries. Some banks make direct entries into
the system while some maintain physical registers. The control procedures need to be
evaluated.
The facility of remitting cash for purchase of Demand Drafts (DD), Telegraphic Transfers
(TT), Government transactions are available to the non-customers also (called as walk-in-
customers).
Facility to customers to deposit/withdraw cash at a different branch is available in a core
banking solution (CBS) environment, as part of ‘anywhere’ banking.
Exchange of soiled/mutilated currency can be made through the bank subject to note exchange
regulation rules.
The cash of the branch would be at the vault or with head cashier and tellers.
There are procedures to be followed for moving cash from the vault to the head cashier and in
turn to the tellers at the beginning of the day and shifting the cash balance at the end of the day
to the vault.
The tellers limit for dispensing cash is based on the size of the branch. For the amounts
beyond that limit, authorization for payment by higher authorities is required.
A cash holding limit for every branch of a bank is fixed which is based upon the size/need of
the branch.
Any excess cash balance is to be remitted to the bank’s currency chest/other branches/other
banks, as security risk is involved and also such cash will not earn any interest. However, this
can be verified only manually.
6.5 CLEARING
Normally the customers

• Deposit cheques issued in their favour drawn on banks/branches.
• Issue cheques from their accounts to others who may deposit the same in their account with
other banks/branches.
In both of the above cases, it is not possible to physically present such instruments directly to
the concerned banks.
Through a system in place, all the banks conduct clearing operations of cheques
(receive/deliver) through a bank nominated by Reserve Bank of India (RBI).
All the banks maintain their accounts with the nominated bank wherein the difference in the
value of the cheques are credited/debited.
Reserve Bank of India (RBI) acts as the nominated bank in main cities and it may nominate a
particular bank in other smaller cities for the purpose of clearing. These are also called as
service branches.
6.5.1 Outward Clearing
The cheques/DDs/POs deposited by the customers of the bank are entered in the system which
is done by batch processing.
All the details such as account type, account name, account number, name of the bank and
branch drawn on, instrument number, date and amount are entered in the system.
The banks branches, then present these instruments to the clearing house through the bank’s
link office.
After their account is credited with net of returned instruments, the bank’s branches release the
credits to the concerned customer’s accounts.
6.5.2 Inward Clearing
The cheques issued by the customers from their accounts maintained in the bank will be
presented by other banks/branches through the clearing house to the bank’s link office, i.e.
service branch.
The instruments drawn on the concerned drawing branch are received from the link office
after the debit of the drawee bank branch account.
The branch verifies the instruments for correctness and then debits the relevant accounts
depending upon availability of funds in the accounts.
The instruments which are not in order (stale/post-dated cheques/incorrectly drawn, want of
funds) are then returned to the banks through the link office.
6.6 MASTER MAINTENANCE
The core banking solution (CBS) or any software would need to have Master Data.
For instance, in a pay roll software, there would be Master Data for each category of
employees. The basic salary, allowances etc. for that needs to be created so that it is
permanent and is accessed and referred to by all entries for which the Master Data is
applicable.
In case of core banking system (CBS), there could be a parameter for interest application in
the software. This could accept two values, either interest earned or interest paid. For
different products like savings, deposits, loans etc. there would be different interest rates.
There could also be a parameter for interest type which could be either simple or compound
interest.
There could be interest application frequency which could be monthly, quarterly, half-yearly
etc.
The interest application module will work based on all the above-said parameters. Different
parameter values give different outputs.
Thus, it is evident that apart from the way the system is designed, the functioning of the system
is also largely influenced by the parameter settings assigned.
It is important that these parameters are entered in the system with due care.
Some of these parameters might require regular updations like interest rates, charges etc. as
per the business requirements.
The parameterization entries are entered by one individual and authorized by another.
The following are some of the critical parameters used by a Core Banking Application:
(a) List of holidays: There can be no operations on the computer during holidays.
( b ) Authorization rights for exception transaction: This will ensure that whenever
exception transactions are entered/generated, it will not be further processed unless those who
have the right to authorize have done so.
(c) Deposit type maintenance: The list of deposit products available with the bank and the
details regarding interest rate, tenor etc.
(d) Recurring Deposit (RD) penalty master maintenance: In case Recurring Deposit (RD)
installment is not paid on due date, the penalty interest rate that needs to be levied.
(e) Operational parameters
• Account type wise operational parameters
• End of Day (EOD) parameters
• Tax Deducted at Source (TDS) parameters
• ATM parameters
• Anywhere banking parameters
(f) Charges parameters
• Standing instruction charge
• Stop payment instruction charges
• Chequebook charges
• Account closing charges
(g) User related parameters
• Password change parameters
• Signing into the system
• Signing off from the system
(h) Interest related parameters
• Term Deposit interest rate parameters
• Interest calculation for advances
• Interest calculation for staff loans
• Interest calculation for senior citizens
(i) Authorization parameters
• Authorization of users
• Authorization for exceptional transactions
6.7 LOG MAINTENANCE
Logs are the records of activities or events that have taken place in the system across all
modules.
These give details about
• The activity
• Users, system
• Date and time
These logs provide important evidence to prove that a transaction occurred. It is important that
these logs are preserved properly.
Also these logs should be confidential and should not be modifiable as otherwise the very
purpose of the log is lost.
It must be ensured that logs are accessible only by the authorized persons.
6.8 BANK GUARANTEE
The bank guarantees are those issued by the banks on behalf of their customers in favour of the
third parties guaranteeing to fulfill the terms of the guarantee in case of any default/non-
performance of the contract entered into by the customers with the third parties.
Normally, the guarantees are classified as performance and deferred payment guarantees. The
customers approach their bankers for the issue of guarantees for purchase of goods,
machineries, etc. and also for receiving their dues after executing the contracts.
For the issue of guarantees, the banks stipulate certain margins and also collaterals depending
on the creditworthiness of the customers and business requirements.
The banks collect commission for issue of the guarantees depending on the period of the
guarantee and also the claim period.
The period of guarantee will also cover the claim period within which the claim, if any should
be made.
6.8.1 Performance Guarantees
The various government departments and certain other organizations seek issue of guarantees
as per their required format. The terms of the guarantee can be invoked in case of non-
performance. The banks are required to have these formats approved by the banks’ legal
adviser for any onerous clauses so that the banks may not face any problems if their guarantees
are invoked and claim made.
6.8.2 Deferred Payment Guarantees
Deferred payment guarantees are those which are issued by the banks for their customers to
enable them to purchase machineries and equipments on a medium or long term basis.
The customers and their suppliers enter into an agreement wherein the suppliers agree to
supply the machineries, subject to the customers furnishing a guarantee from their bankers
towards the cost of the machineries in case of any default by the buyers.
The customers have to meet their commitments over a period of time by way of accepting the
Hundi bills drawn payable on different dates which may even extend over a period of 10
years or more, duly guaranteed by the bank.
The customer has to furnish a counter guarantee in favour of the bank undertaking to meet the
liability if guarantee is invoked.
If the beneficiary invokes the guarantee for non-performance/payment and if the customer fails
to meet the liability created, the bank will debit the defaulted account and make the payment
(up to the value of the guarantee) demanded by the beneficiary.
The bank recovers the defaulted guarantee amount from the customer along with the prevailing
interest.
6.9 BILLS
Bills involve genuine trade transaction and may be classified as follows:

• Clean Supply Bills: Clean supply bills are those in which the goods are sent directly by the
drawer (customer) to the drawee and delivery receipt duly signed by the drawee for having
received the goods, and the invoice are deposited by the customer to his bank and the bank
sends the bill to their branches for collection.
• Demand/Usance Bills: These demand/usance bills are also commercial transactions by
nature and are payable on sight/usance and the same procedure as for supply bills are
followed.
There are four parties involved in a bill transaction, viz. drawer, drawer’s bank, drawee and
drawee’s bank.
The drawer (supplier) raises a bill covering dispatch of the goods along with transport way
bill (railway receipt, lorry receipt, shipping bill and air bill) and presents the documents
through his banker for payment.
The drawee retires the bill on demand or after the usance period and his banker makes
payment of the proceeds of the bill to the drawer’s bank.
The customer’s account is credited with the proceeds of the bill after recovery of the
commission and interest (in case of bill purchase).
Some of the customers who are involved in the trade/manufacture activities approach bank for
sanction of various limits which may include bills purchase facilities.
The banks sanction credit facilities by way of bills purchase to their customers based on their
requirements and feasibility. For these, the banks offer immediate credit up to the limits
sanctioned and collect the commission and the applicable interest.
6.9.1 Outward Bills (Cheques)
Customers deposit the up country cheques in their account for collection/purchase.

Cheques issued favoring the customers are sent by the bank to their up country branches and in
case the bank is not having a branch, these are sent to the drawee bank.
The collection proceeds on realization are credited to the customer’s account, net of
collection charges.
Facilities for immediate credit of the cheques deposited for collection are available from the
banks based on the credit appraisal and the need of the customer.
6.9.2 Inward Bills
The up country banks/branches send the cheques/bills drawn on the customers for collection
and the cheques are debited to the customers account subject to the availability of funds and
the proceeds are remitted to the drawer bank.
In case of bills, the bank sends intimation to their customers for having received the bills
drawn on them and with an instruction to retire the same as per the terms and conditions
stipulated by the drawer (charges, demand and usance).
The customer pays the bill amount and receives the documents, viz. invoice and transport
documents.
6.10 LETTER OF CREDIT
Letter of credit means any arrangement whereby a bank (issuing bank) acts on the request and
on the instructions of a customer (applicant). The instructions would include:
• to making payment to or to the order of a third party (beneficiary), or accepting and paying
bills of exchange drawn by the beneficiary; or
• Authorising another bank to effect such payment, or accepting and paying such bills or
exchange; or
• Authorising another bank to negotiate against stipulated documents provided the terms and
conditions of the credit are complied with.
The customers who are engaged in the manufacture/trade approach bank for opening letters of
credit for purchase of goods/machinery etc. with which supplier is willing to execute the
order subject to the customers’ bank assuring payment by way of letters of credit.
Letter of credit can be revocable or irrevocable based on the requirements of the
customer/supplier.
Beneficiaries in some cases may insist for confirmation of the Letter of credit by a different
bank called the confirming bank.
A confirmation of an irrevocable credit by another bank (confirming bank) upon the
authorization or request of the issuing bank, constitutes a definite undertaking of the confirming
bank in addition to that of the issuing bank.
Letters of credit can be opened for supply on sight/usance basis and terms and conditions as
per the agreement with the suppliers.
The customers can opt to have cash credit/term loan limits for covering the bills drawn under
letters of credit.
In case of letters of credit (foreign), the customer is expected to have to importers/exporters
code allotted by the Reserve Bank of India (RBI).
The shipping terms (viz. Trans-shipment, part shipment) and documents required (Invoice,
certificate of origin, shipping, insurance, and any other documents as the case may be) are
incorporated in the letters of credit established.
The letters of credit so opened should be accepted by the supplier for the correctness and if
any amendments are required, it should be informed to the issuing bank to carry out necessary
amendments.
All requirements for business process would need to be the contents of the different screens of
the particular module.
6.11 REMITTANCES
The process involves remittance of money by way of demand drafts and mail transfers drawn
on upcountry branches and only where the banks are having their branches, at the request of
the purchasers (customers and non-customers).
The remittance can be by way of bankers cheques where the branches of the banks are situated
locally. This type of transfer of money is named as remittances under banking jargon.
The remittances so made are paid to the payee at the paying branch.
Normally, the remitting banks dispatch advices for having emanated the transactions
(applicable in case of non-CBS branches to CBS branches and vice versa). In case of CBS,
this will be inter-branch transaction.
If the demand drafts are presented before the advices are received, the paying branches pay
and then debit the ‘Demand drafts paid without advice’ and this head is reversed as soon as
advices are received.
The transactions are reported in the Inter branch daily report both by the issuing and paying
branches and the reconciliation of the entries are carried out. The pending entries are
followed up for reversing the same.
The banks collect exchange for issuing these remittances as per the guidelines of their
corporate office.
As per the present Reserve Bank of India (RBI) guidelines, remittances by way of CASH are
restricted to Rs. 50000 including the exchange and any remittance over and above this amount
can be done only through the customers’ account.
Thus, non-customers cannot apply for a CASH DD/MT/TT/BC in excess of Rs. 50000.
6.12 STOCK MAINTENANCE OF NEGOTIABLE INSTRUMENTS AND OTHER

NUMBERED INVENTORY
Banks are expected to maintain a record of all security items like

• chequebooks
• demand draft receipts
• term deposit receipts
• any other numbered items
Bank branches enter all such numbered items in their stock book (maintained by the system in
CBS) as and when it is received from their central office. Alternatively in certain banks which
have implemented CBS, stock details are entered by the central office prior to despatch to
individual branches.
These in turn are issued to the concerned departments/customers under written
acknowledgment after making the necessary entries in the stock register and corresponding
customers’ account.
At any point of time it should be possible to tally the physical balance of this secured data
with the stock balance shown in the system.
6.13 DEPOSITS
The deposits are classified as

• Demand
Overdue deposits (matured but not returned)
Exchange earners foreign currency deposits
Margin on deposits (margin money paid by borrowers for credit facility)
• Term deposits
Fixed deposits
Recurring deposits
Re-investment plan
Daily collection deposits
Interest is payable on the above-mentioned deposits based on the period and type of deposit.
Payment of monthly interest option is also available but only at a discounted rate.
Customers can also open recurring deposits wherein a fixed sum is deposited every month
over a period of months/years as per the requirements. The interest along with the principal is
paid at the end of the maturity period.
The senior citizens and the bank staff enjoy additional interest benefits.
The opening of deposit accounts by the non-residents are governed by the RBI/Foreign
Exchange Management Act (FEMA) guidelines.
The balance available in their non-resident external accounts is freely transferable outside
India.
Banks deduct tax at source depending upon the prevailing approved rates of the Government.
Customers can avail maximum loan/overdraft against their deposits, net of the margin
stipulated by the bank. In such cases banks mark lien over the deposits and adjust the loan
from the proceeds of the deposit or release the deposit receipts once the loan/overdraft is
closed by the customer.
The deposits can be closed prematurely if the customer so desire and the appropriate interest
is payable only for the period the deposit was with the bank and not for the original period of
deposit.
Residents in India/exporters (export-oriented units, export promotion zones, software
technology park and other permitted units) can open Exchange Earners Foreign Currency
(EEFC) deposit out of the receipts from exports and professional services subject to the limit
prescribed under this scheme by RBI.
Eligible credits represent inward remittance received through normal banking channel.
The Exchange Earners Foreign Currency (EEFC) deposits can be utilized to repay packing
credit advances (exports) whether availed in Rupee or foreign currency.
For EEFC deposits the account is opened as non-interest bearing and non-credit facilities
(fund based and non-fund based).
The system should comply with the current government regulations.
6.14 ADVANCES
The banks collect both demand deposits and term deposits and out of the same they are
expected to maintain Statutory Liquidity Ratio (SLR) and Cash Reserve Ratio (CRR) with the
RBI and out of the balance available they lend to priority and non-priority sectors.
• Priority sectors:
• Agriculture
• Small scale industry
• Small transport operators
• Small business enterprises
• Government sponsored schemes
• Exports
• Housing (under National Housing Bank)
• Non-renewable energy
• Non-priority sectors:
• Consumer loans
• Transport
• Real estate
• Large and medium scale industries
• Housing
• Wholesale traders
The advances are made to entities in India both in local currency and also in foreign currency.
The loans are classified as unsecured (clean) and secured advances. The secured advances
are those backed by securities (primary and collateral).
The primary security is one where assets are created out of the loan amount and collateral
securities are those which are obtained by the banks in addition to the primary securities.
These securities are charged to the bank by way of lien (e.g. bank deposits), hypothecation and
pledge (e.g. stocks, goods, vehicles, plant and machinery) and mortgage (e.g. immovable
properties).
Drop down menus/list of values will be available in the system to choose the nature of charge
on the securities.
Maker checker concept is required to execute the process.
In the event of the advances becoming bad and doubtful of recovery the banks fall back upon
these securities to realize the dues.
In addition, the banks also have the right of general lien over the assets even if they are not
charged to them.
Activating the Branches

7.1 INTRODUCTION
The data center is a central place and the branches need to be connected to the data center. When core
banking solution is implemented in a bank, it would already have existing branches running on Total
Branch Automation (TBA) or new branches may be opened in new areas. In either case, the
concerned branch would need to get connected to the Central Data center. In the case of existing
branch the data of the existing customers would need to be migrated, after ensuring that it is complete
and correct, to the centralized database.
The steps, when initially core banking solution is being implemented, would be as follows:
1. Core banking solution installation

2. Training of core team
The team will consist of senior experienced staff with a thorough knowledge of banking processes.
This team will participate in customisation. Customisation would include all areas of input, process
output and also generation of reports. Customisation is a process wherein the software as provided by
the vendor, is modified wherever necessary to suit specific additional requirements of the bank. This
team will freeze the specification for the CBS. Eventually, this team will participate in the acceptance
testing. (Final testing of the software before it can go live.)
The above-mentioned process of customisation and testing is very critical and is an important
phase. After the completion of these processes, data migration and implementation process is
commenced.
The process of migration could be broken into the following phases.
Core team training

Gap analysis
Identification for customisation
7.2 CLEANING THE BRANCH DATA

It is a process of mapping the data in the branch to the data as required by core banking solution
(CBS).
7.2.1 Database Requirements

Some existing data may not be as required. These will be separated and posted into an intermediary
account called by different names.
The intermediary account is reviewed repeatedly and brought to NIL balance. This iterative
process of ‘Cleaning’ the accounts would go on till it is NIL balance or till reasonably low volume is
reached. This account would be frozen. No subsequent entries would be passed at the branch level.
This will be dealt with at the central office till all points are sorted out and the account balance is
NIL.
The detailed aspects to be considered while performing data migration would be as follows:
1. Customer data migration: All the existing individual customers and corporate customers,
having either one or more accounts along with the linkage of deposits/loans are to be
migrated.
2. Account migration: All existing savings bank accounts, current accounts, cash credit accounts
and overdraft accounts linked with valid customer IDs need to be migrated with a few
exceptions, if any.
3. Deposit migration: All deposit account details need to be migrated along with instalments
paid and unpaid details. It should also include details regarding interest applied, interest
liquidated, the tax deducted at source etc.
For all deposit accounts for which TDS has been applied, such details along with the date of
such deduction need to be migrated.
Details of deposits overdue for renewal should be migrated for application of correct interest.
4. Loan migration: All live loan accounts properly linked to a valid customer ID are to be
migrated. For all loan master details successfully migrated, the following further details also
need to be included:
• Loan instalments/EMI collected, not collected
• Interest amount due and interest amount paid
• Arrears and overdue repayments
5. Bills migration: All pending bills—Outward Bills Collection (OBC), Inward Bills Collection
(IBC) and Usance Bills Collection (USB) which have linkage to savings bank accounts,
current accounts, cash credit accounts and overdraft accounts need to be migrated. Contra
entries are also to be migrated.
6. Bank guarantee/letter of credit: All pending Bank Guarantee (BG)/Letter of Credit (LC)
amounts which are linked to savings bank accounts, current accounts, cash credit accounts and
overdraft accounts need to be migrated.
7. Chequebook issue migration: All savings bank accounts, current accounts, cash credit
accounts and overdraft accounts for which cheques have been issued need to be migrated.
8. Cheques ‘stop payment’ migration: All stop payment instructions for cheques issued need to
be migrated.
9. Cheques status migration: Status of issued cheque leaves/books are to be migrated.
10. Transaction data migration: For all successfully migrated savings bank accounts, current
accounts, cash credit accounts and overdraft accounts, deposits and loans, balances as on the
date of migration are to be migrated.
11. Remittance issue migration: All DD, pay orders issued for the last six months are to be
migrated.
12. Remittance advice migration: Pending Demand Drafts (DDs) payable, Demand Draft Paid
Without Advice (DPWA) pending as on the date of migration are to be migrated.
13. Stock statement migration: For all Open Loan Cash Credit (OLCC) accounts successfully
migrated, default stock statement as on the date of migration with a drawing power to the tune
of 100% of the limit will be migrated. This would be corrected later at the front end to come
in line with the exact drawing power entered after the migration is completed.
14. Savings bank minimum balance migration: For a savings bank account successfully
migrated, savings bank minimum balance as on the date of migration is to be migrated.
15. Limit migration: For all bills, bank guarantees, letter of credits, customer’s limits are to be
migrated based on customer ID as no limit is required to be migrated for cash credit, overdraft
accounts.
16. FTF Related: All foreign currency related transactions, may not be migrated as the same may
be separately migrated at the time of Foreign Trade Finance (FTF) migration.
As part of the migration, the branch at the minimum has to ensure the following
Customer ID creation and account linking is over.

There is no duplication in customer ID.
Details such as signatory, nominee are correctly entered.
Account and product classification is over.
All individual head-wise balance are tallied with general ledger.
All balance breakup details tallied with general ledger.
Signature scanning and attachment is over.
The balance is zero in temporary parking heads.
Once the branch is ready for migration in all aspects, the data as obtained from the branch will be
taken for a test run. A mock migration is arranged at computer systems department for confirmation
that the branch may be taken for migration.
CSD has to ensure that there are no problems in file format changes. It has to be further ensured that
the extracted data is correct in all respects. This is done by verifying the pre-migration general ledger
with that of the extracted general ledger.
While in the process of migration, it would be useful to have exception reports being generated to
facilitate correct and complete migration.
A suggested data migration exception reports list is as follows. It is illustrative only and not
exhaustive.
1. Customer ID not created list

2. Account not linked to customer ID list
3. Invalid deposit opening date list
4. Invalid deposit maturity date list
5. Invalid customer date of birth list
6. NRE customer detail mismatch list
7. CCOD/LOAN limit mismatch list
8. Loan period mismatch list
9. Bill detail mismatch list
10. Deposit period mismatch list
11. Demand Draft/Pay Order (DD/PO) mismatch list
12. Deposit interest mismatch list
13. Deposit last interest date mismatch list
14. Deposit next interest date mismatch list
15. Number of legal person mismatch list in case of corporate
customers
16. Master/transaction mismatch list
17. RD/loan instalment mismatch list
18. Interest payable pending without principal amount list
19. Over Draft/Temporary Overdraft (OD/TOD) account with 0% interest list
20. Loan/Cash Credit/Over Draft (CC/OD) last interest date mismatch list
21. Loan/CCOD next interest mismatch list
22. Chequebook detail mismatch list
23. Bill amount/bill outstanding mismatch list
24. Deposit interest provision not done list
25. Deposit amount and interest applied mismatch list
26. ATM card detail mismatch list
27. ATM card data and switch data mismatch list
28. Deposit amount and deposit balance mismatch list
29. EMI/equal instalment detail mismatch list
30. Signature scanning non-availability list
31. Bank Guarantee/Letter of Credit (BG/LC) detail mismatch list.
7.3 BRANCH TO ENSURE CORRECTNESS OF MIGRATION

After migration, the branch has to ensure headwise balance with Trial Balance/GL and to ensure that
the same are tallied with the Trial Balance/GL. The branch, through the front end reports has to
randomly verify deposit maturity date, maturity value for all types of deposits, RD accounts, CCD
accounts, etc. to ensure the correctness of the data migrated. The branch has to check stop payment
cheques are migrated. The branch has to check that the account limit, rate of interest and limit due
date for all CCOD/loan accounts are correctly migrated. The branch has to check whether freezing of
account, NPA marking, lien marking, drawing power are correctly migrated.
7.4 ADDITIONAL MIGRATION CHECKLIST

The following checklist may be adopted for smooth data migration process:
1. Deposit amount and interest rates should be within the Min and Max permissible deposit
amount as defined in product parameter.
2. Last and next interest accrual/application date
3. Next interest fixing date should be greater than or equal to next interest credit date.
4. Next interest fixing date should not be greater than the maturity date in case of cumulative
deposits.
5. Interest committed to the depositor at the time of opening should be taken care of.
6. Total applied/settled interest should be taken care of.
7. Mandate for receipt/payment of interest to be given effect only if such accounts are already
migrated.
8. Number of paid instalment in case of Recurring Deposit (RD) and loans has to be checked.
9. Non-Performing Assets (NPA) details need to be manually uploaded. (Protested bills—suites
filed and decreed; Principal and memorandum of interest; security details; NPA classification
—substandard, doubtful and loss assets)
Compatibility of fields
Fields additionally provided or available in the core banking solution (CBS) after migration and not
required to be masked.
Transaction listing
Transaction listing is to be uploaded in case of bills and inter branch transactions, while making sure
that the listing of transactions is available at the branch in the legacy database.
Bills migration
Bills/cheques discounted, due date, accrued interest, particulars are to be migrated.
Inventory
On hand stock of all numbered items like cheques/DDs are to be migrated.
Clearing
Pending clearing details of all instruments are to be migrated.
Permanent Account Number (PAN)
Permanent Account Number (PAN) details are to be migrated, wherever it is mandatory.
As a parallel activity, technical personnel need to verify the network connectivity of the branch to
the central data center. The details as mentioned in Annexure A of this chapter need to be collected.
Tests as mentioned in Annexure B need to be performed.
ANNEXURE A
BRANCH ACTIVITY ACCEPTANCE REPORT
BRANCH DETAILS
Branch Name ................................................

Address
.
.
.
.
.
Phone ................................................
Phone ................................................
Manager (Mobile and Residence)
................................................
.
WAN EQUIPMENT DETAILS
Item Model/Description Serial No
Router ............................. .............................

Leased line Modem ............................. .............................
ISDN NT1 ............................. .............................
Switch ............................. .............................
.
ROUTER HARDWARE CONFIGURATION DETAILS

Ports Used Free
Serial (WAN) Ports ............................. .............................

ISDN Ports ............................. .............................
Ethernet ............................. .............................
WIC/NM Slots ............................. .............................
.
LEASED LINE AND ISDN LINE DETAILS
Leased Line Service Provider ................................................

Leased Line Circuit No. ................................................
Leased Line Bandwidth ................................................
MLLN/non-MLLN ................................................
ISDN Service Provider ................................................
ISDN No. ................................................
.
TCP/IP CONFIGURATION DETAILS
Branch LAN IP Address Range ................................................

Router LAN IP and Subnet Mask ................................................
Switch LAN IP and Subnet Mask ................................................
Router Serial IP and Subnet Mask ................................................
ANNEXURE B
RESPONSE TIME TESTS—NEXT HOP ROUTER
1. Ping test with packet size of different bytes
Command: ping -t <next hop nodal router IP>
Sl. No. Source IP Destination IP Response Time Acceptance Value
Machine 1
Machines 1 and 2
Machines 1, 2 and 3
Response Time Tests—Central Data Center Router

1. Ping test with packet size of different size of bytes
Command : ping -t <next hop nodal router IP>
Sl. No. Source IP Destination IP Response Time Acceptance Value
Machine 1
Machines 1 and 2
Machines 1, 2 and 3
Leased Line Error Tests

Step I: Clear Router Interface Counters
# clear counter interface se0/0
Step II: Record the CRC counter values of the router serial interface in
Table 7.1
# clear counter interface se0/0
Step III: Download the 2MB file from the following URL
http/xxx.xx.x.x/downloads/test.zip
Step IV: After download is completed, record the CRC counter values of the router serial interface
(see Table 7.1)
# show interface se0/0
Table 7.1 Recording CRC counter value
Interface Reading CRC Errors Reliability Collision Late Collision
Serial 0/0 After clear counters
Serial 0/0 After file downloads
Ethernet After clear counters
Ethernet After file downloads
After clear counters
After file downloads
ISDN Fallback Test

Step I: Start continuous ping from a PC ping - XXX.XX.X.X.
Step II: While ping is running, switch off the leased line modem.
Step III: After few timeouts, the ping should continue through ISDN.
PASS FAIL
Step IV: Terminate the ping. Monitor ISDN link in the router.
# show isdn active
Step V: The ISDN link should get disconnected after the configured idle time out period of ___
seconds.
PASS FAIL
Step VI: Start ping test again, ISDN link should come up automatically.
PASS FAIL
Step VII: While ping is running, switch on the leased Line modem.
Step VIII: The ISDN Link should go down after few seconds. Ping should continue now through
leased line.
PASS FAIL
ROUTER CONFIGURATION
<ATTACH ROUTER CONFIGURATION>
ATM Functionality—
How It Works
8.1 INTRODUCTION
Automated Teller Machine (ATM) is a computerized telecommunication device that provides the
customer of a financial institution with access to financial transactions in a public space without the
need for a bank teller.
8.2 ATM CARD ISSUE PROCESS

The customer is identified by inserting a plastic ATM card with a magnetic strip. The card contains a
unique number and some security information, such as expiration date.
Security is provided by the customer entering a personal identification number (PIN).
An ATM card is issued only to an existing customer who belongs, basically to a bank. The
customer, who wishes to avail of the facility, is provided an application form by the branch.
The filled up form is forwarded with authorization by the concerned branch manager to a central
office of the bank to be dealt with by ATM card issuing department.
8.2.1 Procedures for Issuing ATM Card

At ATM card issuing department following procedures are followed before the issue of an ATM
card:
The name, account number and other details as entered in the form are keyed into a computer at a
department in the central office. This computer has application software loaded which has the
following functionalities:
1. Read the details in application form.

2. Check whether they tally with corresponding data in the database (there is a customer
database in the core banking solution (CBS) database).
3. After the data in the application form tallies with the CBS database, the application is
processed:
(a) The output consists of a file containing data for preparation of an ATM card
(b) Personal Identification Number (PIN) generated (is not stored in memory) and directly
sent for printing PIN Mailer and immediately erased from the memory.
(c) As a concurrent process, natural PIN is generated and stored in the database of ATM
switch. There may be different methods of generating a natural PIN. One of the methods is to
encrypt the card number. The encrypted value is decimalized and the first four digits of the
value is stored. The first four digits is called ‘Natural PIN’.
This value is deducted from PIN which results in generating offset value. Anytime the natural PIN
is added to offset value, PIN of the customer will be generated.
The PIN is not stored in the ATM machine or ATM switch. Only the offset value is stored in ATM
switch.
Natural PIN is derived from ATM card number and the summation of the above two is the PIN of
the customer (see Figure 8.3).
The card issuence process is depicted in Figure 8.1 below.
Figure 8.1 Procedure for issuing an ATM card.
8.2.2 ATM Operations

The Automatic Teller Machine (ATM) generally performs the following functions:
Cash withdrawal
Balance enquiry
Mini statement of account
Registering request for cheque book etc.
Personal Identification No. (PIN) change
Network architecture of ATM

An ATM may be connected to a bank branch and situated within the office of the branch. Also an
ATM may be situated anywhere—marketplaces, petrol bunks, on the road side. A sample ATM
network has been shown in Figure 8.2.
Figure 8.2 Structure of an ATM.
All of the ATMs are connected to a switch and the switch is connected to the server of the bank
through internet connection. A switch is also a server.
The ATMs may be connected to the switch by any of the following means:
Leased Line
VSAT (Very Small Aperture Terminal)
Dial Up Line
A single database of all of the customers of the bank is stored in a database server located in the
data center of the bank.
It is possible by arrangement that an ATM of Bank-A could be used not only by the customers of
Bank-A, but also of banks-B and C etc.
The banks which provide facility for the customers of multiple banks would have executed an
agreement to provide such facility. There would be bilateral agreements so that switches of
participating banks are linked. The service at the switch may be provided also by a third party switch
service provider.
Brief description of the functioning of the ATM
Step 1: A customer who has been provided with an ATM card swipes the card through the specific
place provided in the ATM hardware. The information provided in the magnetic strip is read by the
machine.
Step 2: The customer has to key in, his Personal Identification Number (PIN).
Step 3: The PIN which is a very sensitive data is encrypted. The encryption process may be by
means of a hardware (also called as PIN machine) or software which forms part of the ATM. The
Security Model (Hardware Security Model—HSM or Software Security Model—SSM) encrypts the
PIN by means of an encryption algorithm loaded into the machine by the officers of the bank when the
ATM is commissioned to ensure that security of the algorithm is maintained. The banks generally
ensure that it is performed by two the officers of the bank—one officer performs one part of the
function and the second officer performs the balance of the function.
Step 4: When the account number and PIN provided by the customer tally with the data available at
the database of the switch and the PIN generated by the PIN machine, the customer who swiped the
ATM card is authenticated as a genuine customer of the bank. It needs to be noted that any person who
picks up an ATM card would not be able to initiate an operation unless he also has information about
the PIN associated with the card.
Step 5: The switch having authenticated the customer, passes on the information through the
communication line to the database of the bank which is held in the server of the bank. This operation
is to ensure that the authorized customer has sufficient balance in his account to perform the operation
which he desires to do, e.g. cash withdrawal.
The customer would have mentioned the amount he wishes to withdraw by giving the data at the
ATM. The ATM switch passes the data to the database server which in turn would authorize
dispensation of cash required as the customer has the requisite balance.
The operation of activating the cash dispenser is triggered by the facility available at the ATM
switch. Then the cash is dispensed to the customer who picks up the required cash.
Step 6: Once the cash has been picked up by the customer, the reverse process would take place by
which the ATM switch has information that the cash has been dispensed and from the switch, the
information is passed on to the database.
Step 7: At the ATM, cash journal and ATM log are generated. These are the important documents
used for the reconciliation purposes. Also there are electronic journals which are generated at the
ATM. These can be accessed and retrieved from a remote location through a process called as
Electronic Journal Pulling (EJP).
Step 8: Inter Bank Transactions—While the process is similar, it is to be observed that soon after
the ATM card is swiped by the customer, information is available as to which bank the card belongs
to, and hence, is directed to the ATM switch of the corresponding bank. The process of authentication
and authorization would be similar. The database of the card issuing bank would be accessed and
information sent back to the ATM for completing the operation of cash dispensation.
In case, ATM reports error, e.g. the cash may not have been taken out by the customer in time, (in
such a case, the cash is pulled back into the machine) the ATM would report the error. The switch
would request the host for reversal of entry. The switch and the host computer log all the events (see
Figure 8.3).
Figure 8.3 PIN generation process for new ATM cards.
PIN Verification Process

Following is the process through which the customer’s PIN is verified:
1. Customer inserts card and types the PIN.

2. PIN is sent to the ATM switch in encrypted form.
3. ATM switch validates the card number with the card number already in the database.
4. From the card number, natural PIN is generated.
5. First time round the offset value (the difference between PIN and natural PIN) is stored in
ATM switch. Subsequently, whenever a customer inserts his ATM card and types PIN, it is
verified by the system by adopting the following process:
• The system has offset value stored.
• When card is inserted, the card number is encrypted and decimalized and natural PIN is
computed.
• By summing up the offset value already available in the system with the natural PIN, the
relevant PIN is generated within the system.
• This generated PIN is compared with the PIN typed with the customer to authenticate the
customer.
6. If the result of step ‘5’ above is positive, i.e. the two numbers tally, the PIN machine sends a
positive acknowledgment to ATM server to indicate that the customer is authenticated (see
Figure 8.4).
Figure 8.4 ATM card authentication.
It should be noted that only by knowing the PIN of a customer one cannot access the machine unless
he inserts the ATM card of that customer. If card and PIN, both are available to a third party, misuse
is possible.
Change of PIN by customers
When customer wants to change the PIN, he has to convey the fact that he plans to change the number
by pressing on the Key pad—‘Change No.’ He will be expected to give the old PIN and then only key
in the new PIN. When he keys in the old PIN natural PIN is generated and card number compared
with that stored to satisfy itself that he is an existing ATM card holder. The corresponding offset
value is pickedup and internally the existing PIN of card holder is generated. This is compared with
the PIN keyed in by the customer before asking for a change. When they tally, the customer is
permitted to key in the new PIN. As the natural PIN value is available, new offset value is computed
and old offset value is erased. The old PIN or the new PIN should not be stored anywhere.
Confirmation of natural PIN generated from the card of customer and new offset number would be
the basis for generating the customer PIN for comparison with the PIN keyed in by the customer.
Special circumstances: When ATM may not be operational:
1. Cash may be inadequate.

2. Journal paper roll may not be available.
3. ATM kiosk may be not in an operating condition.
8.2.3 Monitoring Process at the Central Office

There is a monitoring office at the ATM cell in head office. All of the ATM machines are monitored
at the central place so that information is available about the non-performance of any ATM kiosk
along with the reasons for the problem.
If there is a hardware problem the monitoring team contacts the vendor of the hardware, who
would act according to the service level agreement entered into with him and take necessary
steps to put the machine back in action.
If cash is inadequate, either the branch manager (if the ATM is connected to the branch) or an
independent cash loader who is responsible for loading the cash would be intimated about the
inadequacy of cash to facilitate immediate action being taken to load the cash at the ATM
kiosk.
If the journal paper roll has been exhausted, necessary steps will be taken to replace the used
up paper roll with a new paper roll.
In case of use of a card, a cardholder is expected to key in his Pin. If he makes a mistake, he gets
three attempts altogether to do it correctly. However, after the third attempt the card is rejected.
A customer might lose a card or his card might have been stolen. He would have informed the
concerned bank and it would have been hotlisted, i.e. to say that the card would not be accepted if
ever presented. However, if a person who has stolen the card or a person who is wrongly in
possession of the hotlisted card inserts in the ATM machine, it will be swallowed by the machine.
8.2.4 Other Procedures at the ATM

Journal paper roll
There is a paper roll fitted at ATM which records all cash transactions. These paper rolls need to be
retained carefully as required by the law. If the roll journal is exhausted or it does not operate, ATM
will cease operating. There is no possibility of ATM functioning without the transactions being
recorded.
Cassettes
The cash is loaded into the cassettes under supervision of two officers. This process may be
outsourced.
If wrong denominations of cash are loaded, especially when higher denominations are loaded in
lower denomination cassettes, there would be cash loss to the bank. These aspects have to be spelt
out clearly in the Service Level Agreement with the cash loading agencies.
There would be maintenance of records of cash loaded into the cassettes.
Rejected notes in bin
When cash is not picked up within a stipulated time, it will get rejected into a bin. The cash in the
rejected bin will be counted in the presence of two officers and considered when cash reconciliation
is done.
Encryption
The dual access controls are required to enable the key encryption to function. The storage
arrangements for all Hardware Security Model (HSM) brass keys, passwords and other devices used
to enter the component values into the HSM need to be secured.
Some of the above procedures may vary and be bank specific.
Internet Banking, Real Time

Gross Settlement and
Cash Management System
9.1 INTRODUCTION
9.2 INTERNET BANKING—PROCESS
Customer applies to the bank branch for Internet banking facility. In most banks, this facility is
automatically provided when a bank account is opened. The customer is provided with user
ID and password and is advised to change the password soon after the first logon.
The customer using a browser (like Internet Explorer) accesses the website of the bank in the
normal course.
The website is hosted in the web server that is placed in a de-militarized zone behind a
firewall. The firewall filters all the traffic except that which are addressed to the web server
through the authorized port.
The web server displays the bank’s web page to the customer.
The web page has provision for customer to enter the user ID and password.
The user ID and password of the customer is encrypted and sent to the bank’s web server.
The web server forwards the customer details to Internet Banking Application Server (IBAS)
which authenticates the customer by verifying the user ID and password with the data stored in
the Internet Banking Application Server (IBAS).
Based on the authentication check, the Internet Banking Application Server (IBAS) sends an
acknowledgement to the web server which in turn informs the customer (in the browser).
If the user ID or password is not correct, an error message is displayed. After consecutive
failed login attempts (usually three), the bank freezes the customer’s internet banking facility.
The customer has to request the bank to re-activate the facility in some cases after a few hours
the facility is automatically re-activated.
Once the customer is logged in, Internet banking services offered by the bank are displayed.
The following are the Internet banking services provided by many banks:
(a) Balance enquiry
(b) Fund transfer
(c) Chequebook request
(d) Stop payment request
(e) Cheque status enquiry
(f) ATM/credit card related queries
(g) Password change
The customer chooses the service from the web page. The web server directs the service
request to the Internet banking application server for processing.
To process the service request, the Internet Banking Application Server will need customer
details which are stored in the central database server. The bank’s central database server
being a critical server can be accessed only through a firewall.
The Internet Banking Application Server (IBAS) sends the data requirement to the Internet
Banking Database Server (IBDS) which retrieves the data from the central database server
that is accessed through a middleware and a firewall. The middleware converts the data to
suit the requirements of the Internet Banking Database Server where the data is temporarily
stored.
The Internet Banking Database Server (IBDS) now sends the customer data to the Internet
Banking Application Server (IBAS) which processes the transaction.
After processing the customer service request, the Internet Banking Application Server
(IBAS) sends the details to the web browser.
The web server generates a dynamic web page for the service request and presents it to the
web browser in encrypted form.
The customer may choose to log out or perform any other transaction.
Once the customer is logged out, the customer’s session on the web server is closed and the
transaction details in the Internet Banking Database Server (IBDS) are purged.
The customer is advised to clear the cookies (cache) that were created and stored temporarily
in the customer’s system when the customer was logged on to his Internet banking account as
these contain confidential information. (To clear internet cookies, one may go to
C:\Documents and Settings\“Windows login name”\Cookies.)
It needs to be emphasized that if internet banking is not properly implemented, it could lead to
security issues ranging between privacy issues to wrong or fraudulent transfer of funds by
account holders.
A pictorial presentation of internet banking data flow has been shown in Figure 9.1.
Figure 9.1 Internet banking—data flow.
9.3 OBJECTIVE OF UTILIZING RTGS

The data flow diagram of RTGS is shown in Figure 9.2.
Figure 9.2 Real time gross settlement.
The objective of utilizing Real Time Gross Settlement (RTGS) is to the enable a customer
belonging to one branch of a bank (say Bank-A) to transfer funds to customer of another bank (say
Bank-B) on a real-time basis. This facility is also used to transfer funds between the banks.
This is possible only if both the banks are recognized as participant banks by RBI.
The transaction, which represents the amount a customer wishes to transfer through RTGS to
another account in Bank-B, is entered in the client machine at the Bank-A. The client machine is
connected to the server.
Each of the participant banks is allotted a code number—Indian Financial System Code (IFSC).
Similarly, each of the branches of the participant bank of RTGS is allotted a unique code (called as
RTGS branch code). A combination of these two codes act as the identification.
The transaction entered is transmitted to the bank’s focal point, where the Participant Interface (PI)
is located. The PI handles the creation and processing of inward and outward messages. The
messages are encrypted and transferred to the Inter Bank Funds Transfer Processor (IFTP) which in
turn transmits the same to the RTGS system at Reserve Bank of India (RBI).
From RBI, the message is transmitted to IFTP which is transmitted to the focal point of the recipient
bank where its Participant Interface (PI) is located. The message is transmitted from that PI to the
appropriate branch of that bank which would credit the account of the intended recipient. This whole
process takes place in ‘Real Time’. The transactions are handled individually. The transactions are
settled individually on a ‘Gross’ basis as against the normal clearing which happens on a ‘Net’ basis.
This briefly describes the Real Time Gross Settlement System.
Figure 9.3 shows a diagrammatic description of the flow of transactions. The figure includes more
details which are discussed in the paragraphs following the figure.
Figure 9.3 Flow of transaction.
The clearing entities to the banks participate in RTGS system for settling high volume payments.
The RTGS system, consists of, as we have observed, the following main components:
(a) Participant Interface (PI)
(b) Inter Bank Funds Transfer Processor (IFTP) at RBI
(c) RTGS system at RBI
(d) Communication system
(e) Encryption process of transaction.
The participant interface comprises of three modules at the server level as follows:
(a) Gateway module (GM) on GM server
(b) Outward Message Manager (OMM) on OMM server
(c) Inward Message Manager (IMM) on the IMM server
The Participant Interface (PI) client is a common front end for all three—OMM, IMM and GM.
Using the PI client, one can not only enter and verify messages but also perform enquires and generate
reports. It contains a tool—User Control Tool (UCT) available at the client which enables
configuration of the required parameters at the server.
The RTGS branches are connected through WAN to the RTGS focal points of the bank.
The PI server stores the user profile. User access is controlled vide user profile and smart cards (if
configured).
Smart card is a plastic card with a micro-processor embedded in it which contains the digital
certificate and encryption keys specially created for the user. Smart cards are used to verify a user’s
identity and to digitally sign messages sent by the user.
The profiles are retrieved, based on the user information and is displayed in the form of many
options in the PI client. All PI server modules run as background processors on the PI server. A PI
uses the queue concept to route messages.
Gateway module (GM): The gateway module which is part of the Participant Interface (PI)
manages the connectivity and transfer of messages between PI and the Inter-Bank Funds Transfer
Processor (IFTP) (Please refer to Figure 9.3 of the chapter). Using the GM, PI connects to the RTGS
system vide the IFTP. The main purpose of GM is the transferring of messages between Participant
Interface (PI) and IFTP. Messages sent to the IFTP (outward messages) are assigned message
sequence numbers by the GM before they are sent. The GM starts receiving all inward messages from
IFTP after establishing a connection with it. The PI client controls the flow of outward messages, but
inward messages are not controlled. They continue to flow as long as its connection with the IFTP is
active. This ensures that PI (Participant Interface) and IFTP receive all messages and that no
messages are lost.
However, message is sent and encrypted before being released to IFTP and decrypted on receipt
from IFTP using the crypto server. The crypto server is on a dedicated server. The crypto server is a
cryptographic system. The system could be either a smart card or a hardware security module. This is
supplied by Institute for Development and Research in Banking (IDRBT).
Outward message manager (OMM): The Outward Message Manager (OMM) module supports the
entry, authorization and release of outgoing messages. In addition to creation of messages, PI also
receives messages from external applications such as the bank’s host system. The messages when
being created could be completed or saved as a draft. Messages are classified as ‘awaiting
completion’, ‘awaiting authorization’, and ‘awaiting release’ and suitably allotted to the appropriate
queue.
Messages can be modified while they are in the ‘awaiting completion’ or ‘receive sub queue’. If no
modification is needed, they are marked as complete.
(a) Message authorization: As sort of authorization process, certain fields must be re-entered
(key verification). The authorization is successful only when the key verification is successful.
Messages in the ‘awaiting authorization’ sub-queue need to be authorized by a supervisor with
appropriate permission.
(b) Message release: When the outward message status is set to “sending”, the GM sends payment
messages from the ‘awaiting release’ sub queue to the IFTP. Payment messages are moved to the
awaiting IFTP acknowledgment sub-queue after releasing them to IFTP.
(c) Settlement: When a payment is settled, the GM receives the settlement notification from the
IFTP. The original payment message is moved to the settlement sub-queue. If the settlement fails, the
IFTP sends a negative settlement notification and the original message is moved to the cancelled sub-
queue.
It is also possible to send a cancellation request to cancel the initiated payment. If the cancellation
request is successful, original payment message is moved to the cancellation sub-queue.
The payment message is final only when it is in the settled, cancelled or rejected sub-queues.
Inward message manager (IMM): The Inward Message Manager (IMM) handles the management of
incoming messages from the IFTP. It also processes responses, notifications and acknowledgments.
The IMM also has separate queues for different purposes. Acknowledgments are provided by the
IFTP to the IMM for outward financial transaction requests, sent originally through OMM.
The IMM module also supports the creation of output files for the payment messages received.
The acknowledgment received from IFTP may be positive or negative. A positive acknowledgment
means that the message was accepted and has been forwarded to the RTGS system for processing.
Table 9.1 shows a comparative study between the present clearing system and RTGs.
Table 9.1 Comparison between the present clearing system and RTGS
Basis of distinction Present clearing system RTGS
Sattlement basis Net Gross
Time of Settlement As specified in-house Continuous basis
Based on Physical instruments Electronic messages
Initiated by Person receiving (payee) Person making payment (drawer)
High value—day 0
Local instruments
Receipt of funds Continuous basis
T + 1 Outstation—
More time
Immediate, final and
Finality of settlement Only after clearing return
irrevocable
Insufficient funds
Due to operational mistakes
Returns Instrument being stale
like incorrect A/c number
Stop payment
9.4 CASH MANAGEMENT SYSTEM

One of the new generation banking products is Cash Management System (CMS). The CMS is
targetted at the customers who have an all India presence and have collection/payments in various
locations. In the normal collection process, the cheques had to be collected in one single location and
then deposited in the bank. There was no certainty as to when the collections would realise and
hence, projections of cash flows was a problem. This resulted in scenarios of excess/shortage in cash
balances. Similarly, payments which had to be made in high volumes, e.g. company dividends, salary
pay outs etc. across different locations was also a problem.
It was in this light that the banks have introduced the concept of cash management system where
they offer the following features:
Multiple collection centers across the country where the instruments can be deposited.
No separate account is required to be opened in different centers.
Credit is offered to the clients on an agreed mandate in clients’ main account at the pooling
center the same day as cleared—even credit against uncleared instruments may be offered on a
discretionary basis.
Customized MIS to customers—location wise/party wise etc. even advanced features like
MIS through E-Mail, SMS are also available.
SECTION A............................................CHAPTER 10
Security Policy
10.1 INTRODUCTION
The objective of security policy is to provide management direction and support for information
security within the bank. The policy applies to the entire bank and to all of its employees, vendors
dealing with the bank and others who may be authorised to deal with the information assets of the
bank. The policy will clearly lay down that employees who have deviated from the best practices
prescribed in the policy would be deemed to be guilty of dereliction of duty and accordingly,
disciplinary action will be taken, which may also lead to termination of employment.
The security policy document would enunciate the policies. It will also be supported by the
guidelines which represent the best recommended practices and the rationale behind the policy.
Procedure would also be laid down for implementing policy. It would be generally preferable to
have a separate policy document and have the guidelines and procedures in yet another document.
In the following pages, a specimen ‘security policy’ is provided. It has been drafted for a
hypothetical organization. It is intended to be illustrative and not exhaustive.
It is essential for all the organizations including banks to have a security policy duly approved by
the management to be in place. There needs to be a machinery to implement the policy.
RBI has laid down that all banks need to have a security policy in place. The existence of the
policy and its implementation is a matter of importance.
10.2 SECURITY POLICY: XXX BANK LIMITED

Tables 10.1, 10.2 and 10.3 show the details of the security policy of XXX Bank Limited.
Table 10.1 Version Control
Version Date Prepared By Changes
Version No. .................... .................... ....................

Table 10.2 Name and reference
Document Name Security Policy
Abstract .................... ...........................

Document Reference .................... ...........................
Table 10.3 Document circulation
Circulation Date Given Expected Date Action
.................... .................... .................... ....................

.................... .................... .................... ....................
.................... .................... .................... ....................
.................... .................... .................... ....................
10.2.1 Introduction
The document details the information security policy of xxx Bank Limited. It is intended to provide a
common basis for developing effective security management practice across the organization and to
provide confidence in inter-organizational dealings. Adherence to the specific policies listed in this
document is mandatory for all employees of the organization, and vendors dealing with the
organization.
The company security policy document also contains the procedures for implementing the policies
and guidelines along with do’s and don’ts.
10.2.2 Objective
The objective of this information security policy is to provide the management with direction and
support for information security within the organization in accordance with the business requirements
and relevant laws and regulations.
This policy shall be approved by the management, published and communicated to all the
employees and relevant external parties. This policy shall be reviewed at planned intervals or in case
of the occurrence of any significant change.
10.2.3 Scope
This security policy applies to the entire organization and to all its employees, customers who have
been provided direct access to the organization’s assets and vendors dealing with the organization.
10.2.4 Enforcement
Any employee found to have violated this policy may be subject to disciplinary action, up to and
including termination of employment. The external service providers found to have violated this
policy may be subject to financial penalties, up to and including termination of the contract.
10.2.5 Exception
Any exception to the policies shall be formulated by the Information Security Committee and
approved by the steering committee.
10.3 ORGANIZATION OF INFORMATION SECURITY COMMITTEE

To manage information security within the organization, a Security Committee (OSC) shall be
constituted. Its roles and responsibilities shall be defined. Information security activity shall be
coordinated by the task force members from different parts of the organization with clearly defined
responsibilities.
Authorization powers for new information processing facilities shall be defined and implemented
to meet the confidentiality and integrity requirements of the organization. A non-disclosure agreement
will be prepared, approved and regularly reviewed.
Appropriate contacts with relevant authorities, special interest groups at security forums shall be
maintained. Independent reviews of information security will be done by a third party at planned
intervals or as when significant changes to the security implementation occur.
10.3.1 External Parties

To maintain the security of the organization’s information processing facilities that are managed by
external parties, all risks involved in giving access to the external parties and the third parties to the
organizations information processing facility, shall be identified and appropriate controls shall be
implemented before granting the access.
10.4 ASSET MANAGEMENT

10.4.1 Responsibility for Assets
To achieve and maintain appropriate protection of organizational assets, all assets shall be clearly
identified. Inventory of all assets shall be drawn up and maintained. Ownership of all assets shall be
clearly identified and defined. The rules for acceptable usage of information and assets associated
with information processing facilities shall be identified, documented and implemented.
10.4.2 Information Classification

To ensure that information receives appropriate level of protection, it shall be classified in terms of
its value, legal requirements, sensitivity and criticality to the organization.
For information labelling and handling, an appropriate set of procedures shall be developed and
implemented in accordance with the classification.
10.5 HUMAN RESOURCES

10.5.1 Prior to Employment
To ensure that employees, contractors and third party users understand their responsibilities and are
suitable for the roles they are considered for and to reduce the risk of theft, fraud or misuse of
facilities, their security roles and responsibilities shall be defined and documented as per this policy.
Background verification of all the candidates seeking employment, contractors and third party users
shall be performed with reference to laws, regulations, ethics and should be proportional to the
business requirements. The classification of information to be accessed by the contractors and third
party users and the risk involved should also be perceived.
The employees, contractors and third party users as a part of their contractual obligation shall sign
an agreement which states their and the organization’s responsibilities for information security.
10.5.2 During Employment

To ensure that employees, contractors and third party users are aware of the information security
threats, their responsibilities and liabilities and are equipped to support organizational security
policy in the course of their normal work and to reduce human errors, management shall require that
all employees, contractors and the third party users make sure that security is applied in accordance
with this policy and the laid down procedures.
Awareness/training shall be provided to all the employees, contractors and third party users
regarding the information security requirements and the consequence of non-compliance in order to
minimize the security risks. A formal disciplinary process for handling security procedures shall be
established.
10.5.3 Termination or Change of Employment
To ensure that the employees, contractors and third party users exit the organization or change
employment in an orderly manner, termination responsibilities shall be clearly defined and assigned.
Upon termination of employment, contract or agreement, all employees, contractors and third party
users shall return all the assets of the organization which are in their possession to the designated
persons.
All the access rights to information processing facilities of all employees shall be removed upon
termination of their employment, contract or agreement or adjusted upon change.
10.6 PHYSICAL AND ENVIRONMENTAL SECURITY
10.6.1 Secure Areas
To prevent an unauthorized access, damage and interference to business premises and information,
critical or sensitive information processing facilities shall be housed in secure areas, protected by
defined security perimeters, with appropriate security barriers and entry controls. They shall be
physically protected from unauthorized access, damage and interference.
The protection provided, shall be commensurate with the identified risks.
10.6.2 Equipment Security
To prevent loss, damage or compromise of assets and interruptions to business activities, equipment
shall be protected from physical and environmental threats.
Protection of equipment (including that used off-site, and the removal of property) is necessary to
reduce the risk of unauthorized access to information and to protect against loss or damage. Special
controls shall be in place to protect against physical threats, and to safeguard supporting facilities,
such as the electrical supply and cabling infrastructure.
10.7 COMMUNICATIONS AND OPERATIONS MANAGEMENT
10.7.1 Operational Procedure and Responsibilities
To ensure the correct and secure operation of information processing facilities, changes to
information processing facilities and system shall be controlled. The operating procedures shall be
documented, maintained and made available to all the users who need them.
A proper segregation of duties shall be implemented where appropriate, to reduce the risk of
negligence or deliberate system misuse. Development, test and operational facilities shall be
separated to reduce the risks of unauthorized access or changes to the operational system.
10.7.2 Third Party Service Delivery Management
To implement and maintain the appropriate level of information security and service delivery in line
with third party services delivery agreements, it shall be ensured that the security controls, service
definitions and delivery levels included in the third party service delivery agreement are
implemented, operated, and maintained by the third party.
The services, report and records provided by the third party shall be regularly monitored and
review audits shall be carried out regularly.
Changes to the provision of services, including maintaining and improving existing information
security policies, procedures and controls, shall be managed, taking into account the criticality of
business systems and process involved and re-assessment of risks.
10.7.3 System Planning and Acceptance

To minimize the risks of system failures, advance planning and preparation shall be made to ensure
the availability of adequate capacity and resources to deliver the required system performance.
Projections of future capacity requirements shall be made to reduce the risk of system overload.
The operational requirements of new systems shall be established, documented, and tested prior to
their acceptance and use.
10.7.4 Protection against Malicious and Mobile Code
To protect the integrity of software and information, detection, prevention, and recovery controls to
protect against malicious code, appropriate user awareness procedures shall be implemented. Where
the use of mobile code is authorized, the configuration shall ensure that the authorized mobile code
operates according to a clearly defined security policy and unauthorized mobile code shall be
prevented from executing.
10.7.5 Backup
To maintain the integrity and availability of information and information processing, backup copies of
information and software shall be taken and tested regularly in accordance with the agreed guidelines
and procedures.
10.7.6 Network Security Management Policy
To ensure the safeguarding of information in networks and the protection of the supporting
infrastructure, the networks shall be adequately managed and controlled, in order to be protected from
threats. Besides, it should be managed to maintain security for the systems and applications using the
network, including information in transit.
Security features, service levels and management requirements of all network services including
Internet shall be identified and included in any network services agreement, whether these services
are provided in-house or outsourced.
E-mail policy
To ensure that e-mails (electronic mails) stored or transmitted using the company’s facilities shall be
used only in accordance with the need for business communication and based upon the criterion
defined from time to time by the management.
Firewall and router security policy
The Internet connections and other internal connection facilities shall be protected from unauthorized
access and usage. Such facilities shall be used only in accordance with the business needs and based
upon the criterion defined from time to time by the management.
Internet policy
All staff with Internet access shall be aware of and will comply with the requirements of the internet
usage policy. There shall be guidelines and procedures in place.
10.7.7 Media Handling and Security Policy

To prevent unauthorized disclosure, modification, removal or destruction of assets and interruption to
business activities, there shall be procedures in place for the management of removable media.
Media shall be disposed of securely and safely when no longer required, using formal procedures.
The procedures for handling and storage of information shall be established to protect this
information from unauthorized disclosure or misuse. System documentation shall be protected against
unauthorized access.
10.8 ACCESS CONTROL

10.8.1 Access Control Policy
To control access to information, an access control policy shall be established, reviewed based on
business and security requirements.
10.8.2 User Access Management Policy

To ensure authorized user access and to prevent unauthorized access to information systems, there
shall be a formal user registration and de-registration procedure in place for granting and revoking
access to all information systems and services.
The allocation and use of privileges shall be restricted and controlled. The allocation of passwords
shall be controlled through a formal management process. Management shall review user’s access
rights at regular intervals using a formal process.
10.8.3 User’s Responsibilities

Unattended computer equipment shall be protected to prevent unauthorized user access and
compromise or theft of information and information processing assets. The users shall be required to
follow good security practices in the selection and use of passwords. They shall ensure that
unattended equipment has appropriate protection and also that the clear desk policy for papers,
removable storage media and a clear screen policy for information processing facilities are being
adopted.
10.8.4 Network Access Control Policy

To prevent unauthorized access to networked services, the users shall only be provided with access
to the services that they have been specifically authorized to use. An appropriate authentication
method shall be used to control access by remote users. Automatic equipment identification shall be
considered as a means to authenticate connections from specific locations and equipment. Physical
and logical access to diagnostic and configuration ports shall be controlled. Groups of information
services, users and information systems shall be segregated on networks.
For the shared networks, especially those extending across the organization boundaries, the
capability of users to connect to the network shall be restricted, in line with the access control policy
and requirements of the business applications. Routing controls shall be implemented for networks to
ensure that computer connections and information flows do not breach the access control policy of the
business applications.
10.8.5 Operating System Access Control

To prevent unauthorized access to the operating system, access to operating systems shall be
controlled by a secure log-on procedure. All the users shall have a unique identifier (user ID) for
their use only and a suitable authentication technique shall be chosen to substantiate the claimed
identity of the user. Systems for managing passwords shall be interactive and shall ensure quality
passwords.
The use of utility programs that might be capable of overriding system and application controls
shall be restricted and tightly controlled. Inactive sessions shall be shut down after a defined period
of inactivity. Restrictions on connection times shall be used to provide additional security for high-
risk applications.
10.8.6 Application and Information Access Control

To prevent unauthorized access to the information stored in application systems, access to
information and application system functions by users and support personnel shall be restricted in
accordance with the defined access control policy. Sensitive systems shall have a dedicated
(isolated) computing environment.
10.8.7 Mobile Computing

To ensure information security when using mobile computing, a formal policy shall be in a place.
Appropriate security measures shall be adopted to protect against the risks of using mobile computing
and communication facilities.
10.8.8 Monitoring
To detect unauthorized information processing activities, audit logs recording user activities,
exceptions and information security events shall be produced and kept for an agreed period to assist
in future investigations and access control monitoring. Procedures for monitoring the use of
information processing facilities shall be established and the results of the monitoring activities need
to be reviewed regularly.
Logging facilities and log information shall be protected against tampering and unauthorized
access.
The system administrator and system operator activities shall be logged. All kinds of faults shall be
logged, analyzed, and an appropriate action taken. The clocks of all relevant information processing
systems within an organization or security domain shall be synchronized with an agreed upon accurate
time source.
10.9 INFORMATION SYSTEMS ACQUISITION, DEVELOPMENT AND MAINTENANCE

10.9.1 Security Requirement of Information System
To ensure that security is internal part of information systems, business requirements for new
information systems or enhancements to existing information systems shall specify the requirements
for security controls.
10.9.2 Correct Processing in Applications

To prevent errors, loss, unauthorized modification or misuse of information in applications, data input
to applications shall be validated to ensure that the data is correct and appropriate. Validation checks
shall be incorporated into the applications to detect any corruption of information through processing
errors or deliberate acts.
Requirements for ensuring authenticity and protecting message integrity in applications shall be
identified. Appropriate controls shall be identified and implemented. Data output from an application
shall be validated to ensure that the processing of stored information is correct and appropriate to the
circumstances.
10.9.3 Security of System Files and Database

To ensure the security of system files and database, there shall be procedures in place to control the
installation of software on operational systems. Test data shall be selected carefully, protected and
controlled. Access to program source code shall be restricted.
10.9.4 Security in Development and Support Process

To maintain the security of application system software and information, the implementation of
changes shall be controlled by the use of formal change control procedures. When operating systems
are changed, business critical applications shall be reviewed and tested to ensure there is no adverse
impact on organizational operation or security.
Modifications to software packages shall be discouraged, limited to necessary changes, and all
changes shall be strictly controlled. Any possibility of information leakage shall be prevented and
outsourced software development shall be supervised and monitored by the organization.
10.9.5 Technical Vulnerability Management

To reduce the risks resulting from the exploitation of published technical vulnerabilities, timely
information about technical vulnerabilities of information systems being used, shall be obtained. The
organization’s exposure to such vulnerabilities should be evaluated and appropriate measures shall
be taken to address the associated risk.
10.10 INFORMATION SECURITY INCIDENT MANAGEMENT

10.10.1 Reporting Information Security Events and Weaknesses
To ensure that information security, events and weaknesses associated with information assets are
communicated in a manner, allowing timely corrective action and, be reported through the
appropriate management channels as quickly as possible.
All employees, contractors and third party users of information systems and services shall be
required to note and report any observed or suspected security weaknesses in systems or services.
10.10.2 Management of Information Security Incidents and Improvements

To ensure that a consistent and effective approach is applied to the management of information
security, management responsibilities and procedure shall be established to facilitate a quick,
effective, and orderly response to information security incidents.
There shall be mechanisms in place to enable the types, volumes, and costs of information security
incidents to be quantified and monitored.
When a follow-up action against a person or organization after an information security incident,
involves legal action (either civil or criminal), evidence shall be collected, retained, and presented to
conform to the rules for evidence laid down in the relevant jurisdiction(s).
10.11 BUSINESS CONTINUITY MANAGEMENT
10.11.1 Information Security Aspects of Business Continuity Management
To counteract interruptions to business activities and to protect critical business processes from the
effects of major failures of information systems or disasters and to ensure their timely resumption, a
well-managed process shall be developed and maintained for business continuity throughout the
organization that addresses the information security requirements needed for the organization’s
business continuity.
The events that can cause interruptions to business processes shall be identified, along with the
probability and impact of such interruptions and their consequences for information security. Various
plans shall be developed and implemented to maintain or restore operations and ensure availability
of information at the required level and in the required time scales, following the interruption to, or
failure of critical business processes.
A single framework of business continuity plans shall be maintained to ensure that all the plans are
consistent to address information security requirements consistently, and to identify the priorities for
testing and maintenance.
The business continuity plans shall be tested and updated regularly to ensure that they are up to date
and effective.
10.12 COMPLIANCE
10.12.1 Compliance with Legal Requirements
To avoid breaches of any criminal and civil law, statutory, regulatory or contractual obligations and
of any security requirements, all relevant statutory, regulatory and contractual requirements and the
organization’s approach to meet these requirements, shall be explicitly defined, documented, and kept
up-to-date.
The appropriate procedures shall be implemented to ensure a proper compliance with legislative,
regulatory, and contractual requirements on the use of material in respect of which there may be
intellectual property rights and proprietary software products.
All the important records shall be protected from loss, destruction and falsification in accordance
with statutory, regulatory, contractual, and business requirements. Data protection and privacy shall
be taken care of as required in relevant legislation, regulations and applicable contractual clauses.
Users shall be deterred from using information processing facilities for unauthorized purposes.
10.12.2 Compliance with Security Policies and Standards, and Technical Compliance
To ensure the compliance of systems with organizational security policies and standards, managers
shall make sure that all security procedures within their area of responsibility are carried out
correctly. All the information systems shall be regularly checked for compliance with security
implementation standards.
10.12.3 Information Systems Audit Consideration

To maximize the effectiveness of and to minimize interference to the information systems audit
process, audit requirements and activities involving checks on operational systems shall be carefully
planned and agreed to minimize the risk of disruptions to business process. Access to information
systems audit tools shall be protected to prevent any possible misuse or compromise.
As mentioned at the beginning of the chapter, the above mentioned document is only a sample
security policy. It needs to be emphasised that a security policy shall be comprehensive and tailor
made as per the need of the organisation.
SECTION A............................................CHAPTER 11
Business Continuity Planning (BCP) and Disaster

Recovery Planning (DRP)
11.1 INTRODUCTION
This is a process by which the bank ensures the maintenance and recovery of operations. This
includes service to customers, even though faced with adverse events such as natural disasters (fire,
flood, earthquake, tsunami etc.), technological failures (operating system crashes, lost connectivity,
computers malfunctioning etc.) and human error etc. Following are the objectives of business
continuity planning (BCP):
(a) Minimize financial loss.
(b) Continue to serve customers (they are able to operate accounts, make fixed deposits, receive
money for matured fixed deposit, receive amounts for loan sanctioned etc.).
(c) Mitigate adverse impact on the image of the bank
(d) Continue to comply with applicable laws and regulations.
Disaster Recovery Planning (DRP) has the following objectives:
(a) To recover from the impact of disaster.
(b) To bring back all support services to restore normalcy.
11.2 BCP AND DR PLANNING PROCESS OF BANKS

Bank’s BCP and DR planning process should be to meet the above-mentioned objectives. The
Business Continuity Planning (BCP) is about ensuring continuity of the entire business and not just
recovering the technology process on which the bank is dependent. The planning process has to be
conducted for the entire organization. Business impact analysis and risk assessment need to be
performed as a prelude to developing an effective BCP and Disaster Recovery Planning (DRP).
The business impact analysis phase consists of determining the risks by identifying critical business
functions and prioritizing. Risk assessment is the process of identifying what could go wrong and
thus, making decisions about various measures for protecting the assets. It helps in minimizing the
impact of non-availability of a certain resource would have on the business of the organization. This
assessment will be limited to identifying the potential risks that affect various critical resources and
the recovery mechanisms in the event of disaster.
The above exercise is carried out for most of the important processes in the bank which are
mentioned herein below:
Branch operations
Savings bank
Current account
Fixed deposit
Draft issuing, etc.
Similarly, other processes mentioned below would also have to be considered:
ATM operations
Internet banking
RTGS etc.
Risk value calculations need to be done for Information Technology (IT) assets also as in a bank
dependency on the same is very critical.
A template as shown in Table 11.1 could be used for computing risk value for the assets.
Table 11.1 Computation of risk value
Probability
Risk ID Type of risk Existing DR mechanism Effect on service Impact Aggregate risk value
of occurrence of risk
......... ......... .................. ...... ................ ......... ........... ..................
......... ......... ......... ......... ...... .................. ......... ........... ..................
Some of the IT assets to be included for risk assessment are mentioned hereunder:
(a) Core banking database server
(b) Application server
(c) Web server
(d) FTF server
(e) Internet banking server
(f) RTGS server
(g) ATM server
(h) Network Infrastructure
(i) Personnel making critical functions
11.2.1 Type of Risks
The various risks to be considered (depending upon the type of service, certain risks may not apply)
would include the following:
1. Failure of the server hardware

2. Failure of the server operating system
3. Failure of the network interface card
4. Non-availability of support personnel at the time of failure
5. Application configuration corruption
6. Server failure due to virus attacks
7. Database failure
8. Power failure
9. Connectivity failure from Internet Service Provider (ISP)
Illustration of risk computation of IT assets

The methodology could remain the same while the types of risks may change. The network resources
would include the following measures:
1. Core edge router

2. Firewall
3. Intrusion detection system
4. Branch router
The types of risks may be of the following nature:
1. Failure of primary Wide Area Network (WAN) links between the branches and the data center
2. Complete failure of the router
3. Router Internetworking Operating System (IOS) failure
4. Router configuration corruption
5. Router serial port failure
6. Router serial port cable failure
7. Router ethernet port failure
8. Failure of the router backup BR 1 ports providing backup connectivity to branches
9. Failure of power supply module
10. Non-availability of support personnel
As regards the firewall and intrusion detection systems, following could be the failures:
1. Failure of configuration/Rule base/Signature database.

2. Failure of hardware
Assessment of risks
The risks associated with various business processes and IT resources are assessed. A general
relational rating system of ‘High’, ‘Medium’, ‘Low’ and ‘Very low’ is used initially to identify the
probability of threat occurring (see Table 11.2).
Table 11.2 Risk assessment
Impact value range
Impact class
From To
High 1000 3100
Medium 500 999
Low 100 499
Very low 0 99
The impact of each type of potential threat on various functions or departments within the bank is
considered in the Risk Analysis Report.
An illustrative table summarizing threat with impact on the business processes is provided. Impact
value is arrived at after initially considering the individual processes and thereafter the total impact
is calculated by summing them.
These values are arrived at without taking into account the containment measures that are in place.
The values thus arrived is classified as high, medium, low and very low. In an exercise performed the
values ranged from 200 to 3100. The classification of range was done as shown in Table 11.3.
Table 11.3 Classification of range
Impact
Sl. No. Threats description % of total impact value Criticality
value
1. Telecommunication failure 3060.0 11.17 High
2. Employee resignations 2304.0 8.41 High
3. Network failure 2160.0 7.89 High
4. System software failure 2124.0 7.76 High
5. System failure 2124.0 7.76 High
6. Application software failure 2016.0 7.36 High
7. Fire/explosion (external) 1848.0 6.75 High
8. VA/C failure 1608.0 5.87 High
9. Computer crime 1488.0 5.43 High
10. Power failure 1120.0 4.09 High
11. Fire/explosion (Internal) 1044.0 3.81 High
12. Flood (internal) 876.0 3.20 Medium
13. Flood (external) 732.0 2.67 Medium
Failure of detection/alarm
14. 640.0 2.34 Medium
system (technology)
15. 640.0 2.34 Medium
system (human)
16. 584.0 2.13 Medium
system (natural)
17. Robbery/burglary 400.0 1.46 Low
18. Major accident 392.0 1.43 Low
19. Storm 342.0 1.25 Low
20. Structural collapse 324.0 1.18 Low
21. Embezzlement 312.0 1.14 Low
22. Earthquake 244.0 0.89 Low
23. Epidemic 234.0 0.85 Low
24. Vandalism 232.0 0.85 Low
25. Terrorism 232.0 0.85 Low
26. Bomb threats 228.0 0.83 Low
27. RSCC 41.0 0.15 Very Low
28. Work stoppage 37.0 0.14 Very Low
Effective risk calculation matrix

Effective risk calculation matrix
For various risk scenarios for a resource, the definition of risk value calculation would depend upon
the risk and probability of that risk materializing into a realizable threat. So the effective risk values
are calculated depending upon the range of values as shown in Table 11.4.
Table 11.4 Calculation of effective risk values
Probability of
Risk Impact of Effective risk Effective risk
occurrence
scenarios the risk (I) value (RV) value range
(P)
1. H H 10
2. H M 9 8–10
3. M H 8
4. H L 7
5. M M 6 5–7
6. M L 5
7. L H 4
8. L M 3 0–4
9. L L 0-2
Note: The above scaling is purely subjective.
Potential vulnerabilities that exist or may exist in the bank should be evaluated to ensure
appropriate threat containment measures are in place to protect the assets with high impact.
For arriving at final risk value for purposes of prioritizing control measures, information is
collected as shown in Table 11.5.
Table 11.5 Collection of information
Existing Probability
Threat control Vulnerability of Impact Risk value
mechanism occurrence
Employees resignation
Fire
Flood etc.
11.3 RISK MANAGEMENT

After conducting business impact analysis and risk assessment, a risk management or a risk reduction
exercise needs to be performed.
Based on these, BCP/DRP would be finalised. The plan would contain details of how a formal
declaration of ‘disaster’ needs to be declared and the process of invoking BCP would take place. A
specimen contents of a BCP document is enclosed for reference in Annexure A.
Details of business impact analysis have not been considered here as it is very elaborate. Business
impact value would depend upon the nature of business, e.g. failure to pay a fixed deposit which has
matured will have more adverse impact on the business than a delayed Management Information
System (MIS) report.
It needs to be re-emphasised that BCP of a Bank or for that matter any organisation is more than
recovery of IT processes supporting the business process. BCP is a plan to recover and continue all
business operations which naturally would include the IT processes as supporting service.
Once disaster is declared, the recovery process starts. After the recovery process is completed,
system is restored and normal business operations would resume within the recovery time objective
stated, say 1 day. The various processes involved during recovery is depicted in Figure 11.1.
Figure 11.1 Business recovery timeline.
11.3.1 Activating BCP/DRP

Activating Business Continuity/Disaster Recovery Plan is as in Figure 11.2.
Figure 11.2 Activating BCP/DR.
The study of business process of bank would remain the same, irrespective of the supporting
technologies. As the emphasis of the book is on core banking solution, examples of possible risks
scenarios could be as mentioned below.
The scenarios given below are likely to occur and cause disruptions. For each scenario, certain
steps are to be taken which are mentioned herein below along with the acronyms:
CSD..........—..........Computer Services Department (CSD)

DC............—..........Data Center
DRS..........—..........Data Recovery Site
Assumption: Non ABC City Branches are connected directly to the data centre while ABC
city branches are connected to the data centre through the CSD.
Scenario 1: No Access to Computer Services Department (CSD) building and also to the Data
Center (DC) site.
Steps to be taken
1. Call the team members to meet in the designated Center (ABC City) which would be the
alternate site.
2. Disaster recovery files have to be manually brought up.
3. Call all the branches except ABC City branches.
4. All other branches will connect through the Integrated Subscribers Digital Network (ISDN) to
the disaster recovery site.
5. Continue the process until normalcy is restored.
Connect to the disaster recovery site to be established and Steps to be taken
1. Ensure that all the Log shipping files are applied.

2. Bring up the data base to open and active mode.
3. Test the application.
4. Announce the readiness.
5. Configure log shipping locally, i.e. at the disaster recovery site.
Scenario 2: No access to CSD building, but DC site is available.

Steps to be taken
1. The ABC City branches will not have connectivity, but all the other branches will be
connected to data center.
2. Call for a meeting at a designated place.
3. Re-route the city branches to the data centre.
Scenario 3: Main server at DC is not working, but access to CSD is available.

As a first step all transactions are to be re-routed to the DR site. Steps to be taken at the disaster
recovery site.
1. Ensure the log shipping is applied.

2. Bring up the database to open and active mode.
3. Test the application.
4. Confirm the log shipping to CSD. This will become the backup center.
Note: xxx minutes data will be lost. All the branches to be informed to key in the data lost. Similar
procedure applies for other delivery channels like ATM, Internet Banking, FTF. The transactions
which have been processed through the channels have to be manually entered into the system.
Scenario 4: CSD and DC sites are available, but no connection to all branches and head office.
Since there is redundancy in the network, DC will be accessible through other communication
channels. Disaster recovery site will be accessible. The network diagram is enclosed for ready
reference.
Scenario 5: CSD and DC sites are available, but no connection to certain branches. As redundancy
is built, network connectivity could be established through ISDN. If both fail (primary and
secondary), the branch is advised to go to the nearby branch and complete the transaction.
Scenario 6: DR site goes down. DC and CSD are available.
Because of disruption, log shipping would be affected.
Steps to be taken
1. Log shipping to be configured to computer system department.

2. Once DR comes up, log shipping needs to be synchronized.
3. Log shipping log to be verified.
Scenario 7: Nodal place goes down.

There is an alternative path built in the network which could be utilised.
As all the branches have ISDN, they could call other nearby nodal places, as also the DC and the
DR directly.
The BCP Document is a dynamic document. Based on regular testing of the plan and the results,
necessary changes need to be incorporated. It needs to reflect the current threats and the
corresponding risk mitigation.
ANNEXURE
Contents of a sample business continuity plan document
Sl. No. Description
Section A: Introduction
1 Background
2 Objectives
3 Definition of disaster
4 Organization for business continuity/disaster recovery
5 Roles and responsibilities of the team and its members
6 Activation of the plans
7 Emergency Operation Center (EOC)
8 Placement of documents
Section B: Business continuity plan
1 Objective
2 Scope
3 Alternate site
4 BCP scenarios
5 Processwise BCP procedures and BCP teams
Section C: Disaster recovery plan
1 Introduction
2 Purpose
3 Threats considered/not considered for the plan
4 Disaster recovery team
5 Emergency calls
6 Disaster recovery procedures—non-IT related
— Fire
— Power outage
— Flood
7 Disaster recovery procedures—IT related
— Failure of hardware
— Failure of system software
— Failure of application software
— Cyber intrusion and cyber crime
8 Contingency operations procedures
9 Recovery and restoration
— Recovery of lost data
— Liaison with application users
— Restoration and return to normal operations
Section D: Emergency response plan
1 Introduction
2 Definition of crisis
3 Emergency response teams
4 Emergency response activation
5 Establishing an alert level
6 Emergency response—Local escalation procedures
7 Action consideration lists
Section E: Maintenance and testing of the plans
Annexures
Annexure 1: Constituents of the BCP, DRP, EMT committees
Annexure 2 : Employee call tree
Annexure 3: List of branches and contact persons
Annexure 4 : Building site plan
Annexure 5: Emergency contact numbers of support services
Annexure 6: Contact numbers of third party service providers (IT)
Annexure 7: Contact numbers of vendors (Non-IT )
Annexure 8: Contact numbers of vendors (IT)
Annexure 9: Formula to be used for computation of customer dues
Annexure A to C: BCP procedures
Annexure D: Formats of documents used during business continuity
Annexure E: Hardware inventory list
Annexure F: List of software used (vendor based )
Annexure G: List of software developed in-house
Annexure H: List of data files used
Annexure I: Media used to store files
Annexure J: Test preplanning checklist
Annexure K: Format for test evaluation sheet
Annexure L: Format for BCP/DRP test report
PART 2 EVALUATION OF SECURITY AND CONTROL
This part deals with evaluation of security and controls in an environment where the core banking solution has been implemented.
In Part 1 we discussed the relevance, appli-cations and functionalities of CBS. In this part we discuss methodology of evaluation
of adequacy of security and the control and the impact of lack of controls.
SECTION B............................................CHAPTER 12
Scope of Evaluation of
Security and Controls in a
Core Banking Solution
12.1 INTRODUCTION
A leading public sector bank while calling for the consultants to bid to evaluate their core banking
solution (CBS) including Internet Banking, defined the scope for evaluation of security and controls in
CBS and for Internet banking. They had also specified the deliverables for each of the systems. The
contents which were downloaded from the Internet are being reproduced below with very slight
modifications, regarding numbering of paragraphs etc.
12.2 FUNCTIONALITY PERSPECTIVE

The vendor shall take inputs of User Acceptance Testing (UAT) version conducted by the bank’s staff
as one of the inputs for the audit.
The vendor shall take into account the final audit report of the earlier auditors for software ‘X’
version ‘a’, who have conducted earlier IS audit, as one of the inputs. A vendor should:
Study the implemented functionality of the core banking application, Internet banking solution,
and other suite of applications as per the scope of this audit.
Perform application functionality and controls review.
Study the core banking application, internet banking and other suite of applications for
adequate input, processing and output controls.
Develop suitable testing methodology/testing strategy document.
Conduct various tests to verify existence and effectiveness of the controls for all
functionalities, schemes and products supported by the application under review.
Perform a test of controls and functionality setup in the core banking application, Internet
banking and other suits of applications.
Identify ineffectiveness of the intended controls in the software and analyze the cause for its
ineffectiveness.
Review controls over automated processing/updations of records, review or check critical
calculations such as interest rates, etc., review the functioning of automated scheduled tasks,
output reports design, reports distribution etc.
A vendor should also take care of the following measures:
Auditability both at client side and server side including sufficiency and accuracy of event
logging, database level logging etc.
Extent of parameterization.
Internal control built in at application software level, database level, server and client side.
Backup/Fallback/Restoration procedures and contingency planning.
Suggestion on segregation of roles and responsibilities with respect to application software to
improve internal controls.
Adequacy, accuracy, data integrity of the Management Iformation Scheme (MIS) reports and
audit reports.
Manageability with respect to ease of configuration, transaction roll backs, time taken for end
of day, day-begin operations and recovery procedures.
A special focused audit is to be made on following items:
• Hard coded and virtual user-ID and password
• Interfaces with CBS software of many other applications/services both in house and third
party systems/solutions—security, confidentiality, integrity, accuracy and non-repudiation of
the data between systems.
• Recovery and restart procedures.
Review of customizations done to the software and the SDLC policy followed for such
customizations.
Proposed change management procedure during conversion, migration of data, version
control, application, replication, etc.
Suggest any application specific audit tools of programs.
Adequacy of audit trails and logs.
Adherence to legal and statutory requirements.
12.3 CONTROLS PERSPECTIVE

As part of the scope, following controls have to be thoroughly analyzed:
Input controls
Output controls
Processing controls
Interface controls
Authorization controls
Data integrity
Purging date
Database controls
Volume test
Server controls—application, web, database, firewall, etc.
Backup/fall back/restoration procedures
Physical Authentication mechanism
Security checks/controls
Physical access controls and logical access controls
Operating system controls
Management controls
• Change management
• Incident management
Logs management
Aspects related to segregation of duties
Adequacy of audit trails
Adherence to legal, statutory requirements
Performance controls
Controls of parameter setup/verification/testing, etc.
Regression testing
Prevalence of proper version controls
12.3.1 Application, Operating System and Database Control

Application, Operating System and Database controls should, inter alia, cover the following:
Application security controls review
The application security setup supported by the core banking solution, Internet banking and other suite
of applications should be reviewed to ensure the following measures:
Access level controls are appropriately built into the application.

Only authorized users should be able to edit, input or update data in the application.
Access on a ‘need-to-know’ and ‘need-to-do’ basis.
• Appropriate user maintenance and password policies are being followed.
• Benchmark the application security parameters and setup to the bank’s security policy and
leading practices.
• Identify gaps in the application security parameter setup in line with the bank’s security
policies and leading practices.
• Provide a report highlighting gaps in application security controls with options for
improving application security.
• Provide a report highlighting the gaps in the application security setting with respect to the
security policy defined by the bank.
Operating system security controls

For each of the applications under Information Systems (IS) audit, i.e. core banking application,
internet banking application and other suite of applications, the operating systems security should be
controlled through automated security scans and manual reviews. As part of this phase, service
provider should audit:
specific operating system security features used and the parameters set
identification of security weakness and recommend solutions
sample user profiles against job roles.
The service provider should provide a detailed technical report directed to the bank’s technical
and operational staff which should state each noted vulnerability, the systems affected by the
vulnerability, a detailed step-by-step fix for all security enhancements and the recommended counter
measures.
Data base security controls
For each of the applications under audit, i.e., core banking application, internet banking application
and other suite of applications, audit the data base systems security through automated security scans
and manual reviews. As part of this phase:
Review specific data base system security features used and the parameters set.
Review user profiles created at the database level against job roles.
Check the database security parameters and settings.
Check the procedures adopted for database/application backup.
Provide a detailed technical report directed to the Bank’s technical and operational staff which
should state each vulnerability noted, the systems affected by the vulnerability, a detailed step-by-step
fix for all security enhancements and counter measures recommended.
12.4 INTERNET BANKING

12.4.1 Compliance to RBI Standards
The organization/individual who has been awarded the assignment shall audit the following sets of
documents for the compliance with Reserve Bank of India (RBI) guidelines on Internet banking:
Information systems policy and procedures document containing the following domains:
Information System (IS) organization structure.

Data classification incident management.
Procedure documents for monitoring the OS, database, application and web server.
Internal security audit plan for Internet banking.
Backup and recovery procedures.
Disaster recovery/business continuity policy.
Employee/service provider training policy on IS security.
O/S security, application security, network security including firewall, router and IDS.
Physical and logical access policy.
Software and hardware acquisition, maintenance and customization for Internet banking.
Service Level Agreement (SLA) with third parties whose services are utilized for Internet
banking and outsourcing guidelines.
The bank’s Internet Banking policy fits into the bank’s overall information technology and
information security policy and ensure confidentiality of records and security systems.
The bank’s Internet banking policy clearly addresses and takes into account the issues
connected with the operational risk.
The bank’s Internet banking policy clearly lays down the procedure to be followed in respect
of ‘Know Your Customer’ requirements.
That the bank’s Internet banking policy meets all the parameters/criteria laid down in the
communications of RBI on Internet banking in India.
Regulatory and Legal documents

The following documents need to be reviewed.
Terms and conditions for Internet banking

Data privacy policy for Internet banking
Disclosure documents displayed on the website
Policy/management representation regarding links from/to the website.
Other specified documents to be reviewed
DRP, test plan for DRP and test results

Operations manual for Internet banking
Insurance coverage for Internet banking risks
Network architecture for Internet infrastructure, application security architecture including
encryption.
The vendor should benchmark the policies, procedures/processes. Standards against the standards
recommended by RBI and identify gaps. The vendors should report the areas where they have
observed the bank to be non-compliant with the RBI guidelines.
Internet banking IT infrastructure review
Web server–review and report on:

• Security settings with reference to security policy
• Security patches applied are current/latest
• Exposure of sensitive data in public area
• Ports on need to have basis, special thrust on disabling unnecessary ports or ports that are
potentially risky
• Usage of superuser account
• Adequacy of control for activities to be done at system console only.
Logs of activity
Review and report on adequacy of audit logs and procedures for review of audit logs as a
preventive and corrective control.
De-militarized zone and firewall—Review and report on:
• Firewall policy, firewall configuration and deployment
• Vulnerability Assessment (VA) of operating system, web server, application server and
database server
• Intrusion detection system used for Internet banking
• Router for net banking infrastructure
• Demilitarized zone
Security review of all services used for Internet banking:
Review and report on:
• Adequacy of operating system security
• Report on parameterization as per security policy
Database administration, security administration and system administration—Review and
report on:
• Roles and responsibilities of DBA and system administrator for OS and server security.
• Process flow documentation
• Adequacy of controls to monitor activities of super users
• Menu options in different modules as per the intent of the policy
Operational activities:
• Procedures for opening and operating account with thrust on legal aspects in internet banking
scenario
• Maintenance of records in internet banking scenario
Application control review of Internet banking application:
• Review and report on adequacy of logical access control procedures
Application security:
• Review and report on adequacy of testing and security infrastructures at various stages of
acquisition process
Penetration testing as mandated by RBI

Undertake penetration tests of the information system. It should include the following points:
Attempt to guess passwords using password cracking tools

Search for back door trap in the program
Attempt to overload the system using Distributed Denial of Services (DDoS) and Denial of
Service (DoS) attacks
Check for existence of commonly known holes in the software, especially the browser and the
email software.
Conduct penetration testing keeping in view the prevailing Reserve Bank of India (RBI)
guidelines, IT Act and other applicable regulations in India and check for following common
vulnerabilities like IP spoofing, buffer overflows, session hijacks, account spoofing, frame
spoofing, caching of web pages, cross-site scripting, cookie handling, SQL injection etc.
Secured server authentication procedures
General computer control’s review like logical access to the internet banking application, OS,
database and network and Physical access control, backup and program change management.
To check vulnerabilities for defacement and unauthorized modification of internet website
Check if commonly known holes in the software, especially the browser and the email
software, if used for internet banking.
12.4.2 Deliverables for CBS
Audit plan and procedure for each of the CBS suite of application packages as per the scope.
Interim report covering all the points as mentioned under the scope of work including specific
observations on the previous IS audit report. All observations will be thoroughly discussed
with the process owners before the finalization of the report.
Final audit reports with sign off by the bank and the Information System Auditor. (To be
submitted within 6 working days of completion of audit and the report should be submitted in
soft copy as word document and PDF format document besides a signed hardcopy). This
should also include report on the regression test. The final report shall, inter alia, contain:
• Present status of the pending observations of the previous audit.
• List of bugs found and key functionalities not supported, as per the current audit assignment,
segregating them as ‘critical’, ‘medium’ and ‘minor’.
• List of enhancements required and feasibility analysis of these requirements in the CBS.
• Suggestions for improvement in the performance of the software audited.
• Report highlighting gaps in input, processing and output controls with recommendations to
remedy the gaps.
• Screen dumps of testing and testing reports.
• Security process audit report and recommendations against best practices.
Report on risk analysis and risk mitigation methodologies.
Review audit report—covering the latest status at the time of review, of all the observations
made in the final audit report.
12.4.3 Deliverables: Internet Banking

The vendor should submit the following specific deliverables for Internet banking, besides those
analysis reports that are highlighted as part of the scope for internet banking and other reports as
required for IS Audit for all solutions mentioned above. The reports on the Internet banking audit
shall also be submitted in two stages, i.e. interim audit report and final audit report and on both the
occasions shall cover the following:
Report on the gaps between the mentioned documents and standards mandated by the RBI and
recommendations to comply with RBI guidelines and security practices being followed.
Vulnerability assessment report covering:
• Vulnerabilities found in all components like, network devices, operating systems,
application servers, database servers.
• Attacks and penetrations found and recommendations to address the same.
A report on all points including controls review covered under ‘Internet Banking IT
Infrastructure review/security review’ and the recommendations.
Compliance status report—After resolution of the areas where the bank was initially non-
compliant, the vendor should perform final compliance review and submit the final report as
part of the review audit report.
Certificate of level of compliance indicating complete compliance with the RBI standards as
per RBI guidelines on Internet banking vide circular no.
DBOD.COMP.BC.No.130/07.03.23/2000-1 and BOD.COMP.BC.14/07.03.29/2005-06.
The above describe the extent to which evaluation of security of the Core Banking Solution needs
to be undertaken.
The following chapters deal with the process of evaluation.
Review of Security
Policy Implementation
13.1 IMPLEMENTATION
It is imperative that there should be a security policy approved by the senior management. This should
contain policies for ensuring security of assets and information. Confidentiality, integrity and
availability need to be ensured.
In Chapter 10 of Section A, a draft security policy has been provided to illustrate the contents of a
security policy. The policy should be updated by the senior management periodically when
circumstances warrant due to change in technology or due to experience gained while analyzing
certain security incidents (i.e. incident of security lapses).
13.2 SECURITY POLICY IMPLEMENTATION

As part of audit, reviewing of implementation of security policy is important. This review will
highlight, if there are areas of non-implementation.
For example, when reviewing logical access controls auditor would review whether those who are
designated as the users by the system are still in service or resigned or retired. It is also possible
there are some users who may not have been provided access rights formally, but are using the
systems.
In both cases, it is a matter of serious concern. This type and other instances of security concerns
would be highlighted when audit of security policy implementation is performed. All aspects of
security policy need to be reviewed. In the following pages, a questionnaire is provided which would
help in formulating an approach for the review of security policy.
The questionnaire is not definitely exhaustive, but fairly detailed to be of guidance to review
effectiveness of implementation (see Table 13.1).
Security officers and inspection and audit department and others who have to discharge similar
functions would also find it useful.
Table 13.1 Questionnaire on security policy review
Sl.
Description
No
1. IS security policy
Is there a security committee?
Are roles and responsibilities identified?
Any awareness programs conducted?
Key personnel identified at each office/branch?
Are there security advisors?
Are there other contacts with external department to handle security incidents?
Are meetings held regularly?
Are purchases of new systems hardware etc., installation, test and acceptance by users handled as per policy?
Are access to third parties in line with the policy/documents/agreements?
2. Outsourcing policy
Is there an agreement/contract for outsourcing?
Are there adequate controls for such outsourced items?
3. Assets
Is there an inventory of assets (Information, software, hardware communication etc.) maintained according to their priority?
Are the ownership for such assets and maintenance of control defined?
4. Information classification
Is there classification and naming of all information, data and documents?
Are the roles and responsibilities of all participants in the information classification program defined under procedures?
Are all the sensitive information labelled as secret/confidential, etc.?
Is there a log maintained for any change in the declassifying or downgrading of secret information?
5. Personnel security
Is there an awareness among the employees about the roles in protecting the information assets?
Is there non-disclosure agreements, terms and condition available?
Is there a spokes person designated to speak on behalf of the organization?
6. User training
Is there a training program for the users in security procedures (employees and third party users)?
7. Incident handling
Is there procedure for reporting incident, incident response and action taken?
Is there evidence of incidents reported, handled, escalated and action taken, post incident analysis done?
Any logs maintained at the offices on the following:
Handling of virus and worm incidents
Handling of hacker incidents
Handling of illegal building access
Property, personal theft
8. Physical and environmental security
Is there adequate physical access controls?
Is there fire, water and physical intrusion protection?
Is the storage media well-protected?
9. Protection of information systems equipment
Are movement of equipments between office controlled?
Is there physical protection of equipments?
10. General control policy
Is there protection for consumables, office equipments, media containing sensitive information, computer peripherals?
Evidence of segregation of duties?
11. Information systems operations and responsibilities policy
Examine evidence of change control procedures followed?
12. Information system planning and acceptance policy
Is there evidence of testing information systems (IS) applications?
13. Protection against malicious software policy
Antivirus policy
Evidence of protection of unauthorized downloading software/exclusion of FDD/disabling USB and external drives.
14. Backup policy
Are backup procedures followed as per policy/evidence of compliance?
15. Network management policy
Any external connection via Internet—is it approved by security manager?
Is there an inventory of all communication equipments at all offices?
Are the movements of equipments controlled and accounted for in the inventory?
Check for the presence of router security policy, firewall security policy, website security policy, Intranet policy, e-mail policy, password
policy, and Internet access policy and verify whether configurations are accordingly managed/patches applied as per policy.
Is there an operation manual maintained by the network division?
Any training programs conducted the users?
Maintenance of master documents supplied by the network equipment vendor needs to be examined?
16. Media handling
Evidence of procedures followed in storage and destruction of secret documents etc. need to be verified?
17. Exchange of information and software
Evidence of procedures followed?
18. Electronic commerce/website security
Are the servers protected by security control like firewall, IDS/placed in a demilitarized zone?
Are suitable cryptographic techniques employed?
Are access to offensive sites blocked?
Has periodic penetration test undertaken for the web servers?
Positioning of the web server/maintenance of the site by website engineers are they as per policy and procedure?
Network application except HTTP—are they all disabled?
Is there sufficient protection of copyrights?
Evidence of no remote administration of the web server.
Evidence of using only recommended patches for the version in use.
Evidence of IDS loaded onto the server.
All web servers connected to the Internet should have a firewall between the web server and internal network.
19. EMAIL policy
Verify whether procedures followed as per policy
20. Housekeeping policy
Are operational staff logs available?
Are the logs reviewed?
Evidence of audit logs reviewed and action taken.
Evidence of Insurance cover.
Are hardware documents (operator manual and technical documentation) available?
21. Intranet policy
Evidence of procedures followed.
22. Firewall policy
Evidence of firewall logs audited for intrusions etc.
Availability of a formal process for managing additions/deletions to rules?

Is there a regular training given for the firewall and backup firewall administrators?
Verify procedures followed for handling of new releases/patches
Evidence of firewall administration carried out as per procedures
Availability of logs
23. Internet access policy
Evidence of procedures followed/policy applied
24. Router security policy
Are logs reviewed and archived for future use?
Is telnet access restricted?
Review of router configuration and backup of router configuration
Documentation of all aspects of the router
Evidence of latest patches applied
25. Alternative communications channel confirmation for transactions policy
Are digital certificates in place, or other communication channels like postal mail etc. as an alternate communication channel?
26. Access control policy
Are physical and logical access controls available according to policy?
27. User access management policy
Evidence for creating a user/allotting an ID/access/deactivating
28. Password management policy
Evidence of policy and procedures followed
29. Securing unattended equipment policy
Evidence of unattended computers being protected/time out/screen savers.
30. Network access control policy
Evidence of procedures being followed
Evidence of remote access procedures being followed
31. Operating system access control policy
Evidence of security features enabled and used.
32. Application access control policy
Evidence of control available
33. Monitoring system access and use policy
Evidence of system access logged and monitored to detect deviation from access control policy and to identify potential misuses of
systems or information.
Review of system logs.
Review of audit logs.
34. Systems development and maintenance
Are SDLC procedures followed?
35. Security requirements of new/modified/existing systems policy
Evidence of formal risk assessment done
Evidence of controls applied
36. Security in application systems policy
Are there validation and authorization controls for Inputs?
Evidence of availability of check/reconciliation/validation procedures for output

Procedures followed for process/review/testing
37. Managing electronic keys policy
Evidence of key management procedure followed
Availability of SLA (service level agreement)/contracts with external suppliers of cryptographic services.
Verify for segregation of duty and dual control, physical and logical controls.
38. Using encryption techniques policy
Presence of controls if encryption is used.
39. Using and receiving digital signatures policy
40. Managing system operations and administration policy
Evidence of system operations and administration activities are conducted in a secure manner.
Availability of audit logs.
Availability of AMC with vendors/their access/monitoring.
Evidence of controlled access to vendors/NDA from the vendors.
Evidence of patch management.
41. Managing operational executable program libraries policy
Updates only on authorized request.
Availability of audit trails.
42. Managing and controlling program source libraries policy
Availability of Escrow arrangements.
Audit trails of update to programs.
Storage of backedup copies at remote site procedures followed.
Retention of old versions.
43. Version control policy
Evidence of version control/backup and retention of older versions-procedure.
44. Using business data for testing policy
Verify the presence of strict access control.
Ensure that business information deleted after testing.
Ensure that testing and development data is isolated from business work.
45. Change control policy
Evidence of procedures followed—formal change control management procedures.
46. Software upgrade policy
Evidence of upgrades to software verified, properly tested and authorized.
Audit trail of changes maintained.
47. Supporting application software policy
Evidence of technical support provided to application software as per policy.
48. Support for operating systems policy
Evidence of regular monitoring of operating system and all house keeping routines adhered to.
Availability of AMC and SLAs with third parties.
49. Controlling software code during software development policy

Evidence of changes to programs properly authorized and tested before moving to the live environment.
50. Database security policy
Evidence of guidelines used and a procedure in place followed.
51. Business continuity management
Evidence of a BCP and procedures followed.
52. Compliance with legal requirements policy
53. Copyright policy
Availability of copyright for the application software developed in-house.
Evidence of clear understanding as to the custody of intellectual property in case of outsourcing software development by third parties.
Evidence of compliance with legal requirements.
54. Software copyright policy
Availability of licenses.
Availability of proof of adherence to policy.
55. Review of security policy and technical compliance policy
Evidence of regular review and tests conducted to verify compliance.
56. Miscellaneous policies
Risk assessment policy
Evidence of risk assessments conducted prior to changes/enhancements.
Evidence of classification of assets.
57. Audit policy
Evidence of IS audit and Internal audit conducted periodically.
58. Audit trail policy
Evidence of procedures followed for logs of computer security, relevant events provide sufficient data to support comprehensive audits of
the effectiveness of, and compliance with security measures.
Review of Business Continuity

Planning and Disaster
Recovery Planning
14.1 INTRODUCTION
It is important to verify the business continuity plan of the bank. There is a mistaken impression
sometime that business continuity plan consists of backing up of the data at the branches at the end of
the day. As mentioned in
Chapter 11 of Section A, on business continuity planning, there needs to be a detailed study to evolve
a business continuity plan. The plan document should contain all those mentioned in the annexure to
Chapter 11 in Section A.
14.2 EVALUATION OF BUSINESS CONTINUITY PLANNING

Though there may be a plan document, it is possible that the plan may remain only as a document. It is
necessary that the plan is implemented in all respects. The following questionnaire gives broad
outline of the various aspects the evaluation should cover.
Verify whether there is a plan

Verify awareness of the contents of the plan amongst the key players
Verify what scenarios of disaster have been envisaged
Study the Business Continuity Plan (BCP) for the various scenarios and assess the adequacy
Verify whether any tests have been done
Review the test reports
If any inadequacies have been found while testing, it is necessary that it should have been
documented
Verify what subsequent action has been taken to meet the inadequacies discovered while
testing the BCP
Verify whether any live disasters have taken place, e.g.
• Connectivity between the branches and the head office might have been lost
• Due to heavy rain, disaster recovery site might have been flooded
• There might have been a major fire in any of the locations
If any of these instances of disaster have taken place what was the recovery procedure? Was it
adequate?
Most importantly, it needs to be verified whether the recovery was within the Recovery Time
Period (RTP) (xx hrs/days)
14.3 EVALUATION OF BUSINESS CONTINUITY AND DISASTER RECOVERY
PLANNING OF CBS
14.3.1 Objective
The banks should have a setup to facilitate uninterrupted usage of CBS application by the branches.
Possible disaster should have been envisaged and steps taken to ensure business continuity.
Procedures to be followed would include verifying whether:
1. The Disaster Recovery (DR) site has been identified and configured to meet the processing
requirements.
2. Redundant network connectivity has been provided for all branches to the data center as well
as the DR site.
3. The data replication has been configured between the data center and the DR site (i.e. through
log shipment etc.). Is the log shipment periodicity in line with the Recovery Point Objective
(RPO) specified in the plan?
4. Has the bank tested the recovery procedure? If so, is there a document evidencing the DR
drill?
5. All the disaster scenarios envisaged (e.g: No access to CSD building and data center, main
server at DC is down, network failure etc.) have been tested?
6. During the DR drill whether the networks and servers at the DR site handled the processing as
per the banks’ requirements. That is, whether there were any performance issues.
7. Appropriate personnel have been identified for DR processes and training has been provided
to them to handle a disaster scenario.
8. Proper co-ordination between various vendors and service providers established for support
during DR?
9. All delivery channels like ATM, Internet banking etc. handled during DR?
10. Banks has plan for re-synchronisation of the DR database and the core database at the data
center? Is reverse log shipment enabled between DR and DC during the drill process? Is there
any data logs?
11. Any directory maintained of contact persons and their mobile and telephone numbers?
12. Any disaster had occurred and lessons learnt have been documented.
13. Review of plan undertaken to ensure that it is currently taking into consideration technology
changes and/or scenario changes.
14.4 EVALUATION OF BUSINESS CONTINUITY PLANNING OF ATM

14.4.1 Objective
The bank should have a setup to facilitate uninterrupted usage of ATM. Possible disasters should
have been envisaged and steps taken to ensure business continuity.
Procedure to be followed would include verifying whether:
1. The application server and database server are configured in such a manner that in the event of
one failing the other will take over.
2. Verifying with what frequency data from data center is replicated to disaster recovery site.
3. Verifying whether application backup is taken whenever any changes are made.
4. Verifying whether there is any concern of ‘single point of failure’, like availability of one
router only and no standby router being available.
5. Verifying whether there is a proper procedure and service level agreement with IDRBT so
that traffic will be routed to the disaster recovery center in case disaster has been declared at
the primary center?
6. Verify whether there is a facility for other banks also using the client bankers ATM facility. In
such cases verify whether measures are in place so that third party connectivity will not be
lost. This would happen if third party links terminate at primary data center only with no such
facility at disaster recovery site.
14.4.2 Evaluation of Disaster Recovery of ATM

Verify the disaster recovery drill activity reports. It is necessary that these reports be maintained so
that experience gained and or any shortfalls noticed could be taken care of. A template of a disaster
recovery drill activity could be as follows:
DR activity—Segment
Date and time of activity
DR activity planned
Level of DR activity/test
Failure scenario if any simulated in the test
Nature of down time, if any
Duration of down time
Details of approval obtained for taking a down time
Third parties involved
Activity involved
Team members at DR site
Final outcome of activity
Brief account of the activity planned to be conducted
Brief account of the activity that could be completed
Problems faced during the DR activity
Whether problems faced have been reported to higher authorities immediately?
After reporting whether any decision points have been arrived at for conclusion of the
activity/test?
Any shortcoming found in the hardware set up
Any shortcoming found in the application
Any shortcoming found in the DR procedure itself
Data loss if any due to the DR activity
Whether all the recovery mechanisms have been taken up to reduce the data loss
In case of activity involving switching over from primary to DR site whether the same was
smooth or whether any problems faced?
In case of an unscheduled activity, which of the persons/agencies could not be contacted for
response?
Whether proper alert has been given to such persons/agencies subsequently?
Activity details documented
Details of deviation if any from the prescribed/specified DR drill document
Action points arising out of the present DR activity
Action owner for rectification/compliance of the above action points
Co-ordinator for the above rectification/compliance
Probable deadline for above compliance (Approximately)
Whether the DR activity has helped in augmenting the DR capacity of the bank and if so
provide details?
The Disaster Recovery (DR) drill are not conducted regularly in all banks. Even if conducted, no
document giving details of the drill are maintained. At the most, it may be contained in the personal
diaries of the concerned members of the staff. Procedures should be in place to ensure that contents of
‘Redo log file, the DBMS’ are taken. As it is time consuming, there should be adequate procedures in
place so that in case of a sudden disaster when data and Redo log files are not available, alternate
procedures are in place.
14.5 VERIFICATION OF BUSINESS CONTINUITY PLANNING AND DISASTER

RECOVERY PLANNING FOR INTERNET BANKING PROCESS
Generally the Internet banking functions would include the following:
1. Balance enquiry
2. Transaction history details
3. Request for
(a) Chequebook
(b) Demand draft
(c) Fund transfer
4. Payment
(a) For taxes
(b) For insurance
5. Stop payment instruction
The process for evaluation of effectiveness of Business Continuity Planning (BCP) would include
the following:
1. Verifying what backup and standby is implemented for Database server. Ensure its adequacy.
2. Verifying whether there is a standby server for web server.
3. Reviewing current backup mechanism for its effectiveness.
4. Verifying whether there is redundant power supply for web server and database server? In the
absence of adequate power supply, Internet operations would be affected and the recovery
time objective may be exceeded.
5. Verifying whether web server is configured at the disaster recovery site also.
6. Verifying whether asynchronous replicator is configured to ensure data loss is minimal.
7. Verifying whether established procedures are in place for reverse replication. This process
consists of replication from disaster recovery site to data center soon after database server
and web servers are brought up after disaster. This alone would ensure continued data
integrity.
8. Review service level agreements with third party service providers to ensure they include
procedures envisaged for backup and recovery of data.
14.6 EVALUATION OF BUSINESS CONTINUITY PLANNING AND DISASTER

RECOVERY PLANNING OF INTEGRATED CASH MANAGEMENT SYSTEMS
Integrated cash management system is used for fast collection and payment of cheques and demand
drafts on behalf of corporate customers.
This service may be rendered even for banks which do not have a local network.
The evaluation procedures would include the following:
1. Verifying whether redundancy has been built for application

servers.
2. Verifying the procedure for database backup.
3. Verifying whether an additional copy of database is maintained offsite.
4. Verifying whether site level redundancy has been built.
5. Verifying whether an application and database server is available at the disaster recovery
site.
6. Verifying whether asynchronous replication is being done to ensure that data at disaster
recovery site and data center are exact copies?
7. Verifying whether procedures are in place for replication of data from data center to disaster
recovery site and also provision for reverse replication after disaster?
8. Verifying whether service level agreements with third party service providers envisage the
conditions envisaged in disaster recovery, specially keeping in mind, the recovery.
Systems Development and

Change Management
15.1 EVALUATION OF CONTROLS IN SYSTEMS DEVELOPMENT AND CHANGE
MANAGEMENT
Systems development refers to the process of developing software which along with the proposed
hardware will produce the required output from the input that is provided by the organization. In a
core banking solution, software will consist of many modules.
As mentioned in the earlier section of the book a core banking solution could be purchased from a
third party vendor or developed inhouse. The computer systems department, by whatever other name
it may be called, would have a systems development team. Generally in banks, the team would
consist of individuals with in-depth knowledge of banking operations and also of individuals who
have the adequate technical knowledge. It is essential that there should be adequate documentation.
The purpose of Systems Development Life Cycle (SDLC) audit is to assess the extent to which the
systems (whether supplied by the third party vendor or inhouse developed) meet the deliverables
identified and approved by the management. The objectives of the audit would include assessing:
Whether business process and systems are designed and implemented with adequate internal
controls?
Whether the required business functionality is achieved?
Whether the project team is using a structured approach for monitoring systems development
activity, systems quality and adherence to organisation policy.
The Information Systems Audit Control Association of USA (ISACA) has published auditing
standards, guidelines and procedures. Standards are mandatory. The guidelines while may be
followed, the onus is on the systems auditor to justify any deviation from the guidelines.
The guideline No. 23 of ISACA deals with Systems Development Life Cycle reviews. The
Guideline envisages that during SDLC of an application, various risks could be encountered
which include the following:
• Inadequate controls in the SDLC process
• User requirements and objectives not being met by the application system
• Lack of management support
• Inappropriate technology and architecture
• Scope variations
• Time over runs
• Cost over runs
• Insufficient attention to security and controls (including validations and audit control in the
application systems)
• Insufficient documentation
• Inadequate contractual protection
• Inadequate adherence to chosen SDLC/development methodology
• Insufficient attention to inter-dependency on other applications and processes
• Inadequate configuration management
• Insufficient planning for data conversion/migration post cut-off
• Disruption of business
15.1.1 Evaluation of Controls in System Development Methodology Prevalent in the Banks

In a banking scenario, there could be two possible alternatives. The management of the bank may
requisition audit after implementation, or while in the process of being implemented.
Generally speaking, it is always advisable to evaluate the procedures adopted in Systems
Development Life Cycle (SDLC) before a system is implemented as this would facilitate proactive
steps to be taken as regards setting right the lack of functionality, as also internal controls. This would
also minimise the security concerns for the organization apart from the costs also being reduced. The
changes to be made after the system has been completed would require far more effort and cost and in
the process, the structure of the system could get altered to such an extent that it could get weakened
by too many patches being applied.
The IS audition should study the systems documentation to get a clear understanding of
hardware configuration, the contents of the various modules of the total system and their inter-
dependence.
In this chapter, our attention would be more on the SDLC methodology being tested before the
system goes live.
Quite a few progressive banks have taken the initiative to have the SDLC methodology to be
critically reviewed and tested either by an independent team of systems auditors internally or by
appointing competent third party systems auditors. The procedures to be followed would be to verify
that there is a formal procedure in existence for the following activities.
1. Formal request for system requirement by an authorized person.

2. There is a procedure for the development team to systematically translate the requirements of
the business process into a deliverable of the system.
3. The crux of the situation is that the deliverables of the system should be in line with the
requirements of the user department and also the process of obtaining these deliverables,
should be user-friendly.
4. The testing of the modules would be done in a test environment, when a separate test server
would be provided and the server would be having the same operating system and the exact
copy of software which could be verified by the version no. of the software as developed and
ready for the implementation.
5. Each of the modules would be tested for functionality, and adequacy of internal controls.
6. It is quite normal in the initial stages to find some bugs in the programs/ software. It is
necessary to document each one of the inadequacies. The normal procedure is to serially
number each one of them and maintain a log of the same so that follow-up action is facilitated.
It needs to be noted that making out a list of software bugs and the process of setting them right
and testing the system again to satisfy that they have been debugged properly is an iterative
process.
Also it should be noted that whenever a program has been changed to set right a particular bug, the
entire program should be tested (it is called regression testing) to ensure that the changed program has
not been affected in any adverse manner and that it continues to perform in the same manner in which
it was performing before the change was effected.
It is also not uncommon to come across such instances when due to a program change being
effected, the program which was working satisfactorily prior to the change, could malfunction due to
the improper implementation.
Each of the modules will have to be tested extensively. The test data would have to be
comprehensive and exhaustive so as to ensure that all aspects of the module are tested effectively. For
example, the systems acceptance of negative values, pre-dated entries, post-dated entries, all are of
equal importance. The system should be tested to ensure that it does not fail under any circumstance.
15.1.2 Process of Moving a Tested Program from a Test Environment to a Production

Environment
Production environment
As already discussed in the chapter dealing with the organization structure of the computer systems
department, development department and production department should be totally isolated. Under no
circumstances should any of the team members of the development have access to the production
environment. The programs developed and tested by the different members of the development team
are cleared by the project leader and then handed over to the librarian. The librarian maintains a
record of the programs. He has a structured methodology of numbering them and storing them in a
library file taking adequate steps to ensure that effective backup procedures are in place.
The fully tested and approved version of the program is then migrated from the development
environment to the production environment.
Change management
A software, however well developed, and in use for quite sometime, may require to undergo changes
under any of the following circumstances:
1. User requirement change

2. The functionality as contained in the program may require modifications to improve controls
and performance.
3. The technology change may warrant certain software changes.
There needs to be a procedure to have a control on change management The following should be
considered:
1. The use and existence of a methodology for authorizing and prioritizing change requests from
the user department.
2. Verifying whether there is a formal procedure for change controls for both the user and the
development team.
3. Whether the change control log ensures that all changes shown were resolved (It is likely that
it may be only partially resolved).
4. Whether emergency change procedures are addressed in the operations manual (It is a
practical situation that all organizations will face after a system is implemented).
5. There would be emergency situations when a change would require to be made immediately
without there being adequate time to comply with the structured procedures for change
management. This situation needs to be envisaged and procedures put in place.
6. The best practice is that the change is effected in a controlled environment and the situation
under which emergency procedure have been invoked is documented. Soon after the
emergency has been tackled, the formal procedures which should have been adopted for a
change would be gone through and a formal testing process would be complied with. The
results obtained after the emergency changes were effected, would be compared with those
obtained after the change control procedures have been formally implemented. This would
ensure that emergency changes though unavoidable are controlled and well-documented.
Example: The fixed deposit product may have to be implemented within a very short time. A new
home loan product may need to be implemented to beat the competition.
In this connection, the adequacy of the security access restrictions over the use of the emergency log
on ID need to be reviewed. Only certain personnel should be authorized. They only should have a
right to exercise emergency log on ID.
Change management
All instances of changes made should be recorded through a change control software or a register.
The log should be reviewed critically bearing the following points in mind:
(a) Ensure that changes to requirements resulted in appropriate change development documents such
as program operations document.
(b) Ensure that the changes were made as documented. Instances are not rare when all changes may
not be documented or documented changes may not represent the actual changes.
(c) In view of the above, determine whether current documentation reflects the changed environment.
(d) Verify the adequacy of procedures being followed for testing changes to system e.g. Regression
testing—testing the whole program again and not only the change.
(e) Review critically the documents evidencing test plans and test results to ensure that best practices
and as laid down in organizational standards are in force.
(f) Verify the library procedures in place which ensure the integrity of source code and executables of
software. Procedures for movement of files and access rights to library need special review. Special
attention needs to be paid to ensure incompatible functions are not clubbed in the responsibility of
one individual.
(g) Review whether every production executable version of the software is supported by an
appropriate authorized version of source code?
(h) Defective compliance of standard library procedures may result in a wrong executable being
loaded in the production version though correct version of changed source code is available.
(i) Absence of procedures, wrong or defective compliance of accepted best practices are likely to be
explained away as computer problems!
Network Security
16.1 INTRODUCTION
In a core banking solution (CBS) there is a complicated and complex network system. Performing a
vulnerability assessment is extremely essential. The vulnerability arises due to some ports which
should never be opened are kept open or due to patch updation not being done regularly to the
operating systems, database management system (DBMS) or networking components like the
firewalls, routers and switches.
16.2 NETWORK VULNERABILITY ASSESSMENT

To perform vulnerability assessment, it needs technical competence and it is not possible otherwise.
Generally, a technical team of the auditor which would include a certified ethical hacker would
perform the vulnerability assessment using a tool for that purpose. The tool at the end of performing
the vulnerability assessment will come out with a report classifying the vulnerabilities as ‘High’,
‘Medium’ and ‘Low’. The technical team will also provide a report on the significance of the
vulnerabilities and the corrective action to be taken.
While performing an evaluation of security of network, it is necessary to call for the vulnerability
assessment report and the corrective action taken thereon. In the event of the vulnerability assessment
not having been performed or worse still, the vulnerabilities being allowed to continue in spite of
being aware of the sensitivity and seriousness of the situation, it is a matter of major security concern.
Unauthorized access could be made to the network and thus, to the application servers or the
database server or ATM server etc., and the system could be brought down. The integrity of the data
and the credibility of the system can become questionable. In view of the seriousness of the situation,
it is essential to verify whether a vulnerability assessment has been performed, call for the reports
and verify whether the action has been taken. The intruders would be looking for the holes in the
system so that they could penetrate it. In a scenario of a core banking solution, where the whole lot of
banking operations are expected to be done on the net, the need for strengthening the network can
never be over-emphasized.
Reserve Bank of India (RBI) used to previously insist that before a bank is permitted to implement
Internet banking, it needs to obtain a certificate from a competent person like a Certified Information
Systems Auditor (CISA) qualified individual with network experience. To certify that the network
connected with the application is robust, the Intrusion Detection System (IDS) and the Intrusion
Prevention System (IPS) would be evaluated by an auditor and a report given, either certifying the
adequacy of controls or report on the weaknesses and corrective action to be taken. RBI is now
insisting on the same only when transactions are going to take place on the internet and not for mere
viewing of statements etc. The system would be rechecked again after the corrective action has been
implemented and the final certification giving clearance for implementing Internet banking would be
provided and forwarded to the Reserve bank of India (RBI) to give permission for the implementation
of Internet banking.
As a matter of routine, while performing systems audit, a competent person should review the
vulnerability assessment reports, and prepare report appropriately on the same. In the following
paragraph a sample Vulnerability Assessment Report is provided wherein the vulnerabilities detected
during the performance of the Vulnerability Assessment Test have been highlighted and
recommendations for corrective action have been provided. It is essential to take such corrective
action and perform vulnerability assessment again to make sure that all the necessary steps are taken
to secure the network.
In a data center, having many servers, routers, switches and firewalls, it is essential to perform
Vulnerability Assessment Test for each one of them.
16.2.1 Sample Vulnerability Assessment Report

We conducted Vulnerability Assessment (VA) of your system covering the following servers and
router by logging through your Local Area Network (LAN). The vulnerability assessment was done
using VA tool. We enclose our detailed report. This sample report refers to the vulnerability
assessment done again after the initial vulnerability assessment when vulnerabilities were reported.
Server Type IP Address
Domain server.............XXX.XXX.XXX.XXX
Mail server..................XXX.XXX.XXX.XXX
ATL server..................XXX.XXX.XXX.XXX
Unix server..................XXX.XXX.XXX.XXX
Router..........................XXX.XXX.XXX.XXX
A soft copy of the detailed report has been handed over to your systems department for taking
appropriate action. In the detailed report vulnerabilities are classified into:
Holes........................Severe flaw, hence high risk

Warnings..................Mild flaw, hence medium risk
Notes........................Information, hence low risk
Our summarised observations are based on the Windows version of the VA tool. (See Table 16.1).
Table 16.1 Comparative Statement of High Risk Vulnerability
IP address Results of Results of
Name
through LAN latest VA earlier VA
xxx.xxx.xxx.xxx Domain server 2 0
xxx.xxx.xxx.xxx Mail server 2 0
xxx.xxx.xxx.xxx Database server 10 1
xxx.xxx.xxx.xxx Unix server 13 9
xxx.xxx.xxx.xxx Switch 0 0
Observation
The high risk vulnerability has increased considerably and immediate action is required for updating
with suitable patches.
A. Domain server
1. KPASSWD (464/tcp): This service is used for changing the password for Kerberos
Authentication System. We understand that the company is not using Kerberos.
Recommendation: Since this service is vulnerable to attacks, the same may be disabled.
2. Microsoft-ds (445/tcp): Arbitrary code can be executed on the server by an unauthorized
person with system privileges. The server is vulnerable to a buffer overrun.
Recommendation: Apply Microsoft set of patches for Windows 2000, XP and 2003.
B. Mail server
1. SMTP (25/tcp): The remote Simple Mail Transport Protocol (SMTP) server can be disabled
by a malicious message which will crash the system.
Recommendation: Simple mail transport protocol message transfer agent is the most
important mail transfer agent in the domain environment and is vulnerable to external attack
and hence, we recommend that it should be reconfigured or upgraded.
2. Microsoft-ds (445/tcp): The version of Windows contains a flaw in the Server Message
Block (SMB) implementation which may allow an unauthorized person to execute arbitrary
code on the server.
Recommendation: Apply Microsoft patches for Windows.
C. Database server
1. Name (42/tcp): The remote Windows Internet Naming Service (WINS) has a flaw which
could allow an unauthorized person to execute arbitrary code on this host.
Recommendation: Apply patches.
2. PCG-Radar (1036/tcp): The remote version of Windows contains a version of Microsoft
Data Transaction Coordinator (MSDTC) service which is vulnerable to several remote code
execution and denial of service vulnerabilities.
An unauthorized person may obtain the complete control of the server (2000, NT4) or crash
the remote service (XP, 2003).
Recommendation: Apply Microsoft set of patches for Windows 2000, XP and 2003.
3. Microsoft-ds (445/tcp)
• An unauthorized person who can execute code on the server can crash the print spooler
service (PSS).
• The remote version of Windows contains a flaw in the Server Message Block (SMB)
implementation which may allow an unauthorized person to execute arbitrary code on the
server.
• It is possible to anonymously read the event logs of the remote Windows 2000 host. An
unauthorized person may use this flaw to anonymously read the system logs of the server. As
system logs typically include valuable information, an unauthorized person may use them to
perform a better attack against the server.
• Arbitrary code can be executed on this server due to a flaw in the ‘server’ service. This has
a vulnerability of heap overflow in the ‘server’ service which may allow an unauthorized
person to execute arbitrary command with the ‘system’ privileges. In addition to this, the
server is also vulnerable to information disclosure vulnerability in SMB which may allow the
person to obtain portions of the memory.
• The arbitrary code can be executed on this server due to a flaw in the ‘server’ service which
will lead to a buffer overflow attack.
Recommendation: Install suitable Microsoft security patches.
4. EPMAP (135/udp): Security vulnerability exists in the messenger service that could allow
arbitrary code execution on an affected system. An unauthorized person who successfully
exploited this vulnerability could run code with local system privileges, or could cause the
messenger service to fail.
Recommendation: Disable the messenger service.
5. Unknown (7938/tcp): A backup software namely ‘Legato’ is running, which has inherent flaw
which will not prevent an unauthorized person from executing a malicious program that could
bring down the system. This was reported in our early vulnerability report also.
Recommendation: Apply patches for the backup software. If this service is not needed,
disable it or filter incoming traffic to this port.
6. Netbios-ns (137/tcp): Arbitrary code can be executed on the server as the server is running a
windows internet naming service (WINS).
Recommendation: Apply security patches.
D. UNIX SERVER
1. FTP (21/tcp): An FTP (File Transfer Protocol) server is running, which is vulnerable to the
‘glob heap corruption’ flaw. An unauthorized person may use this problem to execute arbitrary
commands on this host.
Recommendation: Upgrade ftp server software to the latest version.
2. SMTP (25/tcp): The send mail server in the Unix system has the following vulnerabilities:
An unauthorized person can execute an arbitrary code and cause:
• A ‘buffer flow’ in the DNS handling code
• Buffer overflow and gain ‘root privileges’
• Local privilege escalation when using forward files
• ‘-bt overflow attack’ which allows any local user to execute arbitrary commands as root.
Recommendation: Upgrade the send mail to the latest version.
3. SHELL (514/tcp): It is possible to remotely log into this server using the account ‘atufin’!
without a password or the account is mis configured in ~/.rhosts.
Recommendation: Remove ~/.rhosts or set a password.
4. Sometimes-rpc9 (32773/tcp): The server is running the sadmind Remote Procedure Call
(RPC) service. It is possible to misuse this service to execute arbitrary commands on this
system as root.
Recommendation: Disable this service as Sun does not intend to provide a patch.
5. Sometimes-rpc13 (32775/tcp): The tooltalk RPC service is running.
A possible implementation fault in the ToolTalk object database server may allow an
unauthorized person to execute arbitrary commands as root.
Recommendation: Disable this service.
6. Unknown (32782/tcp): The remote Remote Procedure Call (RPC) service 100249 may be
vulnerable to a heap overflow which allows any user to obtain a root shell on this system.
Recommendation: Disable this service
7. SNMP (161/udp): It is possible to obtain the default community names of the remote SNMP
server. An unauthorized person may use this information to gain more knowledge about the
server, or to change the configuration of the remote system.
Recommendation: Disable the SNMP service on the server if not used. Or filter incoming
UDP packets going to this port, or change the default community string.
Evaluation of Controls in
Operating System
17.1 INTRODUCTION
The Operating System (OS) is a set of computer programs that manage the hardware and software
resources of a computer. These operating systems act as the resource manager. These systems manage
input-output devices, the central processor and all of the files containing information. Figure 17.1
broadly describes the role played by the operating system.
Figure 17.1
The operating system is like a traffic constable. It makes sure that different programs and its users
using the computer at the same time do not interfere with each other. The operating system provides a
software platform on top of which other programs known as ‘Application Programs’, can run.
Operating system is also responsible for the security, ensuring that the unauthorized users do not
access the system.
17.2 AUDIT OF OPERATING SYSTEM

The security features of operating systems ensure that data stored in a computer cannot be accessed by
any users unless they are specifically authorized to do so. A user might be granted ‘Read Access’ to a
file. It means that the concerned user can only read the file, but cannot modify or delete it. There are
different operating systems, e.g. WINDOWS, LINUX, UNIX etc.
An operating system is loaded into the computer by a Boot program. The application programs
make use of the operating system for making requests for services through the Application Program
Interface (API). A system administrator/user can also interact directly with the operating system
through a user Interface, e.g. Graphical User Interface (GUI). The privileges of the systems
administrator are far greater than that of the normal user. It is essential when performing evaluation of
controls that the adequacy of security settings of the relevant operating system are critically reviewed.
Procedure for configuring security settings for different operating systems will vary and it is essential
that the evaluator should possess adequate knowledge. This information would be available in the
administrator’s guide to the operating systems. These are also available on the Web. In the following
paragraph, for ease of understanding security settings, we consider WINDOWS 2003 Operating
System.
17.3 POLICIES OF OPERATING SYSTEMS

Operating system contains a whole list of policies and the system administrator administers the
policies subject to the facilities available and the need of the organization. The administrator guide
which forms part of the documentation and is made available along with the operating system,
provides important information regarding the policies that are available and the implications of the
security settings. Some of the policies are mentioned herein below:
17.3.1 Hardening Mechanism

This deals with the procedures to be adopted to ensure that all up to date patches as available are
applied to the operating systems. It also involves a process of disabling unnecessary services or
facilities. Deployment of patches is an ongoing process as it deals with solutions as and when more
vulnerabilities or holes in the security are discovered. Hence, it is essential to be aware of the latest
patches that are available. There are recommended procedures for applying the patches.
Windows 2003 server hardening check-list
No operating system comes configured securely out of the box. For all the available operating
systems, there should be associated procedures for hardening them. Given below is the password
hardening procedure for Windows 2003 server. The procedures should provide the reader an
opportunity to gain knowledge of the nature of action to be taken for hardening an operating system.
1. Install the latest service pack from http://windowsupdate.microsoft.com. Keep up to date on

service pack releases.
2. Install the appropriate post service pack security.
Configure local accounts are as follows:

1. Guest account is to be disabled.
2. Enable account lockout on the local administrator account. Rename the local administrator
account to something other than the administrator. Ensure that the local administrator
password meets the complexity requirements.
3. Disable or delete unnecessary accounts.
4. Disable unnecessary services.
5. Set stronger password policies.
6. Prevent the last logged in username from being displayed.
7. Configure strong audit policy.
8. Install antivirus software and update.
9. Configure appropriate settings for access control on file shares.
10. Protect the registry from anonymous access.
11. Set up the event logs.
There are various policies which need to be configured based on the security requirements of the
bank.
17.3.2 Domain Policy

The Domain Policy deals with the following:
Overview of the domain policy

Account policies
Password policies
• Password policy settings
Enforce password history
Maximum password age
Minimum password age
Password must meet complexity requirements
Store password using is reversible encryption
• How to prevent users from changing a password except when it is required.
Account lock out policy
• Account lockout policy settings
Account lockout duration
Account lockout threshold
Reset account lockout counter as per duration set
Kerberos policies
Security options
• Security options settings
Microsoft network server: Disconnect clients when logon hours expire
Network access
Network security
17.3.3 Member Server Baseline Policy
The member server baseline policy deals with the following:
Overview
Windows server 2003 baseline policy
Audit policy
• Audit account logon events
• Audit account management
• Audit logon events
• Audit object access
• Audit policy change
• Audit privilege use
• Audit process tracking
• Audit system events
User rights assignments
• Access this computer from the network
• Act as part of the operating system
• Adjust memory quotas for a process
• Allow log on locally
• Allow log on through terminal services
• Backup files and directories
• Managing auditing and security log
Security options
• Accounts settings
Accounts : Administrator account status
Accounts : Guest account status
Accounts : Limit local account use of blank passwords to console logon only
• Audit settings
Audit : Audit the access of global system objects
Audit : Audit the use of backup and restore privilege
Audit : Shut down system immediately if unable to log security audits.
Devices settings
Domain member settings
Interactive logon settings
• Interactive Logon : Display user information when the session is locked
• Interactive Logon : Do not display last user name
• Interactive Logon : Do not require CTRL+ALT+DEL
• Interactive Logon : Message text for users attempting to long on
• Interactive Logon : Message title for users attempting to long on
• Interactive Logon : Number of previous logons to cache (in case domain controller is not
available.)
• Interactive Logon : Prompt user to change password before its expiration
Microsoft network server settings
Network access settings
Network security settings
Shutdown settings
System settings
• System settings : Optional subsystems
• System settings : User certificate rules on Windows executables for software restriction
policies
Event log
• Maximum application log size
• Maximum security log size
• Maximum system log size
• Prevent local guests group from accessing application log
• Prevent local guests group from accessing security log
• Prevent local guests group from accessing system log
• Retention method for application log
• Retention method for security log
• Retention method for system log
Additional security settings
• Manual hardening procedures
17.3.4 The Domain Controller Baseline Policy
Overview
• Domain controller baseline policy
Audit policy settings
• Audit directory service access
User rights assignment Settings
• Access this computer from the network
• Add workstations to domain
• Allow log on locally
• Allow log on through terminal services
• Change the system time
• Enable computer and user accounts to be trusted for delegation
• Load and unload device drivers
• Restore files and directories
• Shutdown the system
Security options
Event log settings
Restricted groups
Additional security settings
There are other servers like the infrastructure server, file server, print server, web server, Internet
Information Services (iIs) server, certificate services server and the bastion host which require
suitable operating system hardening procedures to be followed.
Windows 2003 server hardening guide has several appendices of which are some listed below:
Appendix A to this document deals with security tools, its configuration and formats.
Appendix B deals with key settings to be considered for hardening the operating system. Many
security countermeasures and security settings are discussed. It keeps emphasizing on a few of them
which will have the biggest impact.
Appendix C provides a templates summary.
Appendix D deals with testing the Windows 2003 security that includes test methodology, types of
tests and bug classification.
17.4 PROCEDURE FOR EVALUATING THE SECURITY SETTINGS OF OPERATING

SYSTEM
The evaluator should prepare a template for the best recommended security settings. This template
should be used for benchmarking against the security settings that are in existence in the banks’
departments, both at the data center and the disaster recovery center.
The administrators create an audit policy appropriate to the bank that defines which security events
get reported. He can monitor security related activity, e.g. who accesses an object if he logs on to or
from a computer or if changes are made to an audit policy setting. In the absence of an audit policy, it
would be very difficult to establish what took place during a security incident. Very often failure logs
are more important than success logs, e.g., unsuccessful attempts to log on to a computer even after
three attempts indicates that some unauthorized access is being attempted and the user does not have
user ID or password.
In the following paragraphs, for ease of understanding illustrative security settings of WINDOWS
2003 Operating System is given (though they represent more or less the same in most operating
systems).
More details are available at http://go.microsoft/twlink/?linkld=15159.
An illustrative audit policy setting is as follows:
Audit account log on events..........Success/Failure

Audit account management............Success/Failure
Audit logon events..........................Success/Failure
Audit object access..........................Failure
Audit policy change........................Success
Audit privilege use..........................Failure
Audit process tracking....................No auditing
Audit system events........................Success
In all the above cases only the environment ‘Specialised security—limited functionality’ has been
considered. In legacy client and enterprise client environment, the setting may vary.
17.4.1 Audit Account Logon Events

This policy setting determines whether to audit each instance of a user who logs on or off from
another computer that validate the account.
The audit account logon events setting is configured according to the environment, as mentioned
earlier. ‘The guide by MICROSOFT provides information in the form of a table mentioning the
important security event in the security log (see Table 17.1).
The events are identified by an ‘Event ID’ number and the corresponding description is provided.
While there are about ten event IDs, for illustration purposes, three of these IDs along with its
corresponding event description are given below:
Table 17.1 Event IDs and corresponding description
681.........Logon failure. A domain account logon was attempted. This event is only generated by
domain controllers.
682........A user has reconnected to a disconnected terminal server session
683........A user disconnected a terminal server session, but did not log off
17.4.2 Audit Account Management

This policy setting determines whether to audit each account management event on a computer.
Some examples of account management events include the following:
A user account or group is created, changed or deleted

A user account is renamed, disabled or enabled
A password is set or changed
It is important that at an appropriate senior level in the organization structure, decisions are taken
as to who creates, modifies or deletes both domain and local account.
Unauthorized changes give room for security concern. The logs help to determine which accounts
have been unauthorizedly modified or created. This could be by mistake or intentional. Whatever be
the cause, the logs should be generated and reviewed.
The guide envisages more than thirty event IDs. For each such event ID, corresponding event
description is shown.
A few of the event IDs and event description are provided below:
Table 17.2 Event IDs with event description
Event IDs Event description
624 A user account was created
627 A user password was changed
628 A user password was set
630 A user account was deleted
631 A global group was created
645 A computer account was created
A local security group with security disabled was created.
648 Note: SECURITY_DISABLED in the formal name means that
the group cannot be used to grant permissions in access checks
17.4.3 Audit Log on Events
This policy setting determines whether to audit each instance of user log on and log off from a
computer. The audit log on events setting generates records to monitor domain account activity. If ‘No
auditing is set’, it is difficult to determine which user has logged on or attempted to log on computers
in the organization. However, if ‘success’ value of the audit log on events is set, an event will be
generated each time if someone logs on to the network.
The audit log on event setting is configured in legacy clients and enterprise clients. Table 17.3
includes important security events that this policy setting records in the security log.
Table 17.3 Important security events recorded in the security log
Event IDs Event description
528 A user successfully logged on to a computer
529 Logon failure. A logon attempt was made with an unknown user name or a known user name with a bad password
530 Logon failure. A logon attempt was made outside the allowed time
531 Logon failure. A logon attempt was made using a disabled account
532 Logon failure. A logon attempt was made using an expired account
535 Logon failure. The password for the specified account has expired
539 Logon failure. The account was locked out at the time the logon attempt was made.
Note: The WINDOWS Server 2003 Guide mentions many more security setting events.
17.4.4 Audit Object Access

The audit object access setting determines whether to audit the event when a user accesses an object,
e.g. a file, ledger, registry, key or printer that has a specified system access control list. The list
comprises access control entries. Each of the access control entries contains three pieces of
information as mentioned below:
The security principle (user, computer or group) to be audited

The security access type to be audited (with a access mask)
The flag to indicate whether to audit failed access event, successful access event or objects.
Table 17.4 includes some of the important security settings:

Table 17.4 Important security settings
Event
Event description
ID
560 Access was granted to an already existing object
An attempt was made to open an object with the intent to delete it.
563
Note: This event is used by file systems when the FILE-DELETE_ON_CLOSE flag is specified in Createfile().
564 A protected object was deleted.
A permission associated with a handle was used.
567 Note: A handle is created with certain granted permissions (such as read and write). When the handle is used, upto one audit is
generated for each of the permissions that were used
568 An attempt was made to create a hard link to a file that is being audited.
569 The resource manager in authorization manager attempted to create a client context.
A client attempted to access an object.
570
Note: An event will be generated for every attempted operation on the object.
572 The administrator manager initialized the application.
801 Role separate enabled.
Note: The complete table consists of almost 30 events.
17.4.5 Audit Policy Change

This policy setting determines whether to audit every incident of a change of user rights, assignment
policies, trust policies or the audit policy itself.
The recommended settings would allow one to see any account privileges that an attacker attempts
to escalate, e.g. if they try to add debug program privileges or the backup files and directory
privileges. Table 17.5 includes some of the important security events that this policy setting records
in the security log.
Table 17.5 Important security events
Event ID Event description
608 A user right was assigned.
609 A user right was removed.
610 A trust relationship with another domain was created.
611 A trust relationship with another domain was removed.
612 An audit policy was changed.
614 An IPsec policy agent was disabled.
621 System access was granted to an account.
622 System access was removed from an account.
Note: The table includes many other settings.
17.4.6 Audit Privilege Use

This policy setting determines whether to audit each exercise of user right. If it is configured using the
setting to log success value, audit entry will be generated each time that a user right is exercised
successfully and vice versa.
The audit logs are not generated when the following user rights are exercised even if the audit
privilege is configured, because these user rights generate many events in the security log. Also the
performance of the computer is likely to be affected.
Debug programs
Create a token object
Replace process level token
Generate security audits
Backup files and directories
Restore files and directories
Table 17.6 gives some of the important security events which this setting records in the security
log.
Table 17.6 Security events recorded in security log
Specified privileges were added to a user’s access token
576
Note: This event is generated when the user logs on
577 A user attempted to perform a privileged system service operation
578 Privileges were used on an already open handle to a protected object
17.4.7 Audit Process Tracking

This policy setting determines whether to audit detailed tracking information for events such as
program activation, process exit etc. Generally, the Audit Process Tracking setting is configured to
‘No Audit’, as much volume of information would be generated. However, this policy setting can be
very helpful during an incident response, because it provides a detailed log of the processes that are
started and the time when each one was launched. Table 17.7 includes some of the important security
events that this setting records in the security log.
Table 17.7 Description of events recorded in security log
592 A new process was created
597 A data protection master key was recovered from a recovery server
598 Auditable data was protected
599 Auditable data was unprotected
601 A user attempted to install a service
17.4.8 Audit System Events

This policy setting determines whether to audit when a user restarts or shuts down a computer or
when an event occurs that affect either the computer security or the security log. If the policy is
configured to log success value, the audit entry is generated when the system event is executed
successfully. If it is configured for log in failure event, the audit entry is generated when a system
event is attempted unsuccessfully.
Table 17.8 includes the most useful successful events for the setting.
Table 17.8 Useful successful events
Event
Event description
ID
514 An authentication package was loaded by the Local Security Authority.
Internal resources that were allocated to queue of security event messages have been exhausted and the loss of some security event
516
messages has occurred.
517 The audit log was cleared.
A process is using an invalid Local Procedure Call (LPC) port in an attempt to impersonate a client and reply or read from or write to a
519
client address space.
Testing of Application Modules of Core Banking

Solution
18.1 INTRODUCTION
This chapter deals with an approach to test the functionality controls of the different modules for the
banking software. In Chapter 6, a brief description of the business process of the different modules
for the banking software has been provided. As explained earlier, it may not be exhaustive but
provides an approach to understand the basic functionalities. Before the testing of any of the programs
from the point of view of evaluation of controls, it is essential to have a good knowledge of the
functionality as also the appropriate controls. It is essential to translate one’s general understanding
of the controls into controls to be built into the system.
This chapter considers the various modules of banking software considered earlier and provides
guidance of how to proceed with the testing and evaluation of the controls. As all of us are aware,
testing of software should never be done in live environment. It should necessarily be done in a test
environment. Also it is important, that the exact version/release of the software in the live
environment is loaded in the test environment so that the exercise of evaluating the adequacy of
controls is effective and meaningful.
The report prepared after the exercise of testing the software would contain any deficiency in the
functionality of the software (as compared with the business requirements) as also any deficiency in
the built in controls. The report on any inadequacy of the controls should necessarily prioritize the
security concerns. A report should also recommend corrective action. The impact of lack of controls
and possible risks arising thereof should be highlighted to the management or any appropriate
authority. Needless to add, the report should be supported by appropriate and relevant audit
evidence.
The following paragraphs provide possible methods for testing the functionality and built-in
controls in different modules. Depending upon the functionality/implementation the nature and extent
of testing may vary.
18.2 CUSTOMER ID GENERATION

The control objective is to ensure that evaluation includes ensuring that various mandatory fields are
updated before customer ID is generated.
1. Mandatory fields in this module are as follows:

• Name
• Data of birth with proof
• Address with proof
• Introducer details
• Constitution
• Customer category (public/staff/senior citizen)
• Residential status
• Details of guardian for minor customers
2. It is important to ensure that the above-mentioned mandatory fields are updated and a unique
customer number is generated.
3. Each one of the fields should be left blank, one at a time to test whether the system displays an
error message. If it does not, it establishes the fact that application needs a change.
4. The program needs to be tested for mandatory fields not being capable of being deleted by
using the facility ‘modify’. If the program is defective, data created and accepted could be
modified.
5. Each of the fields should be tested with the appropriate data, e.g. date of birth could be tested
with future date; name may be tested with numeric data.
6. Date of birth field should be linked to the system date to check the status of customer in the
case of minors and senior citizens. In case of minor accounts, the system should prompt details
for guardian. Also the date of birth should not be beyond the system date. That is, the date
cannot be a future date.
7. In case of customers other than the individuals, the system should verify for the existence of
appropriate basic documents, e.g. partnership-partnership deed; company-certificate of
incorporation.
8. There must be dual control for customer creation. One individual should enter the data in the
system. This should be accepted by the system only if another individual uses his user id and
password to authorize the entry. This is called the maker-checker concept. The dual control
would facilitate minimizing errors or creation of wrong data intentionally.
9. It must be ensured that proper procedures are in place to capture customer signatures and
photos and securely store them. The test should include testing delete functions on these fields.
10. Customer creation should be updated in the customer master and branches should be in a
position to access customer details at the time of opening of accounts.
11. Screen shots (that is a print out of the screen) with defective data needs to be taken as also
another screen shot when error message is not displayed or displayed wrongly to form part of
evidence to give an audit opinion.
18.3 ACCOUNTS MANAGEMENT

The main object is to ensure that the account opening process is in line with bank’s laid down
procedures and the KYC norms.
Savings and current account:
Program testing should at the least cover the following:
1. The system should automatically fetch the data from the Master data already created, once the
customer ID is entered. Test should ensure that the mandatory fields are not be capable of
deletion.
2. (a) Staff accounts:
Whenever a staff code is entered, the system should permit specific facilities available to staff
members only. This needs to be tested on the system.
(b) Senior citizen accounts:
Similar procedure should be followed to verify whether specific facilities are available to
them. This needs to be tested on the system.
3. Validation should be in place for not allowing cash receipts/local credits in Non-Resident
External Accounts. As the non-residents can freely repatriate the funds in their NRE accounts
only remittances from other countries/transfers from other NRE accounts should be allowed
(As per present RBI regulations).
4. It needs to be tested whether NRE accounts are treated separately as is meant for NRE
customers and not as normal savings bank customers.
5. Formal procedures should be available for limit creation, standing instruction, auto debits,
blocking and unblocking accounts. The proper implementation of these procedures should be
tested.
6. There should be a procedure to generate a specific account number for each customer and it
should be linked to his customer ID. This needs to be tested on the system.
7. Verify whether the system allows withdrawal in excess of the balance available which may
result in overdraft and whether system automatically awaits further authorization before
processing such cases.
8. The system should have a built-in control to ensure that appropriate documents are presented
for the non-individual customers, e.g. partnership-partnership deed; company-board
resolution.
9. The system should be in a position to capture signatures, tenures and permissible transaction
limits of the authorized signatories and should be in a position to display the same as and
when required for the verification.
10. Verify whether the system accepts a cheque that is not forming part of the series issued to that
customer.
11. Verify whether the system recovers charges for:
• Cheques returned
• Cheque book issue
• Minimum balance not maintained
If the above charges are not recovered, the presence of compensatory controls needs to be
verified.
12. Verify whether the inoperative and unclaimed accounts are segregated and the system calls for
authorization by the branch manager for the operations of such accounts.
13. Confirm that withdrawals are permitted by the system even if the balance goes below the
minimum balance after the debit.
Cash credit and overdraft account
1. Verify whether the system automatically generates a message for submission of stock
statements at stipulated intervals.
2. Verify whether the drawing power arrived at is net of the margin and also least of the limit
sanctioned and advance value.
3. Verify whether the drawing power arrived at is authorized at appropriate level.
4. Verify whether it is possible to modify the drawing power after
authorization.
5. Verify whether the system prompts for review/renewal of the credit facilities.
6. In case of advance to limited companies, verify whether the system automatically generates a
message for creation of charges with regis-trar of companies.
7. In cases where overdraft has been sanctioned against the bank depo-sits, verify whether lien is
marked on these deposits.
8. Verify whether the system calculates over due interest if the balance exceeds the sanctioned
limit/drawing power.
9. In cases where the cash credit/overdrafts are repayable in instalments, verify whether the
origional limit sanctioned is reduced to the extent of the instalment amounts repaid.
10. Verify whether all the excesses over the limit allowed, have the necessary authorizations and
are included in the exception report.
11. To verify how the system treats the existing borrowal accounts where sanctions have
expired/not renewed.
12. To verify whether the system recognizes the interest towards income in non-performing
advances. It should be verified that the interest so calculated is considered separately only and
not to Profit and Loss Account.
18.4 CASH OPERATIONS

It needs to be ensured that the laid down procedures in respect of the cash management as adopted by
the corporate office/RBI are incorporated in the system.
1. Verify who are authorized by the bank management to be cash tellers and also the limit fixed
for each of the tellers.
2. Verify whether the system prompts for Permanent Account Numbers (PAN) numbers for
receipts above Rs. 50,000 in cash. Issue of cash DDs/Banker’s cheques/TTs should not be
permitted by the system in case of remittance by cash above Rs. 50,000 as per the present RBI
guidelines.
3. To verify how the shortage/excess cash is accounted for by the system at the end of the day.
4. The system should capture and maintain denomination details right from the release of cash
from the vault.
5. For cash receipt/payment the system should note the denomination details and allow the
transaction only after tallying with the receipt/payment amount.
6. System should have a control for monitoring the movement of cash between the cash counters.
7. Verify whether the transaction can be modified by the maker only before authorization by the
checker and not afterwards.
8. Check whether the transaction is uniquely identifiable (by generating an ID and a time stamp).
9. Verify whether the system restricts payment per transaction in excess of teller’s limit.
10. Check whether system restricts any transaction in the account before initial deposit is made for
the opening of such accounts.
11. If there is a facility for cash withdrawal relating to an account of a different branch, it should
be verified whether the system enforces any upper limit fixed by the head office.
18.5 CLEARING
The clearing operations are generally done through batch processing and the main object of
evaluation of security is to verify how such batch data are controlled and if it control the totals match
with the total of individual instruments.
1. System should automatically reject cheques that are stale, post-dated, cheques which are
stopped for payment or drawn on accounts which are already closed.
2. The system should prompt for authorization by the concerned official in inoperative accounts
and accounts where sufficient balances are not available.
3. It should be verified whether it is possible to honour a cheque when the available balance in
the account is inadequate unless the cash block is lifted.
Note: Cash block is a specific amount in the account balance which is kept blocked.
4. System should have in-built controls to ensure that duplicate processing of the same
cheque/batch is not permitted.
18.6 MASTER MAINTENANCE

To ensure that appropriate controls are in place for parameter maintenance so that the system works
as intended. Parameter refers to master information like deposit interest rates, charges/commission
percentages/slabs etc.
1. Only the authorized persons should have access to parameter

tables.
2. There must be a log at the system level to record all the changes to parameter tables. The log
should contain the parameter that has been changed, the person who changed it and the date
and time of the change.
3. Test check should be conducted to verify the discipline regarding the parameter maintenance.
4. For certain parameters there could be range within which values can be changed. The system
should be tested to verify whether values outside the range are accepted.
18.7 LOG MAINTENANCE

To ensure that all the required logs are produced by the system and that confidentiality and integrity is
maintained over these logs.
1. Check all logs prepared by the system that are required for the business.
2. Check the levels at which the logs are accessible. Since they are
confidential in nature it must be accessible on a ‘need to know’ basis.
3. Check if controls are in place to ensure that the logs cannot be modified or deleted.
4. Check if all exceptional transactions are reported in the log.
5. Check if the details in the log are adequate.
Refer Chapter 22 for more about audit of system logs.
18.8 BANK GUARANTEE

The object is to check how the eligibility criteria, period of guarantee, charges etc. are configured in
the system and the guarantee format is approved by the competent authorities and certified for non-
existence of any onerous clauses.
1. The functionality of normal guarantee and deferred guarantee as available in the system needs
to be verified to ensure that the business requirements are provided for.
2. The deferred payment guarantee is a secured guarantee since the machineries, equipments etc.
purchased out of the guarantee issued favouring the suppliers form the primary security and
hence, the system should generate a message highlighting the need to comply with legal
requirements.
3. It should be ensured that the system passes necessary entries towards contingent liability at the
time of issue/reversing the guarantees.
4. To verify whether the recovery of applicable charges have been made and in the case of
deferred payment guarantees, only the charges payable for the particular financial year should
be taken to income account even though the charges for the entire period of the guarantee is
recovered at the time of issue of guarantee. Otherwise it will result in income being over
stated for that period.
5. To verify the availability of MIS reports for the review/renewal and expired guarantees.
6. To check for claim period in the guarantee issued as otherwise the guarantee will expire on
the due dates.
7. In case of the beneficiary invoking the guarantee and the guarantee becoming defaulted
guarantee, the accounting procedures need to be verified.
8. Verify the availability of provision in the system to acknowledge the counter-guarantee from
the customer as per the approved format linking it to the terms of the guarantee issued by the
bank.
9. Verify, whether the requisite cash margin as stipulated in the
guarantee sanction has been recovered and whether lien has been marked against such cash
margin deposit.
10. Verify whether it is possible for the system to accept payment of the guarantee amount if the
claim is made after the expiry of the guarantee.
18.9 BILLS
The process involves verification of the cheques/bills and the procedure in place in the system for
such transactions.
1. Check for the availability of provision for recording the details of the documents and
instruments. Inward/outward collections are to be distinctly identifiable.
2. Verify, whether the customer is having valid sanction for bill purchase limits.
3. Verify, whether the total liabilities can exceed the sanctioned limit and if so, whether the same
has been authorized.
4. Verify, whether the modification or waiver of charges are possible without the concurrence of
the authorizing official.
5. Test and verify the configuration of commission, interest charges, numbering of bills and bill
due date (usance) for accuracy and for prevention of leakage of income.
6. Verify, whether the grace period allowed for payment is to be within stipulated range.
7. Verify, whether provision is available for recording details of bills presented and in the case
of non-payment, whether particulars for sending non-payment advice to the drawer bank is
available.
8. In case of the transport documents, verify whether the transporter is in the approved list of
transport operators.
9. Verify, appropriation of proceeds of collection or realization to the total amount due including
the charges.
10. Verify, the correctness of the generated MIS reports for review of the pending bills and
returning the bills outstanding for a considerable period.
11. In case of IDBI/SIDBI bills under re-discounting scheme (applicable in the case of usance
bills), verify whether all such bills are reported to the banks link office.
12. Under drawee bill scheme, verify whether the amount utilized by the customer is reduced from
their cash credit/overdraft limits. This is to avoid double financing.
13. In case of bills purchased, returned by the drawee bank, verify whether the system prompts
recovery of charges concurrently or any procedure is set in motion by system (say MIS) to
follow-up recovery of charges.
14. Verify, whether system accepts bills having future dates or outdated bills which should have
been already paid as on the date of deposit of the same by the customer for purchase/discount.
18.10 LETTER OF CREDIT

The basic requirement for issue of letters of credit is to ensure that it is a genuine trade practice and
the guidelines of the bank are followed in the system.
1. The system should prompt for all the following required details:
• Importer/exporter code
• Import license details (specific/open general license)
• Shipping details
• Trans-shipment details if applicable
• Partial shipment details if applicable
• Letter of credit expiry date
• Document details—sight or usance
• Usance period if applicable
• Last date for shipment
• Last date for negotiation
• Letter of credit amount in rupees or foreign currency
• Letter of credit expiry date
• If revolving letter of credit, number of times or the amount revolving
• Details of merchandise
• Recovery of charges (opening, amendment and confirmation) from customer/beneficiary
2. Verify, whether the last date for shipment is within the date of negotiation and in turn, should
not fall beyond the expiry date of Letter of Credit (LC).
3. Ensure, in case of a foreign LC, whether the bank is having its own branch or a correspondent
bank to advise/confirm the letter of credit and also for presentation of the documents by the
supplier as per the terms of LC.
4. Verify whether the LC terms are as per the INCO terms 2000, which is a set of uniform rules
codifying the interpretation of trade terms defining the rights and obligations of buyer and
sellers in international transactions. Confusion over these terms may result in sale being lost
or in financial loss.
Example: Free on Board (FOB), Cost Insurance and Freight (CIF), Ex Works (EXW) and
Carriage Paid To (CPT).
5. Verify, whether the charges for opening, amendments, advice, commitment, postages are
recovered and if provision is available in the system for all of them.
6. If it is a revolving LC, verify whether necessary validations are in place to confirm the
number of times or the amount up to which the LC can revolve.
7. Verify whether there is a ‘revolving’ or ‘non-revolving’ flag when the LC is opened.
8. When an LC is devolved due to the customer not meeting the bills drawn under LC, verify
whether the system prompts for recovery of the devolved LC/bill amount and charges from the
customer.
9. Verify, whether the contingent liability vouchers under LC is debited at the time of opening
and reversed at the time of closing.
10. Verify, whether the system prompts for recovery of stipulated margin at the time of opening of
Letter of Credit and whether lien is marked on this margin amount.
18.11 REMITTANCES
To verify whether the system complies with the business requirements and Reserve Bank of India
(RBI) guidelines regarding remittances.
1. Verify, whether consideration has been received before the remittance is made (like receipt of
cash, account debit and cleared cheques) along with the applicable commission/exchange.
2. Verify, whether the remittance amount/exchange cannot be modified after authorization.
3. Verify, whether the charges for remittances and issue of duplicate instruments are factored into
the system.
4. Verify, whether the system allows issue/payment by way of cash
an amount exceeding Rs. 50,000/- since only account debit/credit is allowed and these
instruments should be necessarily marked ‘account payee’.
5. Verify, the methodology for revalidation of stale (more than six months old) Demand Drafts
(DDs)/Bankers Cheques (BCs) as per the laid down procedures.
6. Check, whether it is possible to issue duplicate DDs/BCs in case of lost instruments without
noting caution/or confirmation by the paying branch that the instrument has not been paid.
7. Verify, whether control is in place for sending advices in case of issue on non-CBS branches.
8. Verify, whether it is possible to print the same DD/BC by the system. This is to ensure that
duplicates cannot be printed.
9. Verify if the procedures for the reconciliation and the treatment of DDs/BCs issued but not
encashed for a considerable length of time is as per established procedures.
10. Verify, whether the system permits payment of DD/BC drawn on different branches to the
debit of DDs payable account.
11. Verify, whether, maker-checker concept is in place for issue/payment of instruments.
12. Verify, whether the system allows payment of the original/duplicate DD/BC when the
duplicates/original were presented and already paid.
18.12 STOCK MAINTENANCE OF NEGOTIABLE INSTRUMENTS

The object is to ensure that there is a formal procedure for maintenance of inventory of negotiable
instruments on the system.
1. Verify, whether all chequebooks are issued to the customers against the request and whether
such issues are accounted for in the
system.
2. Verify, whether it is possible to issue any series of numbered items without the system itself
allocating such issue.
3. Verify, whether there is any procedure in place to keep track of the chequebooks issued but
not taken delivery by the customer.
4. Verify, whether subsequent issue of chequebooks is possible without ensuring that a
reasonable utilization of the chequebooks already
issued.
5. Ensure system recovers charges against issue of chequebooks.
6. Verify, the procedures for implementation of ‘stop payments’ of the cheques requested by the
customers.
7. If ‘stop payment’ instructions are revoked, verify whether the system allows payment of such
instruments.
8. Verify whether the corporate office guidelines are followed before issue of chequebooks to
newly opened accounts.
18.13 DEPOSITS
The main object of the audit process is to verify whether they are in line with the established
procedures and controls as advised by RBI or the head office. Given below are suggested procedures
to be adopted for testing the deposit module:
1. Verify, whether validations are in place to ensure that system does not accept negative values
with regard to the deposit amount, interest rates, maturity amount and period of deposit. Apart
from other things, the system would automatically calculate and produce misleading figures.
2. Verify, whether appropriate interest rates are correctly applied (normal and additional) as
advised by the head office from time to time.
3. Verify, whether interest amounts payable on monthly basis is in line with accepted practice.
4. Verify, whether data can be modified after authorization.
5. Review procedures in place for renewal of matured deposits and for interest calculations.
Test, whether these procedures are in place in the system.
6. Verify, treatment of deposits on account of foreclosure as interest is payable only at a lesser
rate for the period, the deposit was held with the bank and not for the entire contracted period.
7. Verify, whether it is possible for the system to close the deposit without lifting the lien, if any,
on the deposits.
8. Ensure controls exist to prompt for the proof of identification for special deposits (staff,
senior citizens and other preferential cate-gories).
9. Study the procedures in the system for treatment of matured deposits not claimed.
10. Verify as to how the deposit numbers are generated and what are the controls in place for
duplicate receipt generation. Verify the procedures for generation of numbers and the controls
available over serial number.
11. Check the process of handling NRE TDS (Non-residential external term deposit).
12. Verify, how the unclaimed deposits (> 10 years old) are dealt with.
13. Verify, controls for renewal notice generation.
14. Verify, whether the range in interest rates are available for privileged category customers.
15. Since Government sponsored loans attract interest net of the subsidy amount only, verify,
whether the system has control to desist from paying interest for subsidy deposits.
16. In the case of recurring deposits, verify how delayed payment of instalments is handled in the
system for collection of penal interest.
17. Lien marked against recurring deposits—Is the interest amount considered for security? The
interest payable is kept in accrued interest account only and not credited to the account before
the maturity.
18. Verify, as to how the post maturity interest is calculated for the overdue instalments for few
months.
19. Verify, as to how the foreclosure is treated and whether only simple interest is applied.
20. Verify, whether any prescribed policy is in place to allow apportioning of the penal interest
for delayed payment of instalments against the concession allowed for advance payment of the
instalments.
18.14 ADVANCES
The main object of the audit is to check if the system has necessary controls to ensure that business
and RBI requirements regarding loan eligibility, interest rates, securities and follow up are strictly
adhered to.
1. Verify, whether the eligibility criteria and product parameters are clearly complied within the
system.
2. Verify, whether any unauthorized modifications are possible in the set parameters.
3. Verify, whether the interest calculation applied, is as per the stipulated rates for that particular
product/category and if there are any deviations, verify whether such deviations has the
necessary approval and is reflected in an exception report.
4. Verify, whether the loan amount is reduced by the value of the instalments on repayment and
the drawing limit is arrived accordingly.
5. Verify, whether the system prompts for review/renewal of advances. Any advance continued
without renewal sanction would attract overdue interest.
6. Verify, whether the existence of mandatory document details like:
(a) Demand promissory note
(b) Necessary stipulated agreement details
(c) Board resolution wherever applicable
(d) Mortgage details
(e) Lawyers’ opinion details
(f) Appraiser’ valuation details are captured by the system.
7. In case of company customers, verify, whether the system enforces acknowledgement (by way
of drop down menu or check box) for creation and registration of charges.
8. Verify, whether the system enforces acknowledgement (by way of drop down menu or check
box) for having insured the assets created out of loans.
9. Verify, whether the system prompts for renewal of necessary documents received from the
customers, at defined intervals.
10. Verify, whether appropriate approvals are required by the system for waiving penal interest
and other charges. Also verify, whether the same is reflected in the exception report.
11. Verify, whether the system captures the appropriate appraiser details for different types of
securities. Also verify, whether the system checks if the appraiser value covers the advance
value requested by the customer.
12. Verify, whether the system does not process the loans of customer whose date of birth
indicates that he is a minor.
13. Verify, whether the interest calculation is applied on the loan amount net of subsidies as the
subsidy amount kept as deposit is not eligible for interest.
14. Verify, whether the system enforces the guidelines adopted regarding income recognition and
non-performing assets as improper classification may have impact on revenue calculations.
15. Verify, whether the system processes advances to non residents as per the Foreign Exchange
Management Act and RBI guidelines.
ATM Operations
19.1 INTRODUCTION
The Automated Teller Machine (ATM) is one of the critical components of the Banking process.
Under the following sub-headings the main aspects reviewed for evaluation of security concerns
are provided in the form of checklist wherever possible.
19.2.1 Card and PIN Production
Are separate departments and staff used for card and PIN generation?
Are procedures for production of cards and PINs fully documented?
Does the PIN mailer tape have card or account number?
Is there reconciliation procedure for the number of cards and PIN mailers produced?
Are records maintained for cards and PINs produced, mailed and spoiled?
Are the security procedures for the following adequate?
(a) Access
(b) Storage
(c) Staff
Does security evaluation include the following:
(a) Access to building
(b) Stocks of blank cards
(c) Stocks of cards and PIN mailers
Are monitoring procedures in place to ensure that computer jobs are run only once?
Are spoilt cards and PIN mailers reconciled?
When cards are destroyed, are suitable measures adopted to ensure that the confidential and
sensitive information is not available?
Are PINs encrypted on to the tape?
Are suitable measures in place to prevent unauthorised copying or dumping?
Are the departments producing cards and PINs physically separated?
In case PINs are printed on a fly sheet, are procedures in place to ensure destruction of the
same is in a manner suitable for sensitive data?
Is access to both of the production areas restricted to only authorised personnel?
Are procedures in place to ensure that live cards and PIN mailers are despatched separately
from different locations?
Are proper records maintained for all cards delivered?
Are procedures in place to ensure that the cards are returned to branch offices and not to the
office from where the cards are generated?
Are the procedures in place to ensure that no single officer is in charge of holding stock of
returned cards and returned PIN mailers?
19.2.2 Surrendered and Captured Cards
Are there clear documented procedures with regard to surrendered and captured cards?
Are clear instructions provided to customers regarding the return of cards?
Are there documented procedures in place for issuing replacement cards and PIN?
Are captured cards made ineffective by the cardholder/by the bank?
Are clear instructions given to the customers that PIN should not be kept along with card or
written on the card itself?
Are clear instructions given to the customers that PIN should not be returned to the bank?
Are there documented procedures in the bank for opening of secure mail?
Are registers maintained of surrendered cards?
Are captured cards bin opened on dual control with proper records being maintained?
Is stop instructions in place immediately on the associated accounts when a card is returned
by:
(a) A customer or
(b) By a personal representative of the deceased card-holder?
Does the ATM lock off all details of a captured card?
Are captured cards removed from the ATM on a regular basis under dual control and
reconciled with the journal roll?
Is the report of captured cards produced on the host computer?
Are there procedures in writing regarding re-issue of cards and/or change of PIN following
card capture?
Is there a control in place by which the ATM retains a customer’s card after a said number of
failed attempts to key the correct PIN?
19.2.3 PIN Security
Is there a procedure in place to stop the card operation when a card-holder reports that PIN
has been compromised?
Have customers been formally advised never to keep the PIN and card together?
Are the customers advised not to disclose the PIN to anyone including the police?
Is there procedure in place to ensure that verbal or written request from customers for
specified PIN are accepted? Customers should be able to select their PIN only at the ATM.
Is there a documented procedure in place for action to be taken when a customer forgets
his/her PIN?
Is there a procedure in place for generating a new PIN on a timely basis if PIN numbers are
lost or stolen?
Are PINs held on Data files in encrypted form?
Are PIN offsets encrypted?
Is hardware encryption used?
Is software encryption used?—If software encryption is used the key would be easily
available and are generally to be avoided.
Does the encryption routine incorporate the customer account number so that any substitution
would easily be highlighted?
Are work and storage areas used for PIN encryption immediately zeroized after each
calculation?
Are there procedures in place to ensure that no hard copy records of PINs produced are
anywhere in the system?
Does the host system record instances of PIN changes?
Does the PIN selection prevent combinations such as “1111” or “0000”?
19.2.4 Cash Control and Balancing
Are there documented procedures describing in detail the cash control and balancing process?
Are all the insertions and withdrawals of cassettes automatically recorded on the audit roll?
Is there a duel control procedure in place when cassettes are reinserted or removed?
Are there documented procedures and controls in place to monitor movement and storage of
cassettes?
Are there records maintained of the amount of cash inserted into each cassette?
Is there a daily reconciliation made by the bank staff reconciling the amount shown on the
audit roll regarding
(a) Cash inserted
(b) Cash dispensed
(c) Cash remaining
(d) Mis-fed notes
Are all reconciliation discrepancies investigated?
Is reconciliation of totals performed by person different from the person responsible for cash
management?
Are there checks in place to ensure that
(a) Wrong denomination notes are not inserted into the cassette?
(b) Incorrect denomination cassettes are not placed into the ATM?
Does daily balancing process ensure that
(a) Confirmation is given by branch staff.
(b) The currency deposited and dispensed agree with ATM accumulated total.
(c) The total of the deposit and withdrawal transactions generated by the ATM has been
received and logged by the host computer and branch system.
(d) The net movement of the host computer account file is in agreement with the total branch
transaction.
19.2.5 Transaction Records
Is there a journal roll fitted to each ATM?

Is each journal roll retained for a definite period as required by law?—The journal roll is the
record of events at the ATM and hence, is of paramount importance.
Are hard copies of journal maintained in a secure manner?
Does the system have a built-in procedure to securely store soft copy of the journal (also
called as electronic journal)? Where is it stored? Is it secure and not modifiable?
Does the ATM close down automatically if the journal roll ceases to operate?
Are only the key-holders permitted to make a weekly check of the journal roll machine record
to verify whether any unauthorized opening of an ATM and cassettes removal operations have
taken place?
Do customer receipts contain information which would permit an unauthorized manufacture of
an ATM card?
19.2.6 Lost and Stolen Cards
Are there documented procedures available to be followed relating to stolen cards?

Is there a facility to ensure that “Hot Card File” is maintained to record the details of all
reported stolen cards? What is the frequency of updating this file?
Are there proper authorization procedures for the data to be added on to the file?
Are there adequate restriction procedures in place for accessing this file?
What are the procedures in place to ensure that in case different versions of this file are
available, they are synchronized?
Are the accounts associated with lost or stolen card set to
(a) Reject transaction and
(b) Capture the card in case such a card is used?
Is there provision to put “Stop” on an ATM card even on the basis of verbal information?
Is verification of the identity of the card-holder requested?
Is “Stop” placed on the associated accounts also?
Is replacement card issued only upon receipt of written notification from the Card-holder that
his/her card has been lost or stolen?
Are there facilities to record reports of lost and stolen cards even outside office hours?
How often are the files reviewed?
Is the policy governing liability for withdrawal made prior to and after notification of lost or
theft of a Card or PIN clearly defined and documented?
Is this policy in line with current legal provisions?
Are records of all reports of lost and stolen cards retained and for how long?
19.2.7 Evaluation of Controls at the ATM Switch
The switch consists of a computer with an attached server. Database resides on the server. The
contents of the database are:
Card number and corresponding offset value (offset value explained under section 8.2 in
Chapter 8 of Part I)
Hotlisted cards—Details
Surrendered cards—Details
Account balance of customers
The account balance of customers is made available in the ATM switch database so that the
balance (also called as Positive Balance File–PBF) is provided when ATM is offline.
A switch is a focal point in the ATM infrastructure and the audit at the switch would include the
following:
Physical and logical access

Registers need to be maintained at entry point. A security guard also needs to be posted apart
from making sure that the invisible camera is in working condition to capture all activities.
The operating system security settings need to be reviewed.
Access to operating system which should be to only the system administrator need to be
reviewed.
Root/Super user passwords need to be kept secured.
The switch application software needs to be parameterized for maximum number of
withdrawals per day, maximum withdrawal limit per day, number of failed log in attempts etc.
The procedures for configuring the same need to be reviewed.
The monitoring mechanism needs to be in place. Reports should be available of the
configuration details and changes. Only an authorized personnel should be able to do the
authorized changes.
The other aspects to be audited would include the following:
Key storage and changes procedures
Key used for encryption/decryption purposes
Procedures for hot-listing of ATM cards
Monitoring of switch report e.g., successful/unsuccessful transactions and suspected
transactions
Procedures for generation, monitoring and archival of switch logs.
Incident handling procedures at switch: evidence of any security breaches and how it was
resolved.
Agreements between banks for sharing of ATM network—settlements, handling of customer
claims for money not received but account debited etc.
Report generated at switch for Inter bank/branch reconciliations—Whether report is reviewed
at head office and appropriate action is taken?
Internet Banking
20.1 INTRODUCTION
Internet Banking permits the customers to conduct financial transactions on a secured website.
The following questionnaire deals with various areas and the aspects related to the security and
controls of Internet banking. It is comprehensive but not necessarily exhaustive (See Table 20.1).
Table 20.1 Questionnaire on security and controls of Internet Banking
S.
Description
No.
1. Security policy and procedures
1.1 Are the security policy and procedures pertaining to Internet Banking approved by the management?
1.2 Are the security policy and procedures reviewed on a regular interval?
1.3 Does the Internet Banking security policy include existing service access policy and firewall security policy?
1.4 Is there a documented procedure in place for handling security incidents?
2. Security policy and procedures - Relating to personnel associated with Internet Banking
2.1 Does the management conduct periodic Information security awareness programmes?
2.2 Does the security policy and procedures talk about access controls to be enforced and action to be taken in case of access violations?
Does the security policy and procedures cover security procedures for all the access points namely:
• User system and front end application
• Router, switch, firewall
2.3 • Web and application server
• Local area network
• Mainframe
• Internet infrastructure
3. Security features relating to user identification
3.1 Review, whether the security mechanisms are in place to prevent unauthorized access to other accounts.
3.2 Verify whether the access control mechanisms are employed to control access both in and out of the internal network.
Review whether the access control mechanisms are employed to control the access of unauthorized persons to the transaction
3.3
processing functions of the application programs.
3.4 Review whether there are adequate log reporting and monitoring facilities within the system.
3.5 Review whether the log administration and monitoring procedures have been implemented.
Verify whether the automated tools are in use to highlight log entries that suggest an attempt to penetrate the network, e.g. Intrusion
3.6
Detection System (IDS).
Review whether proactive and detective monitoring measures are performed to highlight attempted or successful security breaches of the
3.7
system.
3.8 Verify whether logs of successful and unsuccessful attempts to penetrate the system are reviewed on a daily basis.
Verify whether there are procedures in place to log multiple unsuccessful log in attempts and to highlight the same to the system
3.9
administrator for immediate action.
3.10 Verify whether adequate restrictions have been enforced over access to software logs and audit trails.
4. Access controls to Internet Banking operation facilities, applications and data
4.1 Verify whether there is adequate segregation of duties.
Verify whether there is a password identification process which ensures that access is given only to the users with valid user IDs and
4.2
relevant passwords.
4.3 Verify whether after prescribed log on failures (say three times), user access is automatically disabled.
Verify whether there are procedures in place to ensure that log on ID and passwords are revoked soon after employees resign or
4.4
transferred.
4.5 Verify whether there is periodical maintenance of both Internet Banking hardware and software.
Verify whether there is an operational manual regarding Internet Banking operations and whether procedures are in place to keep it
4.6
updated.
4.7 Review change control procedures to verify whether they are clearly defined, documented and implemented.
4.8 Verify whether all the recovery procedures for operational failures are adequately documented.
Review whether the physical access to critical Internet Banking System components is secured and only authorised personnel are
4.9
permitted access.
5. Roles and responsibilities of system administrator
5.1 Verify whether responsibility for the security administration of Internet Banking has been assigned to a particular individual?
5.2 Verify whether roles and responsibilities have been clearly stated?
5.3 Verify whether adequate segregation of duties exists within the information system administration?
5.4 Verify whether the staffs are properly trained?
5.5 Verify whether there is a procedure manual detailing the guidelines for the information systems’ administration function?
5.6 Verify whether access violation attempts are monitored and reported to the appropriate authorities?
6. Firewall configurations and security
6.1 Review whether firewall architecture has been defined and implemented in order to adequately support the Internet Banking services?
6.2 Verify whether the Internet Banking services are delivered through a dedicated firewall architecture?
6.3 Verify whether a penetration test has been carried out.
6.4 Verify whether the vulnerabilities identified in the penetration test have been evaluated and appropriate corrective action taken.
6.5 Verify whether there are automated tools in use to highlight the entries which may suggest a penetration attempt.
6.6 Verify whether within the firewall software adequate log in reporting and monitoring facilities are available.
6.7 Verify whether both proactive and detective procedures are in place to highlight attempted security breaches to the system.
6.8 Verify whether the log administration and monitoring procedures have been implemented.
6.9 Verify whether access restrictions are in place for access to software logs and audit trails.
6.10 Verify whether firewall logs are stored in the firewall system itself or elsewhere.
Verify whether a network time protocol is used to synchronize the firewall system clocks. This is to enable accurate and consistent time
6.11
stamping of events.
6.12 Verify whether adequate firewall change control procedures as approved by senior management are in place.
6.13 Verify whether there are procedures in place to monitor and manage changes.
6.14 Verify whether management approval is obtained before firewall, system, routers or their operating systems are altered or upgraded?
Verify whether there are procedures in place to ensure that access control rules of the firewall can be modified only after approval of the
6.15
management.
Verify whether there are procedures in place to test firewall applications after changes have been made. This is to ensure that changes do
6.16
not give room for new vulnerabilities.
6.17 Verify whether there are procedures in place to regularly update the firewall application with latest patches.
Review the physical access procedures to the firewall systems components to ensure that access is restricted to authorized personnel
6.18
only.
6.19 Verify whether there is a clear definition of what are the emergency access procedures for a firewall.
6.20 Verify whether review of emergency procedures is undertaken.

7. Segregation of live and test environments
7.1 Verify whether there is a separate test environment and applications are tested extensively before implementation in a live environment.
7.2 Verify whether there are formal sign off procedures in place for movement of programs including implementation of new patches.
7.3 Verify whether there is a proper organizational structure in existence for testing and development.
7.4 Review the testing procedures for adequacy of documentation.
7.5 Verify whether the testing includes unit testing, system testing, load testing and regression testing.
7.6 Review whether performance monitoring is included in the testing process.
8. Review of network security
8.1 Verify whether access to network is controlled by means of sufficient number of perimeter devices.
8.2 Verify whether separate internal and external domain name servers are utilized to mask internal host name from the internet.
8.3 Verify whether Network Address Translation (NAT) techniques are in place to hide internal IP addresses from the internet users.
8.4 Review access control mechanisms in place to ensure there are controls to access to both in and out of internal network.
8.5 Verify whether router configurations are regularly evaluated to ensure no unauthorized changes have been made.
8.6 Verify whether adequate log in facilities are available within the system.
8.7 Verify whether automated tools are used to identify any suspicious activity.
8.8 Verify whether logs are reviewed on a daily basis for successful and unsuccessful attempts at penetrating the network.
8.9 Verify whether audit trails have been enabled to record application activity.
8.10 Verify whether such audit trails are adequately secured.
8.11 Verify physical access to network system components to ensure that access is restricted only to authorized personnel.
9. Positioning of routers in securing the network
9.1 Verify whether the routers are logically secured and passwords are controlled.
9.2 Verify whether the routers are directly reachable via the internet and whether they accept routing up date from the internet.
Review the configuration of Intranet routers to ensure that communication between Internet banking system within the corporate local
9.3
area network is restricted to only certain necessary systems.
10. Security of web server
10.1 Verify whether web servers run only required processes and nothing else.
10.2 Verify whether the operating systems of the web servers have also been hardened.
11. Securing Internet Banking systems
11.1 Verify whether the Access Control Lists (ACL) are used and whether a list of authorized users is maintained.
11.2 Verify whether Internet Banking system configuration is clearly documented.
11.3 Verify whether adequate controls are in place to ensure integrity and security of transactions.
11.4 Review segregation of duties between personnel in operations.
11.5 Verify whether physical access to the internet banking system is restricted only to authorized personnel.
11.6 Verify whether log administration and monitoring procedures have been implemented.
11.7 Verify whether audit trails regarding system activity have been implemented and secured.
11.8 Verify whether software logs and audit trails are adequately secured.
12. Access controls to the database
12.1 Verify whether access to an intermediate data stored is restricted only to system administration and application users.
12.2 Verify whether sensitive client data like personal Identification No (PIN) stored within data base management system is encrypted.
13. Operational controls—Validations built in the application
13.1 Program tested to ensure application check for correct characters, decimal places.
13.2 Application is tested to ensure that all validity criteria are complied with before transaction is processed.
Test the application with sample transaction to verify the validations built in the application.
The validation could be
13.3 • The application directly validating the data against specific tables;
• The data is validated for appropriate data type; or
• The data is checked if is within a specified range.
13.4 Exception reports are produced listing unusual, unmatched items to facilitate programmed check digits.
13.5 Review whether overrides of the system by the users are automatically logged for independent approval and authorization.
13.6 Verify whether security measures have been defined and implemented to ensure the integrity of the application data is assured.
14. Operational controls—User authentication
14.1 Verify, identification techniques and ensure that they meet the business requirements.
14.2 Review user authentication mechanism to ensure that access is restricted to authorized personnel.
15. Operational controls—Incomplete and cancelled transactions
15.1 Test the program to ensure that errors are returned so that information is provided that the transaction has not been recorded.
15.2 Verify whether the program permits a user to cancel the transaction which has already been accepted.
15.3 Verify whether the specified file of rejected transactions are corrected and re-introduced into the system.
15.4 Review the procedure for incomplete processing.
Verify whether there is a compensating control outside the system to ensure all rejected entries are corrected and fed into the main
15.5
system.
16. Operational Controls—Data security
16.1 Verify whether critical data are encrypted.
16.2 Verify whether keys used for encryption are managed in line with best practices.
16.3 Verify whether keys are stored in a physically secure environment.
16.4 Verify to ensure that critical encryption keys reside in a physically secure hardware like HSM (Hardware Security Model).
17. Operational controls—Application functionality
17.1 Verify whether restart/recovery procedures are in place.
17.2 Ensure that as a result of re-processing due to interruption no transactions are lost.
17.3 Any unauthorized or erroneous entries generated by the system are logged for further investigation.
17.4 Application is tested for reasonableness check, completeness of fields, etc.
18. Change management procedures
18.1 Verify the organization structure in place for system development and change management.
18.2 Verify whether there is a formal mechanism put in place for effecting changes.
18.3 Review the testing procedure to verify whether they are fully documented and cover unit testing, system testing and regression testing.
18.4 Review migration procedures to ensure that they have been formally recorded and strictly followed.
18.5 Verify whether emergency change procedures have been defined and documented.
18.6 Verify existence and adequacy of testing plans.
18.7 Verify whether there is a procedure for accepting the program.
18.8 Verify whether the version number of each release is recorded.
18.9 Verify the procedures in place to ensure that corrections have been made to the correct version of the software.
18.10 Verify whether each version of the program is properly approved for release.
18.11 Comprehensively test the library functions.
19. Acceptance of new system
19.1 Verify whether testing is comprehensive
19.2 Verify whether business objectives have all been achieved.
19.3 Verify whether after successful testing formal sign off documents have been completed.
19. Incident management procedures
• Review the following:
• Problem management procedures
19.1
• Crisis management procedures
• Escalation procedures
Verify whether documented procedures are in place for roles and responsibilities for problem and incident management and ensure that
19.2
they are strictly adhered to.
19.3 Verify whether post-incident reviews are carried out and reports presented to appropriate authorities.
Evaluation of Controls and

Audit of Branches
21.1 INTRODUCTION
In a core banking solution, as already mentioned, all the servers are located in the central data center.
Only the front office operations are performed at the branch. Each of the branches may have several
nodes depending upon the need. The branches are connected by communication lines to the core data
centre.
All the master data of the branch in the nature of customer details, account balances, product details
etc. are all held in the database server at the data center. All the parameters like interest rates
applicable for various transactions (e.g. fixed deposits, loans etc.), charges for transactions, new
product definitions are carried out from the CPPD in the application server at the data center. In the
circumstances, generally, there are no servers maintained at the branches. However, in certain banks,
they do maintain branch level servers which are used generally for storing account balances
(mirrored from the data center) so that in case of problems of network connectivity, minimum/basic
operations at the branch would still continue. Some banks are still experiencing inadequacy of
bandwidth. So that the connectivity between the branch and the data center are not slowed down,
there is a temporary storage of data in the servers at the branches. Periodically, the transactions
would get updated with the servers at the data center.
21.2 GENERATION OF REPORTS IN CBS
Under CBS environment reports are generated centrally at the data center and made available to the
branch. The Branch Manager downloads the MIS reports from the server at the data center.
Alternatively in some banks the reports are pushed on a periodic basis to a designated folder which
can be accessed by the branch. The branches are generally not in a position to generate any reports
locally except those already provided through the application menu.
In certain cases, the ATMs are located in the premises of the branch. Such ATMs are
administratively controlled from a central location and the branches are empowered only to carry out
routine tasks like loading of cash.
In CBS environment, branches are not empowered to grant access rights to the users. They are
created and monitored from the Computer Policy and Planning Department (CPPD).
21.3 METHODS OF OPERATION IN A CBS BRANCH

The method of operations in a branch of a bank where the core banking solution has been
implemented is quite different from the branch operations under the Total Branch Automation (TBA)
systems. In view of the above, while performing the evaluation of controls in a CBS enabled bank
branches while control objectives remain the same, the methodology would be totally different. Even
those performing the concurrent audit of branches need to adopt the changed methodology to perform
an effective audit. For example, most of the reports required for audit purposes would now be
available online as ‘view only’ and analysis through spreadsheets like excel may not be possible at
the branch level. Given below is a suggested checklist for performing audit of a bank’s branch where
core banking solution has been implemented (see Table 21.1).
Table 21.1 Checklist for Information Systems audit of CBS branches
S.
Description
No.
I. Information security policy
1. Is there a security policy for the bank?
2. Does the branch have an extract of the information security policy covering aspects applicable to it?
3. Are the employees aware of the requirements of the security policy?
4. Have all the employees acknowledged, having received and understood the policy requirements?
5. Has there been any incident of security concern in the branch recently?
6. Does the branch have written procedures for handling incidents of security concern? Are the employees aware of such procedures?
II. Access Control Procedures
Password management
(a) Does the system force the user to change the password before it expires?
(b) Does the system prompt for password change during the first login?
1.
(c) How are the User ID and Password communicated to new employees?
(d) Does the user account get locked out after a fixed number of failed login attempts?
(e) If yes, how are such accounts revived?
Is there a User ID register maintained with details of when user ID given and when deleted? Are these entries signed by the employees as
2.
evidence of accountability?
3. Are screensaver passwords enabled in all the systems to take over after a brief period of inactivity?
4. Are the users signing off the application as and when they leave their seats?
5. Are USB ports, CD ROM drives and floppy drives disabled in all the systems?
Server related procedures (generally in a CBS environment, branch level servers may not be there. However, should there be one, the
III.
following information needs to be gathered).
1. Is there a server available at the branch?
2. If yes, what data is stored in the server? Whether it is updated at fixed intervals? (e.g. during the day begin operations)
3. Is the branch system administrator password available in a sealed envelope and kept in a safe custody?
Physical and environmental controls for server
4. Is there any device installed in the server room to monitor temperature, humidity and moisture in the server room?
5. Is access to the server room restricted to authorized users only?
6. Is there a register maintained to log person entering the server room and the purpose?
7. Are there a fire extinguisher and an air conditioner available in the server room?
8. Are the labels on the fire extinguishers displaying ‘refill date’ which is still valid?
IV. Network related procedures
1. Are the various network devices like router, switch and hub secured?
2. Are there any unused ports in router, switch and hubs? How are these protected?
3. Are all network cables protected properly?
V. Application level verification
1. Are there controls to ensure that various parameters like interest, charges are range bound?
2. Does the system allow back-dated entries?
3. Does the system generate an exception report at the end of the day? (e.g. limit excess, temporary overdrafts etc.)
Are the application logs generated? Are the logs comprehensive to provide details of user ID used for creation/authorization, date/time,
4.
machine identification etc.
VI. ATM related verification (for branches issuing ATM cards to customers)
1. Are there adequate security procedures for storing ATM cards (to be issued to customers) received by the branch?
2. Are the ATM cards registers maintained to enable reconciliation of physical inventory of cards?
3. Are there procedures to update CBS with details of card issued to customers?
4. Are the PIN mailers received by the branch? (which is not in line with best practices.)
5. Are the cards and PIN mailers in the custody of two different officers?
In case of branches which have ATMs attached (onsite ATMs):
6. Are procedures for cash loading, recording and reconciliation followed?
7. Is there a dual control over the ATM Master key?
8. Are the used ATM Journal rolls safely stored in the branch?
9. Are the procedures for dealing with swallowed cards in order?
10. Are the procedures for dealing with cash in the rejected bin in order?
VII. Business Continuity Planning (BCP) and Disaster Recovery Planning (DRP)
1. Does the branch have a BCP and DRP procedure?
2. If yes, are the branch employees aware of such procedures?
3. Has the branch carried out any BCP drill recently?
4. Has there been any incident regarding BCP/DRP affecting the branch?
5. Does the branch manager and other key personnel have the numbers to contact in case of emergency?
6. Does the branch have alternate network connectivity to the data center so that if one fails, other can act as fall-back mechanism?
VIII. General
1. Are all the systems supported by the UPS?
2. Does the UPS have a direct power supply?
3. Is there any generator available?
4. Are all the assets numbered and an asset register maintained?
Are all systems and other devices covered by an adequate insurance policy? (Many banks have gone in for comprehensive cover at
5.
C.O/H.O level for all IS Assets)
6. Are all the systems and other devices covered by an AMC?
7. Does the branch maintain an AMC register capturing details of service engineer visits, visit reports etc.?
21.4 EVALUATION OF SECURITY CONTROLS IN REAL TIME GROSS SETTLEMENT

(RTGS) SYSTEM
The main aspects in the audit of Real Time Gross Settlement (RTGS) systems would center around
evaluation procedures followed regarding encryption and authorization of transactions. There needs
to be dual control and no single officer should be able to initiate and complete an RTGS transaction.
Since RTGS works on the strength of Public Key Infrastructure (PKI), if private key is compromised,
the integrity and security of the transactions would be suspect.
The procedures for review of settlement statements need to be studied to ensure that all the
transactions have been dealt with one way or the other.
The Inward Messaging Module (IMM) supports the creation of output files for the payment
messages received. The Inward Messaging Module (IMM) receives the following types of messages
in addition to the inward payments:
Acknowledgements for:
Customer payment
Inter bank payment
Own account transfer
Responses are received from Real Time Gross Settlement (RTGS) and indicate that a message has
been processed.
21.5 AUDIT OF CASH MANAGEMENT SYSTEM

Many banks have used Cash Management System (CMS) to generate a stream of revenue. The various
aspects to be covered in systems audit of CMS are as follows:
Control over parameter settings
The Cash Management System (CMS) have various parameter settings like clearing cycle, credit
limit, charges (in various slabs), interest (in various slabs etc.). Hence, adequate controls over
parameter setting, authorization, modification is to be exercised. Most of the parameters are set-based
or paper-based authorization.
Control over processing of charges/interest etc.
The CMS calculates various charges like DD/Pay-order issue charges, courier charges, cheque return
charges etc. and charges interest for credit afforded. The computational logic is to be verified as any
error would lead to income leakage for the bank. Also the CMS offers facility for discount/waiver of
charges. During audit, the authorization process for the same is to be verified.
Authorization of limit excess
The CMS offers features to grant limit excess to the customers—a scenario where customer credit
exceeds sanctioned limit. The system-based authorization for the same should be verified.
Proper generation of MIS
Numerous client MIS reports, management MIS reports etc. are generated by CMS. The integrity of
such reports should be verified.
Day-end processing
It is during this process that customer debits and credits are pooled in single designated account. All
the balances of various collection centers are pooled. The accuracy of such pooling should be
verified.
Interface with CBS
The CMS interfaces with CBS for posting of entries. This process should be verified to ensure that
correct GL heads are posted.
Audit trails
The CMS provides audit trails for various events like parameter settings, transaction authorization,
charges waiver etc. The adequacy of the audit trails need to be verified, apart from verifying whether
audit trails have been setup for all significant features to be reviewed.
SECTION C............................................CHAPTER 22
Review of System Logs

22.1 INTRODUCTION
In Core Banking Solution (CBS) software, the logs are broadly divided into three parts which are as
mentioned below:
(a) Operating system logs
(b) Application logs
(c) Database logs
In addition to the above mentioned logs, there are other logs generated by the network devices like
firewalls, Intrusion Detection System (IDS) etc.
22.2 APPLICATION LOGS AND EXCEPTIONAL REPORTS

The application logs are usually provided for access through the front-end. Also there are provisions
for enabling logs, i.e. transactions for which the logs have to be captured, can be specifically
configured. Enabling logs is a management decision as logs usually occupy space and slow down
performance. Most banks enable logs for financial transactions like loan authorization, limit creation,
pre-closure of deposits while generally logs may not be enabled for non-financial transactions like
account opening, report generation etc.
22.2.1 Contents of Audit Log

Broadly the contents of Audit Log are classified as under:
(i) User-Id of user initiating the transaction (usually at the clerical
level)
(ii) User-Id of user authorizing the transaction (usually at the officer/manager level)
(iii) Date and time of initiation/authorization
(iv) Machine identification details like some unique number assigned to each machine or its IP
Address.
(v) Branch ID is a unique identifier for each branch under CBS.
The application logs operate as an audit trail for various transactions. But care should be exercised
in cases where logs are overwritten thereby erasing past trails.
22.2.2 CBS Exception Report

Given below are illustrations of few exception reports.
Daily
1. Temporary overdraft/excess report

2. Loan arrears report
3. Cross checking of various general ledger heads like drafts payable, inter branch
reconciliation, funds-in transit etc.
Weekly
1. Temporary overdraft/Excess report

2. Outward collection pending report
3. Inward collection pending report
4. Bills purchased/discounted report
5. Bills returned/unpaid report
Monthly
1. Accounts opened/closed during the month

2. Limits/insurance/demand promissory note due register
3. Stock due date register
There could be other logs also. One needs to enquire and verify their existence.
22.3 DATABASE LOGS

There are several database management system (DBMS) (Ex: Oracle, Ingress, Sybase etc.) which
banks use. For explanation purposes, we consider Oracle database.
These logs are usually viewed only in exceptional circumstances at the Computer System
Department (CSD) and are not available for access at the branch level. These are viewed by an
authorized user with access to the database using SQL or any other query facility. This requires
knowledge of the database table structures and nomenclature as there are numerous tables within the
database.
In a Data Base Management System (DBMS) like Oracle, there are built-in facilities to enable
certain audit trails. It is not uncommon to come across un-auditable systems in the sense that audit
evidence for important exceptions are not readily available. However, there is no magic solution or
silver bullet in creating an auditable system that satisfies all the requirements. The organizations can
create an auditable system by implementing various levels of audit trails in Oracle applications.
There are five primary ways to develop an audit trail which are as follows:
22.3.1 Standard Application Audit

It comes with the ‘vanilla’ installed and provides the last up-date information. Most organizations
which run oracle application, have this audit trail.
22.3.2 Application Level Audit Trail

It allows tracking changes at the detailed level, when enabled at the table level through the system
administration functions, the application works with the database to build a detailed record of
changes, additions and deletions at the database level. This would be an ideal trail and this audit trail
should be stored in a separate table from the production data. However, in view of their concern
about the system performance, these are not enabled very often.
22.3.3 Database Event Auditing

This tracks activity at the event level. An illustration of an event could be user logging into the
application.
22.3.4 Database Trigger Auditing

This is an application level audit trail as this feature relies on the database trigger to form an audit
trail. Database triggered auditing would be useful and necessary to record changes made at the
database level but not made through the application log in.
22.3.5 External Auditing

This allows an audit trail to be built through information contained in the ‘Redo’ logs. This is a very
involved and expensive process. However, it needs to be emphasized that the banks require to
develop a comprehensive strategy to develop an effective and useful audit trail. In the absence of an
audit trail, banks application would not be auditable and that itself would be a security concern. A
sample list of system changes that would need to have an audit trail would include the following:
(a) changes to the database structure
(b) addition, deletion or change to database triggers
(c) changes to programs, libraries or scripts at the operating system level
(d) changes to objects or packages at the database level
(e) changes to the set-ups or profile options at the application level
Most commonly in the implementation of Oracle applications, only the default application level
audit trail is the extent to which all organizations, including the banks have implemented. This does
not impact the performance. However, this does not provide the level of detail required by an auditor.
The application level auditing works with the database to record information about the transactions as
the application interacts with the database.
Data base event auditing
Many database operations can be audited including database logging. In most cases, database event
auditing is part of standard audit base technology. However, in certain proprietary database structures
like Sybase, it may not be easily possible unless one knows the structure. It is as important to obtain
an audit trail as it is to have a policy in place for log management. The logs could be classified as
security logs, operating system logs or application logs.
Log management policy
There needs to be a log management security policy as also procedures. In the following paragraphs,
the log management security policy as well as procedures including an illustration of how log may
appear is enclosed.
Log management security policy
To ensure that events occurring within the organization’s information systems and network are
recorded in a log, a formal policy shall be in a place. Appropriate security measures shall be adopted
to protect against the risks of modification, and deletion.
Log management security policy—procedures
A log is a record of the events occurring within an organization’s systems and networks. The logs are
composed of log entries; each entry contains information related to a specific event that has occurred
within a system or network. Many logs within an organization contain records, related to the computer
security. These computer security logs are generated by many sources, including security software,
such as antivirus software, firewalls, and intrusion detection and prevention systems; operating
systems on servers, workstations, and networking equipment; and applications.
The log management is essential to ensure that computer security records are stored in sufficient
detail for an appropriate period of time. The routine log analysis is beneficial for identifying security
incidents, policy violations, fraudulent activity, and operational problems. The logs are also useful
when performing auditing and forensic analysis, supporting internal investigations, establishing
baselines, and identifying operational trends and long-term problems.
A system is susceptible to the following security risks:
An attack to the system due to known vulnerabilities of operating systems

A virus/worm hit can paralyze the system
Spyware installed on the laptop can steal sensitive information
An attacker can try network-based attack to hack into the system
Anybody can view/delete/modify important files
Malicious scripts embedded in the web pages can damage the system
Compromise the laptop security due to insecure operating system settings
Attackers can use brute force/dictionary attack to break weak passwords
Insecure share can be used to implant virus/worm/Trojans
The organization should use several types of network-based and host-based security software, as
detailed below, to detect malicious activity, protect systems and data, and support incident response
efforts and the logs should be generated and archived.
The specimens of a few logs are provided below which reveal information regarding security
concerns.
Intrusion detection system: [**] [1:1407:9] SNMP trap udp [**] [Classification: Attempted
Information Leak] [Priority: 2] 03/06-8:14:09.082119 192.168.1.167:1052 -> 172.30.128.27:162
UDP TTL:118 TOS:0x0 ID:29101 IpLen:20 DgmLen:87
Firewall: 3/6/2006 8:14:07 AM, ‘Rule’ ‘Block Windows File Sharing’ ‘blocked (192.168.1. XXX,
netbios-ssn(139)).’, ‘Rule’ ‘Block Windows File Sharing’ blocked (192.168.1.54, netbios-ssn(139)).
Inbound TCP connection. Local address, service is (XXX(172.30.128.XXX), netbios-ssn(139)).
Remote address, service is (192.168.1.54,39922). Process name is ‘System’. 3/3/2006 9:04:04 AM,
Firewall configuration updated: 398 rules. Firewall configuration updated: 398 rules.
Antivirus software, log 1: 3/4/2006 9:33:50 AM, Definition File Download, XXX, userk,
Definition downloader 3/4/2006 9:33:09 AM, Antivirus Startup, XXX, userk, System 3/3/2006
3:56:46 PM, Antivirus Shutdown, XXX, userk, System
Anti-spyware software: DSO exploit: Data source object exploit (Registry change, nothing done)
HKEY_USERS\S-1-5-19\Software\Microsoft\Windows\CurrentVersion\Internet
Settings\Zones\0\1004!=W=3
Other important logs
1. Operating system logs: Operating Systems (OS) for servers, workstations, and networking
devices (e.g., routers, switches) usually log a variety of information related to security. The following
types of security-related OS data logs should be generated and archived.
(a) System events
(b) Audit record
Operating system log entry: Event type: Success Audit Event Source: Security Event Category:
(1) Event ID: 517 Date: 3/6/2006 Time: 2:56:40 PM User: WIN AUTHORITY\SYSTEM Computer:
KENT Description: The audit log was cleared Primary User Name: SYSTEM Primary Domain: WIN
AUTHORITY Primary Logon ID: (0x0,0x3F7) Client User Name: userk Client Domain: XXX Client
Logon ID: (0x0,0x28BFD)
2. Application logs: Some applications generate their own log files, while others use the logging
capabilities of the OS on which they are installed. Different types of security-related logs could be
generated and archived.
3. Log management infrastructure: A log management infrastructure consisting of the hardware,
software, networks, and media should be in place to generate, transmit, store, analyze, and dispose of
log data.
A log management infrastructure should comprise the following three tiers:
(a) Log generation: The first tier contains the hosts that generate the log data. Some hosts run
logging client applications or services that make their log data available through networks to log
servers in the second tier. Other hosts make their logs available through other means, such as
allowing those servers to authenticate themselves and retrieve copies of the log files.
(b) Log analysis and storage: The second tier is composed of one or more log servers that receive
log data or copies of log data from the hosts in the first tier. The data is transferred to the servers
either in a real-time or near-real-time manner, or in occasional batches based on a schedule or
the amount of log data waiting to be transferred. Servers that receive the log data from multiple
log generators are sometimes called collectors or aggregators. The log data may be stored on
the log servers themselves or on separate database servers.
(c) Log monitoring: The third tier contains consoles that may be used to monitor and review log
data and the results of automated analysis. The log monitoring the consoles can also be used to
generate reports. In some log management infrastructures, the consoles can also be used to
provide management of the log servers and clients. Also, console user privileges sometimes can
be limited to only the necessary functions and data sources for each user.
General
The log management infrastructures should perform several functions that assist in the storage,
analysis, and disposal of log data. These functions are normally performed in such a way that they do
not alter the original logs. The following items describe common log management infrastructure
functions:
(a) Log parsing is extracting data from a log so that the parsed values can be used as input for
another logging process. A simple example of parsing is reading a text-based log file that
contains 10 comma-separated values per line and extracting the 10 values from each line. Parsing
is performed as part of many other logging functions, such as log conversion and log viewing.
(b) Event filtering is the suppression of log entries from analysis, reporting, or long-term storage
because their characteristics indicate that they are unlikely to contain information of interest. For
example, duplicate log entries and standard informational entries might be filtered because they
do not provide useful information to log analysts. Typically, filtering does not affect the
generation or short-term storage of events because it does not alter the original log files.
(c) In event aggregation, similar entries are consolidated into a single entry containing a count of
the number of occurrences of the event. For example, a thousand entries that each record part of a
scan could be aggregated into a single entry that indicates how many hosts were scanned. An
aggregation is often performed as the logs are originally generated (the generator counts similar
related events and periodically writes a log entry containing the count), and it can also be
performed as part of log reduction or event correlation processes which are described below:
Storage
(a) A log rotation is closing a log file and opening a new one when the first file is considered to be
complete. Log rotation is typically performed according to a schedule (e.g. hourly, daily, weekly)
or when a log file reaches a certain size. The primary benefits of log rotation are preserving the
log entries and keeping the size of log files manageable. When a log file is rotated, the preserved
log file can be compressed to save space. Also, during a log rotation, scripts are often run that act
on the archived log. For example, a script might analyze the old log to identify malicious activity,
or might perform filtering that causes only some log entries meeting certain characteristics to be
preserved. Many log generators offer log rotation capabilities; many log files can also be rotated
through simple scripts or third-party utilities, which in some cases, offer features not provided by
the log generators.
(b) Log archival is retaining the logs for an extended period of time, typically on removable media,
a Storage Area Network (SAN), or a specialized log archival appliance or server. The logs often
need to be preserved to meet legal or regulatory requirements.
There are two types of log archival: retention and preservation. Log retention is archiving logs on
a regular basis as part of standard operational activities.
Log preservation is keeping the logs that normally would be discarded, because they contain
records of activity of particular interest. Log preservation is typically performed in support of
incident handling or investigations or requirement by law, e.g. Information Technology Act.
(c) Log reduction is removing the ‘not needed’ entries from a log to create a smaller new log. A
similar process is event reduction, which removes ‘not needed’ data fields from all log entries.
The log and event reduction are often performed in conjunction with log archival so that only the
log entries and data fields of interest are placed into long-term storage.
(d) Log conversion is parsing a log in one format and storing its entries in a second format. For
example, conversion could take data from a log stored in a database and save it in an XML
format in a text file. Many log generators can convert their own logs to another format; third-party
conversion utilities are also available. A log conversion sometimes includes actions such as
filtering, aggregation, and normalization.
(e) Log normalization is the process in which each log data field is converted to a particular data
representation and categorized consistently. One of the most common uses of normalization is
storing dates and times in a single format. Normalizing the data makes analysis and reporting
much easier when multiple log formats are in use. However, normalization can be very resource-
intensive, especially for complex log entries (e.g., typical intrusion detection logs).
Analysis
(a) Event correlation is finding relationships between two or more log entries. The most common
form of event correlation is rule-based correlation, which matches multiple log entries from a
single source or multiple sources based on logged values, such as timestamps, IP addresses, and
event types. Event correlation can also be performed in other ways, such as using statistical
methods or visualization tools. If correlation is performed through automated methods, generally
the result of successful correlation is a new log entry that brings together the pieces of
information into a single place. Depending on the nature of that information, the infrastructure
might also generate an alert to indicate that the identified event needs further investigation.
(b) Log viewing is displaying log entries in a human-readable format. Most log generators provide
some sort of log viewing capability; third-party log viewing utilities are also available. Some log
viewers provide filtering and aggregation capabilities.
(c) Log reporting is displaying the results of log analysis. Log reporting is often performed to
summarize significant activity over a particular period of time or to record detailed information
related to a particular event or series of events.
Disposal
Log clearing is removing all entries from a log that precede a certain date
and time. Log clearing is often performed to remove old log data that is no longer needed on a system
because it is not of importance or it has been archived.
The logs should be rotated. The confidentiality, integrity, and availability of each type of log data
should be protected while in storage (at both the system level and the infrastructure level).
The period up to which each type of log data is to be preserved should be based on the
organization’s document retention policy and applicable legal regulations. The log data, not needed
should be disposed off as per company’s policy.
The System Administrator is responsible for the following functionalities:
(a) Monitoring the logging status of all log sources.
(b) Monitoring log rotation and archival processes.
(c) Checking for upgrades and patches to logging software, and acquiring, testing, and deploying
them.
(d) Ensuring that each logging host’s clock is synchronized to a common time source.
(e) Reconfiguring logging as needed, based on policy changes, techno-logy changes, and other
factors.
(f) Documenting and reporting anomalies in log settings, configurations, and processes.
(g) Contacting system-level administrators to get additional information regarding an event or to
request that they investigate a particular event.
(h) Identifying changes needed to system logging configurations (e.g., which entries and data fields
are sent to the centralized log servers, what log format should be used) and informing system-
level
administrators of the necessary changes.
(i) Initiating responses to events, including incident handling and operational problems (e.g., a
failure of a log management infrastructure component).
(j) Ensuring that old log data is archived to removable media and disposed of properly once it is no
longer needed.
(k) Co-operating with requests from legal counsel, auditors, and others.
(l) Monitoring the status of the log management infrastructure (e.g. failures in logging software or
log archival media, failures of local systems to transfer their log data) and initiating appropriate
responses when problems occur.
(m) Testing and implementing upgrades and updates to the log management infrastructure’s
components.
(n) Maintaining the security of the log management infrastructure.
SECTION C............................................CHAPTER 23
Audit Tools
23.1 INTRODUCTION
In an advanced computerized environment, it is impossible to carry out testing of systems manually.
The objectives of testing in a computerized environment are the same as in manual system. The
methodology of testing alone changes. The computer based tools and techniques facilitate a more
effective performance of computer assurance audit. The type of tool to be used is dependent upon the
technology, the type of application to be reviewed and most importantly, the expertise and knowledge
of the individual who proposes to use the tool. The procedures for obtaining audit evidence according
to Information Systems Audit and Control Association, USA (ISACA)–IS Auditing Standard 14 are:
Inspection
Observation
Inquiry and confirm
Computation, and
Analytical procedure
To obtain that above evidences in a computerized environment, it becomes necessary to test the
completeness, authorization and accuracy of
Input
Standing data
Processing and output
23.2 USAGE OF AUDIT TOOLS

There are many useful audit tools which can be effectively used by a competent individual having
adequate knowledge of the particular information technology environment and the functionality of the
particular business process.
In this chapter, discussion is centered round the audit tool ‘ACL’. This is due to the fact that the
author’s consultancy organization has extensively utilized this tool for their clients in many industry
verticals and quite complex IT environments. The ACL software is supplied by the vendors in a CD
along with relevant documentation. A toggle switch is also provided which ensures that only licensed
use of the tool is possible. The types of data files that ACL can read are as follows:
Flat Sequential File: Flat sequential file contains sequential data. It has rows of consecutive data
arranged one after the other. Each file has rows of data and each row is divided into various fields.
.dbf File: ACL will be able to automatically detect this data type. However, ACL would not be
able to read the associated files like the index and memo files.
.txt File: The text file contains only printable characters. However, they may not be print files.
Print Files: Print files are text files. The tool ACL will be able to filter the header, blank lines,
total line while extracting data from the file.
.del File: (delimited): In a delimited file, each field is separate from the other by a field separator
character. The ACL would be in a position to automatically detect this type of files.
The flat sequential files are the files which contain rows of consecutive data sequentially arranged.
Each of the rows of data would be divided into fields. The audit tool ACL would be able to
automatically do the following:
detect
analyze and
create data definition
However, most of the databases have no capabilities to save data in flat or .dbf or.txt files. In the
circumstances, it becomes necessary to save the files to be analyzed in one of the above-mentioned
formats. Also, on saving, relation or index is not saved. The files are saved as records and fields
appear physically in the files. The audit tool ACL has the capacity to set relation, index and sort files.
In case the production system which needs to be analyzed for audit purposes does not have the
capacity to save the files as one of the above-mentioned category, the system needs to be Open Data
Base Connectivity (ODBC) compliant. For the system to be ODBC compliant, it becomes necessary
to have ODBC drivers as they only enable access to the database.
23.2.1 ODBC Compliant

ODBC is an application programming interface. It enables multiple heterogeneous database access.
ODBC enables applications to access, view, and modify data from different data sources.
23.2.2 ACL windows

There are four types of Windows in ACL which are mentioned herein below:
View
This contains the data in rows and columns. In the view window:
Data can be re-arranged.

Filters can be applied so that the records which meet the defined criteria can be extracted.
Commands can be issued.
It is possible that the view can be formatted. It is possible to add a computed column. It is also
possible to delete a column from the view.
Overview
An overview window provides a few of the input file definitions as:
Batches
Input file definition
Views
Work places
Indexes
Last result
The last result window shows the results of the last command issued. These results can be printed for
review and verification.
Command log
Whenever the ACL document is opened, it automatically opens a log file. This log file captures every
activity, command and message which can be effectively used as working papers by the auditor.
Creation of ACL document
Initial steps for using the ACL tool would be to create an ACL document which has:
Batches
Input file definition
Indexes
Views
Workplaces
Log file
A document maintains a description of the data in the data file, reports and automated procedures.
An ACL has the facilities which enable an auditor to understand the data and verify its validity.
Understanding of data includes:
Detection of invalid data

Detection of errors in data files
Finding of duplicates and gaps
Analysis of files: The file may contain a collection of data. If the objective of the audit is to sieve a
set of data or a portion of the file which satisfies a particular condition, ‘if’ command would be
given. When the command is executed the required data would be extracted from the file and given as
a report to the auditor.
Filter: The filters enable selection of records depending upon the filter conditions. It enables the
selection of transactions that satisfy a given condition.
Examples: 1. Loans above Rs. 5,00,000
2. Transactions after 30th September and before 31st March
3. Transactions authorized by particular user ID that year
Output files: Whenever an output file is created, the audit tool ACL creates a record of the
commands and options used to create the file. This record is called the ‘file history’. This is of great
use to the auditor as information is always available as to on what basis an output file has been
obtained.
Use of ACL for auditing different information systems: The audit tool is versatile and it is upto a
competent individual to effectively use the tool and obtain critical information to form an opinion on
the effectiveness of controls within the system. An illustrative situation when ACL Audit tool could
be used in a banking environment could be analyzing the data base of the loan module.
The usage of the tool effectively depends upon the individual and his competence in performing an
effective audit.
Given below is an example of various tests which could be conducted in the Loan Module.
Illustrative use of ‘ACL’ Tool for analyzing the data in a loan module
The features of ACL for drilling down, filtering the field, sorting, linking the tables, selection of
different tables and fields, selecting customer view etc. were utilized to analyse the database. The
database was analyzed for the following:
1. It is a policy that maker and checker rules will be observed strictly, i.e. the person who enters
the transaction cannot also authorize the same. Whether the same person who creates a record
has also autho-rized it.
2. Whether the sanctioned amount is less than the disbursed amount or amount disbursed is more
than the sanctioned amount.
3. Whether in case, a customer has got loans in multiple schemes (CC, LC etc.) it does not
exceed its total overdraft limit.
4. Whether loan sanctioned is linked to transactions file containing Post-dated Cheques (PDC).
Sanction should cover the PDC.
5. Whether loans treated as closed in the system has ‘Nil’ balance as outstanding or a very
insignificant amount.
6. Verify whether sanction criteria have been adhered to, i.e. whether a loan amount has been
disbursed without a loan having been sanctioned actually in the system. This could happen by
bypassing controls.
7. Whether charges have been collected in all cases of cheques returned.
8. Whether the system shows as if the loan has been sanctioned by a proper authority while
evidence is to the contrary.
9. Whether the sanctioned amount is greater than the loan requirement and also verify the user
IDs.
10. Whether there are cases where sanction is pending, but the loan amounts have been disbursed.
11. Whether the approval process is in order. Verify whether authorization is back-dated.
12. Whether tenure of the loan is in line with minimum prescribed time-frame.
13. Whether the authorization procedures are in line with Company’s policy?
14. Whether the authorization procedures are in conformity with approved procedures regarding
stages of disbursement?
15. Whether when loans are sanctioned at the branch level, they are in line with company policy.
Check whether there are compensating controls?
16. Whether all procedures have been followed in ‘Closed Loan’ account to be verified by
choosing a sample closed loan?
17. Whether in the case of a pre-closure loan, computation is in order could be verified? Whether
correct related charges are collected?
18. New loan disbursement—Review pending list of new loans on any specific categorization.
A sample of output obtained by using ‘ACL’ tool

A hypothetical report obtained is discussed to illustrate the usage of the tool and reports which could
be obtained.
The various aspects proposed to be checked are mentioned in ‘bold’ letters. It is followed by the
ACL command and under the ‘remarks’ paragraph, the same is explained in plain English.
It is upto the individual concerned, to decide on what aspects to check. Appropriate commands
(which are quite simple) may be used to obtain evidence to form an opinion on adequacy or
otherwise of the controls.
1. Maker and checker rules

• User_ID = Blank
• User_id (RAM) = Authorized _by (RAM) or Sanction by (RAM)
No. of Record Found – 100
Remarks
• User_ID is blank – User-id supposed to be mandatory for all the records and maker and
checker should not be the same person.
• Check any Migration activity has taken place or not, if migration is taken place then we
should eliminate till such date.
2. Sanction limits check
• Amount sanctioned is greater than Rs. 500,000 where there is no authorization or blank field.
• Sanction amount greater than Rs. 500,000 and less than
Rs. 10,00,000.
• Sanction amount greater than Rs. 500,000 and less than Rs.10,00,000 where sanction by
other than branch manager.
Remarks
• We can check organization Approved Sanction Limits versus Database Authorized by. e.g. A
= Rs. 500,000, B = Rs.10,00,000 and C = Rs. 15,00,000
• Also, in case the customer got multiple products (Loans and Deposits) under the same
customer ID
• Find customer ID = 12345 and sanction by and loan and deposit ID
• From the database the relevant records will be displayed. By analyzing each products and
relevant records we can arrive at a solution. e.g. Total Amount Received, time intervals and
sanctioned by, etc.
3. Customer validation
• Customer_id = ‘1234’ or Customer name = ‘Ramesh. N’ where PAN Number is
‘1234567890’
Remarks
• Find out single customer against no. of loans taken.
4. Validity check
• Loan sanction amount greater than Rs. 10,00,000, Sanction_by = ‘Y’ and Repayment/EMI
field = ‘is blank’ or less than sanctioned amount
5. Closed loans
• Closed loans = ‘Y’ and repayments is greater than Rs. 1,00,000 and Rs. 200,000 and Rs.
3,00,000 etc.
• Closed loans table where outstanding amount is greater than
Rs. 100.
Remarks
• To check outstanding amount in the closed loans
• No. of cases with such records, etc.
6. Sanction criteria
• Loan Sanction = ‘NO’, Sanction_Date, Sanction_by, Sanction_amt, user_id, Authorisation =
‘yes’.
Remarks
• To find out Loan not sanctioned but other processes have taken place.
7. Cheques returned cases
• Cheques returned is ‘yes’, Cheques Return_Charges is ‘Blank’.
Remarks
• No. of cases where cheque return charges was not collected.
8. Loans Authorization
• Loans sanctioned by is ‘yes’ , Authorization and Sanction_user_id = ‘blank’
Remarks
• Loan sanctioned without authorization and user id
9. Amount validation
• Loan sanction amount is greater than the loan requested amount with Sanctioned_by and
Authorised_user_ id is ‘yes’
Remarks
• Reason for loan enhancement and find out any authorization procedures bypassed or not.
10. Pending cases validation
• Sanction_hold is ‘yes’ where cancellation is ‘NO’, Sanction_amount is ‘Not Blank’,
Sanction_by is ‘yes’, Sys_date = 1/4/05
• Sanction _hold is ‘yes’ where amount_disbusement is ‘yes’, stages_disbusement is ‘NOT
Blank’
Remarks
• As on 1st April 2005 file is put on hold but where other procedures have taken place, find
out such records and their analysis.
11. Approval processes
• Authorization date earlier than System_date , Recommended_date and
Enhanced_requested_date
Remarks
• Find out any backdated entry in the system.
12. Tenure validation
• Loan _amount is greater than Rs.10,00,000 where tenure is less than 12 months in loan
• Tenure of the loan is ‘Zero’
Remarks
• Find out any dummy loans are created and kept in suspense.
13. Voucher authorization
• Voucher_created = Voucher_Authorization
• Voucher created ‘yes’, Voucherauthorized ‘No’ Dr_amount is ‘greater than Rs. 1000, Rs.
2000’ etc.
Remarks
• Check the transaction authrorization (creator vs. authorizer)
14. Disbursement authorization check
• File_no = ‘12345’ , stagesof_disb = ‘not Zero’ disb_amt_stages = ‘not Zero’, Total
Sanction_amt = ‘not Zero’ sanctioned _by = ?
Remarks
• Here for the particular file no. we can trace stages of
disbursement, disbursement amount at each stages, total sanction amount, sanction by, etc
15. Branch level sanction limits and authorization
• Branch_code = MAD, Amt_sanctioned greater than Rs. 5,00,000 and Less than Rs.
10,00,000, authorized_by = ‘not blank’
Remarks
• To check whether branch level limit and approved authrorization processes followed or not.
16. Closed loans- End to End Trace
• Loan closed = ‘y’, file_no = ‘not blank’ other fields may be selected for the analysis, e.g.
Amt_requested, Amt_sanctioned, Recommend_by, Sanction_by, user-id, Authorized_user-id,
etc.
Remarks
• Check whether all the procedures followed or not.
17. Pre-closure loans details
• Pre_closure = ‘Y’, by selecting appropriate tables, e.g. outstanding amount, principal
outstanding, EMI outstanding, pre-EMI interest outstanding, other dues, etc.
Remarks
• By analyzing the above fields we can arrive at conclusions about pre-closure loans and
whether related charges were collected or not.
18. New loan disbursement process
• Loan_req= ‘Y’, Recommended = ‘Y’, Technical_sanction = ‘y’, Amt_ Sanctioned = ‘not
Zero’ and Sanction_by = ‘N’
Remarks:
• We can find list of pending cases, list of cases waiting for final approval. By changing
different condition we can analyze these cases. e.g.: technical sanction = ‘N’ but Sanction_ by
= ‘Y’
SECTION D............................................CHAPTER 24
Instances of Frauds,
Its Causes and Controls
So far in this book, both in Section A and Section B, the various concepts of the Core Banking
Solution and the best method of implementing the same are covered. The chapters in Section B
specifically covered the methodologies to be adopted, for evaluating controls in a computerized
environment. As professional auditors and members of Inspection and Audit Department know
income leakages and frauds still occur frequently. These leakages and frauds are discussed and
published in print media as computer frauds in banks! These misleading headlines sometimes lead to
a misunderstanding of the situation. It is not that frauds are occurring in computerized environments
only. Sometimes, there are individuals with fraudulent intentions who always want to exploit the
vulnerable situations and weak controls and indulge in frauds. This is done with an intention to have
illegal financial gains. These frauds could be done faster in a computerized environment. There could
be more income leakage.
It would not be out of context to discuss the Equity Funding Case, which has been an eye-opener.
The fraud committed in the Equity Funding Case in the year 1973 in California, laid the foundation for
the evolvement of the profession of systems audit or auditing in a computerized environment. In the
Equity Funding Case, the brief particulars are as follows:
It was an insurance company and the management decided to adopt some means by which they
could make the performance of the company look better than what it was and thus, have the value of
the shares of the company go up. In the process, the management decided that they would create fake
insurance policies so that income would be enhanced and correspondingly sundry debtors are also
enhanced. This company had its presence in very many states in the United States of America. The
company’s auditors included the Big 4 (maybe the Big 6 then). After two years, the management got
further emboldened and they decided that it would be faster to fake insurance policies if they use the
computers in the place of the manual systems.
It was thus that the computers came into the picture. The role played by the computers was nothing
more than a facilitator for printing the insurance policies faster.
Two or three years of the usage of the computers resulted in projection of greater profits and the
expected results of the share value of the company going up happened. The Directors of the company
were happy and the auditors of the company had given a clean chit all through the years. It was a
chance revelation by a disgruntled employee which burst the bubble. The share values crashed. The
Securities and Exchange Commission (SEC), a body in USA similar to SEBI of India, had to
investigate the matter. The subsequent events as they say is history.
The auditors were hauled up for dereliction of duty, negligence and also fraud. The Board of
Directors was also held guilty of fraud. Some of the auditors settled the case outside the court. It was
in those days as shocking an event as ENRON, WORLDCOM etc., which occurred recently.
A detailed examination of the sequence of events was conducted by the Government. It was then
brought to light that while some of the auditors were fraudulent, many others were ignorant of
performing an audit in a computerized environment. They believed that as computers are infallible
any statement prepared by the computer also is infallible. They were not aware of the controls which
have to be in place if they have to rely on the computer statements. They were also not aware that in
the absence of controls within the computer systems there should be at least compensating controls
outside the system.
In view of total lack of appropriate knowledge with the auditors, it was realized that auditors need
to have a different type of knowledge to perform audits in a computerized environment effectively and
efficiently.
It is in this background that we need to understand that however advanced the computer technology
may be, unless the associated controls are in place, it would be a misconception to believe that, the
environment is foolproof and that no fraud can occur. As a matter of fact, it needs to be realized that
fraudsters who are intelligent would be making use of the sophisticated environment as a tool to
perpetuate unconventional frauds.
In the following paragraphs, it is proposed to consider a few of the live cases, where frauds have
occurred in a computerized banking environment. Many frauds have occurred in other industries also.
These are the cases known to the authors of the book due to their association with many bank
officials, as also auditors and faculty members in their academic activities, meeting participants and
professionals.
The methodology proposed for presentation of some the live cases of fraud would be:
1. Narrate the scenario where the fraud has occurred.

2. Discuss which control was not in place which facilitated the occurrence of the fraud.
3. Suggesting a method which could pro-actively have prevented the fraud or detected it soon
after the event.
All the cases discussed are not relating to Core Banking Solution (CBS). They include the cases of
real occurrence in Total Branch Automation (TBA) also— the technology environment which was in
existence before implementation of CBS.
CASE STUDY 1 NON-CORE BANKING CASE STUDY
The Scenario
In a bank, there was a senior clerk who worked very hard, much beyond the call of duty. He was
knowledgeable and could discharge different responsibilities. The manager of the branch was
understandably very impressed by the ‘selfless support’ being provided by the staff member. After a
year of operation of the branch, it was discovered that a sum of about approximately Rs. 2.5 lakhs has
been defrauded. In other words, customers’ money which was supposedly deposited in the bank, was
not accounted for. The bank had, after some deep analysis, the reason to believe that the particular
employee would have committed the fraud. But they had no conclusive evidence to prove their
suspicion. The concerned employee had indeed committed the fraud.
CONTROLS THAT WERE NOT IN PLACE
The bank did not follow the procedure of giving the access rights on a ‘need to know’/‘need to do’
basis. The access rights were provided on the request of the branch manager. User IDs and
passwords are provided for the different individuals. If an individuals has access to different user
IDs and passwords, he would be in a position to perform different duties and more importantly the
duties higher than his position in the bank would warrant. In this particular case discussed, the bank
did not follow the procedure as laid down by the security policy of the bank. The policy document of
the bank had clearly mentioned that;
(i) user access rights need to be given on a need to know basis.
(ii) there should be a register maintained with the following headings:
• Name of the individual
• Date of assigning the user ID
• Date of removing the user ID
• Signature of the employee
This register was envisaged by the security policy so that accountability of the individuals would
be established. The register which is originally started falls into disuse in many banks. This bank was
no exception. The concerned individual had not signed the document and hence he had not, legally
speaking, accepted the user ID allotted to him. The bank by exchange of mails had established within
itself that a particular user ID was assigned to the individual without ensuring that the employee also
accepted it as his user ID by signing the register.
The employee was encouraged by the manager to use different user IDs and the corresponding
passwords. There was no evidence that this particular individual used those user IDs and passwords.
On the other hand, he was encouraged to use other user IDs also by which process it apparently
looked that the transactions were performed by somebody other than the particular individual. He was
given rights of database administrator also. He fiddled with the database. He had created one
database for printing passbook and another for ledger purposes!
What Would Have Prevented the Fraud?

The security policy should have been strictly implemented. A periodic review should have been
performed of all user IDs and passwords in the system to ensure that the live user IDs in the branch
belong to those who are currently working in the branch. An analysis would have revealed, if there
had been employees using other user IDs or wherever access user IDs which might have belonged to
a transferred employee or resigned employees.
The maintenance of the register with the requisite information duly signed by the employee, should
always be current and periodically examined by the branch manager as also the Inspection and Audit
Department or any other audit department.
The branch manager by having encouraged the employee to perform other duties is guilty of
contributory negligence and dereliction of duty and gross violation of security policy requirements.
What Happened in the Live Situation

The circumstantial evidence conclusively proved the fraudulent activities of the individual. However,
the bank was in no position to take legal action much as they wanted to, because they were advised by
the lawyers that in the absence of conclusive evidence their case would not stand a chance in a court
of law. The systems auditors were called in to find out the methodology adopted by the culprit. By
using some additional audit tools and programs, they were able to establish how it was possible for
the individual to have committed the fraud. The bank confronted him with all the evidence and used
other pressures. The employee admitted his guilt and paid back the money to the bank. This situation
highlighted the facts as to how the fraud was committed due to non-complying with best practices for
allotting access rights on a ‘need to know basis’/‘need to do basis’.
CASE STUDY 2 VULNERABILITY IN ACCOUNT MAPPING

The Scenario
The fraud was committed due to vulnerability in mapping of accounts in a Core Banking Solution
(CBS). Mapping of accounts is done only in one place which is at the Central Computer Department
(CCD). In the present scenario, the General Ledger (GL) heads were created and access given to the
branches in such a way that any GL head could be debited or credited. One employee utilized this
feature to debit a GL which had accumulated unreconciled debit balances and credited his personal
account.
Controls that Were Not in Place
The classification in mapping of accounts was done in a manner, such that any GL head could be
debited/credited without restriction.
What Would Have Prevented the Fraud
The software should have provided facility to restrict debits/credits to certain GLs. For example,
debit transactions should not be allowed in income GLs.
CASE STUDY 3 VIOLATION OF SECURITY PRINCIPALS
The Scenario
A loan was unauthorizedly granted. The loan papers were perused and at the appropriate level loan
was sanctioned. The disbursement can be done only after due authorization by a senior level officer.
The junior level employee after obtaining such authorization would be able to disburse the money. In
the instant case, the user ID and password of the senior level officer was known to the junior level
employee. At some point of time, the concerned officer had disclosed the same and allowed the junior
level employee to use it to hasten the work. The senior officer did not change his password
subsequently. The employee exploited the situation.
Controls That Were Not in Place
The best practices for access rights was not complied with. The security policy requirement that no
employee should allow his user ID or password to be compromised, was violated.

Proper employee training and sensitization regarding the importance of user IDs and password could
have acted as appropriate control. The employees should have been made aware thorough official
communication from H.R. that deviation from security policy would amount to dereliction of duty.
Passwords are as sensitive as any key of the Branch. They should never be shared as much as
cash/Branch keys would never be.
CASE STUDY 4 CORE BANKING SOLUTION
The Scenario
A bank in the process of implementing CBS had a central support team at the CPPD. These users
were allowed unrestricted remote access to the branches. One employee used this facility to transfer
funds from in-operative accounts of branches to a particular account of her relative. The money was
subsequently withdrawn. This came to light during regular concurrent audit of the bank when the
auditor noted that there was movement in the in-operative account.

The implementation team was given unrestricted remote access to the branches which is not in line
with best practices.

Enabling only appropriate access rights and monitoring activities of users could have prevented the
fraud.
CASE STUDY 5 ATM FRAUD
The Scenario
An employee of a bank used an ATM card number and the pin mailer available at the branch to
withdraw money from a customer account to the extent of Rs. 1 lakh over a couple of days. The
customer in whose favour the ATM card was issued by the bank, had not yet collected the card but
was debited with the sum of Rs. 1 lakh.
Understandably, the customer was shocked to find that a sum of Rs. 1 lakh was withdrawn from his
account, while the fact was that he had not even received the ATM card.

The bank had not followed the best practice of sending the ATM Card and PIN mailers through
separate delivery channels. Also the ATM cards were not kept under safe custody at the branch and
no inventory of the same was maintained.

The best practice to be followed is that at no point of time, the ATM card and PIN mailer should be
available at one place.
The PIN mailer should be directly mailed to the customer. The card may be mailed to the branch
for personally being handed over to the customer. If the mailed PIN mailer is to be returned to the
bank due to non-availability of the customer or for any other reason the address for the returned PIN
mailer should be to the central office of the bank and not to the branch. In this particular case, the PIN
mailer was returned to the branch in contravention of the best practice prescribed. In addition, the
PIN mailer and the card should be with two different officers of the bank and not be available for any
single employee alone. Even this best practice was violated.
CASE STUDY 6 PARAMETERIZATION
The Scenario
Parameterization like creating new products etc., is done at the central location. In the present case, a
bank which was celebrating its 25th year had decided at a special rate of interest for the fixed deposit
for a period of 25 months. However, due to wrong parameterization, while creating the product, it
was possible for a customer to earn the same interest for a shorter period. It was discovered that
while the original duration was for a period of 25 months, the interest which was reasonably high
was applicable for premature closure of the same. Interest was paid at a much higher rate, in
contravention of Reserve Bank of India (RBI) regulations.

The parameterization of the product should have been done in a manner, such that their own special
rate of interest is not payable if the duration of the fixed deposit is closed prematurely.

The rate applicable should have been parameterized so that the applicable rate as permitted would
not be available for shorter periods. As otherwise, it was possible to exploit the situation. Also a
proper system testing would have detected the wrong parameterization.
CASE STUDY 7 APPLICATION PROGRAM ERROR
The Scenario
In a bank, the deposit module was functioning properly. A fixed deposit could be created. There was
facility for a loan to be granted on the security of the fixed deposit. A lien was marked on the fixed
deposit. The functionality as implemented originally was that a fixed deposit would not be repaid if a
loan is outstanding on a fixed deposit, in view of the link having been established. Only after the loan
is cleared, would the link between the fixed deposit and the loan be released.
This particular module was in force for more than two years and functioning properly. However, in
a particular branch, it was able to repay the fixed deposit in spite of the loan being outstanding. As a
result, the loan became a clean loan without any security. A general investigation of bad debts
revealed that in spite of the fixed deposit having been offered as collateral to the loan, the fixed
deposit was paid on maturity.

As the malfunctioning of the program was a matter of serious concern, systems development life cycle
methodology and the actual practices were reviewed by the systems auditor. It was discovered that
subsequent to the original development of the program, there was a need for a change to be made to
the program regarding preclosure. At that point of time, the program should have been retested
completely to ensure that the existing functions in the program were not affected. This process of
testing the whole program every time a change is made as referred to as regression testing. This
procedure was ignored in the instant case.
System development methodology and change management procedures should be strictly adhered to.
An auditor should review change management procedures followed, apart from it being the primary
responsibility of the Security Officer to ensure that laid down procedures are strictly followed.
CASE STUDY 8 ANYWHERE BANKING
The Scenario
The following is not a case of fraud but a security concern. The bank management were concerned
about privacy issue being violated and corrective action was taken.
The customers were given the facility of viewing their own account on the net. The customers were
given a user ID and password as a response to their request for the same. By using the user ID and
password and requesting for a statement of account, they would be able to view their own account
only and also be in a position to get a printout of the same. In one of the cases, in a bank, a customer
was not only able to view his own account, but was also in a position to view six other accounts and
he could get printouts of the same and gave it to the bank. The customer’s concern quite correctly was
that if he could view the accounts of 6 other individuals, it was possible that his account also could
be viewed by the other customers. This was gross violation of the professional service assured by the
bank which includes maintaining privacy and secracy.

In the present case the password was not strong. It was possible to give the user ID and password of
a few others by knowing their names. The customer was able to even take a statement of the account
of the Chief General Manager by accident. This was possible because the password was not strong
and was easily guessable.

The security concern was that the privacy of the customer was not maintained which is a basic
requirement in banking operation. The user ID password creation was being done without conforming
to the best practices regarding the number of characters, complexity etc. The bank, since then
corrected the situation and avoided further embarrassment and possible legal action.
SECTION E............................................CHAPTER 25
Relevant ISACA Standards,

Guidelines and Procedures
25.1 INTRODUCTION
The Information Systems Audit Control Association (ISACA), USA is an internationally recognized
professional body which specializes in the area of computer assurance and risk management.
Recognizing that Information Systems Auditing and the skill necessary to perform such audits, ISACA
has issued standards that apply specifically to IS Auditing. As of April 2008, ISACA has issued:
16 standards
39 guidelines
11 procedures
The complete details of the standards, guidelines and the procedures are available at the ISACA
website, www.isaca.org. In the following pages with the permission of ISACA, excerpts of some of
the standards, guidelines and procedures are being included. According to ISACA, the standards are
mandatory, while the guidelines are recommendatory. The objective of the auditing guidelines is to
provide additional information on how to apply the IS auditing standards. However, though the
guidelines are not mandatory, any departure needs to be justified by the systems auditor. The
procedures provide details of procedures to be followed under different circumstances to comply
with the standards. Given below are the list of standards, guidelines and procedures which may be
found relevant and appropriate for performing systems audit of banks.
25.1.1 Standards
S3 — Professional ethics and standards
S4 — Competence
S11 — Use of risk assessment in audit planning
S13 — Using the work of other experts
S14 — Audit evidence
25.1.2 Guidelines
G1 Using the work of other auditors
G2 Audit evidence requirements
G4 Outsourcing of IS activities to other organization
G7 Due professional care
G9 Audit consideration for irregularities
G11 Effect of pervasive IS controls
G13 Uses of risk assessment in audit planning
G14 Application system review
G24 Internet banking
G28 Computer forensics
G30 Competence
G31 Privacy
G32 Business continuity planning—review from IT perspective
G33 General consideration on the use of the Internet
25.1.3 Procedures
P1 Electronic fund transfer
P3 Intrusion detection
P6 Firewalls
Contents of a few of the standards, guidelines and procedures are given below:
supplemented
by comments
by authors.
Standard 3: Professional ethics and standards
This Standard apart from expecting the auditors to strictly adhere to the code of professional ethics
expects them to exercise Due Professional Care in conducting audit assignments.
The guideline number 7 deals with due professional care. The definition provided for ‘Due Care’
is as follows: ‘The standard of due care is that level of diligence which a prudent and competent
person would exercise under a given set of circumstances’.
‘Due Professional Care’ applies to an individual who professes to exercise a special skill such as
Information Systems Auditing. The guideline proceeds further to state that an individual exercising
due professional care should exercise the special skill to a level commonly possessed by
practitioners of that speciality.
Due Professional Care implies that the professional auditor approaches the work with professional
diligence. This care extends to every aspect of the audit extending to:
Evaluation of audit risks

Formulation of audit objectives
Establishment of audit scope
Selection of audit test
Evaluation of test results
The Standard further states that the intended recipients of the reports have, understandably an
appropriate expectation that the Information System auditor has exercised due professional care
throughout the process of audit.
The Standard categorically states that an IS auditor should not accept the assignment unless he has
the adequate skills and knowledge to complete the work in a manner expected of a professional.
The auditor is expected to disclose the circumstances of non-compliance with professional
standards to all those who receive the communication of the audit results.
However, this Standard also states, that a situation may arise when in spite of the auditor exercising
due professional care, an incorrect conclusion may be drawn based on a diligent review of the facts
and circumstances. The subsequent discovery does not indicate lack of diligence on the part of the IS
auditor. As long as he has exercised due professional care, and has the evidence to prove it,
subsequent discovery of incorrect conclusion does not prove lack of exercise of due professional
care by the auditor.
Standard 4: Competence
This Standard lays down that a person who performs an Information Systems Audit should be
professionally competent and have the proper skills and knowledge to conduct such an audit.
In the present scenario of highly technical environment of a core banking solution, it becomes very
relevant to perform an audit of a core banking solution by an individual or group of individuals and
he/they should be highly competent. It is in this context that the Reserve Bank of India has issued the
guidelines that the auditors should be a Information Systems Auditors certified by ISACA. For
example, the banks proposing to introduce Internet banking need to get a certificate that there are
appropriate controls including effective intrusion detection systems. A certificate from a competent
person is required by Reserve Bank of India as a pre-requisite before the bank is permitted to use
Internet Banking for processing transactions. Earlier Reserve Bank of India (RBI) insisted on
certification even for just commencing Internet Banking, e.g. viewing of website.
Similarly, in other areas also systems auditors should have the competence and need to maintain it
by continual upgrading of knowledge and skills which become necessary with the technology getting
upgraded so often. The guideline further proceeds to lay down the following:
IS auditors need to have the desired level of competence which will be applied with due care
and diligence.
IS auditors who are not competent to perform should refrain from performing such services.
The audit management is responsible to entrust the audit assignments after ensuring that the IS
auditor possesses required professional and technical skills (it will be observed that in most of the
tender documents, calling for the audit of banks in a computerized environment, details of the profile
of the concerned consultants supported by documentary evidence is called for). Skills and knowledge
include proficiency in identification and management of risks and controls.
Competence means and includes possession of skills and knowledge supported by educational
qualifications and experience.
The Information System auditor and/or audit management should provide reasonable assurance
about the skills and educational qualifications and experience prior to accepting the assignment.
Where there are gaps between the actual level of competence and the expected level of
competence, this needs to be recorded and concurrence of the auditee needs to be obtained for
continuation of the audit.
Importantly, the auditors should not portray themselves as having expertise and competence which
they do not possess.
When any part of the expertise or knowledge is not available with the auditor, it is acceptable to
outsource that part of the assignment to an expert. However, there needs to be reasonable assurance
provided that the outsourced agency possesses the required competence!
Standard 11: Use of risk assessment in audit planning
The systems auditor is expected to use an appropriate risk assessment technique in developing an
audit plan and in determining priorities.
Use of risk assessment in the selection of audit projects facilitate the auditor to quantify the amount
of IS audit resource.
Comments: While performing IS audit, a competent auditor would know where the risks are likely
to be high. For example, inappropriate access rights, or lack of good password practices are the high
risk factors.
Similar would be the scenario with vulnerabilities in network. (Also refer to Guideline No. 13
which deals with use of risk assessment in audit planning)
Standard 13: Using the work of other experts
The Standard states that Information System auditor should consider the work of other experts, after
satisfying themselves about their professional competence, relevant experience and quality control
processes before engaging them.
It is necessary for the IS auditor to assess whether the work of the other expert is adequate and
complete so as to help him to conclude on the current audit objectives. If the work of the other expert
does not provide adequate evidence, it is necessary for the auditor to apply additional audit
procedures to obtain appropriate audit evidence. When such additional evidence is not obtained
through additional test procedures, he needs to mention the same and thereafter provide an audit
opinion. When there are constraints that could impair the work to be performed, auditor is
mandatorily expected to consider, using the work of other experts. The expert could be internal to the
organization or external. The auditor should have access to all work papers, supporting
documentation and reports of other experts, provided there are no legal issues.
IS auditing standard number 6 states that he should obtain sufficient, reliable and relevant evidence
which would be useful to achieve the audit objectives.
Guideline 4: Outsourcing of IS activities to other organizations
This Guideline categorically states that when any aspect of the IS functions has been outsourced to a
service provider, the scope of audit charter should include these services also. The audit charter
should include review of the service level agreement with the service provider, the performance of
systems audit work of the outsourced function and report the findings to the service user.
The auditor should obtain the following information:
The nature and extent of the outsourced services.

Ascertain the controls that the service provider has put in place to address the business
requirements of the user.
Identify the likely risks associated with the outsourcing activity.
Assess the controls in place at the service user’s end to provide reasonable assurance that
business objectives would be achieved.
Review the outsourcing agreement to ascertain whether the systems auditability clause is
comprehensive.
The service level agreement should be reviewed for the following:
• Whether legal opinion has been obtained
• Whether specific provision is made for performing systems audit
• Access rights
• Adherence to security policy
• Adherence to personnel policy
When the conditions agreed to in the service level agreement are not being met, the auditor
should verify whether the service user has taken adequate corrective actions.
If the service provider is not cooperating with the IS auditor, the IS auditor should report the
matter to the service user’s management.
Should there be any restriction on the scope, where access rights are denied, auditor is
expected to explain the effect of such restrictions.
Guideline 9: Audit considerations for irregularities

The Guideline states that IS auditor should be reasonably conversant with the subject of fraud to be
able to identify risk factors that may contribute to the occurrence of fraud. The Information System
auditor should assess the risk of occurrence of irregularities in the area under audit.
The Guideline lays down the various factors which should be considered, the more important of
them are as follows:
Changes in operations or information systems

Strength of relevant controls
Applicable regulatory requirements
Findings outside the scope of audit such as findings from consultants.
Technical complexity of information systems.
The Guideline proceeds to state that if irregularities have been detected, the IS auditor should
assess the effect of these activities on the audit objectives and reliability of audit evidence collected.
The Guideline more importantly states, that the auditor should consider whether to continue the
audit or not when the effect of the irregularities appears to be so significant that sufficient reliable
audit evidence cannot be obtained.
If the audit indicates that irregularities could occur, the IS auditor should recommend to the
management that the matter be investigated further.
Reporting
The detection of irregularities should be reported to the appropriate authorities within the
organization, as occurrence and effect of irregularities is a sensitive issue, reporting itself carries its
own risk as following:
Further abuse of control weakness as a result of publicizing the details of the irregularities.
Loss of image to the organization.
It is recommended that the irregularity be separately reported from other audit issues. If audit scope
has been restricted, the auditor should include an explanation of the nature of the effect of this
restriction in the report.
Guideline 13: Use of risk assessment in audit planning
The Guideline 13 states that any appropriate risk methodology could be used.
IS auditor should consider the following aspects:
Inherent risk
Control risk
Detection risk
Internal risk is the susceptibility of an audit area to error, unless there is an appropriate internal
control.
Inherent risk with operating systems is high, unless security settings are set properly and patches
are updated regularly.
The guideline goes on to state that the auditor while assessing the inherent risk should consider both
pervasive and detailed controls. When services are outsourced and there is direct access by
customers, auditor should review pervasive control to the appropriate level.
At the detailed control level, the Information System auditor should consider to the level
appropriate for the audit area. Special attention needs to be paid to the complexity of the systems
involved, susceptibility to loss or misappropriation of the assets controlled by the system.
Comments: In a core banking solution, technology is complex.
In Internet banking, fund transfer is effected, which is a highly sensitive function.
Control risk: The control risk is the risk that an error which could occur in an audit area which
will not be prevented or detected on a timely basis by the internal control system.
Comments: Manual controls in a complicated technology environment are inappropriate and
ineffective. Appropriate built-in controls in the computer system is needed at all the stages of input
and output process.
The audit logs need to be enabled and the logs need to be reviewed. If neither the logs are enabled
nor are they reviewed, there is a control risk.
Detection risk tuat
Detection risk is the risk that an auditor’s substantive procedures will not detect an error.
The guideline states that the documentation of the auditor should describe the risk assessment
methodology and identification of significant exposures and the corresponding risks.
The document should also include the audit evidence, used to support the auditor’s assessment of
risk.
IS auditing procedure number 1 deals with ‘IS Risk Assessment Measurement Procedure’. It
defines risk ‘as the possibility of an act or event occurring that would have an adverse effect on the
organization and its information systems. Risk-based audit approach is the expectation in the current
scenario.
In a risk-based audit approach, audit or assesses the risk and based on the information, decides
whether the compliance testing or substantive testing would be performed or not. Auditors are relying
on internal and operational controls as well as the knowledge of the organization. The procedure
clearly enunciates that IS auditor is interested in uncontrolled risks and in critical controls. Thus, in a
risk-based audit approach, IS auditor will be interested on technology-based systems which provide
controls for business functions where there is high inherent risk and in technology-based functions
where there is higher than acceptable residual risk.
The procedure deals with IS risk assessment methods and provides sufficient reading material and
examples to understand and perform risk assessment for an audit.
Guideline 14: Application systems review
This Guideline describes the recommended practices in performing an application systems review.
The IS auditor should gain an understanding of the organization’s business objectives as also the
level and manner in which information technology and information systems are used to support the
organization. The auditor should have an understanding of the organizational structure including the
roles and responsibilities of key Information System staff and the business process of the application
systems.
The Guideline further provides application level risks at the system and data level including the
following:
Systems security risks relating to unauthorized access

System integrity risk relating to incomplete, inaccurate or unauthorized processing of data
Security system maintainability risk
Data risks relating to its completeness, integrity, confidentiality, privacy and accuracy.
Application controls may consist of purely built-in controls of the system or a combination of built-
in controls and controls outside the system.
The objectives and scope of the application systems review would cover the following criteria:
Effectiveness
Efficiency
Confidentiality
Integrity
Availability
Compliance
Reliability of information
The Guideline while discussing the details of performance of audit, expects that an auditor should
prepare a high level audit flow diagram or utilize the system documentation, if provided. Application
interfaces with other systems should also be documented.
An auditor is expected to obtain an assurance that the controls are operating as intended. This could
be accomplished through inquiry and observation, review of documentation, testing of application
system controls etc. Effectiveness of computer’s controls is dependent on strong general IT controls.
If general IT controls are not reviewed, ability to place reliance on the application controls may be
severely limited and auditor should consider alternative procedure.
If weaknesses are identified, during the application systems review and they are considered to be
significant or material, appropriate level of management should be advised to undertake immediate
corrective action. The Information System auditor should include in his report appropriate
recommendations to strengthen controls.
Guideline 24: Internet banking
The term Internet banking is defined as the use of the Internet as a remote delivery channel for banking
services including opening of accounts, transferring of funds and electronic on-line payment.
Internet banking activities do not raise risks that were not already identified in traditional banking,
but increase and modify some of the traditional risks.
The core banking and information technology environment are tightly coupled thereby influencing
the overall business profile of Internet banking.
The Guideline states that risk management is the responsibility of the Board of Directors and senior
management. Implementing technology is the responsibility of information technology senior
management. They are expected to have the skill to effectively evaluate banking technology and
products. The bank should consider contracting with a third party, if capabilities are not available
within the organization. The Board of Directors should receive regular reports on the technologies,
implied risks assumed, and how those risks are managed. The review of internal control in the
Internet banking environment must help the IS auditor to provide a reasonable assurance that the
controls are appropriate and functioning appropriately.
Control objective for a bank’s internet would include the following:
Data and service availability.

Data integrity including providing for safeguarding of assets, proper authorization of
transactions and reliability of the data flow.
Data confidentiality and privacy standards including controls over access by both employees
and customers.
In the case of Internet banking involving payments or fund transfers, non-repudiation and integrity of
the transactions are essential. It is essential in Internet banking to confirm that any communication,
transaction or access requests is legitimate. Accordingly, banks should use reliable methods.
Auditability has more significance in the Internet banking environment because a significant
proportion of the transactions takes place in paperless environment.
Following are some of the competence that are expected from an Information System auditor:
Skills and knowledge: The Information System auditor should have the necessary technical and
operational skill and knowledge to carry out the review of the technology employed and risks
associated with Internet banking.
The technical knowledge necessarily would include competence to evaluate aspects such as web
hosting technology, encryption technologies, network security architecture, and security technologies
such as firewalls, intrusion detection systems and virus protection. Where expert advice or expert
input is necessary, appropriate use should be made of external professional resources and the
management be informed of the need to do so.
Planning: The Information System auditor should gather information regarding Internet banking
objectives of the bank, such that it helps in carrying out a high level assessment of the banking risks as
well as the risks pertaining to information criteria.
The IS auditor should follow a risk assessment approach for evaluating the main potential, general
and specific threats connected with the implementation of Internet banking, possible manifestations,
the potential effect on the bank, the likelihood of occurrence and the possible risks management
measures. The following risks should be evaluated:
Strategic risks
Security risks
Legal risks
Reputational risks
The IS auditor, in consultation with the bank’s management should, clearly define the scope and
objective of the review of Internet banking. The auditor should formulate the approach in such a way
that the scope and objectives of the review would be fulfilled in an objective and professional
manner. The approach would depend on whether the review is pre-implementation review or post-
implementation review.
Performance of Internet banking review: In general while analyzing and interpreting an Internet
banking environment, a study should be made of available documents including:
Bank regulations about Internet banking

Internet law
Privacy law
Web banking system documentation
Use of Internet banking solution
To review problems in Internet banking which have been noted previously and which may require
follow-up, the IS auditor should review the following:
Earlier reports
Follow-up activities
Work papers
Internal and external audit reports
As part of IS risk assessment, external IS threats should be evaluated depending on the nature of
product offered by the banks. These threats include the following:
Denial of service
Unauthorized access to data
Unauthorized use of the computer equipment.
Depending on the nature of the pre- or post-implementation review, the IS auditor should satisfy
himself that the processes are functioning as intended. These tests include the following:
Testing of balance enquiry
Testing of bill presentation and payment
Testing of security mechanism using penetration testing
An IS auditor should obtain understanding of the following technicalities:
Network mapping
Network routing
Network security assessment
Internal and external intrusions
To identify any problems relating to the Internet banking, the IS auditor’s review should include the
following aspects:
Organizational aspect: The organizational aspects to be reviewed would include the following:
Due diligence and risk analysis have been performed BEFORE the Bank provides internet
banking facilities.
Due diligence and risk analysis have been performed where cross-border activities are
conducted.
Internet banking is consistent with the bank’s overall mission.
Internet banking system and services are managed inhouse or outsourced with third party.
Personnel of the organization display acceptable knowledge and technical skills to manage
Internet banking.
Segregation of duties are in place.
Management reports are adequate to manage Internet banking transactions and payment
services activities.
Policy aspect:
(a) Review whether suitable policies are in place regarding:
• Acquisition of customers
• Engagement of suppliers
• Customers authentication
• Privacy of customers data
• Audit trail
• Review of usage logs
• Updated knowledge on legal developments associated with
Internet banking
(b) Bank is providing accurate privacy and disclosure associated with Internet banking product.
(c) Information is provided on the website to allow customers to make enough judgment about the
identity and regulatory status.
(d) There are appropriate procedures in place regarding:
• Change control
• Review of audit trail
• Review of usage logs
Planning aspect: Planning aspect should review whether:
(a) The planned technology architecture is feasible and will result in safe and sound operations.
(b) There are appropriate incident response plans in place.
(c) There is an internet product life cycle and is strictly followed for developing, maintenance and
upgrading of internet applications.
(d) Business continuity plans (BCP) for critical processes are in place and regularly tested.
System infrastructure aspect: The review should include the following:
The bank has an adequate process and control to address

• physical security
• hardware
• software
• data communication equipment associated with Internet banking systems.
Whether the internal network is suitably protected from external environment using
appropriate firewall.
Unauthorized access is denied to databases and dataflow.
The record of each customer transaction contains:
• Identification of customer
• Transaction number
• The type of transaction
• Transaction amount
Telecommunication infrastructure aspect: This aspect includes review for whether:
Network architecture is appropriate for the Internet banking operations.

Intrusion Detection System (IDS) and virus control systems are in place.
There is an adequate penetration testing of internal and external network.
Communication across the network is made secure.
Adequate and strong encryption algorithms are selected to protect data during communication
across the network.
Authentication aspect: Authentication aspect should be reviewed for whether:

(a) The control features are in place to validate identity of prospective customers
(b) The control features are built-in to the system to ensure
• authentication of existing customers
• Integrity of data and
• Confidentiality of transaction
(c) The authentication procedures are in place wherever necessary using digital certificate and
digital signatures.
(d) Non-repudiation is ensured.
Third party service provider aspect: This aspect should be reviewed for whether:
(a) Due diligence review was conducted prior to entering into the contract.
(b) The contract protects the interests of the bank and the bank’s
customers.
(c) The bank obtains and reviews audit reports of third party service providers.
(d) Bank’s organization has right to perform system audit of the services of third party service
provider.
(e) The third party service providers have appropriate Business Continuity Plan (BCP).
(f) The software maintained by a vendor is under a software escrow agreement.
(g) The third party opinion is sought in the pre-implementation stage for evaluating the security
architecture of the proposed solution.
In consultation and in agreement with the bank, external expert advice may be used suitably. Before
finalizing the report, observations and recommendations should be validated with appropriate
personnel.
Reporting: The report on Internet banking review should address the following:
Scope and methodology

The overall assessment of strengths and weaknesses and the impact of the weakness
Recommendations to overcome significant weaknesses
A statement of extent of compliance with bank’s regulations.
Guideline 28: Computer forensics

Computer forensics is the process of extracting information and data from computer storage media,
using the tools and technology validated by a court of law and proven forensics best practices to
establish the accuracy and reliability for the purpose of reporting on the same as evidence. The
challenge to computer forensics is as follows:
Finding the data

Collecting the data
Preserving the data
Presenting the data in a readable manner, in a form acceptable in a court of law
Computer forensics has been applied in a number of cases including, but not limited to:
Fraud
Computer misuse
Technology abuse
Malicious mail
Information leakage
Hacking
Illegal transfer of funds
Computer forensics involves a detailed analysis of events in cyberspace and collection of

evidence. The key elements of computer forensics for audit planning are:
Data protection
Data acquisition
Imaging
Extraction
Interrogation
Ingestion/normalisation
Reporting
The challenge to computer forensics is finding the data, collecting it, preserving it and presenting in
a manner acceptable to a court of law.
Guideline 30: Competence
An IS auditor needs to acquire the necessary skill and required knowledge to carry out assignments.
The additional challenge is to maintain competence by continuously upgrading knowledge and skill.
The IS auditor has the following responsibilities;
1. Skills and knowledge: The IS auditor is responsible for acquiring the required professional
and technical skills and knowledge to carry out any assignment that he agrees to perform.
2. Audit management is responsible for ensuring that the audit assignment is entrusted to an
individual or a firm, only after ascertaining that the concerned person has the required
professional and technical skills and knowledge to perform the task.
3. Competence: Competence implies possessing skills and knowledge and expertise through an
adequate level of education and experience. The IS auditor should provide reasonable
assurance that he/she possesses the skills and knowledge necessary to attain the required level
of competence.
4. Continual maintenance: The IS auditors should continually monitor their skills and
knowledge to maintain an acceptable level of competence.
5. Evaluation: An appropriate level of management is required to evaluate the performance of
an internal IS auditor and wherever appropriate and necessary, the performance of an external
IS auditor.
6. Gaps noticed during evaluation should be addressed appropriately.
7. Availability of competent resources: IS Auditor-Audit management should provide
reasonable assurance that requisite resources with the necessary skill, knowledge and
required level of competency are available before commencing an audit assignment.
The Information System (IS) auditors should not portray themselves as having expertise,
competence or experience they do not possess.
Outsourcing: When any part of the audit assignment is outsourced, reasonable assurance must
be provided that the outsourced agency possesses the requisite competence.
Guideline 32: Business Continuity Plan (BCP)—review from
IT perspective
This Guideline deals with Business Continuity Planning (BCP). It recognizes that organizations are
more vulnerable than ever to possibility of technical difficulties, disrupting business. Any disaster
from floods, fire, viruses and cyber terrorism can affect the availability, integrity and confidentiality
of information that is critical to business.
The purpose of this Guideline is to describe the recommended practices in performing a business
continuity plan review from an IT perspective. The purpose also is to identify, document, testing and
evaluating the controls and the associated risks relating to the process of BCP from an IT perspective
as implemented in an organization. This Guideline highlights the application of IS Standard S-6.
Performance of audit work to obtain sufficient, reliable, relevant and useful audit evidence during the
review of BCP from an IT perspective.
The Guideline gives an explanation for the various acronyms used. e.g. Business Continuity Plan
(BCP), Business Impact Analysis (BIA), Disaster Recovery Planning (DRP) etc.
The Guideline while providing an overview of BCP from an IT perspective, mentions the
components of BCP as follows:
Identification—Identify potential threats and risks of the business.

Prevention—Prevent or minimize the probability of the incident.
Detection—Identify the circumstances under which the organization determines entering
contingency status.
Declaration—Specify the conditions on which contingency is declared and identify the person
who can declare it.
Escalation—Specify the condition on which contingency is escalated and identify the person
or the order of escalation in the event of contingency.
Containment—Specify immediate action required to contain or minimize the effect of the
incident on the customers, service providers etc.
Implementation—Specify the complete list of actions to be followed to declare contingency
status. See the following examples:
• Offsite processing
• Back up recovery
• Offsite media and manuals
• Employee transportation.
Recovery—Recovery is advanced planning to minimize adverse business impact. The
components would be;
• Resumption
• Revival
• Restoration
• Relocation, and
• Crisis management
The guideline describes elements of BCP as
1. Risk Assessment; and

2. Business Impact Analysis (BIA)
It lays down the key factors of BCP. Most importantly, this Guideline under the heading
‘Competence’ and sub heading ‘Skills and Knowledge’ lays down that IS auditor should provide
reasonable assurance that he has the required knowledge and skill to carry out the review of the BCP
and its components.
The Guideline further discusses the impact of outsourcing of IS activities by the organization. It
emphasizes the fact that in such circumstances, the auditor should review whether the service
providers’ BCP process conforms to the organization’s BCP.
The Guideline concludes by providing the contents of the final report that an IS auditor should
produce on the processes, facilities and technologies involved in the BCP, the risks assumed and how
those risks are managed in case of contingency. It highlights the fact that monitoring the performance
of the review of BPC is the key success factor. The report produced as a result of the BCP review
should importantly highlight the fact that there is reasonable assurance on the BCP process and
relevant internal controls to ensure that IT systems can be recovered within an acceptable timeframe
in the event of disruption.
Guideline 33: General considerations on the use of Internet
This Guideline needs to be read along with Guideline No. 22 dealing with B2C E-Commerce review
as also Guideline No. 24 dealing with Internet banking. It also suggests that this Guideline needs to be
linked to the following procedures:
P2 Digital signatures and key management

P3 IDS review
P6 Firewalls
P8 Security assessment, penetration testing and vulnerability analysis
P9 Evaluation of management controls over encryption methodology
The enterprise is exposed to many threats by connecting to the Internet. To deal with those threats,
it is important to run a risk analysis and take the necessary security precautions. As Internet is not
static, threats also change, and consequently there would be changes for the security measures to be
taken. This Guideline explains various threats like;
Technical failure
User errors
Misuse of systems or disloyal employees spreading confidential information.
It considers various attacks which include:

Passive attack
Active attack
Service attack
It considers also the various services available on the Internet like Email, www, ftp, Telnet etc. It
considers the various security measures under the following heads:
Policy and products

Firewalls
One time password
Penetration test and test software
Intrusion detection and prevention systems
Encryption
Digital signatures
Virtual Private Network (VPN)
Antivirus program
Anti-spyware program
Logging and monitoring
This Guideline most importantly highlights major factors to be considered while performing
audit/security review.
The Guideline provides the various factors to be considered while performing a detailed review.
Assessing administrative aspects

Reviewing the risk assessment procedure
Reviewing the guidelines for the use of the Internet
Reviewing the documentation of internet operations
Reviewing the documents of Internet connections
It recommends that documentation routine for monitoring should contain, as a minimum, description
of responsibility for administration and maintenance of Internet connection including back up
resources. The procedures to review includes the following:
Review of log files from the firewall

Review of transactions from current server
Review of log files from user activities
Review of network statistics
Following up of potential security incidents.
The responsibility would include:

Users responsibilities
Responsibilities of IT management
Responsibilities of security management
Responsibility of senior management
This Guideline also discusses the technical issues and security measures.
Procedure 3: Intrusion Detection
This Procedure defines IDS. Intrusion Detection is the process of detecting unauthorized use of
systems and network through the use of specialized software and/or hardware. The procedure
describes a number of types of Intrusion Detection Systems (IDs), e.g. user-based. network-based. It
discusses the procedures to review IDS implementation.
Procedure 6: Firewalls
The Procedure deals with evaluation of security concerns in firewalls. It is primarily intended for IS
auditors—internal as well as external. The Procedure further goes on to mention that documents can
be used by other IS security professionals with responsibilities in firewall configuration. The
Procedure deals with types of firewalls. It contains details of common functions and features related
to firewalls. It includes also a description of Intrusion Detection Systems (IDS). The Procedure also
has got details of all common firewall configurations. The procedure highlights the risks controlled
by firewalls. It contains procedures to review firewalls under the following heads:
Gathering preliminary information

Risk assessment
Detailed planning
Stateful inspection
Packet filtering
Inherent risks of packet filtering
Hybrid firewalls
Proxy firewalls
Demilitarized zone (DMZ)
The additional points considered are mentioned below:
Configuration
Monitoring of data and incident response
Backup and recovery
APPENDIX
Relevant RBI Circulars and

Notifications
List of RBI Circulars/Notifications Related to IS Audit/BCP/Internet Banking
S.No. Title Reference number
Information systems audit policy for the banking and financial sector and its Annexure- Department of Information
1.
Information Systems Security Guidelines for the banking and financial sector Technology, October 2001
DBOD.COMP.BC.No.130/07.03.23/
2. Internet Banking in India—Guidelines
2000-01 Dt. June 14, 2001
RBI/2005-06/71
3. Internet Banking in India—Guidelines DBOD No.
Comp.BC.14/07.03.29/2005-06
Standardized checklists for conducting computer audit—Report of the Committee on Computer
4. April 2, 2002
Audit
RBI/2004/191
5. Information System Audit—A Review of Policies and Practices DBS.CO.OSMOS.BC/11
/33.01.029/2003-04/April 30, 2004
Ref.RBI/2004-05/420
6. Operational Risk Management—Business Continuity Planning DBS.CO.IS Audit.No.
19/31.02.03/2004-05
RBI/2006-07/112
7. Internet Banking—Internet based platforms for dealing in foreign exchange DBOD No. Comp. BC. 1658
/07.23.29/2006-07
RBI/2006-2007/335
8. Compliance function in banks Ref. DBS. CO.PP.BC
6/11.01.005/2006-07
RBI/2006-2007/385
9. Guidelines on corporate governance
DNBS.PD/CC 94/03.10.042/2006-07
Details of circulars can be obtained from www.rbi.org

GLOSSARY OF TERMS
Acceptance testing: Acceptance testing is done before implementation of the product to ensure that
the application satisfies the business requirements.
Access control: Access control ensures that each object is accessed on a need to know/do basis by
the users.
Access Control List (ACL): Access Control List (ACL) defines the rules as to who or what is
allowed to access the object and the operations that are allowed to be performed.
Access rights: Access rights are an associated set of resources and rights that are accessible by a
user.
Account lockout: A user account is locked after a certain number of failed login attempts (usually
3) to prevent an unauthorized person logging in to the system by guessing the password.
Accounting audit trail: Audit trail is a chronological sequence of records, each of which is an
evidence for the execution of a particular process in the system. It is highly confidential and control
should be there in place to ensure that these logs cannot be modified or deleted.
ACL: ACL is an audit tool that provides various options for data extraction, analysis and reporting
that is mainly used to test data integrity and completeness of transactions in the database.
Active content: Active contents are dynamic contents on a website that uses binary codes and
execute on the user’s browser.
Active directory: Active directory provides centralized authentication and authorization services.
The directory stores information about the users and resources accessible by them. Thus, it facilitates
administrators to monitor users, assign policies, deploy software and apply critical updates from a
central server.
ALPM: Advanced Ledger Posting Machines (ALPM) is a single-user application that operates in a
stand-alone environment and is used mainly for batch processing.
AMC: Annual Maintenance Contract (AMC) is executed with various vendors for maintenance of
applications and systems.
Antivirus: Antivirus is a computer program that attempts to identify and/or eliminate computer
viruses and other malicious programs by scanning and monitoring all computer files.
API: Application Program Interface (API) is a set protocols and tools for developing and
execution of software applications.
Application server: Application server is where the application centrally resides and is accessed
by the connected client systems. Majority of the operations are processed at the application server
thus taking the load off from the client systems.
Application system: Application system is a set of interrelated components, designed for
performing a particular process or a group of business processes. An application has specific input
requirements, processing functions and output generation functions. There are many modules in an
application that are coupled together.
Archiving: Archiving is the process of copying data to a long-term storage medium for it may be
required to be stored for a mandatory time period as a legal requirement or as a business requirement.
Automated Teller Machines (ATM): An Automated Teller Machine (ATM) is a computer that
provides teller operations to the customers by identifying them with their ATM card and PIN
(Personal Identification Number). These ATMs are situated at various locations and can be accessed
by the customers at any time of the day.
Automated Teller Machine (ATM) - Network: ATMs installed by a bank at various locations
are connected to a central ATM switch through dedicated/ISDN lines which is in turn connected to
other bank’s ATM switch and its own ATM server (at the data center). This forms the ATM network
for a bank. [Refer ATM network diagram, Page 86, Chapter 8]
Authentication: Authentication occurs when an individual makes a claim of identity and the same
is verified for correctness.
Authorization: Authorization is the process of verifying whether a person or a program is allowed
to access a particular data or function.
Authorization controls: Authorization control ensures proper authentication of an object and
verifying the granted permissions before allowing access to data or function.
Backup: Backup is the process of copying data to an external storage medium which could be used
for restoration purposes if there is any loss of data. Backups are different from archives as the latter
is the primary copy of data and the former is the secondary copy of data.
Business Continuity Plan (BCP): Business Continuity Plan (BCP) is a strategy to continue the
business during and after a business disruption. It reflects an organization’s ability to maintain
continuity of critical operations even after a business disruption.
BCP process: In a BCP process, different scenarios that affect the critical business processes are
identified. Then a detailed process is drawn to carry out critical operations during different business
interruption scenarios.
Business Impact Analysis (BIA): Business Impact Analysis is the first step in developing a BCP.
In this phase different events that have an impact on the continuity of business, reputation, customer
satisfaction and financial position are identified. All the impact parameters are quantified and thus the
critical activities are identified.
BoD (Beginning of Day): BoD (Beginning of Day) is a set of activities programmed in the
application that is performed when the application is executed at the beginning of everyday. The BoD
activities differ from one application to another but it mainly does the following:
Date change
Posting of balances after EoD operations (End of Day explained later in this document) are
run
Generation of reports.
Boundary control: Each object in an application should accept values only within a particular
range. This is enforced by boundary controls by fixing an outer limit for the values that an object can
accept.
Bridge: A bridge is network device that acts at Layer 2 of the OSI model. It facilitates the
following:
Eliminates collision in the network

Facilitates segmentation of network
Acts as a repeater by boosting the data signals
Maintains MAC addresses of connected computers
Bridges have fewer ports compared to switches and can connect only few systems. Also bridges
are not as efficient as switches in managing MAC address table and in forwarding data. Hence,
switches are slowly replacing bridges.
Browser: Browser is a software that enables a user to display and interact with the data stored of a
website on the World Wide Web or Local Area Network.
CISA: The Certified Information Systems Auditor (CISA) is a certification offered by Information
Systems Audit and Control Association (ISACA), USA for recognising professionals conducting
Information systems audits, control and security. For more information about CISA, visit
www.isaca.org
Client-server: The client-server architecture is an architecture where there is a server with very
high processing capabilities and clients (computers connected to the server) that has basic processing
capabilities. Thus most of the processing is done centrally at the server which is read by the clients
connected to the server. This takes off the processing load from the clients. It also facilitates effective
resource sharing with all the clients accessing a common resource at the server.
Confidentiality: Confidentiality means the protection of sensitive information from unauthorized
disclosure.
Contingency plan: Contingency plans are made for specific situations to cope with any mishaps.
This is a part of BCP.
Conversion audit: Conversion audits are done before data is migrated from one application to
another application. During this process:
The controls that were available in the old application but not available in the new one are
identified and analyzed.
The new control requirements and controls are identified and analyzed.
Core banking: Core banking describes the banking services provided by a group of networked
bank branches. Customers can access their accounts and perform certain transactions from any of the
branches.
Core banking solution: The core banking solution is a combination of application software and
networking devices. All the bank branches are connected to the bank’s data center. The main
application resides in an application server at the data center and a client version is installed in all
the systems connected to the core banking network. Thus, it facilitates anywhere banking and anytime
banking.
Corrective control: A corrective control identifies a problem and minimizes impact from the
same. To be more effective, the corrective control has to coexist with preventive and detective
controls.
Data center: A data center is a large data-housing infrastructure that provides secure, high
bandwidth access to the clients, for a range of network related services. Essentially, it comprises of
servers, firewalls, high bandwidth network links and stringent physical and logical access security
facilities.
Data conversion: Data conversion is the process of converting data from one form to another.
Whenever there is a change in the application or operating platform, the data has to be converted to
be compatible with the new requirements.
Data storage: Data storage is all about securely storing all data generated by processing the
application. The data should be accessible only on a need to know basis. For the data that is very
critical that there must be some facility to take data backups at regular intervals.
Data Entry Screen: Data entry screen is the interface presented to the user by the application to
input data. The application after processing the data, stores it in the database.
Database administration: Database administration is about maintaining the database to provide
for recoverability, integrity, security, availability and efficient performance.
De-militarized zone (DMZ): De-militarized zone (DMZ) is a border network that connects both to
the internal network (intranet) and to the external network (internet). This is a security zone for the
internal network as a firewall is configured here to block unauthorized and malicious traffic.
Default gateway: Default gateway is a device (router or layer 3 switch) in the network that acts as
an access point to another network. Thus, it is placed at the border of between two networks.
Denial of Service (DOS): Denial of Service is a state during which the computer resource is
unavailable to the legitimate users. This usually happens when the system memory is flooded with
service request (mostly malicious in nature) such that the illegitimate service requests are addressed
slowly or dropped.
Detective control: Detective controls are those which detect and report the occurrences of an
error, omission or malicious activity.
Disaster Recovery Planning (DRP): Disaster Recovery Planning (DRP) is done by an
organization to resume critical business processes following a disaster by gaining access to the
required data, hardware and software. DRP is a part of a larger process called Business Continuity
Planning (BCP).
Distributed Denial of Service (DDoS): The Distributed Denial of Service (DDoS) is a network
attack in which many compromised computers flood the server with service requests thereby
rendering the server to be inaccessible to the legitimate users.
Dumb terminal: A dumb terminal is a computer with limited functionality. In a client-server
architecture, the client computers have limited processing ability and acts as a dumb terminal.
Electronic Fund Transfer (EFT): Electronic Fund Transfer (EFT) is the process of money
transfer from one account to another electronically. This computerized transaction is very fast and
happens on a real-time basis.
Enable password: ‘Enable password’ is with regard to router security. The default password
should be set to something else and the same should be encrypted and stored so that it cannot be
compromised.
EoD (End of Day): EoD (End of Day) is a set of activities programmed in the application that is
performed before closing the application for the day. The EoD activities differ from one application
to another but it mainly do the following operations:
Interest application
Posting of charges
Posting of entries in various accounts
Escrow mechanism for software source code: Escrow is a legal arrangement in which the
software source code is delivered to a third party who have agreed to act as an escrow agent who
shall release the same to the aggrieved party if the terms of contract (like failure to maintain
application, transfer of ownership and liquidation of the developer’s company) are not complied
with.
Exception reporting: Exception report is a report generated by the application tracking all
exception items during processing like the following:
Overrides given during processing

Waivers given
Exceptional interest rates
Encryption: Encryption is the process of rendering a data unreadable by the application of an

encryption key. The process of transforming an encrypted data readable is called decryption.
Decryption process is not possible without the encryption key.
Thus, encryption is important to maintain confidentiality over critical data. It is important that the
encryption key chosen for encryption is fairly large so that the key is not compromised. (Higher the
number of bits in the key stronger the encription.)
File systems: File system is a method of storing computer files so that it is easy to access them. It
is an integral part of the operating system with direct user interaction.
File Transfer Protocol (FTP): The File Transfer Protocol (FTP) is a protocol used to transfer the
data between computers that are networked. FTP is inherently insecure as there is no security over the
data that is being transferred.
Firewall: Firewall is a mechanism to protect an internal network from unauthorized and malicious
data originating from an external network. Both hardware-based and software-based firewall are
available. Firewalls permit or deny access to the data that pass through it after verifying the rules and
policies configured in it. It is thus, important that the firewall rules are in line with the organization’s
security policy.
Firewall
Fully operational test: Fully operational test in the context of BCP is done after a paper test and
preparedness test. The full plan is tested by adopting a simulation scenario for the purpose of testing.
Hackers: A hacker is an unauthorized person who tries breaking into an information system to gain
access to confidential data and/or to cause denial of service to legitimate users.
Hardening: Hardening is the process of securing a system from unauthorized access. Hardening
procedures include configuring the system with appropriate logical access controls, disabling of
unnecessary services, applying appropriate patches released by the vendor, closing unused ports and
setting up a firewall.
Hardware Security Module (HSM): Hardware Security Model (HSM) is proprietary software
that comes with hardware. It is used to secure data by encrypting the same. The HSM consists of an
encryption algorithm and encryption key. These are stored in the hardware in an encrypted form thus
providing security over the algorithm and the key stored in the hardware. Also being a hardware
based model, it provides better performance over a software based encryption system. Any attempt to
compromise the HSM would render the hardware unusable.
Host-based IDS (HIDS): A Host-based Intrusion Detection System (HIDS) monitors the dynamic
behaviour of the system by checking the resources accessed by each program and prompts if there is
any anomaly. Also the HIDS scans the stored information in RAM or in the file system for
appropriateness.
Inherent risk: Inherent risks are the risks that come along with the system or product or practice.
These risks should be promptly identified and appropriate controls should be installed to prevent
exploitation of the same.
Internet banking: The term Internet banking refers to the banking transactions that are routed
through the Internet. This allows registered customers to do banking at any time of the day.
Internet banking system: Internet banking system facilitates banking through the medium of
internet with specialized software and hardware. The application authenticates the customer during
login and processes the service request. Since internet is a public network, appropriate security
features are built-in to maintain the confidentiality and integrity of the data that is being transferred
during the process.
Internet Service Provider (ISP): The Internet Service Provider (ISP) is an organization that
provides internet access to the customers. Various technologies like Dial up, DSL, Broadband,
wireless, Cable modem and ISDN are being provided by most of the ISPs.
Intrusion Detection System (IDS): An Intrusion Detection System (IDS) is a monitoring system
that has the capability of detecting malicious network traffic that cannot be detected by a conventional
firewall. This system contains the following:
Sensors — Senses critical security related events

Console — Facilitates event monitoring
Engine — Logs the events detected by sensors; stores a system of rules to generate security
event alerts
The IDSs are of two types—Host-based Intrusion Detection System (HIDS) and Network-based
Intrusion Detection System (NIDS).
IP address: The IP address is a unique address that is assigned to all computers in a network. The
IP address along with MAC address is used to send and receive data between computers in a
network. These addresses are represented in ‘dotted decimal format’.
IP Address — version 4 contains 32 bits. Example: “192.168.138.10”
IP Address — version 6 contains 128 bits is slowly being introduced as the number of computers
that are being networked are increasing significantly. Example:
“2001:0db8:85a3:08d3:1319:8a2e:0370:7334”
IP spoofing: IP spoofing is the creation of IP data packets with forged source address. The senders
IP address is concealed to impersonate that of another computer.
Local Area Network (LAN): Local Area Network (LAN) is a computer network covering a small
geographic area. Example: Network in an office connecting few computers.
Librarian: Librarian is the person in whose custody all the software executables and source code,
license and user manuals are available. Any new software that has to be deployed should first go to
the librarian.
Limit check: It is a validation to ensure that the data does not exceed a particular limit.
Logon ID: Logon IDs are similar to the user IDs.
Logs: Logs are record of events that has happened in the system. It contains the date, time, user ID
and event summary for all activities in the system. Thus, it serves as an important evidence to prove
the activities in the system. Control should be there to ensure that logs are accessible only on a need
to know basis and it should not be possible to modify or delete logs.
Maker-Checker concept: Under the Maker-Checker concept, there will be one person to enter
data in the system through his user account and there will be another person who logs in with his user
name and password to verify and authorize the data entered. Thus, no transactions will be processed
by a single person.
Middleware: Middleware is a system that converts data to a usable format when the same data has
to be used by different applications.
Monthly backup: Monthly backup is the backup taken at the end of a month. Usually, on a day-to-
day basis incremental backups are taken and at the end of the month, a complete backup is taken.
Multiplexing: Multiplexing is done when multiple data signals (analog or digital) are combined.
Thus, even if data signals are received from different channels, they are combined for processing.
Network cabling: Network cables are those that physically connect computers and other
peripherals in a network. There are different types of cable like fiber optic cable, twisted pair cable
and ethernet cable.
Network Interface Card (NIC): A Network Interface Card (NIC) enables computers to
communicate across a network using cables or even without using wires. Each NIC will have a
unique ID, called the hardware ID or Media Access Control (MAC) address that is used along with
IP address to send and receive data between computers in a network.
Network Interface Card with MAC Address

Network based IDS (NIDS): A Network-based Intrusion Detection System (NIDS) reads all
incoming and outgoing data packets to find suspicious pattern. This system works with other security
devices like firewall.
Node: The node is a device that is connected to a computer network. Example: routers, switch,
hubs.
Operating System (OS): An Operating System is the most important program that runs on every
computer. It performs certain basic tasks like input recognition, sending output, keeping track of files
and directories, memory management, controlling devices connected to the computer (peripherals)
and executing and managing various applications (multi-tasking, multi-processing and multi-
threading).
Parking account: Parking account denotes an account where transactions are temporarily posted
before posting it to the appropriate accounts. It is either because there is a discrepancy in the accounts
that has to be sorted out or because transactions posted to parking accounts are cleared in batches at
regular intervals instead of clearing it as and when it happens.
Password attacks: Password attack is one in which an attacker tries to break into an account by
compromising the password. Password guessing is the most common technique in this regard.
Another popular method is called the ‘Brute-force’ attack where a large number of possibilities are
tired continuously to crack the password.
Patch management: Patches are issued by vendors to fix bugs in the system. The system
administrator should keep track of all patches released by the vendor. The patches should be tested in
a test environment before installing in the live environment to ensure that it does not affect the
functionality of the system.
Penetration testing: Penetration testing is done to evaluate the security of a computer system or
network. In this process, the tester will use all the tools and techniques that a hacker would use to
identify the vulnerabilities in the system.
Ping: Packet Internet Grouper (PING) is used to test whether a particular computer in the network
is reachable. For this purpose, a set of sample data packets are sent to the destination computer which
will acknowledge the same.
Packet Internet Grouper (PING)
Port scanning: Port scanning is done by an application to scan for open ports that could be used to
send or receive data through a network. Port numbers up to 1024 are standard ports that are used by
various services. It is important that these ports be blocked if the service is not required. An open
port is vulnerable to unauthorized usage as an attacker may use the port to use malicious data or
extract confidential information.
Process audit: Process audit is done to check compliance of existing practices with the
benchmarked best practices. Thus, deviation from best practices are identified and process
improvements are done wherever required.
Reasonableness check: Reasonableness check compares data reasonably with established limits.
If the data exceeds the limit, it is treated as an exception and an appropriate action is sought.
Recovery Point Objective (RPO): Recovery Point Objective (RPO) is the time up to which data
loss can be accepted in case of a disruption.
Recovery Time Objective (RTO): Recovery Time Objective (RTO) is the acceptable downtime
for the business in case of a disruption.
Redundancy – Network: These are dedicated network cables that provides backup in case the
primary network cable fails.
Redundancy check: Redundancy check ensure that there are no data transmission errors.
Request for Proposal (RFP): A Request For Proposal (RFP) is an invitation to the suppliers, to
submit a proposal on a specific product or service.
Security logs: Events such as login attempts, account creation, account lockout, account revival,
password change and events related to resource usage (creation, opening or deleting of files) are
recorded in security logs. This log should be accessible strictly on a need to know basis. It must not
be possible to modify or delete logs. Security logs should be verified as a routine to check if there is
any malicious activity.
Sequence check: Sequence check is a check to ensure that the records are processed in order. The
objective being that all records should be processed and updated and there must be no blank records
or out of sequence records in between. This is usually done on the primary field of the database.
Example: Generation of account numbers in sequential order.
Server: A server is a sophisticated computer that accepts service requests from client machines
and processes the same. There are different types of servers based on the functions they perform—
File server, Database server, Application server, Print server, Mail server, Proxy server, Web server
and Domain name server.
Sniffers: Sniffers are hardware-based or software-based that can intercept data passing through it
in a network. Thus it could lead to loss of confidentiality and integrity when an unauthorized person
reads and modifies data in transit.
Spoofing: Spoofing is an attempt to gain access to sensitive information by impersonating or
masquerading like another user or system. Spoofing on website is also called as phishing.
Store and forward switch: Store and forward switch has a buffer memory that stores data passing
through it temporarily and performs a data integrity check (checksum) before forwarding it to the
destination.
Subnet mask: Subnet mask represents a range of logical network addresses within the address
space assigned to an organization. Subnet mask, like an IP address is a 32 bit binary number
expressed in dotted decimal formal. All network bits in an IP address are expressed as 1s and all host
bits in an IP address are expressed as 0s.
Super user: Super user is the user who has got complete access to all aspects and resources of the
system. Only the system administrator’s accounts have such access.
Switch: A switch is network device that acts at Layer 2 of the OSI model. It facilitates the
following:
Eliminates collision in the network

Facilitates segmentation of network
Creates Virtual LANs (VLANs)
Boosts data signals
Switches have more ports compared to the bridges. Thus, it can connect more devices. Besides,
switches are more efficient in managing MAC address table and in forwarding packets compared to
bridges.
Switch
System administrator: A system administrator is responsible for managing a computer system.
The system administrators are super users and have complete access to the system.
System intrusion: System intrusion is breaking into a security system to access confidential
information and perform attacks like denial of service. The intruder may or may not have an intention
to trespass the security system. Techniques that an intruder could use for this purpose include hacking,
spoofing, sniffing and social engineering.
Test data: Test data is used to test the functionality of the application. It is important that the test
data should be comprehensive to cover all possible business cases.
Total Branch Automation (TBA): Total Branch Automation is computerization at the branch
level. In this set-up a server in each branch hosts the application and database. All the computers
connected to the server will access the application and database through the Local Area Network
(LAN).
Trailer label: Trailer label is used to check the completeness of processing. It is available at the
end of each record and the summation will be checked against the control total.
URL: Uniform Resource Locator (URL) is a unique address for locating a web page in the Internet.
USB ports: Universal Serial Bus (USB) ports are used to connect computer peripherals such a
mouse, keyboard, printers, scanners and flash memory. These devices have the plug and play
capability (devices can be connected or disconnected without rebooting the computer).
Universal Serial Bus Ports
User Acceptance Testing (UAT): User Acceptance Testing (UAT) is done before product
implementation to make the users get accustomed to the application. In the process, the users will also
check if the application serves the business requirement.
User IDs: User IDs are unique names that identify each computer user. User access rights are
specified against each user ID in the system. To gain access into the system, user has to enter the user
ID and the password which will be verified by the system.
Version check: Version check is a verification, conducted for confirmation of the version used.
Version control: Version control is the process of differentiating software releases with a unique
serial version number. Thus, it distinguishes each release of the software. It is important the librarian
holds all the versions of the software.
Vulnerability testing: Vulnerability testing is done to assess the adequacy of controls and identify
any security threats in the system. Nessus is a popular vulnerability scanner tool that is used by many
companies. For more information on Nessus, visit www.nessus.org.
Virtual Local Area Network (VLAN): VLAN is the method of creating virtual networks within a
physical network. Each virtual network thus created, will act as a separate network. Advantages of
VLANs include:
It facilitates grouping of users based on job function.

It facilitates controlling data communication between two VLANs as per business
requirements.
It improves network performance as data from VLAN is not forwarded to the entire network.
Virtual Local Area Network (VLAN)

Wide Area Network (WAN): Wide Area Network (WAN) is a network that stretches across wide
geographic area like across metros or even across countries.
Web server: Web server hosts the website and accepts web page requests from users (through the
interface called browser) and processes the same.
WEB REFERENCES
1. The governance, risk, and compliance conference of the year.
http://www.complianceweek.com/
2. Risk-based Internal Audit
www.auditnet.org/rbia.htm
3. IT Compliance Institute
http://www.itcinstitute.com/info.aspx?id=34985
4. Risk-centered practices
https://buildsecurityin.us-cert.gov/daisy/bsi/home.html
5. OCEG also has some great guidance regarding compliance and ethics and on setting
objectives and boundaries. www.oceg.org
6. Assessing the effectiveness of fraud prevention efforts.
http://www.fraudaware.com/
7. AICPA Antifraud and Corporate Responsibility Center:
http://antifraud.aicpa.org/
8. The American Institute of Certified Public Accountants
http://www.aicpa.org/
9. Institute of Internal Auditor’s Comprehensive Fraud Repository.
http://www.theiia.org/
10. Guide for investigating computer crimes
http://www.ncjrs.gov/pdffiles1/nij/210798.pdf
11. The Disaster Recovery Journal.
https://www.drj.com/
12. IT Continuity and Disaster Recovery Newsletter.
http://www.continuitycentral.com/itcnewsoct06.htm
13. Preparing For A Disaster: Determining the Essential Functions That Should Be Up First.
www.sans.org/reading_room/whitepapers/recovery/1658.php
14. The Canadian Center for Emergency Preparedness (CCEP).
http://www.ccep.ca/index.html
15. The National Institute of Standards and Technology Computer Security Resource Center.
http://csrc.nist.gov/
16. CERT. http://www.cert.org/
17. Enterprise Risk Management
www.RIMS.org/
18. Security Absurdity: The Complete, Unquestionable, and Total Failure of Information Security.
http://www.securityabsurdity.com/failure.php
http://searchsecurity.techtarget.com/
19. Information Security Professional
https://www.isc2.org/
20. Felix Kloman’s website—Risk Management Reports
http://www.riskreports.com/
21. KnowledgeLeader provides policies, tools, articles, and other resources to help you
understand enterprise risk management, develop risk management and risk assessment
checklists, policies, and procedures; and discover best practices to mitigate risk.
www.knowledgeleader.com/
22. ISACA and the IT Governance Institute (ITGI).
www.isaca.org and www.itgi.org
23. Global Risk Advisors
http://globalriskadvisors.com/page.php?url=resources
INDEX
Access control, 106
ACL software, 217
Advances, 73, 183
Antivirus procedures, 57
Antivirus server, 12
Anywhere banking, 232
Application security control, 127
Application server, 11, 43
Assessment of risk, 115
Asset control policy, 33
Asset management, 102
ATM, 143
ATM card issue, 84
ATM fraud, 230
ATM switch, 190
Audit account log on events, 166
Audit account management, 166
Audit consideration for irregularities, 239
Audit log on events, 167
Audit logs, 206
Audit policy change, 168
Audit privilege use, 169
Audit tools, 216
Auditor’s responsibility, 17
Automated Teller Machine (ATM), 12, 15
Backup process, 52
Backup server, 44
Bank guarantee, 67, 177
BCP and DR, 112
Bills, 68, 178
Branches, 200
Business continuity management, 110
Business continuity plan, 249
Business continuity planning, 141
Card and PIN production, 185

Cash control and balancing, 188
Cash credit, 62
Cash credit and overdraft account, 174
Cash management system, 99, 204
Cash operations, 63, 175
CBS branch, 201
Change management, 150, 151
Change management procedures, 21
Change of employment, 104
Change of PIN, 90
Cleaning branch data, 76
Clearing, 64, 176
Communications and operations manage-ment, 104
Competence, 236, 248
Compliance, 110
Computer forensics, 247
Copyrights, 140
Core banking solution, 6
Current account, 61
Customization, 18, 75
Database administration, 21
Database events auditing, 209
Database log, 207
Database security control, 128
Database server, 11
Data centre, 23, 36, 41, 51
Data migration, 75
Data process tracking, 170
Deposits, 71, 182
Disaster recovery—cash management system, 146
Disaster recovery—Internet banking, 145
Disaster recovery for ATM, 144
Disposal of media, 32
Domain controller, 13
Domain controller baseline policy, 164
Domain policy, 161
Domain server, 155
Dynamic web, 9
Electronic key policy, 138

Email policy, 106
Equipment security, 26, 104
Equity funding case, 225
Event aggregation, 212
Event filtering, 212
Exception report, 207
Fault logging, 30
Firewall, 40, 252
Firewall and router security policy, 106
Firewall standards, 31
Front office operations, 200
Gateway Module (GM), 97
Hardening checklist, 161

Hardening mechanism, 160
Hardening procedure, 38
Human resources, 103
Incident handling, 135

Incident management, 28, 109
Income leakage, 225
Indian Finance System Code (IFSC), 94
Information classification, 24, 103, 135
Interbank Fund Transfer Processor (IFTP), 94
Interbank transactions, 88
Internet banking, 92, 129, 130, 242, 192
Internet banking application server, 12, 92
Internet banking database server, 13, 93
Internet banking operations, 16
Internet policy, 106
Internet services, 31
Intrusion detection, 252
Intrusion detection systems, 32
Inward bills, 69
Inward clearing, 64
Inward Message Manager (IMM), 97
ISACA, 234
KYC (Know Your Customer), 58
Letter of credit, 69, 179

Librarian, 21
Log archival, 213
Log clearing, 214
Log conversion, 213
Log maintenance, 66, 177
Log management infrastructure, 211
Log normalization, 213
Log parsing, 212
Log reduction, 213
Log rotation, 212
Logs of connectivity, 130
Lost and stolen cards, 189
Mail server, 14, 155

Master maintenance, 65, 176
Media handling, 136
Member server baseline policy, 162
Middleware proxy server, 13
Migration, 79
Mobile computing, 108
Monitoring process, 90
Negotiable instruments, 71, 181

Network access control policy, 107
Network administration, 21
Network connectivity, 80
Network managing, 30
Network vulnerability assessment, 153
ODBC compliance, 217

Offsite storage, 53
Operating system, 159
Operating system access control, 107
Operating system logs, 211
Operating system security control, 128
Organization of security policy, 102
Organization structure, 22
Outsourcing of IS activity, 238
Outsourcing policy, 135
Outward bills, 69
Outward clearing, 64
Outward Message Manager (OMM), 97
Overdraft, 62
Parameterisation , 231
Participant Interface (PI), 94
Patch management process, 38
Patch updation, 37
Patches and upgrades, 29
Penetration testing, 131
Personnel security, 135
Physical and environmental security, 136
PIN security, 187
PIN verification process, 89
Production environment, 150
Professional ethics, 235
Protection of information system equipment, 136
Raid, 43
Redundant network connectivity, 142
Remittances, 70, 180
Restore request, 53
Risk analysis, 25
Risk computation, 114
Risk management, 117
Risks type, 114
Router security policy, 137
Routers, 14, 39
RTGS, 94
RTGS system, 204
Savings and current accounts, 173

Savings bank account, 60
Security administration, 20
Security policy, 100
Security policy implementation, 134
Security settings of operating system, 165
Securitylog, 167
Senior citizen account, 173
Signature configuration, 49
Softward upgrade policy, 139
Software copyright policy, 140
Staff account, 173
Storage area network, 49
Surrendered and captured cards, 186
Switches, 14, 39
System administration, 20
Systems development life cycle, 147, 148
Tape lebelling, 54
Tape management, 53
Tape retention, 54
Technical vulnerability, 109
Test environment, 150
Third party service delivery, 105
Total branch automation, 1
Use of risk assessment, 237

User training, 135
Using the work of other experts, 237
Version control, 127
Version control policy, 139
Vulnerability, 125
Vulnerability assessment report, 154
Web server, 12, 44, 196

Website security, 137

Core Banking PDF

Uploaded by

Copyright:

Available Formats

You might also like

Core Banking PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Core Banking PDF

Uploaded by

Copyright:

Available Formats

CORE BANKING SOLUTION

Evaluation of Security and Controls

Third Printing...................................................................................November, 2010

PART 1: CORE BANKING SOLUTION: ITS FUNCTIONS,

PART 2 EVALUATION OF SECURITY AND CONTROL

Protecting corporate reputation

Information technology is often mistakenly regarded as a separate organization of the business

Core Banking Solution: Evaluation of Security and Controls authored by

What is Core Banking Solution (CBS)?

1.1.1 Advantages of Total Branch Automation (TBA)

1.1.2 Disadvantages of Total Branch Automation (TBA)

Figure 1.2 Core banking system

It enables the organizations, customer relationship management by providing a robust

Figure 2.1 Data center—network diagram.

Central database servers that store the data of the bank

2.1.2 Servers at the Data Center

2.1.3 Network Connectivity

2.1.4 Network Security

2.1.5 Operations from the Branch

2.1.6 Automated Teller Machine (ATM) Operations

2.1.7 Internet Banking Operations

An outside system integrator

3.1.1 Auditor’s Responsibility and Scope

Functions of the Information

Figure 4.1 Information system department organization.

Some of the significant functions are discussed below

4.3 SECURITY ADMINISTRATION

Maintaining access rule to data and other IT resources

4.4 SYSTEM ADMINISTRATION

4.5 DATABASE ADMINISTRATION

Defining the database structure

4.6 NETWORK ADMINISTRATION

Production version of the software

Best practices for an organization structure in a computer services department in any

Figure 4.2 Brief matrix showing the imcompatable functions.

Systems and Procedures for

5.2 DATA CENTER SECURITY PROCESS

5.2.1 Introduction to Manual

Distribution, review, ownership and version control

5.2.2 Asset Classification and Control

Information sensitivity classification and inventory of assets

5.2.3 Physical and Environmental Security

The facility is not to be located in a flood, earthquake or tsunami-prone area. Emergency

Building design and construction

The building should have acceptable fire rating.

Physical security perimeter

The physical security to exist around sensitive areas.

Data center security

Physical entry controls

Manufacturers’ guidelines are to be strictly followed.

Security of equipment off premises

Secure disposal of equipment

5.2.4 Communications and Operations Management

Event log file analysis

5.2.5 Systems Planning and Acceptance

Compliance with network bandwidth requirement

Protection against malicious software

At a minimum, logs are to be maintained for the following activities: