BANCO CENTRAL DE TIMOR-LESTE. National Payments System Development Project. Request for Proposals for an Automated Transfer System

BANCO CENTRAL DE TIMOR-LESTE National Payments System Development Project Request for Proposals for an Automated Transfer System Dili, Timor-Leste 5 August 2013

BCTL 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 4.1 PRINCIPLES... 24 4.2 OPERATIONAL... 24 4.3 INTEGRITY... 25 4.4 TRANSACTION AND FILE PROCESSING CONTROLS... 26 4.5 VALIDATION CONTROLS... 26 4.6 MESSAGE INTEGRITY AND ACCOUNTABILITY... 27 4.7 SYSTEM OPERATION... 27 4.8 ENQUIRY AND REPORTING... 28 4.9 SECURITY... 29 4.10 PROCESSING REQUIREMENTS... 31 4.11 OPERATIONAL REQUIREMENTS... 32 4.12 BILLING INFORMATION... 33 4.13 HARDWARE, SOFTWARE AND COMMUNICATIONS... 34 5. SPECIFIC FUNCTIONAL REQUIREMENTS FOR THE ATS... 37 5.1 OBJECTIVES... 37 5.2 ACH ELEMENT CLEARING FUNCTIONALITY... 38 5.3 RTGS ELEMENT... 38 5.4 ACCOUNTING CONSIDERATIONS... 41 5.5 LIQUIDITY MANAGEMENT... 42 5.6 CASH ISSUING AND RETURN... 44 5.7 MANAGEMENT OF GOVERNMENT TRANSACTIONS... 45 5.8 INTERFACE TO PARTICIPANT BANK SYSTEMS... 48 5.9 MONITORING AND REPORTING... 49 5.10 ACCOUNT MAINTENANCE AND MONITORING... 51 5.11 PARTICIPANTS AND VOLUMES... 51 i

BCTL 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 QUALIFICATIONS... 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 ii

1. Introduction and Background 1.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 northwestern side of the island within Indonesian West Timor. The country's area is a little less than 15,000 km 2. History Following Portuguese colonial rule which lasted from the 16 th century until 1975 (apart from a period of Japanese occupation during the Second World War), 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 the referendum, United Nations peacekeeping troops deployed to the country and helped bring the violence to an end. Democratic elections were held in August 2001 and Timor-Leste became a fully-independent sovereign state on 20 May 2002. In 2006 and 2007 there were further internal upheavals and further United Nations assistance was rendered, culminating in a peaceful election. There was a failed attempted coup in early 2008 and since then the country has enjoyed stability and peace. Economy Timor-Leste is one of the poorest countries in the Asia-Pacific region, with a Gross Domestic Product (GDP) per capita of USD 3,704 1. It is also the fastestgrowing economy in the Pacific region with forecast growth of 9.5% in 2013 2 due to substantial petroleum revenues. As a result it is one of the most heavily petroleum-dependent economies in the world. It was the relative abundance of sandalwood that attracted European explorers to the island in the early 16th century, and subsequently sandalwood remained the main export crop, with coffee exports also becoming significant in the mid-nineteenth century. Agriculture still plays an important part in the non-oil economy, accounting for over 30 per cent of 1 Trade Advocacy and Statistics Section, Australian Department of Foreign Affairs and Trade, 2013 2 Asian Development Bank Pacific Economic Monitor, July 2013 1

GDP and around 75 per cent of employment. However, relatively low food production by small-holders and the low level of development of local markets 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. Petroleum Timor-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 the year. On 13 July 2011 the Timorese Government released a Strategic Development Plan, which provides a framework for development for 2011-2030 3. 1.2 National Payments System Development Programme Banco Central de Timor-Leste (BCTL) is the central bank of Timor-Leste and has, as one of its functions established under the Organic Law of the Central Bank of Timor-Leste 2011 to establish, promote and oversee sound and efficient payments and securities settlement systems. In its Corporate Plan BCTL has set out the following key objectives as they relate to payment systems: To review the safety and efficiency of the payments system, and work with banks to modernise the payments system; To monitor the need for electronic payments and clearing systems; To collect and publish data on payment systems; To establish a nationwide system to improve access of the public for making payments to the government. Further information on BCTL can be found on the website: http://www.bancocentral.tl/ In recognition that the payments system is an integral part of the financial system of every country, and is vital for its soundness, economic growth and financial inclusion, BCTL is committed to the safety and efficiency of Timor- Leste s National Payment System (NPS). BCTL is adopting a strategic approach 3 See http://timor-leste.gov.tl/wp-content/uploads/2012/02/strategic-development-plan_en.pdf 2

to payment systems reform, with the objective of achieving a safe and efficient NPS that effectively contributes to the country s financial stability and 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 in rural areas; 7. Promote efficiency and convenience, and foster trust, in the NPS for both individual and institutional users; 8. Improve the attractiveness of Timor-Leste from an investment and transactional perspective by providing payment services and surety that conform to international standards. 1.3 This RFP At present, there is no automated interbank clearing and settlement system in Timor-Leste. The settlement of all interbank payments, including highvalue, involves physical exchange of paper instruments and manual postings in BCTL s General Ledger (GL). To improve this, and to address systemic risk in the financial system, BCTL wishes to put in place an appropriate electronic system for clearing and settling large-value and time-critical payments. In addition, the current system for retail payments is inefficient and does not provide a satisfactory level of functionality and service to the payments community (which effectively includes, not only banks and other financial institutions but also all citizens, companies and civil society organisations). BCTL therefore intends to acquire and implement a modern Automated Transfer System (ATS). The ATS will be an interbank electronic payment processing system whose function will be to enable commercial banks, GOTL entities and BCTL itself to make and receive payments between themselves. 3

It will conform with current best practice and with international principles and recommendations, particularly the CPSS-IOSCO Principles for Financial Market 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 ensure seamless 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 straightthrough processing (STP). The ATS will also support interfaces to systems operated by agencies of the GOTL, particularly those responsible for making payments and collecting revenues. Within BCTL it will be integrated with a new accounting and financial management system which is currently being procured via a separate RFP. This RFP is therefore issued for the supply and implementation, on a turnkey basis, of an ATS, and proposals are invited from qualified companies for: 1. Supply, customisation and implementation of an ATS application software package; 2. Specification of all: (i) hardware; (ii) licences for system software, database management software, middleware, certificate and web server software; and (iii) networking components and all other technical elements necessary to run both systems in two (primary and Disaster Recovery) processing centres; 3. Implementation of automated linkages between the ATS and a range of other information systems both within BCTL and in external organisations including commercial banks and government entities; 4. The complete range of required services including at least the following: i. Project management; 4 See http://www.bis.org/cpss/index.htm?ql=1 4

ii. iii. iv. Business and user functional requirements specification; Business-level advice and consultancy to both BCTL and all participants related to the establishment and operation of the system; Customisation/parameterisation of software package(s); v. Implementation of all required linkages; vi. Technical advice to system participants (including GOTL participants) on implementing the necessary linkages and modifications to their internal systems; vii. viii. ix. Acceptance testing; Training; Documentation; x. Establishment and operation of a help-desk; xi. Post-live software maintenance and ongoing support. 1.4 Abbreviations and Definitions ACH AML/CFT AP ASYCUDA ATM ATS AUD BCTL BIC BIS CBS CFET CPSS CRIS Customs DR EDTL Automated Clearing House Anti Money Laundering/Countering Financing of Terrorism Accounts Payable Automated System for Customs Data Automated Teller Machine Automated Transfer System Australian Dollar Banco Central de Timor-Leste SWIFT Bank Identifier Code Bank for International Settlements Core Banking System Consolidated Fund of East Timor Committee on Payment and Settlement Systems Credit Registry Information System The Directorate General for Customs of the Ministry of Finance Disaster Recovery Electricidade de Timor-Leste 5

EFTPOS EUR FIU FMIS GDP GL GOTL GUI IBAN IT IOSCO IPWG LAN LVTS MSS NPS ODTI Proposer Revenue RFP RTGS SAS SIGTAS SLA STP Supplier TIN TPO Treasury UNCTAD USD Electronic Funds Transfer at Point of Sale Euro Financial Intelligence Unit Financial Management Information System Gross Domestic Product General Ledger Government of Timor-Leste Graphical User Interface International Bank Account Number Information Technology International Organisation of Securities Commissions Inter-Participant Working Group Local Area Network Large Value Transfer System Ministry of Social Solidarity National Payments System Other Deposit Taking Institutions Company responding to this RFP The Directorate General for Revenues of the Ministry of Finance Request for Proposals Real Time Gross Settlement Survicos de Agua Saneamento (water supply authority) Standard Integrated Government Tax Administration System Service Level Agreement Straight-Through Processing The successful proposer Taxpayer Identification Number Treasury Payment Order The Directorate General for Treasury of the Ministry of Finance United Nations Conference on Trade and Development United States Dollar 6

2. Current Situation 2.1 Institutional 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-Leste were 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: Licensing and supervision of financial institutions (including insurance companies); Providing the means of payment (US Dollar (USD) notes and Timorese centavos coins) through the commercial banks to the economy; Operation of interbank clearing arrangements; Acting as banker to the GOTL; Publication of monetary and banking statistics and other economic information; Operational management of the Petroleum Fund; Operation of a Credit Registry Information System (CRIS). Each commercial bank is required to maintain a Settlement Account at BCTL. These accounts are used for interbank transfers and settlement of payment clearing operations. Settlement Accounts are held in BCTL s GL and are currently updated by manual postings. Commercial banks are also required to maintain Collateral Accounts at BCTL, as described in 2.3.1. BCTL currently pays interest on Collateral Accounts. BCTL also holds several GOTL accounts: 1. The Consolidated Fund of East Timor (CFET) account, which is the GOTL s main operating account. BCTL pays interest on the CFET Account; 7

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 locallyowned 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 it a 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 at Customs head office in Dili, for the collection of Customs duties. 4. PT. Bank Mandiri (Persero) Tbk. Dili Timor-Leste Branch which is a branch of the Indonesian Bank Mandiri and has one branch in Dili. 2.1.2.2 Numbers of accounts Between the four banks, there are some 260,000 accounts in total. Somewhat over half of these accounts are at BNCTL. 2.1.2.3 Bank account numbering At present there is no coherent numbering of bank accounts across the banks operating in Timor-Leste. In order to rectify this, and to prepare for the introduction of electronic interbank payment systems, BCTL and the banking community have decided to standardise bank account numbering using ISO 13616 (the international standard for numbering bank accounts (International Bank Account Numbers or IBAN)). This process is expected to be completed before the ATS goes live, and therefore proposers should take IBAN into account in preparing their proposals as necessary. 2.1.2.4 Payment services The commercial banks provide a range of retail payment services including: cheques for both small and large value transactions; debit cards for point of sale (POS) transactions and withdrawal of cash via Automated Teller Machines (ATMs); and direct credit transfers. With the exception of cheques, 8

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 way in which they can make payments. Cash is even used, for example, to make tax payments (see 2.6.2). 2.2.2 Paper Instruments There are two types of paper instrument used for interbank payments, namely cheques and credit notes, both of which are cleared through the clearing house operated by BCTL as described in 2.3.1. These are the only interbank payment instruments used in Timor-Leste apart from cash. 2.2.2.1 Cheques The numbers of cheques passing through the interbank clearing house (see 2.3.1) are very small, amounting to fewer than 100 per day on average, as shown in Tables 2 and 3 below. Because of the very low volumes of cheques, the ATS will not be required to provide cheque truncation/clearing functionality. Rather, the present manual clearing house will continue in operation. 2.2.2.2 Large value cheques Cheques for amounts greater than USD200,000 are not accepted in the clearing house and are therefore not included in Tables 2 and 3. They are settled via the Large Value Transfer System (LVTS) described in 2.3.2. 9

2.2.2.3 (Credit) notes 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 payments Large 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 sent by Treasury to BCTL for processing, together with the corresponding schedules of individual payments. On receipt of a TPO, BCTL settlements staff debit the CFET account, credit the beneficiary bank s Settlement Account and send a Funds Transfer Advice together with the payment schedule to the beneficiary bank by fax. The original documents are then forwarded to the beneficiary bank, which applies the credit payments to its customers accounts. This arrangement forms part of the LVTS described in 2.3.2. Volumes of these payments are given in Table 4 below. 10

Clearing House Transactions 2012 Month Cheques Notes Return Cheques Return Notes Number Value Number Value Number Value Number Value 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 11

Clearing House Transactions January to June 2013 Month Cheques Notes Return Cheques Return Notes Number Value Number Value Number Value Number Value 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 12

No Distritos Monthly Payroll for Veterans pension 1 Aileu 1,037 389,547.16 2 Ainaro 1,426 509,105.12 3 Baucau 1,944 661,911.91 4 Bobonaro 1,214 463,571.11 5 Covalima 969 292,108.49 6 Dili 3,213 974,537.38 7 Ermera 1,293 501,028.88 8 Lautem 1,484 421,040.10 9 Liquisa 1,188 332,395.52 10 Manatuto 1,930 688,728.54 11 Manufahi 952 413,189.38 12 Oecussi 158 41,440.25 13 Viqueque 1,652 545,711.08 Monthly payroll for public services Payroll as of April 2013 per District Elderlies (Six month) Item Amount Item Amount Item Amount 1009 1064 2435 1885 1595 15860 1390 1450 987 1031 1208 1217 1640 Subsidies for the mothers (Six month) Monthly Payroll for Defence/FDTL Monthly Payroll for police/pntl 285,222 3,052 541,410.00 1,773 251,760.00 93 34,230.09 298,292 5,877 1,066,050.00 1,616 251,520.00 108 36,963.16 704,687 14,485 2,560,980.00 2,927 422,400.00 232 72,070.64 547,744 9,732 1,745,880.00 2,470 346,440.00 224 73,433.89 435,903 6,532 1,163,250.00 3,099 457,500.00 215 69,244.39 4,793,133 8,316 1,480,890.00 3,825 590,400.00 1,840 502,240.50 1,658 527,365.33 402,066 8,163 1,464,090.00 2,679 419,340.00 139 46,796.85 403,303 5,961 1,070,580.00 1,718 265,620.00 151 51,364.98 269,747 5,805 1,032,510.00 1,929 289,560.00 102 32,564.20 291,295 4,655 828,030.00 1,523 211,200.00 113 39,521.79 318,681 5,164 927,540.00 2,232 308,760.00 111 36,133.43 348,057 5,488 967,830.00 1,746 249,600.00 4 926.00 175 54,684.47 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 13

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 Automated Teller Machines (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 Electronic Funds Transfer at Point 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 Credit cards There is very limited use of credit cards, and then only of foreign-issued cards. Very few establishments accept credit cards, mainly those catering to foreigners, such as hotels and restaurants in Dili. In May 2013 5,015 transactions were recorded using foreign credit cards. 2.2.6 Internet payments One or two banks offer Internet payments but only on an intrabank basis (i.e. between customers of the same bank). 2.2.7 Mobile payments There are currently no mobile payment services offered in Timor-Leste. 2.3 Clearing and Settlement 2.3.1 Dili Clearing House Cheques and (credit) notes are cleared through a manual interbank clearing house operated by BCTL at its head office in Dili at 09:30 daily. Monthly volumes for these for the last 18 months are given in Tables 2 and 3. Net positions (credit and debit) arising from the daily clearing house sessions are posted manually to banks Settlement Accounts in BCTL s GL. In order to cater for a situation where a bank has insufficient funds in its Settlement Account to cover a debit position, and cannot borrow from another bank, all 14

banks are required to maintain Collateral Accounts at BCTL, in addition to their Settlement Accounts. The required balance in an individual bank s Collateral 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 System As 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. All interbank credit transfers for amounts greater than USD200,000 are executed via fax as described above. The LVTS also includes the arrangements for clearing and settling GOTL payroll, pension and welfare payments described in 2.2.3. BCTL expects that all payments currently made through the LVTS will disappear when the ATS comes into operation, and will be replaced by RTGS payments. The cheque clearing house will continue to reject high-value cheques, although the value threshold may be altered. 2.3.3 Card clearing Because ATM and EFTPOS circuits are currently not interoperable, all debit card transactions are cleared and settled within the issuing bank. 2.4 Fixed Income Securities At present neither the GOTL not BCTL issues securities. There are also no plans at present for either party to start issuing securities, although this may change over the next few years. 2.5 Equities There is no equities market in Timor-Leste. 15

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 Directorate General for Revenue (Revenue) Revenue is responsible for collecting a variety of taxes. It uses the Standard Integrated Government Tax Administration System (SIGTAS) from the Canadian company CRC Sogema. SIGTAS was implemented in 2001 and has not been updated since then, as a result of which there is significant dissatisfaction with it, and Revenue is planning to go to the market for an upgrade or complete replacement in the near future. At present all tax payments are required to be made at BNU. A taxpayer completes a tax assessment form in three copies which he/she takes to a BNU branch together with the payment which must be made in cash (BNU will not accept cheques for tax payments). Taxpayers can also make their payments via credit transfers to BNU from other banks, but this is hardly used because of the high fees involved. BNU retains one copy of each tax assessment form for its own records. Tax payments are credited to a special account at BNU, which is swept regularly to the CFET account at BCTL. Each day BNU prints a statement of all tax payments, sorted by Taxpayer Identification Number (TIN) and type of tax. A Revenue employee visits BNU each day to collect these statements together with one copy of each of the corresponding tax assessment forms. All of this information is manually entered into SIGTAS. Every month the third copies of all tax assessment forms are sent by BNU to Treasury for updating 16

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 tax/duty payable and prints an Assessment showing the amount payable. As with tax, all Customs payments are required to be made through BNU, which maintains branch offices at Customs head office and a land border crossing for this purpose. Payments are required to be made in cash. Once a payment has been made, the broker takes the receipt to the Customs office where the payment is entered into ASYCUDA and the shipment is cleared (subject to any requirement for inspection). 2.6.5 Ministry of Social Solidarity The Ministry of Social Solidarity (MSS) is responsible for managing the GOTL s welfare payments, including civil service pensions, old age pensions, war veterans payments, disability pensions and child support payments. The volumes of these payments are given in Table 4 above. MSS prepares schedules of required payments and forwards them to Treasury which makes the actual payments via bulk payments as described in 2.2.3. 2.6.6 Others A number of GOTL and state-owned enterprises are involved in receiving significant volumes of payments, including; for example: the state-owned power company Electricidade de Timor-Leste (EDTL); the state-owned water supply organisation Survicos de Agua Saneamento (SAS); the Port Authority of Dili; the Civil Aviation Authority; and others. 17

Introduction of the ATS will offer the opportunity to make such collections faster and more efficient and convenient. 2.7 IT Environment 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 GOTL; 3. Clearinghouse, which is an Excel-based system for calculating Clearing House balances; 4. Investment management software, which is primarily Excel-based; 5. CRIS, which is a Credit Registry Information System running on a Windows server that is used by the commercial banks. Apart from this and its public website, none of the Bank s existing IT facilities are visible outside the organisation. 2.7.3 Database management software Current applications use either Microsoft SQL Server (2000, 2005 and 2008 R2) or Microsoft Access. 2.7.4 IT arrangements for ATS It is anticipated that the ATS will operate out-of-house in a third-party hosting facility in Timor-Leste, with server and network support provided by that facility. BCTL also intends to establish a disaster recovery (DR) site, either on its own premises or in a GOTL or commercial location. 18

3. Scope of this Procurement This 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; 6. Ongoing (post-acceptance) support as specified in 6.8. 3.1 Clearing and Settlement The ATS will provide a comprehensive electronic interbank payment mechanism. Using the ATS, financial institutions will be able to send a variety of payment instructions to each other and to BCTL. The ATS will provide both Real Time Gross Settlement (RTGS) and Automated Clearing House (ACH) capabilities for the clearing and settlement, within one integrated system, of all interbank electronic payments. It will carry out the functions that in some countries have been provided by different, discrete software systems (RTGS and ACH packages) which have had to be installed with interfaces to achieve what the ATS will achieve in one integrated system. 3.1.1 RTGS BCTL expects that the ATS will be based on a Real Time Gross Settlement software package, which will handle the settlement of: 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. Net interbank positions from the ACH clearing element of the ATS; 19

3.1.2 ACH 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 of Delivery 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. 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. 3.2 Participants The participants in the ATS will be: BCTL; the four commercial banks; Treasury. Revenue and Customs will also be participants for the purpose of receiving information on their tax and Customs receipts respectively, as described in 5.7. 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. As noted in 2.1.2, a number of ODTIs have expressed interest in the potential offered by the ACH element of the planned ATS. At some future point they may be admitted as participants without Settlement Accounts (i.e. making and receiving payments in their own right but using a fully-licensed bank as settlement bank). The ATS must have the capability of supporting such a type of participant. 3.3 Linkages Linkages will be developed to: 20

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; 5. A foreign exchange trading system. 3.4 Technical Environment 3.4.1 Security and Integrity The ATS will be developed and implemented to the highest standards of security and will meet all participants expectations of confidentiality, integrity, and availability. Confidentiality will be supported through strong encryption of all data in transit between users, connected systems and the ATS. Stringent user registration and authentication functionality will also be provided to ensure that only authorised persons have access to the system. Operational integrity and availability will be supported through hosting the processing capability for the system at primary and alternate processing sites, with redundancy of key components at the main site and close integration between the two sites to ensure that the system operates to a level of performance and reliability commensurate with its critical role in the national economy of Timor-Leste. 3.4.2 Hardware and Associated Software Proposals must include the specification (but not the supply, as previously stated) of all necessary items of hardware and associated components. 21

The supplier will be required to provide contractual assurances that the agreed total configuration (hardware, networking and software) will support the 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 in terms 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 dependent on the provision of a comprehensive range of high-quality services from the supplier. The services components of proposals will be given a substantial weighting in the overall proposal evaluation process and criteria. Proposals must contain full details of the services to be provided, as described in detail in section 6. In summary they will include: 1. A comprehensive range of implementation services which will include: a. Project Management; b. Business level consulting to advise BCTL and all participants on the non-technical aspects of implementing the systems, including development of associated documentation including system rules, pricing policy, operational procedures, certificate policy and certificate practice statement, and any others of relevance. c. Requirements analysis to investigate and document the functional requirements of the ATS in the specific environment of Timor-Leste; d. Customisation and integration of the application software to meet the detailed requirements documented as described under c above; e. Installation of the application software including technical and integration testing; 22

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

4. General System Requirements Proposals 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.1 Principles 4. Operations, maintenance and support; 5. Development and enhancements; 6. Capacity, scalability and upgradability of the system. The ATS should be based on best international practice and: 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 or host-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 be assured through demonstration, rigorous testing and a robust Service Level Agreement; 4.2 Operational The ATS must be delivered in both English and Portuguese language variants. BCTL is also interested in evaluating the possibility of having a Tetum 5 5 Tetum is one of the two official languages of Timor-Leste, the other being Portuguese. 24

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 onscreen 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 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: 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 system integrity and complete systemwide reconciliation; 25

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 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; 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 26

discuss the processing overhead that validation controls may impose on the system in a high-volume environment. 4.6 Message Integrity and Accountability 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 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 information about the time the message was received and delivered, and 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, after which 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 1. To minimise the opportunity for human error to cause service disruptions, operation of the software should be automated as far as 27

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 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 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); 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 IT operations, BCTL accounting department, BCTL treasury, etc.); 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 set of 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 requests for the purpose of 28

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 and comprehensiveness 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 important elements of the system. Proposers should describe how their system supports this concept, with recommendations as to the data items that would be displayed. 4.9 Security 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 for authorised retrieval and analysis, on a daily basis. It must not 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; 29

4.9.2 Access Controls 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. 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; 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 those functions 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. 30

4.9.3 Fail-Safe Operation 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 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 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 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 other site is able to continue processing with minimal manual intervention. Proposers should address these requirements carefully, and make appropriate recommendations for achieving the highest level of performance 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 switchover 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 interface testing. 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. 31

4.11 Operational Requirements 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 covering at least the following: 1. A performance monitoring system, including an events monitor integrated with the dashboard described in 4.8.2, which depicts critical 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 at least the following parameters: 32

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

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 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 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. BCTL expects 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 expected workloads for at least three years after acceptance. 4.13.1 Hardware 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 34

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 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 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 their application, for example automatic database replication to facilitate high availability. Report Writer 35

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. 4.13.3 Communications 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; 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). 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 hold the 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. 36

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 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 realtime settlement account information reporting and monitoring; 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 and settlement 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 safely following 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 37

should therefore describe all types of payment instruments and arrangements that their proposed 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. 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 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. 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 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); 38

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); 5. Net interbank positions from the ACH clearing element of the ATS; 6. 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. (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. 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 a Timorese 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; 39

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. 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 the order in which they are submitted. 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. 40

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 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 to BCTL 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 BCTL intends that the banks Settlement Accounts and the CFET Account will be moved from the GL to the ATS, which will manage 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. 41

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). 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 the net positions into the RTGS element. 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 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. 42

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 Currency 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 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, for purchase 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 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: 43

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, both notes 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: 5.6.2 Deposit 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. 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 a message 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. 7. Finally the vaults staff post the necessary journal entries to BCTL s GL. 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 44

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 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 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 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 required modifications 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 that this will require the ATS to have an electronic interface to BCTL s SWIFT terminal): 1. Treasury sends an MT103 payment instruction to the ATS with a transaction code indicating that it is an international payment. 2. The ATS: a. Debits the amount from the CFET account; 45

5.7.3 Revenue 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. 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. 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 the payment) for transmission to the ATS. All such payments received 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 46

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

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 entities and payment types. 5.8 Interface to Participant 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. 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 5.8.3 STP 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. 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 and uploaded to the system either fully-automatically (STP) or under 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 48

no charge, and to provide any necessary technical support and advice during the implementation process, again at no charge. Proposals should also contain 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 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 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 archiving) during system implementation. 5.9.1 Intraday On-line Information for BCTL The ATS should provide at least the following information to BCTL operational 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; 49

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 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 should provide 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; 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 50

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 as part of end-of-day processing. 5.10 Account Maintenance and Monitoring 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 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/cfet account 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 Participants and Volumes 5.11.1 Participants The participants in the ATS will be: BCTL; the four commercial banks; Treasury. Revenue and Customs will also be participants for the purpose of receiving information on their tax and Customs receipts respectively, as described in 5.7. They will not have separate accounts in the ATS. 51

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 information should also indicate both any constraints and growth paths available. 52

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 Consulting 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.2 Project Plan and Implementation Schedule 6.2.1 Project Plan Proposals must contain detailed preliminary project plans showing how proposers intend to carry out all aspects of the project. Project plans must address at least the following subjects: 1. Project organisation and management, covering both the proposer s team and the proposer s expectations of the level of input and engagement from BCTL and each participant; 2. The Proposer s project team members showing roles and including CVs and relevant certificates; 3. Phases of the project execution showing sequencing, activities and deliverables for each phase; 4. Task, time and resource schedules showing the estimated duration, sequence, resource allocation and interrelationship of all key activities and resources needed to complete the contract, and including a project plan in Microsoft Project format; 5. Development of detailed business and functional requirements and system specification; 53

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 supplier during 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 listed below. 1. Requirements analysis (scoping study) to establish and document the detailed functional requirements of the ATS in the specific environment of Timor-Leste, taking into account all required linkages with participants systems; 2. Production of the detailed system design specification which will precisely define the system to be delivered and implemented, and which will be formally accepted in writing by BCTL; 3. Customisation and integration of the application software to meet the above-mentioned detailed system design specification; 4. Installation of the application software at primary and DR sites, including technical and integration testing; 5. Detailed documentation and advice to all participants on linking their systems to the ATS; 6. Implementation of all required linkages; 7. Training; 8. Testing including Acceptance Testing; 9. Pilot operation (parallel running). 54

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); 4. Systems integration; 5. Information security; 6. The IT components relevant to this procurement; 7. Training of non-technical end-users. Each key specialist must have at least ten years of relevant experience, with the last five years in his/her specialist area, and at least three years of industry experience in a team leader position. BCTL expects that the supplier s project team, particularly the key specialists, will be assigned to this project throughout its duration. Should any of these persons become unavailable for the project for reasons outside the supplier s control, the supplier must appoint alternate persons of at least equivalent capability and experience, always subject to the approval of BCTL. BCTL may ask for replacement of any of the Supplier s team assigned to this project at any time. 6.4 Project Management The following paragraphs give BCTL s expectations as regards overall project management. Proposers are invited to comment on them and to propose any variations or modifications as they see fit. 55

6.4.1 Steering Committee BCTL has established an RTGS committee which has oversight of the project including 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 taken, and proposed revisions to the project schedule; 3. Other issues and outstanding or potential problems, and proposed actions. The two project managers will hold regular formal progress meetings at a frequency to be agreed, but no less than monthly. These meetings will be used to consider progress to date (including the supplier s monthly progress reports), agree actions to be taken to resolve problems, and update the project plan as necessary. The project managers will invite other project team members to take part in the progress meetings as necessary. Written minutes of all meetings and agreed actions will be taken by BCTL s project manager and circulated to all affected parties as applicable, including the RTGS committee. 6.4.4 Inter-Participant Working Group An Inter-Participant Working Group (IPWG) will be established, whose membership will comprise representatives of all involved BCTL departments, participating banks, Treasury, Revenue and Customs. BCTL s project manager will convene regular meetings of the IPWG, at which the two project managers will report on progress and consult on any project aspects requiring user involvement. 56

6.5 Testing and Acceptance 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; 9. Clear and effective documentation and other support materials; 10. Effective education and training; 11. Effective organisational arrangements for full scale operation; 12. Effective support organisation; 13. Effective problem reporting, tracking and resolution procedures. 6.5.2 Acceptance Testing Successful completion of the contract will be attained through a series of formal acceptance tests performed on all aspects of the ATS. Payment will be directly related to successful completion of agreed milestones. The acceptance tests will demonstrate that the supplier has met each requirement specified and agreed in the contract and has delivered all required reports and documentation and an effective operational system. Each step of the acceptance tests will be fully documented and signed-off by BCTL to signify acceptance of each element. 6.5.3 Sequence of Acceptance Tests 1. Initial acceptance tests will be performed using the system as installed. These tests will confirm general functioning of each element of the ATS, together with any linkages within BCTL, particularly the interface to BCTL s General Ledger. 57

2. Functional acceptance tests will be conducted across the fully installed ATS in both the primary and back-up processing sites, and all elements installed 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 of failover 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 technical staff, 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 BCTL s project manager will be responsible for the final rating of all acceptance test results. At the end of each test phase BCTL s project manager will provide to the supplier either a formal letter of acceptance if the supplier has met its contractual obligations, or a statement specifying which obligations have not been met and must be met before acceptance can be granted. Operational Acceptance will be achieved only after successful completion of all tests and formal acceptance of all project deliverables. 6.5.6 Fault Correction The supplier will be responsible for correcting all faults found during acceptance testing in a timely manner so that the overall project schedule is not affected. A fault is here defined as any instance where an element of the ATS does not perform in accordance with the signed-off detailed system design specification defined in 6.2.2 (2). 6.6 Knowledge Transfer and Training 6.6.1 Knowledge Transfer BCTL considers training and knowledge transfer to be among the most important factors for the success of the ATS project. An important objective is therefore to ensure effective transfer of payment systems and related 58

technological knowledge, not just at BCTL but also among the participant organisations. This is viewed as critical in order for all parties to become selfsufficient 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; 3. Audit staff; 4. Technical training for systems development and testing staff in both BCTL and participant institutions; 5. Technical training for systems operations and maintenance staff in both BCTL and participant institutions; 6. Training in the creation of reports, and in the use of a report writer as applicable; 7. Any other relevant training for users. 6.7 Documentation All documentation necessary to operate and maintain the system must be delivered in the Portuguese and English languages. Preliminary project plans must contain detailed specifications of the documentation which the proposer will provide, indicating for each item: (i) on which medium or media it will be supplied; and (ii) whether it is a standard document or it will be tailored to the specific context of the Timorese system. BCTL expects that the supplied documentation will include at least the following: 1. Product Literature, describing the different system components that address the business and technical requirements of this procurement; 59

2. End-user Documentation, tailored as applicable, covering operations guides, operating manuals, and standard user manuals. On-line help must 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 this time, 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 any other relevant aspects. 6.8.2 After Operational Acceptance Following Operational Acceptance, the supplier will provide support for the ATS at no charge for a period of one year (the Warranty Period), under conditions as detailed in the following paragraphs. These conditions will be included in a Service Level Agreement (SLA) which BCTL will conclude with the supplier prior to Operational Acceptance. Proposals may include sample SLAs at proposers discretion. The supplier will establish a single point of contact for all software or support related problems. The contact point will be available throughout the system operational day, which will be agreed between BCTL and the supplier during implementation. Terms for out of hours support will also be agreed during this period. The support services will include: 1. Software support, including: a. Problem response, management and resolution as detailed in 6.8.3 below; b. Error correction service for the application software; c. General advice and guidance for user of all supplied software products including application software, system software, DBMS, middleware etc. 60

The supplier will ensure that sufficient resources (with respect to the number of personnel and such personnel's training, competence and experience) 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 change management 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 are restrained or minimised. Priority levels will be as follows: 1. Priority 1: A system component has failed in such a way that one or more critical elements of the system are unusable. The supplier will provide appropriate support within fifteen minutes and provide a work-around or fix within two hours of receiving notification. 2. Priority 2: The service is severely impacted and performance is restricted. The supplier will provide appropriate support within two hours and provide a work-around or fix within four hours of receiving notification. 3. Priority 3: The service is impacted and performance is reduced. The supplier will supply a work around or fix within 24 hours of receiving notification. 4. Priority 4: The service may be impacted and performance can be reduced. Priority 4 problems will be supported and resolved during the supplier s and BCTL s normal hours of business. Details of problems logged with the supplier, whether during the implementation project, the System Warranty Period or under an ongoing Service Level Agreement, should be easy for BCTL to follow up. Regular reporting should be a standard feature of the system and should include: 61

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 failure is 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 not delay end of day processing by more than 30 minutes. There will be no more than one such incident per month or three per year. 3. BCTL s general availability expectation for this system is 99.95%, i.e. downtime of 0.05% (where downtime is defined as total unavailability of the system), calculated on an annual basis. Proposers are requested to give details of expected reliability and availability figures for the actual configuration (hardware, software etc.) they are proposing. 6.8.5 Post-Warranty Period During the Post-Warranty Period (five years from expiry of the Warranty Period), the Supplier will be required to continue to provide ongoing services as specified in 6.8.2. These will be provided under a continuation of the above-mentioned SLA. The SLA will be renewable annually after the expiry of the initial five years. 62

7. Instructions to Proposers 7.1 Conditions 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. BCTL wishes to enter into a contract with one party only. However, it is acceptable for proposers to combine with other companies for the supply of different elements of their solutions provided that in each case the proposer (prime contractor) accepts full responsibility for the successful execution of the entire project. Proposals must indicate all parties concerned with, or contributing to, the proposal including any subcontract or similar arrangements. The lowest priced or any proposal will not necessarily be accepted. BCTL shall not be under any obligation to discuss the reason why any proposal is accepted or rejected. The acceptance of a proposal shall not operate to create any contractual relationship between BCTL and the concerned proposer, but shall represent a commitment to enter into negotiations in good faith. No proposal shall be deemed to have been accepted or rejected until such acceptance or rejection has been notified in writing by BCTL. Unless otherwise expressly agreed, there shall be no binding contract between the successful proposer and BCTL unless and until a written contract is executed by BCTL. 63

The requirements specified in this RFP reflect those known at present. BCTL reserves the right to vary the final requirements prior to entering into 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 acceptance of any proposal shall be published in any newspaper, magazine, journal or other medium without the prior consent of BCTL. The contact person nominated in 7.4.1.2 below is the sole point of contact for the purposes of this RFP. Discussions and attempts to influence the process prior to contract award initiated by a proposer, with BCTL staff or BCTL members of management or any other parties outside the formal parameters of the selection process concerning this RFP, may constitute grounds for elimination from the selection process. Objections at any stage in the process shall be submitted within five working days of the receipt of any notice received by the proposer from the BCTL. Objectors shall clearly state the grounds of their objection and the nature of the remedy sought. Claims are to be addressed to: Mr Abraão de Vasconselos Governor Central Bank of Timor-Leste Avenida Bispo Medeiros PO Box 59 Dili, Timor-Leste Email: Office.Governor[at]bancocentral.tl 64

7.2 Proposer Qualifications 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 external systems will be demonstrated as part of the proposal evaluation process; The proposer must have on its current staff at least one key person, who will be assigned to this project, in each of the following specialist areas involved in the project: Project management; High value/high priority payment processing systems (RTGS); Low value and bulk (retail) payment processing systems (ACH); Systems integration; Information security; IT components relevant to this procurement; Training of non-technical end-users. Each key person should meet the following minimum requirements: Ten years of relevant experience, with the last five years in the particular specialist area; The last three years of industry experience in a management/team leadership capacity. 65

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 Structure 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; A written confirmation that, if awarded the contract, the proposer will accept responsibility for successful integration and interoperability of all proposed products, including interfaces to external systems. 7.3.2 Proposer Profile A business profile of the proposer, which must include the following: A copy of the audited financial statements for the last available two years; Organisational history and structure, including number of years in operation, and location of relevant sites/offices, particularly indicating from which location(s) implementation services and ongoing support would be provided to BCTL; Number of staff total employed and numbers relevant to this proposal; History of the proposed product(s), and future development plans; Details of reference sites for the proposed product(s) including a reference letter from the responsible person at each site; A list of current projects involving the proposed products, including status of implementation, expected completion date and key personnel assigned; 66

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: 7.3.4 Services An overview of the full solution, describing each element and how all elements are proposed to interact and link to other external systems as 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. development of custom software module). Related and relevant technical literature on the proposed products and services may be included as appendices to the proposal and clearly cross-referenced from the main body of the proposal as necessary. This section of the proposal must contain clear and detailed responses to the requirements for implementation and support services as specified, and in the same sequence as, in section 6 of this RFP. 7.4 Procurement process 7.4.1 Technical Proposal Submission 7.4.1.1 Registration of intention to respond Companies intending to respond to this RFP and wishing to receive copies of any clarifications issued are requested to register their interest by email to the contact person named below. 67

7.4.1.2 BCTL contact BCTL s contact person for this RFP is Ms. Raquel Gonçalves da Costa. Contact should be made with her by email to raquel.goncalves@bancocentral.tl, 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 Clarification 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 Proposal submission 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- ROM/DVD or flash memory device. Proposers should note that the maximum size of attachments accepted by BCTL s email system is 10MB. Proposals with a maximum size greater than 10MB should therefore be sent in several emails, clearly identifying the correct sequence number of emails and attachments. The deadline for submission is 4.00 p.m. (Timor-Leste time) on 30 September 2013. BCTL reserves the right, at its discretion, to accept or reject proposals received after the deadline. 7.4.1.5 Conformity with qualification criteria After the deadline for submission, proposals will be checked for conformity with the qualification criteria specified in 7.2. BCTL, at its discretion, may exclude from further consideration any proposals which do not meet these criteria, and will inform their proposers accordingly. All other proposals will be subjected to evaluation as described in the following paragraphs. 7.4.2 Evaluation of Proposals The evaluation process, for proposals which have not been rejected by reason of non-conformity with the qualification criteria, will take place in three stages: 68

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 nonresponsive 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 proposal presentation 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 understanding of each proposer s capabilities, functionality of the proposed ATS solution and understanding of BCTL s detailed requirements. At the meetings BCTL and prospective ATS participants will discuss with proposers the detailed design of their solutions and agree with them the elements of their final proposals. Each proposer must therefore ensure that its team attending the meeting includes specialists who can explain and discuss all aspects of the proposed solution. The outline agenda for each proposal presentation meeting is therefore as follows: 1. Brief introduction by BCTL. The purpose of this session is to ensure a common understanding of BCTL s requirements, and of the objective(s) of the meeting. 2. Presentation by the proposer of its proposal. This can include brief information on the proposer, its operations and capabilities, etc. 3. Demonstration of the proposed solution including options and variations. This will also be used to address any questions which BCTL and stakeholders may have formulated following initial evaluation of the proposal as delivered. If possible these questions will be forwarded to proposers prior to the presentation meetings. 69

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 2 nd 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 proposerspecific 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 a. Software itemised for each discrete product; b. Project management; c. Business level consultancy and requirements specification; d. Tailoring and customisation of software and system integration; e. Advice and guidance to participants in connecting/interfacing their systems and operations to the ATS; f. Implementation and testing (including participant sites); g. Documentation; h. Training; i. Any other costs. Recurrent Costs 7.4.5 Evaluation Criteria a. Annual licence and support costs for five years following the Warranty Period (i.e. years 2-6 after Operational Acceptance); b. Any other recurrent costs. Each proposal will be evaluated on a number of criteria, which will include: 70

7.5 Contract 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 Track record in similar implementations Support arrangements Proposals should include any contractual documents that the proposer wishes to put forward as appropriate to this procurement. BCTL reserves the right to use its own form of contract or to negotiate on the basis of the proposer s contract documentation at its own discretion. BCTL s technical requirements as laid down in sections 4 to 6 of this RFP, together with the supplier s response, will form part of the final contract as agreed between the two parties. The contract as finalised will include software escrow arrangements for the ATS and any other relevant source code, together with all documentation necessary to compile the source code into a fully-working system. BCTL s preference is to maintain these materials under its own safe custody arrangements, subject to a suitable contract with the supplier which will set out, inter alia, the conditions for release of the materials. The escrow will be released to and the materials will become the property of BCTL in the event that the agreement between BCTL and the supplier is terminated for either default or insolvency, or should the supplier cease, or give notice of intention 71

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

BCTL (ATS) 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 proposed solution satisfies the requirement: 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 Proposals 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 Response 73

BCTL (ATS) 4.1 Principles Required Feature The ATS should be based on best international practice and: 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 or host-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 be assured through demonstration, rigorous testing and a robust 74 N/A Response

BCTL (ATS) Required Feature 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: 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 75 N/A Response

BCTL (ATS) Required Feature 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. Response 4.3 Integrity The ATS should provide: 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 system integrity and complete system-wide reconciliation; N/A 76

BCTL (ATS) Required Feature 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. Response 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 are correct; 77

BCTL (ATS) Required Feature 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 Response 78

BCTL (ATS) Required Feature controls may impose on the system in a high-volume environment. 4.6 Message Integrity and Accountability 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 sixeyes) 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 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 information about the time the message was received and delivered, and 79 N/A Response

BCTL (ATS) Required Feature 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, after which 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 Response 80

BCTL (ATS) Required Feature 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 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, informationonly); 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 IT operations, BCTL accounting department, BCTL treasury, etc.); 81 Response

BCTL (ATS) Required Feature 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 set of 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 requests for the purpose of monitoring their positions, tuning system functionality, managing intraday liquidity, queue management of payment requests and so on. Response 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. 82

BCTL (ATS) Required Feature 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 important elements of the system. Proposers should describe how their system supports this concept, with recommendations as to the data items that would be displayed. Response 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 for authorised retrieval and analysis, on a daily basis. It must not 83

BCTL (ATS) Required Feature 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 and services (including advice on implementation) to achieve this; Response 84

BCTL (ATS) Required Feature 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 those functions 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 parameterdefined 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 Response 85

BCTL (ATS) Required Feature 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 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 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. Response 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) so that, in the event of a failure at one site, the other site is able to 86

BCTL (ATS) Required Feature continue processing with minimal manual intervention. Proposers should address these requirements carefully, and make appropriate recommendations for achieving the highest level of performance 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 interface testing. 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. Response 87

BCTL (ATS) Required Feature 4.11 Operational Requirements 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. N/A Response 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 88

BCTL (ATS) covering at least the following: Required Feature 1. A performance monitoring system, including an events monitor integrated with the dashboard described in 4.8.2, which depicts critical 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 at least the following parameters: Response 89

BCTL (ATS) Required Feature 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 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 Response 90

BCTL (ATS) Required Feature 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 91 N/A Response

BCTL (ATS) Required Feature 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 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. BCTL expects 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 Response 92

BCTL (ATS) Required Feature expected workloads for at least three years after acceptance. Response 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 93

BCTL (ATS) Required Feature 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. Response 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 94

BCTL (ATS) Required Feature 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 their application, 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. 4.13.3 Communications Proposers should specify in detail all communications requirements for their solutions, covering both BCTL (both processing locations) and all participating organisations, including 95 Response

BCTL (ATS) Required Feature performance, security, reliability, backup capability, bandwidth and any other relevant considerations. Response 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). 96

BCTL (ATS) Required Feature 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 hold the 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 of the AML/CFT capabilities of their proposed systems. Response 97

BCTL (ATS) 5. Specific Functional Requirements for the ATS Required Feature 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 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 and monitoring; 98 N/A N/A Response

BCTL (ATS) Required Feature 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 and settlement 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 safely following 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 of payment instruments and arrangements that their proposed Response 99

BCTL (ATS) solution can handle. Required Feature 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. 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 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. N/A Response 100

BCTL (ATS) 5.2.3 Clearing Required Feature 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. Response 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); 101

BCTL (ATS) Required Feature 5. Net interbank positions from the ACH clearing element of the ATS; 6. 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. (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. Response 102

BCTL (ATS) Required Feature 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 a Timorese 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 Response 103

BCTL (ATS) Required Feature registry system must guarantee Delivery versus Payment (DvP). Proposals should contain details of how the proposed ATS can support these operations. Response 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 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. 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 the order in which they are submitted. 104

BCTL (ATS) Required Feature 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 105 Response

BCTL (ATS) Required Feature 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 to BCTL 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). Response 5.4.1 General Ledger Accounts N/A BCTL intends that the banks Settlement Accounts and the CFET Account will be moved from the GL to the ATS, which will manage 106

BCTL (ATS) Required Feature 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). Response 107

BCTL (ATS) 5.4.3 Collateral Accounts Required Feature 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 the net positions into the RTGS element. 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 108 N/A Response

BCTL (ATS) Required Feature 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. Response 5.5.1 Sources of Liquidity N/A 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 Currency 109

BCTL (ATS) Required Feature 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. Response 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, for purchase 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 110

BCTL (ATS) Required Feature bilateral and multilateral, to limit participants exposures. Response 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 111

BCTL (ATS) Required Feature 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 a message 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. Response 112

BCTL (ATS) Required Feature 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. Response 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-effective and 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 113

BCTL (ATS) Required Feature 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 required modifications 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 that this will require the ATS to have an electronic interface to BCTL s Response 114

BCTL (ATS) Required Feature Response SWIFT terminal): 1. Treasury sends an MT103 payment instruction to the ATS with a transaction code indicating that it is an international payment. 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 115

BCTL (ATS) Required Feature 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 ($$) Response 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 the payment) for transmission to the ATS. All such payments received 116

BCTL (ATS) Required Feature 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. Response 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 117

BCTL (ATS) Required Feature 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 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 inhouse 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. Response 118

BCTL (ATS) Required Feature 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 Response 119

BCTL (ATS) entities and payment types. Required Feature Response 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 and uploaded to the system either fully-automatically (STP) or under 120

BCTL (ATS) Required Feature 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 also contain full details of any software modules that are available to facilitate STP at participants sites, to which their internal CBSs can be interfaced. Response 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). 121

BCTL (ATS) Required Feature 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 122 Response

BCTL (ATS) Required Feature archiving) during system implementation. 5.9.1 Intraday On-line Information for BCTL The ATS should provide at least the following information to BCTL operational 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 Response 123

BCTL (ATS) Required Feature 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 should provide 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; Response 124

BCTL (ATS) Required Feature 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 as part of end-of-day processing. Response 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 125

BCTL (ATS) Required Feature 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 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/cfet account 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 Response 126

BCTL (ATS) Required Feature Treasury. Revenue and Customs will also be participants for the purpose of receiving information on their tax and Customs receipts respectively, as described in 5.7. They will not have separate accounts in the ATS. 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 information should also indicate both any constraints and growth paths available. Response 127