BCda333TL-RFP4AsewTS-Fineweal

8/13/2019 BCda333TL-RFP4AsewTS-Fineweal

http://slidepdf.com/reader/full/bcda333tl-rfp4asewts-fineweal 1/130

BANCO CENTRAL DE TIMOR-LESTE

N ti l P t S t



N ti l P t S t

BCTL RFP – Automated Transfer System

Table of Contents

1. INTRODUCTION AND BACKGROUND ......................................................................................... 1

1.1 TIMOR-LESTE ................................................................................................... ........................... 1 1.2 NATIONAL PAYMENTS SYSTEM DEVELOPMENT PROGRAMME ............................................... ................ 2 1.3 THIS RFP ................................................................................................................................... 3

1.4 ABBREVIATIONS AND DEFINITIONS ............................................................. ...................................... 5

2. CURRENT SITUATION ................................................................................................................. 7

2.1 INSTITUTIONAL STRUCTURE ............................................................ ................................................ 7 2.2 PAYMENT INSTRUMENTS AND CIRCUITS ............................................................................................ 9 2.3 CLEARING AND SETTLEMENT ........................................................................................................ 14 2.4 FIXED INCOME SECURITIES ............................................................................................. .............. 15 2.5 EQUITIES ......................................................................................................... ......................... 15 2.6 GOTL ....................................................... ................................................................. .............. 16 2.7 IT ENVIRONMENT ...................................................................................................................... 18

3. SCOPE OF THIS PROCUREMENT ............................................................................................... 19

3.1 CLEARING AND SETTLEMENT ........................................................................................................ 19 3.2 PARTICIPANTS ........................................................................................................................... 20 3.3 LINKAGES ................................................................................................................................. 20 3.4 TECHNICAL ENVIRONMENT .......................................................................................................... 21 3.5 SERVICES .................................................................................................................... .............. 22

4 GENERAL SYSTEM REQUIREMENTS 24



BCTL RFP – Automated Transfer System

6. IMPLEMENTATION AND SUPPORT ........................................................................................... 53

6.1 BUSINESS LEVEL CONSULTING ......................................................... .............................................. 53 6.2 PROJECT PLAN AND IMPLEMENTATION SCHEDULE ................................................... ......................... 53 6.3 PROPOSER’S STAFF ............................................................ ......................................................... 55 6.4 PROJECT MANAGEMENT ............................................................................................................. 55 6.5 TESTING AND ACCEPTANCE .......................................................................................................... 57 6.6 KNOWLEDGE TRANSFER AND TRAINING .......................................................................................... 58 6.7 DOCUMENTATION ............................................................. ......................................................... 59 6.8 SUPPORT SERVICES ............................................................ ......................................................... 60

7. INSTRUCTIONS TO PROPOSERS ................................................................................................ 63 7.1 CONDITIONS OF THIS RFP .............................................................. .............................................. 63 7.2 PROPOSER Q UALIFICATIONS ......................................................................................................... 65 7.3 STRUCTURE OF PROPOSALS .................................................................................................... ...... 66 7.4 PROCUREMENT PROCESS ............................................................................................................. 67 7.5 CONTRACT ............................................................ ................................................................. ... 71

ATTACHMENT 1: TABLES OF REQUIRED FEATURES ........................................................................... 73

4. COMMON SYSTEM REQUIREMENTS ................................................................ .................................... 73 5. SPECIFIC FUNCTIONAL REQUIREMENTS FOR THE ATS ............................................................... .............. 98



Central Bank of Timor-Leste RFP – Automated Transfer System

1. Introduction and Background1.1 Timor-Leste

Geography

The Democratic Republic of Timor-Leste is a small country in Southeast Asia

with a population of approximately 1.2 million. Geographically it comprises

the eastern half of the island of Timor, which is the largest and easternmost

of the Lesser Sunda Islands at the eastern end of the Indonesian archipelago,

the nearby islands of Atauro and Jaco, and Oecussi, an exclave on the north-

western side of the island within Indonesian West Timor. The country's area

is a little less than 15,000 km2.

History

Following Portuguese colonial rule which lasted from the 16th century until

1975 (apart from a period of Japanese occupation during the Second WorldWar), the country was occupied by Indonesia in 1975. The period of

Indonesian occupation was marked by violence and brutality, with the local

guerrilla force Falintil fighting a campaign against the Indonesian forces from

1975 to 1999. In August 1999 a United Nations-sponsored referendum was

held, resulting in an overwhelming majority in favour of independence from

Indonesia. Following a period of intense civil strife which broke out following

th f d U it d N ti k i t d l d t th




GDP and around 75 per cent of employment. However, relatively low food

production by small-holders and the low level of development of localmarkets have led to a dependence on imports. The current main export apart

from oil is coffee.

Transforming subsistence farming into an export-oriented industry is a

challenge. Key crops such as coffee and vanilla, and potentially candlenut and

palm oil, are being targeted for increased capital investment.

PetroleumTimor-Leste has significant revenue from offshore oil and gas reserves. The

Government of Timor-Leste (GOTL) is seeking to use its oil revenues in

support of long-term economic development, infrastructure development,

economic diversification and poverty reduction. It has established an

internationally-acclaimed Petroleum Fund to manage its petroleum revenues

transparently and sustainably. As at 30 June 2013 the capital of the fund was

US$13.6 billion, having grown from $11.8 billion since the beginning of theyear.

On 13 July 2011 the Timorese Government released a Strategic Development

Plan, which provides a framework for development for 2011-20303.

1.2 Nat ional Payments System Developm ent Programme

B C t l d Ti L t (BCTL) i th t l b k f Ti L t d




to payment systems reform, with the objective of achieving a safe and

efficient NPS that effectively contributes to the country’s financial stabilityand economic growth. BCTL has therefore initiated a comprehensive review

of the NPS with a view to producing a broad strategy for NPS development

covering the next three to six years. This review will involve all stakeholders

in the NPS and BCTL expects to complete and publish it by the end of 2013.

At the same time BCTL has also decided to proceed immediately with the

procurement and implementation of an Automated Transfer System (ATS)

which is the subject of this Request for Proposals (RFP) and which will:

1. Provide a solid and efficient foundation for the development of a range of

innovative payment systems and services;

2. Accelerate the move towards electronic payment instruments and reduce

the systemic importance of cash and cheques;

3. Reduce risk in the financial system;

4. Contribute towards mobilisation of funds as deposits in banks for

productive investment in investment and job creation developments;

5. Improve the timeliness and effectiveness of GOTL and public utilities

payment collections;

6. Improve disbursement of state pensions and social benefits, particularly

i l




It will conform with current best practice and with international principles

and recommendations, particularly the CPSS-IOSCO Principles for FinancialMarket Infrastructures

4.The ATS will provide functionality for clearing and

settling all electronic interbank payments, both high and low value, within

one integrated software package, and will have two main functions:

1. A Real-Time Gross Settlement (RTGS) function for large value and time

critical payments, including settlement of net interbank positions arising

from clearing operations in the ACH function and the operation of

possible future external clearing houses such as card and mobile phone

payment switching and clearing operations; and

2. An Automated Clearing House (ACH) function, which in the first instance

will provide clearing and netting facilities for electronic direct credit

transfers and which will have the capability in future to handle direct

debit payments if and when they are introduced in Timor-Leste.

Both functions will be tightly-integrated within one system so as to ensureseamless clearing and settlement of all domestic interbank payments on a

same-day basis with finality and irrevocability.

The ATS will be interfaced to the in-house core banking systems (CBSs)

operated by the commercial banks, to enable fully automated straight-

through processing (STP). The ATS will also support interfaces to systems

operated by agencies of the GOTL, particularly those responsible for making

d ll i Wi hi BCTL i ill b i d i h




ii. Business and user functional requirements specification;

iii. Business-level advice and consultancy to both BCTL and all

participants related to the establishment and operation of the

system;

iv. Customisation/parameterisation of software package(s);

v. Implementation of all required linkages;

vi. Technical advice to system participants (including GOTLparticipants) on implementing the necessary linkages and

modifications to their internal systems;

vii. Acceptance testing;

viii. Training;

ix. Documentation;

x. Establishment and operation of a help-desk;

xi. Post-live software maintenance and ongoing support.

1.4 Abbreviat ions and Definit ions

ACH Automated Clearing House

AML/CFT A ti M L d i /C t i Fi i f T i




EFTPOS Electronic Funds Transfer at Point of Sale

EUR Euro

FIU Financial Intelligence Unit

FMIS Financial Management Information System

GDP Gross Domestic Product

GL General Ledger

GOTL Government of Timor-Leste

GUI Graphical User Interface

IBAN International Bank Account Number

IT Information Technology

IOSCO International Organisation of Securities Commissions

IPWG Inter-Participant Working Group

LAN Local Area Network

LVTS Large Value Transfer System

MSS Ministry of Social Solidarity

NPS N ti l P t S t




2. Current Situation

2.1 Inst i tu t ional Structure

2.1.1 Central Bank

BCTL is the monetary authority of Timor-Leste, and enjoys legal, operational,

administrative, and financial autonomy. It was formally established on 13

September 2011 under law no 5/2011 in accordance with Article 143 of the

Constitution.

BCTL operates at two sites: its head office in Dili, and a branch office in the

exclave of Oecussi. The Oecussi branch currently has two staff and is used for

cash distribution. In total BCTL employs approximately 80 professional staff.

It is intended that it should be possible to network the Oecussi office with the

head office for financial management and other functions if required.

Until the establishment of BCTL, central banking functions in Timor-Lestewere carried out by its predecessor organizations, the Central Payments

Office (2000-2001) and the Banking & Payments Authority of East Timor

(2001 to 2011), both of which were created by the United Nations

Transitional Administration of East Timor (UNTAET) which administered the

country from October 1999 to May 2002.

BCTL’s functions include:

Li i d i i f fi i l i i i (i l di i




2. The Infrastructure Fund account;

3. The Human Capital Development account.

2.1.2 ‘Formal’ Banking Sector

2.1.2.1 Banks

There are four commercial banks currently operating in Timor-Leste:

1. Australia and New Zealand Banking Group Limited, Timor Leste

branch (ANZ), which has two branches, both in Dili.

2. Banco Nacional de Comércio de Timor-Leste (BNCTL), which is locally-

owned and is the largest bank in Timor-Leste by numbers of both

branches and customers. BNCTL was formed in 2002 as the Instituição

de Micro Finanças de Timor-Leste and was granted a full banking

licence in early 2013.

BNCTL has 12 branches, two sub-branches and eight agencies, giving ita presence in all Districts of the country including Oecussi.

3. Banco Nacional Ultramarino (BNU), which is a branch of the

Portuguese state-owned Grupo Caixa Geral de Depósitos (CGD) and

has eight branches throughout the country (including Oecussi) in

addition to the head office in Dili, with three more planned. In

addition there are BNU offices at the land border with Indonesia and

t C t ’ h d ffi i Dili f th ll ti f C t d ti




these instruments are currently offered for intrabank use only (i.e. between

customers of the same bank).

Total deposits with the commercial banks amounted to USD364.4 million in

March 2013, an increase of 8.4% during the previous 12 months.

2.1.2 Non-Bank Financial Sector

There are several Other Deposit Taking Institutions (ODTIs) which, while

licensed by BCTL, have less stringent licensing criteria than the commercial

banks and whose objectives are to provide financial services to lower-income

segments of the population. They are keen to develop their payment service

offerings but at the present time it is not envisaged that they will be

participants in the ATS.

2.2 Payment Instruments and Circuits

2.2.1 Cash

The USD was adopted as the official currency of Timor-Leste in January 2000.

Timorese domestic coins in denominations of 1, 5, 10, 25 and 50 centavos

were introduced in November 2003 to facilitate small denomination

transactions and contribute to the monetisation of the economy.

Cash is the overwhelmingly predominant means of payment in Timor-Leste.

As the majority of the population do not have bank accounts, cash is the only

i hi h h k C h i d f l




2.2.2.3 (Credi t) no tes

These are primarily used by the Directorate General for Treasury of the

Ministry of Finance (Treasury) for making payments on behalf of GOTL

entities. To make a payment, Treasury draws up a Treasury Payment Order

(TPO) which is sent to BCTL where the information is entered into an Excel

application. The Excel system prints a Funds Transfer Advice which is sent to

the clearing house, and the BCTL accounts department carries out the

necessary GL postings on the basis of the TPO.

Credit notes are also used for interbank transfers.

As might be expected, there is a significant volume of such payments, as

shown in Tables 2 and 3 below (in the columns headed “Notes” and “Return

notes”). Current clearing arrangements for these are described in 2.6.1: they

will be converted to either RTGS payments or ACH Direct Credits in the ATS.

2.2.3 Bulk paymentsLarge volumes of individual payments, such as GOTL payroll, pension and

Social Solidarity payments are made using a bulk payment arrangement.

Under this arrangement schedules of individual payments are drawn up, one

for each commercial bank, and the total amounts of these payments are

calculated.

The actual payments are made using TPOs for the total amounts, which are

b T BCTL f i h i h h di




11

Clearing House Transactions –2012

Month Cheques Notes

Return

Cheques

Return

Notes Value

Number Value Number Value Number Value Number

January 1,666 14,984,743.45 2,042 34,887,080.93 30 921,205.88 50 223,261.11

February 1,768 12,857,120.47 1,142 12,992,631.35 27 773,328.80 46 433,488.18

March 1,828 12,940,743.42 1,855 14,653,753.15 33 930,779.26 53 321,201.14

April 1,548 11,588,970.55 1,383 11,796,664.81 36 348,605.81 44 427,270.61

May 1,904 13,811,094.56 2,027 20,480,733.28 29 756,309.08 59 418,975.04

June 1,851 12,387,771.24 1,718 19,122,053.90 44 783,498.61 60 862,311.44

July 1,734 13,025,174.09 1,736 18,338,058.30 38 765,828.83 60 706,897.07

August 1,728 13,003,201.22 2,592 27,556,567.50 46 863,147.41 61 517,224.86

September 1,461 12,421,698.30 1,578 25,290,830.27 37 859,286.77 62 1,425,745.68

October 1,697 14,674,432.12 2,086 29,189,076.47 50 1,228,453.15 58 654,329.32

November 1,451 11,333,085.10 1,170 13,090,205.23 50 808,703.32 50 292,376.11

December 1,776 14,049,990.13 2,955 37,778,550.59 42 697,305.67 64 619,923.14

Total 2012 20,412 157,078,024.65 22,284 265,176,205.78 462 9,736,452.59 667 6,903,003.70

Table 2: Monthly Clearing House Transactions for 2012




12

Clearing House Transactions – January to June 2013

Month Cheques NotesReturn

ChequesReturnNotes Value

Number Value Number Value Number Value Number

January 1,608 15,611,777.75 3,799 50,285,350.11 36 1,107,599.05 101 1,146,368.40

February 1,432 9,880,629.12 430 5,829,953.87 40 633,041.85 74 396,714.19

March 1,624 11,004,352.02 664 5,567,685.85 43 955,467.61 45 113,854.78

April 1,841 13,905,417.82 1,390 11,933,474.50 56 1,023,931.51 74 357,194.87

May 1,784 13,852,265.54 1,715 13,793,833.49 35 846,453.55 68 450,254.77

June 1,820 14,980,949.63 1,546 12,771,343.12 34 764,661.08 52 340,221.44

Total 6,505 50,402,176.71 6,283 73,616,464.33 175 3,720,040.02 294 2,014,132.24

Table 3: Monthly Clearing House Transactions for the Period January-June 2013




13

Payroll as of April 2013 per District

No Distritos

Monthly Payroll for Veterans

pension

Monthly payroll for public

services

Elderlies (Six month) Subsidies for the mothers (Six

month)

Monthly Payroll for

Defence/FDTL

Monthly Payroll for

police/PNTL

Item Amount Item Amount Item Amount

1 Aileu 1,037 389,547.16 1009 285,222 3,052 541,410.00 1,773 251,760.00 93 34,230.09

2 Ainaro 1,426 509,105.121064

298,292 5,877 1,066,050.00 1,616 251,520.00 108 36,963.16

3 Baucau 1,944 661,911.912435

704,687 14,485 2,560,980.00 2,927 422,400.00 232 72,070.64

4 Bobonaro 1,214 463,571.111885

547,744 9,732 1,745,880.00 2,470 346,440.00 224 73,433.89

5 Covalima 969 292,108.491595

435,903 6,532 1,163,250.00 3,099 457,500.00 215 69,244.39

6 Dili 3,213 974,537.3815860

4,793,133 8,316 1,480,890.00 3,825 590,400.00 1,840 502,240.50 1,658 527,365.33

7 Ermera 1,293 501,028.881390

402,066 8,163 1,464,090.00 2,679 419,340.00 139 46,796.85

8 Lautem 1,484 421,040.101450

403,303 5,961 1,070,580.00 1,718 265,620.00 151 51,364.98

9 Liquisa 1,188 332,395.52987

269,747 5,805 1,032,510.00 1,929 289,560.00 102 32,564.20

10 Manatuto 1,930 688,728.541031

291,295 4,655 828,030.00 1,523 211,200.00 113 39,521.79

11 Manufahi 952 413,189.381208

318,681 5,164 927,540.00 2,232 308,760.00 111 36,133.43

12 Oecussi 158 41,440.251217

348,057 5,488 967,830.00 1,746 249,600.00 4 926.00 175 54,684.47

13 Viqueque 1,652 545,711.081640

473,411 9,808 1,752,510.00 2,567 386,400.00 137 45,104.66

T o t a l 18,460 6,234,314.92 32,771 9,571,540.44 93,038 16,601,550.00 30,104 4,450,500.00 1,844 503,166.50 3,458 1,119,477.88

Table 4: GOTL Welfare and Payroll Disbursements for the Month of April 2013




2.2.4 Debit cards

The use of debit cards (for use in ATMs and POS terminals) is at an early stage

of development in Timor-Leste, with very few places where they can be used.

In May 2013 there were 11,852 debit cards issued across all the banks.

2.2.4.1 Au tom ated Teller Mach ines (ATMs)

As of May 2013 there were 22 ATMs in total in Timor-Leste, nearly all of them

in Dili. They are owned by ANZ (6), BNU (11) and Bank Mandiri (5), while

BNCTL currently has none. There is currently no interoperability between any

of the different banks’ ATMs, although a proposal for this has been made by

one bank.

The number of ATM cash withdrawals in May 2013 was 88,375.2.2.4.2 Electro nic Funds Transfer at Poin t of Sale (EFTPOS)

EFTPOS is hardly used, as there are very few installed terminals. In May 2013

the total number of installed EFTPOS terminals was 51, and in the same

month there were 23 debit card and 913 credit card transactions carried out

on these terminals.

2 2 5 C dit d




banks are required to maintain Collateral Accounts at BCTL, in addition to

their Settlement Accounts. The required balance in an individual bank’sCollateral Account is equal to its maximum debit position in the clearing

house in the previous 60 days, calculated on a rolling monthly basis. If a bank

cannot cover its clearing house debit position from its Settlement Account,

the necessary funds are taken from its Collateral Account. If this is still

insufficient, there is also a loss-sharing arrangement enforced by BCTL which

allocates the remaining debit among the other banks. This ensures that

clearing house positions are always settled.

When the ATS comes into operation, the requirement to maintain ‘Collateral

Account’ funds to the level specified will remain. However, as settlement of

clearing house positions will be carried out in the RTGS element of the ATS,

the Collateral Accounts themselves will cease to exist in BCTL’s GL. This is

further discussed in 5.4.1.

2.3.2 Large Value Transfer SystemAs described in 2.2.2.2, cheques for amounts greater than USD200,000 are

not accepted by the Clearing House and are required to go through the LVTS.

This involves presentation of the cheque directly by the presenting bank to

the drawing bank, which validates the cheque and then either dishonours it

or sends an instruction by secure fax to BCTL to debit its Settlement Account

and credit the presenting bank’s Settlement Account.




2.6 GOTL

2.6.1 Treasury Domestic Payments

Treasury operates a single Financial Management Information System (FMIS)

for all of GOTL. This uses the FreeBalance software package from the

Canadian company of the same name. All payments made by any element of

GOTL are processed in the FreeBalance Accounts Payable module which

creates TPOs as described in 2.2.2.3, and also writes cheques.

Within Treasury the Payment Directorate is responsible for preparing the

GOTL payroll, and for releasing for payment all salaries and pensions

(including those which are prepared by the Ministry of Social Solidarity).

BCTL intends to include Treasury as a direct participant in the ATS so that

Treasury can make and receive payments directly from/to the CFET account

which will be held in the ATS.

2.6.2 Treasury International Payments

Treasury makes a significant number of payments to international payees, all

in USD. At present these are made by Treasury forwarding TPOs (see 2.2.2.3)

to BCTL, which debits the amount from the CFET account and sends an

MT103 payment message via SWIFT to the overseas correspondent bank

(Federal Reserve Bank of New York or Reserve Bank of Australia).

2 6 3 Di t t G l f R (R )




the government revenue accounts. Treasury then sends a monthly statement

to Taxation for reconciliation in SIGTAS.

This is a very inefficient, cumbersome, inconvenient (particularly for the

taxpayer), slow, costly and error-prone process. Both Revenue and Treasury

are looking to make significant improvements, much of which are expected to

come from an upgrade or replacement of SIGTAS, as noted above. They are

also enthusiastic about the potential of the ATS to support these

improvements by making payments easier, faster and more efficient.

2.6.4 Directorate General for Customs (Customs)

Customs is responsible for collecting duty and taxes on all imports. It uses the

Automated System for Customs Data (ASYCUDA) developed by the United

Nations Conference on Trade and Development (UNCTAD). The current

version in use is ASYCUDA++, but Customs is planning to upgrade this to

ASYCUDA World.

In addition to the head office in Dili, Customs has offices in eight locations

throughout Timor-Leste, all of which are connected online to ASYCUDA.

There are some 20 Customs brokers, half of whom are also connected online

to ASYCUDA. For those brokers which do not have an online connection,

terminals are provided in Customs offices.

Brokers enter Customs Declarations into ASYCUDA, which calculates the

/




Introduction of the ATS will offer the opportunity to make such collections

faster and more efficient and convenient.

2.7 IT Envi ronment

The existing IT environment at BCTL can be broadly grouped as follows:

2.7.1 Facilities

BCTL runs a small in-house network based on Microsoft Windows Server

releases 2003 and 2008. It uses the usual Microsoft suite of Office,Outlook/Exchange and Internet Explorer. The Bank has an Internet

connection provided by Timor Telecom.

BCTL’s IT facilities are all located within two buildings at the head office in

Dili.

2.7.2 Applications

Current applications are:

1. The MYOB accounting package, which is deemed to be at the end of its

life: BCTL is in process of issuing an RFP for its replacement at the same

time as this RFP;

2. The Teller Support System, which is a bespoke application to support cash

payments to large numbers of beneficiaries according to lists provided by




3. Scope of this ProcurementThis section briefly summarises the required products and services that are

the subject of this procurement.

The required solution must be proposed on a full turnkey, fixed-price, basis

and cover all elements including:

1. ATS application software package;

2. All hardware and other software (e.g. system software, DBMS, etc.)

necessary to run the ATS at all project locations;

Proposers will not be required to supply these items, which BCTL will

procure via an outsourcing arrangement as described in 2.7.4;

3. A high level of consulting services to assist BCTL and all participants

with the business and technical aspects of introducing the ATS as

detailed in 3.5.4. Any required customisation and integration of the application

software, including requirements analysis, specification, development

of special software modules and implementation;

5. Full implementation services including installation, testing,

documentation, training and integration with external systems in BCTL

and participants as described in 3.3;




4. Purchase and deposit of cash by banks.

It will also be able to handle other types of payment in future, as new

systems are introduced into Timor-Leste, such as:

1. Settlement of net interbank obligations from other clearing houses

such as payment card and mobile phone payment processing

centre(s);

2. Transactions involving purchase and sale of securities (on both

primary and secondary markets) in accordance with the principles ofDelivery versus Payment (DvP) and STP (if and when the GOTL and /or

BCTL start issuing securities);

3. Settlement of transactions on possible trading platforms such as a

Stock Exchange and an interbank money market system.

3.1.2 ACH

In addition to the RTGS capability, the ATS will contain clearing functionality(ACH) to handle the processing of different retail payment streams. In the

first instance these will consist of direct credit payment instructions, either

singly or in batches. In future Direct Debit payments will probably also be

introduced in Timor-Leste, so the ATS must be capable of processing these

also.




1. BCTL’s accounting system (which is currently in process of being

procured under a separate RFP);

2. In-house CBSs operated by participants;

3. The Financial Management Information System (FMIS) operated by

Treasury and based on the FreeBalance software package;

4. The tax accounting system operated by Revenue and based on the

Standard Integrated Government Tax Administration System

(SIGTAS) software package;

5. The Customs management system operated by Customs and based on

the Automated System for Customs Data (ASYCUDA) software

package.

In future BCTL envisages a potential requirement for a variety of other

systems to be linked to the ATS if and when they are introduced in Timor-

Leste. These might, for example, include:1. A securities registry (Central Securities Depository system);

2. An interbank card and mobile payments switch;

3. A Stock Exchange equities trading system;

4. An interbank money market system;




The supplier will be required to provide contractual assurances that the

agreed total configuration (hardware, networking and software) will supportthe ATS in processing expected workloads for at least three years after

acceptance.

3.4.3 Communications

The secure transmission and receipt of messages is essential for all elements

of the ATS. The system will require the highest standards of availability,

reliability and performance.BCTL intends to implement a resilient IP-based network interconnecting the

participants of the ATS. This network will actually comprise two separate

networks using different technologies such as fibre-optic and microwave.

It is not yet known whether the use of SWIFT as a message transport

mechanism will be a requirement.

Proposers should describe the network requirements for their solutions interms of network technology, protocols, bandwidth and resilience. They

should also comment on the above proposed network and/or suggest

alternatives.

3.5 Services

BCTL understands that the success of the ATS project is particularly




f. Detailed documentation and advice to all participants on linking their

systems to the ATS;

g. Implementation of all required linkages;

h. Testing as specified in 6.5;

i. Training as specified in 6.6;

j. Documentation as specified in 6.7.

2. Ongoing (post-acceptance) support of the entire system including:

a. Problem analysis/management and error correction for application

software;

b. Support, advice and guidance for all supplied software;

c. Provision of all corrective, new and updated versions of the software

which become available, including change management support for

introducing them.




4. General System RequirementsProposals should consider all aspects of the system including:

1. The facilities and functionality provided to all system participants;

2. System performance levels;

3. Billing;

4. Operations, maintenance and support;5. Development and enhancements;

6. Capacity, scalability and upgradability of the system.

4.1 Principles

The ATS should be based on best international practice and:

1. Conform to the CPSS-IOSCO Principles for Financial MarketInfrastructures;

2. Have a high level of ease of use, with a common “look and feel” achieved

through a standard graphical user interface (GUI);

3. Comply with industry standard conventions and interfaces which allow

the system to be interfaced easily with other systems, and/or expanded




language variant available and proposals should provide information on how

this can be achieved.

Each individual user must be able to select his/her preferred language

variant.

In addition the ATS should:

1. Allow for easy customisation or change of system functions through on-

screen parameters, etc.;

2. Provide online access to and reporting of historical records – covering a

period of at least five (5) years plus the current year – without

compromising response times;

3. Provide online, context sensitive help for all user and operator functions;

4. Enable automation of daily processing including initiating links to directly

interfaced systems with appropriate security procedures and exception

and summary control reports;

5. Provide full audit trails for all activities within the system, including

system accesses and messages sent and received;

6. Provide comprehensive event and problem management tools;

7. Be configured such as to process the expected workload in terms of

throughput capacity and response times, making due allowance for peaks




4. Local record of all messages sent, pending and received each day;

5. Strong encryption of all data flows;

6. End-of-day audit and activity reporting;

7. Local recovery capabilities;

8. Security of messages with a high level of message authentication, data

integrity, and confidentiality;

9. A very high level of availability and reliability;10. Guarantee of no data loss either in transmission or after a failure.

System management functions must be fully integrated. For example, setting

any parameter that may be applicable to a number of system components

must be set only once. All system information moving between components

must be transparent to system operations.

4.4 Transact ion and File Processin g Controls

Incoming transactions and files must be checked for at least the following:

1. That the type and format are correct;

2. That the source is authorised;

3. That the identification, date and, for files, control totals are correct;




discuss the processing overhead that validation controls may impose on the

system in a high-volume environment.

4.6 Message Integri ty and Acc oun tabi l i ty

The controls must include the following:

1. Each registration of change instruction or payment instruction, and

files containing such instructions, must be uniquely identified with its

physical source, user identification and date and time of entry into the

system;

2. Each instruction must be executed according to the single or multiple

levels of authorisation (two-eyes, four-eyes or six-eyes) prescribed by

the administrator and/or the participants;

3. A message sequence numbering scheme and control procedure must

be implemented to ensure there is no loss, duplication or

unauthorised insertion of messages;

4. Non-repudiation is required for all participant messages;

5. Application level message acknowledgment is required as a

mandatory component of all message handling;

6. Where a user has the ability to make any change to any payment

message or critical system parameters, the system must allow for




possible, with controls to assure successful completion of each job as

a condition for initiation of subsequent job sequences;

2. The software should offer a consistent graphical user interface (GUI)

to enable BCTL to control its overall operation. This should provide a

comprehensive range of user-definable parameters which should be

fully described in proposals;

3. The ATS should be able to show on-line to BCTL short summaries of

the overall liquidity situation of the system, both stand-alone andcompared to previous situations (hours, days, and weeks);

4. Participants must be able at all times to see their liquidity situation,

flow of payments (received, settled and queued) and trends (in the

form of graphs, histograms, etc.) both for the current day and

historically;

5. Technical management requirements must be kept to a minimum. It is

especially important that all error messages be simply displayed and

easy for operational staff to understand and react to;

6. The ATS should require no intervention by IT technical staff for normal

operations including start-up, daily operations and shut-down;

7. The ATS should provide a range of alarms and alerts with options for:

a. Different alert levels (e.g. critical, serious, information-only);




monitoring their positions, tuning system functionality, managing intraday

liquidity, queue management of payment requests and so on.

4.8.1 Reports

Proposals must contain a full list of all standard enquiries and reports

available in the proposed software package, for all types of users. They must

also include a representative sample (listings and screen-shots) of enquiries

and reports sufficient for BCTL to gain a good understanding of what is

provided. These samples should demonstrate comprehensibility, usability andcomprehensiveness of the information contained in enquiry screens and

reports.

Proposals should contain details of: (i) how BCTL staff can tailor/customise

standard reports if desired; (ii) recommended report-writing tools for the

development of further (non-standard or ad hoc) reports; and (iii) proposed

training/knowledge transfer to ensure that BCTL staff are able to undertake

future report development.

4.8.2 Dashboard

BCTL wishes to implement a consolidated display capability (‘dashboard’) to

support operations staff in managing the overall ATS. This would use one or

more large monitors positioned in the Payment Systems operations area to

provide BCTL staff with a view of the overall status of all critical and




f. The number, frequency and source of invalid transactions and

files;

g. Any unusual behaviour patterns by an authorised user, indicating

increased risk and/or attempted fraud.

4.9.2 Access Controls

1. Access to all parts of the ATS must be restricted to authorised

personnel or systems by means of strong system, device and user

authentication;

2. User authentication capabilities should include two-factor

authentication, including fingerprint recognition (or another biometric

function) to counter the possibility of users sharing e-tokens and/or

passwords, and proposals should contain recommendations as to all

necessary hardware, software and services (including advice on

implementation) to achieve this;

3. The ATS should support a hierarchical user structure, such that at

each participant (and also in BCTL’s operational area) there can be a

local administrator with certain additional rights (e.g. for password

reset);

4. Separation of duties must be strictly enforceable for all sensitive

programs and functions;




4.9.3 Fail-Safe Operation

1. The ATS must provide the highest level of availability. The systemshould therefore be configured such as to be able to recover from any

single failure automatically and with no interruption in service;

2. In any case, the ATS must be able to complete processing of all

transactions for the day within a maximum of two hours after normal

close of day.

4.10 Processin g Requirements

BCTL requires the highest level of performance, availability and reliability

from the ATS, which will therefore be implemented to run at two sites.

A further copy of the ATS for test and training will also be run at the primary

site.

In addition BCTL will copy all data to back-up media daily, weekly and

monthly and store it at an off-site location.

4.10.1 Operational Resilience

All system elements must be designed and configured to provide a very high

level of reliability, resilience and availability, as further described in 4.13. The

system at the primary processing site should keep the system at the alternate

site updated (and vice versa) so that, in the event of a failure at one site, the




4.11 Operation al Requir emen ts

4.11.1 Daily Processing Cycle

BCTL will publish an annual schedule giving the daily processing cycle for the

system. The timing and duration of different processing windows will be

agreed between BCTL and participants.

The system operating hours will be flexible and capable of adjustment to

cater for abnormal circumstances.

For certain classes of payments (queues) it must be possible to suspend daily

operation and restart on another day while retaining the same value date.

4.11.2 Start/End of Day

With the exception of security provisions, any procedures related to the

start/end of day activity should normally be handled automatically, but be

capable of being run manually in case of disruptions to the normal daily

schedule.

4.11.3 Performance Monitoring

The performance of all components of the system will be monitored on an

ongoing basis, and relevant exception reports will be produced with suitable

highlights whenever system performance falls outside accepted performance

standards. Proposals should include details of proposers’ recommendations




1. The number and value of RTGS messages per day by payment type,

stream (queue) and participant and in total;

2. The number and value of RTGS messages processed during the peak

hour;

3. Average time in queue of RTGS messages by queue, by participant and

in total per day;

4. The volumes and values of ACH payments by instrument type and

clearing session.

Proposals should describe all available tools to collect and maintain statistics

for both BCTL and participants.

4.11.4 Operational Rules and Procedures

Proposers will be expected to advise and assist BCTL in developing and

implementing rules and procedures (for both BCTL and participants as

applicable) for operation of the system. This must include provision ofsuitable sample documentation which BCTL can adapt.

4.12 Bil l ing Inform at ion

The ATS must include a flexible billing mechanism which will automatically

calculate fees for each participant, and which should have the following

functionality:




4.13 Hardware, Software and Communicat ion s

The ATS will run on dedicated hardware installed in two sites, namely the

primary processing site and a DR site situated at a distance from the primary

site, as follows:

1. The live system will be installed on servers at both sites. The

equipment at each site should be sufficient to run the entire system

should the other site become unavailable, but in normal operation

BCTL expects that the systems at the two sites will be coupled in sucha way that a failure of any single server (for example) will have no

effect on the operation of the system. Proposals must contain

recommendations as to how the two sites will be equipped and

coupled to enable the highest level of availability.

2. Proposals should also contain details of how suitable failover

procedures will be developed and tested to allow for situations of

multiple failures or complete unavailability of one site. BCTL expectsthat the supplier will take an active part in developing and thoroughly

testing failover procedures to cover all possible situations involving

both BCTL and participants.

3. A test and training system will be installed at the central site. This will

be used as required for testing of changes to the software, training of

staff, etc.




necessary for connection to BCTL’s existing IT environment, and all operating

system options.Data Storage

Proposals must specify in detail the recommended data storage capacity and

equipment. This should be supported by sizing information on the capacity

required to hold all copies of the system database(s) and any other

supporting data, based on the current and forecast volumes given in this RFP.

Proposals should allow for the last five plus the current year’s data to be held

in the on-line database and up to ten years’ data on a secondary database.

These requirements will be discussed in more detail with the supplier.

User Workstations

BCTL expects that the system will use existing PCs as user application

workstations. Proposers should specify both minimum and optimum

configurations required.

Other Hardware

Proposals should include details of any other hardware required by their

solution.

4.13.2 Software

Participant Software




Proposals should recommend a standard easy-to-use database report

generation tool that can be used for the rapid development of reports tosatisfy needs that might arise on an ad hoc basis.


Proposers should specify in detail all communications requirements for their

solutions, covering both BCTL (both processing locations) and all participating

organisations, including performance, security, reliability, backup capability,

bandwidth and any other relevant considerations.4.14 AML/CFT

The ATS should include functionality to support the Anti Money

Laundering/Countering Financing of Terrorism (AML/CFT) activities of BCTL

and the Financial Intelligence Unit (FIU) which has been established within

BCTL. In this respect it should be capable of examining all payments as it

processes them and comparing their contents against a database of ‘items of

interest’. The database will hold information on persons, organisations and

other subjects which have been identified as suspicious. The AML/CFT

function should be capable of:

1. Importing a variety of standard Watch-Lists from international bodies

such as the US Office of Foreign Assets Control (OFAC), central banks

such as the Bank of England, the European Central Bank and the Bank

of Japan, and other providers such as Accuity;




5. Specific Functional Requirements for the ATS

The Automated Transfer System (ATS) will provide for the submission,

processing and settlement of all inter-bank payments, both large and small.

As specified in 3.1, it will comprise two tightly-integrated elements, namely

ACH and RTGS.

5.1 Objectives

The objectives of the ATS are to:

1. Improve the quality of payment services to speed up circulation of

funds and increase efficiency of funds transmission, while providing

convenience, improved levels of service, and a greater range of

services to bank customers;

2. Provide efficient and cost-effective clearing and settlement

capabilities for all interbank payments, with the ability to handlesignificant future growth in volumes of payments;

3. Achieve real-time settlement of payments between its participants in

the books of BCTL to deliver irrevocability and finality of payments;

4. Provide facilities to increase the efficiency of daily liquidity

management by BCTL and participants through the provision of real-




should therefore describe all types of payment instruments and

arrangements that their proposed solution can handle.

5.2 ACH Elemen t – Clearing Func t ional i ty

In the first instance the ACH element will handle the processing of direct

credit payment instructions. The proposed software package must also have

the capability of processing direct debits so that these can be introduced in

Timor-Leste at a future time should the banking community decide to do so.

Proposals should also describe any other streams of high-volume low-prioritypayments that their software can process.

5.2.1 Direct Credits

Proposals must contain full details of how low value (retail) direct credit

payments are handled in the ACH element, whether they are submitted on an

individual or batch (file) basis.

The ATS must have the ability (optionally, controlled by BCTL) to permitvisibility of incoming payments, i.e. a participant can see payments to itself

which have been submitted by other participants but which have not yet

entered a clearing session.

5.2.2 Direct Debits and others

For future consideration, proposals must describe in detail how Direct Debits




4. Payments of Customs duty to Treasury, each of which will carry sufficient

identification information to enable it also to be posted in real time tothe correct account in Customs’ management system ASYCUDA (see

5.7.4);

5. Net interbank positions from the ACH clearing element of the ATS;


It will also be able to handle other types of payment in future, as new systems

are introduced into Timor-Leste, such as:

1. Settlement of net interbank obligations from other clearing houses such

as payment card and mobile phone payment processing centre(s);

2. (Future) transactions involving purchase and sale of securities (on both

primary and secondary markets) in accordance with the principles of

Delivery versus Payment (DvP) and STP (as and when the GOTL and /or

BCTL start issuing securities);3. (Future) settlement of transactions on trading platforms such as a

potential Stock Exchange and an interbank money market system.

5.3.2 Operating Currency

As previously noted, Timor-Leste uses the USD as its official currency at

present. This means that accounts in the ATS will be denominated in USD,




3. Intraday liquidity management and other monetary policy operations

of BCTL;4. Settlement of secondary market transactions in securities.

For all such transactions, the principle of STP must be guaranteed and the

operational interaction between the ATS and a securities registry system

must guarantee Delivery versus Payment (DvP).

Proposals should contain details of how the proposed ATS can support these

operations.

5.3.4 Queue Management and Processing Priorities

The RTGS element of the ATS will operate on the basis of multiple payment

streams or queues. Proposers should describe in detail the queuing

mechanisms offered by their proposed solutions (including the maximum

number of queues and queue types). Characteristics should include at a

minimum:1. The ATS should have the capability to ‘warehouse’ certain types of

individual transactions for execution at a forward date and time, as

specified by the submitting participant. The permitted number of

forward days must be able to be set, and changed if desired, by BCTL.

2. Queues will have different levels of priority. Participants must be able

to assign priority levels to all payments submitted.




8. The RTGS element must be designed to avoid gridlock which could

lead to systemic failure, and must contain a gridlock resolutionmechanism.

9. The ATS must provide automatic queue management or intervention

facilities to BCTL at the level of analysis, with calculated solutions

being offered to BCTL operators for implementation. Such facilities

should include reordering, optimisation routines etc.

10. Should any gridlock resolution be used either automatically or

manually by BCTL, system participants should be notified.

11. Each participant and BCTL must be able to enquire into the

aggregated information about the total number and amount of that

participant’s transfers in the queues.

12. The originating participant must be able to cancel a payment

transaction held in the queue. A payment transaction can only be

cancelled if it has not already been settled.

13. Transactions with same-day value not settled by the end of the

operating day will be cancelled (with advice to the participant).

14. The system must have the optional ability (controlled by BCTL) to

permit visibility of incoming payments, i.e. such that a participant can

see payments to itself which have been submitted by other




As previously noted, BCTL pays interest on the CFET Account. The ATS should

therefore be able to calculate interest on a daily basis and credit itautomatically to this account at end of month.

Proposers should provide detailed recommendations as to how the linkage

between the ATS and the GL will be implemented.

5.4.2 Accounts Payable

The Accounts Payable (AP) module of the new financial accounting package

will be linked to the ATS for the purpose of automating BCTL’s own paymentsprocessing for both large value (RTGS) and retail (ACH) payments. Proposers

should provide detailed recommendations as to how the linkage between AP

and the ATS will be implemented (note that it may be necessary for the ATS

to carry out some reformatting of electronic payments received from AP into

suitable MTnnn or ISO 20022 instructions if the accounting system does not

have the ability to create these).

5.4.3 Collateral Accounts

As described in 2.3.1, the Collateral Accounts, which are used to hold funds

against any bank’s potential inability to cover its debit liability arising from

cheque clearing house operations, will be removed from the GL. This is

because all interbank settlements will take place in the RTGS element the

ATS. Clearing house net positions will therefore be settled via manual entry of




5.5.1 Sources of Liquidity

Sources of liquidity in the settlement account may be:

1. Correspondent accounts;

2. Cash deposits;

3. Incoming transfers from other participants;

4. Borrowing from other banks;

5. (Potentially) credit extension from BCTL.

5.5.2 Extension of Credit from BCTL

At the present time BCTL does not intend to create credit/loan facilities for

banks. However, it may do so in future. Proposals should therefore contain

details of how the proposed ATS package can support intraday, overnight and

longer-term loans.

5.5.3 CurrencyAs noted earlier, the fact that Timor-Leste uses the USD as its official currency

may be a constraining factor on BCTL’s ability or willingness to extend credit

to banks for the purpose of liquidity management in the ATS. However,

should a Timorese currency be introduced, this may also open up broader

possibilities. Proposals should contain full details of all liquidity support

functionality offered by their ATS packages, both in a USD-only environment




1. The possibility of an account balance below a minimum level;

2. A payment order larger than a specified amount;3. Details of payments rejected due to insufficient funds.

Proposals should contain details of all such conditions which can be

monitored.

5.6 Cash Withdrawal and Deposit

As the central bank, BCTL has responsibility for the circulation of cash, bothnotes and coins. At present all procedures associated with the withdrawal

and receipt of cash are manual. Proposers are requested to describe how

their ATS products would support the processes of cash withdrawal and

deposit to provide a risk-free solution with minimum manual operation.

5.6.1 Withdrawal

A suggested procedure for cash withdrawal is as follows:

1. The participant which wishes to withdraw cash sends a withdrawal

request in the form of an RTGS MT202 message crediting BCTL, giving

details in field 72 of the denominations it wishes to withdraw, to the

ATS, and specifying the day on which the withdrawal is to take place

(normally the following day). This alerts the ATS that a cash

transaction has been requested.




BCTL Payment Systems staff, along with corresponding postings to the GL.

Alternatively, if permitted by BCTL, vaults staff might be able to post aparticipant credit instruction directly to the bank’s Settlement Account in the

ATS.

5.7 Management of Government Transact io ns

BCTL wishes to make maximum use of the ATS to make GOTL payments and

receipts as efficient, fast, convenient, cost-effective and safe as possible. To

this end the ATS will be interfaced to the financial processing systems ofGOTL agencies as specified in 5.7.1 – 5.7.4.

BCTL expects that the supplier will dedicate a high level of business and

technical expertise to ensuring the successful specification and

implementation of all these interfaces. Proposers must include in their

financial proposals sufficient allowance for the necessary consulting, software

development and implementation effort to achieve this.

5.7.1 Domestic Payments by Treasury

As described in 2.6.1, Treasury operates an all-of-Government FMIS using the

FreeBalance accounting software package, which is used to create all GOTL

payments and to account for revenue receipts. When the ATS is

implemented, Treasury will become a full participant. The CFET account will

be moved to the ATS and will be used in the same way as banks’ Settlement




b. Reformats the MT103 message to contain the name and Bank

Identifier Code (BIC) of the correspondent bank and BCTL’s BICas the Sending Institution, rather than the BIC of the ATS (if the

ATS is implemented to use SWIFT as one of its carrier

networks); and

c. Passes it via the Local Area Network (LAN) to BCTL’s SWIFT

terminal where it is entered into the queue for validation and

approval prior to being transmitted. (All SWIFT payments

require three manual steps: input, validation and approval.This arrangement will replace the first, but not the second or

third, steps).

Proposers should comment on the above and recommend an

alternative approach should they wish.

5.7.3 Revenue

The present arrangement for collection of tax payments is described in 2.6.2,where it is noted that Revenue currently uses a very old version of the SIGTAS

software package, which is likely to be either upgraded or replaced during the

implementation period of the ATS. As also noted in 2.6.2, the present tax

payment process is cumbersome and restrictive, and involves a considerable

amount of manual keying of data between systems in BNU, Revenue and

Treasury.




demand or at an agreed time each day (e.g. end of day). Revenue will then

apply them as updates to its taxpayer database.In collaboration with BCTL, Revenue and Revenue’s software provider, t he

supplier will be required to specify and develop any required modifications to

the ATS software for this. The supplier will also work with these entities to

assist in implementing the required linkage between the ATS and SIGTAS (or

its replacement).

5.7.4 CustomsThe present arrangement for collection of Customs duties is described in

2.6.3. BCTL has been in discussion with Customs as to how the introduction of

the ATS can improve the payment process and thus, not only make revenue

collection more efficient for Customs and convenient for brokers, but also

contribute to relieving congestion of containers at the port. Proposers are

requested to comment on, and/or suggest improvements or alternatives to,

the suggested procedure below, which has been discussed between BCTL andCustoms. Financial proposals should include an allowance for the necessary

consulting, software development and implementation effort to achieve this.

This procedure assumes that electronic connections are in place between: (i)

brokers and their banks’ CBSs; and (ii) the ATS and ASYCUDA. It also assumes

that at least one of the commercial banks will make the necessary

amendments to its CBS so that this facility can be offered as a service to its




7. The relevant record in ASYCUDA is automatically updated to record

the payment, and the shipment is therefore cleared for collection(subject to any requirements for inspection).

The supplier will be required to specify and develop any required

modifications to the ATS software. The supplier will also work with BCTL,

Customs and Customs’ ASYCUDA support consultant to assist in

implementing the required linkage between the ATS and ASYCUDA.

5.7.5 Other Government PaymentsAs noted in 2.6.6, a number of GOTL agencies or state-owned enterprises

collect payments, including licence and registration fees, fines, harbour dues,

utility payments and so on. BCTL is interested in exploring with proposers and

the eventually-selected supplier the possibility of developing a standard form

of electronic payment, including documentation, arrangements with

commercial banks, procedures, and so on that can be used across all such

entities and payment types.

5.8 Interface to Part ic ipant Bank Systems

5.8.1 Messages

BCTL’s preference is for the system to use ISO 20022 message formats for all

messages, both RTGS and ACH. However, it is acceptable to use ISO 15022

(SWIFT MTnnn) formats for RTGS messages.




no charge, and to provide any necessary technical support and advice during

the implementation process, again at no charge. Proposals should alsocontain full details of any software modules that are available to facilitate STP

at participants’ sites, to which their internal CBSs can be interfaced.

5.9 Monito r ing and Report ing

The ATS must provide a comprehensive and flexible set of monitoring,

reporting and analysis capabilities, to enable each participant to have

maximum information about, and control over, its participation in the system(analogous to the way users of online banking services can control all

activities of their various accounts themselves via an internet web browser

connection).

The monitoring, reporting and analysis capabilities should cover:

1. Intraday monitoring reports;

2. End of day reports;

3. Reports on historical system activity.

In the case of participants other than BCTL, these facilities must be strictly

confined to their own participation in the system, whereas BCTL must be able

to get information on the operation of the entire system.

The intraday monitoring facilities should be available on demand, while the




4. All account balance information, by participant;

5. Enquiry into payment instructions in the system (allowing for differentselection criteria);

6. Alerts when queues build up beyond defined limits in terms either of

number of payments or of amounts to be paid. Such limits will be

defined by BCTL;

7. Summarised security reports regarding unsuccessful log-on attempts,

invalid messages (with reason for invalidity);8. A graphical display showing the status of payment queues, and

indicating areas of gridlock etc. Such a display would be incorporated

into the ‘dashboard’ described in 4.8.2.

5.9.2 Intraday On-line Information for Participants

The following will apply to participants: 1. Participants will receive an immediate message for all payments made

or received by them;

2. In case of a service disruption at a participant, BCTL must be able as

soon as possible to notify all other participants of the situation and of

any extension of the normal operating day that may result from this

situation;




to support automated account reconciliation. This information can

be sent throughout the day in response to requests received fromthe participant;

i. A full, daily statement will be sent to each participant as part of

end-of-day processing.

5.10 Ac count Maintenance and Monito r ing

5.10.1 Account Opening and Closure

BCTL will have the authority to open, close or suspend any participant

account held within the system. If an account is suspended, no outgoing

payment transactions may be made, but the system should enable BCTL

either to permit or to disallow incoming payments to be received.

5.10.2 Maintenance of Intraday Credit Limits

BCTL will have the authority to determine and operate all arrangements

relating to the provision of intraday credit.

5.10.3 Account Monitoring by BCTL

For system management purposes, BCTL will have access to all participant

account information. The ATS should have comprehensive facilities to display

online information on the overall liquidity situation of the system, both

continuously throughout the operating day and as a snapshot for the current




Any new bank receiving a banking licence from BCTL in the future will be

required to become a participant in the ATS as a condition of having a licence.

5.11.2 Volumes and Performance

The usage volumes of current instruments are given in section 2. Payment

volumes are expected to increase significantly in the next few years.

Proposals should contain benchmark data to indicate the number of

transactions of different types per minute or hour that the proposed solution

is able to process, on the proposed hardware configuration. This informationshould also indicate both any constraints and growth paths available.




6. Implementation and Support

BCTL expects the provision of exceptional service quality from the supplier.

This section specifies the service requirements that must be satisfied to

ensure successful implementation of the entire system.

6.1 Business Level Consu lt ing

In light of the fact that the introduction of the ATS is a new development for

Timor-Leste, and that BCTL has consequently little experience in this field,BCTL expects that the supplier will provide a high level of business consulting

and advice – in addition to technical support – throughout the project period,

drawing on its international experience in payment systems implementation.

Proposers must therefore provide details of the support they will provide in

this area, not only in finalising the specific functional characteristics of the

ATS, but also covering aspects such as the development of operational rules

and procedures, system charging regimes and any other areas where the

proposer feels that it can offer guidance on good practice and avoidance of

pitfalls, consistent with international best practice. In particular the supplier

will be required to provide example/boilerplate documentation for system

rules, participant agreements, operating procedures and charging policies.

Significant weighting will be given to this aspect of proposals in the

evaluation process.




6. System customisation, delivery and installation plan;

7. System integration plan;

8. Training plan;

9. Documentation plan;

10. Change management plan;

11. Installation and acceptance testing plan;

12. Warranty and post-warranty service plan;

13. A detailed staff deployment schedule showing, for each month of the

proposed contract schedule, the estimated time to be spent by each

member of the Proposer’s team at all project locations (i.e. Dili, the

Proposer’s home office and any other locations).

The supplier’s preliminary project plan will be refined and updated as

necessary by discussion and agreement between BCTL and the supplierduring the first phase of project execution. Once this has happened, it will

become the Agreed Project Plan and will be subject to formal change control

between the two parties’ project managers. The Agreed Project Plan will be

regularly updated to reflect changes as the project evolves.

6.2.2 Implementation Schedule

BCTL expects the project implementation to comprise at least the activities




Proposals should include any additional activities that the Proposer feels are

required.

6.3 Proposer’s Staff

Proposals must describe the structure, competences, roles and

responsibilities of the proposed project team, including CVs for all proposed

team members.

To ensure maximum knowledge transfer, the supplier’s project team should

be structured to work with counterparts within BCTL and other participants,

and proposals should therefore show the proposer’s expectations of BCTL’s

and participants’ team structure and management, together with roles and

responsibilities.

A detailed staff deployment schedule must also be provided showing the

planned engagement in person/days of each team member at each stage of

the project, both on-site in Dili, in home office and in any other location(s).

The project team must include key specialists and alternates in at least the

following areas:

1. Project Manager;

2. High value/high priority payment processing systems (RTGS);

3. Low value and bulk (retail) payment processing systems (ACH);




6.4.1 Steering Committee

BCTL has established an ‘RTGS committee’ which has oversight of the projectincluding this procurement and will have final responsibility for all aspects of

implementation. BCTL’s project manager acts as secretary to the RTGS

committee.

The RTGS committee will meet regularly during the project to consider the

minutes of the previous progress meeting, review progress and approve any

actions proposed by the project managers. Both project managers (see next

paragraph) will attend RTGS committee meetings.

6.4.2 Project Managers

BCTL and the supplier will each appoint a project manager who will have

overall responsibility for ensuring the successful and full discharge of their

respective parties’ obligations under the contract. To this end the two project

managers will work closely together at all stages of the contract.

6.4.3 Progress Monitoring

Throughout the project execution the supplier’s project manager will submit

to BCTL’s project manager a monthly progress report covering:

1. Results accomplished during the preceding month;

2. Any deviations from the Agreed Project Plan, corrective actions to be




6.5 Test ing and Ac ceptance

The full ATS will not be finally accepted (i.e. achieve Operational Acceptance)

until all functionality has been fully tested and demonstrated to be working

correctly at all locations to the satisfaction of BCTL and all participants.

6.5.1 General

The installation and testing process will demonstrate (for all components):

1. Ease of installation and system start up;2. Operation of the system platform;

3. Operation and management of the complete system by non technical

staff;

4. Reliable and efficient automated communications interfaces;

5. High reliability and fast recovery in case of failures;

6. Effective and correct operation of all system linkages;

7. Complete integrity of processing and accurate responses to all system

information enquiries;

8. Ability to handle expected and peak workloads for a minimum period

of three years after Operational Acceptance;




2. Functional acceptance tests will be conducted across the fully installed

ATS in both the primary and back-up processing sites, and all elementsinstalled at participant institutions, including linkages with participants’

in-house systems (in both their primary and back-up processing sites).

These will entail testing every detailed aspect of system functionality,

including a full range of error checking.

3. Operational acceptance tests will involve full load (stress) testing of the

ATS to confirm the ability of the hardware and software (as sized by the

supplier) to handle a peak workload. They will include the full range offailover procedures specified by the supplier for handling failures at either

site.

6.5.4 Acceptance Test Design and Execution

The contents of all acceptance tests will be proposed by the supplier for

BCTL’s approval and planning, and modification as necessary. All acceptance

tests will be carried out by BCTL and/or participant operations and technicalstaff, and will be monitored and supported by the supplier at each step. BCTL

and participants will make management personnel and staff available to the

supplier to participate actively in the acceptance test process as an integral

part of the training and knowledge transfer and eventual handover of the

system to BCTL.

6.5.5 Evaluation of Acceptance Test Results




technological knowledge, not just at BCTL but also among the participant

organisations. This is viewed as critical in order for all parties to become self-sufficient in the operation and maintenance of the new services and related

technologies. Proposers must describe in detail how they intend to achieve a

high degree of knowledge transfer.

6.6.2 Training

Proposals must include training plans showing:

1. The overall approach to be taken;

2. The recommended number and (if applicable) prior knowledge of people

to be trained in each institution;

3. The duration of each training module; and

4. The proposed number of times each module is proposed to be delivered.

Training plans should specify any prerequisites that must be satisfied prior to

the commencement of training. They should cover not only BCTL but all

participants as applicable to each part of the ATS.

Training should include specific modules for:

1. Management level personnel for both BCTL and participants;

2. Supervisory and operational staff for both BCTL and participants;




2. End-user Documentation, tailored as applicable, covering operations

guides, operating manuals, and standard user manuals. On-line helpmust be provided in all system modules;

3. Technical Documentation that BCTL will need to use for the safe and

effective running of the processing environment. This should include

‘as-built’ and final design documentation that includes the selected

options and configuration settings, and all operating instructions and

procedures;

4. Detailed Documentation of Operational Processes.

6.8 Support Services

6.8.1 System Implementation

The supplier will provide operational support for the entire system on-site at

the primary and alternate processing sites during the implementation period

and for a period of one month after Operational Acceptance. During thistime, the Supplier’s support personnel must be available on an immediate

on-call basis during normal business hours at BCTL’s head office.

During the implementation period the supplier will assist BCTL in establishing

a help desk service to provide application-level support to all users during the

operating day, including implementation of a help desk software package,

advice on staffing levels, training, documentation, operating procedures and




The supplier will ensure that sufficient resources (with respect to the

number of personnel and such personnel's training, competence andexperience) are available to provide the software support services at

all times. The resource available shall be of an appropriate skill level

to minimise any impacts to the levels of service required by BCTL,

covering knowledge of BCTL’s and participants’ business operations as

well as expertise in the software itself.

2. Provision of all corrective, new and updated versions of all supplied

software products as they become available, including changemanagement support for introducing them. Proposals should contain

details of the methodology for supplying and implementing software

upgrades during the life of the system, including measures to ensure

that full training is provided on changes and enhancements as

needed, and that business continuity is guaranteed during upgrades,

additions or changes.

6.8.3 Problem Management

The supplier’s support centre will answer incoming telephone calls within one

minute and will check email not less frequently than every ten minutes.

All problems notified to the supplier will have a priority assigned by BCTL that

will define the severity and impact to BCTL’s service levels with a resolution

target and escalation framework to make sure the effects of the problems




1. The number of service-disrupting incidents over any selected period

by source of disruption and in total;2. The number of non-service disrupting incidents reported over any

selected period;

3. The time taken to restore normal service after each recorded service

disruption.

Proposers should also explain how BCTL staff can monitor reported problems

on a regular basis.6.8.4 Performance Expectations

BCTL expects a very high level of reliability and availability of all its systems,

and the system will be particularly crucial in this respect.

BCTL’s expectations of overall system performance include:

1. There will be no more than a total of three software failures per

annum, and no more than one in any single month. A software failureis defined as an event where a component of the application fails to

respond to operator instructions and fails to perform its normal

function, and requires to be manually restarted or fails to restart. In

every case the time to recover from a failure shall be no more than 30

minutes.

2. In a situation where the system performance is degraded, this must




7. Instructions to Proposers

7.1 Cond it ions of this RFP

The following conditions apply to this RFP:

All documents shall be submitted in the English language.

Proposals must be in the format, and follow the sequence, specified in

section 7.3 of this RFP. BCTL reserves the right to exclude from

consideration any proposal which fails to do so.

Each proposal must be signed by a duly authorised officer of the

proposer.

Each proposal must name the person(s) authorised to negotiate and

answer any questions regarding the proposal, and state their

designation(s) together with contact details including physical and email

addresses and telephone number.

BCTL shall be entitled to rely on all statements and representations or

subsequent enquiries or correspondence made by the proposer in

response to this RFP, whether express or implied, made orally or in

writing.

BCTL may choose, at its discretion, to waive any defect, technicality or

informality in any proposal received.




The requirements specified in this RFP reflect those known at present.

BCTL reserves the right to vary the final requirements prior to enteringinto any contract.

BCTL will not be responsible, nor pay, for any expense incurred by a

proposer in the preparation of their proposal or in BCTL’s evaluation of it.

All documentation submitted and statements made as part of, or in

connection with, the successful proposal will be carried forward as part of

the contract.

BCTL will treat all information contained in a proposer’s response, and

any subsequent information, as commercially confidential and will not

disclose it to any third party, except for BCTL’s consultants engaged

specifically in connection with this RFP, without specific written authority.

BCTL will agree to be bound by a proposer’s reasonable non-disclosure

agreement related to specific items of information, provided such

agreement is made in writing.

This RFP and any contract arising from it shall be construed according to

and governed by the law of Timor-Leste and proposers agree to submit to

the exclusive jurisdiction of the Timor-Leste courts in any dispute or

difference of any kind which may arise concerning this RFP or any related

contract.

No advertising, press release or any other information relating to the




7.2 Propo ser Quali f ications

Proposers must establish to BCTL’s satisfaction that they have the financial,

business, technical, and production capability necessary to perform the

contract, and have a successful performance history. In particular proposals

must meet the following qualification criteria:

Proposers must furnish documentary evidence that they meet the

following financial requirement(s): average annual turnover within

the last three (3) years of not less than USD 3,000,000; and access to

financial resources such as lines of credit, etc. of at least USD

1,000,000.

During the past three years, the proposer must have completed at

least one successful contract involving the supply, implementation

and support of an ATS of similar specification to that contained in this

RFP and preferably in a developing country with similar characteristics

to Timor-Leste; Proposals must be for packaged software. BCTL does not wish to fund

systems development (although it is appreciated that customisation

and possibly some minor amount of associated bespoke software

development will need to be carried out);

The software must be fully developed. BCTL expects that the full

functionality including capability for integration with a range of




The project manager nominated by the proposer should have at least

ten years relevant industry experience, the last five of which should

have included project management responsibility for staff over

extended periods involving the development, implementation,

operation and support of integrated banking and payment systems.

7.3 Structur e of Proposals

Proposals must be structured as specified hereunder.

7.3.1 Executive Summary

A concise summary of the entire proposal which must include as a minimum:

An overview of the total solution proposed, including all proposed and

future potential linkages, and describing the benefits to BCTL of each

part of the solution;

A description of all proposed products and services, including

software, hardware, project management, business consulting

services, software customisation, implementation, testing,

documentation, training and ongoing support for both software and

hardware;

A statement accepting the terms and conditions laid down in section

7.1 above;




The above information for each company associated with the

proposer in this proposal (subcontractors, product suppliers,

consulting firms, etc.).

7.3.3 Proposed Solution

This section should provide complete information on all aspects of the

proposed solution, structured as follows:

An overview of the full solution, describing each element and how all

elements are proposed to interact and link to other external systemsas specified in this RFP.

An item-by-item response to the detailed technical requirements as

set down in sections 4 and 5 of this RFP (it is not necessary to provide

a detailed response to section 3). Proposers are requested to use the

Table of Required Features which can be found as Attachment 1 at the

end of this RFP. For each item, a description must be given of how the

proposer’s product satisfies the requirement: for example, “yes” or“complies” are not sufficient. Where alternative options exist to

satisfy any individual requirement, these should be clearly identified,

together with any recommendations that the vendor may wish to

make regarding them. Should a proposed product be incapable of

satisfying any individual requirement, this should be clearly stated,

together with proposals for mitigating such shortfall (e.g.




7.4.1.2 BCTL co ntact

BCTL’s contact person for this RFP is Ms. Raquel Gonçalves da Costa. Contactshould be made with her by email to [email protected], with

the subject line “RFP for Automated Transfer System”.

Email will normally be acknowledged within one business day; should this not

occur the sender may telephone Ms. Gonçalves on +670 331-3712 ext. 108 to

confirm receipt.

No other BCTL staff are to be approached about this RFP.7.4.1.3 Clarif ication

All requests for further information or clarification of these requirements

must be in writing by email to the above-named contact person no later than

two weeks prior to the deadline for proposal submission given below. Each

such request, if BCTL deems it material, will be emailed as soon as practical to

all companies which have registered as prospective proposers along with

BCTL’s response (without identifying the source of the queries).

7.4.1.4 Propo sal submiss ion

Technical proposals (without prices) in response to this RFP must be

submitted as follows:

Proposals must be submitted, in Microsoft Office or PDF format, to

the above-named contact person either by email or by courier on CD-

mailto:[email protected]







1. First, technical proposals will be subjected to initial evaluation against

the criteria given in 7.4.5. The proposal presentation meetings

described in 7.4.3 will be conducted during this period. Any proposals

which are found during this process to be substantially non-

responsive to BCTL’s technical requirements will be excluded from

further consideration, and their proposers will be notified accordingly.

2. Second, following submission of final proposals as prescribed in 7.4.4,

technical proposals will be formally evaluated (with possible

modifications of the evaluation criteria in light of the proposalpresentation meetings, of which proposers will be notified prior to the

deadline for submission of final proposals).

3. Third, financial proposals will be opened and evaluated. Total six-year

costs will be used in the financial evaluation.

As part of the evaluation BCTL may undertake site visits and reference checks

to gather information about each proposed solution’s capabilities (and any

limitations) in live usage.

7.4.3 Proposal Presentation Meetings

During the initial technical evaluation process, proposers will be invited to

attend proposal presentation meetings with BCTL’s RTGS committee and

representatives of all ATS participants. The objective of these meetings will

be for BCTL, its advisers and other involved parties to gain a thorough




4. Discussion with the proposer of matters arising out of the preceding

sessions. At the end of this session BCTL expects to have reached

agreement with the proposer as to the final form of the proposal.

The proposal presentation meetings are expected to take place during the 2nd

half of October 2013 at a location in Dili to be advised. Proposers who have

indicated their intention to submit proposals will be consulted as to their

preference for date(s) prior to the closing date for proposal submission.

7.4.4 Preparation of Final Proposals

Following the proposal presentation meetings, BCTL will draw up proposer-

specific letters which will be sent to proposers which have not been

disqualified, inviting them to submit:

1. Updated Technical Proposals. These will contain revisions of the

previously-submitted technical proposals as applicable in light of

discussions held during the proposal presentation meetings. It will not be

necessary to re-submit the original proposals.

2. Financial Proposals. These must contain a detailed description and

breakdown of all costs associated with the proposed products and

services, clearly distinguishing between one-time and recurrent (post-

Warranty Period) costs. They must be structured as follows:

One-time costs




1. Proposer’s demonstrated understanding of the Timor-Leste

context, in particular national economic development prospects,

BCTL’s strategic direction and the national payments system

development programme.

2. ATS functionality – match to BCTL’s requirements:

RTGS component

Liquidity management

ACH component

3. Technical quality of overall solution:

Integration of components

Linkages to other BCTL systems

Integration with GOTL systems

Adaptability to future requirements

4. Services and support:

Approach and methodology

Project plan

Implementation time-frame

Provision of business-level consulting

Experience of key staff




to cease, to provide maintenance or technical support service for the

software as required by the supply agreement or SLA.

Proposers should indicate their willingness to agree to the proposed escrow

arrangements.



BCTL RFP – Automated Transfer System (ATS)

73

Attachment 1: Tables of Required Features

For each item in the following tables, a description must be given in the “Response” column of how the proposedsolution satisfies therequirement: for example, “yes” or “complies” is not sufficient, nor is reference to a manual. Where alternative options exist to satisfy

any individual requirement, these should be clearly identified, together with any recommendations as to the preferred option. Should a

proposed product be incapable of satisfying any individual requirement, this should be clearly stated, together with proposals for

mitigating such shortfall (e.g. development of a custom software module).

Note – the “Response” column contains N/A where a response is not required.

4. Common System Requirements

Required Feature ResponseProposals should consider all aspects of the system including:

1. The facilities and functionality provided to all system

participants;

2. System performance levels;

3. Billing;

4. Operations, maintenance and support;

5. Development and enhancements;

6. Capacity, scalability and upgradability of the system.

N/A




74

Required Feature Response

4.1 Principles

The ATS should be based on best international practice and:

N/A

1. Conform to the CPSS-IOSCO Principles for Financial Market

Infrastructures;

2. Have a high level of ease of use, with a common “look and feel”

achieved through a standard graphical user interface (GUI);

3. Comply with industry standard conventions and interfaces

which allow the system to be interfaced easily with other

systems, and/or expanded by either functional module or

capacity;

4. Offer low cost and easily implemented technical connections

for external participant sites on either a remote terminal orhost-to-host basis for all system traffic;

5. Enable BCTL system operators easily to add, remove or suspend

participants;

6. As appropriate, permit optimum use to be made of any

equipment that is already installed in both BCTL and participant

organisations;

7. Have high levels of trustworthiness with particular emphasis on

data integrity and security, particularly preventing

unauthorised access and assuring 100% data accuracy;

8. Have very high levels of service availability which will beassured through demonstration, rigorous testing and a robust




75


Service Level Agreement;

4.2 Operational N/A

The ATS must be delivered in both English and Portuguese

language variants. BCTL is also interested in evaluating the

possibility of having a Tetum language variant available and

proposals should provide information on how this can be achieved.

Each individual user must be able to select his/her preferred

language variant.

In addition the ATS should: N/A

1. Allow for easy customisation or change of system functions

through on-screen parameters, etc.;2. Provide online access to and reporting of historical records –

covering a period of at least five (5) years plus the current year

– without compromising response times;

3. Provide online, context sensitive help for all user and operator

functions;

4. Enable automation of daily processing including initiating links

to directly interfaced systems with appropriate security

procedures and exception and summary control reports;

5. Provide full audit trails for all activities within the system,

including system accesses and messages sent and received;6. Provide comprehensive event and problem management tools;

7. Be configured such as to process the expected workload in




76


terms of throughput capacity and response times, making due

allowance for peaks in transaction volumes and general growth

in transaction volumes;8. Be operationally resilient, with high levels of local recovery

supported by an appropriately configured back-up installation

and a smooth cut-over between the primary and alternate

sites, and back again to the primary site when service is

recovered.

4.3 Integrity

The ATS should provide:

N/A

1. Financial integrity checks to ensure that ‘value in = value out’ at

all times and that the ATS component can be reconciled to a

zero net balance at any time;

2. Processing integrity checks to ensure that ‘number of financial

items in = number of financial items out’ at all times and that

each processing site can be reconciled to a ‘no missing items’

position at any time;

3. Consistent and regular reporting for financial processing,

security logs, calculated settlement positions, gross and net

settlement values, batch and file numbers processed etc. which

can be reported both locally and centrally to prove systemintegrity and complete system-wide reconciliation;




77


4. Local record of all messages sent, pending and received each

day;

5. Strong encryption of all data flows;6. End-of-day audit and activity reporting;

7. Local recovery capabilities;

8. Security of messages with a high level of message

authentication, data integrity, and confidentiality;

9. A very high level of availability and reliability;

10. Guarantee of no data loss either in transmission or after a

failure.

System management functions must be fully integrated. For

example, setting any parameter that may be applicable to a

number of system components must be set only once. All system

information moving between components must be transparent to

system operations.

4.4 Transaction and File Processing Controls N/A

Incoming transactions and files must be checked for at least the

following:

1. That the type and format are correct;

2. That the source is authorised;

3. That the identification, date and, for files, control totals arecorrect;




78


4. That a message is not a duplicate;

Outgoing transactions and files must be checked at least as follows:

1. It must be assured that no transaction or file will be left

undelivered;

2. If delivery is not possible, alerts must be available;

3. It must not be possible to deliver twice, except under recovery

procedures when both parties are made aware of the

possibility that the message may be a duplicate.

4.5 Validation Controls

Validation controls must include:

1. Validation of batches and individual payment instructions, of all

types;

2. Validation of mandatory and optionally other fields within

payment instructions;

3. Authentication of message sender;

4. Confirmation of message traffic and validity to the sender;

5. Flexible and tailorable validation routines.

Proposals should describe validation options offered by their

proposed solutions and the extent to which these can be tailored

by BCTL, and also discuss the processing overhead that validation




79


controls may impose on the system in a high-volume environment.

4.6 Message Integrity and Accountability

The controls must include the following:

N/A

1. Each registration of change instruction or payment instruction,

and files containing such instructions, must be uniquely

identified with its physical source, user identification and date

and time of entry into the system;

2. Each instruction must be executed according to the single or

multiple levels of authorisation (two-eyes, four-eyes or six-

eyes) prescribed by the administrator and/or the participants;

3. A message sequence numbering scheme and control procedure

must be implemented to ensure there is no loss, duplication orunauthorised insertion of messages;

4. Non-repudiation is required for all participant messages;

5. Application level message acknowledgment is required as a

mandatory component of all message handling;

6. Where a user has the ability to make any change to any

payment message or critical system parameters, the system

must allow for multiple authorisations;

7. It must be possible for operational management to trace any

transaction from the point of entry into the system up to the

delivery to the final destination with complete informationabout the time the message was received and delivered, and

C d f S ( S)




80


the processing which occurred at each step at each location

handling the transaction/file. Information for this purpose must

be kept on line for a period which can be defined by BCTL, afterwhich time the data must be archived to permanent off-line

storage;

8. It should be possible to suspend processing of elements of the

ATS (for example selected payment queues or streams) in the

course of the business day and resume operation without the

loss or duplication of messages;

9. In the case of failure leading to unavailability of the primary

site, the resumption of service at the alternate (DR) site should

be completed within a maximum time of thirty minutes with

minimum user intervention.4.7 System Operation N/A

1. To minimise the opportunity for human error to cause service

disruptions, operation of the software should be automated as

far as possible, with controls to assure successful completion of

each job as a condition for initiation of subsequent job

sequences;

2. The software should offer a consistent graphical user interface

(GUI) to enable BCTL to control its overall operation. This

should provide a comprehensive range of user-definable

parameters which should be fully described in proposals;

3. The ATS should be able to show on-line to BCTL short

BCTL RFP A t t d T f S t (ATS)




81


summaries of the overall liquidity situation of the system, both

stand-alone and compared to previous situations (hours, days,

and weeks);4. Participants must be able at all times to see their liquidity

situation, flow of payments (received, settled and queued) and

trends (in the form of graphs, histograms, etc.) both for the

current day and historically;

5. Technical management requirements must be kept to a

minimum. It is especially important that all error messages be

simply displayed and easy for operational staff to understand

and react to;

6. The ATS should require no intervention by IT technical staff for

normal operations including start-up, daily operations andshut-down;

7. The ATS should provide a range of alarms and alerts with

options for:

a. Different alert levels (e.g. critical, serious, information-

only);

b. The nature of alarms available (e.g. flashing message at a

workstation, audible warning, email message, SMS message

to a mobile phone);

c. Different recipients (e.g. operations staff in BCTL Payment

Systems department, participant bank end-users, BCTL IToperations, BCTL accounting department, BCTL treasury,

etc.);

BCTL RFP A t t d T f S t (ATS)




82


8. Certification measures will take place using the test

environment that is to be established as part of this

procurement. They should be carried out using a standard setof test messages that will be developed as part of the overall

system implementation and should include:

a. Testing and certifying new software releases/upgrades prior

to use;

b. Testing and certifying new system participants in respect to

hardware, software, communications and procedures.

4.8 Enquiry and Reporting

The ATS will provide comprehensive reporting and on-line enquiry

facilities allowing all participants to make a broad range of requestsfor the purpose of monitoring their positions, tuning system

functionality, managing intraday liquidity, queue management of

payment requests and so on.

4.8.1 Reports N/A

Proposals must contain a full list of all standard enquiries and

reports available in the proposed software package, for all types of

users. They must also include a representative sample (listings and

screen-shots) of enquiries and reports sufficient for BCTL to gain a

good understanding of what is provided. These samples should

demonstrate comprehensibility, usability and comprehensiveness

of the information contained in enquiry screens and reports.

BCTL RFP Automated Transfer System (ATS)




83


Proposals should contain details of: (i) how BCTL staff can

tailor/customise standard reports if desired; (ii) recommended

report-writing tools for the development of further (non-standardor ad hoc) reports; and (iii) proposed training/knowledge transfer

to ensure that BCTL staff are able to undertake future report

development.

4.8.2 Dashboard

BCTL wishes to implement a consolidated display capability

(‘dashboard’) to support operations staff in managing the overall

ATS. This would use one or more large monitors positioned in the

Payment Systems operations area to provide BCTL staff with a view

of the overall status of all critical and important elements of thesystem. Proposers should describe how their system supports this

concept, with recommendations as to the data items that would be

displayed.

4.9 Security N/A

4.9.1 Monitoring and Measurement

1. All accesses to the ATS, transactions handled by the system and

changes affecting access controls, system parameters,

directories and similar control and integrity functions should be

logged and reported to BCTL operators, and be accessible forauthorised retrieval and analysis, on a daily basis. It must not





84


be possible to alter in any way the contents of any audit log;

2. Proposals must specify in detail the audit logging function of

their ATS package, which should include at least the following:

a. System or physical device identification;

b. User identification;

c. Time of each access;

d. Invalid access attempts;

e. Activities involving management of users (from both BCTL

and other participants) and their access privileges;

f. The number, frequency and source of invalid transactions

and files;

g. Any unusual behaviour patterns by an authorised user,

indicating increased risk and/or attempted fraud.

4.9.2 Access Controls N/A

1. Access to all parts of the ATS must be restricted to authorised

personnel or systems by means of strong system, device and

user authentication;

2. User authentication capabilities should include two-factor

authentication, including fingerprint recognition (or another

biometric function) to counter the possibility of users sharing e-

tokens and/or passwords, and proposals should contain

recommendations as to all necessary hardware, software andservices (including advice on implementation) to achieve this;





85


3. The ATS should support a hierarchical user structure, such that

at each participant (and also in BCTL’s operational area) there

can be a local administrator with certain additional rights (e.g.for password reset);

4. Separation of duties must be strictly enforceable for all

sensitive programs and functions;

5. All accesses must be logged as specified in 4.9.1 in order to

provide a clear audit trail for review in case of accidental or

deliberate violation of security controls;

6. The system start-of-day procedures should include the

initiation of directly interfaced systems and confirmation of the

authenticity of each interfaced system;

7. Users should not be able to see menu options for thosefunctions they are not authorised to use;

8. The ATS must enforce sound password management. That

includes: enforcing the use of ‘strong’ passwords; forced expiry

of passwords at parameter-defined intervals; disablement of

accounts after a parameter-defined number of unsuccessful

log-in attempts; and not permitting the re-use of a parameter-

defined number of previously used passwords;

9. Application workstations must be logged off automatically if

idle for more than a parameter-defined period, to prevent

access by unauthorised third parties if left unattended.4.9.3 Fail-Safe Operation N/A





86


1. The ATS must provide the highest level of availability. The

system should therefore be configured such as to be able to

recover from any single failure automatically and with nointerruption in service;

2. In any case, the ATS must be able to complete processing of all

transactions for the day within a maximum of two hours after

normal close of day.

4.10 Processing Requirements

BCTL requires the highest level of performance, availability and

reliability from the ATS, which will therefore be implemented to

run at two sites.

A further copy of the ATS for test and training will also be run at

the primary site.

In addition BCTL will copy all data to back-up media daily, weekly

and monthly and store it at an off-site location.

4.10.1 Operational Resilience N/A

All system elements must be designed and configured to provide a

very high level of reliability, resilience and availability, as further

described in 4.13. The system at the primary processing site should

keep the system at the alternate site updated (and vice versa) sothat, in the event of a failure at one site, the other site is able to





87


continue processing with minimal manual intervention.

Proposers should address these requirements carefully, and make

appropriate recommendations for achieving the highest level ofperformance and reliability. Proposals should contain a detailed

specification of all proposed hardware, software and any other

necessary components to achieve the required levels of reliability

and switchover times. They should also include a discussion of

worst-case scenarios requiring a complete switch-over from the

primary to alternate site.

4.10.2 Test Environment

A test environment should be available at all times to allow for

testing of planned system changes, or for participant interfacetesting. Proposers should describe how they will accomplish the

following main tasks:

1. Management of changes involving hardware, system software

and application software, covering all participants;

2. Operation of the above system components;

3. Testing of parameter-level changes made by the system

operator.

It is expected that the initial system implementation will follow this

process.





88


4.11 Operational Requirements

4.11.1 Daily Processing Cycle

N/A

BCTL will publish an annual schedule giving the daily processing

cycle for the system. The timing and duration of different

processing windows will be agreed between BCTL and participants.

The system operating hours will be flexible and capable of

adjustment to cater for abnormal circumstances.

For certain classes of payments (queues) it must be possible to

suspend daily operation and restart on another day while retaining

the same value date.

4.11.2 Start/End of Day With the exception of security provisions, any procedures related

to the start/end of day activity should normally be handled

automatically, but be capable of being run manually in case of

disruptions to the normal daily schedule.

4.11.3 Performance Monitoring N/A

The performance of all components of the system will be

monitored on an ongoing basis, and relevant exception reports will

be produced with suitable highlights whenever system

performance falls outside accepted performance standards.Proposals should include details of proposers’ recommendations





89


covering at least the following:

1. A performance monitoring system, including an events monitor

integrated with the dashboard described in 4.8.2, which depictscritical operational and security events including the

operational status of all authorised users and attempts to

access the system by unauthorised users;

2. A reporting system which can be used to monitor the quality of

the service and provide appropriate tailored information to all

participants.

Proposers should describe how the different measures should be

monitored and, where appropriate, also give an indication of the

levels of performance they typically expect to achieve. The

measures should include the following:

System Availability

The System Availability measure should capture the percentage of

normal business hours in which each system component is

delivering service to participants regardless of the source of any

service disruption e.g. hardware, software, network, power, human

error.

Message throughput

Message throughput should be monitored and reported against atleast the following parameters:





90


1. The number and value of RTGS messages per day by payment

type, stream (queue) and participant and in total;

2. The number and value of RTGS messages processed during thepeak hour;

3. Average time in queue of RTGS messages by queue, by

participant and in total per day;

4. The volumes and values of ACH payments by instrument type

and clearing session.

Proposals should describe all available tools to collect and maintain

statistics for both BCTL and participants.

4.11.4 Operational Rules and Procedures Proposers will be expected to advise and assist BCTL in developing

and implementing rules and procedures (for both BCTL and

participants as applicable) for operation of the system. This must

include provision of suitable sample documentation which BCTL

can adapt.

4.12 Billing Information

The ATS must include a flexible billing mechanism which will

automatically calculate fees for each participant, and which should

have the following functionality:

1. Enable fixed periodic charges (e.g. annual or monthly




y ( )

91


membership fees) to be levied;

2. Calculate usage fees based on message or instruction type;

3. Apply value modifiers by message during time bands during the

day;

4. Apply value modifiers for different payment streams (queues);

5. Apply value modifiers for volumes of transactions;

6. Allow for different charges according to participant;

7. Apply charges directly to participants’ accounts, with no

manual intervention other than authorising the transaction;

8. Automatically create invoices to be sent to all participants.

The billing and invoicing interval/cycle should be flexible and able

to be set by BCTL.

Proposers should fully explain the options and capabilities of the

charging and billing functionality, including the automatic

generation of relevant messages to participants. The supplier will

be expected to advise and assist BCTL in developing and

implementing a suitable pricing and billing policy.

4.13 Hardware, Software and Communications

The ATS will run on dedicated hardware installed in two sites,namely the primary processing site and a DR site situated at a

N/A




y ( )

92


distance from the primary site, as follows:

1. The live system will be installed on servers at both sites. The

equipment at each site should be sufficient to run the entiresystem should the other site become unavailable, but in normal

operation BCTL expects that the systems at the two sites will be

coupled in such a way that a failure of any single server (for

example) will have no effect on the operation of the system.

Proposals must contain recommendations as to how the two

sites will be equipped and coupled to enable the highest level

of availability.

2. Proposals should also contain details of how suitable failover

procedures will be developed and tested to allow for situations

of multiple failures or complete unavailability of one site. BCTLexpects that the supplier will take an active part in developing

and thoroughly testing failover procedures to cover all possible

situations involving both BCTL and participants.

3. A test and training system will be installed at the central site.

This will be used as required for testing of changes to the

software, training of staff, etc.

Proposals must give full details of all hardware, system software,

middleware and any other products and equipment necessary to

run the system. The supplier will be required to provide contractual

assurances that the agreed total configuration (hardware,networking and software) will support the system in processing




y ( )

93


expected workloads for at least three years after acceptance.

4.13.1 Hardware N/A

Proposers must specify full details of all hardware elements

recommended to operate their proposed solution. These should

include details of any hardware that may need to be installed by

participating organisations.

All components of the system will be required to operate without a

need for upgrade for a period of at least three years from

operational acceptance and the hardware should be sized

accordingly. Hardware recommendations should include all

necessary related services and should cover (as applicable):

Servers

Proposals must specify in detail all recommended server

components, covering application, data and any other required

servers (e.g. web or certificate servers and their associated

software), together with any items necessary for connection to

BCTL’s existing IT environment, and all operating system options.

Data Storage

Proposals must specify in detail the recommended data storage

capacity and equipment. This should be supported by sizing

information on the capacity required to hold all copies of the

system database(s) and any other supporting data, based on the




94


current and forecast volumes given in this RFP. Proposals should

allow for the last five plus the current year’s data to be held in the

on-line database and up to ten years’ data on a secondarydatabase. These requirements will be discussed in more detail with

the supplier.

User Workstations

BCTL expects that the system will use existing PCs as user

application workstations. Proposers should specify both minimum

and optimum configurations required.

Other Hardware

Proposals should include details of any other hardware required by

their solution.

4.13.2 Software N/A

Participant Software

In addition to software required at BCTL, proposals must specify in

detail all software products (required and optional) that may need

to be installed by each participating organisation, including

requirements for STP.

System Software and Middleware

In addition to server operating system(s), proposals should clearly

specify in detail any other system software and middleware items




95


that will be required to run the ATS.

Database Software

Proposals should describe all DBMS products on which their

solution will run, as well as any recommendation as to their

preferred option, noting that BCTL already has Microsoft SQL

Server products installed and that it has a strong preference to

minimise the number of different DBMS products that it has to

support. Proposals must specify the nature and number of DBMS

licences that will be required. Any dependencies with hardware

and operating system options should be set out clearly.

Proposers should provide a description of any special facilities of

the database management software which are utilised by theirapplication, for example automatic database replication to

facilitate high availability.

Report Writer

Proposals should recommend a standard easy-to-use database

report generation tool that can be used for the rapid development

of reports to satisfy needs that might arise on an ad hoc basis.


Proposers should specify in detail all communications

requirements for their solutions, covering both BCTL (both

processing locations) and all participating organisations, including




96


performance, security, reliability, backup capability, bandwidth and

any other relevant considerations.

4.14 AML/CFT N/A

The ATS should include functionality to support the Anti Money

Laundering/Countering Financing of Terrorism (AML/CFT) activities

of BCTL and the Financial Intelligence Unit (FIU) which has been

established within BCTL. In this respect it should be capable of

examining all payments as it processes them and comparing their

contents against a database of ‘items of interest’. The database will

hold information on persons, organisations and other subjects

which have been identified as suspicious.

The AML/CFT function should be capable of:

1. Importing a variety of standard Watch-Lists from international

bodies such as the US Office of Foreign Assets Control (OFAC),

central banks such as the Bank of England, the European

Central Bank and the Bank of Japan, and other providers such

as Accuity;

2. Being updated whenever required with information on ‘local’

subjects of interest which have been identified by the central

bank or the FIU.

3. Being updated by central bank staff with local exceptions(entities known to be not suspicious).




97


The AML/CFT functionality should operate seamlessly within the

ATS. Whenever it identifies a match between any of the contents

of a payment message and an item in its database, it should holdthe payment and raise an alert to a previously-identified user for

analysis. This user should be able either to clear the payment (in

case of a false alert), suspend it or cancel it.

The AML/CFT functionality must be integrated with the RTGS

element of the ATS, and should also be capable of operating with

ACH payments.

The system must maintain a detailed audit trail of all AML/CFT

activities.

Proposers should fully describe the above and all other features ofthe AML/CFT capabilities of their proposed systems.




98

5. Specif ic Function al Requirements for the ATS


The Automated Transfer System (ATS) will provide for the

submission, processing and settlement of all inter-bank payments,

both large and small. As specified in 3.1, it will comprise two

tightly-integrated elements, namely ACH and RTGS.

N/A

5.1 Objectives

The objectives of the ATS are to:

1. Improve the quality of payment services to speed up circulation

of funds and increase efficiency of funds transmission, while

providing convenience, improved levels of service, and a

greater range of services to bank customers;2. Provide efficient and cost-effective clearing and settlement

capabilities for all interbank payments, with the ability to

handle significant future growth in volumes of payments;

3. Achieve real-time settlement of payments between its

participants in the books of BCTL to deliver irrevocability and

finality of payments;

4. Provide facilities to increase the efficiency of daily liquidity

management by BCTL and participants through the provision of

real-time settlement account information reporting andmonitoring;

N/A




99


5. Minimise payments system risk by managing liquidity on both

an individual participant basis and system-wide;

6. Achieve a reliable, safe, and integrated payments andsettlement system to meet the needs of a developing economy,

with the ability to be extended to:

a. Process new payment instruments;

b. Provide tools for BCTL to implement monetary policy;

c. Support new payment and clearing systems as they may be

developed;

d. Integrate with a possible future securities depository to

ensure that transactions in securities are settled safelyfollowing the principle of DvP.

As previously explained, BCTL wishes to procure a modern

integrated solution which is capable of clearing and settling all

types of electronic instruments in a conceptually single electronic

system. The ATS should contain the ability to provide different

processing modalities for high value/time critical payments (to be

handled by the RTGS element) and low value/retail payments (to

be processed using the ACH element), but these must be

integrated in such a way as to provide a single coherent interface

to participants. Proposers should therefore describe all types ofpayment instruments and arrangements that their proposed




100


solution can handle.

5.2 ACH Element – Clearing Functionality

In the first instance the ACH element will handle the processing of

direct credit payment instructions. The proposed software package

must also have the capability of processing direct debits so that

these can be introduced in Timor-Leste at a future time should the

banking community decide to do so. Proposals should also describe

any other streams of high-volume low-priority payments that their

software can process.

N/A

5.2.1 Direct Credits

Proposals must contain full details of how low value (retail) direct

credit payments are handled in the ACH element, whether they aresubmitted on an individual or batch (file) basis.

The ATS must have the ability (optionally, controlled by BCTL) to

permit visibility of incoming payments, i.e. a participant can see

payments to itself which have been submitted by other

participants but which have not yet entered a clearing session.

5.2.2 Direct Debits and others

For future consideration, proposals must describe in detail how

Direct Debits (and any other instruments that the ACH element is

capable of processing) are handled in their proposed solution.




101


5.2.3 Clearing

Proposals must contain details of all options provided by the ACH

element for clearing the foregoing stream(s) of payments (e.g.continuous or deferred netting) and how the resulting positions are

settled in the RTGS element.

5.3 RTGS Element N/A

5.3.1 RTGS Transactions

BCTL expects that the RTGS element of the ATS will handle

settlement of the following:

1. High-value and/or high urgency bank-to-bank payments

including payments to banks’ customers;2. High-value and/or high urgency payments from and to

Treasury;

3. High-value and/or high urgency payments of taxes to Revenue,

each of which will carry sufficient identification information to

enable it also to be posted to the correct account in Revenue’s

tax accounting system SIGTAS (see 5.7.4);

4. Payments of Customs duty to Treasury, each of which will carry

sufficient identification information to enable it also to be

posted in real time to the correct account in Customs’management system ASYCUDA (see 5.7.4);




102


5. Net interbank positions from the ACH clearing element of the

ATS;


It will also be able to handle other types of payment in future, as

new systems are introduced into Timor-Leste, such as:

1. Settlement of net interbank obligations from other clearing

houses such as payment card and mobile phone payment

processing centre(s);

2. (Future) transactions involving purchase and sale of securities

(on both primary and secondary markets) in accordance with

the principles of Delivery versus Payment (DvP) and STP (as and

when the GOTL and /or BCTL start issuing securities);

3. (Future) settlement of transactions on trading platforms such

as a potential Stock Exchange and an interbank money market

system.

5.3.2 Operating Currency

As previously noted, Timor-Leste uses the USD as its official

currency at present. This means that accounts in the ATS will be

denominated in USD, which affects BCTL’s ability to advance

intraday credit to participants, particularly as there are no

securities (hence no automated Securities Depository) which can

be used as a convenient form of collateral for such lending.




103


However, the National Development Plan requires a review of the

currency to be completed by 2015, and the Central Bank wishes to

have systems in place that would support the introduction of aTimorese currency in the event that such a decision were to be

made. Proposers should describe how their ATS would be

implemented to use USD as its working currency, and what

changes/developments would need to be made in the event that a

Timorese domestic currency is introduced.

5.3.3 Settlement of Securities Transactions

At the present time neither BCTL nor the GOTL issues securities of

any kind. However, it is possible that either or both institution(s)

may decide to do so in future. In order to cater for this possibility,

the RTGS element must be able to support a linkage to a securities

registry system for the settlement of securities transactions which

may include:

1. BCTL primary market operations for issuing securities;

2. Open Market Operations of BCTL;

3. Intraday liquidity management and other monetary policy

operations of BCTL;

4. Settlement of secondary market transactions in securities.

For all such transactions, the principle of STP must be guaranteed

and the operational interaction between the ATS and a securities




104


registry system must guarantee Delivery versus Payment (DvP).

Proposals should contain details of how the proposed ATS can

support these operations.

5.3.4 Queue Management and Processing Priorities N/A

The RTGS element of the ATS will operate on the basis of multiple

payment streams or queues. Proposers should describe in detail

the queuing mechanisms offered by their proposed solutions

(including the maximum number of queues and queue types).

Characteristics should include at a minimum:

1. The ATS should have the capability to ‘warehouse’ certain types

of individual transactions for execution at a forward date and

time, as specified by the submitting participant. The permittednumber of forward days must be able to be set, and changed if

desired, by BCTL.

2. Queues will have different levels of priority. Participants must

be able to assign priority levels to all payments submitted.

3. Queues will operate on a “first in, first out” (FIFO) basis, unless

specific gridlock resolution routines are invoked by BCTL as

operator.

4. The construction and operation of the queues must enable the

treasurers at each participant to be reasonably sure that the

payments they submit are generally processed according to theorder in which they are submitted.




105


5. Payment orders will be held in each queue by participant, in

the order in which the participant despatches them and

according to the priority code assigned by the participant

(there will be, conceptually at least, one queue for each priority

level per participant). Each participant will manage only the

queues for the payments that it has issued.

6. No lower priority transfers will be settled until all higher

priority transfers are settled. The payment order at the top of

the queue is settled when funds are available and only then is

the next order in the queue considered for settlement.

7. In order to facilitate daily liquidity management, the system

should offer participants the ability to change the priority of

queued payments and/or position within the queue.

8. The RTGS element must be designed to avoid gridlock which

could lead to systemic failure, and must contain a gridlock

resolution mechanism.

9. The ATS must provide automatic queue management or

intervention facilities to BCTL at the level of analysis, with

calculated solutions being offered to BCTL operators for

implementation. Such facilities should include reordering,

optimisation routines etc.

10. Should any gridlock resolution be used either automatically or

manually by BCTL, system participants should be notified.

11. Each participant and BCTL must be able to enquire into the

aggregated information about the total number and amount of




106


that participant’s transfers in the queues.

12. The originating participant must be able to cancel a payment

transaction held in the queue. A payment transaction can only

be cancelled if it has not already been settled.

13. Transactions with same-day value not settled by the end of the

operating day will be cancelled (with advice to the participant).

14. The system must have the optional ability (controlled by

BCTL).to permit visibility of incoming payments, i.e. such that a

participant can see payments to itself which have been

submitted by other participants but which have not yet been

settled (i.e. credited to its settlement account).

5.4 Accounting Considerations

The introduction of the ATS will entail a number of changes toBCTL’s financial management arrangements, as described below.

As previously described, BCTL is currently in process of procuring a

new financial management system, which is expected to be

installed prior to, or shortly after, the start of the ATS

implementation project. The ATS supplier will be required to work

closely with the supplier of this system to agree and implement the

necessary linkage(s).

5.4.1 General Ledger Accounts N/A

BCTL intends that the banks’ Settlement Accounts and the CFETAccount will be moved from the GL to the ATS, which will manage




107


them and control all transactions passing through them. Any

transactions which do not originate in the ATS (of which there are

expected to be only a small number) will be manually posted to

these accounts, e.g. via participant debit and credit instructions.

They will be replaced by control accounts in the GL, and the ATS

will pass the necessary information to the GL to maintain the

integrity of these control accounts.

As previously noted, BCTL pays interest on the CFET Account. The

ATS should therefore be able to calculate interest on a daily basis

and credit it automatically to this account at end of month.

Proposers should provide detailed recommendations as to how the

linkage between the ATS and the GL will be implemented.

5.4.2 Accounts Payable

The Accounts Payable (AP) module of the new financial accounting

package will be linked to the ATS for the purpose of automating

BCTL’s own payments processing for both large value (RTGS) and

retail (ACH) payments. Proposers should provide detailed

recommendations as to how the linkage between AP and the ATS

will be implemented (note that it may be necessary for the ATS to

carry out some reformatting of electronic payments received from

AP into suitable MTnnn or ISO 20022 instructions if the accounting

system does not have the ability to create these).




108


5.4.3 Collateral Accounts

As described in 2.3.1, the Collateral Accounts, which are used to

hold funds against any bank’s potential inability to cover its debitliability arising from cheque clearing house operations, will be

removed from the GL. This is because all interbank settlements will

take place in the RTGS element the ATS. Clearing house net

positions will therefore be settled via manual entry of the net

positions into the RTGS element.

N/A

Nevertheless, BCTL still wishes to enforce the requirement for

banks to set aside funds to cover their cheque clearing house

obligations, and not use them for any other purpose. Proposals

should describe the facilities available for achieving this. To assist

this, the ATS software must be able to calculate the ‘Collateral

Account’ requirements (i.e. each bank’s maximum clearing house

debit position in the previous 60 days) on a rolling monthly basis

and, if desired, automatically adjust the balances in the banks’

RTGS ‘collateral reserves’ accordingly.

As previously noted, BCTL pays interest on the banks’ Collateral

Accounts. The ATS should therefore be able to calculate interest on

a daily basis and credit it automatically to these accounts at end of

month.

5.5 Liquidity Management

Liquidity management is a critical element in the efficient and




109


effective operation of an ATS, and therefore BCTL intends to give

significant weight to these proposed facilities and functions in the

proposal evaluation process. Proposers should therefore be careful

to explain their liquidity management features and options

(including any option for interfacing to an external Collateral

Management System) in detail in their proposals, and also provide

a clear demonstration and discussion of these features in the

proposal presentation meetings.

5.5.1 Sources of Liquidity

Sources of liquidity in the settlement account may be:

1. Correspondent accounts;

2. Cash deposits;3. Incoming transfers from other participants;

4. Borrowing from other banks;

5. (Potentially) credit extension from BCTL.

N/A

5.5.2 Extension of Credit from BCTL

At the present time BCTL does not intend to create credit/loan

facilities for banks. However, it may do so in future. Proposals

should therefore contain details of how the proposed ATS package

can support intraday, overnight and longer-term loans.

5.5.3 Currency




110


As noted earlier, the fact that Timor-Leste uses the USD as its

official currency may be a constraining factor on BCTL’s ability or

willingness to extend credit to banks for the purpose of liquidity

management in the ATS. However, should a Timorese currency be

introduced, this may also open up broader possibilities. Proposals

should contain full details of all liquidity support functionality

offered by their ATS packages, both in a USD-only environment and

in case of a dual- (or possibly multi-) currency enviroment.

5.5.4 Earmarking Funds in Settlement Accounts N/A

Either BCTL or the participant itself should be able temporarily to

reserve or earmark a quantity of the funds in a participant’s

settlement account up to a given level to cater for known demands

(for example to replace the present Collateral Accounts, forpurchase of cash from BCTL or for settlement of ACH net

positions). In such cases the earmarked funds may not be used to

settle any ATS transactions other than those for which the

earmarked funds are intended.

It should be possible to set an earmark for a forward date. For

example, banks generally order cash the day before they require

delivery, in which case the earmark for cash purchase should be

warehoused for execution the day after it is made.

5.5.5 Credit Limits

The ATS should offer the optional ability to set credit limits, both




111


bilateral and multilateral, to limit participants’ exposures.

5.5.6 Liquidity Problems

The system should notify BCTL and the affected participant about

any developing liquidity problems. The system should be able to

monitor and provide notification of conditions including:

1. The possibility of an account balance below a minimum level;

2. A payment order larger than a specified amount;

3. Details of payments rejected due to insufficient funds.

Proposals should contain details of all such conditions which can be

monitored.

5.6 Cash Withdrawal and Deposit N/A

As the central bank, BCTL has responsibility for the circulation of

cash, both notes and coins. At present all procedures associated

with the withdrawal and deposit of cash are manual. Proposers are

requested to describe how their ATS products would support the

processes of cash withdrawal and deposit to provide a risk-free

solution with minimum manual operation.

5.6.1 Withdrawal

A suggested procedure for cash withdrawal is as follows:

1. The participant which wishes to withdraw cash sends a

withdrawal request in the form of an RTGS MT202 message




112


crediting BCTL, giving details in field 72 of the denominations it

wishes to withdraw, to the ATS, and specifying the day on

which the withdrawal is to take place (normally the following

day). This alerts the ATS that a cash transaction has been

requested.

2. On receipt of the MT202, the ATS advises BCTL ’s vaults staff

immediately, either by a pop-up message or by email (or the

vaults staff may have direct access to an ATS workstation).

3. The ATS warehouses the MT202 for execution at start of day on

the required value date.

4. On the value date, the MT202 is settled in the ATS at system

start of day and, once settlement has occurred, the ATS sends amessage to the vaults staff authorising the release of the cash

(or vaults staff can check via an ATS workstation). The ordering

bank receives confirmation of settlement as for any other RTGS

payment.

5. Also at the start of the value day, the vaults staff assemble the

cash order for collection.

6. Once the payment has been settled and the order has been

assembled, the ordering bank can collect the cash. If the

payment has not been settled by the due time for collection,

the vaults staff will refuse to hand over the cash.




113


7. Finally the vaults staff post the necessary journal entries to

BCTL’s GL.

5.6.2 Deposit

For cash deposit, the vaults staff will receive the cash and raise a

participant credit advice for the amount deposited, which will be

input to the ATS by BCTL Payment Systems staff, along with

corresponding postings to the GL. Alternatively, if permitted by

BCTL, vaults staff might be able to post a participant credit

instruction directly to the bank’s Settlement Account in the ATS.

5.7 Management of Government Transactions N/A

BCTL wishes to make maximum use of the ATS to make GOTL

payments and receipts as efficient, fast, convenient, cost-effectiveand safe as possible. To this end the ATS will be interfaced to the

financial processing systems of GOTL agencies as specified in 5.7.1

– 5.7.4.

BCTL expects that the supplier will dedicate a high level of business

and technical expertise to ensuring the successful specification and

implementation of all these interfaces. Proposers must include in

their financial proposals sufficient allowance for the necessary

consulting, software development and implementation effort to

achieve this.

5.7.1 Domestic Payments by Treasury N/A




114


As described in 2.6.1, Treasury operates an all-of-Government

FMIS using the FreeBalance accounting software package, which is

used to create all GOTL payments and to account for revenue

receipts. When the ATS is implemented, Treasury will become a full

participant. The CFET account will be moved to the ATS and will be

used in the same way as banks’ Settlement Accounts for making

and receiving payments (both RTGS and ATS).

The ATS will generate and transmit to FreeBalance a detailed daily

statement of movements in the CFET account. The format of this

statement will be agreed between BCTL, the ATS supplier and

Treasury such that it can be used for automated reconciliation in

FreeBalance.

The supplier will be required to specify and develop any requiredmodifications to the ATS software to handle an interface to

FreeBalance. The supplier will also work with BCTL, Treasury’s

FreeBalance team and the Financial Management Information

System Unit of the Ministry of Finance to assist in implementing

the required linkage between the ATS and FreeBalance.

5.7.2 International Payments by Treasury

BCTL wishes to provide the facility for Treasury to make its

international payments (see 2.6.2) automatically using the ATS. A

suggested way of achieving the requirement is as follows (note thatthis will require the ATS to have an electronic interface to BCTL’s




115


SWIFT terminal):

1. Treasury sends an MT103 payment instruction to the ATS with

a transaction code indicating that it is an internationalpayment.

2. The ATS:

a. Debits the amount from the CFET account;

b. Reformats the MT103 message to contain the name and

Bank Identifier Code (BIC) of the correspondent bank and

BCTL’s BIC as the Sending Institution, rather than the BIC of

the ATS (if the ATS is implemented to use SWIFT as one of

its carrier networks); and

c. Passes it via the Local Area Network (LAN) to BCTL’s SWIFT

terminal where it is entered into the queue for validation

and approval prior to being transmitted. (All SWIFT

payments require three manual steps: input, validation and

approval. This arrangement will replace the first, but not

the second or third, steps).

Proposers should comment on the above and recommend an

alternative approach should they wish.

5.7.3 Revenue

The present arrangement for collection of tax payments is

described in 2.6.2, where it is noted that Revenue currently uses a




116


very old version of the SIGTAS software package, which is likely to

be either upgraded or replaced during the implementation period

of the ATS. As also noted in 2.6.2, the present tax payment process

is cumbersome and restrictive, and involves a considerable amount

of manual keying of data between systems in BNU, Revenue and

Treasury.

As part of the ATS project BCTL plans, in consultation with Revenue

and the commercial banks, to introduce a facility whereby any tax

payment can be made electronically through the ATS from any

bank, either using an on-line banking service or by requesting the

payment in person at a bank branch. This will require the bank to

capture sufficient information about the payment, which Revenue

can subsequently use to update the taxpayer’s record in SIGTAS (or

its replacement), as follows:

TIN (7 characters)

Tax type (4 characters)

For period ending (date)

Paid on (date)

Amount ($$)

Banks will obviously need to modify their CBSs to capture these

fields and to create customised electronic payment instructions in

both RTGS and ACH formats (depending on the amount of thepayment) for transmission to the ATS. All such payments received




117


by the ATS will be either settled immediately (if made via the RTGS

element) or cleared through the ACH element (if below the value

threshold for ACH payments) and then settled. In any case, the ATS

will accumulate the above-mentioned data fields for each payment

and forward them as a bulk file, in a format to be agreed, to

Revenue either on demand or at an agreed time each day (e.g. end

of day). Revenue will then apply them as updates to its taxpayer

database.

In collaboration with BCTL, Revenue and Revenue’s software

provider, the supplier will be required to specify and develop any

required modifications to the ATS software for this. The supplier

will also work with these entities to assist in implementing the

required linkage between the ATS and SIGTAS (or its replacement).5.7.4 Customs

The present arrangement for collection of Customs duties is

described in 2.6.3. BCTL has been in discussion with Customs as to

how the introduction of the ATS can improve the payment process

and thus, not only make revenue collection more efficient for

Customs and convenient for brokers, but also contribute to

relieving congestion of containers at the port. Proposers are

requested to comment on, and/or suggest improvements or

alternatives to, the suggested procedure below, which has been

discussed between BCTL and Customs. Financial proposals should

include an allowance for the necessary consulting, software




118


development and implementation effort to achieve this.

This procedure assumes that electronic connections are in place

between: (i) brokers and their banks’ CBSs; and (ii) the ATS andASYCUDA. It also assumes that at least one of the commercial

banks will make the necessary amendments to its CBS so that this

facility can be offered as a service to its customers. It may

additionally require some changes to ASYCUDA.

1. As at present, the broker enters details of the import entry

(Customs Declaration) into ASYCUDA, which processes it,

calculates the duty payable and outputs a set of data fields

which uniquely identify the transaction (broker ID, shipment

reference, etc.) .

2. Using these data fields the broker, either manually or via its in-

house IT system, requests a Customs payment from its bank,

via Internet banking, a secure on-line connection to the bank,

or in person at a bank branch.

3. The bank’s CBS creates an RTGS payment instruction containing

the data fields (e.g. customised MT103) in favour of the CFET

account in BCTL and sends it to the ATS.

4. Subject to the normal queuing rules, etc., the ATS settles the

payment immediately and notifies the bank in the usual way as

for any RTGS payment.




119


5. Immediately the payment is settled, the ATS also generates and

sends a message to ASYCUDA containing details of the

payment.

6. (Optionally) the bank notifies the broker that the payment has

been successfully made. Alternatively the broker could get

confirmation of payment via ASYCUDA.

7. The relevant record in ASYCUDA is automatically updated to

record the payment, and the shipment is therefore cleared for

collection (subject to any requirements for inspection).

The supplier will be required to specify and develop any required

modifications to the ATS software. The supplier will also work with

BCTL, Customs and Customs’ ASYCUDA support consultant to assist

in implementing the required linkage between the ATS and

ASYCUDA.

5.7.5 Other Government Payments

As noted in 2.6.6, a number of GOTL agencies or state-owned

enterprises collect payments, including licence and registration

fees, fines, harbour dues, utility payments and so on. BCTL is

interested in exploring with proposers and the eventually-selected

supplier the possibility of developing a standard form of electronic

payment, including documentation, arrangements with commercial

banks, procedures, and so on that can be used across all such




120


entities and payment types.

5.8 Interface to Participant Bank Systems N/A

5.8.1 Messages

BCTL’s preference is for the system to use ISO 20022 message

formats for all messages, both RTGS and ACH. However, it is

acceptable to use ISO 15022 (SWIFT MTnnn) formats for RTGS

messages.

Proposers should provide information on all standards that their

systems follow, particularly their forward development plans in this

area.

5.8.2 Manually-Entered Payments

Single RTGS payments must be able to be entered manually from

either a single dedicated PC for smaller institutions or any number

of authorised workstations and users on the LAN in the case of

larger participants.

5.8.3 STP N/A

It must be possible for participants to submit either single or

multiple RTGS payments directly to the ATS from their internal

CBSs. For batches of Direct Credits to be cleared in the ACH

element, it must be possible for these to be assembled anduploaded to the system either fully-automatically (STP) or under




121


the control of an authorised user. The same should apply in the

opposite direction to incoming RTGS messages and files

downloaded from the ATS (such as files of cleared payments from

the ACH element, rejection notifications, end of day reports and so

on).

The ATS must therefore provide standard linkages to enable STP

for all payment types. This will require participants to carry out the

necessary systems work to integrate their CBSs with the ATS. The

selected supplier of the ATS will be required to work with the

commercial banks to assist them to do this, to provide full interface

specifications for implementation of STP at no charge, and to

provide any necessary technical support and advice during the

implementation process, again at no charge. Proposals should alsocontain full details of any software modules that are available to

facilitate STP at participants’ sites, to which their internal CBSs can

be interfaced.

5.9 Monitoring and Reporting N/A

The ATS must provide a comprehensive and flexible set of

monitoring, reporting and analysis capabilities, to enable each

participant to have maximum information about, and control over,

its participation in the system (analogous to the way users of

online banking services can control all activities of their various

accounts themselves via an internet web browser connection).




122


The monitoring, reporting and analysis capabilities should cover:

1. Intraday monitoring reports;

2. End of day reports;

3. Reports on historical system activity.

In the case of participants other than BCTL, these facilities must be

strictly confined to their own participation in the system, whereas

BCTL must be able to get information on the operation of the

entire system.

The intraday monitoring facilities should be available on demand,

while the end of day reports should be provided automatically to

specified users within both BCTL and participating banks.

The historical analysis facility should provide a wide range of

capabilities, including both a flexible database enquiry capability

and also the ability to download extracts from the historical

database for further analysis using tools such as statistical analysis

or spreadsheet packages. This facility will be available to non-BCTL

participants only via requests to BCTL Payment Systems

Department.

The historical database must be held separate from the online

(current day’s) database, for reasons of both performance and

security. BCTL will agree with the supplier how many months’historical data should be held online (as opposed to offline




123


archiving) during system implementation.

5.9.1 Intraday On-line Information for BCTL

The ATS should provide at least the following information to BCTLoperational users, authorised departments and auditors:

1. Single message and input batch file status;

2. Total daily, weekly, monthly, and annual activity (for each

originating participant and receiving participant);

3. Possible duplicate message reports;

4. All account balance information, by participant;

5. Enquiry into payment instructions in the system (allowing for

different selection criteria);

6. Alerts when queues build up beyond defined limits in terms

either of number of payments or of amounts to be paid. Such

limits will be defined by BCTL;

7. Summarised security reports regarding unsuccessful log-on

attempts, invalid messages (with reason for invalidity);

8. A graphical display showing the status of payment queues, and

indicating areas of gridlock etc. Such a display would be

incorporated into the ‘dashboard’ described in 4.8.2.

5.9.2 Intraday On-line Information for Participants




124


The following will apply to participants: 1. Participants will receive an immediate message for all

payments made or received by them;2. In case of a service disruption at a participant, BCTL must be

able as soon as possible to notify all other participants of the

situation and of any extension of the normal operating day that

may result from this situation;

3. A participant must be able to trace any individual transaction or

batch through all stages of processing;

4. Participants should be able to enquire on the status of their

payment queues throughout the day as well as the running

balance of their settlement/CFET accounts. The ATS shouldprovide at least the following information to participants:

a. Enquiry access to the participant’s own account balance

and transactions which have been settled during the

current day;

b. Enquiry into payment instructions in the system (allowing

for different selection criteria);

c. Notification of the status of payment instructions

sent/received debited/credited, whether successfully

processed or rejected;




125


d. Validation error description;

e. Enquiry access to their own outgoing RTGS queues;

f. Enquiry into calculated intraday daily average balances;

g. Transaction activity and charges;

h. In addition to the online flow of information during the

processing day, the ATS should have the ability to provide

each participant with an electronic file containing

sufficiently detailed information to support automated

account reconciliation. This information can be sent

throughout the day in response to requests received from

the participant;

i. A full, daily statement will be sent to each participant aspart of end-of-day processing.

5.10 Account Maintenance and Monitoring N/A

5.10.1 Account Opening and Closure

BCTL will have the authority to open, close or suspend any

participant account held within the system. If an account is

suspended, no outgoing payment transactions may be made, but

the system should enable BCTL either to permit or to disallow

incoming payments to be received.

5.10.2 Maintenance of Intraday Credit Limits




126


BCTL will have the authority to determine and operate all

arrangements relating to the provision of intraday credit.

5.10.3 Account Monitoring by BCTLFor system management purposes, BCTL will have access to all

participant account information. The ATS should have

comprehensive facilities to display online information on the

overall liquidity situation of the system, both continuously

throughout the operating day and as a snapshot for the current

period and compared to previous period (hours, days, and weeks),

via the dashboard capability described in 4.8.2.

5.10.4 Account Histories

The ATS should maintain on-line records of settlement/CFETaccount transactions for the current month and archives of the

historical data for at least five years. The ATS should provide a

range of graphical capabilities to assist activity and liquidity

monitoring; for example, a graphical display representing the

number of queued payments per bank and the current

performance indicators.

5.11.1 Participants

The participants in the ATS will be:

BCTL;

the four commercial banks;

N/A



Date post:	04-Jun-2018
Category:	Documents
Upload:	helio-araujo
View:	213 times
Download:	0 times

BCda333TL-RFP4AsewTS-Fineweal

Documents