PAPER
Directorate of Accounting and the Payment System Bank Indonesia
TABLE OF CONTENTS
CHAPTER I INTRODUCTION
1.1. Background
1.2. Objectives
1.3. Methodology
1.4. Scope
CHAPTER II LITERATURE REVIEW
2.1. Operational Risks in the Payment System
2.2. Down Time and Late Settlement
2.3. Business Continuity Planning in the
Payment System, Time Recovery
Objectives and Motion and Time Study
CHAPTER III GROWTH AND DEVELOPMENT OF THE BANK INDONESIA
REAL TIME GROSS SETTLEMENT (BI-RTGS) SYSTEM
3.1 Position of the BI-RTGS System within the
National Payment System
3.2 Mechanisms and Operational Risk in
the BI-RTGS System
3.3 Experiences with System Failure
CHAPTER IV ANALYSIS OF DOWN TIME RISK AND RECOVERY TIME
OBJECTIVES FOR THE BI-RTGS SYSTEM
4.1. Business Impact Analysis and Time
Recovery Objectives
4.2. Motion and Time Study in BI-RTGS
CHAPTER V CONCLUSIONS
5.1. Conclusions
5.2. Policy Recommendations
CHAPTER I INTRODUCTION
1.1. Background
The Bank Indonesia Real Time Gross Settlement System,
more commonly known as the BI-RTGS system, is now the major
channel for settlement of financial transactions in
Indonesia. Almost 95 percent of high value and urgent
financial transactions, such as on the interbank money
market and stock market, government transactions, foreign
currency transactions and the proceeds of their settlement
are processed through the BI-RTGS system.
Being a highly strategic and crucial system with far
reaching financial impact, the BI-RTGS system now employs
sophisticated technology to ensure the fast, secure and
effciient operation of the payment system. However, the use
of such highly complicated technology in the BI-RTGS system
also increases operational risks, particularly in regard to
hardware damage and software and network problems that can
result in system down.
Closer attention needs to be given to the management of
operational risks in the BI-RTGS system. Operational risks
can indirectly trigger liquidity risk and credit risk, which
in turn can disrupt the overall stability of the financial
system.
Furthermore, because the BI-RTGS is a high value payment
payment system (SIPS), it must operate at high speed and
deliver high levels of security and reliability. Operation
of the system must be consistently based on compliance with
the 10 Core Principles prescribed by the Bank for
International Settlements, one of which stipulates the need
for operational reliability and provision of contingency
arrangements.
Therefore, to ensure the continued operation of the
BI-RTGS system and compliance with the Core Principles, it is
essential to have backup infrastructure and a concept for an
efficient and effective Business Continuity Plan (BCP). Part
of installing and upgrading the BCP for the BI-RTGS system
involves a study of Down Time Risk and Recovery Time
Objectives (RTO) to ascertain the risks faced and determine
realistic or tolerable times for recovery in the event of
down time in the BI-RTGS system. These times will then be
used as a guide for the BCP.
The Down Time Risk and Recovery Time Objectives (RTOs)
study is part of the Business Impact Analysis (BIA) that
represents the initial step in the development of any BCP.
In the payment system, assessment of down time risk and RTOs
is a new requirement, even though in conceptual terms it has
long been used as supporting material in all BCP
development. The usual approach for determining down time
organisation. However, because of the difficulty of
calculating non-financial risks, this study will only look
at expectations of financial impact and the motion and time
study in the event of down time in the BI-RTGS system.
This information on down time risk is expected to
provide a tangible picture for the Bank Indonesia management
in calculating the operational risk in the BI-RTGS system,
which can then be put to use in pricing policy. The
determination of RTOs will also provide a basis for Bank
Indonesia to maintain transparency toward BI-RTGS system
participants concerning risks and fulfilment of the BI-RTGS
system service level agreement.
1.2. Study Objectives
As explained above, down time risk and determination of
RTOs is fundamental to development of a BCP Concept.
Accordingly, the objectives of this study are:
1. To provide an overview of the development and
operational risks of the BI-RTGS system.
2. To examine risks in the event of down time in the
BI-RTGS system and possible impact that may result.
3. To study the Recovery Time Objectives from the angle of
expected financial impact and technical aspects
concerning the time required for the system recovery
process.
In broad terms, this study applies the descriptive
method. This method is used to help explain and describe the
operational characteristics of the BI-RTGS system, ranging
from transaction growth and operational risks to financial
impact in the event of downtime.
The data used is secondary data obtained from the
payment system database, the BI-RTGS system operational
logbook and literature studies. The scope of the data
analysis begins with the system operational data for the
2003 period. Data from 2003 was selected with the
expectation that it would explain the cyclical or seasonal
nature of transaction data in the BI-RTGS system over a one
year period. To ascertain the time required for system
recovery, primary data was obtained from observations during
trial runs of the Disaster Recovery Plan in 2004.
To obtain a more detailed picture of the possible impact
of downtime at member banks, information was gathered
through in-depth interviews at a sampling of four leading
banks: Bank Central Asia, Bank Mandiri, Lippo Bank and ABN
Amro Bank. This sampling was determined on the basis of
number and diversity of transactions conducted by those
banks using the BI-RTGS system. This selection of banks was
expected to be representative of the pattern and diversity
of transactions conducted in the BI-RTGS system.
Business Impact Analysis approach, which studies the degree
of financial impact from down time risk. Down time risk is
calculated using the following formula:
Determining Down Time Risk (Tom Pisselo, 2002)1
Potential Down Time Cost = average transactions/day x average nominal transaction value
or
Potential Down Time Cost = number of peak hour transactions x average nominal
transaction value
To calculate potential down time risk, two different
transaction periods will be used: monthly and daily. These
periods are analysed separately because the monthly data
contains cyclical or seasonal data for December while the
daily period was chosen because a one-week period contains
one day that is cyclical or seasonal, i.e. Thursday.
To determine down time cost, it is also possible to
assess the impact of down time on Bank Indonesia’s internal
systems.
Down Time Risk for Bank Indonesia’s Internal Systems
Down Time Cost = Bank Indonesia revenues from RTGS system transactions
From a technical angle, the RTO analysis will apply the
Motion and Time Study method by calculating the time taken
for each recovery process in the existing BI-RTGS system.
Recovery Objectives that need to be determined. The time
calculation method is based on the results of a trial
conducted in conjunction with this RTO study in 2004 using
various test scenarios for the BI-RTGS system Disaster
Recovery Plan.
1.4. Scope of the Paper
Following this Introduction, there will be a literature
study on the concepts of operational risk and Business
Continuity Planning concepts in payment systems. This
chapter will also describe the approach to the Recovery Time
Objectives and the Motion and Time Study.
Chapter III will describe the condition and critical
position of the BI-RTGS system within the national payment
system and elaborate on the sub-systems and potential
operational risks within the payment system. Additionally,
this chaper will present some experiences with BI-RTGS
system failure since commencement of operation in order to
look at the probability of loss within each BI-RTGS
sub-system.
Chapter IV will describe the results of the Business
Impact Analysis, including assessment of down time risk. As
added information, this chapter will also present the
findings of the Motion and Time Study for each BI-RTGS
system process.
1
Chapter V will end this report with conclusions on down
time risk and some realistic recommendations on Recovery
CHAPTER II LITERATURE REVIEW
2.1. Operational Risk in the Payment System
Today's rapid pace of change in the financial industry
through innovation of payment system products and services
in combination with advancements in technology has brought
about changes on the operational side of products and
services in the payment system. These changes have also
exacerbated the likelihood of unexpected events involving
any particular product or service, or in other words have
also given rise to operational risks.
The many different focuses of studies and academic
disciplines in operational risk compound the difficulty of
precisely defining this phenomenon. The Board of Governors
of the Federal Reserve defines Operational and System Risks
as follows: the risk of human error or fraud, or that
system will fail to adequately record, monitor and account
for transactions or positions (System Tr adi ng A ctiv iti es
Manu al) . On the other hand, the Basel Committee (2001)
describes operational risk as: the risk of loss resulting
from inadequate or failed internal processes, people and
systems or from external events.
From these differing understandings, we can define
operational risk in simple terms as the potential for
failure in the operational process of an organisation or
revenues. These failures may consist of errors in
accounting and trading, problems with legal settlement,
system failure and natural disasters. As an aid for the risk
management process, Douglas G. Hoffman (2002) divides
operational risk into five categories:
People Risks: Risks arising from human factors, such as
human error, capacity, employee integrity and management.
Relationship Risks: Risks indirectly bearing on an
organisation’s business, constituting the result of
agreements or contracts between the organisation and third
parties, such as stakeholders, members or customers and
counterparties.
Technology and Processing Risks: Risks arising from failure
or technical faults in technology and/or processing. This
includes theft of data, information fraud and technology
poorly matched to the organisation’s needs (data corruption,
programming errors, capacity risk).
Physical Risks: Risks arising from damage to property or
assets of the organisation.
Other External Risks: Risks caused by the actions of third
parties, such as fraud, money laundering, supplier risk,
natural disasters and terrorist threats.
Operational risk in the payment system concerns all
stages in the business process, ranging from validation to
middle and back office processes.
Operational risk normally increases with the distance
between operations sites and the head office. Accordingly,
the location for operation of a payment system is critical,
as it is closely linked to supervision and management
control of operational staff. Furthermore, complexity of
products and services will increase the potential for
operational risk. Another factor influencing operational
losses is a rise in volume of a product or service alongside
market volatility, putting staff under high pressure and
thus increasing the potential for human error.
All potential risks in the operations of any business,
including the operation of payment system services, must be
included in the cost and benefit analysis, particularly to
determine the pricing level of a product or service.
Failure to include assessment of operational risk for a
product or service means that the operator of the product or
service indirectly subsidises the customer and other
parties, with the result that costs are improperly
calculated.
According to Marshall Christopher (2001), costs that
can be included in operational risk calculations are:
Direct Costs, i.e. costs directly related to financial
operations, including reduction in income or loss of the
event on income is specifically the additional cost
expended for resolving an incident and the costs
allocated to prevent such incidents from happening.
Indirect Costs, i.e. events leading to indirect losses as
a result of harm to an organisational’s image or
reputation, which also affects other loss events or the
functions of a business organisation. Indirect costs are
the consequence of reputational risk that may lead to
significant negative public opinion and thus potentially
bring about critical loss of customers or stakeholders.
Opportunity Cost. This represents the maximum potential
revenues not earned as a result of a loss event. For
example, late settlement may result in counterparty
withdrawal. Other examples are late penalties,
retaliatory penalties, staff overtime and staff
opportunity costs.
In most cases, system failure may result from damage to
hardware, software problems, power outages, network
difficulties and human error. According to the Association
for Information Management Professionals (ARMA), average
company down time is 2 hours per week. Types of system
% of Companies
Survey 1996
incidents
Survey 1993
incidents
Power outage
Computer hardware problems
Software problems
Human error
Telecommunication failure
Others (earthquakes, storms, floods, fire, air conditioning, bombings)
- 55.1 % 55 %
Cause of System Failure
72.2 % 27.7 % 35 %
52.2 % 7.7 % 7 %
43.1 % 5.4 %
-34. % 2.0 % 3 %
-2.2. Down Time and Late Settlement
Down time represents one of the most critical
operational risks in the payment system. As a rule, down
time can negatively impact other systems or activities,
producing a domino effect. In simple terms, this can be
illustrated in the impact of a power outage that brings
about operational disruption preventing the system from
functioning properly.
In payment system processes, down time can lead to late
settlement. It is keenly understood that late settlement
is a crucial factor and must be given priority attention
in the operation of a payment system. Enhancements in the
use of technology are constantly aimed at eliminating or
minimising late settlement by each service provider in the
payment system.
In essence, late settlement results from a chain of
events caused by influencing factors. Factors possibly
responsible for late settlement include telecommunications
failure, human error and late confirmation. Late
confirmation, in turn, is the result of system failure,
booking error, human error and system failure at the
counterparty. A study by Christopher Marshall in 2001
concluded that factors likely to trigger late settlement are
The percentages stated in the above diagram indicate the
extent of the influence of those factors as causes of
subsequent events.
Fast, prompt settlement is the end product of a service
provided by a payment system operator and is sometimes
stated in a service level agreement with users of the
service. Accordingly, preventive measures to minimise late
settlement must be constantly upgraded by each payment
system operator through improvements in reliability of
technology. One of these preventive measures is the
preparation of business continuity planning.
2.3. Business Continuity Planning, Recovery Time
Objectives and the Motion and Time Study
The mounting level of technical risk in the operations
of the payment system means that business continuity
planning is essential. This planning is a process of
Booking Error S y s t e m
Failure Missing
Trade
Human Error
5% 45 % 5%
Late Settlement
Human Error Late
Confirmation
Telecom Failure
2% 2% 10%
identifying critical data or systems, analysing the risks of
system failure, determining the likelihood of failure and
development of system recovery in the event of failure.
The objectives of developing BCPs for the operation of
the payment system include the following:
1. Preparation of preventive and recovery measures and
mitigation of impact from unforeseeable events.
2. Provision of a proper recovery mechanism and procedure to
reduce time needed, particularly in decision making
processes.
3. Ensure the shortest possible time for system recovery
using an effective mechanism and procedure.
4. Reduce financial and reputational losses to the operator
in the event of system failure.
As a process, the BCP activity is divided into several
stages. These include assessment and business impact
analysis, selection of implementation method or approach,
plan for development, Disaster Recovery plan and
implementation and quality assurance.
As the initial step in the BCP process, the assessment
performed in the Business Impact Analysis (BIA) is extremely
important and sets the stage for the next step. The BIA is a
systematic, fundamental process for obtaining detailed
information on potential impact and cost in the event of
covers applications, data, networks, information systems,
facilities and so on.
One stage in the BIA is the determination of Recovery
Time Objectives (RTOs). RTOs can be defined as deadlines for
recovery of operational processes and the system to ensure
continuity of operations in the event of disaster.
RTOs essentially have several tiers. The
determination of the tiering depends on a company’s
computer requirements. One example is as follows:
Tier 0– Fault Tolerant: no effect on end users if system down. At Tier 0, the needed action is a replication programme in system design.
T ier 1– R TO le ss th an 24 h our s. At the Tier 1 level, a hot backup is needed with equipment on standby.
Tier 2– RTO less than 48 hours. Machine at backup site takes over system at production site in event of disaster. This can be done if the system operator has a second (backup) data centre.
Tier 3– RTO more than 7 days. At Tier 3, system restoration is required.
Source: Karen Dye, Determining Business Risk for New Projects, Risk Analysis, Disaster Recovery Journal, volume 15. Issue 2. Spring 2002.
RTOs can be determined by means of two approaches:
impact analysis and determination of effective times. Impact
analysis is performed by assessing financial losses incurred
if a system is down. On the other hand, determination of
effective times relies on the Motion and Time Study (MTS).
A Motion and Time Study can be performed to determine
the best method for minimising time spent on repetitive
a task under normal conditions. The objective of the MTS is
to improve work methods, measure distance from each task and
establish time standards for each task and person.
In a down time study, the MTS calculates the time needed
for each recovery activity in the event of disaster. The MTS
is necessary as a reference point for determining time
effectiveness and efficiency of recovery activities.
Additionally, it can also assist in determining RTOs or
CHAPTER III GROWTH AND DEVELOPMENT OF THE BI-RTGS SYSTEM
In view of the extensive coverage of the BI-RTGS
system, at some point almost all financial transactions in
Indonesia are certain to pass through the system. Therefore
according to the criteria established by the Bank for
International Settlements (BIS), the BI-RTGS system is
classified as a Systemically Important Payment System
(SIPS). Specifically, the BI-RTGS system meets the SIPS
criteria in the following areas:
1. The BI-RTGS system processes a very high turnover and
volume of transactions.
2. The range of transactions covered by the BI-RTGS system
is very broad, and the system therefore processes
settlement for most of Indonesia’s financial
transactions.
3. The high turnover passing through the BI-RTGS system
means that any system failure will inevitably transmit
serious shocks to Indonesia’s financial markets.
3.1. Position of the BI-RTGS System in the National Payment
System
The Bank Indonesia Real Time Gross Settlement system is
an interbank funds transfer system using a real time online
mechanism for bank and customer transactions with settlement
performed on an individual transaction basis. As a rule, the
Examples of high value transactions include government
transactions, interbank money market transactions, forex
transactions, securities trading and transactions in large
amounts as specified by Bank Indonesia. At this time, a
transaction can be categorised as high value if the amount
is Rp 100 million or more. Additionally, the BI-RTGS system
can process settlement of urgent retail transactions. The
definition of urgent is normative, in which the amount of a
transaction classified urgent is left to the discretion of
the BI-RTGS system user, whether Bank Indonesia as operator
or bank as member. Retail transactions that may be
categorised as urgent include transactions involving
clearing results and customer transactions in amounts of
less than Rp 100 million.
Since the launching of the BI-RTGS system on 17
November 2000, volume and turnover has grown steadily in
keeping with the growth in the national economy and expanded
scope of transactions processed through the system. In 2001,
the first year of operation, daily turnover reached 46
trillion rupiahs in 4,200 transactions. Subsequently in
2002, turnover climbed 11 percent to a daily overage of 56
trillion rupiahs in 8,800 transactions. The system
subsequently underwent further expansion in scope of
transactions and geographical coverage. In 2003, the BI-RTGS
transactions and was launched at Bank Indonesia Regional
Offices. Activity again soared, with turnover reaching an
average of Rp 80 trillion in 17,000 transactions each day.
The following graph presents the general trend in
BI-RTGS transactions over a one year period, including growth
in turnover and number of transactions during 2003:
The trend in BI-RTGS system transactions during 2003
points to a seasonal or cyclical pattern over a one year
period. Monthly observations reveal certain periods of an
increase or surge in volume and turnover in comparison to
other periods, indicating that transactions are seasonal.
The sharp rise in BI-RTGS system transactions each December
is a result of increased government-related transactions in - Daily Turnover and RTGS Transaction Volume, 2003
-35,000
30,000
25,000
20,000
15,000
10,000
5,000
250
200
150
100
50
response to the settlement of liabilities to the government
and transactions for settlement of liabilities to banks and
customers, which commonly fall due in December. Turnover for
December 2003 was recorded at Rp 2,879 trillion in 416,513
transactions. By comparison, monthly average turnover for
January-November was Rp 1,641 trillion in 340.531
transactions.
Furthermore, if transactions are observed daily, the
pattern in the BI-RTGS system is cyclical, because there are
certain periods that consistently report higher volume and
turnover compared to other periods. High turnover occurs
every Thursday, as this is the day for settlement of
transactions from the Bank Indonesia Certificate auction.
Average turnover on Thursdays during 2003 was well above
turnover for Mondays, Tuesdays, Wednesdays and Fridays.
Thursdays averaged turnover of 128 trillion rupiahs in
16,695 transactions compared to the Monday, Tuesday,
Wednesday and Friday average of 75 trillion rupiahs in
17,224 transactions.
Analysis of transactions during 2003 shows that activity
on the BI-RTGS system can be classified into peak times and
normal times. Peak times may be certain months (December) or
days (Thursdays) while normal times may represent months
(January until November) or days (Mondays, Tuesdays,
periods will be used to analyse down time risk, as described
in the following chapter.
3.2. Mechanisms and Operational Risk in the BI-RTGS System
The BI-RTGS system consists of two main technical
components, the RTGS Central Computer (RCC) installed at the
operator (Bank Indonesia) and the RTGS Terminals (RTs) at
each member bank. Member banks transmit data through their
individual RTs connected online to the RCC. After a process
of validation and checking for sufficient balance of funds,
the settlement process takes place in real time by debiting
the sending bank and crediting the beneficiary bank. Each
party receives a transfer receipt, either a completion
advice or confirmation advice. A simplified diagram of data
In its position as operator of the BI-RTGS system, Bank
Indonesia has a vital interest in the detailed monitoring of
the types of transactions passing through the system. This
data is used for early warning system purposes in bank
supervision and formulation of monetary policy. Thus for
these statistical purposes, the BI-RTGS system is
differentiated into several categories of transactions (Term
Reference Numbers) based on transaction families. By May
2004, the number of TRNs in the system reached 286. These
TRNs fall into two major categories: transactions initiated
by BI and transactions initiated by banks.
Settlement on the BI-RTGS system follows the FIFO system
(First In First Out) in which the first incoming
transactions will be settled first according to the order of
arrival of data transmissions. Accordingly, transactions for
Bank Indonesia are prioritised using the designation of
priority transactions with a scale of priority from 1 to 98.
Normal transactions for banks, on the other hand, are
assigned a priority of 99.
Data may be transmitted within the BI-RTGS system
during the prescribed operating hours, i.e. from 06:30 to
19:00 local time in Jakarta. Some types of transactions,
however, are subject to more restricted operating hours
depending on realistic times and the importance of each
type of transaction, e.g. tax payments and so on. The
following is an illustration of the BI-RTGS system window
time.
Despite the many different types of transactions and
high turnover processed in the BI-RTGS system, some
transactions are dominant. These can be categorised as
critical in terms of importance, value and impact caused
if settlement were to be delayed. The critical
T a x P a ym e nts
09.10 Deposit11.10 13.30 15.00BSKs Clearing
C l e a r i n g B S K s Non-Clearing Cash
Withdrawal Cash Deposit
06.30 10.00 11.00 17.00 18.00 19.00
KSEI Allotment
KSEI Allotment
Securities
Morning FasBI Afternoon FasBI Cut off
Pre- Cut off Money
Market
KSEI
Allotment KSEIAllotment Money Market Customers Forex Bank Cover Position
transactions include nationwide clearing results, tax
payments, government transactions, cash transactions,
stock market transactions, money market transactions,
forex trading, customer transactions, interbank SBI
trading and rupiah intervention (SBI auctions). Types of
transactions and the size of these critical transactions
[CHART] January March May July September November
Clearing, Taxes, Government, Cash, IFTSX000, IFTMM000, Forex, Customers, BIRMM580, BIRMM583
In the 2003 period, turnover for the 12 critical
types of transactions maintained a steady level from month
to month, except in December. All transactions mounted in
December. Among these were some that climbed sharply
during the month, most importantly government transactions
such as tax payments, fund disbursements and so on.
Added to these were transactions influenced by
extraordinary events, such as transactions related to cash
management. Cash withdrawals were up during October to
meet soaring public cash demand during the Ramadan fasting
month and in preparation for the Eid-ul-Fitr festivities.
3.2. Experience with System Failure and the BI-RTGS Backup
System
The history of BI-RTGS system operation has witnessed 300,000
250,000
200,000
150,000
100,000
50,000
Januari Maret Mei Juli September November
Reasons for system failure and consequent down time include
damage to hardware, software problems, power outages,
network breakdown and human error.
According to observations from 2001 to 2003, there were
almost 42 breakdowns in the RCC and 3,412 incidences of down
time with RTs. The most frequent problems with the RCC were
related to software applications. These accounted for 83
percent of the total. Causes included problems with network
module configuration, SAKTI data transmission failure and
difficulties with the beginning of day process. Other
frequent problems with the RCC involved network lines (9.53
percent), human error (4.76 percent) and power outages (2.38
percent).
Down time at member bank RTs was more commonly related
to network line problems, which accounted for 1,666
incidents or 45.34 percent of the total. The most frequent
failure at RTs involved software problems at 44.28 percent.
Hardware damage, human error and power outages each
accounted for 5.14 percent, 5.09 percent and 0.05 percent of
the total. Closer observations reveal a relatively low
incidence of human error in the BI-RTGS system, indicating
adequate levels of proficiency among the system operating
year. The various incidents of system failure in the RCC and
RTs during 2001, 2002 and 2003 are illustrated as follows:
Chart: Percentages of system failure in the BI-RTGS System,
2001-2003
Incidents of system failure at the RCC and RTs have
hampered the operation of the BI-RTGS system with some
events even responsible for system failure. Problems in the
RCC have wide ranging impact resulting in late settlement
and the window time for the BI-RTGS system will be
immediately extended. In addition, system failure at member
bank RTs will affect settlement on the bank end and directly
impact bank service performance for customers. Late
settlement for bank and customer transactions will bring on
claims from the aggrieved parties. Failure in the BI-RTGS
system will indirectly result in both financial losses
(claims, overtime, etc.) and non-financial losses such as
harm to Bank Indonesia’s image as system operator in the
eyes of stakeholders. The following is a visual depiction
of observations of delays in BI-RTGS system operations
during 2004.
H W S W L i n e P o w e r Human Error
4 5 . 3 4 4 4 . 2 8
1.10 6 225/18
Februari
1.48 3 275/22
Maret
1.20 4 250/20/
April
3.28 5 237.5/19
Mei
Duration of Incident Days (hours)
1.73 11
250/20
January
Month Window Time
June 0.15 1 262.5/21
Total 8.94 30 1500/120
[CHART] February March April May
In view of these conditions, the BI-RTGS system requires
upgrading and monitoring of all its components, including
hardware, software, network communications and power supply,
to reduce the incidence of system failure. Also importance
is capacity building for bank operational staff. The high
degree of complexity of the BI-RTGS system calls for
improved cooperation in which providers have a service level
agreement to ensure proper system operation and quick
recovery in the event of any system failure.
To anticipate losses arising in consequence to down
time in the BI-RTGS system, Bank Indonesia as regulator of
the payment system has introduced a requirement for banks
to have backup RTs both on-site and off-site. In addition,
as both operator and member of the BI-RTGS system, Bank
Indonesia maintains a backup configuration for both the
RTGS Central Computer (RCC) and RTGS Terminals (RTs).
Having considered the massive impact that would occur with
the BI-RTGS system down, Bank Indonesia has designated a
mirroring backup RCC in which the backup machine is updated
with data from the primary machine by means of a
replication program run by the system. Nevertheless, if
perform recovery on the backup machine. This still leaves
some potential for down time risk.
To provide assurance for operational continuity from
Bank Indonesia as BI-RTGS member, RT backup servers are now
in place both on-site and off-site. All off-site backup
systems for the BI-RTGS are located at the Disaster
Recovery Centre. The configuration of the BI-RTGS backup
system can be seen in the following diagram:
