Managing Operational Risk in Payment, Clearing and

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


66

6.1.4 Advantages of BCP and DRP in case of Miscellaneous


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

https://en.wikipedia.org/wiki/Basel_Accords

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.

https://www.bis.org/bcbs/

https://en.wikipedia.org/wiki/Bribery

https://tallyfy.com/guides/governance-risk-management-compliance-grc/

https://tallyfy.com/guides/governance-risk-management-compliance-grc/

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

http://www.cio.com/article/720904/How_IT_Leaders_Can_Best_Plan_for_Disaster

https://en.wikipedia.org/wiki/Information_technology

https://en.wikipedia.org/wiki/Disaster

https://en.wikipedia.org/wiki/Natural_disaster

https://en.wikipedia.org/wiki/Environmental_disaster

https://en.wikipedia.org/wiki/Anthropogenic_hazard

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.


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





Router, switch, fiber cut etc).

Network team will also communicate

with central operator (Bangladesh

Bank) to solve the problem. If


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.


Case-3 Bank‘s branch/unit is unable to connect

with PCSS Servers‘ through network

and unable to do payment related tasks.





Router, switch, fiber cut etc). If


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


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.


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.


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.


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


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


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


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.


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.


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.


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.

https://en.wikipedia.org/wiki/Plan

https://en.wikipedia.org/wiki/Committee

https://en.wikipedia.org/wiki/Probabilistic_risk_assessment

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.

https://en.wiktionary.org/wiki/priority

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

https://en.wikipedia.org/wiki/Microcomputer

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.


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.


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.


(without BCP and

DRP)


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.


(without BCP and

DRP)


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.


(without BCP and

DRP)


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.


(without BCP and

DRP)


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


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


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

Documents

Managing Operational Risk in Payment, Clearing and