druk pnb bank limiteddrukpnbbank.bt/downloads/rfp_aml_solution_ho_dpnbl.pdf · druk pnb bank...

DPNBL/RFP/AML-CFT Solutions/2019/3271 Date: April 09, 2019

1 DPNBL/RFP/AML-CFT Solutions/2019/3271 Date: April 09, 2019

DRUK PNB BANK LIMITED CORPORATE OFFICE

NORZIN LAM, THIMPHU BHUTAN

Request for Proposal for Supply, Delivery, Installation, Configuration, implementing and Maintaining AML/CFT (Anti Money Laundering)

Solutions

Reference: DPNBL/RFP/AML-CFT Solutions/2019/3271 Date: April 09, 2019

BID DETAILS



Sl. No. Subject Date / Time

Bid document availability www.drukpnbbank.bt

1 RFP Ref. Number & Date Ref. No. DPNBL/COM-AML/2019/ Date 09/04/2019

2 Last Date for receipt of Queries 20/04/2019

3 Last Date for Bank’s response to Queries 22/04/2019

4

Last date for receipt of Bidding Documents 29/04/2019 04.00 P.M

(BST)

In the event of the target date for the receipt of bids being declared as holiday for the Bank, the

bids will be received till the target time on the next working day.

5 Date & Time of Opening of Technical Bids 30/05/2019 02.00 PM (BST)

6

Venue / Address for Pre-bid meeting,

submission of Bid & Place of Opening of Bids

Druk PNB Bank Ltd., Head Office, Norzin Lam, Thimphu, Bhutan – Conference

Hall

7 Website address www.drukpnbbank.bt

8 E-mail address for communication [email protected]

9 R F P Fee Nu. 5,000/- Non-refundable

10 E M D Amount

Nu. 500,000.00 in the form of Bank Guarantee

valid for 6 months from the last date for

submission of Bids

11

Address for communication and submission of

bid.

The Chief Executive Officer Druk PNB Bank Ltd. Corporate Office, Norzin Lam Thimphu, Bhutan



Contents

1 Background

1.1 Bank profile

1.2 About this Request for Proposal (RFP)

2 Scope of work

2.1 Scope

2.2 Detailed Scope of Work:

2.3 Hardware, software and database:

2.4 Implementation of DR facility

2.5 UAT / Training setup

2.6 Warranty and AMC support

2.7 Training for Bank Team:

2.8 Security

3 Service Levels and Penalties

3.1 Purpose and Objectives of SLA

3.2 Penalties due to downtime

3.3 Penalties for delayed delivery

3.4 Penalties for delayed implementation of the project

3.5 Penalties if the hardware is not sized as per the requirement.

4 Pricing

4.1 Price composition

4.2 Price validity

4.3 No price alterations

4.4 Payment Terms

5 Eligibility criteria

5.1 Eligibility criteria for bidders

5.2 Authorization to bids

6 Preparation of Bids

6.1 Bid security

6.1.2 Costs of preparation & submission of bid

6.1.3 General terms of Bid submission

6.1.4 Two stage bidding process

6.2.1 Clarification of bid documents



6.2.2 Amendments to bid documents

6.3.1 Process of Bids – Response to RFP

6.4.1 Bid documents

6.4.2 Signing of the Bid

6.4.3 Bid submission

6.4.4 Confidentiality of the Bid document

7 Evaluation of Bids

7.1 Evaluation process

7.2 Technical Bid evaluation

7.3 Commercial evaluation

7.4 Final evaluation

7.5 Bidders’ obligations

8

8.1 Termination for default

8.2 Effect of termination

8.3 Indemnity

8.4 Liability of the selected bidder

8.5 Negligence

8.6 Force Majeure

8.7 Rights of the Bank

8.8 Information ownership

8.9 Publicity

8.10 Inspection of records

8.11 Compliance with laws

8.12 Resolution of disputes

8.13 Assignments

8.14 Ownership, grant and delivery

8.15 Privacy & Security Safeguards

8.16 Guarantees

8.17 Contract Re-negotiation

8.18 Corrupt and Fraudulent practices

8.19 Waiver

8.20 Violation Of Terms

8.21 Non-Disclosure of Information

8.22 No Commitment To Accept Lowest Or Any Offer/Bid



ANNEXURES

Annexure 1 Compliance Certificate

Annexure 2 Bidder Constitution and Contact Profile

Annexure 3 Financial Details of the Company

Annexure 4 Bidder’s Support Centre at Mumbai

Annexure 5 Credentials: Projects handled by bidder

Annexure 6 Eligibility Criteria

Annexure 7 Technical Specification

Annexure 8 Query Format

Annexure 9 Mutual Non-disclosure Agreement Format Application Integrity

statement from OEM

Annexure 10 Format of Bank Guarantee (for EMD)

Annexure 11 Bill of Material

Annexure 12 Pre Contract Integrity Pact

Annexure 13 Indicative Commercial Bid

Background

1.1 Bank profile

Druk PNB Bank Ltd. is a FDI Public Limited company (Bank) with PNB India holding 51% of its equity. It has a network of seven branches spread across Bhutan. All Branches are under CBS (Finacle 10) and the Bank has over 21 ATMs. Branches are presently controlled through the corporate office. The Data Center (DC) of the bank is located in New Delhi, India, and the DR is in Thimphu, Bhutan.

The bank is having its corporate office in Thimphu, the capital city of Bhutan. The Bank has eight full-fledged departments viz IT Department, Credit Department, Internal Audit Department, Finance & Accounts Department, Compliance Department, Reconciliation and Payment Settlement Department, Planning & Research Department, and HR Department. It also has other autonomous units including company secretariat, credit review unit, credit recovery unit, risk management unit besides the offices of CEO & DCEO. With around 35 employees at corporate office, the bank has a total of 155 employees as on March 31, 2019.

During the last 9 years of its operations, Bank has strengthened its IT infrastructure, carried out Process Reengineering and has enabled marketing of technology based products and services with strong presence through its alternate delivery channels like ATM, Internet Banking, Mobile Banking, PoS, etc. International Credit Cards services is also in the pipeline.



1.2 About this Request for Proposal (RFP) Scope Overview:

The Bank is performing activities pertaining to Anti Money Laundering/Combating Finance of Terrorism (AML/CFT) and for this purpose Bank seeks solution for providing software solution to fulfill all the regulatory requirement of FATF, Financial Intelligence Unit, RMA, and other regulatory bodies.

The scope of work would include design, supply, configuration, customization, integration, testing, user acceptance, documentation, training, warranty support and post warranty maintenance support for all the solution components including software/ hardware/ database/ licenses/ tools required for the fulfillment of the scope.

The Bank intends to select an experienced and technically competent Bidder with experience of providing AML solution implementation in line with RMA, FIU-Bhutan and other statutory/ regulatory and business requirements issued from time to time to supply, implement and maintain the AML solution for the bank.

The contract will be for an initial period of 6 years (3 years warranty followed by 3 years AMC/ ATS) post warranty and the same may be extended at the discretion of the Bank on mutually agreed terms.

1. This Request for Proposal is issued for inviting proposals (Technical and Commercial Bids) for

implementation and maintenance of Anti Money Laundering (AML) solution. The “Request for Proposal” (RFP) document is now being issued to enable vendors to submit their response to the Bank for the empanelment process.

2. As on date, the bank had no AML-CFT solution/system and been performing its AML-CFT related functions manually.

3. For this purpose Bank invites separate sealed bids (Technical and commercial) from the interested vendors for supply, integration, customization and implementation of hardware and software including backup software for implementing the new Anti-Money Laundering (AML) solution in the Bank.

4. A vendor submitting the proposal in response to this RFP shall hereinafter be referred to as “Bidder / System Integrator (SI)” interchangeably.

5. The RFP document is neither an offer letter nor a legal contract, but an invitation for offers /

responses. No contractual obligation on behalf of Druk PNB Bank Ltd. whatsoever shall arise from the RFP process unless and until a formal contract is signed and executed by duly authorized officers of Druk PNB Bank Ltd. and the bidder.

6. The Bank further reserves the right to accept or reject the total proposal or part thereof based on its

own evaluation of the offers received, or on the basis of stability, capabilities, track records, reputation among users and other similar credentials of a vendor. When the Bank makes any such rejection, the Bank will not be bound to give any reason and / or justification in this regard to the vendor. The bank reserves the right to cancel the RFP at any point of time without informing any reason.



7. All offers of the bidders shall be unconditional and once accepted whether with or without

modifications by the Bank shall be binding between the Bank and such Bidder.

8. However, this is a binding document between Bank and respondents till the completion of selection

process and notification of award and till a contract is signed between Bank and the Vendor in the process in case both parties initiate and expedite certain actions pending the execution of a contract.

9. The Bank may modify any / all of the terms of this RFP and shall be entitled to award the contract

to a selected bidder with / without modification of any conditions contained herein.

10. This RFP document is structured in such a way that the Bidders fully understand and acquaint

themselves with the requirements of the Bank.

11. While this section is a Preface to the entire document, the following sections are meaningfully

segregated for better understanding of the document. The section headings or any other headings do not have any contractual sequence and the submission of responses to RFP should be based on total understanding of the document.

2. SCOPE OF WORK 2.1 Scope

2.1.1 This document constitutes a formal Request for Proposal (RFP) for defining the scope of work for implementation and maintenance of Anti Money Laundering (AML) solution with Banks Data Centre (DC) at New Delhi and DR facility at Thimphu, Bhutan.

2.1.2 The broad scope of work for the bidder for the above mentioned requirement is narrated in the

ensuing paragraphs, wherein the selected bidder has to provide the necessary system to enable Implementation of Anti Money Laundering Solution, including all hardware, middleware etc. as required by the offered solution, application software and all related components, complete interface with the existing Finacle 10 CBS solution, implementation and ongoing support services.

2.1.3 This is an end to end project and all the items required for making the application operational

should be considered by the bidder, even if the same is not explicitly mentioned in this RFP document.

2.2 Detailed Scope of Work:

2.2.1 The solution should be capable of migrating the data including archived data in the existing solution and reading the same for inquiry purposes.

2.2.2 User Creation Policy, Password Policy and maker Checker concept should be implemented in

the proposed solution.

2.2.3 Bidder should provide required software and licenses including implementation / execution of

the same within the stipulated time period.



2.2.4 Bidder should act as a system integrator for providing AML solution, providing all the required

hardware, middleware, application software and third party utilities, if any and installation, testing, commissioning, warranty, annual maintenance etc.

2.2.5 A detailed list of the servers, tape library etc together with their configurations should be provided

in the technical bid. Technical specifications should be recommended keeping in mind that fault-tolerant systems with sufficient redundancy built in to ensure smooth and continuous operations.

2.2.6 During warranty / AMC period, bidder shall provide onsite support for hardware / software at no

additional cost to the Bank. Services under Warranty, AMC and ATS should be provided on comprehensive on site basis only. Remote NOC services are not envisaged.

2.2.7 The proposed solution must encompass installation, integration and customization of the

solutions with the existing Core Banking Solution of the Bank without hampering the routine operations of the bank. The bidder should accomplish the job in coordination with existing System Integrator of the CBS. The customization if any required at Finacle end will be taken care by Bank.

2.2.8 Bidder will have to ensure the troubleshooting in all forms like technical, administrative related

issues etc.

2.2.9 Bidder shall provide necessary software and hardware to support archiving requirements of the

Bank for the entire contracting period.

2.2.10 The proposed hardware should have either horizontal scalability or vertical scalability in

accordance with the requirements of Web / App / DB layers. Bidder has to submit a hardware sizing document duly explaining and detailing make, model, architecture, configuration and OS requirement for each of the systems required for various layers.

2.2.11 Time being an essential feature of the contract, the selected vendor is expected to complete

the implementation within 5 months from the date of Purchase order.

2.2.12 Selected bidder must supply, install and integrate all the hardware, tools, software, media,

documentation and other material as per the terms and conditions agreed by the Bank. All the components required for the project will be owned by the Bank. Space and infrastructure to install the system will be provided to the Bidder. The Bank’s team shall be included in the process so that they are able to understand the details of the system and process.

2.2.13 Selected bidder has to provide following services including provision of software and

maintenance services.

• Selected bidder has to provide necessary project management.



• Selected bidder required to provide adequate training and operational guidelines to designated staff for data extraction, conversion and uploading tasks, Report Generation Software / Tools installed in the AML solutions for a period not less than of one week.

• Selected bidder shall provide comprehensive documentation of the application including application architecture, description of the interfaces, data model, database structure, meta data details, user manual etc.,

2.2.14 The bid should include the hardware and software required for setting up of DR site for the

solution.

2.2.15 The bid should include backup solution including backup hardware.

Functional requirements of Anti Money Laundering Solution: Regulatory Requirements

2.2.16 The system should comply with guidelines on KYC-AML & Combating of Terrorism Financing,

Black Money etc., from various regulators/enforcement agencies like RMA, FIU, Government of Bhutan, etc.

As and when new guidelines are issued various regulators/enforcement agencies like RMA, FIU, Government of Bhutan etc., the system should incorporate the same without bank’s intervention and additional cost to the bank.

2.2.17 The system should address and be compliant with the recommendations laid down by FATF.

KYC & AML Requirements 2.2.18 System should capture all the Due Diligence Information of the customer base of the bank. It

should also capture Due Diligence data on Beneficiaries and connected parties.

2.2.19 Due diligence information should invariably contain parameters like source of funds, business

activity / occupation of customer, expected level of activity in the account, declared income by the customer etc. In addition, where the KYC information is missing, there should be facility to enrich the data.

2.2.20 System should provide a list manager to manage various black-lists provided by regulatory

authorities such as lists provided by OFAC, EU, HMT, PEP lists, UNSCR lists, High risk countries list etc. It should also be possible to add new lists as and when they are introduced in future. The lists should be updated as and when notifications are received from regulators. Users should also be able to create/maintain internal watch lists to monitor certain customers as and when required.

2.2.21 There should be support for list scanning of account /customer database against watch lists –

incremental screening should be there if there are any updates to the watch list data or customer



data. All new customers should be checked against blacklists, watch lists. And there should be provision to run search against existing customers as and when required.

2.2.22 System should categorize accounts into risk categories – High, Medium and Low –as per the

risk rating mechanism in tune with the AML policy. It should support risk profiling of customers based on occupation, STRs filed, KYC compliance, transaction patterns, turnover etc. System should also calculate the threshold limits basing on customer’s profile .There should be a automated periodical review mechanism to update the risk categorization and threshold limits for the customer data. In addition, it should be always possible to override the system calculated risk values, having an option to manually set the risk.

2.2.23 Support for advanced search techniques to search data provided by enforcement agencies. It

should enable the user to enter the match score, sub string search, inclusion of various search parameters to refine the search.

Alerts Management & Transaction Monitoring

2.2.24 The system should provide rule based suspicious transaction identification. The system should have the ability to update above rules incorporating new scenarios as and when notified by the concerned authority for identifying suspicious transactions. These updations should be done on prompt basis. The system should also have provision to create user defined rules basing on various parameters like customer type, nature of business, various risks etc.

2.2.25 Since various persons try to make simple transactions look very complex though various

methods to confuse the investigation official, so the system should have support for link analysis for tracing multitude of relationships between customers and to be able to identify all the intermediate accounts for inclusion in the suspicious case preparation.

2.2.26 The system should effectively integrate with various solutions implemented in the bank like

CBS, Credit Cards application, LAPS, etc. for the generation of all the alert scenarios and also for preparation of various statutory reports.

2.2.27 The AML system should allow for benchmarks to be fixed based on the general behavior of

entities (Customers, Products etc.). The default benchmarks should be definable in the system and the user should be able to edit an existing benchmark

2.2.28 Closure of alerts should be done in the system and report for the same is to be obtained as and

when required. Users should be notified about the cases allotted to them which are pending to be investigated, if it crosses the time window from the date of generation and allotment.

2.2.29 Users should be able to view transactional details of all alerts fired with respect to the certain

customer. There should be no need to navigate away from the system to view these details and bank’s CBS system should be accessible to the user in the same window.



2.2.30 System should have provision for work load balancing for alerts assignment. Reports should also provide information to management on the alerts status. It should also be possible to re-run any rule at any time and for any past date.

Reporting & Case Preparation Requirements

2.2.31 FIU defined formats for various reports like STR, CTR, etc. may change over the period of time and accordingly should be taken up by the vendor and provided without any delays.

2.2.32 Address the challenges in statutory reports‟ submission by automating the process from data extractions to submission to FIU before cut-off date. Various reports like List screening report for new and existing customers, transaction report, transactions in High-risk countries report, KYC gap reports etc. There should be an option to download reports in various formats like xls, rtf, pdf etc.

2.2.33 The suspicious transaction report (STR) should be auto populated with all the necessary

information to substantiate the case and there should be automatic preparation of case approval notes in the defined formats. There should be provision to link multiple cases pertaining to the same customer. Also support for attaching evidence documents.

2.2.34 The case management utility should have provision to define roles for the officers involved. 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.

Other Requirements

2.2.35 There should be support for automated uploading of data for previous day from the bank’s CBS system to AML system without any manual intervention. There should be a provision for the users to raise a ticket in the system in case of any issue faced to maintain the record of time span for issue resolution.

2.2.36 The system should have complete and comprehensive security from unauthorized access. The

number of levels / rights assigned to each level should be user configured by the bank. System should provide Maker/Checker facility. System should provide full audit trail for the events like alert generation, case creation, change to case information, changes to lists etc.

2.2.37 It shall properly maintain and preserve account and alert information in a manner that allows

data to be retrieved easily and quickly whenever required or when requested by the competent authorities. Further, it shall maintain for at least ten years from the date of transaction between the bank and the client, all necessary records of transactions, as required under PMLA2002 which will permit reconstruction of individual transactions so as to provide, if necessary, evidence for prosecution of persons involved in criminal activity.

Architectural Considerations – Envisaged architecture of the proposed Anti-Money Laundering Solution



2.2.38 Bank has implemented Finacle 10 Core Banking Solution over platform with 3tier architecture

(Web, APP and DB) with identical systems at Data Center and Disaster Recovery center.

2.2.39 Bank has deployed Antivirus solution, firewalls of different makes, IPS as part of Security architecture.

2.2.40 The bidders may seek any other details strictly based on NDA and Bank may provide such

detail purely on need basis and its sole discretion.

2.2.41 The proposed solution should be compatible and should integrate with the existing architecture

of the Bank.

2.2.42 The system should automatically pull information from CBS on real time basis and either block

or raise alarm for suspicious transactions.

2.2.43 The proposed solution may have its own App Server with required redundancy.

2.2.44 The proposed solution has to be functional even with the Bank’s DR system, when DR System is designated for the purpose of operations either due to a scheduled cut over (DR Drill) or put to use for the purpose of operations in the event of a disaster.

2.2.45 The software license fees should include DR component. BoM should include the hardware and

software required for DC and DR also.

2.2.46 The bidder is expected to have full understanding of Finacle internals and is capable of working

in close coordination with Finacle Software providers (Infosys). The expectations from Bank’s CBS System Integrator are to be listed out. The Vendor should have willingness to work in coordination with the System Integrator.

2.2.47 The bidder shall provide detailed solution architecture showing all internal components of

transaction workflow.

2.2.48 Bank may require the selected bidders to arrange for a demonstration of the proposed solution,

to assess the feasibility and suitability, at a live reference site. The bidders will have to arrange for the necessary infrastructure for conducting the said demonstration.

2.3 Hardware, software and database:

2.3.1 The bidder needs to supply, install and configure all the required Servers, application software, Operating system, middleware, database, Tape library, backup software, required rack etc. for implementing AML solution. The bidder shall make specify the storage size required for the solution. The bidder can use the existing storage space for implementing the solution at Data Centre & Disaster Recovery Site. Bank prefers to have Open Source software and database wherever feasible. In the case of open source software the following are mandatorily required.



The hardware shall be insured for an amount equal to 110 percent of the value of the Products from “Warehouse to final destination” on “All Risks” basis including War Risks and Strikes, valid for a period not less than 3 months after installation and commissioning and issue of acceptance certificate by the Bank.

Should any loss or damage occur, the supplier shall: a) initiate and pursue claim till settlement end, and b) promptly make arrangements for repair and / or replacement of any damaged item irrespective of settlement of claim by the underwriters.

Intellectual Property (IP) built around the Open Source Software by the SI/OEM. In such cases, the patent number and other details should be provided to the bank. EULA (End User License Agreement) should be signed with the bank

Tech support to be provided for the Open Source Software

2.3.2 The application should have three tier architectures. The web and application layer can be on

the same server and database should be on a separate server. All the servers should be provided in high availability mode i.e in active – passive mode. Further all the equipment should have dual power supply and all the required cables for connecting the equipment should be supplied by the bidder.

The bidder must also ensure that the hardware resources utilization should not exceed 70% at any point of time for five years from the date of signing of contract. In case the utilization exceeds the above level, the bidder must provide additional hardware without any additional cost to the Bank.

2.4 Implementation of DR facility

2.4.1 The bidder has to quote for the hardware and software required at DR facility. The DR setup will be implemented in Banks existing DR facility at Thimphu.

2.4.2 The hardware quoted for DR should be of equivalent capacity as that of the hardware at DC

should be provided in high availability mode i.e in active – passive mode.

2.5 Warranty and AMC support 2.5.1 Warranty:

The Bidder shall offer software solution for Implementation of AML Solution with 3 years AMC / ATS after the Warranty Period of 3 years from the date of commissioning of the services. However, the Bank reserves right to renew AMC/ ATS of the solution at mutually agreed rate for one or more years.

If the bidder fails to offer service for the specified period, then the bid is liable for rejection and may cause Heavy Penalty/ Blacklisting of Bidder’s company/ Legal Action against Bidder Company.

During the warranty period, the bidder has to customize the application as per Bank’s requirement, maintain it and fix reported bugs at no extra cost to the Bank.



2.5.2 The Bidder shall also provide Complete Maintenance Support (Post Warranty AMC –

Onsite (as and when it is required) which must include:

a) Supply, installation and configuration of upgraded versions of application, Software & patches (whenever released).

b) Trouble Shooting &Rectification of bugs/ defects.

c) Fine Tuning/ Performance Tuning/ Security Configuration of the Solution.

d) Reinstallation& Reconfiguration of software/ database (whenever required).

e) Testing of the Solution (as specified above).

2.5.3 Bidder has to provide uninterrupted support services per Bank’s working hours (Monday to Saturday). However, support shall be available on 24*7 basis during periods of crisis, resolution of issues or movement of releases/ fixes, DR drills. Bidder has to provide detailed escalation hierarchy which must include:

a. Maximum Number of Level in escalation hierarchy should not exceed 4.

b. Defined issue resolution time (min & max) at each level.

c. Support Level wise contact information (escalation hierarchy) should be provided to Bank which

includes Support Engineer/ Team Leader/ Manager/ Higher Official Name, Office Number, Mobile Number and Email ID etc.

d. All modes of communication to raise issue should be accepted by Bidder like: by registered

email, by registered phone, by issue tracker system, by official letter from Bank (scanned or actual).

2.5.4 Bidder has to facilitate one:

a. Technical Engineer (with sound web application development & domain knowledge) availability for the discussion & finalization of the additional requirement/ changes in existing requirement (if any, as & when required) throughout the contract period.

b. Single point contact person i.e. “Account Manager” who has to visit HO: CO, Compliance Department (regularly/ on demand) to ensure smooth functionality & various other discussion related to the solution.

2.5.5 As a part of the AMC support, Bidder is required to setup one Development/ Test Server at their

support center to simulate & resolve the issues reported by the Bank (with the help of the log generated by the application). Although the backup will be taken by the DC team the Bidder will also be responsible to test the backup for the restorability using test server once in every 6 months.



2.5.6 Bidder will be responsible to do all the required testing/ validation against the specified guidelines using industry standard tools and submit the relevant reports to the Bank before Go-Live. These testing should be conducted on yearly basic by the AMC Support Team as a part of the AMC contract and relevant report are to be submitted to the Bank. The tests also includes load testing & performance bench marking (if required).

2.6 The successful bidder shall impart training for Bank Team.

Admin Functions Training - One week duration. Core Team Training - 1 Batches of 20 - One week duration. Bank will inform the dates and venue for training within a span of two years.

2.7 the successful Bidder shall furnish the performance security in the form of Bank Guarantee, issued by a Bank in Bhutan other than Druk PNB Bank Ltd., for 10% (ten percent) of the base contract value (exclusive of AMC/ATS charges), valid for 78 months. (Read point 4.4 too)

3. SERVICE LEVELS AND PENALTIES 3.1.1 Service Level Agreements (SLAs)

Within fifteen (15) days of receipt of the Purchase Order or before submission of the bill for payment, the Selected Bidder shall sign and date the SLA designed by the Bank and return it to the Bank. The SLA will include the terms/ conditions as in RFP. The Bidder however may submit the SLA Form they like to execute. It is the prerogative of the Bank to accept the same or to modify. It is reiterated that the SLA to be entered into by the Selected Bidder shall be as approved by the Bank only.

The Bidder need to execute a Service Level Agreement/Contract with the Bank covering all terms and conditions of this tender. Bidder need to strictly adhere to Service Level Agreement (SLA). Services delivered by bidder should comply with the SLA mentioned below. The Bank shall without prejudice to its other rights and remedies under and in accordance with the terms of the RFP levy liquidated damages with applicable taxes including Goods and Services Taxes from payments due to the Bidder. SLA will be reviewed on a quarterly basis. SLA violation will attract penalties.

Time is the essence of the contract and the bank expects the Bidder to complete the project as per the implementation plan specified in the RFP. If the Bidder fails

I) to deliver any or all software; or

II) to commence services within the time specified as per the terms of the RFP; or

III) to perform the services and extend the support that meets the requirements as stipulated in the RFP

within the time specified in the RFP; or

IV) to maintain the uptime of the solution/component of the solution;

Inability of the Bidder either to provide the requirements as per scope or to meet the timelines as specified would attract liquidated damages.



3.2 Penalties due to downtime

Service Levels will include Availability measurements and Performance parameters. The Vendor shall provide Availability Report on monthly basis and a review shall be conducted based on this report. A monthly report shall be provided to the Bank at the end of every month containing the summary of all incidents reported and associated Bidder performance measurement for that period. Bidder shall use an appropriate tool for the purpose of such reporting.

Performance measurements would be assessed through audits or reports, as appropriate to be provided by the Bidder e.g. utilization reports, response time measurements reports, etc.

The tools to perform the audit will need to be provided by the Bidder. Audits will normally be done on regular basis or as required by Bank and will be performed by Bank.

LEVEL Function / Technology

Severity 1 a. Any problem due to which real-time detection or prevention is not working or; b. Any problem due to which the components of AML Solution are not available to

the Bank’s users or does not perform according to the defined performance and query processing parameters required as per the RFP or;

c. Showstoppers involving major functional failure in the application. There are no

usable workarounds available to troubleshoot the Problem

Severity 2 a. Any problem due to which near-real time detection or prevention is not working or ;

b. Any incident which is classified as “Severity 1” for which an acceptable workaround has been provided by the Bidder or;

c. Users face severe functional restrictions in the application Irrespective of the

cause.

Severity 3 a. Any problem due to which offline detection and prevention is not working or;

b. Any incident which is classified as “Severity 2” for which an acceptable workaround has been provided by the Bidder or;

c. Moderate functional restrictions in the application irrespective of the cause. Has a

convenient and readily available workaround.

System availability is defined as:

{(Scheduled operation time – system downtime) / (scheduled operation time)} * 100%

Where:

I. “Scheduled operation time” means the scheduled operating hours of the System for the month.



All planned downtime on the system would be deducted from the total operation time for the month to give the scheduled operation time.

II. “System downtime” subject to the SLA, means accumulated time during which the system is not available to the Bank’s users or customers due to in-scope system or infrastructure failure, and measured from the time Bank and/or its customers log a call with the Bidder help desk of the failure or the failure is known to the Bidder from the availability measurement tools to the time when the System is returned to proper operation.

III. Service Levels should be complied with irrespective of the customizations that the

applications would undergo during the tenure of the Contract.

Severity Definition

Severity Definition during Live operations due to Infrastructure/ Functional issues of the AML Solution.

The Bank will classify all errors in to three categories:

(I) Critical errors defined as the Errors that cause the transactional service disruption or service disruption to other connected systems due to malfunction/ service unavailability of the AML Solution or unavailability of the expected services by AML Solution. The Vendor undertakes and guarantees that all the Critical Errors will be resolved in the production environment within four hours of the Bank intimating the same through writing, telephone or fax.

(II) Medium Level Errors defined as those errors that are not the Critical Errors as defined above

but cause great inconvenience or operational difficulties to the Bank. The Vendor undertakes and guarantees that all the Medium Level Errors will be resolved in the production environment within two days of the Bank intimating the same through writing, telephone or fax.

(III) Low Level Errors defined as those other errors that are not the Critical errors or the Medium

Level Errors as defined above. The vendor undertakes and guarantees that all the Low Level Errors will be resolved in the production environment within five days of the Bank intimating the same through writing, telephone or fax.

For every issue crossing beyond the above referred thresholds for resolution Bank shall have right to levy penalty @ Nu. 10000/- (Nu. Ten Thousand Only) per day per issue, subject to a maximum of 10% of the contract value.

For repeat failure, same or higher penalty will be charged depending upon the delay in rectification of the problem.

3.2.1. Penalty for Losses/ breaches

This shall be in addition to the liquidated damages for not meeting SLA which is defined separately.

a) Penalties will be levied @ Nu. 50,000/- per instance for any loss bank has suffered due to frauds

taken place during the down time or non-availability of system.



b) Penalties will be levied @ Nu. 50,000/- per instance for violations of rules configured to prevent fraud

and/or generate alerts etc.

c) Penalties will be levied @ Nu. 50,000/- per instance for alerts not sent on time to customers in case

of Frauds.

d) Penalty of Nu. 50,000.00 per hour will be levied if the solution disrupts the Banking Operations and

at the rate of Nu. 10,000 per hour if it causes lowering of performance of Banking Operations by at least 40%.

Penalty is not applicable for reasons attributable to the Bank and Force Majeure. However, the onus of proof lies with the bidder.

3.3 Penalties for delayed delivery

3.3.1 The bidder should ensure that the entire hardware / software is delivered within 6 weeks from the date of purchase order.

3.3.2 Bank reserves the right to charge penalty for delayed deliveries with applicable taxes thereon at

the rate of 0.50% of the TCO per week without prejudice to its other rights, if not delivered as per the agreed terms & conditions of delivery schedule as per Bid submitted. The penalty may be increased to 1% per week for the delay beyond 2 weeks from the stipulated delivery date. The penalty is capped at 10 % of the Total Cost of Ownership (TCO) of the Project.

3.3.3 In case of delay from Bank’s side, the SI should provide documentary proof for the same. Bank reserves its right to recover these amounts by any mode such as adjusting from any payments to be made by the Bank to the SI.

3.4 Penalties for delayed implementation of the project

3.4.1 The Bidder is expected to complete the responsibilities that have been assigned on time.

3.4.2 The bidder should ensure that the project implementation at DC / DR is completed within 5

months from the date of Purchase order / signing of contract.

3.4.3 As a deterrent for delay, Bank would levy penalties for delays attributable to the Bidder.

Notwithstanding the Bank’s right to cancel the order, liquidated damages at 0.5 % of TCO of the Project Cost with applicable taxes will be charged for every week delay in implementation subject to a maximum of 10 % of the value of the Project.

3.5 Penalties if the hardware is not sized as per the requirement.

3.5.1 The bidder must also ensure that the hardware resources utilization should not exceed 70% at any point of time for five years from the date of signing of contract. In case the utilization exceeds the above level, the bidder must provide additional hardware without any additional cost to the Bank.



3.5.2 If the required upgrade is not carried out by the bidder bank has the right to carry out the upgrade

and recover the expenditure from any of the payments due to bidder.

4. PRICING 4.1 Price composition

4.1.1 The price quoted should be in Bhutanese Ngultrum (BTN) on a fixed price basis and should include the following:

• One time charges for Installation, Commissioning of entire setups • Cost of Software and Hardware

• AMC charge for Hardware and software

4.1.2 The solution provided should be complete and no other costs will be entertained.

4.1.3 All tools, tackles, testing instruments, consumables, vehicles, transportation, boarding, etc., as

required for commissioning / maintenance /patch updation etc. shall be provided by the Bidder at no extra cost to the Bank for completing the scope of work as per this RFP.

4.1.4 Prices quoted should include all taxes, duties, service taxes and levies.

4.1.5 The quantities indicated in the price bid are approximate and the payment will be made on actual.

4.1.6 The formats given in the annexures shall be strictly adhered to.

4.1.7 Prices shall be inclusive of all costs to be charged and segregated into onetime costs and

recurring costs, taking care of the end to end solution. Taxes, duty, service taxes, other charges should be mentioned specifically.

4.1.8 In case the equipment is to be imported, the SI‟s required to do all such processes like customs clearance etc., without involving the Bank in any manner at any stage. It will be the responsibility of the SI to abide by all the statutory requirements like payment of all taxes, duties etc., without any reference to the Bank. Bank accepts no responsibility or liability in this regard.

4.2 Price validity

4.2.1 The price finalized shall remain valid for a period of one year from the date of such finalization.

4.2.2 The AMC quoted should be valid for entire contract period and bank will not entertain any upward

revision of AMC charges during the contract period.

4.3 No price alterations

4.3.1 All details must be completely filled up. The corrections or alterations, if any should be

authenticated. In the case of the corrections/alteration are not properly authenticated, the offer shall become liable for rejection at the discretion of Bank.



4.4 Payment Terms

Within Thirty (30) days of the receipt of Purchase Order from Bank, the successful Bidder shall furnish the performance security in the form of Bank Guarantee, issued by a Bank in Bhutan other than Druk PNB Bank Ltd., for 10% (ten percent) of the base contract value (exclusive of AMC/ATS charges), valid for 78 months covering Warranty & AMC period as per Annexure- 4. No payment shall be made to the vendor until Performance BG is submitted.

Failure of the Selected Bidder to comply with the requirement of executing Contract and submitting Performance Guarantee shall constitute sufficient grounds for the annulment of the award and forfeiture of the Bid Security.

The bidder must accept the payment terms proposed by the Bank. The financial offer submitted by the bidder must be in conformity with the payment terms proposed by the Bank. Any deviation from the proposed payment terms would not be accepted. The Bank shall have the right to withhold any payment due to the bidder, in case of delays or defaults on the part of the bidder.

Such withholding of payment shall not consider as a default on the part of the Bank.

The scope of work is divided in different areas and the payment would be linked to delivery by the successful Bidder and acceptance by the Bank of each area as explained below:

All payments will be released from our office within 30 days of claim on submission of all relevant documents and proofs. The payments will be released through NEFT/ RGTS and the Selected Bidder has to provide necessary Bank Details like Account No., Bank’s Name with Branch, IFSC Code etc. Applicable TDS, if any, will be deducted at the time of releasing the payments.

A. Project Implementation:

Deliverables % OF

PAYMENT

STAGES (On completion of the activities)

Hardware 70% Delivery and on submission of invoice, Bidder has to mention their TPN, HSN/SAC

number in all the invoices/bills, wherever

applicable.

30%

On successful Installation and

acceptance of the Hardware

AML Application Licenses, Database Licenses, Operating Systems and other peripheral software

70% On delivery of licenses, this shall be only after

acceptance of Hardware and on submission of

proof.

30%

On successful installation and

commissioning and Testing of the respective

software



No payment shall be made to the vendor until a Performance Bank Guarantee is submitted to the

required value. If Performance Bank Guarantee is not submitted by the successful bidder as per

PO terms, Bid Security will be invoked by giving notice to the vendor.

Implementation Cost for

respective modules

20% On AML Solution Sign off by the bank

20% Parameterization

20% UAT

40% Go live

Training 100% Will be paid as and when each batch is trained.

TDS on payments will be deducted as applicable.

B. AMC/ ATC Payment: i. The invoice for AMC/ATC renewal proposal is to be submitted at our Office, at least 30 days

before due date for renewal of AMC, every year.

ii. AMC shall be paid in advance in equal yearly installments within thirty days of receipt of claim at

the start of each year, after completion of warranty/ maintenance obligations of the previous year, at the rates quoted.

5.1.1 Eligibility Criteria:

Bidders meeting the following Eligibility Criteria may respond to this RFP.

Eligibility Criteria Support Documents to be submitted

1) The bidder should be a Registered entity /

Company under Companies Act of its

registered country for the last five years

as on date of RFP.

Copy of certificate of incorporation and Articles of

Association should be submitted along with the

bid or the relevant certificates of Registration.

2) The AML Solution OEM must be a

company/ entity incorporated and

operating for 5 years as on the date of

RFP

Copy of certificate of incorporation and Articles of

Association should be submitted along with the

bid or the relevant certificates of Registration

3) The Bidder should be a profit making company and should have earned

Net profit in at least two out of three preceding Financial Years and Operating profit during remaining Financial years as per the audited Financial Statements.

Certified copies of Audited Financial Statements (and Annual Reports, if applicable) for the last three financial years. (Also furnish the information in Annexure-6)



4) Bidder should have a turnover of Nu. 50 million (fifty million) or above per annum for the last three consecutive financial years.

Certified copies of Audited Financial Statements

or certificate from Auditors providing the Turn

Over details for the last three years. (Also furnish

the information in Annexure-6)

5) The bidder should be the owner or certified / authorized agent of the solution offered

Letter from the OEM authorizing the bidder to

participate in the RFP or agreement with the

solution provider with reference to the solution

offered should be submitted along with the bid. In

case OEM is directly participating self-

declaration has to be provided.

6) The bidder company should have valid ISO 9000 / 9001 & ISO/ IEC 27001 certification

Copy of the ISO 9000 / 9001 & ISO/ IEC 27001

certificate should be submitted along with the bid

7) The bidder should be in the business of

providing services in the area of Anti Money

Laundering with at least 4 member team.

Undertaking from the bidder on bidder’s letter

head signed by the authorized signatory of the

bidder.

8) The OEM should have a dedicated support

Centre in Bhutan.

Undertaking from the bidder on bidder’s letter

head signed by the authorized signatory of the

bidder.

9) The Solution OEM must have at least 15

skilled staff experienced in implementing AML

Solution & should be able to deliver and

support the proposed solution.

Self-Declaration from the Solution OEM on the

company’s letter head signed by the authorized

signatory of the OEM

10) The Bidder should have the experience of Implementing / has under implementation at least one project for a Commercial Bank with more than 25 branches in South Asian Countries. Projects which qualify are any one of the following:: 1. AML Solution 2.Enterprise Fraud Risk Management Solution 3. Core Banking Solution 4. Data Warehousing Solution

Copy of Purchase order or letter from the bank

certifying the same



11) The Proposed AML Solution should have been implemented/ or should be under implementation in at least in one Commercial Bank in South Asian countries having a minimum of 25 branches

Copy of Purchase order or letter from the bank certifying the same

12) The bidder/ OEM should not have been black listed by any Govt. Financial Institutions / Banks/ Government departments/ Semi-Government

departments / RMA/ any PSUs in Bhutan.

A self-declaration by the Bidder and OEM

13) The Bidder’s company and OEM should not be owned or controlled by any Director or Employee (or Relatives) of

Druk PNB Bank Ltd.

A self-declaration by the Bidder and OEM on

Company’s letter head.

14) The bidder and OEM should have service / support infrastructures in Bhutan and should be able to provide efficient and effective support at the banks premises. Bidder shall ensure back to back availability of support from OEM. A letter from OEM in this regard shall be

submitted as part of bid. A list of service

/support center be submitted as a part of

tender document.

Letter from bidder and OEM to this effect with full

address of service centers should be produced.

The bidder needs to comply with all the eligibility criteria mentioned above to be considered for technical evaluation. Non-compliance to any of these criteria would result in outright rejection of the bidder’s proposal. The Bidder should enclose proof in support of all eligibility criteria while submitting the Bid Proposal, failing which, the Bid Proposal will not be considered for further evaluation. There is no restriction on the number of credentials a bidder can provide, however all credential letters should be appropriately bound, labeled and segregated in the respective areas.

The Bank reserves the right to change or relax the eligibility criteria to ensure inclusivity.

5.1.2 Authorization to Bid:

The proposal/ Bid being submitted would be binding on the Bidder. As such it is necessary that authorized personnel of the company or organization sign the Bid. The designated personnel should be authorized by a senior official of the organization having authority to do so. The same person or a different person should be authorized, and should have authority to quote bid amount in on-line-seal bid.



The XEROX copy of necessary Original resolutions/authority/ Power of Attorney having authority to authorize the person to submit Bid documents, on behalf of the company shall be enclosed. The proposal must be accompanied with an undertaking letter duly signed by the designated personnel providing a Bid commitment. The letter should also indicate the complete name and designation of the designated personnel.

6) Preparation of Bids: 6.1 Bid Security:

i. The Bidder shall furnish, as part of its Bid, a Bid Security for an amount of Nu. 100000 (Nu. 0ne Lakh Only) in the form of a Bank Guarantee (BG) issued by a Commercial Bank in Bhutan other than Druk PNB Bank Ltd. in the format enclosed (Annexure-10), to be valid for a period of six months from the last date for submission of Bid Document, along with the Bid Documents.

ii. The Selected Bidder’s Bid Security will be discharged upon the Bidder’s furnishing the Performance Security in the form of Bank Guarantee, as provided in Warranty Clause.

Unsuccessful Bidder’s Bid Security will be discharged or returned as promptly as possible, but not later than 30 days after the expiration of the period of Bid validity prescribed by the Bank.

iii. The bid security may be forfeited, if the bidder:

a) withdraws its Bid during the period of Bid validity; b) fails to enter into agreements with the bank c) To accept Purchase Order, d) To furnish Performance Security Bank Guarantee valid for 78 months within the stipulated time, e) To supply the Hardware / software / services within the stipulated period. f) Fails to comply with any terms of RFP or Purchase Order

6.1.2 Costs of Preparation & Submission Of Bid

The bidder shall bear all costs for the preparation and submission of the bid. BANK shall not be responsible or liable for reimbursing/compensating these costs, regardless of the conduct or outcome of the bidding process.

6.1.3 General terms of Bid submission

The offers should be made strictly as per the formats enclosed.

The Bidder should bear all the costs associated with the preparation and submission of their bid and Bank will in no case be responsible or liable for these costs, regardless of the conduct or outcome of the bidding process.

Two copies of the bid are to be submitted, one in original and the other in copy.

The bid should be signed by the Bidder or any person duly authorized to bind the bidder to the contract. The signatory should give a declaration and through authenticated documentary evidence establish that the person is empowered to sign the tender documents and bind the bidder. All pages of the tender documents except brochures if any are to be signed by the authorized signatory.



The offers submitted to Bank should preferably not bear any corrections, alterations, over writings and additions. In such cases, the persons signing the bid should initial such corrections.

The Bidder is expected to examine all instructions, forms, terms and conditions and technical specifications in the Bidding Documents. Failure to furnish all information required by the Bidding Documents or submission of a bid not substantially responsive to the Bidding Documents in every respect will be at the Bidder’s risk and may result in rejection of the bid.

No columns of the tender should be left blank. Offers with insufficient information and Offers which do not strictly comply with the stipulations given above, are liable for rejection.

Bank may accept or reject, in full or in part, any or all the offers, without assigning any reason whatsoever.

The bids will be opened in the presence of authorized representatives of the bidders. However, the representative of the bidder has to produce an authorization letter from the bidder to represent them at the time of opening of Technical/Commercial bids. Only One representative will be allowed to represent any bidder. In case the bidder’s representative does not present at the time of opening of bids, the quotations/bids will still be opened at the scheduled time at the sole discretion of the Bank.

The bidder must use the entire information furnished in the RFP including scope, detailed requirements of audit of application and other terms and conditions, while submitting the response.

All responses should be in English language only. All responses by the Bidders to this RFP document shall be binding on such Bidders for a period of 180 days from the date of opening the Technical Bid.

All responses including commercial and technical bids would be deemed to be irrevocable offers / proposals from the Bidders and May, if accepted by Bank, form part of the final contact between Bank and Bidder.

Bidders are advised to attach a letter from an authorized signatory attesting the veracity of the information provided in the response.

Any technical or commercial bid submitted cannot be withdrawn / modified after the closing date and time for submission of the bid offers unless specifically permitted by Bank. However, the Bidder may modify or withdraw its offer after submission provided that, Bank, prior to the closing date and time receives a written notice of modification or withdrawal.

Bank concludes that everything as mentioned in the RFP documents circulated to the Bidders and responded by the Bidders have been quoted for by the Bidders and there shall be no extra cost associated with the same other than the cost quoted by the Bidder. The component prices quoted by the bidders shall be binding for any additional component procurement as needed by the Bank within the ambit of the scope of work including any extensions to the same. The component prices should be rational and in line with the overall prices quoted. Any irrational pricing of components can lead to disqualification of the bid.



In the event, Bank has not asked for the quotes for alternative prices and the Bidder furnishes the alternative quotes in the Bidder’s financial bids, the higher of the quotes shall be taken for evaluating the bids. However, payment by Bank shall be made for the lowest quote.

The original and all copies of bids shall be typed or printed in a clear typeface. Copies may be good quality photocopies of the original. An accompanying letter is required, signed by an authorized signatory of the Bidder, committing the bidder to the contents of the original response.

6.1.4 Bidding Process

The response to the present tender is to be submitted in two parts, i.e. the Technical Bid and the Commercial Bid for indicate amount. The bidders will have to submit the “Technical Bid‟ separately from the “Commercial Bid‟.

The bidder has to submit their response in hardcopy and softcopy in Microsoft Office document formats for Technical Bid and Commercial Bid.

The “Technical Bid” will contain the exhaustive and comprehensive details of approach, methodologies to be followed, assertions, documents and any other collateral the Bidder would want to submit to the Bank.

The “Commercial Bid” will contain the pricing information alone.

The Technical Bid should NOT contain any pricing or commercial information at all. Any bids violating this will be summarily rejected and the bids shall be disqualified from further evaluation.

In the first stage, only the “Technical Bids” will be opened and evaluated. Those bidders satisfying the technical requirements of the solution, as determined by Bank and as per the requirements / specifications and the terms and conditions of this document, shall be short-listed.

Bank may call for any clarifications/ additional particulars required, if any, on the technical/ commercial bids submitted. The bidder has to submit the clarifications / additional particulars in writing within the specified date and time. The bidder’s offer will be disqualified, if the clarifications / additional particulars sought are not submitted within the specified date and time.

Bank reserves the right to call for a presentation on the features etc., from the short-listed bidders based on the technical bids submitted by them to make an evaluation.

Bidders must acquaint themselves fully with the conditions of the bids. No plea of insufficient information will be entertained at any time.

The commercial bid shall be opened and evaluated once the technical bid is evaluated and found qualified.



6.2.1. Clarification of tender documents

Written requests for clarification may be submitted to the Bank prior to the date mentioned for the submission of pre-bid queries and clarifications for such queries shall be provided by the Bank in the pre-bid meeting.

Form should preferably be emailed to the Bank or provided by softcopy – in either event hardcopy confirmations are to be submitted with the Bid documents.

The queries and clarifications wherever necessary shall be placed in Bank’s website under Tenders column.

6.2.2. Amendments to tender documents

Amendments to the Tender Document may be issued by the Bank for any reason, whether at its own initiative or in response to a clarification requested by a prospective bidder, prior to the deadline for the submission of bids.

The amendments will be posted on Bank’s web site and will be binding on all the bidders.

From the date of issue, amendments to Terms and Conditions shall be deemed to form an integral part of the RFP.

Further, in order to provide, prospective Bidders, reasonable time to take the amendment into account in preparing their bid, the Bank may, at its discretion extend the deadline for submission of bids.

6.3.1 Process of bids

Response to RFP The bidder shall submit the offer for the full schedule of requirements. Following instructions may please be taken note of in this connection.

All responses should be in English language. All responses including commercial and technical proposals would be deemed to be irrevocable offers/proposals from the Bidders and if accepted by Druk PNB Bank Ltd., form part of the final contract between Druk PNB Bank Ltd. and the selected Bidder. All envelopes should be securely sealed and stamped. The authorized signatories of the bidder should sign on all pages of the proposal.

All Bid Documents are to be properly filed in a box file and all pages of the Technical Bid should be numbered serially (Continuous page number/ Total number of pages) and should bear the company’s seal and signature/s of the authorized person/s on all pages. Documentary proof, wherever required, in terms of the RFP shall be enclosed.



6.4.1 Bid Documents:

Sealing and marking of Bids

The sealed cover containing the Technical offer should in turn be put in a sealed outer envelope to be super-scribed as “Technical offers for implementation and maintenance of AML application” with the RFP Reference number, due date, Name of the Bidder, etc.

The envelope containing Technical Offer should include only Bidder’s Profile (as per enclosed format), Relevant Technical Bid Forms and Standard Printed Technical Literature/Brochure etc., for the bid. The Technical Offer should be complete and indicate that all products and services asked for are considered.

Technical Offer document should not contain any price information.

Other Information required on the envelope and sub-envelopes – Demand Draft for the cost of the RFP, RFP reference number, Name of bidder, Contact Person, Contact Address, E-mail address and Phone number.

The eligibility and technical envelope should have the following documents: a. Cost of RFP

b. Bid security

c. Bid Form

d. All annexures as per RFP on Company’s letter head with authorizing person’s signature and company seal on all pages.

e. All supporting documents and product literature in support of Technical specifications

f. Relevant brochures for Hardware

g. Manufacturers’ Authorization Form as per Annexure-E, if applicable.

h. Technical Specifications as per Annexure-7 are to be furnished item wise.

Please furnish full details, ensuring strict conformity with the specifications in every respect, in order to avoid ambiguity. The software, if any, shall be supplied with Media, Manual and Licenses. Relevant Detailed Product Brochures shall be submitted for each item with the proposal.

The Technical Bids containing erasures or alterations will not be considered.

There should be no hand-written material, corrections or alterations in the Bids. Technical details must be completely filled in. Correct technical information of the product being offered must be filled in. Filling up of the information using terms such as “OK”, “Accepted” and “Noted”, “As given in Brochure/ Manual” is not acceptable. The Bank may treat such Bids as not adhering to the RFP guidelines and as unacceptable.

Bidder’s proposal should strictly conform to the Eligibility Criteria, Technical specifications and all other terms and conditions, stipulated in the RFP.



Proposals not conforming to the specifications will be treated as technically nonresponsive. Bank will not entertain any correspondence on this.

If the participating bidders need any clarification on any of the aspects of the Bid Document, they can seek clarifications in advance through e-mail to [email protected] on or before 20/04/2019 strictly as per Annexure –8 format.

The Bank reserves the right to make amendments to the RFP before the last date prescribed for submission of the responses. Such clarifications, amendments to our RFP, if any, will be sent to all the bidders through email and will form part of this RFP. Bidders are requested to take note of the same.

The Last date for submission of Bid proposals along with Bid Security and RFP is 29/04/2019 04.00 P.M (BST) at this office. Any Bids received after the due date and time will not be accepted.

Technical Bids complete in all aspects should be submitted in sealed master envelope to the Chief Executive Officer, Druk PNB Bank Ltd., Thimphu, Bhutan, PO Box No. 502 within the above stipulated date and time.

The commercial bid completed in all aspects should be sealed in a separate enveloped and carried in the Technical bid envelop.

6.4.2 Signing of the Bid

In the case of a body corporate, the bid shall be signed by the duly authorized officers and supported by internal corporate authorizations.

6.4.3 Bid submission

Bidders are not permitted to submit more than one bid.

The cost of bidding and submission of the bids is entirely the responsibility of the Bidders, regardless of the conduct or outcome of the tendering process.

Bids sealed in accordance with the Instructions to bidders should be delivered as mentioned in the Bid schedule. Bids may be sent by registered post or hand delivery, so as to be received at the address given below in contact details in the tender schedule.

Receipt of the bids shall be closed as mentioned in bid schedule. Bids received after the scheduled time will not be accepted by the Bank under any circumstances.

The technical bids will be opened as mentioned in bid schedule.

Bank will not be responsible for any delay due to postal service or any other means.



The bidders or their authorized representatives shall be present at the time of the opening of the technical bid. Only one person per bidder will be allowed to be present at the time of the opening the technical bids.

6.4.4 CONFIDENTIALITY OF THE BID DOCUMENT

The bidder, irrespective of his/her participation in the bidding process, shall treat the details of the documents as secret and confidential.

Bidder agrees that all information gathered from the Bank including oral enquires, letters, documents, emails, presentations, interactions, technical documentation, discussions with Bank’s service providers and documents gathered from Bank’s service providers etc. related to the Bank’s business and other information identified as confidential by the Druk PNB Bank Ltd. are confidential information of the Bank.

Unauthorized disclosure of any such confidential information will amount to breach of contractual terms and in such cases Bank may pre-maturely terminate the contract and initiate any legal action as deemed fit.

7. Evaluation of Bids

7.1. Evaluation Process:

The Bank will evaluate the bid submitted by the bidders under this RFP. If warranted, the Bank may engage the services of external consultants for evaluation of the bid. It is Bank’s discretion to decide at the relevant point of time.

The Technical Bid will be opened first for Technical Evaluation in the presence of bidders who choose to be present. The bidder is required to comply with the technical specifications mentioned in Annexure-7 of the RFP. Non-compliance to this may lead to disqualification of a bidder, which would be at the discretion of the Bank. The decision of Druk PNB Bank Ltd. would be final and binding on all the bidders to this document. Druk PNB Bank Ltd. may accept or reject an offer without assigning any reason what so ever.

The technical bids shall be evaluated by a committee. RFP evaluation methodology that the Bank would adopt is as given below:

The proposal submitted by the Bidders shall, therefore, be evaluated on the following criteria:

Parameter Weightage Maximum Score

Minimum

Score

Functional features evaluation of AML solution as stated in Annexure-7

40% 400 280

Technical Specification evaluation of solution and servers as stated in Annexure 7

10% 100 70

Bidder’s experience & capabilities 20% 200 140



Solution OEM’s experience & capabilities 10% 100 70

Product Demonstration & Technical Presentation for

the proposed solution

20% 200 140

Total 100% 1000 700

Bidder should ensure that any critical non-compliance against Annexure 7 - RESPONSE TO TECHNICAL & FUNCTIONAL SPECIFICATION may lead to disqualification

Bidders scoring at-least the minimum score under each section as mentioned in the table above and an overall score of 700 marks or more will be declared technically qualified. The evaluation approach is for each section is detailed in the table below:

Sl. No.

Technical Evaluation Evaluation Approach

1 Functional evaluation of AML solution as stated in Annexure 7

• For Functional Specifications, The Bidder shall be awarded full marks for a line item if it is Fully Compliant (FC) – No Customization is required, half marks for a line item if it is Partially Compliant (PC)- customization is required and no marks for a line item if it is, Non Complaint (NC)- Feature cannot be made available in the product

• Unreasonable scope limitations which defeat the purpose of

this RFP shall lead to reduction in scores or even possibility

of disqualification of the bidder. This will be at the sole

discretion of the Bank.



2 Technical evaluation of

solution and servers as

stated in Annexure 7

• The Bidder is required to submit the compliance to Minimum Technical Specifications of solution as stated in Annexure 7 (Maximum Marks 70)

• The Bidder is required to submit the compliance to Minimum Technical Specifications of servers as stated in Annexure 7. (Maximum Marks 30) Note:

For Technical Specification- Bidder should provide ‘yes’ or ‘no’. The Bidder shall be awarded full marks for a line item if it is responded as ‘Yes’ - No Customization is required, half marks for a line item if it is Partially Compliant (PC)- customization is required and no marks for a line item if it is, Non Complaint (NC)- Feature cannot be made available in the product

Unreasonable scope limitations which defeat the purpose of

this RFP shall lead to reduction in scores or even possibility

of disqualification of the bidder. This will be at the sole

discretion of the Bank.



3 Bidder’s experience &

capabilities

Number of resources

• Number of AML resources more than 50+ (excluding any back office teams) : 50 marks

• Number of AML resources more than 20 to 50 excluding any back office teams): 30 marks

The Bidder is required to provide an undertaking on company’s letter head for the above. 1. The Bidder should have had the experience of implementing / has under advanced stage of implementation large technology project in a Public Sector as a Bidder or subcontractor in any of the following areas:

a. AML Solution

b. Core Banking Solution

c. Enterprise Fraud Risk Management

Three Large Banks in India- 100 marks

• Two Large Banks in India- 70 marks

• One Large Bank in India- 50 marks (Large Bank – Having at least 1000 Branches at the time of implementing the referred solution). The Bidder will be awarded half of the above marks if the project is implemented in a scheduled commercial bank with more than 500 branches in India. Bidder is required to provide a copy of purchase order from the

bank. Further bank may at its discretion ask for site visit or

verification of details.



4 Solution OEM’s

experience &

capabilities

The OEM should have the past experience in Large Bank (Having at least 500 branches). • Five or more implemented project on the proposed OEM

solution for the above - 100 marks • Four implemented projects on the proposed OEM solution

for the above - 90 marks • Three implemented projects on the proposed OEM solution

for the above - 80 marks • Two implemented projects on the proposed OEM solution for

the above - 70 marks • At least one project implemented and one under

implementation, on the proposed OEM solution for the above - 60 marks

• Two or more projects under implementation on the proposed OEM solution for the above – 40 marks Note:

Further the OEM is required to provide a credential letter or copy of

purchase order of the past experience

5 Product Demonstration

and Technical

Presentation for the

proposed solution

The Solution OEM is required to demonstrate the product proposed to the bank. The bank will share the demonstration evaluation parameters/ test cases/ list of capabilities to be showcased to the Bidder/ OEM prior to the product demonstration- Maximum 100 marks

• Understanding of Bank’s business and Operating

• environment (20 Marks)

• Demonstration of organization capability for the proposed initiative, proposed solution architecture and sizing (20 Marks)

• Service Model demonstration and governance capabilities (20 Marks)

• Demonstration of value proposition offered in the bid which shall enable the success of the project. (20 Marks)

• Use cases and Case studies (20 marks)

The bidder’s scoring the minimum threshold stated in this section will be declared technically qualified and will be eligible for commercial bid evaluation.

7.3 Commercial Evaluation:

The format for quoting indicative commercial bid is set out in Annexure 13. The indicative commercial bid should consist of comprehensive Cost for required solution. Bidder must provide detailed cost breakup (for each line item) in the commercial bid.



The envelope containing the Indicative Commercial bid of only those Bidders, who will be short-listed after technical & functional evaluation and Solution evaluation, would be opened.

7.4 Final Evaluation:

1. Bank’s decision in respect to evaluation methodology and short-listing Bidders will be final and no

claims whatsoever in this respect will be entertained.

2. Calculation of marks would be rounded off to the nearest two decimal places.

3. Bank reserves the right to change/ relax the criteria for evaluation at its sole discretion.

Note: Bank reserves the right to reject this invitation to offer Bids in part or in full, or cancel the entire procurement process at any stage without assigning any reason.

8. BIDDER’S OBLIGATIONS: i. The Bidder is responsible for managing the activities of its personnel and will hold itself responsible

for any misdemeanors.

ii. The Bidder’s representative & local office in Bhutan will be the contact point for the Bank and all the

authentic status of Delivery and Installation should be made available in writing at least twice in a week.

iii. The Bidder will treat all data and information about the Bank, obtained in the execution of his

responsibilities as confidential and will not reveal such information to any other party without the prior written approval of the Bank.

8.1 TERMINATION FOR DEFAULT:

The Bank, without prejudice to any other remedy for breach of contract, by giving 30 days written notice of default sent to the Bidder and if the Bidder fails to cure the default within the notice period, may terminate this Contract in whole or in part:

i. If the Bidder fails to upgrade any or all of the Software within the period(s) specified in the Contract or within any extension thereof granted by the Bank.

ii. If the bidder fails to perform any other obligation(s) under the Contract.

iii. If the bidder is not providing after sales and maintenance services and the calls are not attended

for three or more occasions the Bank is at liberty to terminate the contract by giving 30 days’ notice.

iv. Delay in Implementation of the Project beyond the specified periods.



v. Non satisfactory performance of the Project during implementation.

vi. Failure to upgrade the project as per the requirements of the Bank.

vii. Serious discrepancies noted in the implementation of the project.

viii. Breaches in the terms and conditions of the Order.

ix. Non satisfactory performance of the Project in terms of affecting the Core Systems of the Bank

The Bank reserves its right to cancel the entire / unexecuted part of Purchase Order at any time by without assigning appropriate reasons in the event of one or more of the above conditions.

In addition to the cancellation of purchase order, the Bank reserves its right to invoke the Performance Bank Guarantee given by the bidder.

8.2 EFFECT OF TERMINATION:

i. The bidder agrees that it shall not be relieved of its obligations under the reverse transition mechanism notwithstanding the termination of the assignment. Reverse Transition mechanism would typically include service and tasks that are required to be performed / rendered by the bidder to the Bank or its designee to ensure smooth handover and transitioning of Bank’s deliverables and maintenance. The reverse transition will be for the period of 3 months post the notice period.

ii. Same terms (including payment terms) which were applicable during the term of the contract should be applicable for reverse transition services

iii. The bidder agrees that after completion of the Term or upon earlier termination of the assignment

the bidder shall, if required by the Bank, continue to provide warranty services to the Bank at no less favorable terms than those contained in this RFP. In case the bank wants to continue with the bidder’s services after the completion of this contract then the bidder shall offer the same or better terms to the bank. Unless mutually agreed, the rates shall remain firm.

iv. The Bank shall make such prorated payment for services rendered by the bidder and accepted

by the Bank at the sole discretion of the Bank in the event of termination, provided that the bidder is in compliance with its obligations till such date. However, no payment for “costs incurred, or irrevocably committed to, up to the effective date of such termination” will be admissible. There shall be no termination compensation payable to the bidder.

v. Termination shall not absolve the liability of the Bank to make payments of undisputed amounts

to the bidder for services rendered till the effective date of termination. Termination shall be without prejudice to any other rights or remedies a party may be entitled to hereunder or at law and shall not affect any accrued rights or liabilities or either party nor the coming into force or



continuation in force of any provision hereof which is expressly intended to come into force or continue in force on or after such termination.

8.3 INDEMNITY:

i. The selected bidder shall indemnify, protect and save the Bank against all claims, losses, costs, damages, expenses, action suits and other proceedings, resulting from infringement of any law pertaining to patent, trademarks, copyrights, Intellectual Property Rights (IPR) etc.

ii. Selected Bidder shall keep the Bank, its Successors, Assignees and Administrators fully

indemnified and harmless against loss or liability, claims actions or proceedings, if any, that may arise from whatsoever nature caused to the Bank through the action of its employees, agents, contractors, subcontractors etc.

iii. The indemnification is only a remedy for the Bank. The Selected Bidder is not absolved from its

responsibility of complying with the statutory obligations as specified above.

iv. Indemnity would be limited to court awarded damages and shall exclude indirect, consequential

and incidental damages. However, indemnity would cover damages, loss or liabilities suffered by the Bank arising out of claims made by its customers and/or regulatory authorities.

v. However, the Selected Bidder would be given an opportunity to be heard by the Bank prior to

making of a decision in respect of such loss or damage.

8.4 LIABILITY OF THE SELECTED BIDDER:

i. Bank shall hold the selected bidder, its Successors, Assignees and Administrators fully liable against loss or liability, claims, actions or proceedings, arising out of non-fulfillment of any obligations under the Contract.

ii. Selected Bidder shall be the principal employer of the employees, agents, contractors,

subcontractors etc. engaged by Selected Bidder and shall be vicariously liable for all the acts, deeds or things done by its employees, agents, contractors, sub-contractors etc., whether the same is within the scope of power or outside the scope of power, vested or instructions issued by the Bank under the Contract to be issued for this tender.

iii. Such liability of the Selected Bidder will be restricted to the actual amount of the Contract.

iv. However, the selected bidder would be given an opportunity to be heard by the Bank prior to

making of a decision in respect of such loss or damage.

8.5 NEGLIGENCE:



In connection with the work or contravenes the provisions of General Terms, if the selected bidder neglects to execute the work with due diligence or expedition or refuses or neglects to comply with any reasonable order given to him in writing by the Bank, in such eventuality, the Bank may after giving notice in writing to the selected bidder calling upon him to make good the failure, neglect or contravention complained of, within such times as may be deemed reasonable and in default of the said notice, the Bank shall have the right to cancel the Contract holding the selected bidder reliable for the damages that the Bank may sustain in this behalf. Thereafter, the Bank is to be compensated for good the failure at the risk and cost of the selected bidder.

8.6 FORCE MAJEURE:

i. The bidder shall not be liable for forfeiture of its performance security, liquidated damages or termination for default, if and to the extent that it’s delay in performance or other failure to perform its obligations under the contract is due to an event of force Majeure. For purposes of this Clause,

“Force Majeure” means an event beyond the control of the bidder and not involving the bidder’s fault or negligence and not foreseeable. Such events may include, but are not limited to, Acts of nature or of public enemy, acts of Government of Bhutan in their sovereign capacity, acts of war, and acts of the Bank either in fires, floods, strikes, lock-outs and freight embargoes.

ii. If a Force Majeure situation arises, the bidder shall promptly notify the Bank in writing of such

conditions and the cause thereof immediately. Unless otherwise directed by the Bank in writing, the bidder shall continue to perform its obligations under the Contract as far as it is reasonably practical, and shall seek all reasonable alternative means for performance not prevented by the Force Majeure event.

iii. In such a case, the time for performance shall be extended by a period(s) not less than the duration of such delay. If the duration of delay continues beyond a period of three months, the Bank and the bidder shall hold consultations with each other in an endeavor to find a solution to the problem.

iv. Notwithstanding the above, the decision of the Bank shall be final and binding on the bidder. 8.7 RIGHTS OF THE BANK The Bank also reserves the right to change any terms and conditions of the RFP and its subsequent addendums as it deems necessary at its sole discretion up to the date of submission of bids.

The Bank reserves the right to extend the dates for submission of responses to this document.

Bidder shall have the opportunity to clarify doubts pertaining to the RFP in order to clarify any issues they may have, prior to finalizing their responses.

i. Preliminary Scrutiny – The Bank will scrutinize the offer to determine whether it is complete,

whether any errors have been made in the offer, whether required technical documentation has been furnished, whether the documents have been properly signed, and whether items are



quoted as per the schedule. The Bank may, at its discretion, waive any minor nonconformity or any minor deficiency in an offer. This shall be binding on the Bidder and the Bank reserves the right for such waivers and the Banks decision in the matter will be final.

ii. Clarification of Offer – To assist in the scrutiny, evaluation and comparison of offer, the Bank

may, at its discretion, ask the Bidder for clarification of their offer. The Bank has the right to disqualify the Bidder whose clarification is found not suitable to the proposed project. The Bank reserves the right to make any changes in the terms and conditions of RFP. The Bank will not be obliged to meet and have discussions with any Bidder, and / or to listen to any representations.

iii. Erasures or Alterations – The offer containing erasures or alterations will not be considered.

iv. There should be no hand-written material, corrections or alterations in the offer. Technical details

must be completely filled up. Correct technical information of the product being offered must be filled in. Filling up of the information using terms such as “OK”, “accepted”, “noted”, “as given in brochure / manual” is not acceptable. The Bank may treat the offers not adhering to these guidelines as unacceptable.

v. Pricing – It is absolutely essential for the Bidder to quote the lowest price at the time of making

the offer in its own interest. In the event of Bank not satisfied with the Price Discovery in this process, bank reserves the right to initiate the tendering process again through Limited or Open tender.

8.8 INFORMATION OWNERSHIP

All information processed, stored, or transmitted by bidder equipment belongs to the Bank. By having the responsibility to maintain the equipment, the bidder does not acquire implicit access rights to the information or rights to redistribute the information. The bidder understands that civil, criminal, or administrative penalties may apply for failure to protect information appropriately

8.9 PUBLICITY

Any publicity by the Bidder in which the name of the Bank is to be used should be done only with the explicit written permission of the Bank.

8.10 INSPECTION OF RECORDS

All bidder’s records with respect to any matters covered by this RFP shall be made available to the Bank or its designees at any time during normal business hours, as often as the Bank deems necessary, to audit, examine, and make excerpts or transcripts of all relevant data. Said records are subject to examination. Bank’s auditors would execute confidentiality agreement with the bidder, provided that the auditors would be permitted to submit their findings to the Bank, which



would be used by the Bank. The cost of the audit will be borne by the Bank. The scope of such audit would be limited to Service Levels being covered under the contract, and financial information would be excluded from such inspection, which will be subject to the requirements of statutory and regulatory authorities.

8.11 COMPLIANCE WITH LAWS

i. Compliance with all applicable laws: The bidder shall undertake to observe, adhere to, abide by, comply with and notify the Bank about all laws in force or as are or as made applicable in future, pertaining to or applicable to them, their business, their employees or their obligations towards them and all purposes of this tender and shall indemnify, keep indemnified, hold harmless, defend and protect the Bank and its employees/officers/staff/ personnel/ representatives /agents from any failure or omission on its part to do so and against all claims or demands of liability and all consequences that may occur or arise for any default or failure on its part to conform or comply with the above and all other statutory obligations arising there from.

ii. Compliance in obtaining approvals/permissions/licenses: The bidder shall promptly and timely

obtain all such consents, permissions, approvals, licenses, etc., as may be necessary or required for any of the purposes of this project or for the conduct of their own business under any applicable Law, Government Regulation/Guidelines and shall keep the same valid and in force during the term of the project, and in the event of any failure or omission to do so, shall indemnify, keep indemnified, hold harmless, defend, protect and fully compensate the Bank and its employees/ officers/ staff/ personnel/ representatives/agents from and against all claims or demands of liability and all consequences that may occur or arise for any default or failure on its part to conform or comply with the above and all other statutory obligations arising there from and the Bank will give notice of any such claim or demand of liability within reasonable time to the Bidder.

8.12 RESOLUTION OF DISPUTES

i. All disputes and differences of any kind whatsoever arising out of or in connection with the

Purchase Order shall be referred to arbitration. The arbitrator may be appointed by both the parties or in case of disagreement each party may appoint an arbitrator and such arbitrators shall appoint an Umpire before entering on the reference. The decision of the Umpire shall be final. Such arbitration shall be governed by the provisions of Bhutan Arbitration Act

ii. Notwithstanding anything contained herein above, in case of any dispute, claim and legal

action arising out of this RFP, the parties shall be subject to the jurisdiction of courts at Thimphu, Bhutan only.

8.13 ASSIGNMENT

Bank may assign the hardware, software and other equipment (including electrical and civil) provided therein by the bidder in whole or as part of a corporate reorganization, consolidation,



merger, or sale of substantially all of its assets. The Bank shall have the right to assign such portion of the AMC/ATS services to any of the sub-contractors or 3rd party, at its sole option, upon the occurrence of the following:

i. bidder refuses to perform;

ii. bidder is unable to perform;

iii. termination of the contract with the bidder for any reason whatsoever;

iv. Expiry of the contract.

Such right shall be without prejudice to the rights and remedies, which the Bank may have against the bidder. In the event of bidder hiring a sub-contractor / 3rd party, the bidder shall ensure that the said subcontractors or 3rd party shall agree to provide such services to the Bank at no less favorable terms than that provided by the bidder and shall include appropriate wordings to this effect in the agreement entered into by the bidder with such sub-contractors.

The assignment envisaged in this scenario is only in certain extreme events such as refusal or inability of the bidder to perform or termination/expiry of the contract

8.14 OWNERSHIP, GRANT AND DELIVERY

i. The Bidder shall procure and provide a non-exclusive, non-transferable, perpetual license to the Bank for all the software to be provided as a part of this project. The use of software by bidders on behalf of the Bank would be considered as use thereof by the Bank and the software should be assignable / transferable to any successor entity of the Bank.

ii. The bank reserves the right to use the excess capacity equipment supplied by the bidder for any

internal use of the Bank or its affiliates, subsidiaries or regional rural bank at no additional cost other than the prices mentioned in the commercial bid. The bidder agrees that they do not have any reservations on such use and will not have any claim whatsoever against such use of the hardware, licenses and other equipment. Further the bidder also agrees that such use will not infringe or violate any license or other requirements.

8.15 PRIVACY & SECURITY SAFEGUARDS

The bidder shall not publish or disclose in any manner, without the Bank’s prior written consent, the details of any security safeguards designed, developed, or implemented by the bidder under this contract or existing at any Bank location. The bidder shall develop procedures plans to ensure that IT resources leaving the control of the assigned user (such as being reassigned, removed for repair, replaced, or upgraded) are cleared of all Bank data and sensitive application software. The bidder shall also ensure that all subcontractors who are involved in providing such security safeguards or part of it shall not publish or disclose in any manner, without the Bank’s prior written consent, the details of any security safeguards designed, developed, or implemented by the bidder under this contract or existing at any Bank location.



8.16 GUARANTEES

Bidder should guarantee that the software and allied components used to service the Bank are licensed and legal. All hardware, related software and other equipment must be supplied with their original and complete printed documentation.

Bidders should provide reasonable level of assurance about the application being free of malware at the time of sale, free of any obvious bugs, and free of any covert channels in the code (of the version of the application being delivered as well as any subsequent versions / modifications done).

CONTRACT RE-NEGOTIATION

i. The Bank will reserve a right to re-negotiate the price and terms of the entire contract with the bidder at more favorable terms in case such terms are offered in the industry at that time for projects of similar and comparable size, scope and quality.

ii. The Bank shall have the option of purchasing the equipment from third-party suppliers, in case

such equipment is available at a lower price and the bidder’s offer does not match such lower price. Notwithstanding the foregoing, the bidder shall continue to have the same obligations as contained in this RFP in relation to such equipment procured from third-party suppliers.

iii. As aforesaid the Bank would procure the equipment from the third party only in the event that

the equipment was available at more favorable terms in the industry, and secondly, The Equipment procured here from third parties is functionally similar, so that the bidder can maintain such equipment. The modalities under this right to re-negotiate /re-procure shall be finalized at the time of contract finalization.

8.18 CORRUPT AND FRAUDULENT PRACTICES

i. As per the Anti-Corruption Act of Bhutan directives, it is required that bidders / Suppliers /

Contractors observe the highest standard of ethics during the procurement and execution of such contracts in pursuance of this policy:

ii. “Corrupt Practice” means the offering, giving, receiving or soliciting of anything of values to influence the action of an official in the procurement process or in contract execution AND

iii. “Fraudulent Practice” means a misrepresentation of facts in order to influence a procurement process or the execution of contract to the detriment of the Bank and includes collusive practice among bidders (prior to or after offer submission) designed to establish offer prices at artificial non-competitive levels and to deprive the Bank of the benefits of free and open competition.

iv. The Bank reserves the right to reject a proposal for award if it determines that the bidder

recommended for award has engaged in corrupt or fraudulent practices in competing for the



contract in question. The Bank reserves the right to declare a firm ineligible, either indefinitely or for a stated period of time, to be awarded a contract if at any time it determines that the firm has engaged in corrupt or fraudulent practices in competing for or in executing the contract.

8.19 WAIVER: No failure or delay on the part of either party relating to the exercise of any right power privilege or remedy provided under this RFP or subsequent agreement with the other party shall operate as a waiver of such right power privilege or remedy or as a waiver of any preceding or succeeding breach by the other party nor shall any single or partial exercise of any right power privilege or remedy preclude any other or further exercise of such or any other right power privilege or remedy provided in this RFP all of which are several and cumulative and are not exclusive of each other or of any other rights or remedies otherwise available to either party at law or in equity.

8.20 VIOLATION OF TERMS The Bank clarifies that the Bank shall be entitled to an injunction, restraining order, right for recovery, suit for specific performance or such other equitable relief as a court of competent jurisdiction may deem necessary or appropriate to restrain the bidder from committing any violation or enforce the performance of the covenants, obligations and representations contained in this RFP. These injunctive remedies are cumulative and are in addition to any other rights and remedies the Bank may have at law or in equity, including without limitation a right for recovery of any amounts and related costs and a right for damages.

8.21 NON-DISCLOSURE OF INFORMATION:

The Selected Bidder shall not, without the Bank’s prior written consent, disclose any specification, plan, drawing, pattern, sample, or information furnished by or on behalf of the Bank in connection therewith, to any person other than a person employed by the Bidder in the performance of the work assigned to them. The Selected Bidder shall be required to sign a Non-Disclosure Agreement with the Bank as per the prescribed format provided in Annexure 9.

8.22 NO COMMITMENT TO ACCEPT LOWEST OR ANY OFFER/BID:

BANK shall be under no obligation to accept the lowest or any other offer received in response to this offer notice and shall be entitled to reject any or all offers without assigning any reason whatsoever. BANK has the right to re-issue tender / bid. BANK reserves the right to make any changes in the terms and conditions of RFP that will be informed to all bidders. BANK will not be obliged to meet and have discussions with any bidder, and / or to listen to any representations once their offer/bid is rejected. Any decision of BANK in this regard shall be final, conclusive and binding upon the bidder.

Yours faithfully,



General Manager

ANNEXURE - I To, Date

The Dy. Chief Executive Officer, Place

Druk PNB Bank Ltd.

Thimphu, Bhutan

Dear Sir,

RFP Ref No: DPNBL/COM-AML/2019/…. dated April 10, 2019

Declaration and Acceptance of Terms and Conditions and Confirmation of offer

The details submitted in this document are true and correct to the best of our knowledge. If it is proved otherwise at any stage of execution of the contract, Druk PNB Bank Ltd. has the right to summarily reject the proposal and disqualify us form the process.

We confirm having understood the entire bid process, contents of RFP with all its terms and conditions and undertake to abide by the terms and conditions.

We have also understood that the Bank may add, alter, modify the terms and conditions and post the required information in its web-site and all such additions, modifications, alterations will form part of the RFP.

We hereby acknowledge and confirm having accepted that the Bank can at its absolute discretion apply whatever criteria it deems appropriate and fit, not just limiting to those criteria set out in the RFP, in short listing of bidders.

We confirm having met all the criteria set out for Bidder’s eligibility including financial soundness.

We also confirm that we are not blacklisted by any Government organization or Govt. agency or Banks in Bhutan There is no legal action against our organization for any cause in any legal jurisdiction which will impose restrictions to the ability of the Bidder in carrying out its obligations under this RFP.



We confirm and warrant that key project personnel to be deployed in this project have sufficient knowledge and been sufficiently involved in similar projects in the past.

Authorized Signatory with Seal Annexure – 2 Bidder Constitution and Contact Profile Company Profile 1. Name of the Company :

2. Address of Registered Office / Head Office:

3. Phone Number (with STD Code) :

4. Fax Number :

5. E-mail id :

6. Constitution (Public Ltd Co., / Pvt Ltd Co./ Partnership/ Proprietary Concern etc.) :

7. Date of Establishment :

8. Name of Chief Executive :

9. Name of Local Contact Person & Phone No:

10. Location of Factory, if applicable :

11. Line of Activity :

12. Date from which the product offered in The tender are marketed :

13. Products Developed / Serviced :

(Attach product literature)

14. Details of Quality Certifications Obtained



For the Company & its Products, such

as ISO- 9001:2000 etc. (attach Photostat copies).

15. Total Number of Employees :

Date:

Place: Authorized Signatory with Seal

Annexure 3

Financial Details of the Company (To be included in Technical Bid Envelope) (In Million Nu)

2014-15 2015-16 2016-17

Audited (A) Provisional (P)

/ (A) (A) (A/P)

Paid up Capital

Tangible Net Worth

Total Assets

Total Sales (net excise)

of

PBDIT

Profit after Tax

Attach annual reports / duly audited financial statements for the latest three financial years. Date: Place: Signature of Authorized Official with Seal



Annexure 4

Bidder’s Support Centre at Thimphu, Bhutan Number of Offices in Bhutan & places: Furnish information about Support Centers at Thimphu, Bhutan

Sl. No.

City / State Address Name of Person In-charge and Phone No

No. Of Qualified Support Engineers & their

qualifications

Whether adequate trained Manpower, knowledge base & stock of spares available for support

Date: Place: Signature of Authorized Official with Seal



Annexure 5

Credentials: Projects handled by bidder (Multiple sheets to be used to provide reference site details)

Details of AML projects implemented and maintained by the Bidder

REFERENCE SITE

DETAILS:

Organization details

Contact person details with

address, phone numbers (Land /

Hand), and email id.

Details of the project

Broad outline of architecture

Platform details




Annexure 6 Eligibility Criteria

Eligibility Criteria Support Documents to be submitted Compliance

The bidder should be a Registered entity /

Company under the Companies Act for the last five

years as on date of RFP.

Copy of certificate of Incorporation and Articles of Association should be submitted along with the bid or the relevant certificates of Registration.

The AML Solution OEM must be a company/ entity

incorporated and operating for 5 years as on the

date of RFP

Copy of certificate of incorporation and Articles of Association should be submitted along with the bid or the relevant certificates of Registration

The Bidder should be a profit making company/ firm for at least 2 out of three preceding financial years and shall have positive Net worth. 2015-16 2016-17

2017-18

Certified copies of Audited Financial Statements (and Annual Reports, if applicable) for the last three financial years. (Also furnish the information in Annexure-6)

4) Bidder should have an turnover of Nu.50 million (Nu. fifty million) or above for the last three consecutive financial years. 2015-16 2016-17

2017-18

Certified copies of Audited Financial Statements or

certificate from Auditors providing the Turn Over

details for the last three years. (Also furnish the

information in Annexure-6)

5) The bidder should be the owner or certified / authorized agent of the solution offered

Letter from the OEM authorizing the bidder to

participate in the RFP or agreement with the solution

provider with reference to the solution offered should

be submitted along with the bid. In case OEM is

directly participating self-declaration has to be

provided.

6) The bidder company should have valid ISO

9000/ 9001 & ISO/ IEC 27001 certification

Copy of the ISO 9000/ 9001 & ISO/ IEC 27001

certificate should be submitted along with the bid

7) The bidder should be in the business of

providing services in the area of Anti Money

Laundering with at least 25 member team.

Undertaking from the bidder on bidder’s letter head

signed by the authorized signatory of the bidder.

8) The OEM should have a dedicated Centre in

Bhutan.

Undertaking from the bidder on bidder’s letter head

signed by the authorized signatory of the bidder.

9) The Solution OEM must have at least 25 skilled

staff experienced in implementing AML Solution &

should be able to deliver and support the proposed

solution.

Self-Declaration from the Solution OEM on the

company’s letter head signed by the authorized

signatory of the OEM



10) The Bidder should have the experience of Implementing / has under implementation at least one project for a Commercial Bank with more than 500 branch. Projects which qualify are any one of the following: 1. AML Solution 2.Enterprise Fraud Risk Management Solution

3. Core Banking Solution

4. Data Warehousing Solution


11) The Proposed AML Solution should have been implemented/ or should be under implementation in at least in one Commercial Bank having a minimum of 500 branches


12) The bidder/ OEM should not have been black listed by any Govt. Financial Institutions / Banks/ Government departments/ Semi-Government

departments /RMA.

A self-declaration by the Bidder and OEM

13) The Bidder’s company and OEM should not be

owned or controlled by any Director or Employee

(or relatives) of Druk PNB Bank Ltd.

A self-declaration by the Bidder and OEM on

Company’s letter head.

14) The bidder and OEM should have service / support infrastructures at Thimphu, Bhutan and should be able to provide efficient and effective support at the banks premises. Bidder shall ensure back to back availability of support from OEM. A letter from OEM in this regard shall be submitted

as part of bid. A list of service /support center be

submitted as a part of tender document.

Letter from bidder and OEM to this effect with full address of service centers at Thimphu, Bhutan should be produced.




Annexure 7 Technical Specification Detailed functional and technical requirements for the Anti-Money Laundering Solution

TECHNICAL REQUIREMENT

01 The vendor shall specify the database type and version used for solution.

02 The vendor agrees to provide documents detailing the Architecture, the hardware,

Operating Software, database structure, middleware and other software required for

the AML/CFT Solution.

03 The application software offered by the bidder should have adequate redundancy,

fault tolerance and Disaster recovery arrangement.

04 Selected Bidder will also provide hardware sizing keeping in view of the 20% growth

rate for the next 5 years

05 The bidder will have to render customization, develop, install, implement, migration of

existing database, integrate, and provide support / maintenance, services to our staff

at the respective Centralized Processing Centre for AML / CFT.

06 The solution should be capable to support for 20% growth in database on YOY basis

for next 5 years

07 Software should be Hardware Independent, and should be able to support Operating

Software, Database (Preferably using Big Data Analytics), and Middleware on latest

release version and should support the latest versions as released by the OEM.

08 System should be three tier (Web/App/DB) web based and should be able to support

simultaneous use of the system by multiple users without any restriction.

09 Software should support web based Alert management deployed to distribute alerts to

HO/Branch level users and for getting feedback on Alerts & dash board for monitoring

the status of Alerts to fix user level bench marks for closing alerts. Provision to verify

and put comments by Concurrent /Internal Auditors must be provided in the Software

10 Separate DRS/Backup/Test server to be configured for smooth Functioning of daily AML Alert generation and monitoring process.



12 CMS- Change Management System should be in place to monitor any changes being

performed in system. The application provider needs to maintain version control,

patch management, upgrade and other changes, etc. as per bank’s guidelines.

13 Upgrades – All upgrades to the Application should be provided

periodically(monthly/quarterly) without waiting on release of Version Upgrade

14 The application software offered by the bidder should have adequate redundancy,

fault tolerance and Disaster recovery arrangement. The solution should support more

than one redundant server i.e. local clustering and remote replica (for DR).

15 The solution should be capable to be implemented in Virtual Environment?

16 The solution should support automatic archival / purging

17 The components of system should support multi-processor architecture with load

sharing capability.

18 The system should support Service Oriented Architecture

19 The system should run in high availability or fault tolerant modes.

20 The application should support modular architecture.

21 The application should support Bulk Static Data upload facility.

22 The solution should provide data masking tool/utility.

23 The product/solution should offer user interface/data-store/reports.

24 The application should take care of rollback and roll-forward features in the event of a

transaction failure.

25 The administration functions should be handled through thin client.

26 The Web, DB or application module support single sign-on using various modules.

27 There should be no limitations or possible security conflicts at your Database/

Application modules

28 The network transmission data packets of client/server or middle-tier support should

support encryption/decryption method.

29 The user access to the database (from the application) should be encrypted.

30 The solution should have out of the box functionality for generation of MIS reports and

ad-hoc reports as required by the bank in the format as desired by the Bank and

regulators (e.g. build by the vendor, crystal, SQL reporting…etc.)

31 The solution should not have any resource limits (memory /disk /threads etc.) that

would prohibit the product from continuous running?

32 The solution should be flexible enough to migrate applications from one Database to

the other



33 The solution should have tools to migrate & mask data across different databases

34 The solution should be capable enough to archive information to reside in a separate

database and yet be available online as and when required by the end-user

35 The solution should be configurable to support holding of minimum 5 or more years

MIS data

36 The solution should have built-in data warehouse facility in the proposed solution.

Data mining procedures and capabilities to be explained.

37 The solution should have flexible, form based input for managing parameters, and

creating new scenarios and risk factors to monitor risks.

38 system should be able to distribute securely across multiple remote (geographic)

environments and servers

39 There should be provision to assign higher processor and I/O resources at

administrator level to handle high volume of transaction during peak hours

40 The solution should be able to deploy remotely

41 Is input data validated for type, length, format and range?

42 Does application accepts special characters (like <>?:;?} {][|\)(*&^%$#!` )?

43 Can User define unacceptable characters in the system?

44 Does the solution integrate with any third party configuration management tools? System should support to integrate all the other softwares adopted by the bank. For ex. CBS(FCR&FCC)/NEFT/RTGS/LAPS/CARDS SOFTWARE / SWIFT / ATM / Internet Banking / Mobile Banking.

45 The solution should provide development platform along with the product suite.

46 The solution should support in-house development/customizations to be done by the

Bank Team

47

Can third party development tools be used with the solution?

51

The tool should have the provision to monitor transactions of our London Branch in

multiple currencies

52 Separate DRS/Backup/Test server to be configured for smooth functioning of daily

AML Alert generation and monitoring process.

75 The solution should be capable enough to archived information to reside in a

separate database and yet be available online as and when required by the end-user



76 The solution should be configurable to support holding of minimum 5 or more years

MIS data

78 The solution should have form based input for managing parameters

79 System should be able to distribute securely across multiple remote (geographic)

environments and servers

80 There should be provision to assign higher processor and I/O resources at

administrator level to handle high volume of transaction during peak hours

85 Does the solution integrate with any third party configuration management tools?

89 Availability of source code for review to the Bank for security review at the discretion

of the Bank or whenever there is any change in the code.

90 Secured code practices are being followed by the developers for the solution.

91 The vendor should provide pre-built test scripts (e.g. for Regression testing; testing

and launching of new products / features etc.)

92 The vendor should implement, as part of the project plan, timely reporting on project

risk events and responses to appropriate levels of management (including the use of

Key Risk Indicators, as appropriate).

93 UAT should be implemented as per SLA.

94 The application should seamlessly integrate with all proposed modules

95 The solution should support standard protocols governing data and services

standards e.g. XML based messaging, Simple Object Access Protocol (SOAP), Web

Services Development Language (WSDL), etc.

96 The system should support standard API for interface & integration with ancillary

applications

97 The system should have APIs that support interface through middleware

98 The system should support the standards for data exchange & messaging formats including ISO 8583,TCP/IP,SWIFT,SEPA,GEVA,FED,CHIPS etc.

99 The System should provide priority processing of transactions, messages, offices etc.

for online screening.

100 The system should maintain core source code with a third party a backup

101 The solution should be able to maintain the active session status in database

102 The solution should allow multiple connections/sessions per user?



103 The Bank should be able to customize security settings fully

104 The security architecture of system should use a granular Role Based Access Control

(RBAC) architecture

105 The Solution should support multi-factor authentication as per four eye principle.

106 The security software used should be independent of the hardware and Operating

System Software

107 The security system should have the capability to integrate with leading Identity

Management Systems e.g. Privilege Identity Management System, etc.

108 The solution should able to deploy 3rd party security certificates

109 The solution should have capability to define password policies as directed by the

Bank Policies.

110 Penetration testing done has not shown any vulnerability of Critical , high or medium

category on the application

111 The solution should take precautionary measures to prevent data modification during

transit

112 There should be controls provided for protecting sensitive data from unauthorized

access or modifications

113 Database connections, passwords, keys and other sensitive information are stored in

encrypted form.

114 Database/modules supports/enables audit trail of (user/Admin, logon/logoff,

transaction, DB Object, Privilege granted) at various levels?

115 The audit trail should record information such as, data source IP address, destination

IP address, date, time stamp of transfer, file name and username etc.

116 Up gradation to new release should be part of AMC during period of contract

117 Confirm that the source code of the application has been reviewed by an independent

third party and all vulnerability found have been resolved. Bidder shall share a copy of

source code review if selected by the Bank

118 Provision for generation of letters to the branches offices against the

account/accounts based on Alert scenario generated and also can allow to send

individually or bulk.

119 Provision for sending information to particular Branch Office in quick manner by using

suitable channel as per bank’s available infrastructure. (System Should have the

ability to Integrate with sources like I P Messaging systems / SMS / Email/any other

secured channel.)



120 System should be able to categorize accounts into risk categories (low/medium/high)

as per the guidelines of the Regulators/Bank.

B REGULATORY REQUIREMENTS

121 Compliance with the FIU requirements, Statutory requirements and guidelines of

regulators, on AML/CFT from time to time.

122 The solution should address and be compliant with the Financial Action Task Force

(FATF), Egmont, World Regulators recommendations and be flexible to include other

lists.

123 Able to provide resolution of Regulatory Requirements on Immediate basis. The

bidder is responsible for generation of statutory reports in the format required by

regulatory bodies.

124 The Proposed Solution should be able to store data as per Banks retention policy. During this period, Data recall should not require any additional coding or additional retrieval procedure. The archival and retrieval programs should facilitate easier analysis of old data. Provide adequate backup and recovery features.

C GENERAL

125 The system should enable creation of different access groups with different access control. Users may belong to multiple groups. The proposed solution should allow users to be controlled (creation, activation, deactivation, deletion etc.) by a specific administrator. System must have a Login ID and password for each user for logging and also supports Remote logging. The system must have a comprehensive log files with every user’s activity (including

action taken by the user). Facility to audit the whole process from logs reports at any

future date.

126 The Solution should come with access capabilities to consolidate enterprise- wide data. The solution should come with Data Manipulation & Predictive Analytics Capability.

127 The Solution should come with the scheduling and refresh of your solution

128 The Solution should come with ad-hoc query, data visualization, predictive analytics

profiling, clustering & segmentation

129 The Solution should come with the feedback loop & self-learning

130 The Solution should come with the support the detection of new unknown patterns of

suspicious activity



D RULES - RULE MANAGEMENT

131 The rules stored in should be easily accessible repository

132 The solution should be capable of performing impact analysis on rule changes(I.e.

"what-if")

133 The solution should be capable of re- running the rules "as-of" point in time

134 Can rules be produced using rule wizards and/or templates?

135 Is rule versioning maintained?

136 Is an audit trail for rule changes maintained?

137 Can rule changes be rolled back

138 The system should not have limitations for the rules set up by the users

139 Rule Service Invocation

140 Are rules invoked directly by the application?

141 Can rules be called individually by the user?

142 Can rules be structured that invoke other rules (i.e. decision chain)?

E GENERAL BANKING SURVEILLANCE

143 Can the application identify structured cash transactions?

144 The application should have ability to identify transactions that may conceal beneficial

owners

145 The application should have ability to monitor transactions involving internal accounts (for example: staff accounts, Corporate Concentration Accounts, etc.)

146 The application should have ability to flag transactions in excess of a certain amount

147 The application should have ability to identify movement of cash into monetary

instruments from one financial institution to another

148 The application should have ability to monitor/flag suspicious cross border

transactions

F CASE MANAGEMENT AND WORKFLOW

149 The solution should have ability to prioritize cases according to predefined rules in the

case management system. Please describe the functionality and the ability for the

user to define the rules.

150 The solution should have ability to reassign closed alerts. The solution should select

closed alerts on random basis for reassignment as per bank’s discretion based on %

of alerts.

151 The solution should have the provision for Bulk closure of Alerts



152 System should be capable of providing list of closed alerts for Audit purpose by

Regulators such as RMA, FIU-BHUTAN etc.

153 Scenario wise reassignment of alerts facility should be available

154 The solution should have ability to manually change priority or score of a suspicious

transaction or event.

155 The solution should have ability to assign / change status of a suspicious transaction

or event.

156 The solution should have ability to assign / change assigned analyst to a suspicious

transaction or event.

157 The solution should have ability to funnel alerts to a pool that may then be worked on

by individual analysts.

158 Does the application allow another analyst to work on a case after it has been

initiated by someone else?

159 Does your application track key milestone dates in a case (e.g. date open, date

closed)?

160 The solution should have ability to distribute cases based on descriptive criteria (e.g.

business unit, score, product, alert type)

161 The solution should have ability to configure alerts to automatically produce an email

162 The solution should have ability to create a case either manually or automatically

based on user defined criteria

163 The solution should have ability to age and view alerts at a summary level (e.g. #

days open)

164 The solution should have ability to monitor audit trail (including action taken) by user

ID

165 The solution should have ability to monitor resolution statistics by alert type, analyst

name, date and other categories.

166 The solution should have ability to protect user input so that no other analyst can alter

information entered.

167 The solution should have ability to associate detailed transaction data with a case.

168 Provision for identifying the Multiple customers IDs. (UCIC/De duplication Model).

Capable of grouping of the data of multiple CIFs into Branch wise and Region wise for

de-duplication and keeping the track record of de duplication process/progress.

169 The solution should have ability to archive cases offline and restore case as needed.

170 The solution should have ability of the application to present other account data (e.g.

type, amount) for a given case



171 The solution should have ability to update a rule or profile integrated with the case

management tool

172 The solution should have ability for administrator to manage individuals or groups.

173 Capability to handle the addition of new cases while existing cases are currently

being worked on from the same day or prior periods.

174 The solution should come with queuing system employed by the AML system, and

describe the available methods of ordering the queue.

175 The solution should Indicate whether the front end GUI queuing pane has ordering

functionality and search functionality.

176 The solution should come with the options which can be applied to the queue, to

allow alerts to be reprioritized and the queue re

177 The solution should confirm that the queue can be automatically refreshed when new

alerts are added, and that refreshed manually as well.

178 The solution should come with the capability sort the main queue of alerts or cases into queues, including by alert type, priority, customer, product, geographic region and transaction type for groups.

179 The solution should come with the sort/filter options which can be applied to the

queue, both automatically based on the user profile, and those which can be

manually applied to the queue by the individual user.

180 The workflow solution should associates cases to a prescribed/appropriate workflow

path based on their type or status.

181 Confirm that a log of actions and notes must be stored throughout the workflow

process to track actions and alterations to the

182 The solution should come with functionality that allows an administrator to create and

manage workflow and capable of having hierarchy for escalation of alerts to different

levels as per Bank’s requirement. Also, having proper mechanism for distribution of

alerts to different users/screening officer at AML cell and to different locations (Branch

offices).

183 The clearance of alert should be 3 customized as required by the Bank.

184 The solution should confirm that the AML system provides functionality that allows an

administrator to assign and reassign cases manually.

185 The solution should come with to provide a diarizing prioritization system that will

support the timely investigation of alerts or cases.



186 The solution should come with capability of the diarizing prioritization system to order

alerts and cases based on the prioritization assigned to an alert/case.

187 The solution should confirm that the diarizing prioritization system enforces agreed

service levels in which alerts/cases should be closed or alternatively raised as

SAR/STRs

188 The solution should come with diarizing prioritization system notifies both the

investigator and the supervisor of a breach of service levels where an alert/case has

not been investigated according to agreed service levels.

189 The solution should come with the functionality that automatically assigns priority to

alerts and cases, including examples of the priority assigned, and how the weighting

is calculated.

190 The solution should come with the capability to institution’s AML Risk Model, which provides for risk weightings on specific attributes (e.g. Customer Type, Customer profile, Industry Type, Geography, Product and Delivery Channel

191 The solution should come with the capability of Ownership functionality of the AML

system, and the process by which they can be reassigned to another business user,

including the restrictions available on reassigning alerts and cases based on business

user profiles.

192 The solution should confirm that the AML system can generate automated

confirmations where a manual SAR/STR has been raised, Re-ordered, the queue can

be specific user case. 3-4 tier architecture and can be investigator’s ‘workflow diary’,

incorporate the alert and Alert

193 The solution should confirm that all such alerts/confirmations are saved as part of the

audit process.

194 The solution should confirm the capability of the AML system to be interoperable with

email software provided by the Bank. ,.

195 The bulk mail facility with email templates should be made available

196 The solution should have capability to be interoperable with the institution’s ‘Global

Address List’ (GAL) email address directory.

197 The solution should have capability to display statuses, including how the AML

system ensures a status is captured for all alerts and cases.

198 The solution should have capability to allow business users to retrieve alerts and

cases directly, or by filtering on a specific status.

199 The solution should come with capability to change statuses, including how the AML

system ensures comments are entered for every status change made.



200 The solution should have capability to provide a standard set of comments that can

be utilized in by users when a status change is performed. And update new set of

comments.

201 The solution should indicate what controls exist such that alerts or cases cannot be

resolved without appropriate status change and comment.

202 The system should be capable of giving daily reconciliation of input of data from core

banking/other solution vis a vis migrated data in AML system – channel wise,

transaction head wise(cash, bank transfer, cross border, inter-office accounts, etc)

203 The system should be able to sort out various alerts on the basis of various risk

parameters and filtering criterion

G NAME SCANNING REQUIREMENTS

204 Application should be able to integrate with core banking interface and other surround

applications, if any, to control the customer onboarding process

205 Application should be able to integrate with core banking interface and other surround

applications, if any, to control the screening of online transaction monitoring

206 Application should be capable of providing details of the list being used with exact

details like page# etc. if any notification is being generated during scanning.

207 The rule based scanning should be possible e.g. name should be scan against name,

address against address, city against city etc.

208 Customer screening at the time of on boarding (real time) as well as periodically screening in batch mode against the sanctioned lists. Provision to manage Negative lists/blacklists provided by the local/international regulatory authorities like RMA/FIAB/FIU/UN sanctioned list/OFAC (Office of Foreign Acts Control)/Politically Exposed Person (PEP) list, etc. The solution should allow to add new lists as and when requires in the future and also should be a user friendly but robust screening facility in terms of sufficiency, efficiency with quality output . All new customers as well as existing customers should be checked against the lists concerned. The solution should have ability to electronically upload custom lists into the application with time stamp of time date of upload and user details. System should have facility to accept/provide data in standard formats from/for other

systems, Import /export facilities like upload of Negative List, Positive list, filtering

rules, etc.

209 Similarly, the system should have capability to advise any deletion of list with time

stamp and user details



210 The application should monitor client demographic data versus applicable negative lists (e.g. a client changes an address to or from an OSFI, NCCT

or OFAC address)

211 Batch upload of customized lists should be possible. Bank should be able to create watch lists of customers & non-customers, and capable of maintaining various watch lists, custom lists. There should be a provision to assign risk to the watch list. Changes to this watch list should also be tracked, with complete audit trail including action taken by the user. The front-end user should be able to ascertain number of list configured for that

instance including details like user who uploaded the list, upload date, last

modification date and report of the same should also be available.

212 The application should automatically determine the changes in the list has changed.

Please describe the frequency of checking and how changes are uploaded to the

application.

213 Provision for screening both outgoing and incoming messages, other cross order

transactions, trade transactions in real time.

214 The system should be capable of generating at the front end report on online

screening of customer on-boarding , transaction screening, batch processing in both

situation where there was no match or there was a match

215 The application should be able to perform a direct name match based on multiple

fields to determine if a customer is on the banned entity or any other negative list?

216 The application should have intelligence to clean list already cleared data in periodic

scrubbing during the next scrubbing unless there is change in customer profile or

watch list profile.(only for offline customer database scrubbing)

217 The Facility should be available for skipping field level, Message type, and record

type.

218 the application should perform a "fuzzy logic" match to determine if a customer is on

the banned entity or other negative list

219 The solution should deploy phonetic and fuzzy logic base search algorithms for

screening the entities names, alias names, counter party details, addresses, country,

ID number, BIC code and NAIC Code etc.

220 The solution should provide a user friendly but robust screening facility in terms of

sufficiency, efficiency and quality output.

221 The solution should interface/integrate with existing SFMS-SWIFT messages MT ( 543,767,195,710,203,202 cov, 102, 192, 720,300, 799, 299,110, 700, 540,103, 999,199,707,721, 542,320,541,202,499,196,742, 111,410,400,701,760,450 or any other any other type introduced by SWIFT in future) as per requirement and Trade finance systems through IBM Websphere MQ (latest version) and web service



222 When the application is implemented does it perform an initial scan of all customers

against the banned entity or negative list?

223 The application should support "clean" lists (I.e. lists of good customers, that may

appear bad when compared to negative list.

224 The product should scan existing customers as names are added to the banned entity

or other negative lists

225 The application should compare additions to the banned entity or other negative lists

to bank "clean" lists? For example, an individual is previously flagged by banned

entity, but the bank determines that the client is okay and adds the client to a clean

list. Subsequently, the actual client is added to the banned entity list and needs to be

removed from the Bank's clean list.

226 The application should have functionality that "unflags" customers as they are

removed from banned entity or negative lists

227 the application should have functionality that compares deletions to banned entity or

negative lists to cases/transactions that were previously flagged as "suspicious" and

are in process

228 The solution should integrate multiple lists provided by list provider such as Dow Jones World check, Factiva etc. or any other such list and also be able to integrate list from different regulators like the lists provided by FATF, FIU, RMA, Office of Foreign Acts Control Specially designated nationals (OFAC SDN), Politically Exposed People (PEP) lists, UN sanctioned list etc. Should be possible to add new lists as and

when they are introduced in future. Online downloads / checks from such sites should

be possible.

229 Multiple lists should be configurable on multiple instances of solution.

230 Bank should be able to create watch lists of customers & noncustomers. Batch

upload of customized lists should be possible. There should be a provision to assign

risk to the watch list. Changes to this watch list should also be tracked, with complete

audit trail.

231 The proposed solution should match new/existing customers on the basis of name,

Date of Birth, identification details , etc. in database against Dow-Jones, list provided

by regulatory authorities, Bank watch list for the KYC parameters defined by the Bank

and generate reports/alerts as per Bank requirement (online and offline). For online

screening separate hardware and installation details needs to be provided. For online

screening solution should be capable to integrate with the System Integrator interface

as required by the Bank.



232

(i) 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.

233 (ii) 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.

Should also have the ability to make a “fuzzy logic” match with the list.

234 (iii) The system should have capability of giving details of maker and checker who

had updated this white list along with time stamp.

235 (iv) The system should be capable of uploading any document(s) on the basis of

which the decision to alter the white list has been taken

236 (i) The proposed solution should have a functionality to display ( for domestic,

Foreign Office) various list provided by regulatory authorities, Bank watch list which

are used to scrub for

237

Customer on-boarding or for batch processing. The display should include date of

original upload, last updation date with time stamp.

(ii) Similarly a report should be made available with these information (format to be

decided in consultation with the Bank)

(iii) Users should be able to maintain internal Watch-lists to monitor their customers.

(iv) Users should be able to add a watch list and customers to that watch list. The list

manager should have a scan feature where in user should be able to check all the

customers added against the lists

238

The application should provide audit trail for any modifications in the Banned Entity

lists along with modification details through front end and through the Back end

7

239 The application should be capable to screen minimum 3000 requests per minute

240

The solution should be capable to scan multiple inputs in different formats from

different interfaces with specified parameters.

241

The solution should be capable to support bulk name scanning from various input

files .xls, csv, .txt etc. and provide output in various formats as required by the Bank.

H KYC

242 Any mandatory fields for an account holder, not filled should be detected & reported.

243 Proposed Solution should validate the CIF data and warn the user for missing data

elements and support modification for missing data elements



244 Proposed Solution should have the flexibility to define account type & customer type

specific (Saving account, Current account etc) template constituting bank specified

mandatory & optional fields, besides the regulatory mandatory fields.

245 The proposed solution should enable the users to define checklists on the Customer /

Account Static Data and to generate reports on mandatory information required for

different type of accounts. This mandatory information could either have been

prescribed by the regulatory authority of the country or required as a part of the

Bank’s internal policies.

246 The proposed solution should provide for completely customizable Mandatory Fields

Template allowing the user complete flexibility in case any changes / additions are

required in mandatory fields.

247 After setting the Fields for each customer type, the user should be able to generate

Mandatory Fields Missing Report from the system, which should provide the user with

a list of names of those customers whose accounts need to be monitored closely, and

from whom the BANK needs to get more information.

248 The Mandatory Fields Missing Report should provide details of Mandatory Fields

Static Data, which will allow the user to capture unfilled mandatory fields in customer

data. This Mandatory Fields Static Data should contain the list of all the mandatory

fields for a particular customer type, under a particular product and with a particular

account status. The report should display the names of those customers, who have

not provided any information about themselves to the BANK.

249 The proposed solution 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.

Graphic presentation of money laundering links

250 When a user’s name is entered in the Link Tracer, and the option for checking the

adverse media entity lists databases is enabled, The proposed solution should scan

for the customer’s name among all the stored published lists system databases

251 The user should also have a provision to search for Duplicate Data regarding a

customer, when compared to another customer of the BANK.

252 The solution should be capable of identifying multiple CIFs of a single customer on

parameters like Date of Birth, TPN number, Driving License, Passport, Voter ID,

Telephone/Mobile number etc for the purpose of De-duplication of customer IDs.



253 The user should also be able to search Static Databases based on parameters such

as Address, Introducer’s Name, TPN, Phone No., etc. The result of the search should

be a list of customer’s personal / geographical relationships with other customers in

the BANK.

254 A search made on a customer’s Transactional Data by the users, should result in a

list of relationships of that customer with all those who are transacting with him / her.

255 Once these relationships are found, the user should have a facility in

Proposed Solution to “Establish” a relationship, and this relationship should be saved

in the system along with the customer’s other static data. The user should also have

the option of changing this saved relationship later if he/she so chooses.

256 The proposed solution should enable the user to refine the search criteria from Exact

Match to Similar Sounding, Partial Name Search, Initials Search, Percentage match

and Sub String search. The user should be able to restrict the number of search

results by entering a figure as the “Hit Limit”.

257 The solution should be capable of generating reports of Branch wise Customer IDs due for KYC updation as per periodicity prescribed by RMA i.e, 1 years

for High Risk, 3 years for Medium Risk and 5 years for Low Risk customers and

capable of generating customized letter for each eligible customer.

258 Capable of providing different reports regarding the deficiencies in KYC details /

documents which will be helpful in customer profile updation and also able to

generate a letter in Bank’s template format as per branch/region wise.

I CUSTOMER RISK CATEGORIZATION

259 System should be able to categorize all accounts of customers into risk categories as

per Customer Risk Categorization policy of the Bank issued from time to time.

260 Proposed Solution should support customer risk assessment as per the bank’s

standard risk grading/rating criteria

261 Proposed Solution should support reassessment of customer risk, reclassification and

recreation of customer behavioral profile. Risk assessment reports should be

provided.

262 Proposed Solution should provide interface facility to update Risk classification from

AML Systems to CBS as per Bank’s specifications.

J ANALYTICS - GENERAL ANALYTIC CAPABILITIES

263 The transaction data should have the capability to do neural analysis i.e. predict

possible money laundering behavior in the future.



264 Does the solution come with the analytic framework employed in your AML

application (e.g. neural network)

265 Does the application incorporate trend analysis?

266 Does the application incorporate a "learning" neural network?

267 Does the application identify patterns not defined and produce a case/rule?

268 Does the application analyze sequences of events (i.e. chaining)? If so, does it look

forwards and backwards?

269 Does the application support profiling?

270 Does the application support link analysis? Use of link analysis which is a more

effective way to discover a money-laundering activity is desirable (Link analysis uses

mathematical algorithms to find common denominators and patterns in massive

amounts of data across the organization).

271 Does the application employ linguistic or phonetic analysis of customer names or

other text fields? Please describe.

272 Can the analytical framework be unbundled (e.g. offer only link analysis and profiling

capability, but not neural networks). Please describe.

K PROFILING

273 Does the solution come with ability to create accurate, verifiable, compact customer baseline profiles from historical data? Should maintain a historical record of Customer, Account, Transaction, etc. Should be possible to retrieve information as on a previous date i.e.,

show the status of a customer as of a particular date.

274 Does the solution support the techniques used by the application to develop profiles

(e.g. business rules, statistical techniques, artificial intelligence)

275 Does the application dynamically produce peer groups to use as the base for

comparisons?

276 Does the application build profiles by transaction type?

277 Does the solution has the ability to adjust profile model and characteristics manually

278 The solution should ensure that suspicious transactions do not get included in a

"normal" profile

279 Is the product able to handle different types of tolerances (for example, name

variations, name order differences, abbreviations, and foreign language differences,

case sensitive).



L ANALYTIC MODEL ADMINISTRATION

280 Will the vendor produce a customized analytic model for a client?

281 The solution should have ability to analyze "model performance" via reporting (e.g.

false positive/false negative hit rate).

282 The solution should have ability to "test" model and interaction with other models and

data prior to implementing in production.

283 The solution should have ability to flag a customer as "good", such that the customer

is excluded from appearing on any alert. Please describe.

284 The users can drag and drop report objects that are procreated by the vendor / IT team and generate / format their own dashboards. They have the ability to then mail / print this dashboard view.

285 The tool provides online help to support the development of

reports/dashboards/scorecards/ad-hoc queries

286 Proposed solution should have inbuilt business rules engine to implement scenarios

287 Proposed solution should have ability to add new scenarios

288 Proposed solution should be able to make scenarios active

289 Proposed solution should be able to execute scenarios in specific order

290 Business rule engine should have capability to change scenario parameters easily

291 Proposed solution should have ability to group scenarios together for performance

292 Proposed solution should be capable to execute scenarios at scheduled times such

as days, weeks or months

293 Proposed solution should have the ability for the rules engine to allow criteria to be

defined / modified (add, delete, create, update).

294 Proposed solution should have the ability for unlimited rules capacity

295 Proposed solution should have the ability for the rules engine to allow decisions

based on criteria (what to do with the item / record).

296 Rules engine should be able to create a case based on externally and internally

created scores as a decision element.

297 Rules engine should be able to create scores that are portfolio specific and/ or

relationship specific.

298 Rules engine should have the ability for allowing criteria to be defined / modified (add,

delete, create, update).

298 Rules engine should have the ability to prioritize work based on portfolio and / or

relationship specific scores.



300 Rules engine should use updatable user defined tables as decision elements such as:

Negative and / or positive files

301 Rules engine should have the ability to track changes to rules (i.e. who, when, what, why) (audit changes)

302 Rules engine should have the ability for each transaction to be evaluated by every

rule.

303 Rules engine should be able to identify to list, by priority, of all rules triggered by a

transaction.

304 Rules engine should be able to create / modify exclusion criteria, within a rule, to

route activity to an ‘exclusion” queue’.

305 Rules engine should be able to create / modify reactivation criteria, within the rule, for

accounts that have previously been reviewed and excluded

306 Proposed solution should be able to define systemic actions at the rule level.

307 Rules engine should be able to assign a unique case number to each item scored

and actioned by the rules engine or out sorted for analyst review.

M TRANSACTION BASED MONITORING

308 The solution should have in built intelligence to detect false positive alerts to reduce

high number of alerts

309 Proposed Solution should support detecting implicit and hidden relationships

between:

310 a) Different accounts of the same customer

b)Different customers

c) Customers, non-customers and Walk in Customers

311 Proposed Solution should support automated relationship identification between

linked accounts

312 Proposed Solution should support monitoring transactions at relationship and

individual account level

313 Proposed Solution should be able to know Money laundering patterns and fraud

patterns like structuring, circulation of fund etc. Proposed Solution should have no

limits to parameterize these patterns based on the banks experiences in money

laundering and fraud

314 Proposed Solution should support parameterize regulatory threshold limits and alert

the users on violation /breach of these set limits



315 The AML system should perform transactions monitoring by analyzing transactions and comparing them against set Benchmarks. Any deviation from benchmark should result in an Alert, which should

be then tracked to resolution.

316 The system should be able to escalate/highlight long pending alerts to the higher

authorities as parameterized in the solution

317 The system should have provision to define multiple benchmarks for alert scenarios

based on customer type, product, nature of business, and country & risk category of

the customer. It includes structured transactions, wire transfers, cross border

transactions patterns in multiple wire transfers, high risk geographies, high risk

entities, transactions with no apparent business purpose, funds transfer etc.

318 The proposed solution should provide for monitoring all amount based transactions,

whether for the current day or historical by filtering the transaction data. Filters should

be available in the system that will enable a user to monitor any type of transaction,

whether for one or all customers.

319 The proposed solution should provide the user to generate a suspicious transaction report (STR), Cash Transaction Report (CTR), Non-Profit Organization Transaction Report (NTR), Counterfeit Currency Report (CCR) and Cross Border Wire Transfer Report (CWTR) and fill up all the requisite information as per the format provided by the respective regulation (Domestic /Foreign Offices) and to submit the same. The user can submit the report to the higher ups for review and final submission to the concerned regulatory authorities.

Capable of Generating CCR (Counterfeit Currency Report) as per prescribed format of

FIU BHUTAN. Branch/Currency chest should be able to feed the CCR details online at

their end and KYC-AML division should be able generate them for final submission.

Capable of highlighting the alerts in screen on which STR is already filed to be viewed

by the Central office users.

Capable of highlighting the alerts in CTR submitted Accounts along with their history of

CTR transactions.

Capable of highlighting the alerts in CBWTR reported Accounts along with their history

of transactions.

Capable generating report of CBWTR -Country wise along with Zone/RO/branch wise

as per bank’s requirement.

Capable of providing details to PO and other Supervisors of progress/pendency of the

work of screening/scrutiny of the alerts under correspondence with the field.



Capable to provide access to Branch users to view letters on KYC Non-complaint

accounts and certifying the genuineness of transactions in their constituents’ accounts

online as required by KYC-AML division. Alerts should be thrown to Branch Manager’s

ID in case of non-compliance.

Capable to select multiple alerts for a single customer or multiple customers for a

specific case action by user through a single button click.

Capable to provide the user an option to view all the STRs generated and update the

status as it moves from review to submission.

320 Proposed Solution should have alert scenarios for individual transaction as well as

historical transactional behavior. Should support profiling of customers.

321 Proposed Solution should have provision to define global benchmarks as well as

account specific benchmarks for an alert scenario. Should be possible to set

threshold limits.

322 Proposed Solution should monitor transactions and analyze them against

benchmarks & generate alerts on exceptions. Should be possible to build profiles

based on transaction type and Turnover Details

323 The user should be able to select transactional attributes & view required transactions

(Report Module)

324 Proposed Solution should have provision to create user defined rules

325 Should be capable to monitor transactions involving internal accounts, from various

locations.

1

326 Identify multiple wire transfer transactions with common suspicious characteristics 3

327 Proposed Solution should have tools to analyze historical transactional attributes of an account & suggest benchmark value. Should support analysis of sequencing of events such as Placement, Layering and Integration accordingly, look forward and backward.

328 Proposed Solution should enable user to effectively manage alerts generated from

the time of generation till such time an appropriate action is taken

329 Huge Deposit or Withdrawals by way of Cash / RTGS / NEFT / Wire transfers in

Newly Opened Accounts

330 Minimum Account Balance

331 Frequent Transactions Just Under Reporting Threshold

332 Successive Withdrawals from ATM using Consecutive Cards

333 Credits and Debits within a certain period

334 High Cash Deposit or Withdrawal



335 Subjective Alerts (IBA) – These alerts should be primarily based on observations made by the teller, user or any other employee of the BANK. The proposed solution should allow the BANK to parameterize

336 Subjective alerts based on requirements and to modify and add alerts as and when

required.

337 All users screen should be customizable as per user requirement

338 The proposed solution should have an Alert Management tool, which should allow the

user to perform the following operations

339 The user should be able to assign the alert generated to the various surveillance

officers of the BANK. Proposed Solution should change the statuses of an alert

automatically in the course of assigning an alert to a user or adding notes to the alert.

The user should be able to enter the various actions to be taken against the customer

and maintain record of the status of the alerts

340 The proposed solution should enable the user to view complete details of alerts fired

on customers, instruments and products, and transactional details with respect to a

particular customer or customers.

341 The user should also have the option to filter alerts based on various parameters

such as time, customer, instrument, product and alert type.

342 The proposed solution should allow the users to pre-assign alerts to single or multiple

users. Complete audit trail should be maintained in the proposed solution for the

alerts assignment from one user to another.

343 The Reports should also provide information to management on the alerts status. The

proposed solution should provide for an alert assigned report allowing the user to

view the alerts and the user/users to whom these alerts have been assigned and also

provide for an alert statistics report to allow the user to view the alert statistics and the

user/users to whom these alerts have been assigned.

344 The proposed solution should provide for other reports to be generated as required by

the BANK at a later date

345 All actions taken by the investigating officer in the course of investigations should be

recorded in the system on each case with comments/ evidences and also enable him

to share the information electronically with other officers.

346 The user should be able to view details of all alerts fired on customers, instruments

and products as well as all the necessary transactional details with respect to the

specified customer.

347 Proposed Solution should have facility to manage false positives



348 It should be possible to re-run any rule at any time and “as-of” any past date.

349 Rule wizard type utility should be available, should be menu-driven, user-friendly and

flexible. Should preferably permit rollback of rule changes. Audit trail of rule-changes

to be maintained and system / product limitations of user-rules, if any, to be

mentioned as a footnote

350 Should provide the user the option to drill down into the details of the transaction on

which the alert was generated

351 Proposed Solution should have provision for resource allocation & work load

balancing

352 The user should have the facility of filtering alerts based on parameters such as time,

customer, instrument, product and alert type

353 Monitoring/Updation of trends and developments in emerging fraudulent techniques

related to the use of e - banking channels and enhance or adjust their fraud

monitoring systems whenever there is a need. During the process, Application

provider should take into account any fraud intelligence gathered from internal or

external sources (e.g. from the industry, the police or information security service

providers)

354 Functionality to detect frequent or multiple funds transfer made to the same payee or

set of payees within a short period of time especially if the amount involved is close to

the maximum allowable transaction limit of the customer account.

355 Functionality to detect change in customer address / mobile phone number for

receiving SMS notification or OTPS, shortly followed by potentially suspicious

activities as (i) large-value funds transfer to unregistered payee(s); and (ii) online

registration of third – party payee(s) subsequently followed by large-value funds

transfers to the same payee(s).

357 The solution having the provision of age wise pending alerts in dashboard which can be drilled down to finer details. A report should also be available on daily basis with comparative position of previous day, previous week and previous month. Capable of providing details to PO and other Supervisors of progress/pendency of the

work of screening/scrutiny of the alerts under correspondence with the field.

358 Capable of Generating CCR (Counterfeit Currency Report) as per prescribed format

of FIU Bhutan. Branch/Currency chest should be able to feed the CCR details online

at their end and KYC-AML division should be able generate them for final submission.

N CASE MANAGEMENT REQUIREMENTS



359 Solution should have the ability to receive alerts from multiple monitoring systems that

have been designated as incidents that require investigation

360 Solution should provide an Incident Triage Queue to allow the user to review

incoming items prior to creating or linking an incident to a case

361 Solution should be able to customize activities and automation of workflow (different

workflows may be developed for different types of cases)

362 Solution should have the ability to assign activities in the workflow to a group of users

363 Solution should have the ability to create, edit and view a case based on user

permissions

364 Solution should have the ability to classify cases by type, category, and subcategory

365 Solution should have the ability to attach documents and video files (any digital media

may be stored)

366 Solution should have the ability to set default fields and values on screens based on

case type

367 Solution should create an audit record containing the identification of the user, a time

stamp, and date when actions are performed to a case that may be provided to

management, an examiner, or regulating agency

368 Solution should have the ability to generate a batch file for regulatory reporting via E-

Filing

369 Solution should have the ability to align cases by priority, high to low to the analyst

role in the queue. New cases will populate the queue according to the priority.

370 Solution should have the ability for additional review(s) of case disposition based on

several factors (role, tier, delegated authority, etc…)

371 The user should be able to manually change a case, The user should be able to

change / modify the ‘due date (SLA) add comments, and designate future review time

to re-review the case (ie. Automated reminder). If “pending” due to unavailability of

analyst, then work should move to “general” queue for work.

372 Solution should provide a free form text comments box on working case screens.

373 The user should be able to manually modify a pended case.

374 The user, based on role, should be able to take specific actions on pended records

375 The user should be able to take ownership of a task (with notification going back to

original pending analyst)



376 The user should be able to release pending record back into queue

377 The user should be able to comment without taking ownership

378 The user should be able to reassign record

379 The solution should allow the user (detection, inbound, etc…) to manually enter a case

380 The solution should be able to differentiate between cases which were created from

alerts versus those which were created manually

381 The user should be able to add free text notes to cases

382 The number / label / length / arrangement of such fields should be configurable

383 The user should be able to add or remove a document to a case

384 The user should be able to add or remove a reminder to a case

385 The user should has ability to apply a mass action to case - close, append etc

386 The user should has ability to link cases under investigation

387 Solution should has automated case processing

388 System should offer links to tools that perform automated case processing

389 Case management should have input/output functionality (API) in order to be able to

link to other platforms

390 The solution should have retrospective analysis, looking for other like events after

updating additional informational about a case or alert. Once a case is closed, the

solution should re-score rules or models for future analysis.

391 The solution have ability to elevate an alert into a case

392 The solution has ability to add several alerts to one case.

393 The solution has ability for automatic assignment of cases to investigators, ability for

supervisor to override and assign cases manually.

394 The solution has flexibility of case management screens: ability to change field layout,

field names, field types, contents of dropdown lists, without vendor involvement.

395 The solution has ability to configure case management workflows in a flexible way by

the user.

396 The solution has ability to import large amount of information from txt, csv, or xls

format - useful for first population of database, or the integration with other

databases.

397 The solution should have full audit trail / logging of all changes in the database (who,

when, which table, which field, old value, new value).

398 Case management fields should be populated automatically with application details if

case is generated from an alert



399 Investigators should be able to sort and filter all case records by entering search

criteria into any data field. Possibilities should include logical searches like "Equals A

or contains B", etc. Query results should be displayed as a list, possibility to open a

record on the list to view all fields, then close and return to result list.

400 Solution should be able to export the results of a query, or the entire table to xlsx, pdf,

docs, pdf, csv etc.

401 Solution should support batch update: Ability to update many records at the same

time, e.g. Overwrite recovered amount for several hundred records at the same time.

O WORKFLOW REQUIREMENTS

402 Solution should provide the ability to perform systematic actions based upon an

analyst’s work action.

403 Screen flow and system process must represent the task workflow.

404 Solution should be able to define the systematic actions to be taken, based upon an

analyst’s work action.

405 Power users should have the ability to configure standard workflows to route case

activities to appropriate teams

406 Detection rules creation/modification and deletion could be subject of approval by

more than one appointed person using workflow functionality.

407 Alerts should be managed by more than one appointed person using workflow

functionality.

408 Cases should be managed by more than one appointed person using workflow

functionality.

409 Reports review and appropriate reaction could be managed by more than one

appointed person using workflow functionality.

410 Workflow actions should not be deleted or altered after submission

411 Users should not be able to delete/modify/recreate workflow steps.

412 Solution should have the ability to control or change (edit/delete) certain workflow

functions

413 The AML systems should maintain comprehensive Audit Trails detailing every user

activity (including action taken by the user). Audit Trail reports should be generated

and may be viewed onscreen and/or printed.

414 Solution should be able to manage and capture audit trails for workflow configuration

415 Solution should have the ability to create and modify workflow without assistance of

software vendor

416 Solution should have ability to add/update/delete scenarios



417 Solution should have ability to make scenarios active or inactive

418 Solution should have ability to track changes to scenarios

419 Solution should not have any restriction on the license in terms of no. of users, no. of

transactions, no. of channels, no. of Banking products, no. of branches and asset

size of bank etc

420 Solution should have ability to add /update/delete users/groups easily

421 Solution should have ability to add add/update/delete reports easily

422 Solution should have ability to add/update user/group privileges

423 Solution should have ability to integrate alerts from other systems

424 Solution should have ability to integrate 3rd party data

425 Solution should have ability to add/update data inputs

P ALERTS MANAGEMENT

426 Real Time Alerts

427 System should have an alert scoring mechanism with product having a relative score

for each alert, the alert scores be modified through the applications of rules, provide

for the categorization of alerts into groups for similar suspicious activity and provide

the user to drill down into the details of the transactions on which the alert was

generated.

428 Current Deposit Account reaching Minimum Balance

429 Savings Account reaching Minimum Balance

430 More than X % of Account Drained in a Day

431 Huge Cash Transactions

432 High / Low Deposit to Withdrawal Ratio

433 High Amount Transaction by DD, WT , RTGS, NEFT, etc..

434 Huge Cash Deposits

435 FCN, TC Limits Crossed

436 Transaction in Dormant or Sensitive Account

437 Frequent transfers in related parties accounts

438 Cash deposits / withdrawals beyond parameterize values

439 Blacklisted customers, introducer, guarantor check

440 Proposed Solution should be able to trigger events based on the alerts e.g. in case

of deposit of over threshold in cash over the counter the system should prompt the

user for entering the PAN number or residential address

441 Non Real time Alerts - These alerts should be fired only when a command is

generated, after collecting the data. The output of these alerts should be available in

the form of a report.



442

- Cash deposit by a single applicant in a single day for issue of drafts

- Draft issued to more than one applicants for a common payee

- Cash Transaction Below Threshold

- High transaction in borrowal accounts

- IBA High value cash transactions inconsistent with profile

- IBA High Value Cash Deposits in a Day.

- Many to One Fund Transfer.

- High transaction in NPA accounts

- One to Many Fund Transfer.

- Sudden High Value Transaction for the Client

- Outward Remittance

- RTGS/NEFT/GRPT

- Monthly Alert Scenario

- High value cash deposits in a month

- High value cash withdrawals in a month

- High value non-cash deposits in a month

- High value non-cash withdrawals in a month

- Sudden Increase in value of transactions in a month for the client

- Sudden Increase in number of Transactions in a month for the Client

- Transaction in Newly opened Account

- High Activity in New Account

- Sudden activity in a dormant account

- Splitting of Cash Deposits below threshold to Multiple Accounts

- Splitting of cash deposits just below threshold

- Numerous low cash Deposits resulting in a high amount Deposit.

- Numerous low cash withdrawals resulting in a high amount withdrawal.

- Repeated Small Cash Deposits Followed by Immediate ATM Withdrawals in

Different Location

- Repeated small value transfers from unrelated parties followed by

immediate ATM withdrawals

- Repeated small value inward remittance from unrelated parties followed by

immediate ATM withdrawals

- Repayment of loan in cash

- Premature closure of large FDR



- High number of cheque leaves issued

- Frequent Locker Operations

- High value cash transactions in Non-Profit Organization

- High value cash transactions related to real estate

- High value cash transactions by dealer in precious metal or stone

- High Value Inward Remittance

- Inward Remittance in a New Account

- Inward Remittance Inconsistent with Client Profile

- Inward remittances from various unrelated accounts followed by immediate

withdrawal through INB,GCC or ATM

- Deposit / Withdrawal above threshold through alternative channels such as

INB, ATM, Kiosks, Wallet, POS machines

- High value transactions with a country with high ML risk

- Multiple Cash Deposit in non-home branch.

- Trade Based Money Laundering- Capable of capturing scenarios under

TBML

- Accounts operated for a very short period and used only for advance

remittances for imports

- Advance remittances sent for imports are repeatedly kept below threshold to

avoid reporting. Import takes place after considerable time after the

remittance is sent.

- Remittance of very high value of X amount to Y amount being made after six

months from the Bill Of Entry(BOE)

- Advance Remittances received but exports are made after a very long time.

- Multiple importers importing goods from the same exporter

- Small cash deposits through more than two Cash Deposit Machine.

- Watch list based Scenario

- Match with UN & UAPA List

- Match with other TF List

- Match with other Criminal List

- Politically Exposed Person (PEP) List

The solution should closely monitor trends and developments in emerging fraudulent

techniques related to the use of e-banking channels and enhance or adjust their fraud

monitoring systems whenever there is a need. It also should take into account any

fraud intelligence gathered from internal or external sources (e.g. from the industry,

the police or information security service providers)



443 Frequent or multiple funds transfer made to the same payee or set of payees within a

short period of time especially if the amount involved is close to the maximum

allowable transaction limit of the customer account.

444 A large value funds transfer conducted shortly after online registration of the payee(s)

via internet banking, especially if the amount involved is close to the maximum

allowable transaction limit or the account balance of the customer’s account.

445 Tracking facility for mail sent/received should be available.

446 Change in customer mobile phone number for receiving SMS notification or OTPS,

shortly followed by potentially suspicious activities as (i) large-value funds transfer to

unregistered payee(s) ; and (ii) online registration of third –party payee(s)

subsequently followed by large value funds transfers to the same payee(s).

447 The tool should provide a Central Metadata Repository to manage the flow and

traceability of data and structures.

448 The tool should provide native access Industry leading RDBMS like ORACLE, SQL Server, Sybase, MYSQL and have specific data access application to access modules. The solution should provide specialized table loaders to provide optimized bulk

loading of databases such as Oracle etc.

449 The Tool Should provide for Multiple- user design environment supports collaboration

on large, enterprise wide projects.

450 The Tool Should provide for Integrated workflow scheduling, automatic load balancing

and grid computing support.

451 The Tool should provide support for Message-Oriented Middleware, including Web

Sphere MQ from IBM, MSMQ from Microsoft and Rendezvous.

452 The tool should be rich in the set of inbuilt analytical transformations and functions that should include predefined table and column-level transformations including slowly changing dimensions.

453 The tool should support targets which are normalized or renormalized. The tool

should provide specific functionality to support either of these two design approaches.

454 The tool should provide for reuse of individual transformations.

455 The tool should support for surrogate key generation.

456 The tool should provide for creation of user-defined functions.

457 The tool should provide pre-build functionalities for the following:

458 Financial Transformations

459 Mathematical Transformations

460 Statistical Computations Should provide intuitive Graphic



461 User interfaces for Data Profiling, Data Standardization, and Clustering and Data

Augmentation capabilities.

462

In Data Profiling it should be able to conduct the following analysis :

• Structure discoveries,

• Frequency distribution of Alerts -Daily, Weekly & Monthly

• The tool should be capable of having proper mechanism for distribution of alerts to different locations such as HO &

Branch as per Bank’s requirement

• Various Statistical Analysis

• Outliers Detection and Percentile reporting

• Relationship Discoveries

• Referential Integrity Analysis

• Redundant Data Analysis

• Drill through analysis from graphical reports to transactional data

• Enable business rule validation.

Support data quality measurement on an on-going basis embedded into batch, near-

time, and real- time process

463 The Tool should supports client requests via standard Simple Object Access Protocol

interfaces.

465 Should support data cleansing and de- duplication, duplicate suspect processing,

house holding, with array of out-of-the- box standardization rules conform data to

corporate standards – or can build customized rules for special situations.

466 Should have business rules and GUI’s for automatic merging and manual merging.

467 The Tool should provide for Master Data Management with semantic data

descriptions of input and output data sources uniquely identify each instance of a

business element customer, account, etc. and standardize the master data to provide

a single source of truth.

468 The Tool should provide for Business rules library. Reusable business rules clean,

standardize, match and enhance data as it moves into the master reference file and is

reused for downstream processes.

469 The Tool Should provide fuzzy logic to induce tolerance during matching

470 The Tool Should use the parsed data to provide flexible matching criteria

471 The Tool Should have options for manual / automatic merging of clustered records

472 The Tool Should enable to define rules for record and/or field selections during the

merging process



473 The Tool Should have the capability to enrich data from internal data sources

474 The Tool Should have the capability to enrich data from external / third party data

sources

475 The Tool Should have options for manual/automatic merging of clustered records

476 The Tool Should enable to define rules for record and / or field selections during the

merging process

477 The tool should have integrated and customized design-time checks for early

notification of potential problems as you build the process flow for a job.

478 The tool should have the ability to disable and enable nodes and submit flows in any

state.

479 The tool should have the ability of performing integrated impact analysis.

480 The tool should have the ability of Full Undo to reverse an action, and Redo to

reverse the Undo operation.

481 The tool should have documentation available in the form of notes on nodes and on

the canvas.

482 The tool should have enhanced mapping features that includes intelligent handling of

data type conversions, easy and selectable customizes mappings, and controlled

propagation of changes to mappings

483 The tool should have status indicators that identify complete and incomplete

transformations in a job.

484 The tool should have status messages that explain the status issues with incomplete

transformations.

485 The tool should have Rules-based mappings that support pattern mapping, user

customizations, and automatic numeric to character or character to numeric

mappings.

486 The tool should have the ability to start job runs from the source, the target, or the

middle of the job.

487 The tool should have the ability to easily capture and display performance information

such as real time, CPU time, memory use, input/output, and record count data, with

the ability to display this information as a table or as a graph.

488 The tool should have transformations to perform analytical operations like

Correlations, Distribution Analysis, Frequency and Summarization.

489 The Data integration jobs should be building the data-marts along with OLAP cubes in

a seamless single process flow.



490 The OLAP building stored processes should be scheduled in a single seamless

interface of ETL Jobs

491 System shall contain the data, software, and processes needed to cleanse,

consolidate and transform the data from their source system format to the data

warehouse format.

492 System shall be able to facilitate bulk data movement

493 System shall be able to join data from multiple sources and support for concurrent

processing of multiple source data streams, without writing procedural code

494 System shall be able to extract and transform information from multiple sources without

any intermediate files

495 System shall be able to check incoming data for quality, reliability, consistency and

validity, and then transform as required.

496 System shall facilitate data profiling based on dynamic, user defined validation rules

and support identification of user defined ‘events’ to trigger alerts (through email

reports) to authorities

497 System shall support In-memory data handling

498 System shall allow high-performance movement and transformation of data between

disparate systems in batch mode.

499 System shall support batch mode data quality implementation

500 System shall be able to generate notification alerts based on the occurrences of

relevant knowledge items and as per pre-defined priority

501 System shall have the capability to correct mistakes in spellings, inconsistencies,

casings and abbreviations

502 Provision to generate list of accounts at a given Name/TPN/Passport/Voter ID/Driving License/address/Mobile/Telephone number/Date of Birth/email, etc. both in the way of individual search or combination of search. System shall support correction logic for Bhutanese names, addresses, phone numbers, TPN numbers, passport number and other identification proof documents and demographic details

503 Data warehouse shall have the capability to export data in open standards (such as

XML formats).

Q INTERFACE REQUIREMENTS

504 The solution should implement query and analytical capabilities that can be used for

event filtering, correlation, pattern matching and aggregation. Facility to define view

and query rights to different work groups. Full capabilities to be described by the

vendor.

505 The solution should support different concepts for time: time of event generation, time

of event processing.



506 The solution should allow for time adjustments through date/time arithmetic of the

individual event streams (solve problems around different system-times).Please state

time zones supported.

507 The solution should integrate and apply analytical models to events and data from

DWH.

508 The solution support visual development

509 The solution IDE should provide capabilities for meta-data like: documentation, dependencies, versioning

510 The solution should support Threshold-based alerting

511 The solution should support Look-up data in a database as required

512 The solution should support data correlation

513 The solution should support data aggregation

514 The solution should be able to support event detection using regular expressions and

rich query language

515 The solution should have configurable storing-time for in- and output events

516 The solution should provide prioritization functionalities It should be possible to define

high priority events for complex event processing.

517 The solution should be able to support real time update and recalculations or filtering

of incoming events

518 Ability to provide pre-defined and pre-built physical data model that supports

comprehensive and immediate capturing of data from multiple source systems in the

bank

519 The data model is open and extensible for the bank to develop and deploy its own

analytical models and applications using the underlying frameworks within the

solution

520 Ability to provide analytical development/customization via wizard based tooling

approach to cover objects at all levels of granularity

521 Ability to provide Linear scalability in terms of compute capacity, storage capacity and performance. System must be scalable without any limitations to accommodate new branches,

offices, users, functions, new software upgrades such as operating systems.

522 The platform should supports the storage indexes to minimize the data seeking

latencies.

523 Ability to provide parameterization to facilitate initial system set-up and future

maintenance activities.

524 Users should be able to leverage the web browser to perform ad-hoc queries and

analysis online via the internet/intranet

525 Solution can Perform complex filtering by defining set operations (union, intersect,

minus) during the course of analysis



526 Solution can Perform drill down on any graph or table to view the detail breakdown on

any value during the course of analysis

527 Solution can Perform pivoting to change the permutation of any graph or table to view

information in various perspectives during the course of analysis

528 Solution can setup alerts to highlight numbers based on threshold settings during the

course of analysis

529 Should Perform automatic sorting based on numbers, alphabets and dates or

manually sort them during the course of analysis

530 Users should be able to share their reports with individual users or to groups of users

easily internally within the reporting environment via shared folders or externally

outside of the reporting environment via email and ftp sites.

531 Users should be able to define totals and subtotals as well as leverage on a library of

functions to define additional calculations during the course of analysis

532 System has the facility to save the queries and edit the same in future to derive newer

queries

533 The tool should have the ability to use Analytics to enable users to conduct fast,

thorough exploration and analysis on all data across different data sources

534 The tool should be able to analyze big data and generate visualizations on the fly,

without any performance degradation

535 The tool should enable different types of users to perform Analysis on data across the

Enterprise without the need to Subset / sample / create multiple views of data

536 The offering should have integrated modules for analytics comprising data

preparation, exploration, visualization and administration. All the modules of the

software should be fully integrated and no manual intervention should be needed for

inter-modules operations.

537 The tool should provide Self-Service platform without the need to build a semantic

metadata layer for End users, thus reducing dependency on IT

538 The tool should provide Scalability and High Performance leveraging cost- effective

architecture

539 The tool should have the ability to be configured on commodity hardware which gives

the scalability and brings down upfront capital investments for an organization

540 The tool should have been designed from the ground up for integration with Big data

for performance optimization and scalability.



541 The tool should provide a user friendly, web based , drag and drop interface for data

preparation for data tables available

542 The tool should visually prepare data for analysis, including joining tables, defining

custom calculated columns and creating custom expressions for data tables available

543 The tool should allow data to be accessed from any industry standard data source

using native connectors and load the same

544 The tool should provide the capability to search for data tables available

545 The tool should provide the capability to upload data from a spreadsheet for analysis

546 The tool should provide self-service analytics on data without the need to create a

semantic metadata layer prior to exploration, thus reducing dependency for end users

547 The tool should allow data load jobs to be scheduled to automate the process of

loading data. Should support processing on Real-Time, Online, Off-line, batch mode,

etc. Should also support scheduling and defining of jobs.

548 The tool should be compatible with Windows

549 The tool should provide analytical capabilities such as Correlations, Regression, Text Analytics/Word Cloud using predefined ontologies, Network Plot, Decision Trees, Scenario Analysis, Statistical Analysis

550 The tool should provide Text Analytics capabilities and lets you represent it using

predefined ontologies.

551 The tool should provide capabilities to create Network Plot which can be plotted over

a Geo-Map

552 The tool should provide the capability to build interactive Decision Trees

553 The tool should provide capabilities to forecast on the fly with forecasting confidence

intervals to further enhance data exploration and analysis.

554 The tool should automatically selects the most appropriate forecasting algorithm for

the selected data.

555 The tool should provide enhanced forecasting capabilities with Scenario Analysis

allowing users to see impact of variable values on the forecasted trend

556 The tool should provide a clear explanation of Analytical results by providing “What

does it mean” capabilities

557 The tool should provide Scalability and High Performance leveraging cost- effective

architecture

558 Built on top of commodity hardware which gives the scalability and brings down

upfront capital investments for an organization



559 The tool should have ability to scale on commodity hardware architecture with

increasing needs of managing Big Data

560 The tool should provide Auto charting. Based on data items selected for analysis, the

tool should automatically choose best visualization suited for representation

561 The tool should allow users to change queries by selecting items to be displayed from

a sidebar or dynamically filtering and grouping.

562 The tool should provide viewable descriptive statistics, such as min, max and mean,

enabling users to gain an overall sense of a particular measure.

563 The tool should provide the capability to link to an external URL from a visual object

with relevant context

564 The tool should allow 'On-the-fly' hierarchy creation for adding drilldown capabilities to

visualizations and reports.

565 The tool should provide capabilities to Slice and dice multidimensional data by

applying filters on any level of a hierarchy.

566 The tool should provide capabilities to Drill up and down through hierarchies, or

expand and collapse entire levels.

567 The tool should provide a data acquisition wizard for previewing, filtering or sampling

data prior to creating visualizations or reports.

568 The tool should provide selection and brushing modes for discovering relationships

while exploring data

569 The tool should provide users the capability to save and share their analysis as

exploration, report, or PDF

570 The tool should provide the capability to export data to Excel, CSV/TSV, PDF, RTF,

DOC, and HTML. document formats

571 The tool should be capable of read and write of comments on reports to aid in

collaboration

572 The tool is capable of emailing a report link with comments to others.

573 The tool should allow users to Capture screenshots and share comments with others.

574 The tool should provide progressive filters. This refers to cascading relation between

filter controls in the report body with bi-directional filter support i.e., each linked filter

control acts as a source as well as target for other prompts

575 The tool should provide collaboration support with Annotation on Tablet

576 The tool should allow users to Receive alerts to updated reports on mobile devices.

577 The tool should provide a thumbnail view of recent and favorite items to select and

open.



578 The tool should provide precision layout capabilities provide flexibility in report layout

and design

579 The tool should provide filtering and selection capabilities with easy to integrate action

elements such as radio buttons, drop-down selections, check boxes, sliders, etc.

580 The tool should provide Percentage of Records as part of Filtering and Result Data

set giving a purview of the amount of data being Analyzed

581 Capability to calculate new data items on the fly from existing data items using

expressions

582 The tool should allow the analysis / explorations / reports based on in memory data to

be pushed for offline viewing to mobile devices

583 The tool should have the ability for Interactive report viewing for information

consumers using iPad and Android devices using a native application most popular

gestures and capabilities, including zoom, swipe, etc., to optimize ease of use and

user engagement.

584 The tool should allow users to securely view reports on mobile devices while online or

offline.

585 The tool should have the capability to monitor the server environment including: Resource utilization including CPU, I/O and Memory, User Sessions, Mobile Device logging History

586 The tool should provide support for Mobile Device Management (MDM) integrating

with 3rd party technologies.

587 The tool should provide ability to Refresh reports from the device

588 The tool should provide server side logging for user actions – reports downloaded

589 The tool should provide Reuse existing queries by Scheduling of the jobs to run data

preparation queries in off- peak times

590 The tool should provide the following capabilities pertaining to security of the

environment:

591 Availability of source code for review to the Bank for security review at the discretion

of the Bank or whenever there is any change in the code.

592 Secured code practices are being followed by the developers for the solution.

593 Mobile device blacklisting through the web based security and administration

interface

594 Mobile device white listing through the web based security and administration

interface



595 System can Print the report, export the report to other formats (excel, pdf) or email

the report to other members in the community during the course of analysis. The

user can setup a schedule to print, export or email the report automatically

R SERVER

596 (These are minimum technical specification required. The bidder can offer

higher specification according to the requirement of solution offered by them.)

597 Technical Requirements Compliance

598 The proposed servers should be 64 Bit RISC/EPIC Processor

599 The proposed server should be Rack Mountable with rail kit - adjustable depth

600 Each server must be configured with requisite processors to deliver at least 1400

SPECint_rate2006 & must be scalable to deliver 2800 SPECint_rate2006.The offered

processor must be benchmarked on public website and the OEM must submit the

published benchmark.

601 The offered processor should be the latest offering and must have at least 3.0 GHz

clock speed. Highest clock speed and highest cache in the offered configuration of

the server must be offered.

602 Minimum 16 GB RAM per core must be configured with memory compression

technology. And proposed server should be scalable to 4TB of memory.

603 The system must be configured with at least 64 MB of cache with minimum of 2MB L3

Cache per processor core. Over and above the minimum cache the vendor should

offer the processor with highest cache in the offered configuration.

604 The proposed system must be capable of at least 450 GBps

605 The proposed servers should have Min 8 x 600 GB or Higher @10k rpm or Higher

Hot pluggable and scalable to 32 Hot pluggable/ Swappable drives.

606 The proposed servers should have PCIe Gen3 with Min 8 PCIe hot plug slots

scalable to 48 Pci hot plug slots.

607 The proposed servers should have minimum 2 ethernet adaptors, 10 Gb with min 4

ports each.

608 The proposed servers should have minimum two 8Gbps FC-HBA with min 4 ports

each.

609 DVD-ROM or equivalent any device attached by which the requirement will be fulfilled

610 Redundant Hot Swappable power supply and Cooling fan/subsystems



611 The partitioning technology should ensure vertical scalability for database server and

horizontal scalability for application servers with adequate resilience and redundancy

built into the system. The partitioning technology must have the capability to allow

movement of resources such as CPU, Memory, IO across a minimum 10 partitions

without reboot of source or target partitions.

612 The proposed virtualization platform must have a clear roadmap and support for the

offered database. Failure of any partition should not affect any other partitions. It

should be possible to virtualize the Fibre Channel and Ethernet ports to any partition

with-in same server. The virtualization technology must be EAL4+ certified. IO should

be virtualized through dual dedicated VM's. If VM cannot be virtualized then dual

dedicated 10G Ethernet & dual dedicated

613 8 Gbps FC adaptors must be configured per virtual machine. Memory Compression must be offered. If memory is not compressed then 32 GB

RAM per core must be configured.

614 Operating system offered should include the following features:

615 Virtualization technology from the OEM of server manufacturer. An independent

kernel of 64 bit UNIX capable of version upgrade and application of patches without

reboot. The Unix Operating Systems shall be licensed to support unlimited users.

616 Partitioning functionality to allow the creation of multiple & minimum 0.1 core

processor partition within the server Volume management to allow the creation,

expansion and shrinking of volumes and dynamically mirrored volumes Journalized

file systems with an encryption option

617 File System should be able to create snapshots without unmounting the file system.

Dynamic multipath I/O for fiber channel and SCSI I/O paths for disk and tape devices.

Failure of any instance of OS kernal should not impact any partition on the server. OS

must be from the server OEM. It must also be possible to reboot/ restart the OS

instance without affecting any other application instance.

618 The proposed servers should have HA features

619 ECC protected DDR3 memory

620 Dynamic Processor resilience and deallocation with Operating System

621 Hot Plug PCIe Adapters

622 Hot Plug disk drives

623 Dynamic firmware updates

624 At least 3 years onsite warranty with full labor, parts & replacement.

625 Should support centralized, distributed as well as hybrid databases.

626 Support automatic switchover to alternate/standby/failover server.



Annexure 8 Query Format Request for Clarification

Name of Organization submitting

request

Name & position submitting request

of person Full formal address of the organization

including phone, fax and email points

of contact

Section / Page No. RFP Terms Query description




Annexure 9

MUTUAL NON-DISCLOSURE AGREEMENT

This Agreement is made as of the …………… day of ……… 2019, between…………………………………….., a company registered under the Companies Act …. and having its Head Office ………………………………………… and

Druk PNB Bank Ltd., a banking company incorporated and functioning under the provisions of the Companies Act of Bhutan 2001 having its Head Office at Thimphu, Bhutan, ( hereinafter collectively referred to as “the Parties”). In order to pursue the mutual business purpose contemplated under this Mutual Non-Disclosure Agreement (hereinafter referred to as the “Agreement”, and such mutual business purpose hereinafter referred to as the “Business Purpose”), the Parties recognize that there is a need to disclose to one another certain confidential information of each party to be used only for the Business Purpose and to protect such confidential information from unauthorized use and disclosure.

In consideration of the other party’s disclosure of such information, the Parties agree as follows:

1. This Agreement will apply to all plans, information (whether written or oral), documentation and support material contained within all analyses, compilations, studies, reports records and other documents which are shown or provided by one party to the other, whether or not any portion thereof is or may be validly copyrighted, trademarked or patented (hereinafter referred to as “Confidential Information”). The terms confidential Information shall also include all information provided to M/ s ………………………………………….., for undertaking

Detailed pre-implementation Application Control Audits and Data Migration Audits with regard to critical systems.

Vulnerability Assessment and Penetration Testing (VAPT) of our Bank’s CBS (Core Banking Solutions) Internal as well as External Systems/ Networks

Application security testing of web/ mobile applications throughout their lifecycle (pre-implementation, post-implementation, after changes) in environment closely resembling or replica of production environment, etc., as per ‘Scope of Work’.

Any other Audit on need basis of the Bank etc., as per the Scope of Work and terms & conditions mentioned in the Request For proposal ref no. ……..dated………. ..

2. Each party agrees (i) to hold the other party’s Confidential Information in strict confidence, (ii) not to disclose such Confidential Information to any third parties, and (iii) not to use any confidential Information for any purpose except for the business Purpose. Without limiting the generality of the aforesaid restrictions, neither party shall use any Confidential Information in connection with any activities or ventures competitive with the business of the other. Each party may disclose the other party’s Confidential Information to its directors, officers, employees attorneys and other advisors (collectively, “Representatives”) on a bona fide need to know basis, but only to the extent necessary to carry out the Business Purpose. Each party agrees to instruct all such Representatives not to disclose such Confidential Information to third parties including consultants, without the prior written permission of the disclosing party.

3. Confidential Information will not include information which;

(i) is now, or hereafter becomes through no act or failure to act on the part of the receiving party, become generally known or available to the public;

(ii) was acquired by the receiving party before receiving such information from the disclosing party and without restriction as to use or disclosure;



(iii) is hereafter rightfully furnished to the receiving party by a third party, without restriction as to use or disclosure;

(iv) is information which the receiving party can document, was independently developed by the receiving party;

(v) is required to be disclosed pursuant to law, provided the receiving party provides the other party, to the extent legally permissible, with prompt written notice of such requirement so that the other party may seek an appropriate protective order with respect thereto; or

(vi) is disclosed with the prior written consent of the disclosing party.

4. The Parties agree to exercise extreme care in protecting the confidentiality of any confidential information, which is removed from the disclosing party’s premises. The Parties agree to comply with any and all terms and conditions, the disclosing party may impose upon any such removal, such as conditions that the removed confidential Information and all copies must be returned by a certain date, and that no copies are to be made off of the premises.

5. Upon the disclosing party’s request, the receiving party will promptly return to the disclosing party all tangible items containing or consisting of the disclosing party’s Confidential Information and all copies thereof.

6. The Parties recognize and agree that nothing contained in this Agreement will be construed as granting any rights to the receiving party, by license or otherwise, to any of the disclosing party’s Confidential Information, except as specified in this Agreement.

7. The parties acknowledge that all of the disclosing party’s Confidential Information is owned solely by the disclosing party (or its licensors) and that the unauthorized disclosure or use of such Confidential Information would cause irreparable harm and significant injury, the degree of which may be difficult to ascertain. Accordingly,

the Parties agree that the disclosing party will have the right to obtain, without the necessity of proving actual damages or posting any bond or other security, temporary and permanent injunctive relief including, but not limited to, specific performance of the terms of this Agreement, as well as the right to pursue any and all other rights and remedies available at law or in equity for such a breach.

8. All references herein to the Parties shall also refer to all entities owned or controlled by the parties, all entities that own or control, or are under common control with, the Parties and their respective offices, directors, employees, shareholders, agent’s attorneys and other advisors.

9. This Agreement will be construed, interpreted, and applied in accordance with the laws of Bhutan. This Agreement is the complete and exclusive statement regarding the subject matter hereof and supersedes all prior agreements, understandings and communications, whether oral or written, express or implied, between the Parties regarding the subject matter of this Agreement.

10. This Agreement will remain in effect for three (3) years from the date of the last disclosure of Confidential Information, at which time it will terminate.

11. All Confidential Information and Confidential Materials are and shall remain the property of disclosing Party/s. By disclosing information to the other Party/s, Disclosing Party/s or Receiving Party does not grant any express or implied right to the other party’s patents, copyrights, trademarks, or trade secret information.

12. This Agreement constitutes the entire agreement between the parties with respect to the subject matter hereof. It shall not be modified except by a written agreement dated subsequent to the date of this Agreement and signed by both parties. None of the provisions of this Agreement shall be deemed to have been waived by any act or



acquiescence on the part of Disclosing Party/s, its agents, or employees, but only by an instrument in writing signed by an authorized officer of Disclosing Party/s. No waiver of any provision of this Agreement shall constitute a waiver of any other provision(s) or of the same provision on another occasion.

13. This Agreement shall be governed by, and construed interpreted and enforced in accordance with the internal substantive laws of Bhutan.

14. If any provision of this Agreement shall be held by a court of competent jurisdiction to be illegal, invalid or unenforceable, the remaining provisions shall remain in full force and effect.

IN WITNESS WHEREOF, the parties hereto have executed this Agreement by their duly authorized officers or representatives.

For Druk PNB Bank Ltd. For...................

Signature Signature

Name Name

Title

Title

*****



Application Integrity statement from OEM To

The Dy. Chief Executive Officer

Druk PNB Bank Ltd.

Thimphu, Bhutan.

Dear Sir,

RFP ref no. No:

This is to certify that the software ………………………..is free of malware at the time of sale, free of any obvious bugs, and free of any covert channels in the code (of the version of the application being delivered as well as any subsequent versions /modifications done)

Yours sincerely,

Date:

Place: Signature of Authorized Official with seal



Annexure 10

Format of Bank Guarantee (for EMD) To

The Dy. Chief Executive Officer

Druk PNB Bank Ltd.

Thimphu, Bhutan

Dear Sirs,

In response to your invitation to respond to your RFP reference No. ________________ , addressed to ___________________ having their registered office at _____________ (hereinafter called the „Bidder‟) wish to respond to the said Request for Proposal (RFP) for self and other associated Bidders and submit the proposal for implementation and maintenance of AML solution listed in the RFP document. Whereas the „Bidder‟ has submitted the proposal in response to RFP, we, the ____________ Bank having our head office ________________ hereby irrevocably guarantee an amount of Nu. ___________ (Nu. ____________ only) as bid security as required to be submitted by the „Bidder‟ as a condition for participation in the said process of RFP. The Bid security for which this guarantee is given is liable to be enforced/ invoked:

1) If the Bidder withdraws his proposal during the period of the proposal validity; or

2) If the Bidder, having been notified of the acceptance of its proposal by the Bank during the period of the validity of the proposal fails or refuses to enter into the contract in accordance with the Terms and Conditions of the RFP or the terms and conditions mutually agreed subsequently.

We undertake to pay immediately on demand to Druk PNB Bank Ltd. the said amount of Nu. ________________ without any reservation, protest, demur, or recourse. The said guarantee is liable to be invoked/ enforced on the happening of the contingencies as mentioned above and also in the RFP document and we shall pay the amount on any Demand made by Druk PNB Bank Ltd. which shall be conclusive and binding on us irrespective of any dispute or difference raised by the Bidder. Notwithstanding anything contained herein:

1) Our liability under this Bank guarantee shall not exceed Nu. ________ (Ngultrum _______________________________________________ only).

2) This Bank guarantee will be valid up to __________________; and

3) We are liable to pay the guarantee amount or any part thereof under this Bank guarantee only upon service of a written claim or demand by you on or before ________________.

In witness whereof the Bank, through the authorized officer has sets its hand and stamp on this _______________ day of __________________ at _________________.



Annexure 11

Bill of Material Details of the hardware and software proposed to be delivered and installed Hardware at DC: Sl. No Details – Server / Tape

library etc.

Make Model Qty. Detailed configuration (CPU / RAM / HDD etc.)

Software at DC:

Sl. No Name of software

the OEM Version number Number of licenses& licensing

details

Details

Details of the hardware and software proposed to be delivered and installed Hardware at DRS: Sl. No Details – Server / Tape

library etc.

Make Model Qty. Detailed configuration (CPU / RAM / HDD etc.)

Software at DRS:

Sl. No Name of software

the OEM Version number Number of

licenses& licensing

details

Details

Date:

Place: Signature of Authorized Official with seal



Annexure 12

PRE CONTRACT INTEGRITY PACT

General This pre-bid pre-contract Agreement (hereinafter called the Integrity Pact) is made on____________ day of the month of _______________ 20__, between, on one hand, Druk PNB Bank Ltd., a Public Limited Company Undertaking constituted under the Companies Act of Bhutan represented by Mr. ________________, (Designation of the Officer), (hereinafter called the 'BUYER', which expression shall mean and include, unless the context otherwise requires, his successors in office and assigns) of the First Part and M/s. ____________________ represented by Mr.___________________________, Dy. Chief Executive Officer (hereinafter called the "BIDDER/SELLER" which expression shall mean and include, unless the context otherwise requires, his successors and permitted assigns) of the Second Part. WHEREAS the 'BUYER' has invited bids for the ______________ and the BIDDER/SELLER is submitting his bid for the same and WHEREAS the BIDDER is a Private Limited company/Public Limited company/Government undertaking/registered partnership firm/ constituted in accordance with the relevant law in the matter and the 'BUYER' is Druk PNB Bank Ltd.

NOW, THEREFORE, To avoid all forms of corruption by following a system that is fair, transparent and free from any influence/prejudiced dealings prior to, during and subsequent to the currency of the contract to be entered into with a view to:-

Enabling the BUYER to obtain the desired said equipment/ services/ works at a competitive price in conformity with the defined specifications by avoiding the high cost and the distortionary impact of corruption on public procurement, and Enabling BIDDERS to abstain from bribing or indulging in any corrupt practice in order to secure the contract by providing assurance to them that their competitors will also abstain from bribing and other corrupt practices and the 'BUYER' will commit to prevent corruption, in any form, by its officials by following transparent procedures. The parties hereto hereby agree to enter into this Integrity Pact and agree as follows: Commitments of the 'BUYER'

1.1. The 'BUYER' undertakes that no official of the 'BUYER', connected directly or indirectly with the

contract, will demand, take a promise for or accept, directly or through intermediaries, any bribe, consideration, gift, reward, favor or any material or immaterial benefit or any other advantage from the BIDDER, either for themselves or for any person, organization or third party related to the contract in exchange for an advantage in the bidding process, bid evaluation, contracting or implementation process related to the contract.

1.2. The 'BUYER' will, during the pre-contract stage, treat all BIDDERS alike and will provide to all BIDDERS the same information and will not provide any such information to any particular BIDDER which could afford an advantage to that particular BIDDER in comparison to other BIDDERS.

1.3. All the officials of the 'BUYER' will report to the appropriate Government office any attempted or completed breaches of the above commitments as well as any substantial suspicion of such a breach.

2. In case any such preceding misconduct on the part of such official(s) is reported by the BIDDER to the

'BUYER' with full and verifiable facts and the same is prima facie found to be correct by the 'BUYER' necessary disciplinary proceedings, or any other action as deemed fit, including criminal proceedings may be initiated by the 'BUYER' and such a person shall be debarred from further dealings related-to the contract process. In such a case while an enquiry is being conducted by the 'BUYER' the proceedings under the contract would not be stalled. Commitments of BIDDERS



3. The BIDDER commits itself to take all measures necessary to prevent corrupt practices, unfair means and

illegal activities during any stage of its bid or during any pre-contract or post-contract stage in order to secure the contract or in furtherance to secure it and in particular commit itself to the following:-

3.1 The BIDDER will not offer, directly or through intermediaries, any bribe, gift, consideration,

reward, favor, any material or immaterial benefit or other advantage, commission, fees, brokerage or inducement to any official of the 'BUYER' connected directly or indirectly with the bidding process, or to any person, organization or third party related to the contract in exchange for any advantage in the bidding, evaluation, contracting and implementation of the contract.

3.2 The BIDDER further undertakes that it has not given, offered or promised to give, directly or indirectly any bribe, gift, consideration, reward, favor, any material or immaterial benefit or other advantage, commission, fees, brokerage or inducement to any official of the 'BUYER' or otherwise in procuring the Contract or forbearing to do or having done any act in relation to the obtaining or execution of the contract or any other contract with the Government for showing or forbearing to show favor or disfavor to any person in relation to the contract or any other contract with the Government.

3.3 BIDDERS shall disclose the name and address of agents and representatives and Bhutanese BIDDERS shall disclose their foreign principals or associates.

3.4 BIDDERS shall disclose the payments to be made by them to agents/brokers or any other intermediary, in connection with this bid/contract.

3.6 The BIDDER further confirms and declares to the 'BUYER' that the BIDDER has not engaged any individual or firm or company whether Bhutanese or foreign to intercede, facilitate or in any way to recommend to the BUYER or any of its functionaries, whether officially or unofficially to the award of the contract to the BIDDER, nor has any amount been paid, promised or intended to be paid to any such individual, firm or company in respect of any such intercession, facilitation or recommendation.

3.7 The BIDDER, either while presenting the bid or during pre-contract negotiations or before signing the contract, shall disclose any payments he has made, is committed to or intends to make to officials of the 'BUYER' or their family members, agents, brokers or any other intermediaries in connection with the contract and the details of services agreed upon for such payments.

3.8 The BIDDER will not collude with other parties interested in the contract to impair the transparency,

fairness and progress of the bidding process, bid evaluation, contracting and implementation of the contract.

3.9 The BIDDER will not accept any advantage in exchange for any corrupt practice, unfair means and illegal activities.

3.10 The BIDDER shall not use improperly, for purposes of competition or personal gain, or pass on to

others, any information provided by the 'BUYER' as part of the business relationship, regarding plans, technical proposals and business details, including information contained in any electronic data carrier. The BIDDER also undertakes to exercise due and adequate care lest any such information is divulged.

3.11 The BIDDER commits to refrain from giving any complaint directly or through any other manner

without supporting it with full and verifiable facts.



3.12 The BIDDER shall not instigate or cause to instigate any third person to commit any of the actions

mentioned above.

3.13 If the BIDDER or any employee of the BIDDER or any person acting on behalf of the BIDDER,

either directly or indirectly, is a relative of any of the officers of the 'BUYER' or alternatively, if any relative of an officer of the 'BUYER' has financial interest/stake in the BIDDER's firm, the same shall be disclosed by the BIDDER at the time of filing of tender. The term 'relative' for this purpose would be as defined in Section 6 of the Companies Act 1956.

3.14 The BIDDER shall not lend to or borrow any money from or enter into any monetary dealings or

transactions, directly or indirectly, with any employee of the 'BUYER'. 4. Previous Transgression 4.1 The BIDDER declares that no previous transgression occurred in the last three years immediately

before signing of this Integrity Pact, with any other company in any country in respect of any corrupt practices envisaged hereunder or with any Public Sector Enterprise in Bhutan or any Government Department in Bhutan that could justify bidder's exclusion from the tender process.

4.2 The BIDDER agrees that if it makes incorrect statement on this subject, BIDDER can be disqualified from the tender process or the contract, if already awarded, can be terminated for such reason.

5. Earnest Money (Security Deposit) 5.1 While submitting commercial bid, the BIDDER shall deposit an amount ____ (to be specified in Bid

Document) as Earnest Money/Security Deposit, with the 'BUYER' through any of the following instruments: (i) Bank Draft or a Pay Order in favor of _______ (ii) A confirmed guarantee by any Bank in Bhutan, promising payment of the guaranteed sum to the 'BUYER' on demand within 3 working days without any demur whatsoever and without seeking any reasons whatsoever. The demand for payment by the 'BUYER' shall be treated as conclusive proof of payment. (iii) Any other mode or through any other instrument (to be specified in the Bid Document).

5.2 The Earnest Money/Security Deposit shall be valid up to a period of ______ months or the complete

conclusion of the contractual obligations to the complete satisfaction of both the BIDDER and the BUYER, including warranty period, whichever is later.

5.3 In case of the successful BIDDER a clause would also be incorporated in the Article pertaining to

Performance Bond in the Purchase Contract that the provisions of Sanctions for violation shall be applicable for forfeiture of Performance Bond in case of a decision by the BUYER to forfeit the same without assigning any reason for imposing sanction for violation of this Pact.

5.4 No interest shall be payable by the 'BUYER' to the BIDDER on Earnest Money/ Security Deposit for

the period of its currency.

6. Sanctions for Violations



1.1 Any breach of the aforesaid provisions by the BIDDER or any one employed by it or acting on its behalf (whether with or without the knowledge of the BIDDER) shall entitle the 'BUYER' to take all or any one of the following actions, wherever required:-

(i) To immediately call off the pre contract negotiations without assigning any reason or giving any compensation to the BIDDER. However, the proceedings with the other BIDDER(s) would continue.

(ii) The Earnest Money Deposit (in pre-contract stage) and/or Security Deposit/Performance Bond (after

the contract is signed) shall stand forfeited either fully or partially, as decided by the 'BUYER' and the 'BUYER' shall not be required to assign any reason therefore.

(iii) To immediately cancel the contract, if already signed, without giving any compensation to the BIDDER.

(iv) To recover all sums already paid by the BUYER, and in case of a Bhutanese BIDDER with interest

thereon at 2% higher than the prevailing Prime Lending Rate of Bank of Bhutan, while in case of a BIDDER from a country other than Bhutan with interest thereon at 2% higher than the LIBOR. If any outstanding payment is due to the BIDDER from the BUYER in connection with any other contract, such outstanding payment could also be utilized to recover the aforesaid sum and interest.

(v) To encash the advance bank guarantee and performance bond/warranty bond, if furnished by the

BIDDER, in order to recover the payments, already made by the BUYER, along with interest.

(vi) To cancel all or any other Contracts with the BIDDER. The BIDDER shall, be liable to pay compensation

for any loss or damage to the 'BUYER' resulting from such cancellation/rescission and the 'BUYER' shall be entitled to deduct the amount so payable from the money(s) due to the BIDDER.

(vii) To debar the BIDDER from participating in future bidding processes of the Government of Bhutan for

a minimum period of five years, which may be further extended at the discretion of the 'BUYER.

(viii) In cases where irrevocable Letters of Credit have been received in respect of any contract signed by

the BUYER with the BIDDER, the same shall not be opened.

(ix) To recover all sums paid in violation of this Pact by BIDDER(s) to any middleman or agent or broker

with a view to securing the contract.

(x) Forfeiture of Performance Guarantee in case of a decision by the 'BUYER' to forfeit the same without

assigning any reason for imposing sanction for violation of this Pact.

6.2 The 'BUYER' will be entitled to take all or any of the actions mentioned at para 6.1(i) to (x) of this Pact

also on the Commission by the BIDDER or any one employed by it or acting on its behalf (whether with or without the knowledge of the BIDDER), of an offence as defined in Chapter IX of the Penal code of Bhutan or Prevention of Corruption Act, 1988 or any other statute enacted for prevention of corruption. 6.3 The decision of the 'BUYER' to the effect that a breach of the provisions of this Pact has been committed by the BIDDER shall be final and conclusive on the BIDDER. However, the BIDDER can approach the Independent Monitor(s) appointed for the purposes of this Pact.



7. Fall Clause 7.1 The BIDDER undertakes that it has not supplied/is not supplying similar Product/ systems or

subsystems at a price lower than that offered in the present bid in respect of any other Ministry / Department of the Government of Bhutan or PSU and if it is found at any stage that similar project was performed by the BIDDER to any other

Ministry/Department of the Government of Bhutan or a PSU at a lower price, then that very price, with due allowance for elapsed time, will be applicable to the present case and the difference in the cost would be refunded by the BIDDER to the 'BUYER', if the contract has already been concluded.

8. Facilitation of Investigation In case of any allegation of violation of any provisions of this pact or payment

of commission, the BUYER or its agencies shall be entitled to examine all the documents including the Books of Accounts of the BIDDER and the BIDDER shall provide necessary information and documents in English and shall extend all possible help for the purpose of such examination.

9. Law and Place of Jurisdiction This Pact is subject to Bhutanese Law.' The place of performance and

jurisdiction is the seat of the BUYER

10. Other Legal Actions: The actions stipulated in this Integrity Pact are without prejudice to any other legal

action that may follow in accordance with the provisions of the extant law in force relating to any civil or criminal proceedings.

11. Validity

11.1 The validity of this Integrity Pact shall be from date of its signing and extend up to 5 years or the

complete execution of the contract to the satisfaction of both the BUYER and the BIDDER/SELLER, including warranty period, whichever is later. In case BIDDER is unsuccessful, this Integrity Pact shall expire after six months from the date of the signing of the contract.

11.2 Should one or several provisions of this Pact turn out to be invalid; the remainder of this Pact shall

remain valid. In this case, the parties will strive to come to an agreement to their original intentions.

12. The parties hereby sign this Integrity Pact at Thimphu on________ BUYER BIDDER.

Name of the Officer: A B Rai

Designation: Dy. Chief Executive Officer

Druk PNB Bank Ltd., Head Office, Thimphu, Bhutan

Witness

Witness: 1. ________________



2.___________________,

ANNEXURE – 13

COMMERCIAL BID

The indicative commercial Bid needs to contain the information listed hereunder in a sealed envelope bearing the identification – “Commercial Bid for The Procurement of AML Solution”. To be submitted to the Dy. Chief Executive Officer, Druk PNB Bank Ltd., Thimphu, Bhutan.

Name of the Bidder & address

Particulars / Areas /

Products

DESCRIPTION No. of Units

Price per unit Price (in

Rs.)

Hardware Servers

Other equipment

Software Software License Cost (perpetual

enterprise unlimited license)

Cost of Implementation of AML/CFT

Solution in branches / offices in

Bhutan

Cost of Customization

Training Training for employees

Total

Annual Technical Support

ATS for Software @..........% of the

Software cost Total for the next 3

years after 3 years warranty (Year

wise breakup required)

On Site Technical Support

required as per

scope.

Total

Man Days for Customization & New Developments



Total

Grand total