managing operational risk in payment, clearing and
TRANSCRIPT
i
Managing Operational Risk in Payment, Clearing and Settlement Systems
in Banking Industry: A Case Study
by
Md. Nurul Alam
MASTER OF ENGINEERING IN ADVANCED ENGINEERING MANAGEMENT Department of Industrial and Production Engineering
BANGLADESH UNIVERSITY OF ENGINEERING & TECHNOLOGY
January, 2019
ii
iii
iv
This Work is Dedicated to My Parents
v
Table of Contents
List of Figures………………………………………………………………………… vii
List of Tables………………………………………………………………………….. ix
List of Abbreviations………………………………………………………………….. x
Acknowledgement…………………………………………………………………….. xi
Abstract……………………………………………………………………………….. xii
Chapter 1 Introduction…………………………………………………………... 1
1.1 Introduction……………………………………………………………. 1
1.2 Research Gap and Motivation…………………………………………. 2
1.3 Objectives of the Present Work………………………………………... 2
1.4 Scope of the Project……………………………………………………. 3
1.5 Limitations……………………………………………………………... 3
Chapter 2 Literature Review…………………………………………………….. 4
2.1 Operational Risk……………………………………………………….. 4
2.2 Operational Risk Management………………………………………… 4
2.3 The Benefits of Operational Risk Management……………………….. 5
2.4 The Growing Awareness of Operational Risk in Payment, Clearing
and Settlement Systems (PCSS)………………………………………..
7
Chapter 3 Payment Systems in Bangladesh…………………………………….. 10
3.1 Bangladesh Automated Clearing House……………………………….. 10
3.2 Bangladesh Automated Cheque Processing Systems (BACPS)………. 10
3.2.1 Cheque system participants……………………………………. 11
3.2.2 Sample of Cheques and Instruments flow chart……………….. 11
3.2.3 General requirements for BACPS……………………………... 12
3.2.4 Hardware and Software required for BACPS…………………. 12
3.3 Bangladesh Electronic Fund Transfer Network (BEFTN)…………….. 14
3.3.1 Features of EFT………………………………………………... 14
3.3.2 The participants in BEFTN……………………………………. 15
3.3.3 EFT transactions……………………………………………….. 15
3.3.4 EFT credit entries……………………………………………… 15
3.3.5 EFT debit entries………………………………………………. 16
3.3.6 EFT transaction types………………………………………….. 17
3.4 Bangladesh Real Time Gross Settlement (BD-RTGS)………………... 17
3.4.1 Why RTGS…………………………………………………….. 18
3.4.2 Finality and irrevocability of payments……………………….. 19
3.4.3 RTGS utilities………………………………………………….. 20
3.4.4 Responsibilities of the participants……………………………. 20
Chapter 4 Methodology…………………………………………………………... 21
4.1 Research Methodology………………………………………………… 21
4.2 Risk Management Solutions ………………………………………… 22
4.2.1 Risk Management System (RMS) Software…………………... 22
4.2.2 Business Continuity Plan (BCP)………………………………. 22
4.2.3 Disaster Recovery Plan (DRP) 23
Chapter 5 Framework for Managing Operational Risk in Payment, Clearing
and Settlement Systems (PCSS)……………………………………...
24
5.1 Defining Operational Risk in PCSS…………………………………… 24
5.2 Identifying Operational Risk in PCSS…………………………………. 25
5.3 Assessing and Measuring Operational Risk in PCSS…………………. 25
5.4 Controlling and Mitigating Operational Risks in PCSS……………….. 26
5.4.1 Risk Management System (RMS) Software…………………... 26
vi
5.4.2 Business Continuity Plan and Disaster Recovery Plan………... 30
5.4.3 Introducing Business Continuity and Disaster Recovery
Planning………………………………………………………...
30
5.4.4 Importance of BCP and DRP for Payment, Clearing and
Settlement Systems (PCSS) operations………………………...
31
5.4.5 The BCP and DRP should be an integral part of the ORM
framework and developed to ensure that the following
objectives are met………………………………………………
31
5.4.6 Building Business Continuity Plan (BCP)…………………….. 31
5.4.7 Building Disaster Recovery Plan (DRP)………………………. 52
5.5 Monitoring Operational Risks in PCSS……………………………… 62
Chapter 6 Results and Discussions………………………………………………. 63
6.1 Benefits/Advantages of BCP & DRP using as Controlling and
Mitigating Technique for PCSS………………………………………..
63
6.1.1 Advantages of BCP and DRP in case of Network Interruption.. 63
6.1.2 Advantages of BCP and DRP in case of Software
Malfunctioning…………………………………………………
65
6.1.3 Advantages of BCP and DRP in case of Hardware
Malfunctioning…………………………………………………
66
6.1.4 Advantages of BCP and DRP in case of Miscellaneous
Malfunctioning…………………………………………………
67
6.1.5 Benefits/Advantages of BCP and DRP using as controlling and
mitigating technique (Summary)……………………………….
69
6.2 Benefits of Risk Management System (RMS) Software………………. 71
Chapter 7 Conclusions and Recommendations………………………………… 73
7.1 Conclusions……………………………………………………………. 73
7.2 Recommendations……………………………………………………... 73
References …………………………………………………………………………. 74
Appendix …………………………………………………………………………. 77
vii
List of Figures
Figure no. Title Page no.
Figure 3.1 Bangladesh Automated Clearing House (BACH) 10
Figure 3.2 Sample of Cheques 11
Figure 3.3 Traditional Paper Collection 11
Figure 3.4 Flow of Instruments both in Traditional & BACPS 12
Figure 3.5 BACPS files flow from one bank server to another bank server 13
Figure 3.6 Interfaces with BACPS (Outward and Inward Return) 13
Figure 3.7 Information Flow in BEFTN 15
Figure 3.8 EFT Credit Transaction Flow 16
Figure 3.9 EFT Debit Transaction Flow 16
Figure 3.10 BEFTN files flow from one bank server to another bank server 17
Figure 3.11 Major components of RTGS 18
Figure 3.12 Financial Message Flows 19
Figure 3.13 Finality and irrevocability of Payments 19
Figure 5.1 Risks incidents data from January, 2017 to December, 2017 26
Figure 5.2 RMS Software (Login Page) 27
Figure 5.3 RMS Software (Problem Creation Page) 27
Figure 5.4 RMS Software (Problem Description Page) 28
Figure 5.5 RMS Software (Request Received Dashboard Page) 28
Figure 5.6 RMS Software (Replying Message after solving Problem) 29
Figure 5.7 RMS Software (Risk Statistics Report Page) 29
Figure 5.8 Steps to Develop a Business Continuity Plan (BCP) 32
Figure 5.9 RPO and RTO (a) 35
Figure 5.10 RPO and RTO (b) 36
Figure 5.11 Flowchart to follow BCP 38
Figure 5.12 Backup Site for Business Continuity 44
Figure 5.13 Steps of Disaster Recovery Plan (DRP) 53
Figure 5.14 Flowchart to Activate Disaster Recovery (DR) site 58
viii
Figure 5.15 Disaster Recovery Teams 59
Figure 6.1 Risks Data variation between year, 2017 and 2018 72
ix
List of Tables
Table no. Title Page no.
Table 5.1 Risks data from January, 2017 to December, 2017 25
Table 5.2 Payment Systems critical process/systems 33
Table 5.3 Rank given by the respondents 34
Table 5.4 Percent position and Garrett value 34
Table 5.5 Calculation of Garret Score and Ranking 35
Table 5.6 Impact level/Rank after applying GARRETT ranking Method 35
Table 5.7 Data of RPO and RTO for Software down(on-site location) 36
Table 5.8 Data of RPO and RTO for Hardware down (off-site location) 36
Table 5.9 DRP timeframe for maintenance and testing 52
Table 5.10 Planning committee for DRP 54
Table 5.11 Risk assessment form 55
Table 5.12 Affect on service over time 55
Table 5.13 Rank given by the respondents 56
Table 5.14 Percent position and Garrett value 56
Table 5.15 Calculation of Garret Score and Ranking 56
Table 5.16 Rank/ Priorities after applying GARRET ranking method 57
Table 5.17 Emergency response activities and Disaster Recovery Teams 59
Table 6.1 Risks data variation between 2018 and 2017 72
x
List of Abbreviations
BACPS Bangladesh Automated Cheque Processing System
BB Bangladesh Bank
BCP Business Continuity Plan
BIA Business Impact Analysis
BIS Bank for International Settlements
CIO Chief Information Officer
CP Contingency Plan
DR Disaster Recovery
DRP Disaster Recovery Planning
FI(s) Financial Institution/Institutions
IS Information Systems
MIS Management Information System
MTD Maximum Tolerable Downtime
PCSS Payment, Clearing and Settlement Systems
PSD Payment Systems Department
RMS Risk Management System
RPO Recovery Point Objective
RTGS Real Time Gross Settlement
RTO Recovery Time Objectives
SLA Service Level Agreement
SOPs Standard Operating Procedures
UAT User Acceptance Testing
WRT Work Recovery Time
xi
Acknowledgement
At first the author expresses his heartiest thanks to the Almighty for giving the patience and
potentiality to dispatch this thesis in light. The author has the pleasure to express sincere
gratitude and profound indebtedness to his supervisor Dr. Sultana Parveen, Professor,
Department of Industrial & Production Engineering (IPE), BUET, Dhaka, for his continuous
support, guidance and valuable suggestions throughout the progress of this work.
The author also expresses his sincere gratitude and thanks to the board of examiners Dr. Syed
Mithun Ali, Associate Professor Department of Industrial & Production Engineering, BUET
and Dr. Shuva Ghosh, Assistant Professor, Department of Industrial & Production
Engineering, BUET for their valuable suggestions and guidance.
The author recognizes and expresses his thanks to the people of visited banking industries
who provided surplus facilities and supports to complete the work.
Finally, the author would like to thank all of his friends for their cooperation and motivation
to complete the thesis timely. And the author would also like to extend his thanks to his
parents whose continuous inspiration, sacrifice and support encouraged his to complete the
thesis successfully.
xii
Abstract
Awareness of operational risk has increased greatly in recent years for Payment, Clearing,
and Settlement Systems (PCSS) in banking industry. PCSS consist of networks of
interconnected elements (i.e., Bangladesh Bank as central operator, different banks as
participants). Operational problems at any one of the key elements have the potential to
disrupt the system as a whole and negatively affect financial stability.
Operational risks mean a range of threats from loss of key personnel, settlement failure, and
compliance failure, to theft, systems failure and building damage. Operational risk
management aims to ensure the integrity and quality of the operations of Payment, Clearing,
and Settlement Systems (PCSS) using Risk Management System (RMS) Software, Business
Continuity and Disaster Recovery Planning (BCP and DRP).
This thesis identifies and analyzes various operational risks occurring in payments systems of
banking industry. An Operational Risk Management (ORM) framework including RMS
Software, BCP and DRP have been built in terms of the potential outcomes of operational
events from certain risk factors such as systems problems, human error, process problems,
and external events, their likelihood, and their frequency.
In the meantime, qualitative analysis provided by operations experts associated with the
various elements of PCSS will be important for judging the potential impact and frequency of
events. Once operational risk databases are developed that record the frequency and severity
of operational events then it will be possible to effectively manage operational risks in PCSS.
In a changing financial environment, it is hoped that this risk management framework could
be used for managing operational risk in payment, clearing, and settlement systems of
banking industry.
1
Chapter 1
Introduction
1.1 Introduction
A modern national payment system is the backbone for a country‘s monetary and financial
infrastructure and an advanced payment system plays a critical role in the country‘s current
and future economic development (Bangladesh Bank, 2010). Payment, Clearing and
Settlement systems (PCSS) are a key part of the financial infrastructure. They allow financial
institutions to ex-change payments, settle securities transactions, and finalize the transfer of
funds involved in foreign exchange transactions. PCSS consist of networks of interconnected
elements—central operators of the systems, their participants, and their settlement agents
(McPhail, 2003).
Sound operational risk management in payment, clearing, and settlement systems (PCSS) is
important for financial stability. During the day, PCSS allow financial institutions and their
clients to exchange payments. PCSS are networks that support much financial and economic
activity. PCSS is closely linked to another so disruptions in one may cause problems for
another system. PCSS are a key part of the financial infrastructure. Because of their critical
function in the economy, PCSS must be safe, reliable, efficient, and secure.
Operational risk is defined as the risk of loss resulting from inadequate or failed internal
processes, people and systems or from external events (Basel II Basel Accords, 2004).
Awareness of operational risk has increased greatly in recent years, both at individual
financial institutions and for payment, clearing, and settlement systems (PCSS). Operational
problems at any one of the key elements have the potential to disrupt the system as a whole
and negatively affect financial stability. Most organizations accept that their people and
processes will inherently incur errors and contribute to ineffective operations. Poor
operational risk management can hurt an organization's reputation and cause financial
damage (Margaret, 2000).
Confirm business continuity planning enables the institution to quickly recover and maintain
payment processing operations. Establish controls around critical systems and test the
controls regularly. Appropriate controls include, but are not limited to access controls,
segregation of duties, audits, and fraud detection, and should be implemented according to
associated risks (FFIEC, 2016).
2
To monitor the entire system 24x7 round the clock, effective Information Security Operation
Centre should be established along with evaluation of technological weakness and disaster
recovery management (Bangladesh Bank, 2017).
Awareness of operational risk management is low in our country, and has no specific
business continuity and disaster recovery plan. This is not seen as important or a priority,
there are inadequate resources allocated to establish and maintain an operational risk
management (ORM) framework, and responsibility is hand over to information technology
division. It becomes a one-time project rather than an integral part of the day-to-day
operations.
The aim of this project work is to describe a practical approach that could be used to assess
and manage operational risk in Payment, Clearing and Settlement systems (PCSS) in banking
industry.
1.2 Research Gap and Motivation
The extant literature reveals that there is little work on identifying, analyzing and managing
various operational risks in the context of payment systems. Despite the growth of the
banking sector, the literature lacks to managing operational risks of payment systems in the
context of Bangladesh.
Thus, this study attempts to fill this research gap in the operational risks management
literature with the help of Risk Management System (RMS) software, Business Continuity
Plan (BCP) and Disaster Recovery Plan (DRP). The major contribution of this research is the
identification and analyzing of common operational risks in the field of payment systems. To
realize managing operational risks in payment, clearing and settlement systems (PCSS) a real
life case study on payment systems in banking industry is also introduced.
1.3 Objectives of the Present Work
The objectives of this study are:
To develop a common understanding of operational risk in Payment, Clearing and
Settlement Systems (PCSS) and managing it effectively.
To ensure integrity and quality of the daily operations.
To continue operations if any disaster occurs.
To minimize operational losses.
To reduce exposure to future risks.
3
1.4 Scope of the Project
The project report is organized into seven chapters including this one. The chapters are
structured in the following way:
Chapter 1 gives the motivation and objectives of this project.
Chapter 2 presents the literature review on operational risk and operational risk management.
Chapter 3 gives an overview on payment systems of Bangladesh banking industry.
Chapter 4 Research methodology and risk management solutions are illustrated in this
chapter.
Chapter 5 A detail framework for assessing and managing operational risk in Payment,
Clearing and Settlement Systems (PCSS) and practical case study has been explained in this
chapter.
Chapter 6 Results and discussions after implementing Risk Management System (RMS)
software, Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) have been
included in this chapter.
Finally, conclusions and recommendations are presented in Chapter 7. References presented
at the end of the thesis.
This report will be helpful to those people who intend to prepare further research on the
managing operation risk on payment, clearing and settlement systems in banking industry in
future. From this report they can gather knowledge about the present risk management of
banking industry. The study aims to help better management of risk handling which occurs in
payment, clearing and settlement system.
1.5 Limitations
1. The main constraint of the study was insufficiency of information, which is required
for the study.
2. Since the employees are very busy with their routine activities as a result it is difficult
to collect different types of information from other banks.
3. To maintain official confidentiality some information and plan are not disclose in the
report.
4
Chapter 2
Literature Review
2.1 Operational Risk
The Basel Committee on Banking Supervision has described operational risk as:
"The risk of loss resulting from inadequate or failed internal processes, people and systems or
from external events."
However, the Basel Committee recognizes that operational risk is a term that has a variety of
meanings and therefore, for internal purposes, banks are permitted to adopt their own
definitions of operational risk, provided that the minimum elements in the Committee's
definition are included. The following lists the seven official Basel II event types with some
examples for each category:
1. Internal Fraud – misappropriation of assets, tax evasion, intentional mismarking of
positions, bribery.
2. External Fraud – theft of information, hacking damage, third-party theft and forgery.
3. Employment Practices and Workplace Safety – discrimination, workers
compensation, employee health and safety.
4. Clients, Products, and Business Practice – market manipulation, antitrust, improper
trade, product defects, fiduciary breaches, account churning.
5. Damage to Physical Assets – natural disasters, terrorism, vandalism.
6. Business Disruption and Systems Failures – utility disruptions, software failures,
hardware failures.
7. Execution, Delivery, and Process Management – data entry errors, accounting errors,
failed mandatory reporting, negligent loss of client assets.
All of these risks need to be managed and the more sophisticated the approach to risk
management, the more chance the business has to thrive and grow.
2.2 Operational Risk Management
The term operational risk management (ORM) is defined as a continual cyclic process which
includes risk assessment, risk decision making, and implementation of risk controls, which
results in acceptance, mitigation, or avoidance of risk. ORM is the oversight of operational
risk, including the risk of loss resulting from inadequate or failed internal processes and
systems; human factors; or external events.
The U.S. Department of Defense summarizes the principles of ORM as follows:
• Accept risk when benefits outweigh the cost.
5
• Accept no unnecessary risk.
• Anticipate and manage risk by planning.
• Make risk decisions at the right level.
2.3 The Benefits of Operational Risk Management
Operational Risk Management is an essential step for every company that is looking to avoid
potentially damaging issues. Here are the main benefits of Operational Risk Management:
Improving the reliability of business operations
Improving the effectiveness of the risk management operations
Strengthening the decision-making process where risks are involved
Reduction of operational losses caused by poorly-identified risks
Early identification of unlawful activities
Lower compliance costs
Reduction in potential damage from future risks
From the day the internet became the vital component of operating a business, attacks on
compromising systems with networks as the main vulnerable tool have begun. While cyber
attacks are the most certain aspects that come into mind when thought about information
security, there are some attacks that are not intentionally done yet bring huge losses to the
organization. Either way, businesses must prepare themselves for the disaster. ―The secret of
survival is preparation‖ (Edwards, 1994, p. 38).
As the technology has grown, many data back up plans have come up so that at
least the data and information are not lost. Adding to the benefit of having the ability to bring
the data back, if a business can also run its core processes during the disasters, will be the
great capability one can bring into this digital era. That capability is called the Contingency
plan, which includes incident response, disaster recovery and business continuity plans.
By having a good contingency plan, employees will have enough knowledge on what choices
to be made, what assets to be protected on high priority and which business operation should
be continued during a crisis (Gregg, 2009).
Incident response. Incident response is a phase that prepares a team, Incident Response
Team, to be ready to handle any incident on the moment. An incident can range from
hardware failure or power outages to violation of organization‘s policies by a disgruntled
employee (Bejtlich, 2004).
Business continuity plan. ―Business continuity refers to the activities required to keep
the organization running during a period of displacement or interruption of normal
operations‖ (SANS Institute, 2002, p. 1).
6
According to Britton (2016), risks of not having a Business Continuity Management Program
are: 1. Business Failure: It seems, 75% of the companies drop from their business within
three years after a disaster has occurred.
2. Disasters can lead to injury and death of the employees, clients and other visitors of the
company.
3. Disasters can be very costly, if they are not properly handled. ―Over a five-year period,
businesses lost more than $70 million due to downtime alone‖ (Britton, 2016).
4. Bad Reputation: Companies that does not have a disaster recovery or a business continuity
plan are viewed as insecure investment and untrustworthy by customers and stakeholders.
5. Loss of productivity is the major consequence of disasters, even if the company survives
the disaster; it has to compromise on at least one of its mission critical operation.
Disaster recovery plan. ―The most successful disaster recovery strategy is the one that will
never be implemented; therefore, risk avoidance is a critical element in the disaster recovery
process‖ (Martin, 2002, p. 1).
―Depending on the nature of the organization and its size and various other factors, a
company must design an optimal plan to minimize the effect of disaster and continue the
critical business functions‖ (SANS Institute 2002, p. 559)
Contingency planning, more precisely business continuity and disaster recovery plans,
decides the last chance for a business to survive. Global Benchmark Study reveals that 73%
of the organizations lack disaster recovery strategies and more than 5 million losses are
incurred due to critical application failure, data losses, data center outages etc. (Kahan, 2014).
S.K.Bagchi, former director of Birla Industrial & Technological Museum, India observed
that in the world of finance more specifically in Banking, Credit Risk is the most
predominant risk in Banking and occupies roughly 90-95 per cent of risk segment. The
remaining fraction is on account of Market Risk, Operations Risk etc. He feels that so much
of concern on operational risk is misplaced. As per him, it may be just one to two per cent of
Bank‘s risk. For this small fraction, instituting an elaborate mechanism may be unwarranted.
A well laid out Risk Management System should give its best attention to Credit Risk and
Market Risk. In instituting the Risk Management apparatus, Banks seem to be giving equal
priority to these three Risks viz., Credit Risk, Operational Risk and Market Risk. This may
prove counter-productive.
Chief Risk Officer, Alden Toevs of Commonwealth Bank of Australia states that a major
failure of risk management highlighted by the global financial crisis was the inability of
financial institutions to view risk on a holistic basis. ‗The global financial crisis exposed, with
chilling clarity, the dangers of thinking in silos, particularly where risk management is
concerned‘ says the author. The malady is due to the Banks focusing on individual risk
exposures without taking into consideration the broader picture. As per the author the root of
the problem is the failure of the Banks to consider risks on an enterprise-wide basis. The new
7
relevance and urgency for implementing the Enterprise Risk Management (ERM) is due to
the regulatory insistence with a number of proposals to ensure that institutions stay focused
on the big picture. In a way the Three Pillar Approach frame work of the Basel II Accord is
an effort to fulfill this requirement. The risk weighted approaches to Credit Risk on the basis
of the asset quality, allocation of capital to Operational Risk and Market Risks nearly capture
all the risks attendant to a Bank‘s functioning.
According to Widup (2003), ―20.4% of the organization does not have a disaster recovery
plan, among the organizations that have DRP, 26.1% of them have not tested their plan‖
According to Snedaker (2007), BC and DR plans cannot be ignored as the statistics of losses
due to disaster are alarming and this should serve as a wakeup call for IT professionals and
corporate executives.
After the September 11, 2001 horrifying terrorist attacks on the World Trade Center,
government agencies and businesses have decided to implement DR plans to strengthen
security and business continuity. Immediately after the attack, 73 declarations from 36
companies seeking help were filed regarding the disaster (Hanning, 2001).
A disaster recovery plan is much more than just having data backups, and most of the
organizations having this misconception have changed their minds after September 11
(Lancaster, 2002).
―Business continuity and disaster recovery are the strategies implemented to increase the
likelihood of effectively recovering business functions from a major disaster‖ (Barbara,
2006).
The organizations that thought ahead and had a plan that is prepared for the impacts of a
disaster survive in this competitive world. There are very few such organizations, statistically
only 5% of the organizations are genuinely prepared to handle a disaster.
2 .4 The Growing Awareness of Operational Risk in Payment, Clearing and Settlement
Systems (PCSS)
Awareness of operational risk has increased sharply in recent years due to well-publicized,
very sizable losses suffered by a number of large financial institutions over the past decade as
a result of weaknesses in internal controls. There is a growing recognition that although the
likelihood is small, the financial consequences of such events could be extremely damaging.
A severe operational problem within a financial institution can create problems for
important parts of the financial system architecture. A prominent example of such an event is
that of the Bank of New York (BONY), because of the key role it plays in clearing U.S.-
dollar securities. In 1985, a 28-hour computer malfunction prevented BONY from carrying
out its securities-related activities. As a result, BONY needed to borrow a record amount—
more than $20 billion—from the Federal Reserve‘s discount window. Other financial
institutions were left with a corresponding excess of cash. Their efforts to dispose of this
8
surplus temporarily drove the federal funds rate down by about 300 basis points. Problems at
BONY during the events following 11 September 2001 also contributed to extreme liquidity
disruptions and problems in securities markets in the United States.
In 1990, a fire in New York left a number of buildings in lower Manhattan, including that of
the Federal Reserve Bank of New York, without power for six days. Severe demands were
placed on operations and backup facilities.
Operational risk in the financial infrastructure can also spill over to international markets. In
April, 2000, a software problem caused trading on the London Stock Exchange (LSE) to stop
for almost eight hours. The London International Futures Exchange, which uses spot prices
obtained from the LSE to value futures contracts, was also affected. The inability to adjust
U.K. portfolios was reported to have caused a number of investors to sell European shares,
and prices on European exchanges fell.
The realization of operational risk in PCSS may result in market, liquidity, and credit risk
problems. The events following the terrorist attacks of 11 September 2001 affected the entire
financial infrastructure in the United States and parts of the infrastructure in Canada and other
countries. Large-value payment systems around the world remained open during that period
and the financial architecture functioned remarkably well under the circumstances.
Nevertheless, the settlement of bond transactions in the United States was severely disrupted
and dislocations in U.S. payment systems contributed to severe liquidity problems at some
institutions. Major stock exchanges in the United States and Canada closed. The two largest
electronic interbank trading systems for foreign exchange transactions, Reuters and EBS, also
closed for a short time due to an overload of backup systems. In Canada, concern by domestic
financial institutions that they might not receive U.S. funds owing to them in a timely fashion
(because of potential disruptions in US payment systems) altered the flow of payments in the
Large Value Transfer System (LVTS).
The events of 11 September have emphasized the importance of documented, validated, and
tested contingency plans to deal with extreme events. Around the world, operators of PCSS
are reexamining whether contingency plans are robust enough to deal with the consequences
of extreme disruptions of one or more of the critical elements of PCSS.
Operational risk management has gained prominence for other reasons. Change in the
financial sector globally has been rapid in the past decade and it will continue in the future.
Examples include globalization, disintermediation, and the increasing complexity of financial
instruments.
In North America, large value payment systems and some securities settlement systems are
moving towards 24-hour availability. Technological advances are leading to increasing
economies of scale and scope that influence many aspects of PCSS. These trends make more
severe the consequences of operational disruptions at one of the key elements of the financial
infrastructure. This may require PCSS to invest more resources to reduce the financial
system‘s vulnerability to this type of shock.
9
Technological advances also shift the composition of operational risk. New technologies are
often adopted because of cost considerations rather than because of any expected reduction in
risk. Although advancing technology allows for more straight-through processing and a
reduction in manual intervention, more sophisticated technology may make it more difficult
to identify the nature of operational problems and may take much longer to resolve them
when they occur. Moreover, when these systems fail, it may be far more difficult to rely on
manual backup and disruptions in these more efficient, integrated systems should occur much
less frequently, but their consequences may be more severe.
It will likely become increasingly important for many payments and financial instruments to
be delivered promptly at specific times of day. As this time-criticality grows in importance, it
places a much greater burden on the operational reliability of all elements of PCSS operators,
participants, and settlement agents.
10
Chapter 3
Payment Systems in Bangladesh
3.1 Bangladesh Automated Clearing House
Bangladesh Automated Clearing House (BACH): BACH, the first ever electronic clearing
house of Bangladesh, has two components - the Automated Cheque Processing System
(ACPS) and the Electronic Funds Transfer (EFT). Both the systems operate in batch
processing mode- transactions received from the banks during the day are processed at a pre-
fixed time and settled through a single multilateral netting figure on each individual bank‘s
respective books maintained with the Bangladesh Bank. A state-of-the-art Data Center (DC)
and a Disaster Recovery Site (DRS) have been established comprising of most modern
software and hardware for dealing with the operations of BACH. A Virtual Private Network
(VPN) has been created between the participating commercial banks and Data Center (DC) &
Disaster Recovery Site (DRS) for communicating necessary information related to BACH.
Digital Certificate has been formulated for the first time in Bangladesh for secured data
communication. Bangladesh Automated Clearing House (BACH) has been operating under
Payment Systems Department of Bangladesh Bank having two wings as under:
Figure 3.1: Bangladesh Automated Clearing House, (Bangladesh Bank, 2010).
3.2 Bangladesh Automated Cheque Processing Systems (BACPS)
Bangladesh Automated Cheque Processing System (BACPS) will process and clear the paper
based instruments among all member banks. When a customer deposits his cheque to the
collecting bank, digital image of the cheque will be generated and electronic information will
be captured for clearing process. Cheque image will be presented to the drawee bank
electronically. Paper Cheques will be retained by the collecting bank.
Bangladesh Automated Cheque Processing Systems (BACPS) has started its 'Live Operation'
on 7th October 2010 in the Dhaka Clearing House area. BACPS uses the Cheque Imaging
and Truncation (CIT) technology for electronic presentment and payment of paper
instruments (i.e. cheque, pay order, dividend & refund warrants, etc). The system supports
both intra-regional and interregional clearing and is based on a centralized processing centre
located in Dhaka and in designated clearing regions.
Bangladesh Automated Clearing House (BACH)
Bangladesh Automated Cheque Processing System
(BACPS)
Bangladesh Electronic Fund
Transfer Network (BEFTN)
11
There are two types of cheque clearing under BACPS, i.e. High Value (HV) and Regular
Value (RV) Cheque clearing. Cheque amounting Tk. 500,000 or above are eligible for HV
clearing which has shorter clearing cycle than RV.
3.2.1 Cheque system participants
Payer – party obligated to pay on cheque (also known as the maker, cheque writer, or
drawee)
Payee – party or parties due payment and so indicated on the cheque
BOFD– the Bank of First Deposit (BOFD) at which a cheque is deposited Presenting Bank
also known as the collecting or sending bank (payee‘s bank)
Paying Bank – bank whose routing number is encoded in MICR on a cheque (payer‘s bank)
3.2.2 Sample of Cheques and Instruments flow chart
Cheque design 3.5 x 7.5 inches
Figure 3.2: Sample of Cheque
5
Figure 3.3: Traditional Paper Collections, (Bangladesh Bank, 2010).
12
3.2.3 General requirements for BACPS
• Each BACPS-eligible item shall be exchanged, cleared and settled in accordance with
BACPS rules made by Bangladesh Bank.
• All items must contain MICR encoded routing number in order to be eligible for
BACPS
• An image of each BACPS-eligible item shall be captured prior to truncation in
accordance with these rules.
• Each bank shall maintain an archive of data and images for each BACPS-eligible item
for which it is the presenting bank or the paying bank.
• Each presenting bank shall retain original paper items (source documents) for a period
of six years commencing as of the date of capture.
• Each presenting bank may destroy source documents following the expiration date of
the source document retention period.
Traditional Paper Collection
3
Bangladesh Bank Paying BankBOFDcheque cheque cheque
BACPS Paying BankBOFD ImageImagecheque
Image Collection
Figure 3.4: Flow of Instruments both in Traditional & BACPS, (Bangladesh Bank, 2010).
3.2.4 Hardware and Software required for BACPS
Each capturing Bank shall capture images in accordance with the, BACPS Image Usability
Standard and the BACPS Active Image Clearing Specifications (AICS). MICR Scanner is
needed to capture digital image of MICR cheque. Hardware such as PBM server, BACH
server and computer needed to participate in BACPS. Software such as BACH software,
Core Banking System (CBS) also must for automated cheque processing system.
13
• SJIBL
SJIBL BR
SJIBL
BACPS
SERVER
SJIBL PBM
SERVER BB SERVERIBBL PBM
SERVER
IBBL BACPS
SERVER
IBBL BR
Figure 3.5: BACPS files flow from one bank server to another bank server, (SJIBL, 2015).
Figure 3.6: Interfaces with BACPS-Outward and Inward Return, (SJIBL, 2010).
14
3.3 Bangladesh Electronic Fund Transfer Network (BEFTN)
The EFT Network refers to a highly reliable and efficient nationwide batch-oriented
electronic funds transfer system, which provides for the interbank clearing of electronic
debits and credits.
BEFTN has started its 'Live Operation' on 28th February 2011 with the objective to
decrease paper-based payment methods and encourage electronic payment methods for
secured, faster & cost-effective transactions. The Network started with credit transactions and
open for debits from 15 September 2011.
BEFTN facilitates the transmission of payments between the banks electronically, which
makes it faster and efficient means of inter-bank clearing over the existing paper-based
system i.e. BACPS. It is able to handle a wide variety of credit transfers such as payroll,
foreign and domestic remittances, social security, company dividends, retirement, expense
reimbursement, bill payments, corporate payments, government tax payments, social security
payments and person to person payments.
3.3.1 Features of EFT
End to end electronic
EFT operates on customer instructions.
EFT transaction may both be debit or credit.
3.3.2 The participants in BEFTN
Originator: The Originator is the entity that agrees to initiate EFT entries into the network
according to an arrangement with a receiver.
Originating Bank (OB): The originating bank is the bank which receives payment
instructions from its client (the originator) and forwards the entry to the EFT operator.
EFT Operator (Bangladesh Bank): BEFTN is the central clearing facility, operated by
Bangladesh Bank that receives entries from OBs, distributes the entries to appropriate RBs,
and facilitates the settlement functions for the participating banking institutions.
Receiving Bank (RB): The receiving bank is the bank that will receive EFT entries from
BEFTN and post the entries to the account of its depositors (Receivers).
Receiver: A receiver is a person/organization who has authorized an Originator to receive an
EFT entry to the account maintained with the Receiving Bank (RB).
15
7 11/2/20147
BEFTNOrigination Bank Receiving Bank
OriginatorReceiver
For settlement
BB
Information Flow in BEFTN
Authorization (for Debits)
Figure 3.7: Information Flow in BEFTN, (Bangladesh Bank, 2010).
3.3.3 EFT transactions
An EFT entry may either be a credit or a debit entry. By examining what happens to
the receiver‘s account will determine whether it is a debit or a credit.
If the receiver‘s account is debited, the entry is an EFT debit and if the receiver‘s
account is credited, the entry is an EFT credit.
3.3.4 EFT credit entries
In EFT credit transfers (also termed as ‗credit push‘), the Originator instructs his/her bank to
debit his/her account and credit the funds to the Receiver‘s account.
Examples
• Payroll Corporate and Govt.
• Inward Foreign Remittances
• Dividend, Interest and Refund Payments
• Tax Payments
• Customer initiated transactions (online purchase)
16
Figure 3.8: EFT Credit Transaction Flow, (Bangladesh Bank, 2010).
3.3.5 EFT debit entries
In an EFT debit (also termed as ‗debit pull‘), the Originator instruct its bank to collect
payment from the Receiver (paying party)‘s account, often on a recurring basis.
Examples
• Utility Bill Payments
• Mortgage/Loan Installment
• Insurance Premium
• Club/ Association Payments
• Corporate Cash Concentration
Figure 3.9: EFT Debit Transaction Flow, (Bangladesh Bank, 2010).
17
3.3.6 EFT transaction types
Credit or Debit
Credit examples: salary, pension, annuities
Debit examples: insurance, loan installment, utility payments
Consumer, Commercial or Govt.
Consumer: P2P, P2B,P2G
Commercial: B2B, B2P, B2G
Government: G2P, G2B
• SJIBLSJIBL
BR**
SJIBL
BEFTN
SERVER
SJIBL PBM
SERVER BB SERVERIBBL PBM
SERVERIBBL BEFTN
SERVER
IBBL BR
Figure 3.10: BEFTN files flow from one bank server to another bank server, (SJIBL, 2015).
3.4 Bangladesh Real Time Gross Settlement (BD-RTGS)
BD-RTGS is a real time interbank large value electronic funds transfer mechanism for both
local and foreign currency transactions. Participating banks will be able to transfer funds on
`real time‘ and on `gross‘ basis. Settlement in `real time‘ means transaction is not subjected to
any waiting period. `Gross settlement‘ means the transaction is booked in central bank‘s
account on one to one basis without netting with any other transaction. BD-RTGS will
accommodate only credit transfers from participating banks while Bangladesh Bank and
other payment system operator(s) may be allowed to settle both credit and debit transactions.
The participants in the BD-RTGS system are as follows:
Originator: The Originator is the entity that agrees to make payment to a receiver by
initiating RTGS entries into the system. The Originator is usually a company, bank itself,
government agency or an individual instructing the Originating Bank to debit his/her/its
account and credit the amount to another customer‘s account with Receiving Bank. However,
as an exception, Bangladesh Bank or other Payment System Operator(s) can act as an
18
Originator and may send instructions directly to the system in which other participants‘
account may be debited and/or credited.
Originating Bank (OB): The Originating Bank is the bank which receives payment
instructions from its customer (the Originator) and forwards the instruction to BD-RTGS
system.
Bangladesh Real Time Gross Settlement (BD-RTGS) System: BD-RTGS System is the
central processing and settlement facility, operated by Bangladesh Bank. The system receives
instructions from Originating Banks, and before distributing the instructions to the
appropriate Receiving Bank, it does the settlement.
Receiving Bank (RB): The Receiving Bank is the bank that receives RTGS payment
instructions from BD-RTGS System and posts the same to the appropriate account which
may be its customer (Receiver).
Receiver: A Receiver is a person/organization that has agreed with an Originator to receive
RTGS payment to its account maintained with Receiving Bank.
3.4.1 Why RTGS
Reasons for introducing RTGS:
Eliminate Credit risk and thereby systemic risk
Reduction of settlement risk in forex and Govt. securities
Boost economic activities
Better customer service
Peer Pressure/international best practices
(190 countries currently have RTGS system)
Paying
participant
Connectivity
Payment processing
Settlement processing
Funds transferQueue
Sufficient Balance?YesNo
Receiving
participant
• Authentication, validation,
reconciliation and confirmation of
payment instructions.
• Transfer of funds between the
settlement accounts and give finality
and irrevocability.
• Interface with the participants or
other systems
Figure 3.11: Major components of RTGS, (standard chartered Bank, 2015).
19
CentralApplication
1
2
4
5
1 Payment Instruction
3 Authorisation response
4Final Payment Instruction received
5
Sender notification and reporting (Optional)
2 Authorisation request
3
SWIFT
Interface
SWIFTNet
CentralInstitution
Bank A Bank B
Y- Copy
5
Figure 3.12: Financial Message Flows, (standard chartered Bank, 2015).
3.4.2 Finality and irrevocability of payments
A valid RTGS payment is final and irrevocable. As from the moment that the central System
has accepted a Payment Instruction for Settlement, withdrawal by the Originator/OB or by
the System is not allowed unless the payment is queued for settlement and is allowed to do
the cancellation. Settlement will be final and unconditional at the moment that the Settlement
Accounts of OB and RB have been debited and credited. There is no perceptible delay
between the acceptance for Settlement and the final Settlement in RTGS System.
Figure 3.13: Finality and irrevocability of Payments, (Bangladesh Bank, 2015).
20
3.4.3 RTGS utilities
BD-RTGS is the interbank large value payment system which accommodates:
Local and approved foreign currency payments initiated by OBs on their own behalf
and on behalf of their customers.
The transactions involving Government securities processed through the securities
registration systems maintained by BB Market Infrastructure (MI) Module and Islami
Bond System (IBS), on the principle of Delivery versus Payment (DvP).
The final and irrevocable gross settlement in Participants‘ Settlement Accounts of the
net positions arise from the Deferred Net Settlement (DNS) operations of:
-Bangladesh Automated Cheque Processing System (BACPS);
‐ Bangladesh Electronic Funds Transfer Network (BEFTN);
‐ National Payment Switch Bangladesh (NPSB);
‐ Or from any other multilateral interbank DNS system that BB may deem
appropriate.
3.4.4 Responsibilities of the participants
The participants shall issue their payment instructions to BD-RTGS in accordance with these
rules and shall adhere and be held responsible for the followings:
a) The completeness and authenticity of the information they send on their own behalf and
on behalf of their customers;
b) The compliance of payment messages with the agreed-upon technical protocols and
formats;
c) Securing the access to their BD-RTGS Monitoring and Control Workplace(s) and ensure
proper segregation of duties and responsibilities among the operational team;
d) Ensuring that they collect all data provided to them by BD-RTGS;
e) Ensuring that only duly authorized Users who have been issued with an access control e-
token by BB are using the System.
21
Chapter 4
Methodology
4.1 Research Methodology
The aim of this research work is to find out the most significant operational risks in payment,
clearing and settlement systems in banking industry and design a framework to manage these
types of operational risks. The proposed research consists of five steps as mentioned below.
Step 1: Defining operational risk in Payment, Clearing and Settlement Systems (PCSS)
To manage or work with operational risks, it is important to have clear view on area and
definition of operational risks. The objective of this step is to define operational risks in
Payment, Clearing and Settlement Systems (PCSS) in banking industry with short
explanation.
Step 2: Identifying operational risk in PCSS
The objective of this step is to generate a comprehensive list of operational risks. In this step,
most relevant operational risks are identified through Interviewing and Information
gathering techniques and from practical operational field. Risk factors that are main
responsible for PCSS operational interruption have been identified.
Step 3: Assessing and Measuring Operational Risk in PCSS
Primary operational risks have already been identified in Payment, Clearing and Settlement
Systems (PCSS) in previous step. This step has been focusing on assessing and measuring
operational risks on primary operational risks such as Hardware failure, Software failure,
Network failure, Process Error, Power failure, Third party providers, Human error, Key
person missing, Poor maintenance, etc. Risk categories or standard which are based on
various types of risks occurrences have been discussed here.
Step 4: Controlling and Mitigating Operational Risks in PCSS
A detail contingency plan which had developed according to risks category or standard have
been proposed in this step to control and mitigate operational risks. Contingency plan also
contain business activities, critical processes and systems; and made considering practical
problems related to regular payment, clearing and settlement system of banking industry.
Furthermore, implementation procedures will be discussed in this step.
Step 5: Monitoring operational risk in PCSS
How to monitor overall framework of operational risks management and regarding regular
testing and updating of contingency plan will be discussed in this step.
22
4.2 Risk Management Solutions
Going back to the history, when an adverse event occurs and the data or records or equipment
are damaged, the result cannot be undone, and the business is either on halt or put to an end.
But, as the technology has grown, many data back up plans have come up so that at least the
data and information are not lost. Adding to the benefit of having the ability to bring the data
back, if a business can also run its core processes during the disasters, will be the great
capability. That capability is called the Contingency plan, which includes incident response,
disaster recovery and business continuity plans.
Contingency planning, more precisely business continuity and disaster recovery plans,
decides the last chance for a business to survive. Global Benchmark Study reveals that 73%
of the organizations lack disaster recovery strategies and more than 5 million losses are
incurred due to critical application failure, data losses, data center outages etc. (Kahan, 2014).
4.2.1 Risk Management System (RMS) Software
Managing operational risk is the ongoing process undertaken by an organization to identify,
evaluate, and treat potential exposure to loss, and to monitor risk factors to reduce the effects
of damages or loss.
Risk Management System software helps organization to identify risks associated with their
operations, and displays them via a dashboard. Such software can measure and monitor virtually
any kind of risk.
Here, Risk Management System (RMS) Software has been developed according to Risk
Register tools and technique.
4.2.2 Business Continuity Plan (BCP)
―Business continuity refers to the activities required to keep the organization running during a
period of displacement or interruption of normal operations‖ (SANS Institute, 2002). BCP
helps in continuing the business even after a disaster occurs.
Business has to stay active during the crisis; if it closes its operations even for a day or a
week, they are many chances that the organization will experience losses and will have to
shut down.
Moreover, legal issues can arise if the critical services are not provided to clients. This can
lead to bad reputation and many more legal problems for an organization in addition to
having the pain of being in the state of disaster. Hence an efficient BCP plan can be used to
actively run and maintain the business activities.
Business continuity plan (BCP) is the creation of a strategy through the recognition of threats
and risks facing a company, with an eye to ensure that personnel and assets are protected and
able to function in the event of a disaster. Business continuity planning involves defining
potential risks, determining how those risks will affect operations, implementing safeguards
and procedures designed to mitigate those risks, testing those procedures to ensure that they
23
work, and periodically reviewing the process to make sure that it is up to date.
4.2.3 Disaster Recovery Plan (DRP)
Disaster Recovery Plan is a plan designed to recover all the vital business processes during a
disaster with in a limited amount of time. This plan has all the procedures required to handle
the emergency situations. A disaster recovery process should have provable recovery
capability, and hence it provides the most efficient method to be adopted immediately after a
disaster occurs.
Mostly the DRP has technology oriented methodologies and concentrates on getting the
systems up as soon as possible, within a reasonable amount of time (RTO and RPO). RTO
and RPO are the recovery time objective and recovery point objective, which are the targets
of DRP.
―The most successful disaster recovery strategy is the one that will never be implemented;
therefore, risk avoidance is a critical element in the disaster recovery process‖ (Martin, 2002).
A disaster recovery plan (DRP) is a documented process or set of procedures to recover and
protect a business IT infrastructure in the event of a disaster. Such a plan, ordinarily
documented in written form, specifies procedures an organization is to follow in the event of
a disaster. It is "a comprehensive statement of consistent actions to be taken before, during
and after a disaster". The disaster could be natural, environmental or man-made. Man-made
disasters could be intentional (for example, an act of a terrorist) or unintentional (that is,
accidental, such as the breakage of a man-made dam).
In a changing financial system, it is hoped that this methodology could be used to support
core aspects of operational risk management, such as sound day to day operations, internal
controls, policies and procedures, knowledgeable people, and robust Business Continuity
Plan (BCP) and Disaster Recovery Plan (DRP).
Hence, to remain safe and have seamless business operation‘s continuity, organizations must
build a strong RMS software, business continuity and disaster recovery plan and strictly
implement it.
24
Chapter 5
Framework for Managing Operational Risk in Payment, Clearing and
Settlement Systems (PCSS)
This section focuses on the systemic aspect of operational risk in PCSS rather than on the
consequences of operational events for individual participants in PCSS. This systemic
perspective may, therefore, differ from that of a participant in a PCSS.
An approach is described that could be used to assess and manage operational risk in PCSS.
It follows the framework set up by the Bank for International Settlements (BIS) to address the
management of operational risk at individual financial institutions. PCSS are interconnected
networks. Each participant in a PCSS will have its own risk-management strategy and
practices that it has developed for its own internal risk management purposes. It is important
that the central operator of a PCSS sets clear standards that participants must meet to prevent
or limit the consequences of disruptions in their own operations.
In terms of the methodology that we propose, the model for managing operational risk in
PCSS involves defining, identifying, assessing and measuring, controlling and mitigating,
and monitoring operational risk. This methodology is recommended in virtually all recent
publications.
5.1 Defining Operational Risk in PCSS
Following is the approach taken by the BIS for individual financial institutions, operational
risk in PCSS is defined as follows: The risk resulting from inadequate or failed internal
processes, systems, human error, or from external events related to any element of
payment, clearing, and settlement systems. In describing the consequences of operational
risk in PCSS, the focus will be on the potential for financial instability when serious problems
arise in these systems. The focus of this definition on the causes of operational risk (these are
also called risk factors) is useful. It provides a direct link between the causes of operational
risk and consequences for PCSS and, therefore, for financial stability, rather than
emphasizing the multitude of operational events that are the symptoms of operational risk.
Many causes of operational disruptions are internal to one or more elements of PCSS
(participants, central operator). For example, systems problems at BACPS (Automated
Cheque Processing System) participant may alter the payment activity of other participants
and, thus, the payment system as a whole. Similarly, a problem caused by human error at the
central operator (Bangladesh Bank) might cause a lengthy BACPS settlement that disrupts
the payment activities of all participants. Conversely, a lengthy delay in BACPS settlement
could delay settlement of the RTGS (Real Time Gross Settlement).
Other operational risk factors that can contribute to financial instability may be external.
These could include natural disasters (earthquake, fire, and flood) at a participant, or operator
of a PCSS. The terrorist attacks of 11 September 2001 are an example of an external risk
25
factor that affected all elements of PCSS in the United States and many elements of the
financial infrastructure in Canada and abroad.
5.2 Identifying Operational Risk in PCSS
The definition of operational risk has already set out the risk factors for PCSS. The primary
focus of the operational risk management framework for PCSS is related to the effect of risk
on financial stability.
In identifying operational risk in PCSS, it helps to identify the risk factors that are most
important for preserving the smooth functioning of PCSS (e.g., key systems, processes, and
resources). This helps to set priorities when it comes to measuring, analyzing, and managing
operational risk as well as establishing contingency measures, such as business-continuity
plans, to deal with extreme events. This assessment can be made by operational experts in
PCSS who are aware of the most critical elements of processes, systems, and skills required
for successful operations. These experts may come from the operators of PCSS or from the
participants. These experts are also well-placed to consider how changes to business
procedures or functions may reduce the level of operational risk. An environmental scan can
help to identify potential changes in external risk factors that originate outside PCSS.
5.3 Assessing and Measuring Operational Risk in PCSS
We have already been identified primary operational risks in Payment, Clearing and
Settlement System (PCSS) in banking industry. This section has been focusing on assessing
and measuring operational risks on Hardware failure, Software failure, Network failure,
Process Error, Power failure, Missing Third party Support, Human error, Key person
missing risk, Poor maintenance. We collected data from January, 2017 to December, 2017
and analyzing on it.
Table 5.1: Risks data from January, 2017 to December, 2017
Types of Incidents Data of 12 Months % of Incidents
Hardware failure 5 18.52%
Software failure 4 14.81%
Network failure 6 22.22%
Process Error 2 7.41%
Power failure 5 18.52%
Missing Third party Support 1 3.70%
Human error 1 3.70%
Key person missing risk 2 7.41%
Poor maintenance 1 3.70%
Total Incidents 27 100.00%
26
Figure 5.1: Risks incidents data from January, 2017 to December, 2017
5.4 Controlling and Mitigating Operational Risks in PCSS
The following solutions have been developed to control and mitigate operational risks,
considering practical problems related to payment, clearing and settlement systems (PCSS) of
banking industry.
Risk Management System (RMS) Software
Business Continuity Plan (BCP) and
Disaster Recovery Plan (DRP)
A strong and well-structured Risk Management System (RMS) Software, Business
Continuity and Disaster Recovery Plan (BCP and DRP) would help an organization to tackle
unexpected events. Risk Management System (RMS) Software or any contingency plan
would not help in getting profits for business but would definitely help in preventing huge
losses. A disaster can occur at any time, and a business must be prepared for it.
If any components of Payment, Clearing and Settlement Systems (PCSS) shown abnormality
during normal business operation then it is suggested taking help through RMS software or
following BCP and DRP.
5.4.1 Risk Management System (RMS) Software
Risk Management System (RMS) Software has been developed according to Risk Register
Tools and Technique: The Risk Management System (RMS) software addresses following:
Taking input of various risks
List of identified Risks
Taking severity of Risks
Applying possible solutions to those risks and
Monitoring and updating Risk Categories
0
1
2
3
4
5
6
7
Nu
mb
er o
f In
cid
ents
Types of Incidents
27
RMS Software (Login Page)
RMS is online base software, therefore users of branches or head office‘s division can log on
to the software easily from their respective places. To login RMS software, user registration
is must.
Figure 5.2: RMS (Login Page)
RMS Software (Problem Creation Page)
Users can input problem type, specific problem, severity level and details of problem through
Problem creation or ticket issuing page. Users also create or issue ticket through this page.
Figure 5.3: RMS (Problem Creation Page)
28
RMS Software (Problem Description Page)
Problem originator sees Problem Description Page after issuing problem through RMS
software. This page confirms that problem has been issued.
Figure 5.4: RMS (Problem Description Page)
RMS Software (Request Received Dashboard Page)
Problem responders or solver can see the problem through their dashboard page and pick the
ticket.
Figure 5.5: RMS (Request Received Dashboard Page)
RMS Software (Replying Message after solving Problem)
After solving the problem, problem solver or responder reply problem status through RMS
software to problem initiator. As per replying message originator or initiator take decision
which steps to be taken to next.
29
Figure 5.6: RMS (Replying Message after solving Problem)
RMS Software (Risk Statistics Report Page)
Risk Statistics Report shows Risks category, No of Risk and Percentage. From this page
PCSS related official can be able to monitor and take decisions regarding various types of
risks.
Figure 5.7: RMS (Risk Statistics Report Page)
30
5.4.2 Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP)
Business continuity Planning (BCP) refers to maintaining business functions or quickly
resuming them in the event of a major disruption, whether caused by a fire, flood or
malicious attack by cybercriminals. A business continuity plan outlines procedures and
instructions an organization must follow in the face of such disasters; it covers business
processes, assets, human resources, business partners and more.
Disaster Recovery (DR) plan is the same as a business continuity plan, but a DR plan focuses
mainly on restoring an IT infrastructure and operations after a crisis. It's actually just one part
of a complete business continuity plan, as a BC plan looks at the continuity of the entire
organization. Both are very important and are often combined into a single document for
convenience.
A Disaster Recovery Plan (DRP) is a documented process or set of procedures to recover and
protect a business IT infrastructure in the event of a disaster. Such a plan, ordinarily
documented in written form, specifies procedures an organization is to follow in the event of
a disaster. It is "a comprehensive statement of consistent actions to be taken before, during
and after a disaster". The disaster could be natural, environmental or man-made. Man-made
disasters could be intentional (for example, an act of a terrorist) or unintentional.
Organizations' increasing dependency on information technology to run their operations, a
disaster recovery plan, increasingly associated with the recovery of information technology
data, assets, and facilities.
5.4.3 Introducing Business Continuity and Disaster Recovery Planning
It is important to have effective operation risk management and business continuity planning
frameworks in place. Business continuity planning assists in preventing, preparing for,
responding to, managing, and recovering from the impacts of an incident or disruptive event.
Business continuity planning is the part of Operation Risk Management (ORM). Payment
system faces a variety of risks. These may be externally and therefore largely out of the
immediate control or internally that arise at the operational (business process) level.
Business continuity planning should address the subset of operational risks where
environmental factors or poor operational controls raise the potential for loss of or damage to
payment operations (including people, information, infrastructure, and premises). With the
support of all staff, Payment Systems Department (PSD) should maintain a BCP and DRP
that the senior management and external counterparties will view as sound practice, and
31
which will play an important part in the overall approach to ORM. It is also advisable to
cover incidents of lower probability that have a catastrophic/major impact.
5.4.4 Importance of BCP and DRP for Payment, Clearing and Settlement Systems
(PCSS) operations
Developing a BCP and DRP is important for every business as it can limit damages;
minimize interruptions when things do not go according to plan. Payment‘s policy for
business continuity planning should be to:
• perform a business impact analysis, and develop mitigation strategies, which will ensure the
continuity of its business, operations and technology components in the event the existing
environment is unavailable.
• Develop and maintain a comprehensive business continuity and disaster recovery plan
(BCP/DRP) to ensure that essential/critical activities are recoverable.
• BCP and DRP should be developed in accordance with standards.
• Report the status of BCP and DRP annually to the senior management.
5.4.5 The BCP and DRP should be an integral part of the ORM framework and
developed to ensure that the following objectives are met
• Bank‘s interests are protected in terms of reputation, reporting and resource impact, and
impact on payment operations.
• Should an essential/critical activity, this activity is re-established within the designated
recovery period using the DRP; and
• BCP and DRP is an integral part of payment‘s day-to-day operations and that it is regularly
updated with ongoing staff training and testing.
5.4.6 Building Business Continuity Plan (BCP)
A Business Continuity and Disaster Recovery Plan are only as effective as its last update and
its last test. The document control should be assigned to a senior staff member who will be
responsible for its maintenance. Whenever the document is updated, the changes should be
noted as a revision and approved by the appropriate staff member. A list of key BCP contacts
should also be maintained. Version Control should be updated whenever the plan has been
modified so that changes can be tracked and monitored.
5.4.6.1 Process to Develop a Business Continuity Plan (BCP)
To develop the BCP, a six-step process is discussed as follows (each step is described in
more detail in the next section):
32
Step 1:
Document Business Activities and Critical Processes and
Systems
Step 2:
Undertake Business Impact Analysis
Step 3:
Develop Business Continuity Plan (BCP)
Step 4:
Implement Business Continuity Plan (BCP)
Step 5:
Training to Imbed into the Day-to-Day Operations of the
Payment, Clearing and Settlement Systems (PCSS)
Step 6:
Regular Testing and Updating
Figure 5.8: Steps to Develop a Business Continuity Plan (BCP)
Step 1: Document Business Activities and Critical Processes and Systems
The first step for Payment Systems Department (PSD) is to fully understand the activities,
processes and systems and identify the key risks that might impact on operations. Process
maps and process-flow analysis can be used along with existing procedure manuals to
understand payment, clearing and settlement operations. The risk champion/expert can
oversee this process to ensure a common understanding and consistency of approach and
terminology.
The key is to identify critical processes and systems and the time period when these processes
and systems are required. This will determine the criticality of each activity, process and
system in terms of the time period (minutes, hours or days). A table of essential/critical
systems should be developed and maintained by Payment Systems Department (an example
is provided as Table 5.2 below). It will set out the time period when each system is required,
the data that will be recovered from the back-up, and the location where the system can be
accessed should an incident occur.
33
Table 5.2: Payment Systems critical process/systems
Payment Systems Time Period
(minutes,
hours or days)
Data Back-up
(time and location)
Access
Location
(alternate site
or
data center)
Bangladesh Automated
Cheque Processing
System (BACPS)
00:01-12:00
(High Value
Payment)
00:01-12:30
(Regular Value
Payment)
-After every 30 minutes
-Data backup at
respective server, on-site
location and off-site
location
-On-site
location
-Off-site
location if
disaster occurs
Bangladesh Electronic
Fund Transfer Network
(BEFTN)
00:01-24:00 -After every 30 minutes
-Data backup at
respective server, on-site
location and off-site
location
-On-site
location
-Off-site
location if
disaster occurs
Bangladesh Real Time
Gross Settlement (BD-
RTGS)
00:01-16:00 -Integrated with bank‘s
Core Banking System
(CBS)
-Real time data backup
with on-site and off-site
database
-On-site
location
-Off-site
location if
disaster occurs
Step 2: Business Impact Analysis
The Business Impact Analysis (BIA) focuses on the effects or consequences of the
interruption to critical business functions and attempts to quantify the financial and non-
financial costs associated with a disaster. BIA, if done prior to the disaster or crisis, will help
the organization in having a smoother recovery process.
A business impact analysis will involve everyone responsible for PCSS operations, including
the more junior staff, as it helps to develop a risk understanding and a risk culture within
department. This can be done by convening workshops and brainstorming sessions for each
function. The consequences of adverse operational events in PCSS for financial instability are
extremely difficult to quantify. The judgment of operational experts can be helpful
in developing a consensus on values that can be used to create an index of ―financial
instability.‖
34
Persons, who are involved with operations, can measure the impact level of disruption on
payment systems. Data collection from different banks has been performed through surveying
and impact on financial instability for interruption in payment systems has been established
by applying Henry Garrett method.
The following section has been discussed in detail how to establish impact on financial
instability for interruption in payment systems by applying Henry Garrett method.
Step (A): Rank given by the respondents
The following table 5.3 counting how many respondents have given 1st to 5
th Ranks for each
payment systems. For example, 20 respondents have given rank 1 to PS-5 (Collapse whole
Payment Systems).
Table 5.3: Rank given by the respondents
Step (B): Calculating percent position and Garrett value
According to Garrett method, formula for calculating percent position=100 (Rij- 0.5)/ Nj
Rij= 1st, 2
nd, 3
rd, 4
th, 5
th Ranks
Nj= Total ranks given by the respondents=5 (Five)
Finding Garrett value for each percent position value from the Henry Garrett table. The result
is provided in the following table.
Table 5.4: Percent position and Garrett value
Step (C): Calculation of Garret score and ranking
(a) Multiply the Garret value of table 5.4 with the rank data given in table 5.3.
(b) After adding, we get total Garrett score for each payment systems.
(c) Each total score is divided by total number of respondents (in this case: 20) to determine
average score.
(d) To determine Rank, highest average score is given first rank and so on.
1st 2nd 3rd 4th 5th
PS-1 Electronic Fund Transfer 1 1 0 3 15
PS-2 Automated Cheque Processing Regular Value (RV) 0 2 4 14 0
PS-3 Automated Cheque Processing High Value (HV) 2 7 11 0 0
PS-4 Real Time Gross Settlement (RTGS) 1 12 3 1 3
PS-5 Collapse whole Payment Systems 20 0 0 0 0
PS No. Disruption on Payment SystemsRank given by the respondents
PS No. 100 ( Rij- 0.5)/ Nj Percent position Garrett Value
PS-1 100 (1 – 0.5)/ 5 10 75
PS-2 100 (2 – 0.5)/ 5 30 60
PS-3 100 (3 – 0.5)/ 5 50 50
PS-4 100 (4 – 0.5)/ 5 70 40
PS-5 100 (5 – 0.5)/ 5 90 24
35
Table 5.5: Calculation of Garret Score and Ranking
Table 5.6: Impact level/Rank after applying GARRETT ranking Method
Here, 1 meaning highest impact on financial stability and 5 means lowest impact on financial
stability. This scenario analysis allows assessing the consequences of extreme events that
have a very low likelihood of occurring, but has severe affect on financial stability. This is
useful to identify areas of risk and to develop appropriate contingency measures to manage
these types of events.
Determining Recovery Point Objectives (RPO) and Recovery Time Objectives (RTO)
A recovery point objective (RPO) is defined by business continuity planning. It is the
maximum targeted period in which data (transactions) might be lost from an IT service due to
a major incident.
Figure 5.9: RPO and RTO (a), (wikipedia).
1st * 75 2nd * 60 3rd * 50 4th * 40 5th * 24 Total Score Avg. Score=Total Score/20 Rank
PS-1 Electronic Fund Transfer 75 60 0 120 360 615 30.75 5
PS-2 Automated Cheque Processing Regular Value (RV) 0 120 200 460 0 780 39 4
PS-3 Automated Cheque Processing High Value (HV) 150 420 550 0 0 1120 56 2
PS-4 Real Time Gross Settlement (RTGS) 75 720 150 40 72 1057 52.85 3
PS-5 Collapse whole Payment Systems 1500 0 0 0 0 1500 75 1
PS No. Disruption on Payment SystemsRank given by the respondents
PS No. Disruption on Payment Systems Impact Level
PS-5 Collapse whole Payment Systems 1
PS-3 Automated Cheque Processing Systems-High Value (HV) 2
PS-4 Real Time Gross Settlement (RTGS) 3
PS-2 Automated Cheque Processing Systems-Regular Value (RV) 4
PS-1 Electronic Fund Transfer Network (EFTN) 5
36
The recovery time objective (RTO) is the targeted duration of time and a service level within
which a business process must be restored after a disaster (or disruption) in order to avoid
unacceptable consequences associated with a break in business continuity.
Figure 5.10: RPO and RTO (b), (wikipedia).
If software/database shows disturbance in live server then respective operation would be up
from on-site location server. RPO and RTO are described in below table for different
payment related operations.
Table 5.7: Data of RPO and RTO for Software/Database down (Recovery in on-site location)
Operations Name RPO RTO
(Minutes)
BACPS Any downtime from (00:01-24:00) 30 ±10
BEFTN Any downtime from (00:01-24:00) 30 ±10
RTGS Any downtime from (00:01-24:00) Integrated with Core
Banking System.
Therefore, no require
of database restoration
If whole system is shown disturbance in on-site location then respective operation would be
up from off-site location (DR site). RPO and RTO are described in below table for different
payment related operations.
Table 5.8: Data of RPO and RTO for Hardware down (Recovery in off-site location)
Operations Name RPO RTO
(Minutes)
BACPS Any downtime from (00:01-24:00) 60 ±20
BEFTN Any downtime from (00:01-24:00) 60 ±20
RTGS Any downtime from (00:01-24:00) 60 ±20
37
The following are the Typical Operational Risks in PCSS
• Infrastructure and technology failures covering computer systems, power,
telecommunications, data and physical records.
• Incidents where access to premises is denied, either through inaccessibility or building
damage.
• Dependencies on third party key service providers such as the central and/or
commercial banks, telecom and internet providers, and other outsourced operations.
• Human errors or failures through lack of resources, skills, training, policies,
procedures, delegations, code of conduct, and poor management.
• Failure to meet statutory, legal or contractual, human resources and other obligations
including management objectives and reporting obligations.
The following are the primary operational risks in Payment, Clearing and Settlement System
(PCSS) in banking industry:
Hardware failure, Software failure, Network failure, Process Error, Power failure,
Missing Third party Support, Human error, Key person missing risk, Poor
maintenance.
Step 3: Develop Business Continuity Plan (BCP)
We have analyzed different bank‘s Payment, Clearing and Settlement System (PCSS)
operations which are Bangladesh Automated Cheque Processing System (BACPS),
Bangladesh Electronic Fund Transfer Network (BEFTN), Bangladesh Real Time Gross
Settlement (BD-RTGS).
BCP and DRP covers operational risks considering the most common problems related with
our business. Network/Connectivity interruption, Software malfunctions, Hardware
malfunctions and Processing Error is mainly responsible for business disruption in
Payment, Clearing and Settlement System (PCSS).
In the following section, we have been discussing, analyzing common problems related to
PCSS and providing solution procedure and suggestions case-by-case basis to make an
effective Business Continuity Plan (BCP). The following flowchart has been proposed to
follow Business Continuity Plan (BCP).
38
START
Problem Identification
Find Solution in BCP
Is Solution Described
in BCP?
Update or Modify BCPSolve problem according to
BCP
END
YESNO
Figure 5.11: Flowchart to follow BCP
BCP for Network/Connectivity Interruption
Importance Network connectivity is the cornerstone of running a business. The value of
importance of Network Connectivity cannot be underestimated. In fact, it is the backbone of
an organization. It is therefore important for the businesses to adopt good network
connectivity in order to comfortably execute their daily business operations. Uninterrupted
Network connection is fundamental for smooth Payment related operations. Bank to bank
information is exchange through network connection. Network failure or down for a while in
a bank creates payment related complexities not only particular bank but in whole payment
system. We have discussed different Network connectivity related problem and give solution
procedure as well as suggestion case-by-case basis in the following table.
Case
No.
Problem Descriptions Solution Procedure
Case-1 No network connection among PCSS
servers of a bank (Intra bank network
disruption/failure among server).
Step-1: Communicate with Bank‘s
Network Team/Network vendor.
Network team/vendor will check all
the network issue thoroughly (e.g.
Router, switch, fiber cut etc). If
problem is not solved then follow
step-2.
Step-2: Payment related files (e.g.
39
Case
No.
Problem Descriptions Solution Procedure
xml, img, ecl files etc) transfer to
PBM server manually (PBM server is
most sensitive server among all
servers and acts as gateway between
participant and central operator-
Bangladesh Bank). For example,
Write files in the CD/DVD from the
PCSS servers‘ and paste into PBM
server.
Advice/Remarks: Sets of backup
CD/DVD to be kept at PSD Data
Centre (on-site location).
Case-2 No network connection between central
operator (Bangladesh Bank) & PCSS
Server of a bank (Inter Bank network
failure).
Step-1: Communicate with Bank‘s
Network Team/Network vendor.
Network team/vendor will check all
the network issue thoroughly (e.g.
Router, switch, fiber cut etc).
Network team will also communicate
with central operator (Bangladesh
Bank) to solve the problem. If
problem is not solved then follow
step-2.
Step-2: Communicate with central
operator/central bank (Central Bank
team) to send payment related files
manually. By taking permission from
central operator, Payment related
encrypted files write to CD/DVD
from PBM server and send to
Bangladesh Bank.
Step-3: Concerned department also
collected encrypted files by CD/DVD
from central operator and processed
in PCSS servers to clear and settle
payment of other financial intuitions.
40
Case
No.
Problem Descriptions Solution Procedure
Case-3 Bank‘s branch/unit is unable to connect
with PCSS Servers‘ through network
and unable to do payment related tasks.
Step-1: Communicate with Bank‘s
Network Team/Network vendor.
Network team/vendor will check all
the network issue thoroughly (e.g.
Router, switch, fiber cut etc). If
problem is not solved then follow
step-2.
Step-2: Go nearest branch along with
clearing instruments, which branch
has network connection with PCSS
servers then process clearing
instruments and participate in
payment systems. If problem is not
solved then follow step-3.
Step-3: Go to Bank‘s central payment
system department such as Payment
Systems Department-PSD (which
department coordinating PCSS
related works) along with clearing
instruments and participate in
payment systems. PSD can help
branch to participate in clearing
operation or at least can help in
inward operation. If problem is not
solved then follow Case-2 Solution
Procedure.
Case-4 Network devices crashed (e.g. Router,
Switch, Media converter etc) at the on
site location/primary Data Centre (DC).
Step-1: Inform bank‘s Network Team
regarding crashed network devices.
Network team/vendor will arrange to
replace crashed network
devices/equipments by compatible
backup equipments immediately. If
problem is not solved then follow
step-2 and step-3 of Case-2 Solution
Procedure.
Advice/Remarks: Sets of backup
networks equipments such as Router,
Switch etc. to be kept at PSD Data
Centre (on-site location).
41
BCP for Hardware Malfunctioning
A computer system is made up of combination of two components, which is hardware and
software. Both components are important and have its own functions and meaningful usages
in payment, clearing and settlement system. For PCSS operation primarily four servers have
been used which are PBM, BACPS, BEFTN and RTGS server. We have discussed various
Hardware related problems and give solution procedure as well as suggestion case-by-case
basis in the following table.
Case
No.
Problem Details Solution Procedure
Case-1 PCSS Live server is not working (e.g.
Server is not Turn On from Turn off
position).
Step-1: Up/Turn on onsite backup
PCSS server.
Step-2: Establishes network
connection between new Live PCSS
Server with central operator‘s
(Bangladesh Bank) Server.
Step-3: Do necessary configuration or
update immediately if needed for the
backup server now works as a main
server. If problem is not solved then
follow step-4.
Step-4: Up/Turn on off-site backup
PCSS server.
Advices/Remarks: backup server
must be kept at on-site location.
Case-2 Payments related files are lost in the
Live server.
Step-1: All files have to be
downloaded from central operator
(Bangladesh Bank).
Step-2: Files need to be identified,
segregate and restored at backup
server to make it operational. If it is
not possible to download files from
central operator then follow step-3.
Step-3: Files will be collected from
central operator end via media
devices such as CD or DVD etc.
42
Case
No.
Problem Details Solution Procedure
Case-3 USB Token Problem (Recommended
Hardware provided by Central
operator). License of USB Token has
been expired.
Step-1: A USB token is inserted at
PBM server to establish secure
connection between commercial/
schedule bank and central operator.
In that case/problem concerned
department will insert the backup
token at PBM server to run PCSS
operation without interruption.
Step-2: In the mean time, PSD needs
to take the locked token to
Bangladesh Bank for unlock/update
license.
Advices/Remarks: Always kept/
backup extra USB token devices to
avoid untoward situation.
Case-4 Branch cheque MICR scanner problem. Step-1: In case of MICR scanner
problem, branch will continue
outward operation through nearby
scanning point branch.
Step-2: Branch will immediately
communicate with PSD about faulty
MICR Scanner.
Step-3: PSD will check everything by
logging remote desktop.
Step-4: If faulty MICR Scanner is not
repairable by PSD then machine will
be sent to vendor. On the other hand,
PSD will send support MICR scanner
to branch for this interim period if
available.
BCP for Software Malfunctioning
A computer server will not work without installing the software required in order to make it
work. Since PCSS operation need different types software, which would mean that every
server will require different software to be installed to use it. Nowadays, almost all businesses
depend highly on transactions and processes that are done automatically with the use of high-
end computer software. The software effectiveness and efficiency are a must and should be
given top priority.
43
For PCSS operation different types software has been used. We have discussed various
Software related problems and give solution procedure as well as suggestion case-by-case
basis in the following table.
Case
No.
Problem Descriptions Solution Procedure
Case-1 PCSS Live servers‘ is showing error
(e.g. run time error, system crash,
database crash, application software
crash, system error) or disturbing.
Step-1: Check and restart all processes of
the server. If problem is not solved then
follow step-2.
Step-2: Immediately informed to
appropriate resource person and bring
him for support. For example,
Communicate with software vendor or
central bank team. If problem is not
solved then follow step-3.
Step-3: Up/Turn on on-site backup PCSS
server. If problem is not solved then
up/turn on off-site backup PCSS server.
Advices/Remarks: backup server must be
kept at on-site location.
Case-2 Update of PCSS server (Live &
Backup).
Step-1: The updated data will be restored
time to time in the backup server from
the backup media.
Step-2: PCSS servers‘ (Live & Backup)
need to be always updated as per time to
time according to Bangladesh Bank
instructions.
Case-3 Servers‘ performance is not up to
mark.
Step-1: Check and deleted or uninstalled
unnecessary files and software.
Step-2: Communicate with software
vendor for software modification/update.
Step-3: Replace old hardware and
installed updated hardware.
44
Case
No.
Problem Descriptions Solution Procedure
Case-4 Taking PCSS Data/database backup. Data of PCSS has been taken up to 4th
level backup, such as individual sever,
another server and backup site and in the
external hard disks drive.
So if any sever of PCSS down then we
can easily up server from the backup
servers or devices.
1st level back up: Data backup at
respective servers after every 30 minutes.
2nd
level back up: Auto data backup sent
to remote Server after every 30 minutes.
3rd
level back up: Auto data backup sent
to DR-Site Server after end of day
operation.
4th
level back up: Data backup taken in
two external hard disks every day after
end of day operation. One hard disk is
preserve at on-site location and another
one is preserve at off-site location.
Figure 5.12: Backup Site for Business Continuity, (wikipedia).
45
BCP for Processing Error
In Payment, Clearing and Settlement Systems, processing error meaning error such as
incorrect transaction, untimely transaction, settlement error, accounting error, not generating
payment related files, other bank payment files are not recognized by our server, branch
could not send dishonor/return file and BACPS software scanning problem.
Case No. Problem Descriptions Solution Procedure
Case-1 Settlement error, accounting error:
sometimes settlement and accounting
error have been occurred among
branches. Branch could not
understand how to rectify settlement
and accounting error if occurred.
Step-1: Currently organization has
accounting manual. Accounting
manual clearly explains how to settle
clearing type transaction. If branch
cannot understand settlement and
accounting procedure by reading
manual then follow step-2.
Step-2: Officials of Payment Systems
Department has clear understanding
regarding settlement and accounting
procedures. So branch can solve this
type of problem with the help of PSD
officials.
Note: After integration of PCSS and
Core Banking software, all
transactions are done automatically
without manual intervention. So in
some cases it is required to settle any
settlement or accounting error with
manual intervention.
Case-2 Incorrect/untimely transaction:
sometimes branch sent incorrect
transaction to other bank and do
untimely transaction. BACH has
specific time frame to present
instruments in clearing house.
Step-1: Now we have specific circular
to present payment instruments to
other bank in time frame.
Step-2: If any branch wants to present
instruments out of the time frame for
emergency purpose then permission is
needed from upper management with
proper explanation.
Step-3: If any incorrect transaction
occurred then that transaction will be
rectified with the help of PSD.
46
Case No. Problem Descriptions Solution Procedure
Note: PSD can identify error or
incorrect transaction and take proper
measure if branch doesn‘t informed to
PSD about error or incorrect
transaction.
Case-3 Outward payments files (ECL file)
are not generated in PBM server.
Step-1: .ECL is encrypted cheque
clearing file and said files are being
generated in PBM server. So check
and restart the whole process of PBM
server. If .ECL file is not generated
then follow step-2.
Step-2: Up on-site backup server and
monitor .ECl file is generated or not.
If problem is not solved then follow
step-3.
Step-3: Up PBM server of Disaster
Recovery (DR) site to generated .ECL
file.
Case-4 Inward payment files are not
recognized by PBM server.
Step-1: Collect inward payments files
from Bangladesh Bank‘s end.
Step-2: put inward files in backup
PBM server for testing purpose that
files are ok or not.
Step-3: If ok then put into live PBM
server.
Case-5 Branch payment operation interrupted
for network connectivity problem.
Step-1: For network connectivity
interruption, branch official will
continue outward clearing operation
from nearest scanning point branches.
Step-2: Inward clearing, EFT and
RTGS operation can be continued
from any branches. It is to be
mentioned here that in this case
branch officials need to log on to
BACH (BACPS and BEFTN) and
RTGS software with own user ID and
47
Case No. Problem Descriptions Solution Procedure
password.
Step-3: In case of network interruption
for so long that branch will miss
clearing cut off time then branch will
request PSD operational unit to
arrange to return/dishonor cheque. For
outward clearing, branch need to
continue this service through nearby
scanning point branches.
Case-6 Branch could not send return file to
respective bank in specific cut-off
time.
Step-1: In case of outward
return/dishonor (clearing) problem,
such as missing clearing cut off time,
branch will communicate with
Payment Systems Department (PSD).
Step-2: PSD will contact with
respective bank and request to stop
payment and return fund through EFT
or Payment Order (PO).
Step-3: After receiving fund from
other bank through EFT or PO, PSD
return said fund to their branch.
Case-7 BACPS software scanning problem
(branch cannot scan cheque to present
in clearing house).
Step-1: If there is any scanning
problem in BACPS software, then
branch will send outward clearing
instruments with Batch Control
Voucher (BCV) to major clearing
house branch zones.
Step-2: Major clearing house branches
zones will manually take all physical
instruments with separate BCVs to
Bangladesh Bank zonal offices with
accumulated cheque count and amount
at least 30 minutes before the clearing
cut-off time.
Step-3: Bangladesh Bank Bureau
Service will provide scanning facility
for the Bank.
48
Case No. Problem Descriptions Solution Procedure
Step-4: Major branches zones will
send the detailed data and files (xml,
image files given by Bangladesh
Bank) to PSD operational and
technical unit to update PBM (PCSS
server) accordingly.
BCP for Miscellaneous issue
Aside from what we have already mentioned (Network, Software, Hardware, Process), there
are so many other types of problems that obstruct daily business operation. We have
discussed miscellaneous problems related to PCSS and give solution procedure as well as
suggestion case-by-case basis in the following table.
Case
No.
Problem Details Solution Procedure
Case-1 People risk: No fallback plan for
responsible personnel. If any
employee absent for illness then
it will be difficult to run
operations and increase people
risk.
Fallback plan is a backup plan or
contingency strategy; an alternative which
can be used if something goes wrong with
the main plan.
Previously, no fallback was existed with
proper job explanation.
Currently, fallback plan is developed for
operational personnel. As a result if a
responsible official is absent from the work
then other respective backup person is able
to run the work. Therefore, it minimizes key
person risk or people risk.
Case-2 People risk: doing unauthorized
and fraud transaction.
Payments Systems transactions have been
performed and checked by following ways:
Step-1: Transactions have been checked at
branch level by maker and authorizer.
Step-2: Branch transactions have been
checked by Payment Systems Department
(PSD) by maker and authorizer.
Step-3: PSD‘s transactions also checked by
concerned department of Head Office by
49
Case
No.
Problem Details Solution Procedure
maker and authorizer.
Therefore, it is difficult to perform
unauthorized or fraud transactions by any
officials related with payment process.
Case-3 If natural events occurred such as
fire, theft etc.
If fire and theft occurred in primary site that
it is impossible to run regular operation with
primary site then it is possible to run
payments operation with backup
site/Disaster Recovery (DR) site.
Case-4 No backup technical personnel
for regular operation.
It is difficult to run PCSS operation with
only one technical person. Therefore, it is
suggested to recruit backup technical person
immediately.
Case-5 No separate department with
appropriate manpower to run
PCSS operation.
Previously, regular operation has been done
with the help of principal branch of the bank
which was creating complexities regarding
operation.
Since, PCSS related operation is more
sensitive it is suggested to establish separate
department with sufficient manpower.
Case-6 No arrangement for data backup
in portable devices, e.g., hard
disk drive.
Previously, data backup was taken in server
and no arrangement for portable devices. So
it was risks if server crash or go to down
position.
Presently, all important data is being taken
to portable hard disk drive and kept in on-
site and off-site location.
Case-7 MICR Scanner support to
branches.
MICR scanner is used to scan instruments to
present in clearing house.
Previously, organization has no spare/
additional scanner to support branches at the
time scanner problem.
Presently, bank has extra MICR scanner to
support branches when branches scanner do
not work.
On the other hand, PSD has proper
procedure/ arrangement to fix problematic
MICR scanner.
50
Case
No.
Problem Details Solution Procedure
Case-8 Power failure issue. In case of main power failure such as
electricity failure, there is 2nd level, 3rd
level, 4th
level power back up for PCSS
operation as on-line UPS, generator, IPS
respectively.
Advices/Remarks: In case of non-
functionality of any power back up, PSD
will contact immediately with concerned
division/ persons such as bank‘s common
service division.
Advices/Suggestion:
All required PCSS server installation documents, software, HSM backup etc. need to
be kept in secured location by PSD.
PSD will always concentrate on sending outward files in CD/DVDs in case of any
hazard within stipulated time frame.
1st level support & services should be ensured by the PSD.
Log book to be maintained by PSD and branches for support, service and
maintenance.
Necessary support devices / items to be stocked / procured / purchased for immediate
support by PSD and branches.
All required software must be pre-installed in the backup server.
If the discontinuity is related to PC / Printer / MICR scanner /UPS etc., the related
vendor support to be provided within warranty period. If the warranty period expires,
the related equipment to be sent to concerned divisions immediately.
Maintenance agreement between 3rd
party and organization should be updated before
the expiry period.
For any query regarding BACH and RTGS operation difficulties, branch officials are
asked to communicate with Payment Systems Department (PSD).
Contact details of resource persons need to be kept and contact with them (if required)
in case of emergency.
51
S/N Name Division Contact No.
1 ABC Commlink info Tech (software vendor)
2 XYZ Payment Systems Department (PSD)
3 PQR Information & Communication Technology
(ICT) Division
Step 4: Implement the Business Continuity Plan (BCP)
Once the BCP has been approved, the risk champion/expert or risk management unit can
oversee the implementation of the BCP and incorporate it into the wider ORM monitoring
and control policies and procedures. This will include raising awareness with external parties
to cover all activities external to payment systems of the BCP and ORM framework in order
that they understand their respective roles in maintaining business continuity. The risk
champion or risk management unit will be responsible for maintaining and ensuring
compliance with the requirements set out in the BCP.
Payment Systems Department (PSD) should also introduce the requirement that third party
providers have in BCP and this should be included in service level agreements. These third
parties would include the central bank, providers of telecommunication and banking services,
and relevant external IT providers.
Step 5: Training to imbed into the day-to-day operations of PCSS
Staff in Payment System Department (PSD) needs to understand its roles and responsibilities
in compliance with the BCP and wider ORM policies and procedures. They may also need to
take on additional responsibilities to introduce and maintain risk-reduction or mitigation
strategies for their respective area. The BCP should include a section on training with training
exercise/scenarios and the frequency of such training. Training should be managed by the risk
champion/expert or risk management unit and undertaken for all staff members. If Payment
System Department has an alternate/backup site, this can provide a valuable training facility
as regular testing at the alternate site can be integrated with the training program. For
example, it will enable staffs to become familiar with the alternate site and how operations
can be run while an incident or event occurs.
While it is normal to rely on experienced staff that are deemed expert to operations, this
process can broaden knowledge and experience in order to reduce key person risk. Moreover,
skilled staff may not be available when an incident or event occurs and other staff can be
called upon to provide the necessary backup in this situation. Some organizations have staff
permanently at the alternate site with staff that can be rotated. This both ensures familiarity,
and facilitates a quick start-up. It also allows continuity in the event that the primary site is
completely destroyed.
52
Step 6: Regular Testing and Updating
All persons involved, from the executives down through the on-site implementation team,
must review the plan at least annually‖ (Pitney Bowes, n.d., p. 3). Most important aspect
about this plan is that the plan should be verified under realistic conditions so that the plan
works for a disaster most appropriately in the real scenario.
The critical systems and processes of Payment, Clearing and Settlement Systems (PCSS)
should be tested annually and the BCP updated based on the results of each test and the need
for continual improvement. It is important each system and process be individually tested. It
is not recommended the BCP be tested as a whole as this may affect normal operations–
unless it is at the weekend. The testing could be done in conjunction with the testing of the
other systems such as the central bank‘s own BCP. An example of the maintenance and
testing of the BCP/DRP is shown in Table 5.7.
Table 5.9: BCP and DRP timeframe for maintenance and testing
Maintenance Timeframe
BCP and DRP documentation review and update six monthly
Technology recovery testing six monthly
Staff familiarity testing annually
Scenario testing annually
Full test annually
Maintaining the BCP requires an ongoing monitoring process to assess its effectiveness and
whether it is in accordance with the wider ORM policies and procedures. This is achieved
through a combination of ongoing monitoring activities and periodic testing including the
annual testing of the BCP. The BCP can be improved over time as experience develops,
particularly when there is a history of incidents or events and their impact in terms of
reputation, reporting and resource, or impact on PCSS operations.
All new business activities should be reported to the risk management unit during the
planning phase. Changes to existing procedures and systems, these will also be reported to
the risk management unit. No critical systems or new business activities should be put into
production until suitable recovery arrangements have been implemented and tested.
5.4.7 Building Disaster Recovery Plan (DRP)
Scope
The scope of this DR plan is limited to Network, Server and Software recovery. This is a
disaster recovery (DR) plan, not a daily problem resolution procedures document.
The Payment Systems Department (PSD) will provide the following information to Disaster
Recovery Team (DRT) or senior management:
Location of incident (e.g., primary site or disaster site).
53
Type of incident (e.g., fire, power problem, flood).
Summarize the damage (e.g., minimal, heavy, total destruction).
The PSD will contact the Disaster Recovery Team (DRT) and report that disasters
involving network operations, server related or software related have occurred.
The PSD and/or DRT will contact the senior management and report that a disaster
affecting normal operations has occurred.
Disaster declaration
The Senior Management Team, with input from the Payment Systems Department (PSD),
Disaster Recovery Team and IT Technical Support, is responsible for declaring a disaster and
activating disaster recovery plan. The Disaster Recovery Team will respond based on the
directives specified by senior management.
Notification
The Disaster Recovery Team (DRT) must be activated immediately in the following cases:
PBM system is down for one (1) or more hours.
BACPS system is down for Two (2) or more hours.
RTGS system is down for Two (2) or more hours.
BEFTN system is down for Five (5) or more hours.
Steps of Disaster Recovery Plan (DRP)
To build an effective Disaster Recovery Plan (DRP) following eight steps required. All steps
are explained in details.
Step 1:
Obtaining top management commitment
Step 2:
Establishing a planning committee
Step 3:
Performing a risk assessment
Step 4:
Establishing priorities for processing and
operations
Step 5:
Collecting Information
Step 6:
Organizing and documenting a written plan/
Building DR Plan
Step 7:
Testing the plan and procedures
Step 8:
Obtaining plan approval
Figure 5.13: Steps of Disaster Recovery Plan (DRP)
54
First: Obtaining top management commitment
For a disaster recovery plan to be successful, the central responsibility for the plan must
reside on top management. Management is responsible for coordinating the disaster recovery
plan and ensuring its effectiveness within the organization. It is also responsible for allocating
adequate time and resources required in the development of an effective plan. Resources that
management must allocate include both financial considerations and the effort of all
personnel involved. In this regard, top management has given their consent to build an
effective Disaster Recovery Plan (DRP).
Second: Establishing a planning committee
A planning committee is formed to oversee the development and implementation of the plan.
The planning committee includes representatives from concern functional areas of the bank.
The committee also defines the scope of the plan. Table 5.8 contains members of the
planning committee.
Table 5.10: Planning committee for DRP
S/N Name Division
1 ABC Head of Business Operation Division (BOD)
2 XYZ Head of Payment Systems Division (PSD)
3 PQR Head of Information & Communication Technology (ICT) Division
Third: Performing a risk assessment
The planning committee performs a risk analysis that includes a range of possible disasters,
including natural, technical threats. Each functional area of the organization is analyzed to
determine the potential consequence and impact associated with several disaster scenarios.
Traditionally, fire has posed the greatest threat to an organization. Intentional human
destruction, however, should also be considered. The planning committee also analyzes the
costs related to minimizing the potential exposures.
It is time to score and sort all of them, category by category, in terms of their likelihood and
impact. The scoring process approached by preparing a score sheet, as shown in Table 5.9,
that has the following keys:
Groups are the subcategories of the main risk category.
Risks are the individual risks under each group that can affect the business.
Likelihood is estimated on a scale from 0 to 10, with 0 being not probable and 10
highly probable. The likelihood that something happens has been considered from
taking previous year‘s data
Impact is estimated on a scale from 0 to 10, with 0 being no impact and 10 being an
impact that threatens the company‘s existence. Impact is highly sensitive to time of
day and day of the week.
55
Restoration Time is estimated on a scale from 1 to 10. A higher value would mean
longer restoration time.
Table 5.11: Risk assessment form
Likelihood Impact Restoration Time Score
Grouping Risk 0 – 10 0 – 10 1 – 10
Technical Disasters
Server down 5 5 6 150
Software down 5 4 4 80
Network down 6 6 5 180
Payment systems working under specified time frame. So payment systems have been
affected over time which is shown in the following Table 5.10.
Table 5.12: Affect on Service over time
Time Affect on Service
10:00-12:00 High Value automated cheque processing
12:00-12:30 Regular Value automated cheque processing
10:00-12:00 Real Time Gross Settlement (RTGS) payment systems
10:00-17:00 Electronic Fund Transfer (EFT) processing
Fourth: Establishing priorities for processing and operations
At this point, the critical needs of each department within the organization are evaluated in
order to prioritize them. Establishing priorities is important because no organization
possesses much operation simultaneously. A method used to determine the critical needs of a
department is to document all the functions performed by each department. Once the primary
functions have been identified, the operations and processes are then ranked in order of
priority: essential, important and non-essential.
In this case data collection from different banks has been performed through surveying and
priorities or rank for processing and operating payment operations from Disaster Recovery
(DR) site has been established by applying Henry Garrett method.
The following section has been discussed in detail how to establish priorities or rank for
processing and operating payment operations from Disaster Recovery (DR) site by applying
Henry Garrett method.
Step (A): Rank given by the respondents
The following table 5.13 counting how many respondents have given 1st to 8
th ranks for each
payment systems. For example, among the 20 respondents (from 11 banks), 16 respondents
have given rank 1 to PS-1 (Process and Send High value cheque files) and 6 respondents to
PS-5 (Process and Send RTGS files) etc.
56
Table 5.13: Rank given by the respondents
Step (B): Calculating percent position and Garrett value
According to Garrett method, formula for calculating percent position=100 (Rij- 0.5)/ Nj
Rij= 1st, 2
nd, 3
rd, 4
th, 5
th, 6
th, 7
th, 8
th ranks
Nj= Total ranks given by the respondents=8 (Eight)
Finding Garrett value for each percent position value from the Henry Garrett table. The result
is provided in the following table.
Table 5.14: Percent position and Garrett value
Step (C): Calculation of Garret score and ranking
(a) Multiply the Garret value of table 5.14 with the rank data given in table 5.13.
(b) After adding, we get total Garrett score for each payment systems.
(c) Each total score is divided by total number of respondents (in this case: 20) to determine
average score.
(d) To determine rank, highest average score is given first rank and so on.
Table 5.15: Calculation of Garret Score and Ranking
1st 2nd 3rd 4th 5th 6th 7th 8th
PS-1 BACPS Process and Send High value cheque files 16 2 0 0 2 0 0 0
PS-2 BACPS Process and Send Regular value cheque files 0 7 0 3 7 3 0 0
PS-3 BACPS Receive and process High value cheque files 2 1 10 0 7 0 0 0
PS-4 BACPS Receiving and process regular value cheque files 0 2 0 3 1 13 0 1
PS-5 RTGS Process and Send RTGS files 6 8 3 2 0 1 0 0
PS-6 RTGS Receive and process RTGS files 2 2 3 8 0 0 2 3
PS-7 BEFTN Receive and process Electronic Fund Transfer files 0 2 0 0 1 1 3 13
PS-8 BEFTN Process and send Electronic Fund Transfer files 0 1 3 2 0 0 13 1
PS No. Payment Systems Payments OperationsRank given by the respondents
PS No. 100 ( Rij- 0.5)/ Nj Percent Position Garrett Value
PS-1 100 (1 – 0.5)/ 8 6.25 80
PS-2 100 (2 – 0.5)/ 8 18.75 68
PS-3 100 (3 – 0.5)/ 8 31.25 60
PS-4 100 (4 – 0.5)/ 8 43.75 53
PS-5 100 (5 – 0.5)/ 8 56.25 47
PS-6 100 (6 – 0.5)/ 8 68.75 40
PS-7 100 (7 – 0.5)/ 8 81.25 32
PS-8 100 (8 – 0.5)/ 8 93.75 20
1st * 80 2nd * 68 3rd * 60 4th * 53 5th * 47 6th * 40 7th * 32 8th * 20 Total Score Avg. Score=Total Score/20 Rank
PS-1 BACPS Process and Send High value cheque files 1280 136 0 0 94 0 0 0 1510 75.5 1
PS-2 BACPS Process and Send Regular value cheque files 0 476 0 159 329 120 0 0 1084 54.2 4
PS-3 BACPS Receive and process High value cheque files 160 68 600 0 329 0 0 0 1157 57.85 3
PS-4 BACPS Receiving and process regular value cheque files 0 136 0 159 47 520 0 20 882 44.1 6
PS-5 RTGS Process and Send RTGS files 480 544 180 106 0 40 0 0 1350 67.5 2
PS-6 RTGS Receive and process RTGS files 160 136 180 424 0 0 64 60 1024 51.2 5
PS-7 BEFTN Receive and process Electronic Fund Transfer files 0 136 0 0 47 40 96 260 579 28.95 8
PS-8 BEFTN Process and send Electronic Fund Transfer files 0 68 180 106 0 0 416 20 790 39.5 7
PS No. Payment Systems Payments OperationsRank given by the respondents
57
Here, PS-1 (Process and Send High value cheque files) got the 1st rank, followed by PS-5
(Process and Send RTGS files), PS-3, PS-2,PS-6, PS-4, PS-8, PS-7 got 2nd
, 3rd
, 4th
, 5th
, 6th
,
7th
, 8th
ranks respectively.
Table 5.16: Rank/ Priorities after applying GARRET ranking method
If it is needed to operate clearing operations (e.g. BACPS, BEFTN, RTGS) from Disaster
Recovery (DR) site then give highest priority to activate payment system PS-1 (Process and
Send High value cheque files) and give lowest priority to activate PS-7 (Receive and process
Electronic Fund Transfer files).
Fifth: Collecting Information
In this phase, data collection takes place. Among the recommended data gathering materials
and documentation often included are various lists such as employee position listing, critical
telephone numbers list, vendor list, data center, server, computer hardware, microcomputer
hardware and software, off-site storage location, software and data files backup/retention
schedules etc.
List of Server at Disaster site
Server Name Location
PBM backup server Dhaka
BACPS backup server Dhaka
BEFTN backup server Dhaka
RTGS backup server Dhaka
Emergency notification contacts
Name Address Mobile/Cell Phone
DR execution Team Leader Dhaka 01715-xxxxxxx
Network Recovery Team Leader Dhaka 01725-xxxxxxx
Server/Hardware Recovery Team Leader Dhaka 01735-xxxxxxx
Software Recovery Team Leader Dhaka 01745-xxxxxxx
Software vendor (Commlink infotech) Dhaka 01815-xxxxxxx
PS No. Payment Systems Payments Operations Rank/ Priority
PS-1 BACPS Process and Send High value cheque files 1
PS-5 RTGS Process and Send RTGS files 2
PS-3 BACPS Receive and process High value cheque files 3
PS-2 BACPS Process and Send Regular value cheque files 4
PS-6 RTGS Receive and process RTGS files 5
PS-4 BACPS Receiving and process regular value cheque files 6
PS-8 BEFTN Process and send Electronic Fund Transfer files 7
PS-7 BEFTN Receive and process Electronic Fund Transfer files 8
58
Server and computer equipment suppliers
Company Name Work Contact
xxx Network equipments supplier 01725-xxxxxx
yyy Server/Hardware supplier 01725-xxxxxx
Sixth: Organizing and documenting a written plan/Building DR Plan
The following procedures or recovery steps are to be followed by DR execution team leader,
and network recovery, server recovery and software recovery team leader in the event of a
disruption or related outage. Where uncertainty exists in case of important system, the more
reactive action should be followed to provide maximum protection. These procedures are
furnished from practical point view.
START
Taking approval from Concern
Management to Activate Disaster
Recovery (DR) Site
Start and check all process servers and
services
Network or Server or Software
Problem?
END
YES
Restore backup database and update all
process or software if required into DR
site servers
Inform all branch/centre to process
files
Files send/upload to central bank/
operator
Files receive/downloaded from central
bank/operator
Establish Inter and Intra Network
connection
NO
Contact with Network or Server or
Software vendor and repeat whole steps
Figure 5.14: Flowchart to Activate Disaster Recovery (DR) site
59
Table 5.17: Emergency response activities and Disaster Recovery Teams
SN. Action Who Performs
1. Decision to invoke or initiate DR plan Senior Management consulting with
concerned department
2. Identify and assess network outage Network Recovery Team Leader
3. Server malfunctions Server/Hardware Recovery Team Leader
4. Software malfunctions Software Recovery Team Leader
DR Execution Team
Leader
Server Recovery
Team Leader
Software Recovery
Team Leader
Network Recovery
Team Leader
1st Contact Name
2nd Contact Name
1st Contact Name
2nd Contact Name
1st Contact Name
2nd Contact Name
Payment Systems
Department (PSD)
Senior Management
Network, Server,
Software Vendors
Figure 5.15: Disaster Recovery Teams
Payment Systems Department (PSD)
PSD is responsible for overall coordination of the disaster recovery effort, evaluation and
determining disaster declaration and communication with senior management.
Support activities:
The Payment Systems Department (PSD):
Evaluates which recovery actions should be invoked and coordinate with the
corresponding recovery teams.
Analyzes damage assessment findings.
Provides ongoing status information to senior management.
Work with DR execution team leader and vendors to develop a rebuild/repair schedule.
Disaster Recovery Team (DRT)
Disaster Recovery Team (DRT) is responsible for overall coordination of the disaster
recovery effort. Communicate with senior management, the Payment Systems Department
(PSD), and vendors.
Support activities:
Coordinate with Payment Systems Department, senior management and vendors.
Facilitate recovery and restoration activities.
60
Determine all recovery needs.
If disaster is declared, take appropriate action to return to normal operations with all
concerned members.
Providing guidance on replacement equipment, systems and services, as required.
Coordinate testing of operations to ensure the all is function normally.
Prepare post-disaster report.
Coordinate the development of revised recovery plans and ensure they are updated.
Steps of Network Disaster Recovery
For the following cases, it is may be needed to activate Network Disaster Recovery Planning
which are natural disaster, fire, network services provider outage, flood or water damage in
the primary or Data Centre (DC). In the event of said cases, the following guidelines and
procedures are to be followed.
Step Action
Step-1 DR Execution Team Leader will notify Network Recovery Team Leader or
Network Team.
Step-2 Concern teams will check disaster site network devices such as Router, Switch,
Media Converter, Power status etc.
Step-3 Establishes network connection with all the server
Step-4 With the help of network team establish intra server network connectivity.
Step-5 Establish inter network connectivity between bank‘s PCSS server and central
operator (Bangladesh Bank) server.
Step-6 Sent small amount of outward files to Bangladesh Bank server for testing
purpose. If successful then start full operation.
Step-7 After taking all measure if connectivity problem is not solved then Network
Recovery Team will contact bank‘s Network vendors to aid regarding the
recovery and resumption of network services.
Advices It must be ensured to keep all network devices in Disaster Recovery (DR) site
with proper configuration before any disaster occurs.
Steps of Hardware/Server Disaster Recovery
Step Action
Step-1 DR Execution Team Leader will notify Server Recovery Team Leader.
Step-2 Server Recovery Team will start and check all backup PCSS server such as PBM
server, BACPS server, BEFTN server, RTGS server.
Step-3 Hardware components of all server will be checked such as Hard disk drive,
RAM, processor, etc.
Step-4 PSD will check whether outward and inward files are processed or not.
Step-5 After taking all measure if Server/hardware shows any problem then contact with
hardware vendors to solve problems.
61
Steps of Software Disaster Recovery
Step Action
Step-1 DR Execution Team Leader will notify Software Recovery Team Leader.
Step-2 Software Recovery Team will check installed software in servers.
Step-3 Update software (Operating System-OS, Database) in case of necessary.
Step-4 PSD will check whether outward files are generated or not.
Step-5 After taking all measure if software shows problem then contact with software
vendors through software recovery team.
Seventh: Testing the plan and procedures
The DR plan is tested for the following reasons:
Determining the feasibility and compatibility of the DR plan.
Modification of the plan has been done where it needs.
Providing training to the team leader and team members.
Demonstrating the ability of the organization to recover.
Providing motivation for maintaining and updating the disaster recovery plan.
The DR plan should be tested and evaluated on a regular basis (at least annually) and based
on the results of each test and the need for continual improvement. It is important each
system and process be individually tested. The testing could be done in conjunction with the
testing of the other systems such as the central bank‘s own DR Plan. The proposed DR plan
has been tested. Testing such as checklist tests and full interruption tests has been done.
Eighth: Obtaining plan approval
It is top management‘s ultimate responsibility that the organization has a documented and
tested plan. Proposed Disaster Recovery plan has been written and tested; the plan is then
submitted before the management and concerned management approved it.
Miscellaneous Discussion/Advices:
Key people (DR Execution team leader, Recovery team leader and members) will be
available following a disaster.
This plan and critical documents are stored in a secure off-site location and not only
survived the disaster but are accessible immediately following a disaster.
Other IT departments and support organizations will have their own DR plans.
Backup policy: Full and incremental backups of database and network information
should be performed on a regular basis. Backup media should be stored in a secure and
geographically separate location from the original and isolated from environmental
hazards. Backup network components, cabling and connectors, power supplies, spare
parts and relevant documentation should be stored in a secure area on-site as well as at
other corporate locations.
Off-site storage procedures:
A copy of the most current network and system databases must be made regularly.
62
These backups must be stored offsite.
Disks and other suitable media are stored in environmentally secure facilities.
Access to backup databases and other data is tested regularly.
The network recovery and software recovery team leader are responsible for this
activity.
5.5 Monitoring operational risk in PCSS
PCSS are more and more dependent on information systems. Technologically effective, up-
to- date, and user-friendly management information systems (MIS) are necessary so that
systematic, comprehensive, objective, timely, and accurate information related to operational
risk can be generated, analyzed, summarized, and reported. The building of databases on
operational events should be a priority.
Risks are easier to detect by building a database with a history of operational events,
changing sources of operational. The judgment of experts in the field will always remain
important for assessing operational risk, particularly for extreme events that occur
infrequently (or may not yet have occurred). As changes occur in the financial environment
as technological innovations continue, and the complexity of financial instruments and PCSS
also increasing day by day. By monitoring these changes using data from the database and by
projecting future changes, one can assess the effect that the changes will have on the
Payment, Clearing and Settlement Systems.
63
Chapter 6
Results and Discussions
6.1 Benefits/Advantages of BCP & DRP using as Controlling and Mitigating Technique
for PCSS
We have proposed a well documented Business Continuity Plan (BCP) and Disaster
Recovery Plan (DRP). If any components of Payment, Clearing and Settlement system
(PCSS) shown abnormality during normal business operation then it is suggested to follow
BCP and DRP. We have practically applied BCP most of the cases and DRP some cases
where elements of Payment, Clearing and Settlement systems (PCSS) had deviated from
normal business operation. We have discussed in the following table case-by-case basis how
BCP and DRP minimize operational risk in PCSS and improve regular operation.
BCP and DRP have been developed, considering practical problems related to regular
payment, clearing and settlement system of banking industry. We have been following and
applying BCP and DRP when operation shows abnormality, from January, 2018 and get the
following good results and benefits.
6.1.1 Advantages of BCP and DRP in case of Network/Connectivity Interruption
Case
No.
Problem Descriptions Previous status (without
BCP and DRP)
Present Status
(after introducing
BCP and DRP)
Case-1
Permanent Connectivity
failure between central
bank and Bank‘s PCSS
Server (Inter
connectivity disruption).
In previous incident, bank
was no policy how to send
files manually to central bank
in case of connectivity failure
between central bank and
particular bank. As a result
bank was fall in huge
financial and reputational
losses.
In BCP it is
described in detail
how to write files in
CDs/DVDs from
PBM server and
send manually to
central bank.
By this way it is
possible to avoid
untoward situation
and save the bank
form significant
financial losses
Case-2 No network connection
among PCSS servers‘ of
a bank (Intra
connectivity failure).
No arrangement for media
devices to avoid operational
haphazard.
Described problem
has been solved by
transferring files
among server using
CDs/DVDs. How to
64
Case
No.
Problem Descriptions Previous status (without
BCP and DRP)
Present Status
(after introducing
BCP and DRP)
transfer files among
server has been
described in BCP.
Case-3 Bank‘s branches users
are unable to connect
with PCSS servers‘
through network and
unable to do payment
related tasks with other
bank.
Before, bank‘s branches failed
to participate and present
clearing instruments to other
bank through central bank as
they had no clear policy how
to work with nearest branches
as a result branches were fall
in financial loss.
BCP clearly
describes how to
present clearing
instruments or
electronic files to the
clearing house
through their nearest
branches or Payment
System Department
(PSD).
Presently, branches
are able to
participate and send
files to central
clearing house if
individual bank‘s
branch has no
network connection.
Case-4 Network devices
crashed (e.g. Router,
Switch, Media converter
etc).
Before, bank suffers a lot for
not having extra network
devices if network devices
had been crashed.
In BCP it is
recommended to
keep extra network
devices with proper
configuration to
avoid connectivity
problem.
Currently, extra
network devices
have been kept at
on-site and off-site
location. For
example, Network
device Router has
been kept at on-site
location with proper
configuration.
Therefore, if live
65
Case
No.
Problem Descriptions Previous status (without
BCP and DRP)
Present Status
(after introducing
BCP and DRP)
Router shows any
problem we can
replace it with
backup Router.
6.1.2 Advantages of BCP and DRP in case of Software Malfunctioning
Case
No.
Problem Details Previous Status (without
BCP and DRP)
Present Status
(after introducing
BCP and DRP)
Case-1 PCSS Live server is
showing error (e.g. run time
error, system crash,
database crash, application
software crash) or
disturbing.
In previous occasions,
operation had been
hampered due lack of
proper guidelines.
Primary solution
steps and procedure
have been described
in BCP. So person
who has general
knowledge about the
server can solve the
problem.
List of Resource
personnel (such as
software vendor and
central banks
operator) has been
attached with their
specific jobs to
contact in case of
server failure. These
steps reduce risk of
operation being
hampered.
Case-2 Backup server is not up to
date.
No policy had exist to
update backup sever from
time to time according to
operational requirements.
PCSS backup server
is now updated
according to policy.
So if live server fall/
down then it is easy
to replace with
backup updated
server.
66
Case
No.
Problem Details Previous Status (without
BCP and DRP)
Present Status
(after introducing
BCP and DRP)
Case-3 PCSS Server performance is
not up to mark.
Regular PCSS operation
had been hampered for
slowness of server.
According to BCP,
we had updated
PCSS software from
time to time
communicating with
our software vendor
and installed up to
date hardware.
Case-4 Update of common/general
server-Presenting Bank
Module (PBM) related to
PCSS server (Live & Back
Up)
One of most sensitive
server of PCSS operation
is PBM server. But this
server was not updated as
per central bank
guidelines.
PBM servers (Live
and backup) are now
updated as per
central bank‘s
instructions.
So if live PBM
server down then it
is easy to run regular
operation from
backup PBM server.
6.1.3 Advantages of BCP and DRP in case of Hardware Malfunctioning
Case
No.
Problem Details Previous Status
(without BCP and
DRP)
Present Status (after
introducing BCP and
DRP)
Case-1 PCSS Live server is not
working (e.g. Server is not
turning on from turning off
position).
Previously, we are
waiting for new server
to be configured as a
result daily operation
hampered drastically
and organization fall in
huge financial losses.
As per BCP, backup
server is standby ready
with proper
configuration in on-site
location and disaster
recovery (off- site
location) site. So we
can easily run regular
operation if our PCSS
Live server is not
working.
Case-2 Payments related files are
lost in the Live server.
Previously, we have no
proper procedure how
to collect payments
Now we have
procedural steps how to
collect, categorize and
67
Case
No.
Problem Details Previous Status
(without BCP and
DRP)
Present Status (after
introducing BCP and
DRP)
related files and how to
segregate/categorize
files and input into
database.
restore payments
related files in the live
server. This plan saves
huge amount of times
while operation.
Case-3 USB Token (required to
connect with Bangladesh
Bank) Problem
(Recommended Hardware
provided by Central
operator).
USB token is used to
verify authenticity of
network connection
between banks and
operator (Bangladesh
Bank).
Previously, regular
operation had been
performed with only
token. So It was risky
in case of failure.
Currently, backup USB
token with updated
configuration has been
kept to use in case of
failure in first one.
6.1.4 Advantages of BCP and DRP in case of Miscellaneous Problems
Case
No.
Problem Details Previous Status
(without BCP and
DRP)
Present Status (after
introducing BCP and
DRP)
Case-1 Lack of technical backup
personnel for regular
operation.
Previously, regular
operation has been
done with only one
technical person.
Presently, one technical
backup personnel has
been recruited. Hence,
this approach mitigated
risk related to missing
key person risk.
Case-2 Separate department with
appropriate manpower.
Previously, regular
operation has been
done with the help of
principal branch of the
bank which was
creating complexities
regarding smooth
operation.
Presently, separate
department (e.g.,
Payment Systems
Department) has been
established with
sufficient manpower.
Hence, payment related
all operation has been
done smoothly without
difficulties.
Case-3 PCSS data backup. Previously, there was Presently, data of PCSS
68
Case
No.
Problem Details Previous Status
(without BCP and
DRP)
Present Status (after
introducing BCP and
DRP)
no proper plan
regarding data backup
and data restore. So at
the time of database
problem it was taking
much time to restore
database because lack
of proper procedure
how to take data
backup and data
restore.
has been taken back up
data for 4th
level such
individual sever,
another server and
backup site and in the
external hard disk.
So if any server of
PCSS down then we
can easily restore
database from the
backup devices.
Case-4 Data backup to portable hard
disk drive.
In past no arrangement
exist to keep data
backup in portable hard
disk drive and keep that
drive in outside of the
data centre.
All PCSS operational
related data is kept in
portable hard disk drive
along with individual
server and that drive
retain in outside of data
centre.
So if any natural
disaster occurred (e.g.;
earthquake, flood, fire)
then it is possible to
ready all PCSS related
server from said
portable hard disk
drive.
Case-5 MICR Scanner support to
branches in case of problem
in MICR scanner.
MICR scanner is used
to scan instruments/
cheque to present in the
clearing house.
In the past, bank has no
proper plan to support
branches providing
MICR scanner in case
of disturbance in
scanner machine and to
keep extra scanner in
concerned department
for support purpose.
Presently, bank has
extra MICR scanner to
support branches when
branches scanner
shows disturbance. On the other hand, PSD
has proper procedure/
arrangement to fix
problematic MICR
scanner.
69
Case
No.
Problem Details Previous Status
(without BCP and
DRP)
Present Status (after
introducing BCP and
DRP)
Case-6 Branch Connectivity
Interruption.
Previously, branch was
unable to participate in
clearing house by going
to nearest branch or
through PSD.
According to BCP
policy, branch can
participate in regular
clearing house by going
to nearest branch or by
the PSD.
PSD can help to branch
in clearing operation or
at least able to help in
inward operation.
Case-7 Power failure issue. Previously, no proper
power backup plan was
exist.
In case of primary
power failure, there is
2nd
level, 3rd
level, and
4th level power backup
to continue operation.
Backup power supports
are On-line UPS,
Generator, IPS
respectively.
6.1.5 Benefits/Advantages of BCP and DRP using as controlling and mitigating
technique (Summary)
Types of Incidents Present Status (after introducing BCP and
DRP)
Hardware Malfunctions It is no possible to tackle or avoid all hardware
related problems. But we can control or minimize
it to an acceptance level. So that at least we can
run our daily business operation without
hampering whole payment system while
hardware malfunctions.
Since, as per BCP and DRP, backup had been
taken of all important hardware devices as a
result we are in a position to minimize the risks
related to hardware malfunctions at an acceptable
level.
For example: From January, 2018 four hardware
related disasters had occurred in PCSS operation.
In BCP and DRP it is clearly defined how to
70
Types of Incidents Present Status (after introducing BCP and
DRP)
recover from disaster case-by-case basis and
continue daily operations. We had taken measures
according to BCP/DRP and within shortest time
period our daily operations had been resumed.
First version of Payment, Clearing and Settlement
Systems (BACPS and BEFTN) of Bangladesh
banking industry inaugurated on 07 October,
2010. One of the sophisticated sever of PCSS is
PBM sever. Now life time of this server had
already been expired. We could not
change/update mentioned server because this
server support old version of operating system
(OS). For example it is support 2003 OS and
2005 SQL server. Hardware/Server which
support old version of OS and database is totally
market out. By following BCP/DRP, we had
collected old version of server from our old stock
and using at the time of emergency period. So
risks related to sophisticated server minimizes to
an acceptable level. Hardware related problems
would be reduced to minimum level when second
version of Payment, Clearing and Settlement
Systems (BACPS and BEFTN) will be introduced
in coming month because in second version we
will be able to install state-of-the-art server.
Although hardware related problems is not
decreased significantly in current year but we are
in a position to run/continue the PCSS operation
more confidently and smoothly than previous
years.
Software Malfunctions Software of all PCSS server except PBM has
been updated according to suggestion given by
BCP/DRP. We are not in a position to update
PBM server without proper instructions of central
bank. PBM server software problem will be
solved in coming month by inaugurating new
version of PCSS operation. Software had been
updated by communicating with third party.
If PBM server software shows problem then we
run regular operation by backup server following
71
Types of Incidents Present Status (after introducing BCP and
DRP)
BCP and DRP.
Therefore, this way software related malfunctions
has been reduced or minimized to an acceptable
level.
Network/Connectivity Interruption Backup/redundant network connection has been
established. So network interruption, for example
fiber cut has been mitigated.
On the other hand, network devices such as
Router, switch etc with proper configurations has
been kept at on-site location and off-site location.
Hence, Network related interruption has been
reduced or minimized by taking various steps
described in BCP and DRP.
Power failure Power failure has been solved by taking
redundancy power backup such as IPS, online
UPS, generator etc.
Human error (which may be due
to poor training or inadequate
supervision)
In BCP, it is suggested to arrange training on
regular basis to increase efficiency and skills of
concern staff/officials.
Currently, regular training has been arranged by
organization training institute. So gradually
human related error will be reduced.
Key person missing risk (which may
lead to human error when key person
is absent)
Now experienced person has been recruited for
backup purpose. This measure reduced key
person missing risk significantly.
6.2 Benefits of Risk Management System (RMS) Software
The following benefits or advantages have been attained from RMS software.
Comprehensive: List of all risks has been included in RMS software. Users can input their
problem or risk from the given list.
Easy Access: RMS is online base software. So users can access from any branch or head
office.
Fast: users get service faster regarding PCSS problem.
Easy to Use: RMS software is easy to use. Basic computer knowledge is required to operate.
Reliable: Since it is controlled by responsible officials therefore it is reliable.
72
Reusable: To develop modified or update version of RMS software, current software may be
used.
Faster Feedback: Users get fast feedback from problem responder or solver.
Easy update/Programmable: RMS software is updateable according to user‘s information.
Forecasting: Using RMS software database, it is easy to take decision regarding future risks
exposure.
Table 6.1: Risks data variation between 2018 and 2017
Types of
Incidents/Risks
Data
Jan
to
Dec-
2018
Data Jan
to Dec-
2017
Data variation
between 2018 &
2017
Percentage of
data variation
between 2018 &
2017
Remarks
Hardware failure 4 5 (1) -20.00% Reduced
Software failure 2 4 (2) -50.00% Reduced
Network failure 3 6 (3) -50.00% Reduced
Data corruption 1 2 (1) -50.00% Reduced
Power failure 3 5 (2) -40.00% Reduced
Missing Third
party Support
1 1 0 0.00% No
Change
Human error 1 1 0 0.00% No
Change
Key person
missing risk
0 2 (2) -100.00% Reduced
Poor maintenance 1 1 0 0.00% No
Change
Total Incidents 16 27 (11) (40.74%) Reduced
Figure 6.1: Risks Data variation between year, 2017 and 2018
0
1
2
3
4
5
6
7
Nu
mb
er
of
Inci
de
nts
Types of Incidents
2017
2018
73
Chapter 7
Conclusions and Recommendations
7.1 Conclusions
Awareness of operational risk in PCSS is growing significantly. As PCSS become more
interconnected, successful management of operational risk is more important and more
complex.
Putting in place an Operational Risk Management (ORM) framework including RMS
software, BCP and DRP should be seen as a priority for any PCSS operation. The
development of RMS software, BCP and DRP should not be seen as a one-off project but
consider as an integral part of the day-to-day operations.
The framework described above provides a way in which operational risk in PCSS could be
assessed and managed. PCSS in Bangladesh is controlled by the central bank. Thus, it is their
responsibility to ensure that participants are managing it effectively.
In addition to its oversight responsibility of central bank, the Bank may be asked to provide
operational assistance to PCSS or their participants in the event of severe operational
disruptions. It is important that participants and the operators of these systems have effective
operational risk-management standards and practices that prevent excessive reliance on the
bank for operational assistance. At the same time, in the case of extreme events there is a
need for coordination among the banks and other key elements of PCSS.
The framework described in this paper could provide a unified and systemic perspective on
operational risk in PCSS that could promotes financial stability.
7.2 Recommendations
Based on the summary and conclusion of this study, the following recommendations were
made for efficient and quality service for Payment, clearing and settlement system:
It is advisable that a ―risk champion‖ to be appointed to take overall responsibility for
Operational Risks Management (ORM). The risk champion will lead and guide the
process, coordinate reporting to the senior management, and develop the appropriate
ORM policies and procedures and control environment. Ideally, the risk champion
would have relevant background or experience.
If it is not possible to appoint risk champion. There are, however, opportunities for
professional training in ORM and business continuity planning which could be
considered.
It is recommended for testing, practicing, monitoring, coordinating and assessing the
appropriateness of the plans of Business continuity and Disaster Recovery plan (BCP
and DRP).
74
References
Acharyya, M. (2010). The role of operational risk and strategic risk in the enterprise
risk management framework of financial services firms. Int. J. Services
Sciences, vol. 3, pp. 79-102.
Barbara, M. (2006). Determining the Critical Success Factors of an effective
Business Continuity / Disaster Recovery Program in a Post 9/11 World: a
Multi- Method Approach, MBA Thesis, Concordia University.
Bandyopadhyay, K. ( 2001), The role of business impact analysis and testing in
disaster recovery planning by health maintenance organizations, Hospital
Topics. Vol. 1, pp. 79.
Bangladesh Bank, Payment Systems Division (2010). Bangladesh Automated Cheque
Processing System (BACPS) Operating Rules and Procedures. pp. 12-15.
Bangladesh Bank, Payment Systems Division (2014).Bangladesh Payment and
Settlement Systems Regulation. pp. 1-16
Bangladesh Bank, Payment Systems Division (2015). Bangladesh Real Time Gross
Settlement (BD-RTGS) System Rules. pp. 1-47.
Bangladesh Bank, Payment Systems Division (2010). Bangladesh Electronic Fund
Transfer Network (BEFTN) Operating Rules. pp. 9-12.
Bangladesh Bank, Payment Systems Division (2010). An Overview on Bangladesh
Automated Clearing House (BACH. pp. 2-6.
Bangladesh Bank, Payment Systems Division (2010). Bangladesh Automated
Cheque Processing System (BACPS) Operating Procedures. pp. 8-19.
Bangladesh Bank, Payment Systems Division (2014). Regulations on Electronic
Fund Transfer. vol. 2, pp. 5-10.
Bangladesh Bank, IT Operation & Communication Department (2010). ICT Security
Inspection Checklist For Scheduled Banks and Financial Institutions. pp. 5-6.
Bangladesh Bank, Payment Systems Department (2018). Bangladesh Mobile
Financial Services (MFS) Regulations. pp. 11-11.
Bangladesh Bank (2017), Ensuring Security, Minimizing Transaction Risks and
Enhancing Public Awareness in Card-Based Payments Through Different
payment Channels to Discourage or Reduce Cash Transactions,.
Bronson, J. (2014). Business Continuity and Disaster Recovery-Trends,
considerations and leading practices. vol. 1, pp. 6-8.
75
Carvajal, J.F. ,Garcia, M. (2003). Business Continuity Controls in ISO 17799 and
COB information technology. European Journal for the Informatics
Professional, vol. 4(6), pp. 17-23.
Cerullo, V. and Cerullo, M. J. (2004). Business Continuity Planning: A
Comprehensive Approach. Information Systems Management. Vol. 21(3),
pp. 70-78.
Dhanavandan, S. (2016). Application of Garret Ranking Technique: practical
approach. Gandhigram Rural Institute - Deemed University, India.
International Journal of Library and Information Studies, vol. 6(3), pp. 1-6.
Di Renzo, B., Hillairet, M., Picard, M., Rifaut, A., Bernard, C., Hagen, D., Maar, P.,
Reinard, D. (2007). Operational Risk Management in Financial Institutions:
Process Assessment in Concordance with Basel II, Software Process
Improvement and Practice. vol. 12, pp. 321-330.
Edwards, B. (1994). Developing a successful network disaster recovery plan.
Information Management and Computer Security, vol. 2(3), pp. 37-42.
Elliott, D., E. Swartz, et al. (1999). Just Waiting for the Next Bang: Business
Continuity Planning in the UK Finance Sector. Journal of Applied
Management Studies, vol. 8(1), pp. 43¬60.
Grillo, A., (2003). Information Systems Auditing of Business Continuity Plans.
European Journal for the Informatics Professional, vol. 4(6), pp. 12-16.
Jorrigala, V. D. (2018). Business Continuity and Disaster Recovery Plan for
Information Security, M. Sc. Engg. Thesis, Department of Information
Systems, Saint Cloud State University. pp. 17-20.
Morwood, G. (1998). Business continuity: awareness and training programmes.
Information Management & Computer Security. Bradford, vol. 6 (1).
McPhail, K. (2003). Managing Operational Risk in Payment, Clearing, and
Settlement Systems. Working Paper, Department of Banking Operations,
Bank of Canada, pp. 10-18.
Moosa, I. (2007). Operational Risk: A Survey, Financial Markets, Institutions &
Instruments. vol. 16, pp. 167-200.
Rohde, R. and Haskett, J. (1990). Disaster Recovery Planning for Academic
Computing Centers. Communications of the ACM, vol. 33(6), pp. 652-657.
76
Schaffler, D., Baez, V., Lamoureux, D. (2011). Business Continuity Plan (BCP)
versus Disaster Recovery Plan (DRP), Bank of Canada, Information
Technology Services (ITS), vol. 1, pp. 6-8.
Smith, R. (1995). Business Continuity Planning and Service Level Agreements,
Information Management & Computer Security, vol. 3(3), pp. 17-21.
Storkey, I. (2011), Operational Risk Management and Business Continuity Planning
for Modern State Treasuries. International Monetary Fund, Fiscal Affairs
Department, pp. 11-20.
Supatgiat, C., Kenyon, C., Heusler, L. (2006). Cause-to-effect operational-risk
quantification and management, Risk Management, vol. 8, pp. 16-42.
Wong, B., Monaco, K., John, A. and Louise, C. (1994). Disaster recovery planning:
Suggestions to top management and information systems managers. Journal
of Systems Management, vol. 5, pp. 45.
77
APPENDIX A
Table A1: BCP and DRP Checklists
Characteristics of Sound Practice of BCP/DRP in PCSS Operations Completed
yes/no
Level of
Implementation
(Basic/Mature)
Characteristic 1: An ORM framework including BCP/DRP is in place.
Characteristic 2: Training and awareness of BCP/DRP has been conducted.
Characteristic 3: A risk assessment has been conducted.
Characteristic 4: A business impact analysis has been conducted.
Characteristic 5: Preparatory controls have been implemented.
Characteristic 6: Senior management has endorsed BCP/DRP.
Characteristic 7: BCP/DRP testing and exercises have been conducted.
Characteristic 8: A risk champion or risk management unit is monitoring
BCP/DRP.
Identify Critical Business Processes and Systems Completed
yes/no
Document and confirm objectives and performance criteria.
List all critical business processes and systems which underpin achievement of objectives.
Rank the processes and systems in order of importance to the objectives and exclude those
processes not considered critical to achieving the objectives.
Review the functional organization chart to identify general areas of operational
responsibility.
Obtain any supporting documentation that is available which would provide a summary of
critical business processes and systems.
Interview managers responsible for critical business processes and systems to confirm
understanding.
78
A2: Questionnaire
Date:
Name of Contact:
Phone Number:
Bank Name:
(A): Establishing impact on financial stability for interruption in payment systems
If any payment systems (e.g., BACPS, BEFTN, RTGS) is interrupted then what will be its
effects or consequences on financial stability. Please assign a number from 1, 2, 3, 4, 5 to
determine impact on financial stability. (Here, 1 means highest impact on financial
stability and 5 means lowest impact on financial stability).
Disruption on Payment Systems Impact
Level
Remarks
Electronic Fund Transfer Network (EFTN)
Automated Cheque Processing Systems-Regular Value (RV)
Automated Cheque Processing Systems-High Value (HV)
Real Time Gross Settlement (RTGS)
Collapse whole Payment Systems
(B): Establishing priorities for processing and operating payment operations from
Disaster Recovery (DR) site
Sometimes it is needed to operate clearing operations (e.g., BACPS, BEFTN, RTGS) from
Disaster Recovery (DR) site. If clearing operations resume from DR site for any case then
how do you prioritize or rank payment operations. Please assign a number from 1, 2, 3, 4, 5,
6, 7, 8 to determine Priority or Rank. (Here, 1 means highest priority and 8 means lowest
priority).
Payment
Systems
Payments Operations Rank/
Priority
Remarks
BACPS Process and Send High value cheque files
BACPS Process and Send Regular value cheque files
BACPS Receive and process High value cheque files
BACPS Receiving and process regular value cheque files
RTGS Process and Send RTGS files
RTGS Receive and process RTGS files
BEFTN Receive and process Electronic Fund Transfer files
BEFTN Process and send Electronic Fund Transfer files
79
A3: Henry Garrett ranking conversion table