BANKI

KUU YA

KENYA

CENTRAL BANK OF KENYA

Haile Selassie Avenue

P.O. Box 60000 - 00200 Nairobi Kenya

Telephone: 2861000/2863000

Email: supplies@centralbank.go.ke

TENDER DOCUMENT

INTERNATIONAL TENDER FOR SUPPLY, DELIVERY, TESTING

AND COMMISSIONING OF

PORTFOLIO MANAGEMENT AND TRADE PROCESSING

SYSTEM (PMTP)- LOT 1

and

INVESTMENT RISK MANAGEMENT SYSTEM (IRMS)- LOT 2

(REF. NO. CBK/25/2020/2021)

CLOSING DATE: 17th JUNE, 2021 AT 10.30 A.M

2

TABLE OF CONTENTS

PAGE

SECTION I INVITATION TO TENDER…………................………….5 SECTION II INSTRUCTIONS TO TENDERERS.……..............…….…6 Appendix to Instructions to tenderers……..........19 Evaluation Criteria……………………………… 21 SECTION III GENERAL CONDITIONS OF CONTRACT…………. 27 SECTION IV SPECIAL CONDITIONS OF CONTRACT………….... 31 SECTION V SCHEDULE OF REQUIREMENTS AND PRICE….…. 33 SECTION VI TECHNICAL DESCRIPTION OF SERVICE……….… 34 SECTION VII STANDARD FORMS ……………………………….…. 38 7.1 FORM OF TENDER ………………….…………………………. 39 7.2 CONTRACT AGREEMENT FORM ….…………………………… 40 7.3 TENDER SECURITY FORM ………….…………………………... 41 7.4 PERFORMANCE SECURITY FORM ……………………………… 42 7.5 CONFIDENTIAL BUSINESS QUESTIONNAIRE FORM……… 43 7.6 LETTER ON NOTIFICATION OF AWARD ……………………… 44 7.7 FORM RB 1 ..………………………………………………………….45 7.8 DECLARATION FORM…… …………….…………………………. 46

3

GUIDELINES IN PREPARATION OF BID DOCUMENT

In preparing the bid document in response to the tender, bidders are advised to note the

following:

1. Section I – Invitation to Tender. This section gives guidelines on how and where to

seek further clarification pertaining to the tender document; the form and amount of

Tender Security required; where and when the tenders should be submitted; and place

where tenders will be opened.

2. Section II – Instruction to Tenderers. This section guides tenderers basically on how

to prepare their bid and how the tendering process will be carried out up to the award

stage including notification of award to the successful bidder. “Appendix to Instruction

to Tenderers” customizes clauses under Section II. Wherever there is a conflict between

the provisions of the Instructions to Tenderers under Section II and the provisions of the

appendix, the provisions of the appendix prevail.

3. Evaluation Criteria: This gives information on how the tender will be evaluated.

Tenderers should be able to evaluate their bids before submission to determine in

advance whether they meet the requirement of the bid or not. Through the evaluation

criteria bidders will be able to note all the required documents that should be attached

to the bid document.

Checklist of Document Forming the Bid Document:

No. Documents forming part of the Proposal

1 The main sections of the Request for Tender document include: i) Section I – Invitation to Tender; ii) Section II – Instructions to Tenderers; iii) Section III – General Conditions of Contract; iv) Section IV - Special Conditions of Contract; v) Section V - Schedule of Requirements and Price vi) Section VI – Technical Description of service

These sections remain as they are in the bid document.

2 Documentary evidence of the company’s certificate of incorporation or other similar registration document confirming the bidder is a legal entity.

4 Provision of certificate of Tax compliance issued by the Tax authorities of the participating bidder.

5 Financial proposal containing completed price schedules and transferred to the form of Tender. Prices to be quoted to be inclusive of all the applicable taxes.

6 Duly filled and signed Financial Form in the format provided in the tender document.

4

7 Duly filled and signed Confidential Business Questionnaire in the form or format provided in the tender document.

8 Company profile. This should include: i) List of staff members that will be dedicated to the PMTP / IRMS Project with the

necessary qualification and experience (attach copies of CV); ii) List of technical team to manage the transition (attach copies of CV as per

sample CV provided in this document); iii) List of five (5) current clients who are using your system.

9 Duly filled and signed declaration form in the form provided in the Tender document.

10 Any other document in support of the bidder’s qualification.

5

SECTION I: INVITATION TO TENDER

1. The Central Bank of Kenya invites sealed tenders from eligible bidders for TENDER FOR

SUPPLY, DELIVERY, TESTING AND COMMISSIONING OF PORTFOLIO

MANAGEMENT AND TRADE PROCESSING SYSTEM (PMTP) AND INVESTMENT

RISK MANAGEMENT SYSTEM (IRMS)

2. Further information as pertains to this tender may be obtained during working hours (Monday to Friday) between 9:00 am and 5:00 pm using the following address: The Director, General Services Department (GSD), Tel: +254 20 2861000/2860000, 5th Floor, Central Bank of Kenya, Haile Selassie Avenue, Nairobi, Email: supplies@centralbank.go.ke

3. A complete set of tender documents containing detailed information can be downloaded from the Central Bank of Kenya website; www.centralbank.go.ke or the Public Procurement Information Portal (PPIP) website: www.tenders.go.ke. Bidders who download the tender documents from the websites should email their contact addresses to the email address: supplies@centralbank.go.ke for registration before the tender closing date.

4. Prices quoted should be inclusive of all taxes and delivery costs and must be expressed in Kenya shillings, USD, Euro or Sterling Pound and shall remain valid for a period of 120 days from the closing date of the tender.

5. Tenders must be accompanied by a Tender Security of USD 10,000.00, valid for 150 days

from the tender closing date issued by a reputable Bank or Financial Institution. Tender Security issued by Financial Institutions outside Kenya should be issued through correspondent Banks recognized by the Central Bank of Kenya. Failure to attach the Tender Security will lead to automatic rejection of the proposal.

6. A pre-bid meeting (conference) of the client (Central Bank of Kenya) and prospective bidders will be held on 3rd June 2021. Interested bidders are requested to register for participation in the tender and provide email addresses through which they will receive invitations for the pre-bid meeting.

7. Completed Tender Documents in plain sealed envelopes marked with the tender

number and title should be deposited in the Green Tender Box No. 3 located at the main

entrance to the CBK Building on Haile Selassie Avenue before 17th June 2021 at 10.30am.

Late bids will not be accepted and will be returned unopened.

8. Tenders will be opened immediately thereafter, i.e. on 17th June 2021 at 10.30am in the

presence of the tenderers representatives who may choose to attend the opening at the

Central Bank of Kenya Head Office, MICR Room, Mezzanine Floor.

9. Bidders are required to serialize all the pages of the bid documents submitted including

any addenda, appendices and attachments.

DIRECTOR, GENERAL SERVICES DEPARTMENT

21st May 2021

6

SECTION II: INSTRUCTIONS TO TENDERERS

TABLE OF CONTENTS Page

2.1 Eligible Tenderers ………………………………………….…….......... 7 2.2 Cost of tendering ……………………………………………............... 7 2.3 Contents of tender documents ………………………………….......... 7 2.4 Clarification of Tender documents …………………………..…......... 8 2.5 Amendment of tender documents ………………………................... 8 2.6 Language of tenders ……………………………………….…….......... 9 2.7 Documents comprising the tender ……………………….…….......... 9 2.8 Form of tender …………………………………………….…………… 9 2.9 Tender prices …………………………………………………….…….. 9 2.10 Tender currencies ……………………………………………………... 10 2.11 Tenderers eligibility and qualifications ……………….………......... 10 2.12 Tender security ………………………………………………….……. 10 2.13 Validity of tenders ……………………………………….…………… 11 2.14 Format and signing of tenders ………………………………….......... 11 2.15 Sealing and marking of tenders ………………………….................... 12 2.16 Deadline for submission of tenders …………………….………......... 12 2.17 Modification and withdrawal of tenders ………………………......... 13 2.18 Opening of tenders ………………………………………..…………… 13 2.19 Clarification of tenders …………………………………..………......... 14 2.20 Preliminary Examination ………………………………………..……. 14 2.21 Conversion to other currencies ………………………………………. 15 2.22 Evaluation and comparison of tenders …………………………........ 15 2.23 Contacting the Central Bank of Kenya …………………………….…. 16 2.24 Award of contract………………………………………………………. 16 2.25 Notification of award …………………………………………………. 17 2.26 Signing of Contract ……………………………………………………. 17 2.27 Performance security …………………………………………………. 18 2.28 Corrupt or fraudulent practices ………………………………..……. 18

7

SECTION II: INSTRUCTIONS TO TENDERERS

2.1 Eligible tenderers

2.1.1. This Invitation to tender is open to all tenderers eligible as described in the instructions to tenderers. Successful tenderers shall provide the services for the stipulated duration from the date of commencement (hereinafter referred to as the term) specified in the tender documents.

2.1.2. The Central Bank of Kenya’s employees, committee members, board members and their relatives (spouse and children) are not eligible to participate in the tender unless where specially allowed under section 131 of the Act.

2.1.3. Tenderers shall provide the qualification information statement that the tenderer (including all members of a joint venture and subcontractors) is not associated, or have been associated in the past, directly or indirectly, with a firm or any of its affiliates which have been engaged by the Central Bank of Kenya to provide consulting services for the preparation of the design, specifications, and other documents to be used for the procurement of the services under this Invitation for tenders.

2.1.4. Tenderers involved in corrupt or fraudulent practices or debarred from participating in public procurement shall not be eligible.

2.2 Cost of tendering

2.2.1 The Tenderer shall bear all costs associated with the preparation and submission of its tender, and the Central Bank of Kenya, will in no case be responsible or liable for those costs, regardless of the conduct or outcome of the tendering process.

2.2.2 The price to be charged for the tender document shall not exceed Kshs. 1,000.00

2.2.3 The Central Bank of Kenya shall allow the tenderer to review the tender document free of charge before purchase.

2.3 Contents of tender documents

2.3.1. The tender document comprises of the documents listed below and addenda issued in accordance with clause 6 of these instructions to tenderers

i) Instructions to tenderers ii) General Conditions of Contract iii) Special Conditions of Contract iv) Schedule of Requirements v) Details of service vi) Form of tender vii) Price schedules viii) Contract form

8

ix) Confidential business questionnaire form x) Tender security form xi) Performance security form xii) Principal’s or manufacturers authorization form xiii) Declaration form

2.3.2. The Tenderer is expected to examine all instructions, forms, terms, and specifications in the tender documents. Failure to furnish all information required by the tender documents or to submit a tender not substantially responsive to the tender documents in every respect will be at the tenderers risk and may result in the rejection of its tender.

TENDER SCHEDULE OF EVENTS

2.4 Schedule of Events

Event Time Date

1. Tender Issued May 21st th , 2021

2. Written “Questions & Clarifications” Deadline

June 11th , 2021

3. Tender Response Deadline 10.30 am Jun 17th, 2021

4. Tender Evaluation Commencement June 18th 2021

5. Duration of Tender Evaluation June 18th 2021 to July 17th 2021

2.5 Clarification of Documents

2.5.1. A prospective candidate making inquiries of the tender document may notify the Central Bank of Kenya in writing or by post, fax or email at the entity’s address indicated in the Invitation for tenders. The Central Bank of Kenya will respond in writing to any request for clarification of the tender documents, which it receives no later than seven (7) days prior to the deadline for the submission of tenders, prescribed by the Central Bank of Kenya. Written copies of the Procuring entities response (including an explanation of the query but without identifying the source of inquiry) will be sent to all prospective tenderers who have received the tender documents.”

2.5.2. The Central Bank of Kenya shall reply to any clarifications sought by the tenderer

within 3 days of receiving the request to enable the tenderer to make timely submission of its tender

2.6 Amendment of documents

9

2.6.1. At any time prior to the deadline for submission of tenders, the Central Bank of Kenya, for any reason, whether at its own initiative or in response to a clarification requested by a prospective tenderer, may modify the tender documents by issuing an addendum.

2.6.2. All prospective tenderers who have obtained the tender documents will be notified of the amendment by post, fax or email and such amendment will be binding on them.

2.6.3. In order to allow prospective tenderers reasonable time in which to take the amendment into account in preparing their tenders, the Central Bank of Kenya, at its discretion, may extend the deadline for the submission of tenders.

2.7 Language of tender

2.7.1. The tender prepared by the tenderer, as well as all correspondence and documents relating to the tender exchanged by the tenderer and the Central Bank of Kenya, shall be written in English language. Any printed literature furnished by the tenderer may be written in another language provided they are accompanied by an accurate English translation of the relevant passages in which case, for purposes of interpretation of the tender, the English translation shall govern.

2.7 Documents Comprising the Tender The tender prepared by the tenderer shall comprise the following components: a) A Tender Form and a Price Schedule completed in accordance with paragraph 9, 10

and 11 below.

b) Documentary evidence established in accordance with Clause 2.11 that the tenderer is eligible to tender and is qualified to perform the contract if its tender is accepted;

c) Tender security furnished is in accordance with Clause 2.12

d) Confidential business questionnaire

2.8 Form of Tender 2.8.1 The tenderers shall complete the Form of Tender and the appropriate Price Schedule

furnished in the tender documents, indicating the services to be performed.

2.9 Tender Prices

2.9.1 The tenderer shall indicate on the Price schedule the unit prices where applicable and total tender prices of the services it proposes to provide under the contract.

2.9.2 Prices indicated on the Price Schedule shall be the cost of the services quoted including all customs duties and VAT and other taxes payable:

2.9.3 Prices quoted by the tenderer shall remain fixed during the term of the contract unless otherwise agreed by the parties. A tender submitted with an adjustable price

10

quotation will be treated as non-responsive and will be rejected, pursuant to paragraph 2.22.

2.9.4 Contract price variations shall not be allowed for contracts not exceeding one year (12 months)

2.9.5 Where contract price variation is allowed, the variation shall not exceed 10% of the original contract price.

2.9.6 Price variation requests shall be processed by the Central Bank of Kenya within 30 days of receiving the request.

2.10 Tender Currencies 2.10.1 Prices shall be quoted in Kenya Shillings unless otherwise specified in the appendix

to in Instructions to Tenderers.

2.11 Tenderers Eligibility and Qualifications.

2.11.1 Pursuant to Clause 2.1 the tenderer shall furnish, as part of its tender, documents establishing the tenderers eligibility to tender and its qualifications to perform the contract if its tender is accepted.

2.11.2 The documentary evidence of the tenderers qualifications to perform the contract if its tender is accepted shall establish to the Central Bank of Kenya’s satisfaction that the tenderer has the financial and technical capability necessary to perform the contract.

2.12 Tender Security

2.12.1 The tenderer shall furnish, as part of its tender, a tender security for the amount and form specified in the Invitation to tender.

2.12.2 The tender security shall be in the amount not exceeding 2 per cent of the tender price.

2.12.2 The tender security is required to protect the Central Bank of Kenya against the risk of Tenderer’s conduct which would warrant the security’s forfeiture, pursuant to paragraph 2.12.7

2.12.3 The tender security shall be denominated in a Kenya Shillings or in another freely convertible currency and shall be in the form of:

a) A bank guarantee. b) Cash. c) Such insurance guarantee approved by the relevant Authority. d) Letter of credit

11

2.12.4 Any tender not secured in accordance with paragraph 2.12.1 and 2.12.3 will be rejected by the Central Bank of Kenya as non-responsive, pursuant to paragraph 2.20

2.12.5 Unsuccessful tenderer’s security will be discharged or returned as promptly as possible but not later than thirty (30) days after the expiration of the period of tender validity prescribed by the Central Bank of Kenya.

2.12.6 The successful tenderer’s tender security will be discharged upon the tenderer signing the contract, pursuant to paragraph 2.29, and furnishing the performance security, pursuant to paragraph 2.30.

2.12.7 The tender security may be forfeited:

(a) If a tenderer withdraws its tender during the period of tender validity specified by the Central Bank of Kenya on the Tender Form; or (b) In the case of a successful tenderer, if the tenderer fails: (i) to sign the contract in accordance with paragraph 30 or (ii) to furnish performance security in accordance with paragraph 31.

(c) If the tenderer rejects, correction of an error in the tender.

2.13 Validity of Tenders

2.13.1 Tenders shall remain valid for 120 days or as specified in the invitation to tender after date of tender opening prescribed by the Central Bank of Kenya, pursuant to paragraph 2.18. A tender valid for a shorter period shall be rejected by the Central Bank of Kenya as nonresponsive.

2.13.2 In exceptional circumstances, the Central Bank of Kenya may solicit the Tenderer’s consent to an extension of the period of validity. The request and the responses thereto shall be made in writing. The tender security provided under paragraph 2.12 shall also be suitably extended. A tenderer may refuse the request without forfeiting its tender security. A tenderer granting the request will not be required nor permitted to modify its tender.

2.14 Format and Signing of Tender

2.14.1 The tenderer shall prepare two (2) copies of the tender, clearly / marking each “ORIGINAL TENDER” and “COPY OF TENDER,” as appropriate. In the event of any discrepancy between them, the original shall govern.

2.14.2 The original and all copies of the tender shall be typed or written in indelible ink and shall be signed by the tenderer or a person or persons duly authorized to bind the

12

tenderer to the contract. All pages of the tender, except for unamended printed literature, shall be initialed by the person or persons signing the tender.

2.14.3 The tender shall have no interlineations, erasures, or overwriting except as necessary to correct errors made by the tenderer, in which case such corrections shall be initialed by the person or persons signing the tender.

2.15 Sealing and Marking of Tenders

2.15.1 The tenderer shall seal the original and each copy of the tender in separate envelopes, duly marking the envelopes as “ORIGINAL” and “COPY.” The envelopes shall then be sealed in an outer envelope. The inner and outer envelopes shall: (a) be addressed to the Central Bank of Kenya at the address given in the invitation to tender

(b) bear tender number and name in the invitation to tender and the words: “DO NOT OPEN BEFORE (day, date and time of closing),”

2.15.3 The inner envelopes shall also indicate the name and address of the tenderer to enable the tender to be returned unopened in case it is declared “late”. —

2.15.4 If the outer envelope is not sealed and marked as required by paragraph 2.15.2, the Central Bank of Kenya will assume no responsibility for the tender’s misplacement or premature opening.

2.16 Deadline for Submission of Tenders

2.16.1 Tenders must be received by the Central Bank of Kenya at the address

specified under appendix to instruction to tenderers.

2.16.2 The Central Bank of Kenya may, at its discretion, extend this deadline for the submission of tenders by amending the tender documents in accordance with paragraph 6, in which case all rights and obligations of the Central Bank of Kenya and candidates previously subject to the deadline will thereafter be subject to the deadline as extended.

2.16.3 Bulky tenders which will not fit in the tender box shall be received by the Central Bank of Kenya as provided for in the appendix.

2.17 Modification and withdrawal of tenders

2.17.1 The tenderer may modify or withdraw its tender after the tender’s submission, provided that written notice of the modification, including substitution or withdrawal of the tender’s is received by the Central Bank of Kenya prior to the deadline prescribed for the submission of tenders.

13

2.17.2 The Tenderer’s modification or withdrawal notice shall be prepared, sealed, marked, and dispatched in accordance with the provisions of paragraph 2.15. A withdrawal notice may also be sent by cable, but followed by a signed confirmation copy, postmarked not later than the deadline for submission of tenders.

2.17.3 No tender may be modified after the deadline for submission of tenders.

2.17.4 No tender may be withdrawn in the interval between the deadline for submission of tenders and the expiration of the period of tender validity specified by the tenderer on the Tender Form. Withdrawal of a tender during this interval may result in the Tenderer’s forfeiture of its tender security, pursuant to paragraph 2.12.7.

2.17.5 The Central Bank of Kenya may at any time terminate procurement proceedings before contract award and shall not be liable to any person for the termination.

2.17.6 The Central Bank of Kenya shall give prompt notice of the termination to the tenderers and on request give its reasons for termination within 14 days of receiving the request from any tenderer.

2.18 Opening of Tenders.

2.18.1 The Central Bank of Kenya will open all tenders in the presence of tenderers’ representatives who choose to attend, at the time and date and in the location specified in the invitation to tender. The tenderers’ representatives who are present shall sign a register evidencing their attendance.

2.18.3 The tenderers’ names, tender modifications or withdrawals, tender prices, discounts, and the presence or absence of requisite tender security and such other details as the Central Bank of Kenya, at its discretion, may consider appropriate, will be announced at the opening.

2.18.4 The Central Bank of Kenya will prepare minutes of the tender opening which will be submitted to the tenderers that signed the tender opening register and will have made the request.

2.19 Clarification of tenders

2.19.1 To assist in the examination, evaluation and comparison of tenders the Central Bank of Kenya may at its discretion, ask the tenderer for a clarification of its tender. The request for clarification and the response shall be in writing, and no change in the prices or substance shall be sought, offered, or permitted.

2.19.2 Any effort by the tenderer to influence the Central Bank of Kenya in the Central Bank of Kenya’s tender evaluation, tender comparison or contract award decisions may result in the rejection of the tenderers tender.

14

Comparison or contract award decisions may result in the rejection of the tenderers’ tender.

2.20 Preliminary Examination and Responsiveness

2.20.1 The Central Bank of Kenya will examine the tenders to determine whether they are complete, whether any computational errors have been made, whether required securities have been furnished whether the documents have been properly signed, and whether the tenders are generally in order.

2.20.2 Arithmetical errors will be rectified on the following basis. If there is a discrepancy between the unit price and the total price that is obtained by multiplying the unit price and quantity, the unit price shall prevail, and the total price shall be corrected. if the candidate does not accept the correction of the errors, its tender will be rejected, and its tender security may be forfeited. If there is a discrepancy between words and figures, the amount in words will prevail.

2.20.3 The Central Bank of Kenya may waive any minor informality or nonconformity or irregularity in a tender which does not constitute a material deviation, provided such waiver does not prejudice or affect the relative ranking of any tenderer.

2.20.4 Prior to the detailed evaluation, pursuant to paragraph 23, the Central Bank of Kenya will determine the substantial responsiveness of each tender to the tender documents. For purposes of these paragraphs, a substantially responsive tender is one which conforms to all the terms and conditions of the tender documents without material deviations. The Central Bank of Kenya’s determination of a tender’s responsiveness is to be based on the contents of the tender itself without recourse to extrinsic evidence.

2.20.5 If a tender is not substantially responsive, it will be rejected by the Central Bank of Kenya and may not subsequently be made responsive by the tenderer by correction of the nonconformity.

2.21 Conversion to a single currency

2.21.1 Where other currencies are used, the Central Bank of Kenya will convert those currencies to Kenya shillings using the selling exchange rate on the date of tender closing provided by the central bank of Kenya.

2.22 Evaluation and comparison of tenders.

2.22.1 The Central Bank of Kenya will evaluate and compare the tenders which have been determined to be substantially responsive, pursuant to paragraph 2.20

2.22.2 The comparison shall be of the price including all costs as well as duties and taxes payable on all the materials to be used in the provision of the services.

15

2.22.3 The Central Bank of Kenya’s evaluation of a tender will take into account, in addition to the tender price, the following factors, in the manner and to the extent indicated in paragraph 2.22.4 and in the technical specifications:

(a) Operational plan proposed in the tender; (b) Deviations in payment schedule from that specified in the Special Conditions of Contract;

2.22.4 Pursuant to paragraph 22.3 the following evaluation methods will be applied: (a) Operational Plan.

The Central Bank of Kenya requires that the services under the Invitation for Tenders shall be performed at the time specified in the Schedule of Requirements. Tenders offering to perform longer than the Central Bank of Kenya’s required delivery time will be treated as non-responsive and rejected.

(b) Deviation in payment schedule.

Tenderers shall state their tender price for the payment on a schedule outlined in the special conditions of contract. Tenders will be evaluated on the basis of this base price. Tenderers are, however, permitted to state an alternative payment schedule and indicate the reduction in tender price they wish to offer for such alternative payment schedule. The Central Bank of Kenya may consider the alternative payment schedule offered by the selected tenderer.

2.22.5 The tender evaluation committee shall evaluate the tender within 30 days from the date of opening the tender.

2.22.6 To qualify for contract awards, the tenderer shall have the following: -

(a) Necessary qualifications, capability experience, services, equipment and facilities to provide what is being procured.

(b) Legal capacity to enter into a contract for procurement.

(c) Shall not be insolvent, in receivership, bankrupt or in the process of being wound up and is not the subject of legal proceedings relating to the foregoing

(d) Shall not be debarred from participating in public procurement.

2.23. Contacting the Central Bank of Kenya

2.23.1 Subject to paragraph 2.19, no tenderer shall contact the Central Bank of Kenya on any matter relating to its tender, from the time of the tender opening to the time the contract is awarded.

16

2.23.2 Any effort by a tenderer to influence the Central Bank of Kenya in its decisions on tender evaluation tender comparison or contract award may result in the rejection of the tenderers tender.

2.24 Award of Contract

a) Post qualification

2.24.1 In the absence of pre-qualification, the Central Bank of Kenya will determine to its satisfaction whether the tenderer that is selected as having submitted the lowest evaluated responsive tender is qualified to perform the contract satisfactorily.

2.24.2 The determination will consider the Tenderer’s financial and technical capabilities. It will be based upon an examination of the documentary evidence of the tenderers qualifications submitted by the tenderer, pursuant to paragraph 2.1.2, as well as such other information as the Central Bank of Kenya deems necessary and appropriate.

2.24.3 An affirmative determination will be a prerequisite for award of the contract to the tenderer. A negative determination will result in rejection of the Tenderer’s tender, in which event the Central Bank of Kenya will proceed to the next lowest evaluated tender to make a similar determination of that Tenderer’s capabilities to perform satisfactorily.

b) Award Criteria

2.24.3 Subject to paragraph 2.24.1 the Central Bank of Kenya will award the contract to the successful tenderer whose tender has been determined to be substantially responsive and has been determined to be the lowest evaluated tender, provided further that the tenderer is determined to be qualified to perform the contract satisfactorily.

2.24.4 The Central Bank of Kenya reserves the right to accept or reject any tender and to annul the tendering process and reject all tenders at any time prior to contract award, without thereby incurring any liability to the affected tenderer or tenderers or any obligation to inform the affected tenderer or tenderers of the grounds for the Central Bank of Kenya’s action. If the Central Bank of Kenya determines that none of the tenderers is responsive; the Central Bank of Kenya shall notify each tenderer who submitted a tender.

2.24.5 A tenderer who gives false information in the tender document about its qualification or who refuses to enter into a contract after notification of contract award shall be considered for debarment from participating in future public procurement.

2.25 Notification of award

17

2.25.1 Prior to the expiration of the period of tender validity, the Central Bank of Kenya will notify the successful tenderer in writing that its tender has been accepted. 2.25.2 The notification of award will signify the formation of the Contract subject to the

signing of the contract between the tenderer and the Central Bank of Kenya pursuant to clause 2.29. Simultaneously the other tenderers shall be notified that their tenders have not been successful.

2.25.3 Upon the successful Tenderer’s furnishing of the performance security pursuant to paragraph 31, the Central Bank of Kenya will promptly notify each unsuccessful Tenderer and will discharge its tender security, pursuant to paragraph 2.12

2.26 Signing of Contract

2.26.1 At the same time as the Central Bank of Kenya notifies the successful tenderer that its tender has been accepted, the Central Bank of Kenya will simultaneously inform the other tenderers that their tenders have not been successful.

2.26.2 Within fourteen (14) days of receipt of the Contract Form, the successful tenderer shall sign and date the contract and return it to the Central Bank of Kenya.

2.26.3 The parties to the contract shall have it signed within 30 days from the date of notification of contract award unless there is an administrative review request.

2.27 Performance Security

2.27.1 Within thirty (30) days of the receipt of notification of award from the Central Bank of Kenya, the successful tenderer shall furnish the performance security in accordance with the Conditions of Contract, in the Performance Security Form provided in the tender documents, or in another form acceptable to the Central Bank of Kenya.

2.27.2 Failure of the successful tenderer to comply with the requirement of paragraph 2.27.1 shall constitute sufficient grounds for the annulment of the award and forfeiture of the tender security, in which event the Central Bank of Kenya may make the award to the next lowest evaluated or call for new tenders.

2.28 Corrupt or Fraudulent Practices

2.28.1 The Central Bank of Kenya requires that tenderers observe the highest standard of ethics during the procurement process and execution of contracts. A tenderer shall sign a declaration that he has not and will not be involved in corrupt or fraudulent practices.

2.28.2 The Central Bank of Kenya will reject a proposal for award if it determines that the tenderer recommended for award has engaged in corrupt or fraudulent practices in

18

competing for the contract in question;

2.28.3 Further, a tenderer who is found to have indulged in corrupt or fraudulent practices risks being debarred from participating in public procurement in Kenya.

19

APPENDIX TO INSTRUCTIONS TO THE TENDERERS

The following information for procurement of services shall complement or amend the provisions of the instructions to tenderers. Wherever there is a conflict between the provisions of the instructions to tenderers and the provisions of the appendix, the provisions of the appendix herein shall prevail over those of the instructions to tenderers:

Instructions to tenderers

Particulars of appendix to Instructions to Tenderers

2.1.1 Eligible Tenderers shall be firms dealing in provision and maintenance of investment management systems. Tenderers can bid for one or both lots / systems: Lot 1: Portfolio Management and Trade Processing (PMTP) and Lot 2: Investment Risk Management System (IRMS). Tenders bids for each system will be evaluated independently.

2.2.2 The price to be charged for hard copy tender document shall be Kshs.

1,000.00 and free for downloading from the websites.

2.4.1 A prospective candidate may seek clarifications of the tender document not later than seven (7) days prior to the deadline for submission of tenders.

2.7 The tender prepared by the tenderer shall comprise in addition to documents specified under clause 2.7 all other documents described in clause 2.3.1 of this tender document and any other document required in determining qualification of the tenderer.

2.9.2 Price quoted shall be inclusive of all applicable taxes and delivery costs

2.10 Prices shall be quoted in either US Dollars, Euro or Sterling Pound

2.11.1 Proof of eligibility and qualifications documents of evidence required (See qualification criteria below).

2.12.2 Tenders must be accompanied by a Tender Security of US Dollars

10,000.00 and must be valid for 150 days from the date of tender closing/opening

2.13.1 The validity period of the Tender shall be 120 days from the closing date of Tenders.

2.14.1 Bidders to submit one original hard copy plus two (2) copies

1.16.1 Closing date of the Tender shall be 17th June, 2021 at 10:30 am

2,26.2 A draft of the contract document (Appendix C) that will be signed by the eventual successful bidder has been attached to the tender document for review by prospective bidders.

20

2.27 Within thirty (30) days of the receipt of notification of award from the Central Bank of Kenya, the successful tenderer shall furnish the performance security equal to 5% of the contract amount valid for the period of the contract from a commercial Bank operating in Kenya supervised by the Central Bank of Kenya

21

EVALUATION CRITERIA Evaluation Categories & Maximum Points The CBK will consider qualifications, experience, technical approach, and cost in the evaluation of responses and award points in each of the categories detailed below (up to the maximum evaluation points indicated) to each response deemed by the CBK to be responsive. Lot A: Portfolio Management and Trade Processing System (PMTP) EVALUATION CATEGORY MAXIMUM POINTS POSSIBLE

1. General Qualifications & Experience (refer to Annex A – Section A - Part II )

10

2. Technical Qualifications, Experience & Approach

a) Business Requirements (refer to Annex A – Section A - Part II)

60

b) Information Technology Requirements (refer to Annex A – Section B - Part II)

30

Total 100

Lot B: Investment Risk Management System (IRMS) EVALUATION CATEGORY MAXIMUM POINTS POSSIBLE

1. General Qualifications & Experience (refer to Annex B – Section B - Part II)

10

2. Technical Qualifications, Experience & Approach

c) Business Requirements (refer to Annex B – Section A - Part II)

60

d) Information Technology Requirements (refer to Annex B – Section B - Part II)

30

Total 100

Evaluation Process Evaluation will be carried out through six stages as follows: Stage1: Compliance with the Mandatory Requirements

Stage 2: Technical Evaluation on Compliance with the Technical Requirements

Stage 3: Technical Evaluation on capacity to deliver the contract

Stage 4: The Financial Evaluation

Stage 5: Due Diligence and Presentations

Stage 6: Recommendation of Award.

22

STAGE 1: MANDATORY REQUIREMENTS (MR) The following mandatory requirements must be met notwithstanding other requirements in the document.

Bidders will be required to meet all the Mandatory Requirements to qualify to proceed to the Technical Evaluation Stage.

STAGE 2: TECHNICAL EVALUATION

Annex A Lot 1: Portfolio Management and Trade Processing System (PMTP)

Besides the mandatory requirements in Stage 1 above, the bidders will also need to comply with all mandatory requirements in Annex A – Section A Part II (page 13) before the evaluation of technical requirements in Annex A – Section A Part II (page 18). Failure to comply with all the Mandatory Requirements at this stage will lead to dropping of the bid (Lot A) from further evaluation and eventual procurement.

The tenderer must demonstrate compliance to the technical specifications provided in Annex A – Section A Part II (page 18). The responses to each requirement must be accompanied by a detailed explanation and supported with relevant documentation. The tenderers are encouraged to attach supporting links or references in their responses. The bid will be

NO REQUIREMENTS TENDERER’S RESPONSE

MR 1 Provide copy of the company’s certificate of incorporation (or equivalent document confirming the legal structure of the company)

MR 2 Provide a copy of the company’s valid Certificate of Tax Compliance issued by the bidder’s country of origin tax authority, valid at least up to the tender closing date.

MR 3 Submit a completed Company’s profile using the Confidential Business Questionnaire Form as provided in the tender document.

MR 4 Provide an original Tender Security of US 10,000.00 and must be valid for 150 days in the format provided in this tender document.

MR 5 Provide confirmation that you are the developer and owner of the proposed system

MR 5 Provide three letters of reference from three (3) Central Banks or other institutions of a similar scale & size, where the same product was provided within the last five (5) years. A reference shall be valid if it is for the same proposed IT solution as described in the bidder’s response. Each of the three letters must be signed by a named contact.

MR6 Audited financials for the latest three (3) financial years (2018,2019, 2020)

23

considered responsive at this stage if the bidder scores a minimum of 75%. Failure to attain a seventy-five percent score at this stage will lead to dropping of bid (Lot A) from further evaluation and eventual procurement.

Annex B. Lot 2: Investment Risk Management System (IRMS)

Besides the mandatory requirements in Stage 1 above, the bidders will also need to comply with all mandatory requirements in Annex B – Section A Part II (page 8) before the evaluation of technical requirements in Annex B – Section A Part II (page 12). Failure to comply with all the Mandatory Requirements at this stage will lead to dropping of the bid (Lot B) from further evaluation and eventual procurement.

The tenderer must demonstrate compliance to the technical specifications provided in Annex B – Section A Part II (page 12). The responses to each requirement must be accompanied by a detailed explanation and supported with relevant documentation. The tenderers are encouraged to attach supporting links or references in their responses. The bid will be considered responsive at this stage if the bidder scores a minimum of 75%. Failure to attain a seventy-five percent score at this stage will lead to dropping of bid (Lot B) from further evaluation and eventual procurement.

STAGE 3: EVALUATION OF TECHNICAL CAPACITY TO DELIVER THE PROPOSED

SOLUTION

At this stage, bidders should demonstrate their capacity in terms of project planning, professional experience, and technical personnel to deliver the proposed solution. Only bidders that successfully demonstrate their capacity to deliver the proposed solution as per the criteria outlined in the sections below, will proceed to Stage 4 (Financial Evaluation). The evaluation criteria will include the sections outlined below:

1. Project plan: The bidder must submit a high-level project plan for the implementation of the proposed solution. The system implementation plan must have a well-defined project schedule with deliverables broken into tasks with trackable milestones and timelines.

2. Data migration strategy: The bidder should provide a detailed data migration

strategy, clearly outlining: a. The methodology that will be followed, b. The entire data sets that will be in scope for each of the business unit.

i. Note: Any data migration scope limitations should be clearly mentioned in the response for the evaluators to review.

c. Assurance steps that will be invoked to double check data movement to detect errors, omissions, duplicates, etc. including who exactly will carry out this work stream and how it will be reported.

3. Bidder Competency: The bidder must describe the competencies, roles and responsibilities of the proposed project team members, and support their response by attaching their curriculum vitaes (CV’s) and academic certificates. These must be relevant and skilled resources who:

a. Are qualified to implement the proposed solution.

24

b. Have prior experience (at least three years’ experience) deploying similar solutions in Central Banks and in other organizations of a similar scale and size to Central Bank of Kenya.

c. Will be accessible, committed, engaged, and tied to the project for the entire duration of the project implementation cycle.

d. Cut across (but not necessarily limited to) the following domains: i. Steering Committee Members

ii. Project Manager iii. IT Technical Leads iv. Functional Analysts v. Business consultants (SME for each business area which includes Trading,

Accounting, Portfolio Management, Risk Management and Technical Support Lead)

vi. Cyber Security subject matter experts

The table below outlines the requirements to be used when the bidder provides their response in the curriculum vitaes (CV’s).

DOMAIN No. of Relevant (CV’s)

Minimum Years Of Experience

Front Office – Trading and Portfolio Management

2 At least 3 years

Middle Office – Performance Measurement, Risk Management and Compliance Monitoring

2 At least 3 years

Back Office – Settlements, Accounting 2 At least 3 years

Information Technology (IT) Consultants: 1. Apps developer / Integrations Lead 2. System Administrator 3. Database Administrator (DBA) 4. Security Leads

2 1 1 1

At least 3 years

Tenderers fully complying with technical specifications will be subjected to technical evaluation on capacity to deliver the contract based on the technical parameters given below:

Evaluation Attribute Tenderer’s Response

Weighting Score Max Score %

T1 Number of years the product / solution has been in the market

• 5 Years and above: 30%

• Others prorated at: Number of years x 30 5

30

25

T2 Provide a list of all Major clients where the company has provided similar services in the last 5 years.

• 5 or more clients: 30%

• Others prorated at: Number of clients x 30 5

30

T3 Number of qualified consultants / officers specialized in investment management systems (Must provide evidence using CV and certificates)

• 5 or more qualified staff: 20%

• Others prorated at: Number of staff x 20 5

20

T4 Financial Stability: a) Profitability Margin**

A margin above 10% will score 10 marks; 5-9 % - 5 marks and 1-4% - 3 marks; below 1% No mark

10

b) Liquidity Ratio***

Above 1:1 – 10 marks; 1:1 – 5 marks; 0.5:1- 2 marks less than 0.5 no mark

10

Total 100 **Profitability Margin = ______EBIT___ Gross Revenue/Sales ***Current Ratio = Current Assets Current Liabilities

✓ EBIT = Earnings Before Interest and Taxes

Only tenderers that score 75% and above on the above capacity to deliver will qualify for Financial Evaluation. STAGE 4: FINANCIAL EVALUATION.

Financial Evaluation involves checking for completeness of the Bidders’ schedule of pricing to ensure all the Bills of Materials, Terms of References, Software, Support and Services have been priced and quotations are accurate. Bidders whose price schedules are not complete i.e. where the bidder fails to price for all materials, terms of references, software (all required modules) and services are disqualified from further evaluation.

In providing the response for the commercials/pricing, the bidder must consider and include provisions for post-production support and warranty period of at least one (1) year after deployment of the solution. Thereafter, the bidder must also provide a comprehensive maintenance and support plan for the deployed solution for at least three (3) years. These post-go live maintenance and support plans must be in accordance to the bidder’s response on the roles and responsibilities as outlined in the technical specifications schedule.

At this stage, Tenderers that score 75 % and above under Technical Evaluation on Capacity to deliver the contract will be ranked and the lowest financial bidder recommended for due diligence and presentations.

26

Stage 5: Due diligence and Oral presentation The bidder with the lowest financial bid whose technical score is above 75% will be subjected to due diligence. The exercise will involve verification of the bidder’s qualification information submitted in compliance with the mandatory requirements, technical requirements, to confirm the bidder’s ability and capability to provide the services. The Central Bank of Kenya team may also visit at least two organizations where the bidder is offering/has offered similar services in the last three years. The respective bidder will be required to secure appointment with the respective organizations on behalf of the Central Bank of Kenya team. The feed-back from the firms/clients visited on the quality of the services provided by the respective bidder will be used to assess the bidder’s ability to execute the Bank’s prospective contract. Due diligence will also involve oral presentations by the lowest evaluated bidder. Representatives of the Bank will also hold discussions with the vendor’s representative on the Technical Requirements/Terms of References (TORS) and any other suggestions made by the prospective Vendor to improve the Terms of References. The Central Bank of Kenya and the lowest evaluated tenderer undergoing due diligence will then work out final Terms of References, Technical specifications, etc. The agreed final Terms of Reference will then be incorporated in the “Statement of Work” and form part of the Contract. Special attention will be paid to getting the most of what the prospective provider can offer within the available budget and time. In the event that the vendor with lowest evaluated bid is found to have provided false information in regard to the bidder’s qualifications or adverse report is provided by the bidder’s clients on the quality of services provided to the clients, then the bidder will be disqualified at this stage. Consequently, the second lowest evaluated bidder who submitted the tender that, according to the evaluation would have been successful had the lowest evaluated bid not been submitted will be subjected to due diligence for consideration of award Stage 6: Recommendation of Award The bidder which complies with all the Mandatory Requirements, with technical requirements complying with the all the requirements as contained in the tender document, scores 75% or above, emerges with lowest bid at the financial evaluation stage and passes the due diligence will then be recommended for award upon successful negotiation.

27

SECTION III: GENERAL CONDITIONS OF CONTRACT

3.1 Definitions

In this contract the following terms shall be interpreted as indicated:

a) “The contract” means the agreement entered into between the Central Bank of Kenya and the tenderer as recorded in the Contract Form signed by the parties, including all attachments and appendices thereto and all documents incorporated by reference therein.

b) “The Contract Price” means the price payable to the tenderer under the Contract for the full and proper performance of its contractual obligations.

c) “The services” means services to be provided by the contractor including materials and incidentals which the tenderer is required to provide to the Central Bank of Kenya under the Contract.

d) “The Central Bank of Kenya” means the organization sourcing for the services under this Contract.

e) “The contractor means the individual or firm providing the services under this Contract.

f) “GCC” means general conditions of contract contained in this section

g) “SCC” means the special conditions of contract

h) “Day” means calendar day

3.2 Application These General Conditions shall apply to the extent that they are not superseded by provisions of other part of contract.

3.3 Standards

3.3.1 The services provided under this Contract shall conform to the standards mentioned in the Schedule of requirements

3.5 Patent Right’s The tenderer shall indemnify the Central Bank of Kenya against all third-party claims of infringement of patent, trademark, or industrial design rights arising from use of the services under the contract or any part thereof .

3.6 Performance Security Within twenty eight (28) days of receipt of the notification of Contract award, the successful tenderer shall furnish to the Central Bank of Kenya the performance security where applicable in the amount specified in Special Conditions of Contract.

28

3.6.2 The proceeds of the performance security shall be payable to the Central Bank of Kenya as compensation for any loss resulting from the Tenderer’s failure to complete its obligations under the Contract.

3.6.3 The performance security shall be denominated in the currency of the Contract, or in a freely convertible currency acceptable to the Central Bank of Kenya and shall be in the form of:

a) Cash. b) A bank guarantee. c) Letter of credit.

3.6.4 The performance security will be discharged by the Central Bank of Kenya and returned to the candidate not later than thirty (30) days following the date of completion of the tenderer’s performance of obligations under the contract, including any warranty obligations under the contract.

3.7 Inspections and Tests

3.7.1 The Central Bank of Kenya or its representative shall have the right to inspect And/or to test the services to confirm their conformity to the Contract specifications. The Central Bank of Kenya shall notify the tenderer in writing, in a timely manner, of the identity of any representatives retained for these purposes.

3.7.2 The inspections and tests may be conducted on the premises of the tenderer or its subcontractor(s). If conducted on the premises of the tenderer or its subcontractor(s), all reasonable facilities and assistance, including access to drawings and production data, shall be furnished to the inspectors at no charge to the Central Bank of Kenya.

3.7.3 Should any inspected or tested services fail to conform to the Specifications, the Central Bank of Kenya may reject the services, and the tenderer shall either replace the rejected services or make alterations necessary to meet specification requirements free of cost to the Central Bank of Kenya.

3.7.4 Nothing in paragraph 3.7 shall in any way release the tenderer from any warranty or other obligations under this Contract.

3.8 Payment

3.8.1 The method and conditions of payment to be made to the tenderer under this Contract shall be specified in SCC

3.9 Prices

Prices charged by the contractor for services performed under the Contract shall not, with the exception of any Price adjustments authorized in SCC, vary from the prices by the tenderer in its tender or in the Central Bank of Kenya’s request for tender validity extension as the case may be. No variation in or modification to the terms of the contract shall be made except by written amendment signed by the parties.

29

3.10 Assignment

The tenderer shall not assign, in whole or in part, its obligations to perform under this contract, except with the Central Bank of Kenya’s prior written consent.

3.10 Termination for Default The Central Bank of Kenya may, without prejudice to any other remedy for breach of Contract, by written notice of default sent to the tenderer, terminate this Contract in whole or in part:

a) if the tenderer fails to provide any or all of the services within the period(s) specified in the Contract, or within any extension thereof granted by the Central Bank of Kenya.

b) if the tenderer fails to perform any other obligation(s) under the Contract.

c) if the tenderer, in the judgment of the Central Bank of Kenya has engaged in corrupt or fraudulent practices in competing for or in executing the Contract.

In the event the Central Bank of Kenya terminates the Contract in whole or in part, it may procure, upon such terms and in such manner as it deems appropriate, services similar to those undelivered, and the tenderer shall be liable to the Central Bank of Kenya for any excess costs for such similar services.

3.12 Termination of insolvency The Central Bank of Kenya may at the anytime terminate the contract by giving written notice to the contractor if the contractor becomes bankrupt or otherwise insolvent. In this event, termination will be without compensation to the contractor, provided that such termination will not produce or affect any right of action or remedy, which has accrued or will accrue thereafter to the Central Bank of Kenya.

3.13 Termination for convenience

3.13.1 The Central Bank of Kenya by written notice sent to the contractor may terminate the contract in whole or in part, at any time for its convenience. The notice of termination shall specify that the termination is for the Central Bank of Kenya convenience, the extent to which performance of the contractor of the contract is terminated and the date on which such termination becomes effective.

3.13.2 For the remaining part of the contract after termination the Central Bank of Kenya may elect to cancel the services and pay to the contractor on agreed amount for partially completed services.

3.14 Resolution of disputes

The Central Bank of Kenya’s and the contractor shall make every effort to resolve amicably by direct informal negotiations any disagreement or dispute arising between them under or in connection with the contract.

30

If after thirty (30) days from the commencement of such informal negotiations both parties have been unable to resolve amicably a contract dispute either party may require that the dispute be referred for resolution to the formal mechanisms specified in the SCC.

3.15 Governing Language

The contract shall be written in the English language. All correspondence and other documents pertaining to the contract, which are exchanged by the parties, shall be written in the same language.

3.16 Force Majeure The contractor shall not be liable for forfeiture of its performance security, or termination for default if and to the extent that its delay in performance or other failure to perform its obligations under the Contract is the result of an event of Force Majeure.

3.17 Applicable Law. The contract shall be interpreted in accordance with the laws of Kenya unless otherwise specified in the SCC

3.18 Notices Any notices given by one party to the other pursuant to this contract shall be sent to the other party by post or by fax or E-mail and confirmed in writing to the other party’s address specified in the SCC. A notice shall be effective when delivered or on the notices effective date, whichever is later.

31

SECTION IV: SPECIAL CONDITIONS OF CONTRACT (SCC) 4.1 Special conditions of contract shall supplement the general conditions of contract,

wherever there is a conflict between the GCC and the SCC, the provisions of the SCC herein shall prevail over those in the GCC.

4.2 Special conditions of contract with reference to the general conditions of contract.

General conditions of contract reference

Special conditions of contract

3.1 (b) The contract price will be in US Dollars.

3.1 (C) The project to be undertaken is for TENDER FOR SUPPLY,

DELIVERY, TESTING AND COMMISSIONING OF

PORTFOLIO MANAGEMENT AND TRADE PROCESSING

SYSTEM (PMTP) and INVESTMENT RISK MANAGEMENT

SYSTEM (IRMS) (REF. NO.CBK/25/2020/2021)

3.1 (d) The Central Bank of Kenya is Central Bank of Kenya, P. O. Box 60000 – 00200, Nairobi

3.6 The successful tenderer shall furnish to the Central Bank of Kenya the performance security equivalent to 5% of the contract sum from a commercial Bank operating in Kenya supervised by the Central Bank of Kenya.

3.7 The supervisor of the service under the contract is the Office of the Director, Financial Markets/Information Technology Department.

3.8 Payment will be made after the installation and testing of the system and upon submission of invoice and signing of certificate of Services issued by a representative of the Office of the Director, Financial Markets Department.

3.9 No price adjustments will be allowed unless under exceptional. circumstances and upon approval by the Bank

3.13.1 Termination of the contract shall be done by either party giving the other 30 days notice.

3.14 If both parties have been unable to resolve amicably a contract dispute either party may require that the dispute be referred for resolution to an Arbitrator or to a court of law.

3.17 The laws of Kenya shall apply

3.18 The address to be used for purposes of notices will be: The Director, General Services Department, P. O. Box 60000 – 00200, Nairobi. Email: supplies@centralbank.go.ke

32

1. Penalty for non-performance

In the event of non-performance of the service provider, the Bank will give the service provider a one-month notice giving details of the shortcomings that the service provider is expected to rectify. If the service provider fails to show improvement in his/her performance during the one-month notice, then the Bank will terminate the contract and call up the Bank Guarantee provided by the service provider.

33

SECTION V – SCHEDULE OF REQUIREMENTS AND PRICE SCHEDULE

LOT 1: Portfolio Management and Trade Processing System (PMTP)

Cost Items Amount (USD)

1. On-Premise Perpetual Software License for Portfolio Management and Trade Processing System (PMTP)

Provide the licensing cost by module where the system is made up of modules

2. Third - Party Components Licenses

3. Integration Costs

4. Implementation Costs

5. Training Costs

6. One Year Warranty ( starting three (3) months after Go-Live)

Free

7. Annual Maintenance Cost (3 years)

Total Costs

LOT 2: Investment Risk Management System (IRMS)

Cost Items Amount (USD)

1. On-Premise Perpetual Software License – Investment Risk Management System Provide the licensing cost by module where the system is made up of modules

2. Third - Party Components Licenses

3. Integration Costs

4. Implementation Costs

5. Training Costs

6. One Year Warranty ( starting three (3) months after Go-Live)

Free

7. Annual Maintenance Cost (3 years)

Total Costs

34

SECTION VI: TECHNICAL REQUIREMENTS, SERVICES AND DELIVERABLES

A. BACKGROUND

The Central Bank of Kenya (CBK) was established by an Act of Parliament of March 24, 1966 and

opened its doors to the public on September 14, 1966. The Bank is now anchored in the Constitution

under Article 231. The Bank is responsible for formulating monetary policy to achieve and maintain

price stability and issuing currency.

Pursuant to the Central Bank of Kenya Act, the Central Bank promotes financial stability through

regulation, supervision and licensing of financial institutions under its mandate. The Bank also

provides oversight of payment, clearing and settlement systems. All these efforts are geared

towards fostering liquidity, solvency and proper functioning of the financial system. The Bank also

formulates and implements foreign exchange policy and manages foreign exchange reserves. CBK

is the banker for, adviser to, and fiscal agent of the Government.

In discharging its mandate, the Central Bank contributes to the country’s economic development

and growth and promotes the interest of the public. The Bank strives to carry out its statutory

mandate effectively and efficiently guided by the principles of integrity and transparency

Business Objectives of the Purchaser

The Central Bank of Kenya (CBK) is responsible for the management of foreign exchange reserves.

The objectives of holding foreign exchange reserves include:

a) To provide policy option to cushion the country from possible foreign currency net imbalances

in the balance of payments and protect the country’s wellbeing in the event of national calamity

or external shocks;

b) To provide foreign currency liquidity and flexibility to finance government forex obligations;

c) To enhance market confidence in the Kenya’s economy; and

d) To facilitate policy actions to smoothen excessive volatility in the foreign exchange market and

support monetary policy framework.

The Portfolio Management and Transaction Processing System (PMTP) and Investment Risk

Management System (IRMS) will support the investment management process for foreign currency

reserves and enable users in the portfolio management (front office), risk and analytics (middle

office) and operations (back office) areas to achieve the following:

a) Portfolio Management and Trade Execution

b) Portfolio Risk and Scenario Analysis;

c) Portfolio Performance Measurement and Attribution;

d) Compliance Monitoring;

e) Accounting and Settlement;

f) Reporting;

g) Interface to Trading and Messaging Platforms – SWIFT, Bloomberg, Reuters;

h) Maintenance of audit trails of all changes made in the system.

35

B. SCOPE OF SERVICES AND DELIVERABLES

I. PORTFOLIO MANAGEMENT AND TRADE PROCESSING SYSTEM (PMTP)

SCOPE OF SERVICES

The Bank is seeking not only a supplier(s) of the software but also partnership with the provider

to help the Bank in leveraging this solution through a sound implementation approach and

proven organizational adoption tools. Based on this, the scope will include the following:

a) Supply, install, configure, customize and maintain Portfolio Management and Trade

Processing System (PMTP) that will meet the functional and technical requirements as

specified in this RFP (see Annex A).

b) Provide system that will be able to accommodate 50 users and shall be hosted in the

Bank premises and shall be compatible and integrated into the Banks’s IT infrastructure.

c) Develop and propose an implementation methodology with roadmap/schedule with

monitoring targets and risks towards the desired target Portfolio Management and

Trade Processing System (PMTP) from the installation through deployment of the

solution.

d) Carry out implementation services of the solution as stated in the proposed roadmap

from installation, configuration, customization and final deployment of the solution

system.

e) Provide maintenance service for the solution including software version upgrade.

f) Provide support and assistance including both remote and local/onsite assistance for

resolution of major technical problems or technical issues.

g) Provide a flexible open solution for expansion to cover other asset types that may not be

included in the initial version

DELIVERABLES

Vendors should provide comfort to the Central Bank of Kenya that the solution meets the

requirements specified in the Terms of Reference. Upon the completion of the project, the

solution vendor shall provide a comprehensive report with details of completed implementation

of project. The Bank expects to receive from Vendor the following outputs:

a) A fully installed, well configured, integrated, customized and functioning PORTFOLIO

MANAGEMENT AND TRADE PROCESSING SYSTEM (PMTP) that meets the need of

Central Bank of Kenya business requirements as specified in the scope of the services.

b) A proposal for the implementation of gaps that would have been identified by

Management during the live demonstration of the solution implemented.

c) A detailed description of completed implementation work.

d) An executive summary report validating the implementation process and the various

functionalities specified in the TOR.

e) Training services for the solution before and during the implementation to end-users

and technical staff for knowledge transfer both on the functional and technical aspects

36

f) Full documentation of the solution from the installation, configuration and

customization to deployment. The documentation shall include the user manual.

II. INVESTMENT RISK MANAGEMENT SYSTEM (IRMS)

SCOPE OF SERVICES

The Bank is seeking not only a supplier(s) of the software but also partnership with the provider

to help the Bank in leveraging this solution through a sound implementation approach and

proven organizational adoption tools. Based on this, the scope will include the following:

a) Supply, install, configure, customize and maintain Investment Risk Management System

(IRMS) that will meet the functional and technical requirements as specified in this RFP (see

Annex B).

b) Provide system that will be able to accommodate 20 users and shall be hosted in the Bank

premises and shall be compatible and integrated into the Banks’s IT infrastructure.

c) Develop and propose an implementation methodology with roadmap/schedule with

monitoring targets and risks towards the desired target Investment Risk Management

System (IRMS) from the installation through deployment of the solution.

d) Carry out implementation services of the solution as stated in the proposed roadmap from

installation, configuration, customization and final deployment of the solution system.

e) Provide maintenance service for the solution including software version upgrade.

f) Provide support and assistance including both remote and local/onsite assistance for

resolution of major technical problems or technical issues.

g) Provide a flexible open solution for expansion to cover other asset types that may not be

included in the initial version

DELIVERABLES

Vendors should provide comfort to the Central Bank of Kenya that the solution meets the

requirements specified in the Terms of Reference. Upon the completion of the project, the

solution vendor shall provide a comprehensive report with details of completed implementation

of project. The Bank expects to receive from Vendor the following outputs:

a) A fully installed, well configured, integrated, customized and functioning INVESTMENT

RISK MANAGEMENT SYSTEM (IRMS) that meets the need of Central Bank of Kenya

business requirements as specified in the scope of the services.

b) A proposal for the implementation of gaps that would have been identified by

Management during the live demonstration of the solution implemented.

c) A detailed description of completed implementation work.

d) An executive summary report validating the implementation process and the various

functionalities specified in the TOR.

e) Training services for the solution during the implementation to technical staff for

knowledge transfer both on the functional and technical aspects and to users on

functional aspects.

f) Full documentation of the solution from the installation, configuration and

customization to deployment. The documentation shall include the user manual.

37

C. TECHNICAL SPECIFICATIONS

1) Technical Specifications for Management and Trade Processing System (PMTP)

Refer to Annex A: Business and Technology Requirements for Portfolio Management and Trade

Processing System (PMTP)

2) Technical Specifications for Investment Risk Management System (IRMS)

Refer to Annex B: Business and Technology Requirements for Investment Risk Management

System (IRMS)

38

SECTION VII- STANDARD FORMS

7.1 Form of tender

7.2 Contract Agreement Form

7.3 Form of Tender Security

7.4 Performance Security Form

7.5 Confidential Questionnaire Form

7.6 Letter of Notification of Award

7.7 Form RB1

7.8 Declaration Form

39

7.1 FORM OF TENDER

Date____________________________ Tender No._______________________

To……………………..

…………………………..

[Name and address of Central Bank of Kenya]

Gentlemen and/or Ladies:

1. Having examined the tender documents including Addenda Nos.. [insert numbers, the of which is hereby duly acknowledged, we, the undersigned, offer to provide. [description of services] in conformity with the said tender documents for the sum of . [total tender amount in words and figures] or such other sums as may be ascertained in accordance with the Schedule of Prices attached herewith and made part of this Tender.

2. We undertake, if our Tender is accepted, to provide the services in accordance with the services schedule specified in the Schedule of Requirements.

3. If our Tender is accepted, we will obtain the tender guarantee in a sum equivalent to _____ percent of the Contract Price for the due performance of the Contract, in the form prescribed by (Central Bank of Kenya).

4. We agree to abide by this Tender for a period of [number] days from the date fixed for tender opening of the Instructions to tenderers, and it shall remain binding upon us and may be accepted at any time before the expiration of that period.

5. Until a formal Contract is prepared and executed, this Tender, together with your written acceptance thereof and your notification of award, shall constitute a binding Contract between us.

Dated this _________________ day of_________________ 20 [signature] [In the capacity of] Duly authorized to sign tender for and on behalf of___________

40

7.2 CONTRACT AGREEMENT FORM

THIS AGREEMENT made the ___day of _____20____between…………[name of procurement entity] of ……………….[country of Procurement entity](hereinafter called “the Central Bank of Kenya”) of the one part and ……………………[name of tenderer] of ……….[city and country of tenderer](hereinafter called “the tenderer”) of the other part. WHEREAS the Central Bank of Kenya invited tenders for software and services. Viz……………………..[brief description of software and services] and has accepted a tender by the tenderer for the supply of those software and services in the sum of ………………………………………[contract price in words and figures]

NOW THIS AGREEMENT WITNESSETH AS FOLLOWS: 1. In this Agreement words and expressions shall have the same meanings as are

respectively assigned to them in the Conditions of Contract referred to.

2. The following documents shall be deemed to form and be read and construed as part of this Agreement, viz.:

(a) the Tender Form and the Price Schedule submitted by the tenderer; (b) the Schedule of Requirements; (c) the Technical Specifications; (d) the General Conditions of Contract; (e) the Special Conditions of Contract; and (f) the Central Bank of Kenya’s Notification of Award.

3. In consideration of the payments to be made by the Central Bank of Kenya to the tenderer as hereinafter mentioned, the tenderer hereby covenants with the Central Bank of Kenya to provide the software and services and to remedy defects therein in conformity in all respects with the provisions of the Contract

4. The Central Bank of Kenya hereby covenants to pay the tenderer in consideration of the provision of the software and services and the remedying of defects therein, the Contract Price or such other sum as may become payable under the provisions of the contract at the times and in the manner prescribed by the contract.

IN WITNESS whereof the parties hereto have caused this Agreement to be executed in accordance with their respective laws the day and year first above written.

Signed, sealed, delivered by___________the _________(for the Central Bank of Kenya)

Signed, sealed, delivered by___________the __________(for the tenderer)

in the presence of_______________.

41

7.3 FORM OF TENDER SECURITY

WHEREAS………………………………………………………………………… (hereinafter called “the Tenderer”) has submitted his tender dated……………….for Supply, Installation, Testing and commissioning of the Reserves Investment Management System for Central Bank of Kenya.

KNOW ALL PEOPLE by these presents that WE,…………………………………..….…… ……………………………………………………………………………………………….....….. having our registered office at …………………………...…………………………………..… (Hereinafter called “the Bank”), are bound unto CENTRAL BANK OF KENYA (hereinafter called “the Employer”) in the sum of USD 10,000.00 for which payment well and truly to be made to the said Employer, the Bank binds itself, its successors and assigns by these presents, sealed with the Common Seal of the said Bank this……………………..day of …………………….2014 THE CONDITIONS of this obligation are: 1. If after tender opening the Tenderer withdraws his tender during the period of

tender validity specified in the instructions to Tenderers OR 2. If the Tenderer, having been notified of the acceptance of his tender by the Employer

during the period of tender validity:

a) fails or refuses to execute the form of Agreement in accordance with the Instructions to Tenderers, if required; or

b) fails or refuses to furnish the Performance Security, in accordance with the Instructions to Tenderers;

We undertake to pay to the Employer up to the above amount upon receipt of his first written demand, without the Employer having to substantiate his demand, provided that in his demand the Employer will note that the amount claimed by him is due to him, owing to the occurrence of one or both of the two conditions, specifying the occurred condition or conditions. This guarantee will remain in force up to and including thirty (30) days after the period of tender validity, and any demand in respect thereof should reach the Bank not later than the said date.

___________________ ________________ (Date) Signature of the Bank) ___________________(Witness) _________________(Seal)

42

7.4 PERFORMANCE SECURITY FORM To …………………………………………. [name of Central Bank of Kenya] WHEREAS …………………………………… [name of tenderer] (hereinafter called “the tenderer”) has undertaken , in pursuance of Contract No. [reference number of the contract] dated 20 to supply ……………………………………………… [description of goods] (hereinafter called “the Contract”). AND WHEREAS it has been stipulated by you in the said Contract that the tenderer shall furnish you with a bank guarantee by a reputable bank for the sum specified therein as security for compliance with the Tenderer’s performance obligations in accordance with the Contract. AND WHEREAS we have agreed to give the tenderer a guarantee: THEREFORE WE hereby affirm that we are Guarantors and responsible to you, on behalf of the tenderer, up to a total of ………………………. [amount of the guarantee in words and figure] and we undertake to pay you, upon your first written demand declaring the tenderer to be in default under the Contract and without cavil or argument, any sum or sums within the limits of …………………….. [amount of guarantee] as aforesaid, without you needing to prove or to show grounds or reasons for your demand or the sum specified therein. This guarantee is valid until the day of 20 Signed and seal of the Guarantors [name of bank or financial institution] [address] [date]

43

7.5 CONFIDENTIAL BUSINESS QUESTIONNAIRE FORM

You are requested to give the particulars indicated in Part 1 and either Part 2(a), 2(b) or 2 (c ) whichever applied to your type of business. You are advised that it is a serious offence to give false information on this form

Part 1 – General:

Business Name ………………………………………………………………………………………………

Location of business premises. ………………………………………………………………………………

Plot No………………………………………………… Street/Road ………………………………………..

Postal Address ……………………….. Tel No. …………………. Fax ………………. E mail …………….

Nature of Business …………………………………………………………………………………………..

Registration Certificate No. …………………………………………………………………………………

Maximum value of business which you can handle at any one time – Kshs. …………………………

Name of your bankers ……………………………………….. Branch ……………………………………

Part 2 (a) – Sole Proprietor

Your name in full …………………………………………………….. Age ………………………..

Nationality ………………………………… Country of origin…………………………………….

Citizenship details …………………………………………………….

Part 2 (b) Partnership

Given details of partners as follows:

Name Nationality Citizenship Details Shares

1. ………………………………………………………………………………………….…… 2. …………………………………………………………………………………………….… 3. …………………………………………………………………………………………..…..

Part 2 (c ) – Registered Company

Private or Public …………………………………………………………………………………….

State the nominal and issued capital of company-

Nominal Kshs. ………………………………

Issued Kshs. …………………………………

Given details of all directors as follows

Name Nationality Citizenship Details Shares

1…………………………………………………………………………………………………………

2. ………………………………………………………………………………………………………..

3. ………………………………………………………………………………………………………

4. ………………………………………………………………………………………………………

Date ………………………………………………….. Signature of Candidate ………………………………..

If a Kenya Citizen, indicate under “Citizenship Details” whether by Birth, Naturalization or registration.

44

7.6. LETTER OF NOTIFICATION OF AWARD

Address of Central Bank of Kenya

_____________________ _____________________ To: RE: Tender No. Tender Name This is to notify that the contract/s stated below under the above mentioned tender have been awarded to you.

1. Please acknowledge receipt of this letter of notification signifying your acceptance. 2. The contract/contracts shall be signed by the parties within 30 days of the date of

this letter but not earlier than 14 days from the date of the letter.

3. You may contact the officer(s) whose particulars appear below on the subject matter

of this letter of notification of award. (FULL PARTICULARS)

SIGNED FOR ACCOUNTING OFFICER

45

7.7. FORM RB 1 REPUBLIC OF KENYA PUBLIC PROCUREMENT ADMINISTRATIVE REVIEW BOARD APPLICATION NO…………….OF……….….20……... BETWEEN …………………………………………….APPLICANT AND …………………………………RESPONDENT (Central Bank of Kenya) Request for review of the decision of the…………… (Name of the Central Bank of Kenya) of ……………dated the…day of ………….20……….in the matter of Tender No………..…of …………..20… REQUEST FOR REVIEW I/We……………………………,the above named Applicant(s), of address: Physical address…………….Fax No……Tel. No……..Email ……………, hereby request the Public Procurement Administrative Review Board to review the whole/part of the above mentioned decision on the following grounds , namely:- 1. 2. …. By this memorandum, the Applicant requests the Board for an order/orders that: - 1. 2. …. SIGNED ……………….(Applicant) Dated on…………….day of ……………/…20…

FOR OFFICIAL USE ONLY Lodged with the Secretary Public Procurement Administrative Review Board on ………… day of ………....20….……… SIGNED Board Secretary

46

7.8 DECLARATION FORM

Date To The tenderer i.e. (name and address) declare the following:

a) Has not been debarred from participating in public procurement.

b) Has not been involved in and will not be involved in corrupt and fraudulent practices regarding public procurement.

Title Signature Date (To be signed by authorized representative and officially stamped)

ANNEX A

INTERNATIONAL TENDER FOR SUPPLY, DELIVERY, TESTING

AND COMMISSIONING OF PORTFOLIO MANAGEMENT AND TRADE PROCESSING SYSTEM (PMTP)

REF. NO. CBK/25/2020/2021

BUSINESS AND INFORMATION TECHNOLOGY (IT) REQUIREMENTS

2

TABLE OF CONTENTS

PAGE

SECTION A BUSINESS REQUIREMENTS ………................…………...3 PART 1 - STATEMENT OF WORK……………………………………………………..….3

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE………….13

SECTION B INFORMATION TECHNOLOGY REQUIREMENTS …35

PART 1 - STATEMENT OF WORK………………………………………………………...35

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE…………...59

APPENDIX A LIST OF INVESTMENT INSTRUMENTS…………….…74

APPENDIX B LIST OF SWIFT MESSAGE TYPES ………………………75

APPENDIX C SYSTEM INTERFACES ………………………………….…80

APPENDIX D TYPES OF PAYMENTS AND RECEIPTS …………….....82

3

Section A: Business Requirements

PART 1 – STATEMENT OF WORK

Background

The Central Bank of Kenya (herein referred to as “CBK” or “the Bank”) is established under article 231 of the Constitution of Kenya 2010 and governed by the Central Bank of Kenya Act Cap 491 laws of Kenya (the CBK Act) and has its Head office in Nairobi and three branches in Mombasa, Kisumu and Eldoret. The principal object of the Bank is to formulate and implement monetary policy directed to achieving and maintaining stability in the general level of prices. In fulfilling this mandate, the Bank fosters the liquidity, solvency, and proper functioning of a stable market-based financial system. Amongst its other objects, the Bank is also required by statute to hold and manage the country’s foreign exchange reserves. Overview of CBK’s Forex Reserves Management

Foreign Exchange Reserves play a key role in ensuring that Kenya will be able to maintain confidence in its monetary, financial stability and exchange rate policies and protect the economic well-being of the country in the event of external shocks. In accordance with its role as a central bank and as provided in the Central Bank of Kenya Act 2015 (CBK Act), the official foreign exchange reserves of the Republic of Kenya are held and managed by the Central Bank of Kenya (CBK). The CBK Act requires the Bank to at all times endeavor to maintain a reserve of external assets at an aggregate amount of not less than the value of four months’ imports as recorded and averaged in the last three preceding years. The objectives of the management of the foreign exchange reserves are:

1. Safety: Investments will be undertaken with the aim of preserving the capital of the overall portfolio over the investment horizon, subject to the approved risk tolerance;

2. Liquidity: Investment management will seek to ensure that adequate reserves are available to meet a defined range of objectives. In order to maintain sufficient liquidity, the foreign reserves will as much as possible be invested in instruments or securities with an active secondary market;

3. Returns: Foreign exchange reserves will be invested in order to achieve a reasonable rate of return consistent with the investment objectives and risk constraints, after taking into consideration the two principles of Safety and Liquidity.

Statement of Need

The Central Bank of Kenya wishes to procure a Portfolio Management and Trade Processing

System for managing its foreign currency reserves. The system is expected to automate the

front and back-office operations. Specifically, the system should enable position keeping and

reporting, management of static data, valuation of assets, simulation of trade impacts,

4

calculation of performance and attribution, benchmark analysis and trade processing (from

execution to accounting).

In addition, a strong compliance monitoring capability should be provided to ensure

management of the reserves in accordance with the Investment Policy and Guidelines. A

robust trade workflow from Front to Back offices should be provided to ensure enforcement

of all required controls and reduce operational risk by eliminating duplicate data entry.

The CBK invests its forex reserves in fixed income and money market instruments (list of

instruments is provided in Appendix A). The system should at the minimum have the

following features or capabilities:

1) Trading

a) Order creation and trade entry capability including manual entry interfaces to accept

trades from trading platforms such as Bloomberg and Reuters (Refinitiv).

b) Pre-Trade analytics such as what-if analysis to evaluate different trading strategies by

assessing the impact of potential trades on P&L (return) and risk in order to manage a

bond portfolio versus its benchmark

c) Provide pre-trade and post-trade compliance checks such as counterparty exposure

versus the limit, concentration risk, value at risk (VAR), Stop loss levels to ensure

compliance with guidelines before trades are executed.

2. Portfolio Management

2.1 Position Management

a) View investible and non-investible cash and forecast future cash positions including

transactions and events that impact cash accounts.

b) Provide valuation and pricing for all instruments (see Appendix A)

c) Manage and monitor positions for all instruments (see Appendix A) on a real-time as

well as on historical basis by parameters such as: dealer, portfolio, counterparty,

product type, issuer, currency and also consolidated global risk position.

d) Provide Investment Book of Record (IBOR) that supports all functions – from the front

office, risk, through to compliance, and accounting for investments.

e) Capability to support portfolio look-through (drill-down/aggregate)

2.2 Portfolio Tranching and Optimization

The system should:

a) Support at least four (4) levels of portfolio hierarchy (see figure 2)

b) Allow assignment of appropriate benchmarks at lowest level of hierarchy (sub-

portfolio level) and aggregation of benchmarks upwards on the hierarchy.

5

c) Maintain various benchmarks (composed of a single or multiple indices) including the

index compositions and have the capability to aggregate benchmarks to match the

portfolio Tranching structure.

d) Have ability to set currency compositions and target sizes for the tranches (portfolios)

e) Allow inter-portfolio transfers of cash and positions.

f) Allow setting of upper and lower limits of tranche / portfolio in percentage or

absolute terms

g) Allow multi-currency transactions in a subportfolio

h) Enable aggregation of investments holdings by portfolio, issuer, sector, asset class etc

i) Enable classification of assets in each subportfolio according to IFRS 9 for accounting

purposes

j) Be capable of producing scenario analysis based on historical and user-defined

scenarios for historical and hypothetical scenarios.

k) Have capability of performing portfolio optimization.

Figure 2

6

2.3 Benchmark Maintenance

The system should:

a) Support the definition and maintenance of different benchmarks including custom

(modified composition of existing benchmark) and blended / composite

(benchmark with multiple asset classes) benchmarks.

b) Support the upload of index compositions and returns

c) Allow multiple portfolios to be benchmarked to a single benchmark.

d) Support multi-currency bond indices

2.4 Strategic Asset Allocation

The system should:

a) Produce scenario analysis based on historical and user-defined scenarios for historical

events and hypothetical scenarios

b) Simulate asset returns based on the defined scenarios (risk factors).

c) Perform portfolio optimization

2.5 Cashflow and Liquidity Management

The system should:

a) Show the investible cashflow by portfolio and bank accounts for portfolio managers and

accountants

b) Allow for the input of non-investment related cashflows manually or via an automated

interface from other internal systems, and update the accounts.

c) Allow for input of special cashflows to be used in generating special reports with no

impact on both accounting and portfolio performance.

d) Able to generate cashflow forecasts based on defined periods / buckets

e) Allow for upload of a schedule of non-investment payments / cashflows from file, and

produce forecasts by combining these payments and cashflows from investments to

produce holistic cashflow forecasts / projections.

2.6 External Managers

The system should be able to:

a) Provide capability to combine external manager data with internal portfolio data

(positions and cash) to monitor compliance, risk and performance of the total

reserves.

b) Provide for upload of external manager data, for accounting purposes, at both at

summarised and granular (detailed) level.

7

2.7 Pricing and Valuation

The system should be able to:

a) Support the manual upload of market data from files (CSV, Spreadsheets etc) and

direct interface to pricing sources such as Bloomberg, Refinitiv (Reuters), IDC, Markit

etc

b) Provide valuation and pricing for all instruments, including over the counter

derivatives (see Appendix A)

c) Support the construction of yield curve from market data uploaded to the system

d) Support the valuation of financial instruments off a yield curve, volatility surface, and

other valuation methods necessary to derive the fair value of a financial instrument,

including over the counter derivatives (see Appendix D)

e) Provide facility to create and maintain prices and exchange rates.

f) Provide facility to maintain a price hierarchy for the securities, i.e. the priority of price

sources within the system for portfolio valuations and allow for selection of price

types (mid, bid, ask, close).

g) Provide facility to flag pricing exceptions (i.e. missing prices, stale prices, significant

price movements, etc.) as per user defined parameters.

h) Support CSA (Credit Support Annex) discounting.

2.8 Static and Reference Data

The system should be able to:

a) Support maintenance (capture and editing) of holiday calendar by country and

currency including the functional currency (Kenya Shilling).

b) Support the maintenance of Counterparties and respective Standard Settlement

Instructions (SSIs)

c) Provide facility to maintain bank accounts and SSIs

d) Provide facility to maintain the following reference datasets: Currencies, Countries,

Issuers, Issuer Types, and Security Master.

e) System should be capable of adjusting settlements because of change in the holidays

on normal & sudden basis.

3 Trade Processing and Accounting

3.1 Accounting

The Reserves Investment Management system should be able to:

a) Maintain a chart of accounts at required granular level to assist in accounting of FX

reserves.

8

b) Support generation of accounting entries for all instrument life cycle events (trade,

settlement, coupon, maturity, interest accrual, MTM, etc.)

c) Support the mark to market of all positions; calculate gains and losses at predefined

closing rates and posting of the results.

d) Support the revaluation of Nostro Account balances at user defined frequencies and

post the resulting gains or losses.

e) Support incremental posting, manual postings and reversals.

f) Support manual adjustments via file uploads or direct input

g) Support the different instrument classifications in IFRS 9 - fair value through other

comprehensive income (FVTOCI), fair value through profit or loss (FVTPL) and

amortised cost (AC).

h) Support both straight line and effective interest rate amortization methods

i) Support file uploads of accounting transactions from fund managers and custodians.

j) Support multiple and parallel accounting frameworks such as IFRS 9 and the US

Generally Accepted Accounting Principles (US GAAP) – each framework with its own

posting rules and account mapping

k) Maintain a sub ledger and generate accounting entries for all trade lifecycle events

(trade, coupon, maturity, amortization etc) .

l) Interface the PMTP sub ledger with the CBK’s general ledger.

m) Support creation, modification and customization of accounting rules for application

to specific financial instruments, currency and product. Meanwhile, provide out of

box accounting rules as per IFRS for all required instruments

n) Support both trade date and settlement date accounting options.

o) Support institution’s compliance to International Financial Reporting Standard IFRS

9 accounting reporting standards.

p) Provide comprehensive accounting reports such as Balances in transaction currency,

Balances in reporting currency, Valuation reports per currency, Valuation reports per

product, and Valuation reports per account.

q) Provide functions for users to inquire accounting entries, as per user defined

parameters and for users to export such data out to Excel, PDF or CSV formats.

r) Support different cost basis methods: First In First Out (FIFO), and Weighted Average

Cost (WAC)

9

s) Support the valuation of all financial instruments (e.g. fixed income securities and

derivatives) as per defined rules and the posting of results (see Appendix A for the

full list of instruments).

t) Support different accrual conventions e.g. Last Not First (LNF), First Not Last (FNL).

u) Support end of accounting period in sync with the general ledger.

v) Provide support for the foreign currency translation as provided for under IAS 21.

3.2 Post-Trade Operations

The system should be able to:

a) Provide functionality for trade processing, that is, straight through trade

confirmations, matching and settlement workflows.

b) Provide for dashboard style, real-time monitoring all post-trade activities.

c) Provide alerts on new trades, outstanding actions, and errors during the trade

lifecycle.

d) Generate SWIFT confirmation, Settlement, and payment messages (MT 300, MT320,

MT541, MT543, MT 545, MT 547, MT548, MT 202, MT200 and MT210).

e) Support resubmission for trades that did not settle because of some incorrect

information between the counterparty and trade ticket.

f) Support processing of all corporate actions: coupon payments, dividends, Bonus

issues, rights issues, Mergers & acquisitions, stock splits and maturities.

3.3 Reconciliations

The system should be able to:

a) Provide functionality to accept the SWIFT (940/950 / 535) statements, and reconcile

them with ledger and positions.

b) Provide functionality to identify and match trade and payment transactions generated

in the ledger (CBK books) with related transactional messages received from

correspondent banks and counterparties through SWIFT.

c) Create and maintain reconciliation rules through parameterization.

d) Generate reconciliation reports including exception reports for appropriate

investigations.

e) Reconcile settled positions with custody.

f) Reconcile traded positions with custody.

g) Reconcile cash positions with custody.

10

h) Carry out a three-way reconciliation between accounting, custody, and the master

record keeper.

i) Load and store custody security positions for reconciliation activities.

j) Load and store custody cash positions for reconciliation activities.

k) Maintain exceptions through time including aging and run it by schedule.

l) Interface/connect with Global Custodian systems

4 Performance, Risk Management and Compliance

4.1 Performance Measurement and Attribution

The system should:

a) Produce accurate daily, weekly, monthly, quarterly, calendar and fiscal year-to-date,

rolling periods, and since inception performance reporting.

b) Calculate performance using the Global Investment Performance Standards (GIPS).

c) Calculate the following risk-adjusted performance measures: Sharpe ratio, Jensen

Alpha, Treynor ratio, Beta (ex post), Information Ratio and Sortino Ratio.

d) Show portfolio performance by a classification of choice (i.e., country, region, asset

class, sub-asset class, credit ratings, currency, Global Industry Classification Standard

(GICS) sector, manager.

e) Provide ex-post performance attribution analysis into yield, spread, currency, time

return (carry), asset allocation and selection effect.

f) Provide detailed view of the performance contribution of each the component

securities to the portfolio’s performance over time.

g) The system should be able to calculate performance based on both money-weighted

and time-weighted measures of performance.

h) Provide performance for all investment instruments in Appendix A.

i) The system should be able to incorporate accruals in the valuation of investment

instruments.

j) The system should provide performance analytics such as attribution and risk-

adjusted performance measures covering all instruments listed in Appendix A

k) Support calculation of performance in both reporting (with FX) and trade currency.

4.2 Compliance Monitoring

The system should:

11

a) Maintain compliance rules to reflect Investment Guidelines and monitor portfolio

compliance versus the rules and limits.

b) Allow the testing of the compliance rules before applying to portfolio.

c) Have a library of predefined compliance rules, and also enable creation of user-

defined rules.

d) Compliance rules should be able to run on all portfolios.

e) Be capable of defining compliance rules based on specific attributes of the security

master (i.e., credit ratings, security type, sector, country, counterparty, issuer, region,

and market of issue).

f) Be capable of defining effective from/start and effective to/end dates for all

compliance rules and maintain the history.

g) Have capability of setting up early warnings for potential compliance breaches and to

assign severity levels to those warnings.

h) Allow viewing of compliance exceptions and overrides and store a record of all

compliance violations and compliance overrides for audit purposes

i) Be able to measure various exposures, monitor counterparties' credit exposure against

authorized limits on a real-time basis: Issuer limit, portfolio manager, country limits

and counterparty limits.

5 Reporting

a) Ability to display and modify the screen set up by individual user to view positions

/ reports in different perspectives.

b) Ability to customize dashboards by user roles/groups.

c) The solution should allow reports to be exported in different formats (MS Excel, MS

word, PDF, HTML)

d) The solution should provide for report-writer tool with user-friendly capabilities of

parameterizing generating reports.

e) The solution should include a facility to enable a user to define the sorting, grouping,

and drill-down.

f) The solution should provide ability to generate reports per trading currency,

reporting currency, base currency, and local currency.

12

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE

The Tenderer must respond to every stated request or requirement and indicate that they

confirm acceptance of and understand the CBK’s stated requirements. The deferral of a

response to a question or issue to the contract negotiation stage is not acceptable. Any

item not specifically addressed in the Vendor’s proposal will be deemed as accepted by

the Vendor.

PART 2.A: MANDATORY REQUIREMENTS

The Tenderer must address all items detailed below and provide, in sequence, the

information and documentation as required.

Item Ref.

Mandatory Requirement Items Response (Yes / No)

Comments

A. 1. Provide statement indicating that the vendor’s system provides facility to construct and maintain portfolios as per investment policy and guidelines

A. 2. Provide a statement indicating that the vendor’s system provides facility to view real-time positions and cash for all portfolios

A. 3. Provide statement indicating that the vendor’s product can trade and process multiple asset classes (see appendix A)

A. 4. Provide a statement indicating that the vendor’s system has capability to model portfolio impacts of one or more stress factors: interest rate and FX shifts, credit spread changes, inflation shocks, yield curve changes etc

A. 5. Provide a statement that the vendor’s product automates the entire post-trade process: confirmation, trade matching, settlement, reconciliation, and accounting

A. 6. Provide statement indicating that the vendor’s product has

an automated interface to the SWIFTNet network to send

and receives settlement messages.

A. 7. Provide statement indicating that the Vendor’s product has capability to monitor compliance at every stage of the investment lifecycle: pre-trade, in-trade and post-trade

A. 8. Provide a statement indicating that the vendor product, at a minimum, can perform the following return attribution analysis on both a portfolio and aggregate basis: a. Excess return (curve change and carry)

b. Excess return (allocation vs. selection)

13

c. Groupings (credit ratings, sub-industry types, coupon,

etc.); and

d. Ability to incorporate derivative holdings in

performance and attribution calculations.

A. 9. Provide statement indicating that vendor’s system be installed / maintained on CBK’s own servers

14

PART 2.B: GENERAL QUALIFICATIONS & EXPERIENCE

The tenderer must address all items detailed below and provide, in sequence, the

information and documentation as required (referenced with the associated item

references). Evaluation Team members will independently evaluate and assign one score

for all responses to Section B— General Qualifications & Experience Items.

Item Ref.

General Qualifications & Experience Items

B. 1. Detail the name, e-mail address, mailing address, telephone number, and facsimile number of the person the Central Bank of Kenya should contact regarding the response.

B. 2. Describe your form of business (i.e., individual, sole proprietor, corporation, non-

profit corporation, partnership, limited liability company) and business location

(physical location or domicile).

B. 3. Briefly describe how long you have been providing the goods or services required

by this RFP.

B. 4. Provide information on your number of employees, client base (specify the

number of central banks who are part of your clients), and location of offices.

B. 5. Provide a statement of whether there have been any mergers, acquisitions, or

change of control of the Tenderer within the last ten (10) years. If so, include an

explanation providing relevant details.

B. 6. Provide a statement of whether the Tenderer or, to the Tenderer ‘s knowledge, any

of the Tenderer’s employees, agents, independent contractors, or subcontractors,

involved in the delivery of goods or performance of services on a contract

pursuant to this RFP, have been convicted of, pled guilty to, or pled nolo

contendere to any felony. If so, include an explanation providing relevant details.

B. 7. Provide a statement of whether, in the last ten (10) years, the Tenderer has filed (or

had filed against it) any bankruptcy or insolvency proceeding, whether voluntary

or involuntary, or undergone the appointment of a receiver, trustee, or assignee

for the benefit of creditors. If so, include an explanation providing relevant details.

B. 8. Provide a statement of whether there is any material, pending litigation against

the Tenderer that the Tenderer should reasonably believe could adversely affect

its ability to meet contract requirements pursuant to this RFP or is likely to have a

material adverse effect on the Tenderer ‘s financial condition. If such exists, list

each separately, explain the relevant details, and attach the opinion of counsel

addressing whether and to what extent it would impair the Tenderer’s

performance in a contract pursuant to this RFP.

15

B. 9. Provide a brief, descriptive statement detailing evidence of the Respondent’s

ability to deliver the goods or services sought under this RFP (e.g., prior

experience, training, certifications, resources, program and quality management

systems).

B. 10. Provide a personnel roster listing the names of key people who the Tenderer will

assign to meet the Tenderer’s requirements under this RFP. Follow the personnel

roster with a resume for each of the people listed. The resumes must detail the

individual’s title, education, current position with the Tenderer, and employment

history.

B. 11. Provide a statement of whether the Tenderer intends to use subcontractors to meet

the Tenderer ’s requirements of any contract awarded pursuant to this RFP, and if

so, detail:

a) the names of the subcontractors along with the contact person, mailing

address, telephone number, and e-mail address for each;

b) a description of the scope and portions of the goods each subcontractor

involved in the delivery of goods or performance of the services each

subcontractor will perform; and

c) a statement specifying that each proposed subcontractor has expressly

assented to being proposed as a subcontractor in the Respondent’s

response to this RFP.

B. 12. Provide a statement and any relevant details addressing whether the Tenderer is

any of the following:

a) is presently debarred, suspended, proposed for debarment, or voluntarily

excluded from covered transactions by any government or agency;

b) has within the past three (3) years, been convicted of, or had a civil

judgment rendered against the contracting party from commission of

fraud, or a criminal offence in connection with obtaining, attempting to

obtain, or performing a public (state, or local) transaction or grant under a

public transaction; violation of antitrust statutes or commission of

embezzlement, theft, forgery, bribery, falsification, or destruction of

records, making false statements, or receiving stolen property;

c) is presently indicted or otherwise criminally or civilly charged by a

government entity (federal, state, or local) with commission of any of the

offenses detailed above; and

d) has within a three (3) year period preceding the contract had one or more

public transactions (federal, state, or local) terminated for cause or default.

16

PART 2.C: TECHNICAL QUALIFICATIONS, EXPERIENCE & APPROACH.

The Vendor must address all items (below) and provide, in sequence, the information and

documentation as required (referenced with the associated item references). The

The evaluators will independently evaluate and score the response to each item. Each

evaluator will use the following whole number, raw point scale for scoring each item:

0 = little value 1 = poor 2 = fair 3 = satisfactory 4 = good 5 = excellent

Responding to the List of Requirements

Vendor must respond to each requirement contained within this tender document using the

following criteria. Vendor’s responses must be in the same order in which the questions

appear and must use the same numbering scheme as outlined below:

FP Fully Provided (Out-of-the-box), Solution currently includes this capability in its current general software release.

TP Third Party Software Required Third party solutions is required to deliver this capability

M Modification to existing software Minimal modification is required to provide the requirement

C Custom Development Required Custom development required for the requirement

NA Not Available Functionality is not available (Out of the box)

O Other Other

For any specifications to which the Vendor answers other than FP (Fully Provided),

Bidder must describe:

• Whether the CBK will incur any additional cost for the feature, function, product,

or service once it becomes available other than the cost of maintaining a valid

software maintenance agreement for the current modules/system proposed by the

Bidder as part of the initial installation (i.e. a new module, replacement or upgrade

to an existing module, new hardware required, etc.)

• If the feature, function product or service falls under the category as Not Available

(N), the Bidder may provide; (a) an explanation of how the specification might be

met using alternative methods within the system or (b) if it is available from a third

party partner. Either explanation must include availability dates and additional

costs, either direct or indirect.

17

Item Ref.

Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

C. 1. Portfolio Management 12

a) Does the system have capability to show positions and portfolio exposure by a classification of choice (i.e., country, asset class, currency, GICS sector, manager etc.)?

b) Does the system have a trade blotter functionality - record of each trade, status of each trade that transacted for a given period?

c) Can the system support at least four (4) levels of portfolio hierarchy i.e., Subportfolio, portfolio and tranche (portfolio groups)? Refer to the portfolio structure diagram ( page 6 )

d) Does the system have capability to: (i). Compare benchmark vs portfolio holdings?

(ii). Transfer of positions from one portfolio to another? (iii). Calculate unrealized/realized gains and losses. (iv). Mark to market of the securities and cash positions.

e) Does the system have capability to show amortization by position and aggregate by portfolio, or any other classification?

f) Does the system support portfolio-look-through (drilldown and aggregation)?

18

g) Does system have capability to show exposure by respective trade currencies and by the reporting currency?

C. 2. Performance Measurement and Attribution 10

a) Does the system have the capability to calculate performance for the asset classes specified in appendix A?

b) Do the performance calculations comply with the Global Investment Performance Standards (GIPS)?

c) Does the system have capability to show portfolio performance by a classification of choice (i.e., country, region, asset class, sub-asset class, credit ratings, currency, Global Industry Classification Standard (GICS) sector, manager

d) Is the performance calculation generated and stored during the daily end-of-day batch process, or generated in real-time?

e) Does the system have capability to calculate the following risk-adjusted performance measures: Sharpe ratio, Jensen Alpha, Treynor ratio, Beta (ex post), Information Ratio and Sortino Ratio?

f) Does the system support calculation of performance in both reporting (with FX) and trading currency?

19

g) Are the performance calculations created at the security level or account level and then rolled up to portfolio and/or group level?

h) Is the accounting data and performance data housed in one area or in separate areas? If it is housed in two different areas, how well do the two areas interface, and is there an automated reconciliation tool that the client can use to reconcile the two sets of data?

i) Does the system have capability to handle inter-portfolio transfers? Briefly describe the impact in relation to performance measurement?

j) If the client enters transactions from a prior accounting period, does it have an adverse impact on the performance?

k) Is your system capable of calculating performance on a custom / blended benchmark?

l) Please describe your system’s capability to calculate attribution daily, monthly, quarterly, yearly, and cumulatively between any two dates including any system limitations and/or issues.

20

m) Does the system support fixed-income portfolio performance attribution based on Campisi and Brinson models for the following security types listed below? (i). Futures (Bonds and Interest Rate) (ii). Vanilla Bonds (iii). Money Market Instruments (iv). Forwards (v). Swaps (vi). Callable corporate and agency bonds (vii). U.S. ABS and CMBS (viii). Agency MBS and agency CMO

n) Does system have capability to show attribution results graphically?

o) What procedures do you use to back test and/or audit the performance of the product you propose?

C. 3. Scenario Analysis & Stress Testing 6

a) Does the system have capability to perform what-if analysis to assess impact of the intended trade(s) on the risk, performance, compliance, etc. of the portfolio in absolute terms and relative to benchmarks / targets?

b) Does the system have capability to do stress testing (i.e., how the portfolio would look through a 2008 crisis or other historical crises, a 20% drop or interest rate spike of 200 basis points) along with any system limitations and/or issues.

21

c) Does the system have capability to setup custom scenarios and generate impact of these scenarios for both simulated and actual portfolio?

d) Does the system have capability to model portfolio impacts of one or more stress factors: interest rate and FX shifts, credit spread changes, inflation shocks, yield curve changes etc.

C. 4. Trading 10

a) Does the system have capability to interface with FIX providers / Trading Platforms (Bloomberg, Refinitiv) and counterparties (brokers)?

b) Does the system have capability to automatically receive and process new trades, amendment, and cancellation messages from FIX providers / trading platforms such as Bloomberg, Refinitiv(Reuters) etc.?

c) Does the system have facility for manual trade entry and upload from files for new trades?

d) Does the system have capability to show limit balances for portfolios, counterparties, securities, and other trading activities?

e) Does the system have capability to customize a trade workflow by asset class?

22

f) Does the system support trade enrichment - attachment to a trade of relevant information (bank accounts, SSIs, Counterparties, etc.) necessary to complete trade workflow?

g) Does the system support modification of trades before and after settlement, such as amend, replace or cancellation, for all trade types listed in appendix A, by authorized user?

h) Does the system provide for early termination of deposits (money market deposit placements)?

i) When an early termination of a money market deposit (via change of maturity date) is undertaken, Is the performance and accounting recalculated from trade date?

j) Does the system generate modification and cancellation messages (SWIFT or FIX) for all trade types (as provided in Appendix A) according to international requirements?

k) Does the system support cash transactions such as charges, payments, commissions, interest adjustments, cash injections/ withdrawals?

l) Does the system support rollover (principal only, partial principal, and interest only) of money market deposits?

m) Does the system support the following market conventions for day count (30/360, 30 / 365, actual / 360, actual / 365, and actual / actual)

23

n) Does the system support the following holiday conventions - Actual, following business day, modified following business day, Previous business day, modified previous business day, and Modified Rolling business day etc. and un-adjusted and adjusted?

C. 5. Cashflow Management 7

a) Does the system have an inbuilt a cashflow and/or liquidity management module?

b) Does the system have functionality to show investible cash by portfolio and bank account?

c) Does the system have capability to capture non-investment related cashflows (external cashflows) manually and via an automated interface from other internal systems (Core Banking System etc..), and update accounting?

d) Does the system have capability to upload a schedule of payments / cashflows from file, and produce forecasts by combing these payments and cashflows from investments to produce holistic cashflow forecasts / projections?

e) Does the system have the capability to capture / record special cashflows to be used only in generating reports with no impact on both accounting and portfolio performance?

f) Does the system have capability to forecast future cash positions based on transactions and events that impact positions?

24

g) Does the system have capability to produce cashflow forecasts based on user defined buckets (weekly, quarterly etc)?

h) Does the system have capability to record non-investment related cash flows? e.g., penalties, cash injections, fees, Government Payments?

C. 6. Benchmark Maintenance 7

a) Does the system have capability to define benchmarks at the lowest level of the portfolio hierarchy (subportfolio) and then aggregate up to the top-level (tranche) for single or multiple indices?

b) Does the system support the upload of index compositions and returns from file or directly import from Bloomberg or other platforms?

c) Does the system allow for multiple portfolios to be benchmarked to the same index?

d) Does the system have the facility to change the assigned benchmark for a particular portfolio without impacting the historical performance of the portfolio?

e) Does the system support the definition and maintenance of custom (modified composition of existing benchmark) and blended / composite (benchmark with multiple asset classes) benchmarks?

25

f) Does the system support Benchmark scaling when there is capital injection/withdrawal?

g) Can benchmarks be rebalanced to fixed weights or based on market value?

h) Does the system have capability combine internal and external manager investment positions for risk, compliance, accounting, and performance reporting purposes?

C. 7. Pricing and Valuation 7

a) Does the system have capability to maintain a pricing hierarchy (i.e., levels, sources, validation, etc. )

b) Does the system have capability to download market data (FX rates, security prices, yield curves etc.) from pricing sources (e.g. Bloomberg, Reuters (Refinitiv), index providers, custodian)?

c) Does the system have capability to set security price change tolerance limits and have drill-down capabilities to show source of the variations?

d) Does the system have consistent pricing between the accounting and performance measurement data?

e) Does the system provide facility for user to specify what prices to be used in valuation? i.e. closing, mid, opening prices etc

26

f) Does the system have the capability to value all instruments in Appendix A

g) Does the system have the ability to:

(i). Flag stale pricing, zero pricing, and price movements based on a tolerance level set by the client?

(ii). Price a security from yield curve data?

C. 8. Compliance Monitoring 7

a) Does the system have an inbuilt compliance monitoring tool / engine?

b) Are the compliance rules input by the user or by the vendor? If input by the vendor, how are the rules updated when investment policy specifications changes?

c) Does the system have capability to define compliance rules based on specific attributes of the security master (i.e. security type, sector, country)?

d) Does the system have capability to set limits at asset type, issuer, region, country of risk, counterparty, portfolio, tranche (portfolio group) etc in nominal value or percentage of portfolio?

27

e) Does the system possess capability to set up and trigger early warnings to assigned users for potential compliance breaches and to assign severity levels to those warnings?

f) Can rules be tested before being applied to a portfolio or portfolio groups?

g) When a rule is tested, does the system display all of the exceptions for the tested rule based on the most recent data available in the system?

h) Can compliance rules be run on a single portfolio or portfolio groups?

i) Does the system have capability to define effective from/start and effective to/end dates for all compliance rules?

j) Does the system have capability to store a record of all compliance violations and compliance overrides for audit purposes?

k) Describe the system’s rule approval workflow process. When a new rule is created or an existing rule is modified, does the system notify users of errors (if any) in the newly created/updated rule?

C. 9. Accounting 12

a) Does the system have inbuilt accounting module that has capacity to support setting up and maintaining of chart of accounts, transaction codes and products?

28

b) Does the system have capability to generate accounting entries all trade lifecycle events (trade, settlement, coupon accrual and payment, interest accrual, valuation, and maturity etc.) for assets types defined in Appendix A

c) Does the system support mark to market for all positions (cash and securities) for revaluation purposes

d) Does the system support manual posting, adjustments, and reversals?

e) Does the system support the following accounting standard or conventions: (i). effective and straight-line interest rate method of

amortizations? (ii). trade and settlement date accounting

(iii). support flexible settlement dates (T+0,T+2, T+5, etc.) (iv). support FIFO, LIFO and AVCO methods of valuing

securities? (v). accrual conventions - Last not first (LNF) and first not

last (FNL)?

f) Does the system support IFRS 9

g) Does the system have capability to capture multi-currency transactions and to translate to local currency using daily FX rates as per IAS 21?

h) Does the system support inter-portfolio cash transfer (funding)?

29

i) Does the system have the capability of supporting backdated accounting adjustments and related reports?

j) Does the system have capability to set the number of days (or period) for when the last accounting period remains open after financial year-end for posting adjustments?

k) Does your system maintain audit trails of all changes to the chart of accounts, reporting templates, amortization methods, day count conversion, accounting dates, pricing methods, and any other administrative changes that would affect the calculation or reporting of investment transactions?

l) Are there any manual processes within your accounting system?

m) Does your system have the ability to view positions At cost, with unrealized gain/ loss, market value, accrued income and NAV?

n) Does the system have capability to accept aggregate accounting entries (NAV) from external fund managers and/or global custodian for accounting purposes?

o) Does your system have the capability to generate month-end journal entries as well as other user-defined reporting periods?

p) Does the system have capability to interface with General Ledger (Oracle GL)?

C. 10. Settlement 6

30

a) Does the system support generation and processing of standard SWIFT messages outlined in Appendix B

b) Does the system have capability to match outgoing with incoming trade confirmation messages?

c) Does the system have capability to generate exception reports showing which fields in both outgoing and incoming confirmation messages are not matching?

d) If automatic matching fails, does the system provide for manual matching such as attaching email confirmation to a trade?

e) Does the system have capability of showing status of trades – settled trades and unsettled trades?

f) Does the system have a facility for setup and maintenance of Standing Settlement Instructions (SSI) without any limitations?

g) Does the system have a Post-Trade Settlement blotter to view and monitor trades in settlement and identify settlement fails

C. 11. Reconciliation 6

a) Does your system support automatic matching of transactions between the Sub ledger and Nostro accounts?

b) If (a) above fails, does your system support manual matching of transactions for reconciliation purposes.

31

c) Does the reconciliation module allow for creation and maintenance of custom reconciliation rules?

d) Does the system have capability to reconcile custodian positions holding (MT 535) to the internal positions for securities and cash balances?

e) Does the system retain historical records for reconciliation purposes?

f) Does your system provide a three-way reconciliation function between accounting, custody, and master record keeper?

C. 12. Reporting 10

a) Does the system have capability to compute and run

reports for any user-defined reporting period for all types of reporting

b) Does the system have capability to drill-down to position

level for all types of reporting

c) Does the system produce dynamic customizable

reporting? If so, is it easy for an end-user to create a custom report or, does an IT Developer have to create the reporting?

d) Does the system allow the end-user the ability to export

files in formats that can be uploaded to other systems?

32

e) Does the system provide multiple reporting formats such

as: xls, pdf, csv, txt, and mobile formats

f) Please provide evidence that report delivery is flexible

and deliverable through multiple channels (i.e., e-mail, print, file drop, and on-schedule’s). Please describe any limitations with the reporting.

g) Does the system provide for report-writer tool with user-

friendly capabilities of parameterizing generating reports.

Total Score 100

Total Raw Weighted Score: (sum of Raw Weighted Scores above)

𝑻𝒐𝒕𝒂𝒍 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆

𝑴𝒂𝒙𝒊𝒎𝒖𝒎 𝑷𝒐𝒔𝒔𝒊𝒃𝒍𝒆 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆 𝑿 𝟔𝟎 = 𝑺𝒄𝒐𝒓𝒆

Section B: Information Technology Requirements

PART 1 – STATEMENT OF WORK

Introduction

The section contains the technology requirements for the Portfolio Management and Trade Processing System (PMTP) which will be run by the Central Bank of Kenya (CBK). The CBK wishes to ensure that the PMTP system provides a leading edge to the Central Bank. The main purpose of this document is to provide a clear understanding of the meaning and scope of the information technology (IT) requirements. The IT requirements encompass all basic functionalities of a standard PMTP, with mapping to the existing IT environment of the CBK.

Project Scope

The scope of the project is for the supply and implementation, of system and their related linkages, and proposals are invited from qualified companies for:

a) Supply, installation and configuration of PMTP application software package

on the existing environment in Central Bank of Kenya;

b) Integration/linkage of the PMTP with other systems as specified in the

Appendix B

c) The complete range of required services including at least the following:

(i). Project management;

(ii). Business-level advice and consultancy to CBK concerning the

establishment and operation of the system;

(iii). Customizations/parameterization of software package(s);

(iv). Installation of all software items;

(v). Implementation of all required interfaces;

(vi). Acceptance testing;

(vii). Training;

(viii). Documentation;

(ix). Support and Helpdesk;

(x). Migration of Data

(xi). Support during Going-Live

(xii). Maintenance and on-going support.

General Technical Requirements

a) Language Support: The system must provide support for English.

b) Specifically, all display technologies and software must support the ISO 8859-15,

ISO 8859-6 and Windows-1256 (if appropriate) character sets

34

Specific Information Technology Requirements

1 General Requirements

As applicable, the system should: a) The system should support three (3) site deployment (primary, backup and Data

recovery site) for high availability.

b) Have a high level of usability with a common “look and feel” achieved through

a standard graphical user interface (GUI);

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

d) Provide full audit trails for all activities within the system, including system

accesses and messages sent and received.

e) Have high levels of trustworthiness with particular emphasis on data integrity

and security, particularly preventing unauthorized access and assuring 100%

data accuracy; support for multifactor authentication is preferred.

f) Possess high levels of service availability which will be assured through

demonstration, rigorous testing and a robust Service Level Agreement.

g) The system should be designed in 3-tier application architecture at minimum

(Database, Business layer and presentation layer)

h) The system should be designed in a modular structure, the bidder is required to

provide a list of available modules of the system to CBK, with explanation of

recommended modules, and to other modules that are not part of the proposal.

Integrity

The system should provide:

a) Financial integrity checks that ensure that all transactions are processed and are

reconcilable at the end of each business day.

b) Message processing integrity checks to ensure that the total nominal value of all

instruments in all recorded portfolios is matched and reconciles with the control

totals for all issues registered.

c) 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 to prove system integrity and

complete system-wide reconciliation.

d) Security of messages with a high level of message authentication, data integrity,

and confidentiality.

e) Guarantee of no data loss either in transmission or after a failure; system should

be able to recover gracefully in the event of unplanned/unforeseen outages

35

Security, Authentication, Access, and Audit

Security

a) Exchange of data between PMTP and other systems inside CBK should be hashed

and / or encrypted.

b) The System must be based on accepted, widely used and recognized technical and

security solutions.

c) The System’s databases must be protected against undesired changes.

d) Users and Administrators must not be able to change the transactions history in

the System

Operating System (OS) and Platform Configurations

a) All system components (OS, Database, applications, network devices) will be

hardened according to specific Central Bank of Kenya cyber security guidelines

as well as specifications provided by the product manufacturer.

b) All applications placed in the DMZ (or other equivalent secure zone) must be

configured to run in a restricted server environment (such as chroot for UNIX)

c) All software (OS, application, database) packages and modules not required for

this system must be deactivated and removed (where possible) from the system

d) The vendor must provide a list of all the minimum required software (OS,

application, databases) and service ports required for the system to function.

e) The most recent version of the software in use, with the latest security patches /

service packs must be applied across all components.

f) The supplier/vendor must have a mechanism to inform Central bank of Kenya

regularly about relevant security updates and patches that may affect smooth and

secure operations of the system.

System Security Architecture

1.1.1 System Design & Documentation

Detailed security design documentation of the system must be provided by vendor

covering, as a minimum, descriptions of:

a) system architecture

b) interfaces

c) all installed and uninstalled/disabled components or application modules

d) supplier related Operations & Maintenance Procedures (where relevant)

e) remote maintenance and support procedures and mechanisms, if any

f) all implemented and available authentication and authorization mechanisms

g) exhaustive list of all security updates and modification

h) controls against manipulation, misuse or disclosure of personal or sensitive data

36

i) password parameters and how they can be configured

j) user role matrix and its configuration

1.1.2 System Security

Detailed documentation must be provided with regard to security mechanisms to

protect connections to public networks.

Authentication

a) CBK expects multi-factor authentication to be used for user management. It is

assumed that this will be based on either use of hardware or software tokens (or

equivalent), each containing a unique digital certificate identifying its owner.

Bidder should provide full details of the proposed approach, including the

hardware and software required and the way in which the PMTP implements

multi-factor authentication.

b) The System must only allow access to identified, authenticated, and authorized

users.

c) Authentication data must not be shown, stored, transported, or recorded in clear

text.

d) The strength of passwords used with operation and maintenance accounts

system must be enforced as per leading international standards. This system

capability must also be configurable to meet changing password policy control

requirements (for example, but not limited to, a change in the password length &

complexity policy requirement).

e) The system must provide a configurable mechanism:

• to detect and block simple passwords (e.g. 123456, abcdef, identical username

& password, etc.)

• check that the password does not contain more than two successive identical

characters

• to allow only the administrator to reset the passwords

• Not to allow hard-coded passwords (i.e. no service/application user

passwords displayed in source code)

f) The system must provide a password change confirmation procedure

g) The System must be able to limit (and report on) the number of unsuccessful

logon attempts through a “lockout” mechanism

h) The system must provide the capability to detect (and report on) multiple logons

from the same user ID and restrict users to one session at a time

i) The system must provide the capability to lock/deactivate/suspend or delete

certain accounts/user IDs either manually or automatically

37

j) The system must provide the capability to print a list of all possible access

privileges, a specific user's access privileges and comparison tables between

different user IDs

User Access

a) System access, named for this document as an Access Control System (ACS),

must be based on a documented security and system access model and

architecture, including a policy for interacting with different security and access

models at operating system and database level.

b) The ACS must be based on the “least privilege principle”.

c) The ACS must have a role-based access model.

d) The ACS must be able to set privileges and access rights to objects and subjects.

e) The ACS must categorize users into groups and define access levels on both user

level and group level.

f) CBK must be able to use the ACS in a corresponding manner to

• register groups for access rights for different categories of users of the System

• register, cancel and update access rights

g) For each registration in the ACS, it must be possible to require that the duality

principle is used when registering data (the “four eyes" or “six eyes” principle) if

this is prescribed in the access rights profiles for the users.

h) This must be done in such a way that verification of the registration will be

required by another user or that full registration will require two different users.

i) The ACS must be able to manage the following types of privileges:

• Read-only rights

• Read/write rights

• Administrator rights (the right to assign access rights)

• Master rights (complete access rights)

• No privileges permitted

j) The ACS must enforce the generation and use of strong two factor (incl. support

for biometric) authentication/high quality passwords and PINs

k) All remote operation and maintenance tasks must only be performed via

encrypted protocols (e.g. ssh, ssl) and unencrypted accesses deactivated

l) There should be a possibility of the ACS to interface to Directory Services e.g.

Active Directory for user authentication

Audit Trail

a) A log must be kept of all logon attempts on all Systems delivered by the bidder.

b) The System must maintain detailed audit trails to enable investigation of:

• attempted frauds

• disputed transactions

• suspicions of errors

38

• suspicions of fraud

• other abuses or attempted abuses of the System

• communication transmission attempts, whether successful or not

c) The System must maintain:

• a log of all errors occurring in the system including preparation of a message

• access control over the audit records

d) The system should provide audit trails on all software layers (OS, database,

application) allowing a tight control of accessed functions and information

e) The security log files & audit trail must be protected against manual modification

even by the super user and methods applied documented.

f) The system must have a configurable automated process implemented to send log

files or defined logged events to a security log server.

g) The system must be able to interface with other third-party Enterprise Log

Management System, e.g. SIEM for centralized logging

Operational requirements

General Requirements

As applicable, the system should:

a) Allow for easy customization through on-screen parameters to accommodate

new, changed or modified rules that will govern various functions e.g. create a

new message type, create a new instrument type, etc.;

b) Allow authorized personnel to change the business process flow through the

setting of parameters in process control tables.

c) Provide online access to and reporting of historical records – covering a period

of at least seven (7) years plus the current year – without compromising response

times;

d) Provide online, context sensitive help for all user and operator functions.

e) Enable automation of daily processing including initiating links to directly

interfaced systems with appropriate security procedures and exception and

summary control reports;

f) Be operationally resilient, with high levels of local recovery supported by an

appropriately configured High-availability and Disaster Recovery (DR)

installation and a smooth cut-over between the primary, secondary and DR sites,

and back again to the primary site when service is recovered.

System availability

a) The System must be accessible at least 20 hours a day, every day of the

month except for about four days for maintenance (planned shutdown,

non-working days for maintenance).

39

b) The System must have a Service Availability of 99.95% during the hours

when the System is open.

System capacity

a) Despite the current numbers shown in the table 1, system capacity is expected to

be as mentioned in the text after the table.

Table 1: PMTP TRANSACTIONS AND VOLUMES.

Transaction Type Number Per month

1 Bond Trades 600

2 FX Trades 300

3 Payments (includes external cashflows) 1,000

4 Money Market Placements 300

5 SWIFT Messages 10,000

b) The System must have the capacity at least:

(i). to process and settle at least 3,000 transactions a day, and at the same time

allow use of the System’s other functions.

(ii). to have 50 users logged on and making enquiries through the System

concurrently.

(iii). be scalable to handle a growth rate of 50% per annum with scalability for 8

years.

c) Bidder must provide examples of capacities of the provided Systems in other

live environments, with scales higher than specified here, indicating the

hardware size.

Response Times

The actual response time is measured from the point where the transaction is received

by the System. The following list of requirements must be met:

a) For 95% of transactions and simple queries in real time, the response time must not

exceed 1 second during the peak hour.

b) For 95% of complex queries in real time, the response time must not exceed 2

seconds during the peak hour.

c) The maximum response time for system log-in is 7 seconds. (Response means full

login and display of next screen)

d) The maximum response time for message arrival acknowledgement is 5 seconds.

40

Parameter Management

a) It must be possible to make system parameters changes, like Date changes, while

a System is open and these changes should have immediate effect.

b) Please list what system parameters can be changed or updated while a system is

open. And what changes take effect on next business day.

Infrastructure requirements

Environments

The PMTP will run on CBK equipment. As a mandatory requirement, the bidder will be required to implement the system in three sites, a primary processing site (data centre) at CBK’s head office, at high availability site that is not far from head office, and in a business recovery centre (DRC):

a) The equipment at the primary site is designed to have comprehensive resilience

features to ensure that, in normal operation, a failure of any single element such as

a server or blade (for example) will have no effect on the operation of the system.

b) Under normal operation the primary site will host the live version of the system.

c) The live system will be installed on servers at the three (3) sites. Responses must

contain the Bidders response as to how all sites will be installed and coupled to

enable the highest level of availability.

d) Responses must 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.

e) A reference environment must be available at all times to carry copy of the live

environment to be refreshed daily for troubleshooting. Before going Live, this

environment will be considered a ‘pre-production’ version of the system that must

be installed at the primary site for use in parallel running in the period between

user acceptance and load testing and cut-over to live operation.

f) A training environment must be available at all times to allow for training of CBK

staff and new users.

g) A user acceptance testing environment must be available at all times to allow for

testing of system features, integration, performance, planned system changes, and

participant interface testing.

h) Bidders must describe how they will accomplish the following main tasks:

- Management of changes involving operating systems, system software,

middleware, databases, and application software, covering all participants

where applicable;

- Operation of the above system components;

- Testing of parameter-level changes made by the system operator.

41

- Testing of system performance.

i) Bidder must give full details of all hardware, system software, middleware and

any other products and equipment necessary to run the system.

Infrastructure – Hardware & Software

a) The following are current CBK hardware and software configurations:

• The CBK installed server hardware is IBM POWER9 Server

• The CBK installed server operating system is AIX 8.1

• The CBK middleware used to communicate between existing systems /

applications is IBM WebSphere MQ (JMS).

• Application Server IBM WebSphere Application Server (WAS)

• The CBK installed database servers is Oracle 12c and above.

b) Preferably, the system should be able to operate within the above configuration of

hardware, software, and middleware.

Data Retention Requirements

Backing up data standard is:

a) Full backups will be performed over weekends

b) Incremental (only changes) backups must be performed during each business

day

c) 25 business day cycles of the daily backups must be kept (each cycle to keep the

pre and post backup of the database)

d) The System must not compromise the integrity or security of confidential stored

information in any way.

e) The Bidder must provide a definition of the back-up plan according to the

following four types of data:

o System (Operating System and Applications) data

o User Data (the data specific to each part of the system that is susceptible to

being modified frequently)

o Confidential Information (relating to the architecture of the network

belonging to Central Bank of Kenya or its stakeholders)

o Log (the set of traces on what is made on/from each part of the system).

f) All backup actions must be traceable

g) Data must be retained in the System for at least 15 years. 10 years available online

and offline as backups for 15 years

42

h) When media used by the system is to be disposed of or reused, necessary

measures must be taken to prevent any subsequent retrieval of personal data and

other information stored.

High availability requirements

High Availability

Please indicate how these mandatory requirements will be met:

a) All production Systems are deployed as highly available and in redundant pairs,

in high availability site, as well as in a disaster recovery environment.

b) Replication on three active sites with real-time synchronization of application

and database. Replication of primary, secondary and disaster recovery is

mandatory for any system installed in the bank

c) Please indicate if your System can be installed and operate with this

configuration

d) There must be no loss of trades/orders/data when failing over to a highly

available environment.

e) In the event of a system failure at the Live Site, the System must re-start from the

last valid transaction without duplication of any transactions or loss of any

transactions.

f) The System components must support Storage Area Networks (SAN), or similar

and not require local storage with locally attached hard drive(s).

g) High availability must be ensured on all System components

h) The System must ensure “no single loss” of a message due to failure of any

component of the System.

Disaster recovery

Please indicate how these mandatory requirements will be met:

a) The Bidder must provide a documented Business Continuity Plan for the

service.

b) The Bidder must provide a detailed scenario of fail over between Systems in

the production site; and between production, high availability, and DRC sites.

c) The System must be able to be run at one site with production and backup

servers and with automatic fail-over within the site, while having a high

availability site with failover to this other site.

d) The Bidder must define a down time for the fail over to the backup System

within the production site of 0 to 10 minutes.

43

e) The Bidder must define a max time required to fail back the service from the

high availability site to the production site of 30 mins or less (during time

assigned for maintenance)

f) Hot standby or disaster recovery site can be up to 300 KM far from the active

site.

System Interfaces

All interfaces should meet the bank’s security standards, the System will have the

following interfaces. More details on interfaces provided in Appendix C.

Direct Access to the system

The System’s users must be able to enter data to the system by the following ways:

• opening a pre-defined form for data entry – controlled data entry

• uploading a data file in a pre-defined format

Any interchange of data between the PMTP and other systems, must be performed

through the following methods:

• A SWIFT message format: The system must support SWIFT standard MTnnn

formats and other which correspond to the ISO20022

• An XML message in ISO20022 format

• A file in FIX (Financial Information Exchange), XSL, or flat file (character

delimited format).

• As an option, the system should provide for open standards architecture by

allowing exchange through web service, API, JMS, open for integration

• Bidder should provide information on all message standards that their systems

follow, particularly their forward development plans in this area.

• Bidder should work to fulfill integration with existing trading and messaging

platforms: SWIFT, Bloomberg, Refinitiv (Reuters)

Any report extracted from the system must be produced in, at least, the following

formats:

• XSL, XML, or comma delimited format

• PDF format

• XLS or XLXS

Core Banking System (Currently Temenos T24)

It is expected that there will be interface between PMTP and Core Banking System

(CBS), as government forex payments will originate from the CBS where the

government local currency accounts are domiciled.

44

Investment Risk Management System (IRMS)

It is expected that there will be interface between PMTP and the Investment Risk

Management System (IRMS). The IRMS will download positions, cash balances and

market data from the PMTP.

SWIFT:

Settlement / Custody Messages exchanged between PMTP and Counterparties and

Global Custodian shall be in the form of SWIFT messages. While communicating to

SWIFT, the system will observe all security protocols applied by SWIFT including

authentication and encryption.

CBK has a direct connection to SWIFT. Connection to SWIFT is via the IBM

WebSphere MQ middleware.

Bloomberg

The Bloomberg platform is used for execution of Fixed Income, FX and Money Market

(deposit placements) transactions. Market data – Security prices, CDS, security

definitions, FX rates – is also downloaded from Bloomberg. The new PMTP system

should therefore have capability to interface to Bloomberg for the following:

a) Fixed Income Trades,

b) FX Trades

c) Money Market Trades (Deposit Placements

d) Security definitions

e) Security Prices

Refinitiv (formerly Reuters)

The Refinitiv platform is used for execution of FX and Money Market (deposit

placements) transactions. Foreign Exchange rate data is also extracted from the

platform. The new PMTP system should therefore have capability to interface to

Refinitiv for FX and Money Market transactions, and market data.

Global Custodian

The settlement and custody transactions with the Global Custodian will be vide the

SWIFT Message platform.

The Global Custodian sends periodic performance / risk, valuation, and Balance Sheet

& P&L for externally managed funds. The Balance Sheet and P&L of externally

managed funds is uploaded to the General Ledger at the end of the month.

Oracle GL

The sub-ledger in the PMTP will be integrated to the main General Ledger in Oracle

GL system. This will be through defined flat file upload to the Oracle GL

45

Index Providers – Intercontinental Exchange

Currently, at the end of each day, the index (G1QA) composition file is received via

email from Intercontinental Exchange (ICE). The security prices are extracted from

this file and uploaded to the system. At the end of the month, the composition is

uploaded to the system for portfolio rebalancing and simulation.

Report Generation

In order to generate customized reports, the system must either

• provide a report generation module, where system admin, will be able to develop

customized reports bringing data from multiple areas in the system and putting

them together, including customizing page format, developing SQL queries,

formatting the output results in a customized way, and inserting static

information, graphs and other tools. This option is a preferred option, Or

• Allowing an external report generation system from accessing the PMTP system

directly, including access to read data from the system. This will imply the bidder

will provide the PMTP data structure in the form of tables or views.

Data Warehouse and Business Intelligence Platform (DWH):

a) At the end of the business day, a selective set of data (i.e. positions, account balances)

will be transferred to the CBK data warehouse.

b) The process of generating daily reports to be sent to DWH must be automatic, in a

pre-defined file format.

Microsoft Active Directory

The PMTP systems should have capability to interface to Microsoft Active Directory

for user creation and authentication. Role assignment should be provided for in PMTP

46

Implementation and Support This part specifies the service requirements that must be satisfied to ensure successful

implementation of the entire system.

1 Business Level Consulting

CBK expects that the Bidder must provide a high level of business consulting and

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

its international experience in financial market infrastructure implementation.

Bidders are required to provide documentation including system rules, certificate

policy, e-token management procedures, user acceptance tests scenario, operating

procedures and charging policies.

Project Plan and Implementation Schedule

Project Plan

Bidder must provide Preliminary Project Plans showing how they intend to carry out

all aspects of the project. Project plans must address at least the following subjects:

a) Project organization and management plan (covering both the Bidder’s team and

expectations of the Purchaser’s involvement);

b) The Bidder’s proposed project team.

c) Phases of the project execution showing sequencing, activities and deliverables

for each phase;

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

e) a project plan in Gantt chart format;

f) System requirements analysis, design, development and delivery;

g) A detailed installation plan – site preparation, hardware installation and testing;

h) System integration plan;

i) Training plan;

j) Change management plan;

k) Documentation plan;

l) Change management plan;

m) Acceptance testing plan;

n) Warranty and post-warranty service plan;

o) Data Migration Plan

47

Implementation Schedule

CBK expects the project implementation to comprise of at least the activities listed

below. The project will follow Agile Methodology in its implementation.

Identify the Project Scope

a) Business analysis (scoping study) to establish and document the detailed

functional, technical and integration requirements of the system.

b) Customization and integration of the application software to meet the detailed

requirements documented as described in both Business and IT Requirements;

c) Installation, configuration, testing and commissioning of the technical

components (hardware and software) of the system, including integration with

the existing ICT environment as necessary;

d) Installation and testing of the application software, and third party software in all

in four (4) environments, including Development (DEV), Test (TST), Production

(PRD) and Disaster Recovery (DR):

e) Implementation of all required system interfaces (refer to Appendix A);

f) Training – includes business and technical training.;

g) User Acceptance Testing (UAT);

h) Pilot operation (parallel running).

i) Migration of data from old environments to PMTP

j) Go Live.

k) Post-Implementation Maintenance and Support

Bidder should include any additional activities that they feel are required.

Bidder’s Project Team

a) The Bidder must describe the competences, roles and responsibilities of their

proposed team members, including resume for all proposed team members.

b) To ensure maximum knowledge transfer, the Bidder’s project team must be

structured to work with counterparts within CBK, and Bidder must therefore

show their expectations of CBK’s team structure and management, together

with roles and responsibilities.

c) The Bidder’s assigned project staff that should not change during the project

and bidder should describe how they will ensure that the resources working

on the project will continue to be available throughout the project. If there

should be any changes in resources, bidders should describe the process for

48

identifying contingency resources. Replacement of the key personnel will

require prior written consent from CBK.

d) 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 Kenya, offsite and offshore location(s).

The project team must include key specialists and alternates in at least the following areas: a. Project Management;

b. Business Experts (PMTP);

c. Systems Integration

d. Change Management

e. Training

f. Application testing

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.

Project Management

The following section give CBK’s expectations as regards overall project

management. Bidder are invited to comment on them and to propose any variations

or modifications as they see fit.

Steering Committee

a) CBK will appoint an internal steering committee which will have oversight of

the project and will have final responsibility for all aspects. The steering

committee will liaise as required with the responsible implementation teams or

staffs.

b) CBK’s project manager will act as secretary to the steering committee.

c) The steering 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.

d) Both project managers must attend steering committee meetings.

Project Managers

CBK and the Bidder must 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 must

work closely together at all stages of the contract.

49

Progress Monitoring

Throughout the project execution, the Bidder’s project manager must submit to

CBK’s project manager a weekly progress report covering:

a) results accomplished during the prior period;

b) cumulative deviations to date from schedule of progress milestones as

specified in the

c) Agreed and Finalized Project Plan;

d) corrective actions to be taken to return to planned schedule of progress

and/or proposed revisions to planned schedule;

e) other issues and outstanding problems and proposed actions to be taken to

resolve them;

f) resources that the Bidder expects to be provided by the Purchaser and/or

actions to be taken by the Purchaser in the next reporting period;

g) other issues or potential problems the Bidder foresees that could have an

impact on project progress and/or effectiveness;

h) (as applicable) training participant test results;

i) log of service calls and problem resolutions during the preceding month.

The two project managers must 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 Bidder’s monthly progress reports), agree actions to

be taken to resolve problems, and update the project plan as necessary.

The project managers must invite other project team members to take part in the

progress meetings as necessary.

Written minutes of all meetings and agreed actions must be taken by CBK’s project

manager and circulated to all affected parties as applicable, including the steering

committee.

User Group Meetings

The membership of this Working Group comprises representatives of all involved

CBK departments. CBK’s project manager will convene regular meetings of the

Working Group, at which the two project managers will report on progress and

consult on any project aspects requiring user involvement.

CBK Consultancy Firm

CBK may appoint a specialized consultancy firm to support CBK in different aspects

of the PMTP implementation, including business aspects, legal aspects, and others.

50

CBK consultancy firm will act as a CBK staff, and It is expected that the bidder will

provide full support to the operation of the firm.

Testing and Acceptance

The full system must not be finally accepted (i.e. achieve Operational Acceptance)

until all functionality has been fully tested and shown to be working correctly at all

locations, including all users, and with full integration of all systems defined in the

SOW.

General

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

a. Ease of installation and system start up;

b. Operation of the system platform;

c. Operation and management of the systems by both business and technical teams;

d. Reliable and efficient automated communications interfaces;

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

f. Ability to handle expected and peak workloads for a minimum period of five years’ after

g. Operational Acceptance;

h. Clear and effective documentation and other support materials;

i. Effective education and training;

j. Effective organizational arrangements for full scale operation;

k. Effective support organization;

l. Effective problem reporting, tracking and resolution procedures.

Acceptance Testing

a) Successful completion of the contract must be attained through a series of formal

acceptance tests performed on all aspects of both systems. Payment will be

directly related to successful completion of agreed milestones.

b) The acceptance tests will demonstrate that the Bidder has met each requirement

specified and agreed in the contract and has delivered all required reports and

documentation and an effective operational system.

c) Each step of the acceptance tests must be fully documented and signed-off by CBK

to signify acceptance of each element.

Sequence of User Acceptance Tests (UAT)

a. Initial acceptance tests must be performed using the system installed at the

primary site at CBK. These tests will confirm general functioning of each element

of the entire system.

b. Functional acceptance tests must be conducted across the fully installed systems

in both the primary and DR processing sites. These will entail testing every

detailed aspect of system functionality, including a full range of error checking.

51

c. Operational acceptance tests must involve full load (stress) testing of the system

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

handle the maximum expected peak workload. They will include the full range of

failover procedures specified by the Bidder for handling failures at either site.

d. Interface acceptance tests must involve full testing of the system to confirm the

proper functioning of the major interfaces which include:

• the interface to SWIFT.

• the interface to BLOOMBERG.

• the interface to REFINITIV (REUTERS).

• Interface to T24

• Interface to GL

• Interface to RTGS

Acceptance Test Design and Execution

The Bidder must propose the contents of all acceptance tests for CBK’s approval and

planning, and modification as necessary. CBK will develop its own acceptance tests

as well, to represent its work flow and practices. All acceptance tests will be carried

out by CBK operations and technical staff, and will be monitored and supported by

the Bidder at each step. CBK will make management personnel and staff available to

the Bidder 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 CBK.

Evaluation of Acceptance Test Results

CBK’s project manager will be responsible for the final rating of all acceptance test

results. At the end of each test phase, CBK’s project manager will provide to the

Bidder either a formal letter of acceptance if the Bidder 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.

Fault Correction

The Bidder must be responsible for correcting all faults (i.e. instances where any

element of the systems does not perform in accordance with the signed-off

specification) found during acceptance testing in a timely manner so that the overall

project schedule is not affected.

Training and Knowledge Transfer

Knowledge Transfer

CBK considers training and knowledge transfer to be among the most important

factors for the success of the project. An important objective is therefore to ensure

effective transfer of PMTP and related technological knowledge. The bidder must

52

prepare targeted technical and business-based knowledge transfer to the relevant

teams. This is viewed as critical for all parties to become self-sufficient in the

operation and maintenance of the new services and related technologies. The Bidder

must describe in detail how they intend to achieve a high degree of knowledge

transfer.

Training

a) The Bidder must provide training plans showing, for each system element to be

supplied, and for the project overall, all proposed training programs, the

recommended number and (if applicable) prior knowledge of people to be

trained in each institution, the duration of each training module and the

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

programs will include:

(i). Functional Training - Class room sessions on all required modules for the

Project Core Team (business super users, business analysts)

(ii). Technical Training - Class room sessions on all technical aspects of the system

e.g. data organization, customization, interfacing with other standard

software like Bloomberg, Refinitiv (Reuters), SWIFT, legacy systems

installation, and maintenance aspects of the system.

(iii). End User Training (Functional & technical) - Class room sessions for End

Users. This should be given just before QA environment and User Acceptance

testing, so the team is ready for the Acceptance testing.

(iv). Operations Training – computer operations requirements, security operations,

backup, disaster recovery and business continuity operations

b) Qualified personnel who hold relevant certificates as applicable must carry out

all training. The Curriculum Vitae and copy/ies of certificate/s must be supplied

for each trainer proposed.

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

commencement of training. They should cover not only CBK but all involved

organizations as applicable to each component/module of the PMTP.

d) Any other relevant training that will enable optimal usage of the system

Documentation

Preliminary project plans must contain detailed specifications of the documentation,

which the bidder 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 CBK system.

CBK expects that the supplied documentation must include at least the following:

53

a) Product Literature, describing the different system components that address the

business and technical requirements of this procurement;

b) 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;

c) Technical Documentation that CBK 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. This must include:

i. Utility software functional specifications and descriptions;

ii. Application software functional specifications and descriptions;

iii. Documentation covering the testing environment;

iv. Instructions for backup, restore and selective restore;

v. Instructions for switch-over of processing to and from the Hi-Availability

and DRC sites;

vi. As-Built and Final Design documentation that includes the selected

options and configuration settings;

vii. Any other technical documentation that the CBK will need to use for the

safe and effective running of the processing environment.

d) Detailed Documentation of Operational Processes. This must include:

i. Standard batch scripts;

ii. Recommended scheduling of batch jobs (background and foreground);

iii. Details of all background and foreground tasks;

iv. Dependencies of all programs within each batch;

v. Dependencies between batches;

vi. Details of all standard reports;

vii. Internal integrity controls performed by the system;

viii. Relationships between programs and data;

ix. Relationship between application and operating system;

x. Relationship between application and database manager.

Migration of Data

Data migration must follow the following approach:

a) The Bidder must provide clear guidelines detailing data to be migrated from

legacy system. All necessary datasets required in PMTP from the legacy system

must be documented in detail.

b) A process to validate the migrated data must be put in place to audit the data. This

must include reconciliation reports to show statistics and checksums for the data

migrated vs the legacy system.

54

c) Just before the first day of going live, to migrate opening balances of all accounts,

positions, static data, custodians, plus history of transactions, allowing for printing

of account statements, calculating of taxes, and other functions depending on

historical data.

d) The migration process must be planned very well, and there must be an automated

batch that handles all data coming from T24 for migration, restructure it, and

inserts them in the PMTP database.

e) There will be need to have parallel (pilot) runs to ensure that the migrated data is

valid and system is reporting at par as the production system.

Go-Live, Warranty and Support Services

Go-Live Support

The Bidder must provide on-site support for the system during the Go-Live process

to ensure smooth and timely switch to the new system. The support should cover

both production and disaster recovery sites.

Warranty Period

The Bidder must provide operational support for the system on-site at the primary

and alternate processing sites for a period of three (3) months after Go-Live. During

this time, the Bidder’s support personnel must be available on an immediate on-call

basis during normal business hours at CBK’s head office.

Support and Maintenance Period

Bidder must provide support for the entire system at no charge for a period of 24

months after Go-Live. The Bidder 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 CBK and the Bidder

during implementation.

During this maintenance period, any new releases and upgrades of the system will

be installed at no additional charge. The Bidder and CBK will agree on the pricing

and period of maintenance after expiry of this initial maintenance period.

The Bidder 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 CBK and the Bidder during implementation.

Terms for out of hours support must also be agreed upon during this period. The

support services must include at least the following:

a) Software support, including:

i. Problem response, management and resolution as detailed below;

ii. Error correction (patches) for the application software.

55

iii. General advice and guidance for all software products including

application packages, system software, DBMS, middleware etc.

iv. The Bidder shall 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

minimize any impacts to the levels of service required by CBK, covering

knowledge of CBK’s business operations as well as expertise in the

application software.

v. Provision of all patches and corrective, new and updated

vi. versions of all supplied software products which become available,

including change management support for introducing them. Bidder

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.

On-going implementation of changes if required/requested by CBK. Bids must

include the Bidder’s proposed procedures for processing and implementing Change

Requests, including the costs per person/hour or person/day for all categories of

personnel who may be involved in the Change Request process. Such costs shall be

fixed for the duration of the Warranty Period

Service Level Agreement (SLA)

The bidder will provide a draft SLA agreement detailing the service hours, system

availability, and the business impact levels for CBK review.

Extreme Situations

Bidders are requested to suggest procedures that can invoked in the event of extreme

emergency situations, extreme event which affects both the main IT processing center

at CBK’s head office and alternative centers.

Problem Management

The Bidder’s support center must answer incoming telephone calls within one

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

All problems notified to the Bidder must have a priority assigned by CBK that will

define the severity and impact to CBK’s service levels with a resolution target and

escalation framework to make sure the effects of the problems are restrained or

minimized.

Priority levels will be as follows:

a) Priority 1: A system component has failed in such a way that one or more critical

elements of the system are unusable. The Bidder must provide appropriate

56

support within fifteen minutes and provide a work-around or fix within two

hours of receiving notification.

b) Priority 2: The service is severely impacted and performance is restricted. The

Bidder must provide appropriate support within two hours and provide a work-

around or fix within four hours of receiving notification.

c) Priority 3: The service is impacted and performance is reduced. The Bidder must

supply a work around or fix within 24 hours of receiving notification.

d) Priority 4: The service may be impacted and performance can be reduced. Priority

4 problems must be supported during the Bidder’s and CBK’s normal hours of

business.

Details of problems logged with the Bidder, whether during the project, the System Warranty Period or under an on-going Service Level Agreement, must be easy for CBK to follow up. Regular reporting must be a standard feature of the service, provided by the bidder on on-line basis, and must include:

a) The number of service-disrupting incidents over any selected period by source of

disruption and in total;

b) The number of non-services disrupting incidents reported over any selected

period;

c) The time taken to restore normal service after each recorded service disruption.

d) Bidder should also explain how CBK staff can monitor reported problems on a

regular basis.

Performance Expectations

CBK expects a very high level of reliability and availability of all its systems and the

system will be particularly crucial in this respect.

CBK’s expectations of overall system performance include:

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

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

c) CBK’s general availability expectation for this system is 99.95% (where

downtime is defined as total unavailability of the service). Bidder are requested

to give details of expected reliability and availability figures for the actual

configuration (hardware, software etc.) they are proposing.

57

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE

The Tenderer must respond to every stated request or requirement and indicate

that they confirm acceptance of and understand the CBK’s stated requirements.

The deferral of a response to a question or issue to the contract negotiation stage is

not acceptable. Any item not specifically addressed in the Vendor’s proposal will

be deemed as accepted by the Vendor.

Responding to the List of Requirements

Tenderer must respond to each requirement contained within this RFP using the

following criteria. Vendor’s responses must be in the same order in which the

questions appear and must use the same numbering scheme as outlined below:

FP Fully Provided (Out-of-the-box), Solution currently includes this capability in its current general software release.

TP Third Party Software Required Third party solutions is required to deliver this capability

M Modification to existing software Minimal modification is required to provide the requirement

C Custom Development Required Custom development required for the requirement

NA Not Available Functionality is not available (Out of the box)

O Other Other

For any specifications to which the Vendor answers other than FP (Fully Provided),

Bidder must describe:

• Whether the CBK will incur any additional cost for the feature, function, product,

or service once it becomes available other than the cost of maintaining a valid

software maintenance agreement for the current modules/system proposed by

the Bidder as part of the initial installation (i.e. a new module, replacement or

upgrade to an existing module, new hardware required, etc.)

• If the feature, function product or service falls under the category as Not

Available (N), the Bidder may provide; (a) an explanation of how the

specification might be met using alternative methods within the system or (b) if

it is available from a third party partner. Either explanation must include

availability dates and additional costs, either direct or indirect.

58

Item Ref. Information Technology Requirements, Project Management etc.

Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

C. 1. General Requirements 10

a) Can your product be maintained on a client’s own

server? What database system (i.e., SQL, Oracle,

etc.) does your system use?

b) Identify the most current version of the software.

Detail the percentage of live customers that are

utilizing the proposed version of the software.

Please provide a breakdown of customers (by

percentage) for each version of the software

currently in use.

c) Please describe any modules or add-ons that you

offer for your software.

d) Describe how often a client should upgrade the

software including what the trigger or decision

point is for upgrading/changing the system, and

if there is an associated cost.

e) How many environments are supported in the

basic offering for a client? Is a development

59

version of the system available to clients for

testing?

f) Are the error messages produced by your system

in plain English, and do they contain a specific

reason for the occurrence of error?

g) Does the system have capability to define

workflow processes and business rules, including

approval levels, and to modify workflow (e.g.,

assigning a proxy approving authority)?

h) Does the system have capability to send out

emails and SMS out to Users? Please give detail on

what service is used and how it is integrated for

On-premise solutions.

i) Does the system provide an API for extracting

data to the Enterprise Data Warehouse?

j) Does the system support addition of more

features or modules without affecting

performance of other functioning modules

k) Does the system provide for STP in trade

processing?

60

l) Does the system provide a dashboard style real

time monitoring of post trade activities?

m) Does the system provide alerts for all trade

transactions queuing for approval?

n) In the event of SWIFT failure, what alternative

confirmation methods are available from the

system? Does the system support resubmission of

same message with amendments?

o) Does the system have an aging report which

shows how long an outstanding item has

remained in the system? Can this be customised to

define the red CBK preferred line?

p) Describe the End of Day process.

C. 2. Integrity 3

a) Does the system have capability to encrypt or

digitally sign data flows and transactions? Explain

any limitations

b) Describe features of system that guarantee zero

data loss especially during recovery from

unplanned outage

61

c) What privacy methods used to ensure that

confidential Data and sensitive communications

are kept private?

d) If multiple databases are employed, what extra

procedures are employed to ensure

synchronization among databases?

C. 3. Security, authentication, access and audit 7

a) Does the system provide capability to administer

user and group security permissions for access to

software solution

b) Does the system support integration with

Microsoft Active Directory? List other directory

servers supported.

c) Does the system support multifactor

authentication? Provide description.

d) Does the system restrict multiple logins by same

user?

e) Does the system support role-based access?

62

f) Does the system support complex passwords? Can

the administrator set / change the level of

password complexity required?

g) Does the system provide facility to disable / enable

a user account?

h) Does the system have capability to provide audit

trails, logs, history tracking and reports for user

activity such as authentication, data access inserts,

updates and deletions etc.

i) Describe your web-based session management

(time out, configuration, etc.)

j) Does the system have capability to set the idle

session timeout for automatic logout

k) Provide detailed solution architecture for the

proposed system highlighting the required

interfaces and technology platforms

l) Does the system provide classification of log events

into following classes: Errors, Warning,

Information, Debug and Trace?

m) Does the system restrict access to system logs to

only authorized users?

63

n) Does the system support both HTTP and HTTPS

with encryption of internal communication using

latest version TLS (Transport Layer Security)?

o) Does the system apply measure such as “Captcha”

at the time login by the user to determine whether

user is human or not?

p) Does the system have capability to ensure edited

and deleted records are traceable and copy of

records stored in the system for MIS reporting?

C. 4. Operational Requirements 6

a) Describe the system features for meeting workload

processing demands

b) Describe the scalability features of the system

c) Does the system send alerts when resource (CPU,

Memory, network etc) / performance thresholds

are reached?

d) Does the system support definition of working

profiles – normal, short, end month, and end of

year days

64

e) Please quantify a typical system response time for

operational activities such as security master set-

up, trade entry, position query, and cash query.

f) Does your system provide the client with the

ability to use third party software to schedule and

control processing times? Please provide a list of

preferred third-party job scheduling software

partners.

g) Does your system provide the client with the

ability to use monitoring statistics to verify that

functionality is available? Please provide a list of

monitoring software partners.

C. 5. Infrastructure Requirements 10

a) Is server virtualization supported for both a web

application and a database application? Please

describe any issues and/or support of

virtualization.

b) Can your product be maintained on a client’s own

server?

c) Please describe the technical resources which

support the platform and their physical locations

and time zones supported.

65

d) Identify the operating system required by the

proposed applications software and database

management system. In the event there is more

than one suitable operating system, list all options

indicating the relative strengths and drawbacks (if

any) of each.

e) Is your system able to be installed on server that

runs IBM AIX 8.1 server operating system?

f) Is the Oracle 12c Database Platform supported?

g) Is the system supported on three (3) site

configuration – primary, backup and disaster

recovery – where is replicated to all sites. CBK uses

two or three application environments. Generally,

these are Production, Test and Development. These

are used for, testing application patches, testing

configuration changes, testing security patches,

user acceptance of new functionality, isolated fault

finding analysis, user training, other application

integration testing i.e.

C. 6. High Availability Requirements and Business Continuity 5

a) Does the system support clustering and high

availability?

66

b) Describe systems backup process for the proposed

system.

c) Describe the disaster recovery features for the

proposed system

d) What is the maximum time required to fail back to

production site?

e) What is the estimated down time for the fail over

to the backup or disaster recovery system?

f) Is the system able to run in load balanced

environment?

C. 7. System Interfaces 10

a) Is the system fully integrated across modules and

functional areas?

b) Does the system have an pre-built capability to

send / receive SWIFT messages via middleware

platforms (including IBM WebSphere MQ)?

c) Is your company a SWIFTReady label provider?

d) Is your proposed product a SWIFTReady

application (certified by Swift)?

67

e) Provide a list of standard messages that are pre-

built (i.e., MT541, MT543, etc.).

f) Describe any incompatibilities / issues with

SWIFT integration

g) Does your system have pre-built data feeds into

Bloomberg for market data, security definitions

and trade tickets? If so, please describe including

any system limitations and/or issues with the

process.

h) Does your system have pre-built data feeds into

Refinitiv (Reuters) Platform for market data and

trade tickets? If so, please describe including any

system limitations and/or issues with the process.

i) Does your system have pre-built data feeds into

Oracle GL? If so, please describe including any

system limitations and/or issues with the process.

j) Does your system have pre-built capability to

upload custodian data (positions and cash) for

reconciliation purposes? Explain any limitations

k) Does the system have capability to consume

RESTful and SOAP web services?

68

l) Does the system have capability to interface with

SMS gateway and Email Serve for SMS and email

notifications respectively?

C. 8. Implementation, Maintenance and Support 15

Implementation

a) Provide the standard timeframe for a fully

implemented system per the scope of this RFP. If

the proposal contains a phased approach, provide

typical duration(s) for each phase and a listing of

the modules proposed for each phase. The phases

include: Scope review, Business Analysis,

Installation and Configuration, User Acceptance

Testing, Data Migration, Go-Live, etc.

b) What implementation methodology do you

typically use for system implementations? Agile

or SDLC

c) Do you have a standard implementation contract?

d) What approach do use for conducting the

business analysis / scoping?

e) Describe the implementation methodology /

lifecycle / activity sequence for a typical

69

implementation of the package from project

initiation through to warranty.

Customizations, Upgrades and Release Management

f) What is the process of identifying and

implementing system customizations / change

requests?

g) Describe the release process that is followed

including the frequency of releases and versioning

h) Describe the release nomenclature (i.e. minor,

major releases)

i) Describe the methodology for issue and problem

management. What tools are used to support this

process.

j) If a client encounters system issues that must be

resolved with a software patch, are software

patches supplied by you or does a client have to

wait until the next software release?

C. 9. Project Team --

a) Describe your project organization structure and

assigned project staff. Describe the skills,

experience, and roles and responsibilities for each

70

project team member and their location (on-site,

offsite, offshore).

b) Describe the resource requirements (include

onsite, off site and offshore resources) for the

typical implementation of the base package.

Provide the estimated time of the resources on the

project.

c) Describe the process of identifying contingency

resources when the primary are unavailable for

the project implementation

d) Describe your expectation of the structure and

composition of the CBK project team

C. 10. Training 6

e) Describe your technical, functional and end-user

training program(s) you provide. Indicate the

delivery location (onsite or offsite) and duration of

training

f) Do you provide both end-user and technical

documentation?

71

g) Do you provide custom training tailored for

specific needs or group of users?

C. 11. Support 6

h) Describe the customer service/support that you

provide. What is the typical response time for

client requests?

i) Which locations is support is available (local,

EMEA and/or global)?

j) Describe your levels of support programs. Does

your company provide guarantees on software

performance or support Service Level Agreements

(SLAs).

k) Please list the number and type of personnel

resources that are necessary to support ongoing

operations of your system and/or system

modules as dictated by system design.

C. 12. Project Management 10

a) Provide / describe your project management

methodology / plan

72

b) Provide a matrix of “roles and responsibilities” for

each major activity and task contained within the

proposed implementation plan.

C. 13. Licensing 4

a) What is the licensing metric used for the system –

per user, per Server, per module?

b) Is the licence perpetual or periodically (annual)

renewed?

c) Do the testing and development instances require

a separate license?

d) Is the disaster recovery instance licensed

separately?

e) Do you have third party products or tools that

need to be licensed separately? Provide the list?

f) Describe how you ensure that third-party

products are licensed?

C. 14. Data Backup 5

73

a) Does the system have capability to archive data

based on user defined parameters such as date

range?

b) Does the system have capability to schedule

backup or manually initiate back up process?

c) Does the system have ability to automatically

synchronise data with disaster recovery site (or

system)?

d) Does the system have capability to restore backups

to a point in time?

e) Does the system generate report for each backup or

restore activity?

f) Does the system have ability to run multiple

backup tasks in parallel?

C. 15. Document Management System 3

a) Does the system have an internal document

management module?

b) Does the system have capability to interface to

external document management systems

74

c) Does system have capability to attached

documents (documents, images ) to transactions?

Total Score 100

Total Raw Weighted Score: (sum of Raw Weighted Scores above)

𝑻𝒐𝒕𝒂𝒍 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆

𝑴𝒂𝒙𝒊𝒎𝒖𝒎 𝑷𝒐𝒔𝒔𝒊𝒃𝒍𝒆 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆 𝑿 𝟑𝟎 = 𝑺𝒄𝒐𝒓𝒆

APPENDIX A: LIST OF INVESTMENT INSTRUMENTS

1. Money Market

1.1. Time Deposits

1.2. Certificate of Deposits

1.3. REPOs, Reverse REPOs & Securities Lending

1.4. Commercial Paper

1.5. Treasury bills

1.6. Cash / Demand Deposit

2. Fixed Income

2.1. Sovereign Notes / Bonds – Fixed and Floating

2.2. Sovereign Agency Notes/ Bonds – Fixed and Floating

2.3. Corporate Bonds

2.4. Emerging Market Bonds

2.5. Local / Regional Government Bonds

2.6. Ex-Div Bonds

2.7. MBS

2.8. ABS

2.9. SOFR Linked Bonds

3. Gold

4. Derivatives

4.1. FX Forward Outright

4.2. FX Swaps

4.3. Dual Currency Deposits

4.4. Futures

4.4.1. Interest Rate Futures

4.4.2. Bond Futures

5. Special Drawing Rights (SDR)

6. Equities

76

APPENDIX B: LIST OF SWIFT MESSAGE TYPES

MESSAGE TYPE PURPOSE

Category 1 Messages

MT 101 Requests to debit a customer's account held at the receiver or at another institution.

MT 102 Conveys multiple payment instructions between financial institutions.

MT 102+(STP) Conveys multiple payment instructions between financial institutions (Straight-Through Processing).

MT 103 Instructs a funds transfer.

MT 103+ (REMIT) Instructs a funds transfer with Extended Remittance Information.

MT 103+ (STP) Instructs a funds transfer (Straight-Through Processing).

MT 190 Advises an account owner of charges, interest, and other adjustments.

MT 192 Requests the receiver to consider cancellation of the message identified in the request.

MT 199 Contains information for which no other message type has been defined.

Category 2 Messages

MT 200 Requests the movement of the sender's funds to its account at another financial institution.

MT 201 Multiple of the MT 200.

MT 202 Requests the movement of funds between financial institutions except if the transfer is related to an underlying customer credit transfer that was sent with the cover method, in which case the MT 202 COV must be used.

MT 202 COV Requests the movement of funds between financial institutions, related to an underlying customer credit transfer that was sent with the cover method.

MT 204 Claims funds from SWIFT member banks.

MT 205 Further transmits a transfer request domestically except if the transfer is related to an underlying customer credit transfer that was sent with the cover method, in which case the MT 205 COV must be used.

MT 205 COV Further transmits a transfer request domestically, related to an underlying customer credit transfer that was sent with the cover method.

77

MT 210 Notifies the receiver that it will receive funds for the sender's account.

MT 290 Advises an account owner of charges, interest, and other adjustments.

MT 291 Requests payment of charges, interest, or other expenses.

MT 292 Requests the receiver to consider cancellation of the message identified in the request.

MT 295 Requests information relating to a previous message or amendment to a previous message.

MT 299 Contains information for which no other message type has been defined.

Category 3 Messages

MT 300 Confirms information agreed to in the buying/selling of two currencies.

MT 304 Advises of or instructs settlement of a third party foreign exchange deal.

MT 305 Confirms information agreed to in the buying and selling of vanilla options on currencies.

MT 306 Confirms information agreed to in the buying and selling of exotic options on currencies.

MT 320 Confirms the terms of a contract relative to a fixed loan/deposit transaction.

MT 340 Confirms the details of a forward rate agreement.

MT 341 Confirms the settlement details of a forward rate agreement.

MT 360 Confirms the details of a single currency interest rate derivative swap, cap, collar or floor.

MT 361 Confirms the details of a cross currency interest rate swap transaction.

MT 391 Requests payment of charges, interest, or other expenses.

MT 392 Requests the receiver to consider cancellation of the message identified in the request.

MT 395 Requests information relating to a previous message or amendment to a previous message.

MT 396 Responds to an MT 195 Query or MT 192 Request for Cancellation or other message where no specific message type has been provided for a response.

MT 399 Contains information for which no other message type has been defined.

Category 5 Messages

MT 502 Instructs the purchase or sale of a given quantity of a specified financial instrument under specified conditions.

78

MT 509 Provides information about the status of a previously executed trade.

MT 515 Provides a detailed accounting of financial instruments purchased or sold by the sender on behalf of the receiver or its client. It may also convey the payment details of the purchase or sale. It may also be sent by, or via an ETC service provider.

MT 515 (FUNDS)

MT 517 Positively affirms the details of a previously received confirmation/contract note.

MT 518 Confirms the details of a trade and, where necessary, its settlement to a trading counterparty.

MT 535 Reports at a specified time, the quantity and identification of securities and other holdings which the account servicer holds for the account owner.

MT 541 Instructs a receipt of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction.

MT 543 Instructs a delivery of financial instruments against payment. It may also be used to request a cancellation or pre-advise an instruction.

MT 545 Confirms a receipt of financial instruments against payment. It may also be used to cancel or reverse a confirmation.

MT 547 Confirms a delivery of financial instruments against payment. It may also be used to cancel or reverse a confirmation.

MT 548 Advises the status of a settlement instruction or replies to a cancellation request.

Category 9 Messages

MT 900 Advises an account owner of a debit to its account.

MT 910 Advises an account owner of a credit to its account.

MT 940 Provides balance and transaction details of an account to a financial institution on behalf of the account owner.

MT 950 Provides balance and transaction details of an account to the account owner.

MT 999 Contains information for which no other message type has been defined.

79

Appendix C: Application Interfaces

Interface Name Direction Interface Technology (Middleware)

Interface Data and Descriptions

1. Bloomberg 2-way Fix Messages Bloomberg to PMTP a) Security Prices b) Exchange Rates c) Fixed Income Trades d) FX Trades e) Money Market Trades f) Index Compositions g) Index Returns h) Security Definitions

PMTP to Bloomberg The following datasets will be periodically uploaded to

Bloomberg PORT for risk and performance analytics: a) Security positions b) Money Market Positions c) Cash

2. Refinitiv (Reuters) 1-way Reuters API Refinitiv to PMTP a) Security Prices b) Exchange Rates c) FX Trades d) Money Market Trades

3. Temenos T24 Core Banking System

1-way IBM WebSphere MQ

T24 to PMTP a) Government Payments b) Aggregate DFCC balances c) Aggregate Special Projects Account Balances

80

4. Investment Risk Management System (IRMS)

1-Way Database Connection / Middleware

Portfolio Management & Transaction Processing (PMTP) to IRMS a) Positions and cash balances b) Market /pricing data c) Securities master

5. SWIFT 2-way IBM WebSphere MQ

Portfolio Management & Transaction Processing (PMTP) to / From SWIFT a) Account statements – MT940/950 b) Message Confirmations c) Counterparty Messages d) Trade settlement messages

6. Oracle GL 1-way IBM WebSphere MQ

PMTP to Oracle GL Accounting Journals / Trial Balance

7. Enterprise Data Warehouse

1-way Database Connection

PMTP to Data Warehouse a) Positions b) Security Prices c) Trades (MM, Securities, Cash, FX) d) Performance & Risk Statistics e) Security Definitions (security master)

8. Global Custodian 1-way csv/xml files Global Custodian to PMTP a) Positions b) Security Prices c) External Fund Manager Data d) Performance & Risk Statistics e) NAV and Accounting Data

9. External Fund Managers 1-way Web Service External Fund Manager to PMTP a) Positions b) Transactions

10. Enterprise Directory Server ( Microsoft Active Directory)

1-way TCP Port PMTP to Active Directory a) User Authentication Request b) User Creation Request

APPENDIX D: TYPES OF PAYMENTS AND RECEIPTS (EXTERNAL CASHFLOWS)

1) Government Foreign Debt Payments – debt payments on

behalf of Kenya government. These cashflows reduce the forex

reserves.

2) Other Government Foreign Payments – Other payments on

behalf of government for other purposes (non – debt

payments).

3) Government Forex Receipts – Forex receipts on behalf of

Kenya governments. These receipts are acquired by central

bank in exchange of local currency. They increase the

investible reserves.

4) CBK Foreign Payments – Payments made for central bank’s

own account / expenses.

5) Special Project Payments—Direct Payments

Payments made on behalf of the Government out of special

projects accounts. Special projects accounts are not part of the

investible funds for CBK. They are owned and controlled by

Government and donor agencies.

6) Special Project Payments – Payments in Local Currency -

Occasionally, CBK acquires forex from special project

accounts in exchange for local currency in cases when

government needs to pay local currency out of the funds in

special projects accounts.

ANNEX B

INTERNATIONAL TENDER FOR SUPPLY, DELIVERY, TESTING AND COMMISSIONING OF INVESTMENT RISK

MANAGEMENT SYSTEM (IRMS)

REF. NO. CBK/25/2020-21

BUSINESS AND INFORMATION TECHNOLOGY (IT) REQUIREMENTS

TABLE OF CONTENTS

PAGE

SECTION A BUSINESS REQUIREMENTS ………................…..……….3 PART 1 - STATEMENT OF WORK……………………………………...……….…3

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE………….8

SECTION B INFORMATION TECHNOLOGY REQUIREMENTS…19

PART 1 – STATEMENT OF WORK…………………………………………….….19

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE…………40

APPENDIX A LIST OF INVESTMENT INSTRUMENTS………………51

APPENDIX B SYSTEM INTERFACES…………………………….………52

3

Section A: Business Requirements

Part 1 – Statement of Work

Background

The Central Bank of Kenya (herein referred to as “CBK” or “the Bank”) is established

under article 231 of the Constitution of Kenya 2010 and governed by the Central Bank

of Kenya Act Cap 491 laws of Kenya (the CBK Act) and has its Head office in Nairobi

and three branches in Mombasa, Kisumu and Eldoret.

The principal object of the Bank is to formulate and implement monetary policy

directed to achieving and maintaining stability in the general level of prices. In

fulfilling this mandate, the Bank shall foster the liquidity, solvency, and proper

functioning of a stable market-based financial system. Amongst its other objects, the

Bank is also required by statute to hold and manage the country’s foreign exchange

reserves.

Overview of CBK’s Forex Reserves Management

Foreign Exchange Reserves play a key role in ensuring that Kenya will be able to

maintain confidence in its monetary, financial stability and exchange rate policies and

protect the economic well-being of the country in the event of external shocks. In

accordance with its role as a central bank and as provided in the Central Bank of

Kenya Act 2015 (CBK Act), the official foreign exchange reserves of the Republic of

Kenya are held and managed by the Central Bank of Kenya (CBK). The CBK Act

requires the Bank to at all times endeavor to maintain a reserve of external assets at

an aggregate amount of not less than the value of four months’ imports as recorded

and averaged in the last three preceding years.

The objectives of the management of the foreign exchange reserves are:

1. Safety: Investments will be undertaken with the aim of preserving the capital of

the overall portfolio over the investment horizon, subject to the approved risk

tolerance;

2. Liquidity: Investment management will seek to ensure that adequate reserves are

available to meet a defined range of objectives. In order to maintain sufficient

4

liquidity, the foreign reserves will as much as possible be invested in instruments

or securities with an active secondary market;

3. Returns: Foreign exchange reserves will be invested in order to achieve a

reasonable rate of return consistent with the investment objectives and risk

constraints, after taking into consideration the two principles of Safety and

Liquidity.

Statement of Need

The Central Bank of Kenya seeks to procure an Investment Risk Management

System that will model and assess risk in detail with respect to both the aggregate

portfolio and individual securities, allowing staff to automate risk measurement and

reporting. In addition, a compliance monitoring capability should be provided to

ensure management of the reserves in accordance with the Investment Policy and

Guidelines.

The CBK invests its forex reserves in fixed income and money market instruments

(list of instruments is provided in Appendix A). The system should have the following

features or capabilities:

6 Risk Management and Attribution

6.1 Scenario Analysis

The system should:

l) Be capable of producing scenario analysis based on historical and user-defined

scenarios.

m) Support ability to perform what-if analysis in order to assess impact of the intended

trade(s) on the market risk, credit compliance, etc. of the portfolio in absolute terms

and relative to benchmarks / targets.

n) Calculate the impact of common market stress scenarios such as global financial crisis,

Libyan oil crisis, US financial crisis, Tequila crisis, Asian crisis for both simulated and

actual portfolios.

o) Ability to perform sensitivity analysis at every level of the portfolio – aggregate level

down to the security or risk factor levels.

5

6.2 Market risk

The system should:

a) Calculate standard risk measures (i.e. Volatility, Value at Risk (VaR),

Correlation, modified duration, Tracking error etc.) for assets outlined in

Appendix A.

b) Drill down risk exposures from the group level (portfolio) to the individual

security level.

c) Provide risk measures at security-level and aggregated at portfolio level on a

daily, weekly, monthly, quarterly, yearly, and custom period.

d) calculate risk measures on both absolute and relative (to the benchmark) basis

e) Provide risk contribution breakdown at user-defined levels such as asset class,

sector, country, region, and individual security level.

f) Have its own internal credit ratings model and provide capability of comparing

the credit ratings of assets/ counterparties generated with internal model with

those provided by the rating agencies

g) Compute Ex-ante factor risks and attribute the risks into factor and non-factor

components.

h) Generate incremental VaR and marginal VaR for portfolio ex-ante risk

attribution at different portfolio levels.

i) Be capable of computing Value at Risk (VaR) using the following methods:

Historical Simulation, Parametric, and Monte Carlo Simulation methodologies.

j) Provide user defined (custom) confidence levels and horizons for the

calculation of Value at Risk (VaR), Conditional Value at Risk (CVaR).

k) Provide capability to set market risk limits such as scenario limits and stop-loss

limits.

6.3 Credit risk

The system should:

a) Compute credit exposure at security, asset class, portfolio, portfolio manager,

tranche, issuer, counterparty, country, region, sector, credit rating.

6

b) Be able to calculate exposure limits at different levels such as security, asset

class, portfolio manager, issuer, counterparty, country, region, sector, credit

rating.

c) Show exposure deviations (under or over exposure) against the set limits at

security, asset class, issuer, counterparty, country, region, sector and credit

rating levels.

d) Provide credit exposure by par, clean and dirty market valuation.

e) Provide credit exposure by different maturity buckets

f) Have a provision to define a counterparty’s capital structure such as parent,

branch, or subsidiary with total exposure to the counterparty (branch and

subsidiary) being aggregated to the parent.

g) Compute Ex-ante factor risks and attribute the risks into factor and non-factor

components?

h) Have a provision to compute Expected Credit Loss (ECL) from user-defined

(custom) Probabilities of Default (PD), Loss Given Default (LGD) at security

level.

i) Have a provision to perform predictive risk modelling and compute Credit

VaR at security level over different time horizons (daily, weekly, monthly,

quarterly, yearly, and custom timelines) expressed at different levels of

statistical confidence.

j) Have the provision to upload static and real-time data from other systems.

7 Compliance Monitoring

The system should:

j) Maintain compliance rules to reflect Investment Guidelines and monitor

portfolio compliance versus the rules and limits.

k) Allow the testing of the compliance rules before applying to portfolio.

l) Have a library of predefined compliance rules, and also enable creation of user-

defined rules.

m) Compliance rules should be able to run on all portfolios and positions

n) Be able to provide notification on limit on both simulation and executed trade

level.

7

o) Allow viewing of compliance exceptions and overrides and store a record of

all compliance violations and compliance overrides for audit purposes

p) Be able to measure various exposures, monitor counterparties' credit exposure

against authorized limits on a real-time basis: Issuer limit, portfolio manager,

country limits and counterparty limits.

8 Pricing and Valuation

The system should be able to:

i) Support the manual upload of market data and automatic interface to pricing

sources such as Bloomberg, Refinitiv (Reuters), IDC, Markit, web sites,

spreadsheets, and text files.

j) Support the construction of yield curve from market data uploaded to the

system

k) Support the valuation of financial instruments off a yield curve, volatility

surface, and other valuation methods necessary to derive the fair value of a

financial instrument, including over the counter derivatives (see Appendix A)

l) Provide facility to define and maintain prices and exchange rates.

9 Reporting

The system should:

g) Have the ability to display and modify the screen set up by individual user

to view positions / reports in different perspectives.

h) Have the ability to customize dashboards by user roles/groups.

i) Have the ability to allow reports to be exported in different formats (MS

Excel, MS word, PDF, HTML)

j) Provide for report-writer tool with user-friendly capabilities of

parameterizing generating reports.

k) Include a facility to enable a user to define the sorting, grouping, and drill-

down.

l) Provide ability to generate reports per trading currency, reporting currency,

base currency, and local currency.

m) Support uploads from other systems for reporting purposes.

8

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE

The tenderer must respond to every stated request or requirement and indicate that

they confirm acceptance of and understand the CBK’s stated requirements. The

deferral of a response to a question or issue to the contract negotiation stage is not

acceptable. Any item not specifically addressed in the tenderer’s proposal will be

deemed as accepted by the tenderer.

PART 2.A: MANDATORY REQUIREMENTS

The tenderer must address all items detailed below and provide, in sequence, the

information and documentation as required.

Item Ref.

Mandatory Requirement Items Response (Yes / No)

Comments

A.1. Provide statement indicating that vendor’s product is able to calculate standard risk measures (i.e. Volatility, Value at Risk (VaR), Correlation, modified duration, Tracking error) for assets outlined in Annex A

A.2. Provide a statement indicating that the Respondent’s product can perform the following functions: a. Drill down risk exposures from the group level to the

individual holdings level.

b. Analyse risk factors on both a standalone basis and a

relative to a specified benchmark.

c. Create and customize risk reports.

A.3. Provide a statement indicating that the vendor’s product can incorporate derivatives into their risk models.

A.4. Provide statement indicating that vendor’s system can provide a risk contribution breakdown at user-defined levels

such as asset class, sector, country, region, and individual security level.

A.5. Provide a statement indicating that the vendor’s system can be

installed / maintained in CBK’s own servers

9

PART 2.B: GENERAL QUALIFICATIONS & EXPERIENCE

The vendor must address all items detailed below and provide, in sequence, the

information and documentation as required (referenced with the associated item

references). Evaluation Team members will independently evaluate and assign one

score for all responses to Section B— General Qualifications & Experience Items.

Item Ref.

General Qualifications & Experience Items

B. 1. Detail the name, e-mail address, mailing address, telephone number, and facsimile number of the person the Central Bank of Kenya should contact regarding the response.

B. 2. Describe your form of business (i.e., individual, sole proprietor, corporation, non-

profit corporation, partnership, limited liability company) and business location

(physical location or domicile).

B. 3. Briefly describe how long you have been providing the goods or services required

by this RFP.

B. 4. Provide information on your number of employees, client base (specify the

number of central banks who are part of your clients), and location of offices.

B. 5. Provide a statement of whether there have been any mergers, acquisitions, or

change of control of the Tenderer within the last ten (10) years. If so, include an

explanation providing relevant details.

B. 6. Provide a statement of whether the Tenderer or, to the Tenderer ‘s knowledge, any

of the Tenderer’s employees, agents, independent contractors, or subcontractors,

involved in the delivery of goods or performance of services on a contract

pursuant to this RFP, have been convicted of, pled guilty to, or pled nolo

contendere to any felony. If so, include an explanation providing relevant details.

B. 7. Provide a statement of whether, in the last ten (10) years, the Tenderer has filed (or

had filed against it) any bankruptcy or insolvency proceeding, whether voluntary

or involuntary, or undergone the appointment of a receiver, trustee, or assignee

for the benefit of creditors. If so, include an explanation providing relevant details.

B. 8. Provide a statement of whether there is any material, pending litigation against

the Tenderer that the Tenderer should reasonably believe could adversely affect

its ability to meet contract requirements pursuant to this RFP or is likely to have a

material adverse effect on the Tenderer ‘s financial condition. If such exists, list

10

each separately, explain the relevant details, and attach the opinion of counsel

addressing whether and to what extent it would impair the Tenderer’s

performance in a contract pursuant to this RFP.

B. 9. Provide a brief, descriptive statement detailing evidence of the Respondent’s

ability to deliver the goods or services sought under this RFP (e.g., prior

experience, training, certifications, resources, program and quality management

systems).

B. 10. Provide a personnel roster listing the names of key people who the Tenderer will

assign to meet the Tenderer’s requirements under this RFP. Follow the personnel

roster with a resume for each of the people listed. The resumes must detail the

individual’s title, education, current position with the Tenderer, and employment

history.

B. 11. Provide a statement of whether the Tenderer intends to use subcontractors to meet

the Tenderer ’s requirements of any contract awarded pursuant to this RFP, and if

so, detail:

d) the names of the subcontractors along with the contact person, mailing

address, telephone number, and e-mail address for each;

e) a description of the scope and portions of the goods each subcontractor

involved in the delivery of goods or performance of the services each

subcontractor will perform; and

f) a statement specifying that each proposed subcontractor has expressly

assented to being proposed as a subcontractor in the Respondent’s

response to this RFP.

B. 12. Provide a statement and any relevant details addressing whether the Tenderer is

any of the following:

e) is presently debarred, suspended, proposed for debarment, or voluntarily

excluded from covered transactions by any government or agency;

f) has within the past three (3) years, been convicted of, or had a civil

judgment rendered against the contracting party from commission of

fraud, or a criminal offence in connection with obtaining, attempting to

obtain, or performing a public (state, or local) transaction or grant under a

public transaction; violation of antitrust statutes or commission of

embezzlement, theft, forgery, bribery, falsification, or destruction of

records, making false statements, or receiving stolen property;

11

g) is presently indicted or otherwise criminally or civilly charged by a

government entity (federal, state, or local) with commission of any of the

offenses detailed above; and

h) has within a three (3) year period preceding the contract had one or more

public transactions (federal, state, or local) terminated for cause or default.

12

PART 2.C: TECHNICAL QUALIFICATIONS, EXPERIENCE & APPROACH.

The tenderer must address all items (below) and provide, in sequence, the information

and documentation as required (referenced with the associated item references). The

The evaluators will independently evaluate and score the response to each item. Each

evaluator will use the following whole number, raw point scale for scoring each item:

0 = little value 1 = poor 2 = fair 3 = satisfactory 4 = good 5 = excellent

Responding to the List of Requirements

Tenderer must respond to each requirement contained within this tender document

using the following criteria. Vendor’s responses must be in the same order in which the

questions appear and must use the same numbering scheme as outlined below:

FP Fully Provided (Out-of-the-box), Solution currently includes this capability in its current general software release.

TP Third Party Software Required Third party solutions is required to deliver this capability

M Modification to existing software Minimal modification is required to provide the requirement

C Custom Development Required Custom development required for the requirement

NA Not Available Functionality is not available (Out of the box)

O Other Other

For any specifications to which the Vendor answers other than FP (Fully Provided),

Bidder must describe:

• Whether the CBK will incur any additional cost for the feature, function, product, or

service once it becomes available other than the cost of maintaining a valid software

maintenance agreement for the current modules/system proposed by the Bidder as

part of the initial installation (i.e. a new module, replacement or upgrade to an

existing module, new hardware required, etc.)

• If the feature, function product or service falls under the category as Not Available

(N), the Bidder may provide; (a) an explanation of how the specification might be

met using alternative methods within the system or (b) if it is available from a third

party partner. Either explanation must include availability dates and additional

costs, either direct or indirect.

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

C. 1. Does the system have capability to calculate and analyze the risk

measures below both on standalone and relative-to-benchmark basis

with aggregation at both portfolio and group levels. Please provide a

separate answer for each measure listed below:

• Yield to maturity

• Modified duration

• Option-adjusted duration

• Contribution to duration

• Option-adjusted spread

• Key rates duration

• PV01

• DV01

• G-Spread

• I-Spread

• Z-Spread

• Option-adjusted convexity

• Tracking error

• Value-at-Risk

15

14

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

C. 2.

Does the system have ability to load CBK’s historical portfolio holdings and/or transactional data for historical risk analysis?

8

C. 3. Does the system have the ability to calculate risk contribution and

attribution for the following security types of investments listed

below?

a) Futures (Bonds and Interest Rate)

b) Plain Vanilla Bonds

c) Money Market Instruments

d) Inflation-Linked notes and bonds

e) Forwards

f) Swaps

g) Callable corporate and agency bonds

h) U.S. ABS and CMBS

i) Agency MBS and agency CMO

12

C. 4. Scenario Analysis and Stress Testing 10

15

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

a) Does the system have capability to perform what-if analysis

to assess impact of one or more stress factors, including

interest rate and FX shifts, credit spread changes, inflation

shocks, volatility shifts, and prepayment shifts on risk,

performance, and compliance of the portfolio in absolute

terms and relative to benchmarks / targets?

b) Does the system have capability to do stress testing (i.e., how

the portfolio would look through a 2008 crisis or other

historical crises, a 20% drop or interest rate spike of 200 basis

points) along with any system limitations and/or issues.

c) Does the system have capability to setup custom scenarios

and generate impact of these scenarios for both simulated

and actual portfolio?

C. 5. Value at Risk (VaR)

10

16

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

a) Does the system have capability to compute the following ex-ante

risk measures: Value at Risk (VaR). Conditional VaR and

Component VaR?

b) Does the system have capability to produce the above measures for

the following periods: one-day, one-month, one-quarter, one (1)

year, three (3) year and five (5) year periods?

c) Does system have capability to set user-defined (custom)

confidence levels and horizons for the calculation of Value at Risk

(VaR) and Conditional Value at Risk (CVaR)?

d) Does the system support historical, Monte Carlo and Parametric

methods for VaR calculation?

e) Describe your system’s VaR back testing capabilities

C. 6. Credit Risk 15

a) Does the system have capability to show credit risk exposures

by a classification of choice (i.e., country, country of risk, asset

class, sub-asset class, currency, portfolio manager, tranche,

issuer, counterparty, Global Industry Classification Standard

(GICS) sectors, region, industry portfolio)?

b) Does your system have the capability to track changes in the

credit rating of different counterparties?

17

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

c) Does your system have capability to utilize or integrate

market-based credit risk measures such as Market CDS

spreads data from external platforms such as Markit or

Bloomberg?

d) Does your system have a provision to compute Expected

Credit Loss (ECL), Probabilities of Default (PD) and Loss

Given Default (LGD) for counterparties, issuers and

sovereigns?

e) Does your system have an inbuilt credit rating mechanism for

counterparties, issuers and sovereigns?

f) Does the system allow calculation of a composite rating based

on ratings from rating agencies and/or internal

methodology?

g) Does the system support simulation of changes in ratings so

that the user is able to tell how the average ratings have been

affected prior to and after the ratings change?

h) Does the system keep track and report the history of changes

in ratings for counterparts and issuers, etc.?

18

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

i) Does the system have capability to compute Credit VaR for

counterparties and issuers?

C. 7. Compliance Monitoring 15

a) Does the system have features that can configure and report

concentration limits by, and not limited to, sector, country,

region, asset class, ratings?

b) Does the system allow setup of limits in notional value

and/or percentage of the portfolio size?

c) Is your system able to show exposure deviations (under or

over exposure) against the set limits at security, asset class,

issuer, counterparty, country, region, sector and credit rating

levels.

d) Does the system possess capability to set up and trigger early

warnings to assigned users for potential compliance breaches

and to assign severity levels to those warnings?

e) Does the system support viewing the compliance status by

specific attributes (exposure, ratings, sector etc.) for

counterparties and issuers, etc.?

19

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

f) Does your system have the capability to set market risk limits

such as scenario limits and stop-loss limits?

C. 6. Reporting 15

h) Does the system have capability to compute and run reports

for any user-defined reporting period for all types of

reporting

i) Does the system have capability to drill-down to position

level for all types of reporting

j) Does the system produce dynamic customizable reporting? If

so, is it easy for an end-user to create a custom report or, does

an IT Developer have to create the reporting?

k) Does the system allow the end-user the ability to export files

in formats that can be uploaded to other systems?

l) Does the system provide multiple reporting formats such as:

xls, pdf, csv, txt, and mobile formats

m) Please provide evidence that report delivery is flexible and

deliverable through multiple channels (i.e., e-mail, print, file

drop, and on-schedule’s). Please describe any limitations with

the reporting.

20

Item Ref. Technical Qualifications, Experience & Approach Items Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

n) Does the system provide for report-writer tool with user-

friendly capabilities of parameterizing generating reports.

Total Score

Total Raw Weighted Score: (sum of Raw Weighted Scores above)

𝑻𝒐𝒕𝒂𝒍 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆

𝑴𝒂𝒙𝒊𝒎𝒖𝒎 𝑷𝒐𝒔𝒔𝒊𝒃𝒍𝒆 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆 𝑿 𝟔𝟎 = 𝑺𝒄𝒐𝒓𝒆

Section B: Information Technology Requirements

PART 1 – STATEMENT OF WORK

Introduction

The section contains the technology requirements for the Investment Risk Management System (IRMS) which will be run by the Central Bank of Kenya (CBK). The CBK wishes to ensure that the IRMS system provides a leading edge to the Central Bank. The main purpose of this document is to provide a clear understanding of the meaning and scope of the information technology (IT) requirements. The IT requirements encompass all basic functionalities of a standard IRMS, with mapping to the existing IT environment of the CBK.

Project Scope

The scope of the project is for the supply and implementation, of system and their related linkages, and proposals are invited from qualified companies for:

a) Supply, installation and configuration of IRMS application software package on the

existing environment in Central Bank of Kenya;

b) Integration/linkage of the IRMS with other systems as specified in the Appendix B

c) The complete range of required services including at least the following:

(i).Project management;

(ii).Business-level advice and consultancy to CBK concerning the establishment

and operation of the system;

(iii).Customizations/parameterization of software package(s);

(iv).Installation of all software items;

(v).Implementation of all required interfaces;

(vi).Acceptance testing;

(vii).Training;

(viii).Documentation;

(ix).Support and Helpdesk;

(x).Migration of Data

(xi).Support during Going-Live

(xii).Maintenance and on-going support.

General Technical Requirements

c) Language Support: The system must provide support for English.

d) Specifically, all display technologies and software must support the ISO 8859-15,

ISO 8859-6 and Windows-1256 (if appropriate) character sets

22

Specific Information Technology Requirements

2 General Requirements

As applicable, the system should:

a) The system should support three (3) site deployment (primary, backup and

Data recovery site) for high availability.

b) Have a high level of usability with a common “look and feel” achieved

through a standard graphical user interface (GUI);

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

d) Provide full audit trails for all activities within the system, including system

accesses and messages sent and received.

e) Have high levels of trustworthiness with particular emphasis on data

integrity and security, particularly preventing unauthorized access and assuring

100% data accuracy; support for multifactor authentication is preferred.

f) Possess high levels of service availability which will be assured through

demonstration, rigorous testing and a robust Service Level Agreement.

Integrity

The system should provide:

f) Message processing integrity checks to ensure that the total nominal value of all

instruments in all recorded portfolios is matched and reconciles with the control

totals for all issues registered.

g) Security of messages with a high level of message authentication, data integrity, and

confidentiality.

h) Guarantee of no data loss either in transmission or after a failure; system should be

able to recover gracefully in the event of unplanned/unforeseen outages

Security, Authentication, Access, and Audit

Security

e) Exchange of data between IRMS and other systems inside CBK should be hashed and

/ or encrypted.

f) The System must be based on accepted, widely used and recognized technical and

security solutions.

23

g) The System’s databases must be protected against undesired changes.

h) Users and Administrators must not be able to change the transactions history in the

System

Operating System (OS) and Platform Configurations

g) All system components (OS, Database, applications, network devices) will be

hardened according to specific Central Bank of Kenya cyber security guidelines as

well as specifications provided by the product manufacturer.

h) All software (OS, application, database) packages and modules not required for this

system must be deactivated and removed (where possible) from the system

i) The vendor must provide a list of all the minimum required software (OS,

application, databases) and service ports required for the system to function.

j) The most recent version of the software in use, with the latest security patches /

service packs must be applied across all components.

k) The supplier/vendor must have a mechanism to inform Central bank of Kenya

regularly about relevant security updates and patches that may affect smooth and

secure operations of the system.

System Security Architecture

2.1.1 System Design & Documentation

Detailed security design documentation of the system must be provided by vendor

covering, as a minimum, descriptions of:

k) system architecture

l) interfaces

m) all installed and uninstalled/disabled components or application modules

n) supplier related Operations & Maintenance Procedures (where relevant)

o) exhaustive list of all security updates and modification

p) controls against manipulation, misuse or disclosure of personal or sensitive data

q) password parameters and how they can be configured

r) user role matrix and its configuration

2.1.2 System Security

Detailed documentation must be provided with regard to security mechanisms to protect

connections to public networks.

Authentication

k) The System must only allow access to identified, authenticated, and authorized

users.

24

l) Authentication data must not be shown, stored, transported, or recorded in clear

text.

m) The strength of passwords used with operation and maintenance accounts system

must be enforced as per leading international standards. This system capability

must also be configurable to meet changing password policy control requirements

(for example, but not limited to, a change in the password length & complexity

policy requirement).

n) The system must provide a configurable mechanism:

• to detect and block simple passwords (e.g. 123456, abcdef, identical username &

password, etc.)

• check that the password does not contain more than two successive identical

characters

• to allow only the administrator to reset the passwords

• Not to allow hard-coded passwords (i.e. no service/application user passwords

displayed in source code)

o) The system must provide a password change confirmation procedure

p) The system must provide the capability to print a list of all possible access

privileges, a specific user's access privileges and comparison tables between

different user IDs

User Access

m) System access, named for this document as an Access Control System (ACS), must

be based on a documented security and system access model and architecture,

including a policy for interacting with different security and access models at

operating system and database level.

n) The ACS must be based on the “least privilege principle”.

o) The ACS must have a role-based access model.

p) The ACS must be able to set privileges and access rights to objects and subjects.

q) The ACS must categorize users into groups and define access levels on both user

level and group level.

r) This must be done in such a way that verification of the registration will be

required by another user or that full registration will require two different users.

s) The ACS must enforce the generation and use of strong two factor (incl. support for

biometric) authentication/high quality passwords and PINs

t) All remote operation and maintenance tasks must only be performed via encrypted

protocols (e.g. ssh, ssl) and unencrypted accesses deactivated

25

u) There should be a possibility of the ACS to interface to Directory Services e.g.

Active Directory for user authentication

Audit Trail

h) A log must be kept of all logon attempts on all Systems delivered by the bidder.

i) The System must maintain detailed audit trails to enable investigation of:

• suspicions of errors

• other abuses or attempted abuses of the System

• communication transmission attempts, whether successful or not

j) The System must maintain:

• a log of all errors occurring in the system including preparation of a message

• access control over the audit records

k) The system should provide audit trails on all software layers (OS, database,

application) allowing a tight control of accessed functions and information

l) The security log files & audit trail must be protected against manual modification

even by the super user and methods applied documented.

m) The system must have a configurable automated process implemented to send log

files or defined logged events to a security log server.

n) The system must be able to interface with other third-party Enterprise Log

Management System, e.g. SIEM for centralized logging

Operational requirements

General Requirements

As applicable, the system should:

g) Allow for easy customization through on-screen parameters to

accommodate new, changed or modified rules that will govern various functions

e.g. create a new message type, create a new instrument type, etc.;

h) Allow authorized personnel to change the business process flow through

the setting of parameters in process control tables.

i) Provide online access to and reporting of historical records – covering a

period of at least seven (7) years plus the current year – without compromising

response times;

j) Provide online, context sensitive help for all user and operator functions.

k) Enable automation of daily processing including initiating links to directly

interfaced systems with appropriate security procedures and exception and

summary control reports;

26

l) Be operationally resilient, with high levels of local recovery supported by

an appropriately configured High-availability and Disaster Recovery (DR)

installation and a smooth cut-over between the primary, secondary and DR sites,

and back again to the primary site when service is recovered.

System availability

c) The System must be accessible at least 20 hours a day, every day of the month

except for about four days for maintenance (planned shutdown, non-working

days for maintenance).

d) The System must have a Service Availability of 99.95% during the hours

when the System is open.

System capacity

The System must have the capacity at least: (iv). to process and settle 2,000 transactions a day, and at the same time allow use

of the System’s other functions.

(v). to have 20 users logged on and providing requests to the System concurrently.

(vi). be scalable to handle a growth rate of 50% per annum with scalability for 8

years.

Response Times

The actual response time is measured from the point where the transaction is received by

the System. The following list of requirements must be met:

e) For 95% of transactions and simple queries in real time, the response time must not

exceed 1 second during the peak hour.

f) For 95% of complex queries in real time, the response time must not exceed 2 seconds

during the peak hour.

g) The maximum response time for system log-in is 7 seconds. (Response means full

login and display of next screen)

h) The maximum response time for message arrival acknowledgement is 5 seconds.

Parameter Management

c) It must be possible to make system parameters changes, like Date changes, while a

System is open and these changes should have immediate effect.

d) Please list what system parameters can be changed or updated while a system is

open. And what changes take effect on next business day.

27

Infrastructure requirements

Environments

The IRMS will run on CBK equipment. As a mandatory requirement, the bidder will be required to implement the system in three sites, a primary processing site (data centre) at CBK’s head office, at high availability site that is not far from head office, and in a business recovery centre (DRC):

j) The equipment at the primary site is designed to have comprehensive resilience

features to ensure that, in normal operation, a failure of any single element such as a

server or blade (for example) will have no effect on the operation of the system.

k) Under normal operation the primary site will host the live version of the system.

l) The live system will be installed on servers at the three (3) sites. Responses must

contain the Bidders response as to how all sites will be installed and coupled to enable

the highest level of availability.

m) Responses must 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.

n) A reference environment must be available at all times to carry copy of the live

environment to be refreshed daily for troubleshooting. Before going Live, this

environment will be considered a ‘pre-production’ version of the system that must be

installed at the primary site for use in parallel running in the period between user

acceptance and load testing and cut-over to live operation.

o) A training environment must be available at all times to allow for training of CBK

staff and new users.

p) A user acceptance testing environment must be available at all times to allow for

testing of system features, integration, performance, planned system changes, and

participant interface testing.

q) Bidders must describe how they will accomplish the following main tasks:

- Management of changes involving operating systems, system software,

middleware, databases, and application software, covering all participants where

applicable;

- Operation of the above system components;

- Testing of parameter-level changes made by the system operator.

- Testing of system performance.

r) Bidder must give full details of all hardware, system software, middleware and any

other products and equipment necessary to run the system.

28

Infrastructure – Hardware & Software

c) The following are current CBK hardware and software configurations:

• The CBK installed server hardware is IBM POWER9 Server and Windows Intel

Server Blades

• The CBK installed server operating system is AIX 8.1 and Windows Server OS

• The CBK installed database servers is Oracle 12c and above.

d) Preferably, the system should be able to operate within the above configuration of

hardware, software, and middleware.

Data Retention Requirements

Backing up data standard is:

i) Full backups will be performed over weekends

j) Incremental (only changes) backups must be performed during each business day

k) 25 business day cycles of the daily backups must be kept (each cycle to keep the pre

and post backup of the database)

l) The System must not compromise the integrity or security of confidential stored

information in any way.

m) The Bidder must provide a definition of the back-up plan according to the following

four types of data:

o System (Operating System and Applications) data

o User Data (the data specific to each part of the system that is susceptible to being

modified frequently)

o Confidential Information (relating to the architecture of the network belonging

to Central Bank of Kenya or its stakeholders)

o Log (the set of traces on what is made on/from each part of the system).

n) All backup actions must be traceable

o) Data must be retained in the System for at least 15 years. 10 years available online

and offline as backups for 15 years

p) When media used by the system is to be disposed of or reused, necessary measures

must be taken to prevent any subsequent retrieval of personal data and other

information stored.

29

High availability requirements

High Availability

Please indicate how these mandatory requirements will be met:

i) All production Systems are deployed as highly available and in redundant pairs,

in high availability site, as well as in a disaster recovery environment.

j) Replication on three active sites with real-time synchronization of application and

database. Replication of primary, secondary and disaster recovery is mandatory

for any system installed in the bank

k) Please indicate if your System can be installed and operate with this configuration

l) High availability must be ensured on all System components

m) The System must ensure “no single loss” of a message due to failure of any

component of the System.

Disaster recovery

Please indicate how these mandatory requirements will be met:

g) The Bidder must provide a documented Business Continuity Plan for the service.

h) The Bidder must provide a detailed scenario of fail over between Systems in the

production site; and between production, high availability, and DRC sites.

i) The System must be able to be run at one site with production and backup servers

and with automatic fail-over within the site, while having a high availability site

with failover to this other site.

j) The Bidder must define a down time for the fail over to the backup System within

the production site of 0 to 10 minutes.

k) The Bidder must define a max time required to fail back the service from the high

availability site to the production site of 30 mins or less (during time assigned for

maintenance)

l) Hot standby or disaster recovery site can be up to 300 KM far from the active site.

System Interfaces

All interfaces should meet the bank’s security standards, the System will have the

following interfaces. More details on interfaces provided in Appendix A.

Direct Access to the system:

The System’s users must be able to enter data to the system by the following ways:

• opening a pre-defined form for data entry – controlled data entry

30

• uploading a data file in a pre-defined format

Any interchange of data between the IRMS and other systems, must be performed

through the following methods:

• An XML message in ISO20022 format

• As an option, the system should provide for open standards architecture by allowing

exchange through web service, API, JMS, open for integration

• Bidder should provide information on all message standards that their systems

follow, particularly their forward development plans in this area.

Any report extracted from the system must be produced in, at least, the following

formats:

• XSL, XML, or comma delimited format

• PDF format

• XLS or XLXS

Portfolio Management and Transaction Processing (PMTP)

It is expected that there will be interconnection between IRMS and PMTP to download

positions, transactions and market data.

Bloomberg

The Bloomberg platform is used for execution of Fixed Income, FX and Money Market

(deposit placements) transactions. Market data – Security prices, CDS, security

definitions, FX rates – is also downloaded from Bloomberg. The new IRMS system

should therefore have capability to interface to Bloomberg for the following:

f) Fixed Income Trades,

g) FX Trades

h) Money Market Trades (Deposit Placements

i) Security definitions

j) Security Prices

Index Providers – Intercontinental Exchange

Currently, at the end of each day, the index (G1QA) composition file is received via email

from Intercontinental Exchange (ICE). The security prices are extracted from this file and

uploaded to the system. At the end of the month, the composition is uploaded to the

system for portfolio rebalancing and simulation.

Report Generation

In order to generate customized reports, the system must either

31

• provide a report generation module, where system admin, will be able to develop

customized reports bringing data from multiple areas in the system and putting them

together, including customizing page format, developing SQL queries, formatting the

output results in a customized way, and inserting static information, graphs and other

tools. This option is a preferred option, Or

• Allowing an external report generation system from accessing the IRMS system

directly, including access to read data from the system. This will imply the bidder will

provide the IRMS data structure in the form of tables or views.

Data Warehouse and Business Intelligence Platform (DWH):

c) At the end of the business day, a selective set of data (i.e. positions, limit balances)

will be transferred to the CBK data warehouse.

d) The process of generating daily reports to be sent to DWH must be automatic, in a

pre-defined file format.

Microsoft Active Directory

The IRMS systems should have capability to interface to Microsoft Active Directory for

user creation and authentication. Role assignment should be provided for in IRMS

Implementation and Support This part specifies the service requirements that must be satisfied to ensure successful

implementation of the entire system.

3 Business Level Consulting

CBK expects that the Bidder must provide a high level of business consulting and

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

its international experience in financial market infrastructure implementation. Bidders

are required to provide documentation including system rules, certificate policy, e-

token management procedures, user acceptance tests scenario, operating procedures

and charging policies.

Project Plan and Implementation Schedule

Project Plan

Bidder must provide Preliminary Project Plans showing how they intend to carry out

all aspects of the project. Project plans must address at least the following subjects:

p) Project organization and management plan (covering both the Bidder’s team and

expectations of the Purchaser’s involvement);

q) The Bidder’s proposed project team.

32

r) Phases of the project execution showing sequencing, activities and deliverables for

each phase;

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

t) a project plan in Gantt chart format;

u) System requirements analysis, design, development and delivery;

v) A detailed installation plan – site preparation, hardware installation and testing;

w) System integration plan;

x) Training plan;

y) Change management plan;

z) Documentation plan;

aa) Change management plan;

bb) Acceptance testing plan;

cc) Warranty and post-warranty service plan;

dd) Data Migration Plan

Implementation Schedule

CBK expects the project implementation to comprise of at least the activities listed

below. The project will follow Agile Methodology in its implementation.

Identify the Project Scope

l) Business analysis (scoping study) to establish and document the detailed

functional, technical and integration requirements of the system.

m) Customization and integration of the application software to meet the detailed

requirements documented as described in both Business and IT Requirements;

n) Installation, configuration, testing and commissioning of the technical components

(hardware and software) of the system, including integration with the existing ICT

environment as necessary;

o) Installation and testing of the application software, and third party software in all

in four (4) environments, including Development (DEV), Test (TST), Production

(PRD) and Disaster Recovery (DR):

33

p) Implementation of all required system interfaces (refer to Appendix A);

q) Training – includes business and technical training.;

r) User Acceptance Testing (UAT);

s) Pilot operation (parallel running).

t) Migration of data from old environments to IRMS

u) Go Live.

v) Post-Implementation Maintenance and Support

Bidder should include any additional activities that they feel are required.

Bidder’s Project Team

e) The Bidder must describe the competences, roles and responsibilities of their

proposed team members, including resume for all proposed team members.

f) To ensure maximum knowledge transfer, the Bidder’s project team must be

structured to work with counterparts within CBK, and Bidder must therefore

show their expectations of CBK’s team structure and management, together

with roles and responsibilities.

g) The Bidder’s assigned project staff that should not change during the project

and bidder should describe how they will ensure that the resources working on

the project will continue to be available throughout the project. If there should

be any changes in resources, bidders should describe the process for identifying

contingency resources. Replacement of the key personnel will require prior

written consent from CBK.

h) 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 Kenya, offsite and offshore location(s).

The project team must include key specialists and alternates in at least the following areas: g. Project Management;

h. Business Experts (IRMS);

i. Systems Integration

j. Change Management

k. Training

l. Application testing

34

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.

Project Management

The following section give CBK’s expectations as regards overall project management.

Bidder are invited to comment on them and to propose any variations or modifications

as they see fit.

Steering Committee

e) CBK will appoint an internal steering committee which will have oversight of the

project and will have final responsibility for all aspects. The steering committee

will liaise as required with the responsible implementation teams or staffs.

f) CBK’s project manager will act as secretary to the steering committee.

g) The steering 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.

h) Both project managers must attend steering committee meetings.

Project Managers

CBK and the Bidder must 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 must work closely

together at all stages of the contract.

Progress Monitoring

Throughout the project execution, the Bidder’s project manager must submit to CBK’s

project manager a weekly progress report covering:

j) results accomplished during the prior period;

k) cumulative deviations to date from schedule of progress milestones as

specified in the

l) Agreed and Finalized Project Plan;

m) corrective actions to be taken to return to planned schedule of progress

and/or proposed revisions to planned schedule;

n) other issues and outstanding problems and proposed actions to be taken to

resolve them;

35

o) resources that the Bidder expects to be provided by the Purchaser and/or

actions to be taken by the Purchaser in the next reporting period;

p) other issues or potential problems the Bidder foresees that could have an

impact on project progress and/or effectiveness;

q) (as applicable) training participant test results;

r) log of service calls and problem resolutions during the preceding month.

The two project managers must 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 Bidder’s monthly progress reports), agree actions to be

taken to resolve problems, and update the project plan as necessary.

The project managers must invite other project team members to take part in the

progress meetings as necessary.

Written minutes of all meetings and agreed actions must be taken by CBK’s project

manager and circulated to all affected parties as applicable, including the steering

committee.

User Group Meetings

The membership of this Working Group comprises representatives of all involved CBK

departments. CBK’s project manager will convene regular meetings of the Working

Group, at which the two project managers will report on progress and consult on any

project aspects requiring user involvement.

CBK Consultancy Firm

CBK may appoint a specialized consultancy firm to support CBK in different aspects of

the IRMS implementation, including business aspects, legal aspects, and others. CBK

consultancy firm will act as a CBK staff, and It is expected that the bidder will provide

full support to the operation of the firm.

Testing and Acceptance

The full system must not be finally accepted (i.e. achieve Operational Acceptance) until

all functionality has been fully tested and shown to be working correctly at all

locations, including all users, and with full integration of all systems defined in the

SOW.

36

General

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

m. Ease of installation and system start up;

n. Operation of the system platform;

o. Operation and management of the systems by both business and technical teams;

p. Reliable and efficient automated communications interfaces;

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

r. Ability to handle expected and peak workloads for a minimum period of five years’

after

s. Operational Acceptance;

t. Clear and effective documentation and other support materials;

u. Effective education and training;

v. Effective organizational arrangements for full scale operation;

w. Effective support organization;

x. Effective problem reporting, tracking and resolution procedures.

Acceptance Testing

d) Successful completion of the contract must be attained through a series of formal

acceptance tests performed on all aspects of both systems. Payment will be directly

related to successful completion of agreed milestones.

e) The acceptance tests will demonstrate that the Bidder has met each requirement

specified and agreed in the contract and has delivered all required reports and

documentation and an effective operational system.

f) Each step of the acceptance tests must be fully documented and signed-off by CBK

to signify acceptance of each element.

Sequence of User Acceptance Tests (UAT)

e. Initial acceptance tests must be performed using the system installed at the

primary site at CBK. These tests will confirm general functioning of each element of

the entire system.

f. Functional acceptance tests must be conducted across the fully installed systems in

both the primary and DR processing sites. These will entail testing every detailed

aspect of system functionality, including a full range of error checking.

g. Operational acceptance tests must involve full load (stress) testing of the system to

confirm the ability of the hardware and software (as sized by the Bidder) to handle

the maximum expected peak workload. They will include the full range of failover

procedures specified by the Bidder for handling failures at either site.

h. Interface acceptance tests must involve full testing of the system to confirm the

proper functioning of the major interfaces which include:

37

• the interface to BLOOMBERG.

• the interface to Portfolio Management and Transaction Processing System

(PMTP)

Acceptance Test Design and Execution

The Bidder must propose the contents of all acceptance tests for CBK’s approval and

planning, and modification as necessary. CBK will develop its own acceptance tests as

well, to represent its work flow and practices. All acceptance tests will be carried out

by CBK operations and technical staff, and will be monitored and supported by the

Bidder at each step. CBK will make management personnel and staff available to the

Bidder 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 CBK.

Evaluation of Acceptance Test Results

CBK’s project manager will be responsible for the final rating of all acceptance test

results. At the end of each test phase, CBK’s project manager will provide to the Bidder

either a formal letter of acceptance if the Bidder 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.

Fault Correction

The Bidder must be responsible for correcting all faults (i.e. instances where any

element of the systems does not perform in accordance with the signed-off

specification) found during acceptance testing in a timely manner so that the overall

project schedule is not affected.

Training and Knowledge Transfer

Knowledge Transfer

CBK considers training and knowledge transfer to be among the most important

factors for the success of the project. An important objective is therefore to ensure

effective transfer of IRMS and related technological knowledge. The bidder must

prepare targeted technical and business-based knowledge transfer to the relevant

teams. This is viewed as critical for all parties to become self-sufficient in the operation

and maintenance of the new services and related technologies. The Bidder must

describe in detail how they intend to achieve a high degree of knowledge transfer.

38

Training

e) The Bidder must provide training plans showing, for each system element to be

supplied, and for the project overall, all proposed training programs, the

recommended number and (if applicable) prior knowledge of people to be trained

in each institution, the duration of each training module and the proposed number

of times each module is proposed to be delivered. The training programs will

include:

(v). Functional Training - Class room sessions on all required modules for the

Project Core Team (business super users, business analysts)

(vi). Technical Training - Class room sessions on all technical aspects of the system

e.g. data organization, customization, interfacing with other standard software

like Bloomberg, Reuters, SWIFT, legacy systems installation, and maintenance

aspects of the system.

(vii). End User Training (Functional & technical) - Class room sessions for End Users.

This should be given just before QA environment and User Acceptance testing,

so the team is ready for the Acceptance testing.

(viii). Operations Training – computer operations requirements, security operations,

backup, disaster recovery and business continuity operations

f) Qualified personnel who hold relevant certificates as applicable must carry out all

training. The Curriculum Vitae and copy/ies of certificate/s must be supplied for

each trainer proposed.

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

commencement of training. They should cover not only CBK but all involved

organizations as applicable to each component/module of the IRMS.

h) Any other relevant training that will enable optimal usage of the system

Documentation

Preliminary project plans must contain detailed specifications of the documentation,

which the bidder 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 CBK system.

CBK expects that the supplied documentation must include at least the following:

e) Product Literature, describing the different system components that address the

business and technical requirements of this procurement;

39

f) 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;

g) Technical Documentation that CBK 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. This must include:

viii. Utility software functional specifications and descriptions;

ix. Application software functional specifications and descriptions;

x. Documentation covering the testing environment;

xi. Instructions for backup, restore and selective restore;

xii. Instructions for switch-over of processing to and from the Hi-Availability

and DRC sites;

xiii. As-Built and Final Design documentation that includes the selected

options and configuration settings;

xiv. Any other technical documentation that the CBK will need to use for the

safe and effective running of the processing environment.

h) Detailed Documentation of Operational Processes. This must include:

xi. Standard batch scripts;

xii. Recommended scheduling of batch jobs (background and foreground);

xiii. Details of all background and foreground tasks;

xiv. Dependencies of all programs within each batch;

xv. Dependencies between batches;

xvi. Details of all standard reports;

xvii. Internal integrity controls performed by the system;

xviii. Relationships between programs and data;

xix. Relationship between application and operating system;

xx. Relationship between application and database manager.

Migration of Data

Data migration must follow the following approach:

f) The Bidder must provide clear guidelines detailing data to be migrated from legacy

system. All necessary datasets required in IRMS from the legacy system must be

documented in detail.

g) A process to validate the migrated data must be put in place to audit the data. This

must include reconciliation reports to show statistics and checksums for the data

migrated vs the legacy system.

40

h) Just before the first day of going live, to migrate opening balances of all accounts,

positions, static data, custodians, plus history of transactions, allowing for printing

of account statements, calculating of taxes, and other functions depending on

historical data.

i) The migration process must be planned very well, and there must be an automated

batch that handles all data coming from T24 for migration, restructure it, and inserts

them in the IRMS database.

j) There will be need to have parallel (pilot) runs to ensure that the migrated data is

valid and system is reporting at par as the production system.

Go-Live, Warranty and Support Services

Go-Live Support

The Bidder must provide on-site support for the system during the Go-Live process to

ensure smooth and timely switch to the new system. The support should cover both

production and disaster recovery sites.

Warranty Period

The Bidder must provide operational support for the system on-site at the primary and

alternate processing sites for a period of three (3) months after Go-Live. During this

time, the Bidder’s support personnel must be available on an immediate on-call basis

during normal business hours at CBK’s head office.

Support and Maintenance Period

Bidder must provide support for the entire system at no charge for a period of 24

months after Go-Live. The Bidder 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 CBK and the Bidder during

implementation.

During this maintenance period, any new releases and upgrades of the system will be

installed at no additional charge. The Bidder and CBK will agree on the pricing and

period of maintenance after expiry of this initial maintenance period.

The Bidder 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 CBK and the Bidder during implementation.

Terms for out of hours support must also be agreed upon during this period. The

support services must include at least the following:

b) Software support, including:

41

vii. Problem response, management and resolution as detailed below;

viii. Error correction (patches) for the application software.

ix. General advice and guidance for all software products including

application packages, system software, DBMS, middleware etc.

x. The Bidder shall 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

minimize any impacts to the levels of service required by CBK, covering

knowledge of CBK’s business operations as well as expertise in the

application software.

xi. Provision of all patches and corrective, new and updated

xii. versions of all supplied software products which become available,

including change management support for introducing them. Bidder

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.

On-going implementation of changes if required/requested by CBK. Bids must include

the Bidder’s proposed procedures for processing and implementing Change Requests,

including the costs per person/hour or person/day for all categories of personnel who

may be involved in the Change Request process. Such costs shall be fixed for the

duration of the Warranty Period

Service Level Agreement (SLA)

The bidder will provide a draft SLA agreement detailing the service hours, system

availability, and the business impact levels for CBK review.

Extreme Situations

Bidders are requested to suggest procedures that can invoked in the event of extreme

emergency situations, extreme event which affects both the main IT processing center

at CBK’s head office and alternative centers.

Problem Management

The Bidder’s support center must answer incoming telephone calls within one minute

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

All problems notified to the Bidder must have a priority assigned by CBK that will

define the severity and impact to CBK’s service levels with a resolution target and

42

escalation framework to make sure the effects of the problems are restrained or

minimized.

Priority levels will be as follows:

e) Priority 1: A system component has failed in such a way that one or more critical

elements of the system are unusable. The Bidder must provide appropriate support

within fifteen minutes and provide a work-around or fix within two hours of

receiving notification.

f) Priority 2: The service is severely impacted and performance is restricted. The

Bidder must provide appropriate support within two hours and provide a work-

around or fix within four hours of receiving notification.

g) Priority 3: The service is impacted and performance is reduced. The Bidder must

supply a work around or fix within 24 hours of receiving notification.

h) Priority 4: The service may be impacted and performance can be reduced. Priority 4

problems must be supported during the Bidder’s and CBK’s normal hours of

business.

Details of problems logged with the Bidder, whether during the project, the System

Warranty Period or under an on-going Service Level Agreement, must be easy for CBK

to follow up. Regular reporting must be a standard feature of the service, provided by

the bidder on on-line basis, and must include:

e) The number of service-disrupting incidents over any selected period by source of

disruption and in total;

f) The number of non-services disrupting incidents reported over any selected period;

g) The time taken to restore normal service after each recorded service disruption.

h) Bidder should also explain how CBK staff can monitor reported problems on a

regular basis.

Performance Expectations

CBK expects a very high level of reliability and availability of all its systems and the

system will be particularly crucial in this respect.

CBK’s expectations of overall system performance include:

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

43

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

minutes.

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

f) CBK’s general availability expectation for this system is 99.95% (where downtime

is defined as total unavailability of the service). Bidder are requested to give details

of expected reliability and availability figures for the actual configuration

(hardware, software etc.) they are proposing.

44

PART 2 – REQUIREMENTS MATRIX AND EVALUATION GUIDE

The tenderer must respond to every stated request or requirement and indicate that

they confirm acceptance of and understand the CBK’s stated requirements. The

deferral of a response to a question or issue to the contract negotiation stage is not

acceptable. Any item not specifically addressed in the Vendor’s proposal will be

deemed as accepted by the Vendor.

Responding to the List of Requirements

Tenderer must respond to each requirement contained within this RFP using the

following criteria. Tenderer’s responses must be in the same order in which the

questions appear and must use the same numbering scheme as outlined below:

FP Fully Provided (Out-of-the-box), Solution currently includes this capability in its current general software release.

TP Third Party Software Required Third party solutions is required to deliver this capability

M Modification to existing software Minimal modification is required to provide the requirement

C Custom Development Required Custom development required for the requirement

NA Not Available Functionality is not available (Out of the box)

O Other Other

For any specifications to which the Vendor answers other than FP (Fully Provided),

Bidder must describe:

• Whether the CBK will incur any additional cost for the feature, function, product, or

service once it becomes available other than the cost of maintaining a valid software

maintenance agreement for the current modules/system proposed by the Bidder as

part of the initial installation (i.e. a new module, replacement or upgrade to an

existing module, new hardware required, etc.)

• If the feature, function product or service falls under the category as Not Available

(N), the Bidder may provide; (a) an explanation of how the specification might be

met using alternative methods within the system or (b) if it is available from a third

party partner. Either explanation must include availability dates and additional

costs, either direct or indirect.

45

Item Ref. Information Technology Requirements, Project Management etc

Item Score

Evaluation Factor

Weighted Score

Response (FP, TP, M, C, NA, O)

C. 1. General Requirements 10

q) Can your product be maintained on a client’s own

server? What database system (i.e., SQL, Oracle,

etc.) does your system use?

r) Identify the most current version of the software.

Detail the percentage of live customers that are

utilizing the proposed version of the software.

Please provide a breakdown of customers (by

percentage) for each version of the software

currently in use.

s) Please describe any modules or add-ons that you

offer for your software.

t) Describe how often a client should upgrade the

software including what the trigger or decision

point is for upgrading/changing the system, and

if there is an associated cost.

u) How many environments are supported in the

basic offering for a client? Is a development

46

version of the system available to clients for

testing?

v) Are the error messages produced by your system

in plain English, and do they contain a specific

reason for the occurrence of error?

w) Does the system have an aging report which

shows how long an outstanding item has

remained in the system? Can this be customised to

define the red CBK preferred line?

x) Describe the End of Day process.

C. 2. Integrity 3

e) Describe features of system that guarantee zero

data loss especially during recovery from

unplanned outage

f) What privacy methods used to ensure that

confidential Data and sensitive communications

are kept private?

C. 3. Security, authentication, access and audit 7

q) What security tools are included with the software?

How does your application restrict access to the

following: administrative tool access, application

47

access, menu access, record access, field access and

querying/reporting access?

r) Does your system maintain audit trails of all

changes to pricing methods, risk models and any

other administrative changes that would affect the

calculation or reporting of investment transactions?

s) Does the system provide capability to administer

user and group security permissions for access to

software solution

t) Does the system support integration with

Microsoft Active Directory? List other directory

servers supported.

u) Does the system support role-based access?

v) Does the system support complex passwords? Can

the administrator set / change the level of

password complexity required?

w) Does the system provide facility to disable / enable

a user account?

x) Does the system have capability to provide audit

trails, logs, history tracking and reports for user

48

activity such as authentication, data access inserts,

updates and deletions etc.

y) Provide detailed solution architecture for the

proposed system highlighting the required

interfaces and technology platforms

z) Does the system provide classification of log events

into following classes: Errors, Warning,

Information, Debug and Trace?

aa) Does the system restrict access to system logs to

only authorized users?

C. 4. Operational Requirements 5

h) Describe the system features for meeting workload

processing demands

i) Describe the scalability features of the system

j) Does your system provide the client with the

ability to use monitoring statistics to verify that

functionality is available? Please provide a list of

monitoring software partners.

C. 5. Infrastructure Requirements 7

49

h) Please describe the technical resources which

support the platform and their physical locations

and time zones supported.

i) Identify the operating system required by the

proposed applications software and database

management system. In the event there is more

than one suitable operating system, list all options

indicating the relative strengths and drawbacks (if

any) of each.

j) Provide the ideal database platform choices for the

proposed software. In the event that there is more

than one suitable database platform, please list all

options.

k) Is the Oracle 12c Database Platform supported?

l) Is the system supported on three (3) site

configuration – primary, backup and disaster

recovery – where is replicated to all sites. CBK uses

two or three application environments. Generally,

these are Production, Test and Development. These

are used for, testing application patches, testing

configuration changes, testing security patches,

user acceptance of new functionality, isolated fault

finding analysis, user training, other application

integration testing i.e.

50

C. 6. Business Continuity 10

g) Does the system support clustering and high

availability?

h) Describe systems backup process for the proposed

system.

i) Describe the disaster recovery features for the

proposed system

j) What is the estimated down time for the fail over

to the backup or disaster recovery system?

k) Is the system able to run in load balanced

environment?

C. 7. System Interfaces and Customizations 10

m) Does your system have pre-built data feeds into

Bloomberg for market data, security definitions

and market data?

n) Does your system have pre-built data feeds into

Refinitiv (Reuters) Platform for market data and

trade tickets? If so, please describe including any

system limitations and/or issues with the process.

o) Does the system have capability to consume

RESTful and SOAP web services?

51

p) Does the system have capability to interface to

common Portfolio Management Systems?

C. 8. Implementation, Maintenance and Support 15

k) Provide the standard timeframe for a fully

implemented system per the scope of this RFP. If

the proposal contains a phased approach, provide

typical duration(s) for each phase and a listing of

the modules proposed for each phase. The phases

include: Scope review, Business Analysis,

Installation and Configuration, User Acceptance

Testing, Data Migration, Go-Live, etc.

l) What implementation methodology do you

typically use for system implementations? Agile

or SDLC

m) What approach do use for conducting the business

analysis / scoping?

n) Describe the implementation methodology /

lifecycle / activity sequence for a typical

implementation of the package from project

initiation through to warranty.

Customizations, Upgrades and Release Management

52

o) What is the process of identifying and

implementing system customizations / change

requests?

p) Describe the release process that is followed

including the frequency of releases and versioning

q) Describe the release nomenclature (i.e. minor,

major releases)

r) Describe the methodology for issue and problem

management. What tools are used to support this

process.

s) If a client encounters system issues that must be

resolved with a software patch, are software

patches supplied by you or does a client have to

wait until the next software release?

C. 9. Project Team 8

l) Describe your project organization structure and

assigned project staff. Describe the skills,

experience, and roles and responsibilities for each

project team member and their location (on-site,

offsite, offshore).

53

m) Describe the resource requirements (include

onsite, off site and offshore resources) for the

typical implementation of the base package.

Provide the estimated time of the resources on the

project.

n) Describe the process of identifying contingency

resources when the primary are unavailable for

the project implementation

o) Describe your expectation of the structure and

composition of the CBK project team

Training

10

p) Describe your technical, functional and end-user

training program(s) you provide. Indicate the

delivery location (onsite or offsite) and duration of

training

q) Do you provide both end-user and technical

documentation?

r) Do you provide custom training tailored for

specific needs or group of users?

Support

54

s) Describe the customer service/support that you

provide. What is the typical response time for

client requests?

t) Which locations is support is available (local,

EMEA and/or global)?

u) Describe your levels of support programs. Does

your company provide guarantees on software

performance or support Service Level Agreements

(SLAs).

v) Please list the number and type of personnel

resources that are necessary to support ongoing

operations of your system and/or system modules

as dictated by system design.

C. 10. Project Management 15

c) Provide / describe your project management

methodology / plan

d) Provide a matrix of “roles and responsibilities” for

each major activity and task contained within the

proposed implementation plan.

C. 11. Licensing 5

g) What is the licensing metric used for the system –

per user, per Server, per module?

55

h) Is the licence perpetual or periodically (annual)

renewed?

i) Do the testing and development instances require

a separate license?

j) Is the disaster recovery instance licensed

separately?

k) Do you have third party products or tools that

need to be licensed separately? Provide the list?

l) Describe how you ensure that third-party

products are licensed?

C. 12. Data Backup 5

g) Does the system have capability to archive data

based on user defined parameters such as date

range?

h) Does the system have capability to schedule

backup or manually initiate back up process?

i) Does the system have ability to automatically

synchronise data with disaster recovery site (or

system)?

56

j) Does the system have capability to restore backups

to a point in time?

Total Score

Total Raw Weighted Score: (sum of Raw Weighted Scores above)

𝑻𝒐𝒕𝒂𝒍 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆

𝑴𝒂𝒙𝒊𝒎𝒖𝒎 𝑷𝒐𝒔𝒔𝒊𝒃𝒍𝒆 𝑹𝒂𝒘 𝑾𝒆𝒊𝒈𝒉𝒕𝒆𝒅 𝑺𝒄𝒐𝒓𝒆 𝑿 𝟑𝟎 = 𝑺𝒄𝒐𝒓𝒆

APPENDIX A: LIST OF INVESTMENT INSTRUMENTS

7. Money Market

7.1. Time Deposits

7.2. Certificate of Deposits

7.3. REPOs, Reverse REPOs & Securities Lending

7.4. Commercial Paper

7.5. Treasury bills

7.6. Cash / Demand Deposit

8. Fixed Income

8.1. Sovereign Notes / Bonds – Fixed and Floating

8.2. Sovereign Agency Notes/ Bonds – Fixed and Floating

8.3. Corporate Bonds

8.4. Emerging Market Bonds

8.5. Local / Regional Government Bonds

8.6. Ex-Div Bonds

8.7. MBS

8.8. ABS

8.9. SOFR Linked Bonds

9. Gold

10. Derivatives

10.1. FX Forward Outright

10.2. FX Swaps

10.3. Dual Currency Deposits

10.4. Futures

10.4.1. Interest Rate Futures

10.4.2. Bond Futures

11. Equities

Appendix B: Application Interfaces

Interface Name Direction Interface Technology (Middleware)

Interface Data and Descriptions

11. Bloomberg 2-way Fix Messages / API

Bloomberg to IRMS

i) Security Prices j) Exchange Rates k) Fixed Income Trades l) FX Trades m) Money Market Trades n) Index Compositions o) Index Returns p) Security Definitions

12. Portfolio Management and Transaction Processing (PMTP)

1-way API / Database PMTP to IRMS

e) Positions f) Cash g) Reference data

13. Enterprise Directory Server ( Microsoft Active Directory)

2-way TCP Port IRMS to Active Directory

c) User Authentication Request d) User Creation Request

ANNEX C

INTERNATIONAL TENDER FOR SUPPLY, DELIVERY, TESTING AND COMMISSIONING OF PORTFOLIO

MANAGEMENT AND TRADE PROCESSING SYSTEM (PMTP) AND INVESTMENT RISK MANAGEMENT SYSTEM

(IRMS)

REF. NO. CBK/25/2020/2021

CONTRACT FORM The Central Bank of Kenya (CBK) expects the Offeror to submit its proposed reserves management system contract terms and conditions as well as the support and maintenance services contract terms and conditions along with its technical proposal for review and acceptability by the CBK. It is expected that the proposed reserves management system contract and the support and maintenance service contract of the selected Offeror will be subject to discussion and negotiation prior to the contract award and execution. It is expected that the signatories and parties executing the resulting reserves management system contract will be the Offeror and the CBK. With respect to the contractual elements in the matrix below, the bidder is required to provide a response to each of the items. The Bank is open to negotiating all the contractual terms in the RMS Agreement. However, due to legal and regulatory constraints, the Bank will hold some contractual provisions as non-negotiable. The non-negotiable provisions are indicated as such in the matrix. As part of the discussions on the proposed system agreement, the CBK will expect the service provider to address within its provisions the following items including, but not limited to:

2

No. Provision / issue Proposed minimum standard / proposed discussion

Is the offeror willing to negotiate (tick applicable column)

YES NO

1. Warranty/standard of goods and services

The Service Provider will provide a warranty that the procured goods and services are fit for use in keeping with international best practice and provide a warranty

2. Sovereign Immunities The CBK will preserve its sovereign immunities – Non-Negotiable

3. Dispute Resolution We would prefer to allow for non-exclusive jurisdiction of courts

4. Applicable/Governing Law

Kenyan law or the law of England and wales

5. Limitation of liability The service provider will not limit liability for loss due to intention, fraud or negligence of the service provider or its agents.

6. Indemnities Indemnity obligations will apply equally to both parties

7. Consequential Damages No party will be liable for consequential damages

8. Termination Notice The Service Provider will give notice of not less than 180 days of its intention to terminate the contract – except for termination due to a force majeure event

3

No. Provision / issue Proposed minimum standard / proposed discussion

Is the offeror willing to negotiate (tick applicable column)

YES NO

9. Software held in Escrow The service provider will consent to surrender the software to be held in escrow by a party to be agreed upon by both parties

10. Assignment /sub-contracting

The Service provider will not assign or subcontract its rights and obligations under the contract in any manner whatsoever without the Bank’s express written consent

11. Advertising Restrictions (Sovereign’s Name/Logo, etc.)

Neither party will advertise or announce the contractual relationship without the others’ written consent, which consent will not be unreasonably withheld

12. Insurance Requirements The Service provider will

have in place adequate

relevant insurance

including professional

indemnity for its personnel

to ensure uninterrupted

delivery of its obligations

under the contract

13. Force Majeure Whatever force majeure events as may be defined under the contract will apply equally to both parties

14. Technical and financial Proposal

The procurement laws in Kenya stipulate that the

4

No. Provision / issue Proposed minimum standard / proposed discussion

Is the offeror willing to negotiate (tick applicable column)

YES NO

bidder’s technical and financial proposal automatically form part of the contract. We will therefore require the contract to specifically mention that the technical and financial proposal are part of the contract

15. Annual maintenance and support Services

Please confirm that you are also willing to enter into an annual support and maintenance service contract with the Bank for the RMS