CONTENTS
REQUEST FOR PROPOSAL
ANTI MONEY LAUNDERING SOLUTION
CBKL/RC/AML/15 - 1
TABLE OF CONTENTS
31SECTION 1 – REQUEST FOR PROPOSALS
1.1Introduction3
1.2Instruction to Bidders3
2SECTION 2 - TERMS OF REFERENCE7
2.1Requirements8
3SECTION 3 - GENERAL CONDITIONS OF CONTRACT10
4SECTION 4 – ANNEXURES12
SECTION 1 – REQUEST FOR PROPOSALS
1.1 Introduction
This document constitutes the formal Request for Proposals (RFP)
for the implementation of an Anti Laundering Solution for the
Bank.
1.2 Instruction to Bidders
1.2.1 Purpose
Objectives of the proposal are listed in section 2. The bidder
shall include in their offer any additional services considered
necessary for the successful achievement of the objectives.
1.2.2 Proposals
Proposals from bidders should be submitted in two distinct
parts, namely technical proposal and financial proposal and these
should be in two separate sealed envelopes, both of which should
then be placed in a common sealed envelope marked
“CBKL/RC/AML/15-1”
DO NOT OPEN BEFORE 20thJuly 2015 at 12.00 Noon.
The two separate inner envelopes should be clearly marked
“Technical Proposal”, and “Financial Proposal”, respectively, and
should bear the name of the Bidder.
a. The Bidder shall prepare original and 1 (one) hard copy of
the bid, clearly marking each “ORIGINAL BID” and “COPY OF BID,” as
appropriate. In the event of any discrepancy between original and
the copy, the original hard copy shall govern.
b. Valid only if initialed by the people signing the bid.
1.2.3 Technical Proposal
The Proposal should contain the following:
a. Executive Summary
b. Profile of the firm.
c. Vendor Information
d. General Product Requirements
e. Understanding of Bank Requirements
f. Proposed Solution
g. Functional Requirements
h. Technical Requirements
i. Technical Architecture
j. Hardware & Software Requirements
k. Implementation & Support
l. Project Plan & Schedule
m. Project Implementation Methodology
n. Help Desk & Support
o. Additional Requirements
p. Eligibility Documentation
q. Proof of Bidder engaged in implementing at least 10 projects
globally
r. Proof of Bidder having director support offices in Kenya
s. Client References
1.2.4 Evaluation of bids
A two-stage procedure will be adopted by the Bank for evaluating
the proposals, with the technical proposals being evaluated prior
to the financial proposals. Technical proposals will be evaluated
based on the following general areas:
STAGE I: Functional & Technical Evaluation
In this stage, the evaluation would be made separately for each
of the four sections described hereunder:-
· Functional features. (M1)
· Technical features. (M2)
· Vendor and Product Details (M3)
· Product Implementation & Support (M4)
STAGE II – Product Demo / POC / Site Visit
The vendors qualifying in stage I as per the procedure
prescribed hereinabove shall become eligible for evaluation in
stage II (POC). In stage II, vendors would be asked to do POC on
Bank’s data. Selected Technical functionalities/ capabilities would
be evaluated in this stage.
1.2.5 Bid Validity Period
Bidders are requested to hold their proposals valid for one
twenty (120) days from the closing date for the submission.
1.2.6 Documents Comprising the Bid
The bid submitted by a Bidder shall comprise the proposal to the
requirements. Each bid shall include only one technical and one
price/financial solution.
1.2.7 Cancellation of the bidding process
The Bank reserves the right to accept or to reject any bid, and
to annul the bidding process and reject all bids at any time prior
to the award of the contract, without thereby incurring any
liability to any Bidder or any obligation to inform the Bidder of
the grounds for its action.
1.2.8 Cost of bidding
The Bidder shall bear all costs associated with the preparation
and submission of its bid, and the Bank will in no case be
responsible or liable for those costs, regardless of the conduct or
outcome of the bidding process.
1.2.9 Clarification of Bidding Document
All correspondence related to the contract shall be made in
English. Any clarification sought by the bidder in respect of the
project shall be addressed at least three (3) days before the
deadline for submission of bids, in writing to the Tender
Committee
The queries and replies thereto shall then be circulated to all
other prospective bidders (without divulging the name of the bidder
raising the queries) in the form of an addendum, which shall be
acknowledged in writing by the prospective bidders.
Enquiries or clarifications should be sent by e-mail to:
[email protected]
1.2.10 Amendment of Bidding Document
At any time prior to the deadline for submission of bids, the
Bank, for any reason, whether at its own initiative or in response
to a clarification requested by a prospective Bidder, may modify
the bidding documents by amendment.
All prospective Bidders that have received the bidding documents
will be notified of the amendment in writing, and it will be
binding on them. It is therefore important that bidders give the
contact correct details at the time of collecting/receiving the bid
document.
To allow prospective Bidders reasonable time to take any
amendments into account in preparing their bids, the Bank may at
its sole discretion extend the deadline for the submission of bids
based on the nature of the amendments.
Deadline for Submission of Bids
Bids must be delivered on or before 20thJuly 2015, 12.00 noon
to:
The Chairman,
Tender Committee,
Consolidated Bank of Kenya Limited,
6th Floor, Consolidated Bank Building,
P.O. Box 51133 - 00200
Nairobi, Kenya
Bids sent by mail should reach by the same deadline. Bids
received after the above-specified date and time shall not be
considered.
Bids will be opened in the presence of a maximum of one
representative from each bidder who chooses to attend at 12.00 noon
on the same day on 6th Floor, Consolidated Bank Building
1.2.11 Bid Price
The Bidder shall, in their offer (Financial Proposal), detail
the proposed fee structure for the contract with the Bank.
The fee should be a Fixed Lump Sum Fee but with sufficient
elemental breakdown. The summary of the bid price will be recorded
in the Bid Price schedules as included in annexes 4.2.
No price escalation under this contract shall be allowed.
Taxes and Incidental Costs
The prices and rates in the financial offer will be deemed to be
inclusive of all taxes and any other incidental costs and overheads
but exclusive only of Value Added Tax (VAT), which shall be
computed and indicated in the price schedule.
Responsiveness of Proposals
The responsiveness of the proposals to the requirements of this
RFP will be determined. A responsive proposal is deemed to contain
all documents or information specifically called for in this RFP
document. A bid determined not responsive will be rejected by the
Bank and may not subsequently be made responsive by the Bidder by
correction of the non-conforming item(s).
Currency for Pricing of Tender
All bids in response to this RFP should be expressed in Kenya
Shillings. Expressions in other currencies shall not be
permitted.
Correction of Errors.
Bids determined to be substantially responsive will be checked
by the Bank for any arithmetical errors. Errors will be corrected
by the Bank as below:
a. where there is a discrepancy between the amounts in figures
and in words, the amount in words will govern, and
b. where there is a discrepancy between the unit rate and the
line total resulting from multiplying the unit rate by the
quantity, the unit rate as quoted will govern.
The price amount stated in the Bid will be adjusted by the Bank
in accordance with the above procedure for the correction of
errors.
Evaluation and Comparison of Bids
Technical proposals will be evaluated prior to the evaluation of
the financial bids. Financial bids of firms whose technical
proposals are found to be non-qualifying in whatever respect may be
returned unopened.
SECTION 2 - TERMS OF REFERENCE
1. EXECUTIVE SUMMARY
Bank Profile
The Bank plans to implement an anti money laundering solution in
it’s endavor to comply with regulatory requirement for the
monitoring and reporting of suspicious transactions to the
Financial Reporting Centre. The solution deployed should be in line
with the Kenyan regulatory anti money laundering requirements as
prescribed from time to time. The solution will need to be upgraded
by the Vendor in the event of any changes /modification / new
regulatory requirements or reporting requirements which warrants
the Bank’s compliance. The solution would need to be interfaced to
the Core Banking System and other third party solutions to meet the
business requirements.
The purpose of this RFP is to obtain competitive proposals for
solutions that meet the AML compliance requirements. The AML
solution deployed should meet the requirements as listed in
· Vendor and General Product Requirements
· Functional & Additional Requirements
· Technical Requirements.
· Implementation & Support.
2. SCOPE OF WORK
Eligibility Criteria
Only such selected Vendors who fulfil the following criteria are
eligible to respond to the RFP. Offers received from Vendors who do
not fulfil any of the following eligibility criteria are liable to
be rejected.
1. Vendor must be a legal entity.
2. Bidder should have been engaged / having experience in
implementing at least 10 AML projects globally.
3. Bidder must have direct local presence and support office in
Kenya
Proposal Format – Technical & Commercial
A TWO BID system offer would be followed where the bidder would
submit the Commercial and Technical Proposals in TWO SEPARATE
sealed envelopes on or before 1200HRS, 20th July 2015
Offers received after the last date and time specified for such
receipt will be rejected. All envelopes should be securely sealed
and stamped.
The Technical Offer (T.O) should be complete in all respects and
contain all information asked for, except prices. The Technical
Offer should not contain any price information. The Commercial
Offer (C.O) should give all relevant price information and should
not contradict the T.O. in any manner.
Technical and Commercial Offers must be submitted separately, in
different envelopes. It may be noted that if any envelope is found
to contain both technical and commercial offers, such offer will be
rejected.
The Table below lists the Proposal format to be used for
submission -
Sl.No
Proposal Format Checklist
1
Executive Summary
2
Company Profile
3
Vendor Information - Annexure 1
4
General Product Requirements - Annexure 2
5
Understanding of Bank Requirements - Scope of Work
6
Proposed Solution
7
Functional Requirements - Annexure 3
8
Technical Requirements - Annexure 4
9
Technical Architecture
10
Hardware & Software Requirements
11
Implementation & Support - Annexure 6
12
Project Plan & Schedule
13
Project Implementation Methodology
14
Help Desk & Support
15
Additional Requirements - Annexure 5
16
Eligibility Documentation
17
Proof of Bidder engaged in implementing at least 10 projects
globally
18
Proof of Bidder having director support offices in Kenya
19
Client References
The Commercial Proposal must include the following details
· Bill of Materials
· Total Cost of Ownership
· Annual Maintenance Cost (AMC) charges
Note:
· The Vendor is expected to quote all components & services
as part of the commercial bid inclusive of all costs and taxes.
· The vendor will be entirely responsible to pay all taxes
including corporate tax, income tax, license fees, duties etc., in
connection with delivery of the solution at site including
incidental services and commissioning.
3. TECHNICAL SPECIFICATION
ANNEXURE 1
Sl.No
Vendor Information
Vendor Comments
Company Information
1
Provide details on company background
2
Total number of employees
3
Turnover details ( Last 3 years)
4
Total number of office locations (world-wide)
5
Office Presence in Africa
6
Year company was established
7
Number of products (IPR's) the vendor has in the BFS space.
AML Credentials
8
When was the AML product launched?
9
Number of core banking systems that the solution has interfaced
with
10
Number of countries in which the product has been
implemented
11
Does the vendor publish AML Newsletters / Whitepapers?
ANNEXURE 2
Sl.No
General Product Requirements
Vendor Comments
1
Please provide the following details for each application
software product proposed: • Product name. • Version release number
& year of release
2
What programming language(s) is the system written in?
3
Total number of completed (live) installations in AML
4
List any 2 reference sites in Africa
5
List any 3 reference sites globally
6
Scalability – Specify average daily transaction volume handled
by AML system at Largest Customer.
7
The proposed solution should be the vendors own IPR. Yes/No
ANNEXURE 3
Sl.No
AML Functionality Requirements
Requirement Criticality (Critical/ Nice to Have)
Availability (A/ PA/ RM/ NA)
Vendor Comments
Anti-Money Laundering Regulation Requirements
1
The system should comply with local FRC requirements and CBK
Prudential guideline on KYC AML & Combating Terrorism
Financing
Critical
2
The system should address and be compliant with the
recommendations laid down by FATF
Critical
Know Your Customer Requirements
3
System should capture all the Due Diligence Information of the
customer base of the institution. It should also capture Due
Diligence data on Beneficiaries and connected parties.
Critical
4
System should provide for capturing customer due diligence
details like source of funds, expected nature and level of activity
in the account, expected origin of the funds into the relationship,
details of occupation / employment of the customer
Critical
5
Where the respective core banking system does not have
provisions to capture the KYC information, the AML software should
provide facilities to enter the missing data – Data Enrichment
Nice to have
6
The system should validate the CIF data and warn the user for
missing data elements.
Nice to have
7
System should manage blacklists provided by regulatory
authorities such as the lists provided by FRC, OFAC, List issued
time to time by the law enforcement agencies, PEP lists, UN
Sanctioned list etc. It should also be possible to add new lists as
and when they are introduced in future.
Critical
8
Support for list scanning of account/customer database against
watch lists – incremental screening should take place if there are
any updates to the watchlist data or the customer data.
Critical
9
Bank should be able to create watch lists of customers &
non-customers. Batch upload of customized lists should be possible.
Changes to this watch list should also be tracked, with complete
audit trail.
Critical
10
The AML system should provide a list manager that will be used
to manage various lists like OFAC-SDN and Politically Exposed
Peoples (PEPs). Users should be able to maintain internal
Watch-lists to monitor their customers.
Critical
11
Bank should be able to reduce false positives by creating a
white list in which user can add customers who have matched with
lists but are not deemed suspicious i.e. support for exclusions of
names to avoid multiple false hits
Critical
12
Support for advanced search techniques like Phonetic and Fuzzy
Logic in Name search
Critical
13
The AML system should enable the user to refine the search
criteria from Exact Match to Similar Sounding, Partial Name Search,
Initials Search, and Sub String search.
Critical
14
The system should be able to manage false hit results from the
list screening process.
Critical
15
The system should have the flexibility to define the mandatory
customer fields to be captured by combination of account type &
customer type
Nice to have
16
KYC Gap - Mandatory Fields Missing Report should provide details
of account wise missing data which has not been captured in the
system.. The report should display the names of those customers,
which have not provided any specific mandatory information about
themselves to the BANK.
Critical
17
KYC Mandatory fields missing Report should be generated
Critical
18
All new customers as well as existing customers should be
checked against blacklists, watch lists and white list.
Critical
19
System should be able to trace direct and indirect links between
customers in the bank
Critical
20
The user should also have a provision to search for Duplicate
Data regarding a customer to check for multiple accounts (hidden)
for a customer within a bank.
Critical
Link Analysis
21
The AML system should provide a Link Tracer that defines and
tracks a multitude of relationships between customers. The Link
Tracer should enable the compliance officer to analyze the
complexity of a relationship and associations
Critical
22
Option to view customer and account/portfolio details on right
click
Critical
Customer Profiling
23
Describe how the AML software provides the ability to create
accurate, verifiable, compact customer baseline profiles from
historical data as well as from initial data obtained at the
inception when account is opened.
Critical
24
The solution should validate customer’s current activity with
these profile patterns to identify unusual or deviant
activities.
Critical
25
Transaction Monitoring should be a combination of rules defined
and profile deviations
Critical
26
Transaction attributes like value, frequency, time, channel,
instrument, channel, instrument, branch etc. should be analyzed by
the system to build multi-dimensional profiles.
Critical
Risk Categorization
27
System should be able to categorize accounts into risk
categories in a flexible manner in accordance to the above acts,
FRC directions, the Bank concerned and internationally recognized
best practices.
Critical
28
Provide a detailed note on the Risk Rating mechanism /
functionality
Critical
29
The risk rating should be based on both customer and
account/portfolio related parameters. Specify the parameters/
factors used.
Critical
30
Factors/ Weightage should be user configurable by the bank
Critical
31
The solution should support risk profiling of customers based on
country of origin, country of residence, occupation, STR filed,
customer type, account type, KYC gaps etc.
Critical
32
The system should provide a risk over-ride capability with admin
having the option to manually set the risk
Critical
33
The system should support reassessment of customer risk-. Risk
Assessment Reports should be provided
Critical
34
Risk Dashboard should be displayed view month wise change in
risk profile of customers
Nice to Have
Benchmarking
35
The AML system should allow for benchmarks to be fixed based on
the general behaviour of entities (Customers, Products etc.). The
Default Benchmarks should be definable in the AML system for all
customers based on the Customer Category and the Amount range in
which they are operating. The user should be able to create, and
even edit an existing benchmark.
Critical
36
Visual Benchmarking - The Visual benchmarking tool should enable
the AML officer to assess the number of alerts that would result
based on specified thresholds given for an alert and the
transaction amount ranges.
Optional
Transaction Monitoring
37
The system should provide rule based suspicious transaction
identification.
Critical
38
The system should have the ability to update above rules
incorporating new scenarios of suspicious transactions
Critical
39
The system should have alert scenarios for individual
transaction as well as historical transactional behaviour
Critical
40
The system should have provision to define multiple benchmarks
for alert scenarios based on customer type, nature of business,
branch, country& account/portfolio risk.
Critical
41
The system should have provision to create user defined
rules
Critical
42
The system should be able to schedule the frequency of the
alert
Critical
43
The system should enable user to effectively manage alerts
generated from the time of generation till such time an appropriate
action is taken
Critical
44
The Suspicious Transaction Reporting (STR) in the solution
should be auto populated in line with FRC requirements.
Critical
45
Regulator defined formats for STR; CTR may change from time to
time. This should be handled by the vendor and provided as part of
AMC.
Critical
Alerts Management
46
Any/all actions taken by the investigating officer should be
recorded in the system.
Critical
47
The user should be able to view details of all alerts fired on
customer as well as all the necessary transactional details with
respect to the specified customer.
Critical
48
The system should support alert justification recognition i.e.
the user should be able to ascertain the reason behind the
alert
Critical
49
The system should have facility to manage false positives.
Critical
50
It should be possible to re-run any rule at any time and “as-of”
any past date.
Critical
51
Audit trail of rule-changes to be maintained and system /
product limitations of user-rules, if any, to be mentioned as a
footnote.
Critical
52
The system should provide the user the option to drill down into
the details of the transaction on which the alert was
generated.
Critical
53
The system should have provision for resource allocation &
work load balancing for alerts assignment
Critical
54
The user should have the facility of filtering alerts based on
parameters such as time, customer, product and alert type
Critical
55
The system should have the feature to prioritize alerts
Critical
56
Module for Alert Assignment to be available in the system.
Critical
57
The AML system should allow the users to pre-assign alerts to
single or multiple users.
Critical
58
Reports should also provide information to management on the
alerts status.
Critical
59
The system should have complete audit trail of the alert
generated.
Critical
60
Option to forward/mail alerts should be available
Critical
Suspicious Transaction Scenarios
61
Sudden surge in activity level for account/client– value
Critical
62
Sudden surge in account/client volume
Critical
63
Transactions below reporting limit for client
Critical
64
New account opening followed by quick withdrawal- account level
& client level
Critical
65
Repeat deposits above given threshold for account or client
Critical
66
Consecutive withdrawal transactions for account
Critical
67
Fund in fund out/ cash in cash out
Critical
68
High value transactions with a country with high ML risk
Critical
69
Deposit above given threshold for account/ client
Critical
Nice to have
70
Cash withdrawal above given threshold for account/ client
Nice to have
71
Transactions in dormant account
Critical
72
New account opening followed by quick deposits of substantial
sums
Critical
73
Large cheque deposit above a given threshold
Nice to have
74
Transaction above given threshold for account/ client
Critical
75
Transactions deviating from net worth / income
Critical
76
Many to One Fund Transfer or One to Many Fund Transfer
Critical
77
Transaction involving a country with high TF risk
Critical
78
Multiple Accounts with common name and address
Critical
79
Repeated small value inward remittance from unrelated parties
followed by immediate ATM withdrawals
Nice to have
80
High value cash transactions inconsistent with profile
Critical
81
Manual Alerts – These alerts should be primarily based on
observations made by the Relationship Manager, user or any other
employee of the BANK. The AML system should allow the BANK to
parameterize subjective alerts based on requirements and to modify
and add alerts as and when required
Critical
82
Customers matched with names under watch lists
Critical
83
Credit transaction exceeding the declared/accepted profile
Critical
84
Unusual activity in Overdraft accounts
Critical
85
Accounts turnover breaching threshold limit
Critical
86
Only cash transactions in newly opened accounts
Critical
87
Common beneficiary for incoming payments
Critical
88
Cash deposits to numerous accounts under same base number
Critical
89
High cash transactions ratio in corporate accounts
Critical
90
Cash in cash out matches
Critical
91
Transactions in high risk accounts
Critical
92
Credits greater than principal for Loan accounts
Critical
93
Frequent Foreign exchange transactions
Critical
94
Loan Repayment from account not associated with the contract
Critical
95
Loans sanctioned to high risk Customers
Critical
96
Unusual interest rates on loans and fixed deposits
Critical
97
Predominant cash transactions in an account
Critical
98
Multiple credits same counterparty
Critical
99
Transactions in Minor accounts
Critical
100
Blocked account report
Critical
101
Large foreign exchange Credits & Debits
Critical
102
Funds in funds out (transfers)
Critical
REPORTS
103
List Screening Report ( Match with UN, OFAC, Internal Lists) for
new & existing customers
Critical
104
Transaction Report
Critical
105
Audit Log Report
Critical
106
Transactions in High Risk Currencies/ Countries
Critical
107
Transactions in Watched Account
Critical
108
Customer Comprehensive Report
Critical
109
List of Dormant Accounts
Critical
110
KYC Gap Report
Critical
111
Frequent Change In Address/ Important Information
Critical
112
Duplicate Data Report
Critical
113
Blocked accounts report
Critical
114
Alert Statistics Report
Critical
115
Risk Update Report
Critical
Analysis and Reporting Requirements
116
The system should have reporting capabilities as defined by the
Regulator / FRC
Critical
117
Describe and List the MIS reports that come with the System.
Critical
118
Should provide the capability to export data to other
systems.
Critical
119
Should have the ability to produce reports detailing the entire
history of the account in question.
Critical
Case Management
120
Solution should provide complete and comprehensive case
management module with facility to store alerts, emails and all
necessary information recorded by the surveillance officer to
substantiate the case should be present.
Critical
121
The system should support analytical capabilities for analysis
and investigation of cases
Critical
122
The case management utility should have provision to define
roles for the officers involved
Critical
123
Should be possible to prioritize cases according to predefined
rules in the case management system.
Critical
124
Multiple cases pertaining to the same customer must be linked
and reported
Critical
125
Option to reassign cases where needed by the administrator
should be provided.
Critical
126
The system should support entering comments and attach
supporting evidence, i.e. check image, list of transactions etc, to
the cases
Critical
127
Facility to attach / import external documents to case 'files',
including scanned images and word documents to be provided.
Critical
128
The system should have facility to escalate the case to next
level after completion of the role assigned to a user up to logical
conclusion of the case. Option to email to users should be
available
Critical
Security & Administration
129
Complete and comprehensive security from unauthorized access and
misuse should be available along with necessary audit trail
detailing every users activity.
Critical
130
System must have a Login ID and password for each user for
logging into the system.
Critical
131
Passwords must be kept encrypted in the database and should not
be visible using any source.
Critical
132
The number of levels / rights assigned to each level should be
user configured by the bank
Critical
133
Option to grant modular access to the different menu options and
fields to the different users should be configurable by the
administrator
Critical
134
System should provide Maker/Checker facility for critical
modules
Critical
135
Access to the system for all the users should be available only
through menu selection of the user interface.
Critical
Audit Trail
136
There should be a comprehensive audit trail detailing every
users activity.
Critical
137
Audit Logs should be generated in multiple formats – pdf, rtf,
xlsetc
Nice to Have
138
The system should have complete audit trail of the alerts
generated.
Critical
General Requirements
139
User dashboard should provide a status wise analysis of the
various alerts handled by the user – i.e. alerts that are open,
close, escalated, reviewed etc.
Critical
140
User Dashboard should provide a graphical as well as tabular
summary of the alerts generated in the system. Summary of alerts
generated on each customer, product, etc. to be provided
Critical
141
The system should provide a facility for printing every
report.
Critical
142
Should offer multi currency support
Critical
143
Should be possible to retrieve information as on a previous date
i.e., show the status of a customer as of a particular date.
Critical
ANNEXURE 4 – TECHNICAL & ARCHITECTURE REQUIREMENTS
Sl.No
Technical Requirements
Requirement (Critical/ Nice to Have)
Availability (A/ PA/ RM/ NA)
Vendor Comments
1
Describe the architecture of the solution– N-tier etc
Critical
2
Scalability across multiple hardware, operating systems and
database management systems.
Critical
HARDWARE
3
Recommend ALL server hardware for production, test and off-site
disaster recovery systems. Provide details of hardware
configurations, operating system software versions, and any
utilities required to run each of the systems.
Critical
Data Ingestion and Interfaces
4
The AML solution should have standard APIs to integrate with
other systems in the bank
Critical
5
System should have facility to accept/provide data in ASCII and
other standard formats from/for other systems
Critical
6
Support for the data ingestion in following formats:- CSV- XML-
Message Queues
Critical
7
Should have the ability to Integrate with sources like messaging
systems, SWIFT, Email, etc
Critical
8
Support password encryption
Critical
9
Support for data validation
Critical
Processing Requirement
10
The system shall support processing of an average of 100,000
transactions per day with 15% year on year growth
Critical
Security
11
Detail the security aspects of the application
Critical
Archiving
12
The system must maintain historic data before archiving it to
separate data files, in line with user defined retention
periods.
Critical
Application Architecture Details
13
Application System should be modular and should support modular
implementation.
Nice to Have
14
The proposed replication solution should support AIX, Solaris,
HP-UX Windows 2000, 2003, 2008 and Linux OS platforms
Critical
15
The proposed solution should be a storage agnostic solution
Critical
16
The proposed replication solution should be manageable through
Java GUI or a web based GUI
Critical
17
Provide details on DR and HA implementation of the system
Critical
18
The proposed solution should have option to integrate with High
Availability clustering software from SUN, IBM, HP, Microsoft .
Critical
19
Vendor/Bidder should provide extensive documentation related to
the Application S/W such as :
Critical
i. Application
Architecture
Critical
ii. Database layouts and
architecture.
Critical
iii. User/Operational Manuals
Critical
iv. System Reference Manuals
Critical
vi. Training Manuals
Critical
vii Additions / changes to the documents
after upgrades
Critical
viii Data Dictionary to be provided.
Critical
ANNEXURE 5 – IMPLEMENTATION & SUPPORT
Sl.No
Implementation and Support
Vendor Comments
1
Solution Implementation timeframe should be less than 12
weeks
2
Project Managers must have experience in delivering at least 3
successful implementations.
3
Product Delivery Team must have Business Analysts in AML/Anti
Fraud with > 4 years domain experience. Provide Implementation
personnel CVs
4
Number of support and implementation personnel in delivery
team
5
Detail Project Implementation Approach & Methodology
6
Detail Knowledge Management and Training Plan
7
Location of Support Center/ Office in Kenya/East Africa region /
South Africa
4. RESPONSE INSTRUCTIONS
The vendor should use the following codes to determine the
Compliance Level (CL) of each requirement.
S. No.
Code
Description
1
A -(Available/
Fully Supported)
The application fully supports the requirement without any
workarounds or modifications
2
PA - (Partially
Available)
The application supports the requirement with use of a system or
workflow workaround
3
RM - (Requires
Modification)
The application requires customization in order to support the
requirement
4
NA - (Not
Supported)
The system is not capable of supporting the requirement and
cannot be modified to accommodate the requirement
The response should specify one of the codes above along with
vendor comments that qualify the response. Where a requirement
contains multiple sub parts, vendor must provide response for all
sub points along with necessary comments.
The listed requirements are wide-ranging, but should not be
regarded as “knock-out” criteria. Where additional modules/packages
can be used to meet more of the listed requirements, these can be
included in the response, provided that they are clearly
differentiated from the core system, and associated costs and
interface issues are specified.
5. EVALUTION CRITERIA
On the basis of documents / Information submitted, the
Eligibility proof will be scrutinized firstly as per the terms
& conditions described in the RFP. The Technical offer will be
evaluated only for such vendors who have qualified in the
Eligibility Criteria prescribed by the Bank or any consultant
appointed by the Bank.
Technicals will be evaluated on the basis of following
criteria:-
The evaluation and award process shall comprise of following
three stages:-
STAGE I: Functional & Technical Evaluation
In this stage, the evaluation would be made separately for each
of the four sections described hereunder:-
Marks obtained in each section would be reduced to a factor of
100 respectively by the following scaling method:
Scaled Mark = (Total Marks Obtained/ Maximum Possible Marks) X
100
Weightage for calculation of Stage – I
50% of Scaled marks obtained for Functional features. (M1)
20% of Scaled marks obtained for Technical features. (M2)
15% of Scaled marks obtained for Vendor and Product Details
(M3)
15% of Scaled marks obtained for Product Implementation &
Support (M4)
Overall Stage 1 Marks = (M1*50+M2*20+M3*15+M4*15)/ 100
Based on Stage 1 marks, the vendors who have scored overall 70%
marks or more and at least 50% in each of the individual sections
will be considered as qualified for next stage i.e. Stage II.
STAGE II – Product Demo / POC / Site Visit
The vendors qualifying in stage I as per the procedure
prescribed hereinabove shall become eligible for evaluation in
stage II (POC). In stage II, vendors would be asked to do POC on
bank’s data. Selected Technical functionalities/ capabilities would
be evaluated in this stage. This stage would contain a maximum of
100 marks. The vendors scoring more than 80% in stage II shall get
qualified for final evaluation stage i.e. stage III.
Final Technical Score = ((Stage 1 Marks * 60) + (Stage 2 Marks
*40))/ 100
Stage –III FINANCIAL & FINAL BID EVALUATION:
Financial bids of those bidders who qualify stage II as per
prescribed percentage criteria will be opened for Stage-III. The
total cost of the project quoted by bidders will be considered for
calculation of financial marks. The commercial quotes shall be
calculated as:
Financial Score = (Minimum evaluated cost of any bidder/
Evaluated cost of bidder under consideration) *100
FINAL STAGE
Final score for Evaluation of bids shall be calculated as
under:
Final Score = (0.7 x Technical Score) + (0.3 x Financial Score)
where
Final Score = Overall evaluated marks (score) of Bidder under
consideration
Technical Score = Technical marks (score) for the Bidder under
consideration
Financial Score = Normalized financial marks (score) of the
Bidder under consideration
SECTION 3 - 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
Consolidated Bank of Kenya Limited and the Supplier, as recorded in
the Contract Form signed by both parties, including all attachments
and appendices thereto and all documents incorporated by reference
therein.
(b) “The Contract Price” means the price payable to the Supplier
under the Contract for the full and proper performance of all its
contractual obligations.
(c) “The Purchaser” means the Consolidated Bank of Kenya
Ltd.
(d) “The Supplier” means the firm or joint venture conducting
the Public Relations Services under this Contract.
(f) “The Public Relations Services” means all of the services to
be delivered by the Supplier under the Contract.
(g) “The Services” means those services associated with the
performance of “The Public Relations Services” assignment, as
defined in the Contract.
(h) “The Effective Date” means the date following contract
signing that the Contract enters into full force and effect with
respect to the scheduled dates for the Public Relations Services,
as specified in the Terms of Reference, and upon fulfillment of any
and all additional conditions specified in the contract.
(i) “The Project Manager” means the duly authorized Bank’s
representative, who shall manage and be responsible for fulfillment
of the Bank’s obligations, and shall oversee the Supplier’s
performance of the Contract.
(j) “The Project Plan” means the document to be developed by the
Supplier and approved by the Bank, based on the requirements of the
Contract and the preliminary project plan included in the
Supplier’s bid. Should the Project Plan conflict with the Contract
in any way; the relevant provisions of the Contract shall prevail
in each and every instance.
(k) “Acceptance” means the Bank’s written certification that,
the Advertising Services (or a specific part thereof) has been
verified as complete and/or fully operational as agreed in the
Contract.
3.2. Introduction
Specific terms of contract shall be discussed with the Supplier
whose proposal will be accepted by the Bank. The resulting contract
shall include but not be limited to the general terms of contract
as stated below.
3.3. Award of Contract
Following the opening and evaluation of proposals, the Bank will
award the Contract to the successful Bidder whose bid has been
determined to be substantially responsive and has been determined
as the best evaluated bid. The Bank will communicate to the
selected Supplier its intention to finalise the draft conditions of
engagement submitted earlier with his proposals. After agreement
will have been reached, the successful Supplier shall be invited
for agreement and signing of the Contract Agreement to be prepared
by the Bank in consultation with the Supplier.
3.4. Application of General Conditions of Contract
These General Conditions shall apply to the extent that they are
not superseded by provisions in other parts of the Contract that
shall be signed.
3.5. Bid Validity Period
Suppliers are requested to hold their proposals valid for ninety
(90) days from the closing date for the submission.
3.6. Non-variation of Costs
The prices quoted for the service and subsequently agreed and
incorporated into the contract shall be held fixed for the contract
period.
3.7. Delays in the Performance
a. Delivery and implementation of the evaluation shall be made
by the successful Supplier in accordance with the time schedule as
per Agreement.
b. If at any time during the performance of the Contract, the
Supplier should encounter conditions impeding timely delivery and
performance of the Services, the Supplier shall promptly notify the
Bank in writing of the fact of the delay, its likely duration and
its cause(s). As soon as practicable after receipt of the
Supplier's notice, the Bank shall evaluate the situation and may at
its discretion extend the Supplier's time for performance, with or
without liquidated damages, in which case the extension shall be
ratified by the parties by amendment of the Contract.
c. Except in the case of “force majeure” as provided in Clause
3.17, a delay by the Supplier in the performance of its delivery
obligations shall render the Supplier liable to the imposition of
liquidated damages pursuant to Clause 3.8.
3.8. Liquidated damages for delay
If the Supplier fails to deliver or if any of the deliverable
fails to gain Acceptance within the period(s) specified in the
Contract, the Bank shall, without prejudice to its other remedies
under the Contract, deduct from the Payment due to supplier, as
liquidated damages, a sum equivalent to the percentage of the
Contract price
(a)Applicable rate: 1% percentage of Contract Price for each
week of delay.
(b)Maximum deduction: 10% maximum percentage of Contract
Price
3.9. 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 also be in English.
3.10. Applicable Law
This agreement arising out of this RFP shall be governed by and
construed in accordance with the laws of Kenya and the parties
submit to the exclusive jurisdiction of the Kenyan Courts.
3.11. Implementation Services
a. The Supplier shall provide all Services specified in the
contract and the Terms of Reference in accordance with the highest
standards of professional competence and integrity. THE BANK
reserves the right to require the replacement of any Supplier staff
assigned to work on THE BANK’s site by suitably qualified staff, in
the event that the staff concerned is determined to be incompetent
or loses the confidence of THE BANK.
b. Prices charged by the Supplier for Services, if not included
in the Contract, shall be agreed upon in advance by the parties and
shall not exceed the prevailing rates charged by the Supplier to
other purchasers in Kenya for similar services.
3.12. Inspections and Acceptance
a. THE BANK or its representative shall have the right to
inspect and/or test the project to confirm their conformity to the
Contract specifications at any point of the project and/or at the
final delivery at no extra cost to the Purchaser.
b. Should any inspected or tested deliverable fail to conform to
the Contract specifications or to pass the Acceptance tests as
defined jointly in the Project Plan, the Purchaser may reject the
Process Improvements, and the Supplier shall either replace the
rejected deliverable or make alterations as necessary to meet the
specifications free of cost.
c. Nothing in Clause 3.13 shall in any way release the Supplier
from any warranty or other obligations under this Contract or limit
the BANK’s ability to seek other remedies as specified in the
Contract.
3.13. Supplier’s Obligations
a. The Supplier is obliged to work closely with the Bank's
staff, act within its own authority, and abide by directives issued
by the Bank that are consistent with the terms of the Contract.
b. The Supplier will abide by the job safety measures and will
indemnify the Bank from all demands or responsibilities arising
from accidents or loss of life, the cause of which is the
Supplier's negligence. The Supplier will pay all indemnities
arising from such incidents and will not hold the Bank responsible
or obligated.
c. The Supplier is responsible for managing the activities of
its personnel, or subcontracted personnel, and will hold itself
responsible for any misdemeanors.
d. The Supplier shall appoint an experienced counterpart Project
Manager for the duration of the Contract. The Bank’s shall review
the proposed manager’s credentials and must be satisfied with the
selection prior to the manager commencing work. This manager may be
replaced only with the prior written consent of the Bank. The Bank
may also demand a replacement of the manager if it is not satisfied
with the manager’s work or for any other reason.
e. The Supplier shall take the lead role and be jointly
responsible with the Bank for producing a finalised project plan
and schedule, including identification of all major milestones and
specific resources that the Bank is required to provide.
f. The Supplier will not disclose the Bank's information it has
access to, during the course of the project, to any other third
parties without the prior written authorisation of the Bank. This
clause shall survive the expiry or earlier termination of the
contract
3.14. The Bank’s Obligations
In addition to providing the Supplier with such information as
may be required by the Supplier to complete the Business Process
Improvement Project:
a. The Bank will appoint a Project Manager responsible for
managing the project, with the authority to accept or reject all
deliverables and to be the primary contact for the Supplier’s
Representative. The Project Manager will officially record all
delays and problems, and forward them to the Supplier within two
weeks of discovery of such problems.
b. The Bank shall be responsible for timely provision of all
resources, facilities, equipment access, and information necessary
for the completion of project implementation, as identified in the
agreed and finalized Project Plan.
c. The Bank will designate appropriate staff for the training
courses to be given by the Supplier, and shall make all appropriate
logistical arrangements therefore in accordance with the Project
Plan.
3.15. Confidentiality
The parties undertake on behalf of themselves and their
employees, agents and permitted subcontractors that they will keep
confidential and will not use for their own purposes (other than
fulfilling their obligations under the contemplated contract) nor
without the prior written consent of the other disclose to any
third party any information of a confidential nature relating to
the other (including, without limitation, any trade secrets,
confidential or proprietary technical information, trading and
financial details and any other information of commercial value)
which may become known to them under or in connection with the
contemplated contract. The terms of this Clause 3.13 shall survive
the expiry or earlier termination of the contract.
3.16. Force Majeure
Neither Supplier nor Bank shall be liable for failure to meet
contractual obligations due to Force Majeure.
Force Majeure impediment is taken to mean unforeseen events,
which occur after signing the contract with the successful bidder,
including but not limited to strikes, blockade, war, mobilization,
revolution or riots, natural disaster, acts of God, refusal of
license by Authorities or other stipulations or restrictions by
authorities, in so far as such an event prevents or delays the
contractual party from fulfilling its obligations, without its
being able to prevent or remove the impediment at reasonable
cost.
The party involved in a case of Force Majeure shall immediately
take reasonable steps to limit consequence of such an event.
The party who wishes to plead Force Majeure is under obligation
to inform in writing the other party without delay of the event, of
the time it began and its probable duration. The moment of
cessation of the event shall also be reported in writing.
The party who has pleaded a Force Majeure event is under
obligation, when requested, to prove its effect on the fulfilling
of the contemplated contract.
3.17. Payment
Payment will be made within 30 days of submission of valid
claims and/or invoices upon the successful completion of the
exercise as defined in the terms of reference / objectives.
SECTION 4 – ANNEXURES
4.1. Form of Contract Agreement
THIS AGREEMENT is made the _____ day of __________ 2015 between
the Consolidated Bank of Kenya (hereinafter called “the Purchaser”)
of the one part and [name of Supplier] of [city and country of
Supplier] (hereinafter called “the Supplier”) of the other
part:
ADVANCE \D 6.0WHEREAS the Purchaser invited bids for certain
products and ancillary services, for implementation of the
__________________and as accepted a bid by the Supplier for the
supply of those products and services in the sum of [contact price
in words and figures] (hereinafter called “the Contract
Price”).
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 request for proposal (RFP);
(b) The Purchaser’s Notification of Award; and
(c) The Supplier’s Bid.
3.In consideration of the payments to be made by the Purchaser
to the Supplier as hereinafter mentioned, the Supplier hereby
covenants with the Purchaser to provide the products and services
and to remedy defects therein in conformity in all respects with
the provisions of the Contract.
4.The Purchaser hereby covenants to pay the Supplier in
consideration of the provision of the products 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, and delivered by the
Said [name of representative] (for the Purchaser)
In the presence of [name of witness]
Signed, sealed, and delivered by the
Said [name of representative] (for the Supplier)
In the presence of [name of witness]
4.2. Bid Price Summary Form
Name of Bidder ___________________
No.
DESCRIPTION
COST IN KSHS
16% VAT
Total Cost (VAT Inclusive)
Delivery period
______________________________________________
Signature of Bidder
Stamp _________________________________________________
