developing anti-money laundering and combating the

Developing Anti-Money Laundering and

Combating the Financing of Terrorism

Approaches, Methodologies and Controls

Request for Proposal

for

Selection of a Consultant

to

Develop an Online Anti-Money Laundering

Web-Based System

Developing an Online Anti-Money Laundering Web-Based System Terms of Reference

Strictly private and confidential 2

Table of Contents

Note to Bidders ......................................................................................................................... 7

1 Assignment Objective and Project Background ................................................................... 8

1.1 Key Objectives ...................................................................................................................................... 8

2 Introduction ...................................................................................................................... 10

2.1 AML/CFT Act of 2018 ....................................................................................................................... 10

2.2 Financial Intelligence Department ................................................................................................... 10

3 Overview of the Current State ............................................................................................12

3.1 Reporting Entities ............................................................................................................................... 12

3.2 Law Enforcement Agencies ................................................................................................................ 12

4 Scope of Work ....................................................................................................................13

4.1 System Development .......................................................................................................................... 13

4.2 Historical Processing of Data ............................................................................................................. 13

4.3 Maintenance ....................................................................................................................................... 14

4.4 Exit Management ................................................................................................................................ 14

5 Functional Requirements .................................................................................................. 16

5.1 Common Functionalities .................................................................................................................... 16

5.2 REs ...................................................................................................................................................... 18

5.3 FID-Bhutan ......................................................................................................................................... 21

5.4 LEAs ................................................................................................................................................... 27

6 Technical Requirements ................................................................................................... 30

6.1 Key Design Principles ........................................................................................................................ 30

6.2 Logical Architecture .......................................................................................................................... 32

6.3 Key Solution Components ................................................................................................................. 33

7 Operational Requirements ................................................................................................ 38

7.1 Project Management and Reporting................................................................................................. 38

7.2 Solution Maintenance and Support .................................................................................................. 39

8 Advanced Services Package ............................................................................................... 40

8.1 Mobile Friendly Portal ...................................................................................................................... 40

8.2 Training and E-learns ........................................................................................................................ 40

8.3 Helpdesk.............................................................................................................................................. 41

8.4 Report Monitoring .............................................................................................................................. 41

8.5 Analytics Modules for FID-Bhutan .................................................................................................... 41

8.6 Value Added Service Proposed By Bidder ........................................................................................ 42

9 Expertise Required ........................................................................................................... 43

9.1 Firm Qualification ............................................................................................................................. 43

9.2 Team Composition and Expert Qualification .................................................................................. 43

9.3 Delivery Model ................................................................................................................................... 44

10 Project Implementation and Timelines ....................................................................... 45



11 Project Deliverables ..................................................................................................... 47

12 Deliverables and Payment Schedule ............................................................................ 49

13 Technical Evaluation Criteria ...................................................................................... 50

14 Annexure 1: Additional Stakeholder Details ................................................................. 51

14.1 Organization Structure of FID-Bhutan ............................................................................................. 51

14.2 Functions of FID-Bhutan ................................................................................................................... 51

14.3 Indicative Reporting Volumes and Historical Data ......................................................................... 52

14.4 Overview of LEAs ............................................................................................................................... 52

15 Annexure 2: Indicative Registration Forms ................................................................. 54

15.1 Registration for New User Group ..................................................................................................... 54

15.2 Registration for New User ................................................................................................................. 54

16 Annexure 3: Indicative Notifications and Alerts .......................................................... 55

17 Annexure 4: Indicative Feedback Forms ..................................................................... 57

17.1 Feedback From LEAs to FID ............................................................................................................. 57

18 Annexure 5: Indicative Status Codes ........................................................................... 58

18.1 Report Submission ............................................................................................................................ 58

18.2 Reactive Requests Sent to REs .......................................................................................................... 58

18.3 Reactive Requests Sent to FID-Bhutan ............................................................................................ 59

19 Annexure 6: Indicative Timelines for Report Monitoring............................................ 60

20 Annexure 7- Existing Hardware ................................................................................... 62

21 Annexure 8- Template for Hardware Requirements for OARS .................................... 63

22 Annexure 9: Template for AMC Cost ............................................................................ 64



Table of Figures

Figure 1: Functions of FID-Bhutan ............................................................................................................................ 11 Figure 2 Reporting Entities ......................................................................................................................................... 12 Figure 3: Functional Block Diagram .......................................................................................................................... 16 Figure 4: Reporting Formats by Entities.................................................................................................................... 19 Figure 5: Logical Architecture ................................................................................................................................... 32 Figure 6: Advanced Services Package Evaluation .................................................................................................... 40 Figure 7: Required Resources .................................................................................................................................... 44 Figure 8: Timelines .................................................................................................................................................... 46 Figure 9: List of project deliverables ......................................................................................................................... 48 Figure 10: Payment Terms ......................................................................................................................................... 49 Figure 11: Advanced Services Package Evaluation ................................................................................................... 50 Figure 12: Organizational Structure of FID-Bhutan .................................................................................................. 51 Figure 13: Indicative Reporting Volumes.................................................................................................................. 52 Figure 14: Registration Process for Business Entity ................................................................................................. 54 Figure 15: Registration Process for an Individual .................................................................................................... 54 Figure 16: Notifications and Alerts ............................................................................................................................ 56 Figure 17: Feedback from LEA .................................................................................................................................... 57 Figure 18: Status Code for REs .................................................................................................................................. 58 Figure 19: Status Code Reactive Information with RE ............................................................................................. 59 Figure 20: Status Code Reactive Information with RE ............................................................................................ 59 Figure 21: Timeline for Reporting for REs ................................................................................................................ 60 Figure 22: Timeline for Reactive Information from REs ......................................................................................... 60 Figure 23: Timeline for Reactive Information from FID-Bhutan ............................................................................. 61 Figure 24: Timeline for case submission ................................................................................................................... 61 Figure 25: Timeline for dissemination to RMA departments ................................................................................... 61



List of Acronyms

Acronym Definition

ACC Anti-Corruption Commission

ADB Asian Development Bank

AMC Annual Maintenance Contract

AML Anti-Money Laundering

AMLCO Anti-Money Laundering Compliance Officer

BDB Bhutan Development Bank

BNB Bhutan National Bank

BNCA Bhutan Narcotics Control Authority

BOB Bank of Bhutan

CID Citizenship Identity Card

CDD Customer Due Diligence

CFT Countering the Financing of Terrorism

CTR Cash Transaction Reports

DNFBP Designated Non-Financial Businesses and Professions

DPNB Druk Punjab National Banks

DRC Department of Revenue and Control

FATF Financial Action Task Force

FID Financial Intelligence Department

FIU Financial Intelligence Unit

FRS Functional Requirement Specifications

HLD High Level Design

LEA LEAs

LLD Low Level Design

ML Money Laundering

MoU Memorandums of Understanding

NCA National Crime Agency

NCC National Coordination Committee

OAG Office of Attorney General

OARS Online AML Reporting System

RAID Risks, Assumptions, Issues, Dependencies



Acronym Definition

RBP Royal Bhutan Police

RE Reporting Entity

RFI Red Flag Indicators

RFP Request for Proposal

RID Revenue Intelligence Department

RMA Royal Monetary Authority

RoC Registrar of Companies

SOP Standard Operating Procedures

SRS System Requirement Specifications

STR Suspicious Transaction Reports

TA Technical Assistance

TF Terrorism Financing

ToR Terms of Reference

UN United Nations

UNODC United Nations Office on Drugs and Crime

XML eXtensible Markup Language



NOTE TO BIDDERS

The Government of Bhutan received a Cluster Regional Technical Assistance for Developing Anti-Money Laundering (AML) and Combating the Financing of Terrorism (CFT) Approaches, Methodologies and Controls (the “AML RETA”) from the Asian Development Bank (ADB). Under Subproject A of the AML RETA 0023, the Technical Assistance (TA) team engaged a consulting firm, to assist the Financial Intelligence Department-Bhutan (FID-Bhutan) in developing a practical approach towards having an Online AML Reporting System (OARS). After a detailed study of the people, processes and technologies in the FID ecosystem, and evaluating multiple possible solutions, it was recommended that a customized web-based tool be developed to support FID-Bhutan

To equip Bhutan with the necessary tools and technologies in its AML/CFT efforts, Subproject B of the AML RETA has been envisioned to provide assistance to the country for the development of the OARS. Thus, ADB is facilitating the recruitment of the developer following line with ADB’s procurement rules and guidelines.

Since this is a project of national importance that aims to strengthen the financial security architecture of the country, the purpose of this Request for Proposal (RFP) is to seek a bidder that will share the same vision, and works in tandem with FID-Bhutan to realise it. With this intent ADB and FID-Bhutan seek a bidder that delivers business outcomes as envisioned in the RFP. ADB and FID-Bhutan do not view this as a technology centric project, but a technology-led process innovation enablement journey that shall transform the information gathering and intelligence generation activities of the FID ecosystem.

This document shall provide bidders with an overview of the current state and the need for the OARS, along with key assignment objectives. In addition, it shall also provide bidders with the scope of work, timelines, expected deliverables, payment schedule and required expertise. The scope of work in this document has been bifurcated across two services –

1. Core Services spanning the minimum modules and functional requirements that are required in the system and to be implemented by the on boarded vendor.

2. Advanced Services spanning modules and functional requirements that may be provided as a value addition by the bidder, at no additional cost. These services are optional for the bidders, however, bidders who provide some of all of these services, will be awarded higher scores in the technical evaluation (as given in Section 13)

The envisaged duration of this engagement is for a period of 6 months spanning 3 months of system development, including historical processing of data and user acceptance testing and 3 months of maintenance, under warranty. It is envisaged that go-live of the system occurs 3 months after on-boarding of vendor. In addition, there shall also be 2 weeks of exit management and transition, whereby the on-boarded vendor will hand over all deliverables and documents to FID-Bhutan.

Overall, the critical success factors for this project would include speed, usability, convenience and accuracy in terms of system efficiency and availability as well as processing outcomes. Through this project, ADB and FID-Bhutan, envision to put in place a state-of-the-art system, that automates collection, processing, analysis and dissemination of data, thus strengthening overall AML/CFT efforts and enabling rapid identification of money laundering and terrorism financing activities.



1 ASSIGNMENT OBJECTIVE AND PROJECT

BACKGROUND

Through funding from ADB, FID-Bhutan undertook an exercise in 2018 to devise a long-term strategy to strengthen its tactical, operational and strategic analytical capabilities driven by technological enablers. The objective of the study was to conduct a comprehensive assessment of current state of FID ecosystem, comprising of FID, Reporting Entities (REs) and LEAs (LEAs), study the best practices/recommendations from international community and formulate a blueprint for an Information Technology (IT) led transformation of FID-Bhutan.

The current assessment of the ecosystem revealed scope for improvement in stakeholder communication, data analysis and capacity building. Given the novelty of the AML/CFT Act in Bhutan and the recently established FID, a majority of the processes are being conducted offline including data exchange between stakeholders, communication and analysis, indicating an opportunity to strengthen security, analysis and improve efficiency of the ecosystem.

In order to strengthen the AML/CFT efforts in Bhutan, there is a need to develop a modern IT system that will pave the way forward and mitigate future challenges regarding data exchange and analysis of financial information. The indicative features of the envisaged web based solution include the following–

Flexibility: The web-based solution shall provide users with flexibility to access the system anywhere, as and when it is necessary. In addition, there shall be no need to download software onto individual laptops, since the system shall be accessible via a web browser.

Security: The web-based solution shall be deployed on the FID-Bhutan server, thereby ensuring that no unauthorized user shall be able to access data. Given that FID-Bhutan has access to sensitive and confidential financial information regarding individuals and entities, it is essential to ensure that security of data.

Scalability of web based solution: The AML ecosystem in Bhutan comprises of REs, LEAs and FID-Bhutan. Currently there are nine types of REs and five LEAs in Bhutan. However, in the future there may be a need to identify new REs and LEAs. Scalability of the web based solution shall ensure that more users and reporting formats can be added as and when it is required. In addition, it shall also ensure that volumes of reporting can increase without having an impact on the system.

Improved communication: The web based solution shall enhance the communication that occurs between stakeholders and FID-Bhutan. Users shall be able to share data, collaborate with other users and gain feedback in a rapid manner

1.1 KEY OBJECTIVES

Through the development of the OARS, ADB and FID-Bhutan envision to streamline and automate the process of collection, processing and dissemination of data for the purpose of effectively generating meaningful intelligence to curb Money Laundering (ML) and Terrorism Financing (TF) activities in the country.

Currently, the REs report financial data in an Excel sheet through offline mode and analysis is carried out manually. Moving FID-Bhutan towards online web-based system is expected to enhance the efficiency of FID-Bhutan’s operation and benefit LEAs in receiving strong leads to enable effective investigation and curbing the financial crime and money laundering offenses. Through development of the OARS, this project also aims at improving the technical compliance rating of the Financial Action Task Force (FATF) recommendations.



The core objectives of the project include –

Developing an efficient system for collection and processing of data from REs, thus reducing lead time

Developing a system that is flexible, secure and scalable enough to handle increased workloads and spikes in volumes of data

Developing an efficient system for dissemination and exchange of information with stakeholders, thus enabling rapid and secure exchange of data (as shown in the figure below)

Adopting security measures and internal controls to protect the information from unauthorized access

Enabling reciprocity of information exchange, while conducting analysis for domestic and international agencies

Expanding and systematizing international cooperation in the reciprocal exchange of financial intelligence information.

Automating the processes and functions of FID-Bhutan and reducing the need for manual intervention



2 INTRODUCTION

The Financial Action Task Force recommends –

“Countries should establish a Financial Intelligence Unit (FIU) that serves as a centre for the receipt and analysis of (a) suspicious transaction reports; and (b) other relevant information related to money laundering, associated predicate offences and terrorist financing, and for the dissemination of results of that analysis. The FIU should be able to obtain additional information from reporting entities, and should have access on a timely basis to the financial, administrative and law enforcement information that it requires to undertake its functions properly."

To conceptualize an efficient system for collection, processing, analysis and dissemination of information and select the best-in-class vendor for development of such a system, a thorough understanding of the ecosystem will–

Ensure that the system is developed to suit the usability and needs of various stakeholder groups

Provide reasonable assurance that the system is developed keeping in mind stakeholder feedback, and identified operational and administrative issues

Ensure that the system is aligned with the legal framework of the country

2.1 AML/CFT ACT OF 2018

The AML/CFT Act governing the operations of FID-Bhutan came into force on 8th January 2018 and had the following objectives–

Promote integrity of financial systems by detailing measures for the identification and prevention of money laundering and terrorism financing activities, and establishing a stable framework for the same. In addition, the Act would facilitate co-operation between stakeholders and constitute a National Coordination Committee (NCC).

Empower regulatory stakeholders with various measures and powers that would enable them to take action on ML/TF activities.

Overall, the AML/CFT Act of 2018 includes rules and guidelines regarding the following–

Which entities qualify as Reporting Entities and their obligations

Supervisors of reporting entities and their powers

FID-Bhutan and its powers

Customer due diligence that should be conducted by reporting entities

Transaction reporting, including cash transaction thresholds for all reporting entities

Targeted financial sanctions

Penalties- that can be taken against a non-compliant reporting entity, individuals etc.

2.2 FINANCIAL INTELLIGENCE DEPARTMENT

FID-Bhutan formerly Financial Intelligence Unit- Bhutan, was set up by the Royal Monetary Authority (RMA) in the year 2011 under the supervision of the Financial Supervision Department of RMA. In 2018, with the enactment of the AML/CFT Act of 2018, the FIU was upgraded to department and granted new functions and powers.



FID-Bhutan’s mission is to strengthen Bhutan’s financial systems and protect it against ML and TF activities. In order to achieve its mission, FID-Bhutan supports detection and analysis of ML and TF activities by collecting, analysing and disseminating financial data.

The core objectives behind the establishment of FID-Bhutan include –

Strengthening and ensuring effective surveillance of AML/CFT activities in the country

Upgrading compliance status of Bhutan as per FATF recommendations

Strengthening co-operation with international agencies and FIUs enabling adoption of best practices

Creating awareness of AML/CFT initiatives and efforts across Bhutan and financial institutions

Co-ordinating with LEAs, regulators and other stakeholders in detecting and preventing ML/TF threats

2.2.1 Organization Structure of FID-Bhutan

To support its functioning, FID-Bhutan has seven (7) officers that work in a flat, non-hierarchical fashion. The functions of the department are overseen by the Governor and Deputy Governor of RMA, who provide advisory level of guidance, with the Executive Director providing oversight and support on the day to day operations and overall strategy. The organization structure of FID-Bhutan can be found in Section 14.1

2.2.2 Functions of FID-Bhutan

The broad categories of functions of FID-Bhutan include policy formulation, information analysis and compliance and regulatory. The detailed functions can be found in Section 14.2.

Figure 1: Functions of FID-Bhutan



3 OVERVIEW OF THE CURRENT STATE

3.1 REPORTING ENTITIES

According to the AML/CFT Act of 2018, REs are financial institutions or Designated Non-Financial institutions, Businesses or Professions (DNFBPs), or any other agency deemed relevant and notified by the RMA of Bhutan. REs are required to manage ML/TF risks by undertaking assessments of ML activities, keeping records, applying customer due diligence and complying with the reporting guidelines of the law.

Currently, the types of reports submitted by the reporting entities are–

Suspicious Transaction Reports (STRs) for reporting of suspicious activity basis red flag indicators filed within 2 days of the transaction

Cross border currency transportation reports/money transfer reports submitted every month

Threshold reports/Cash Transaction Reports (CTRs) for transactions over Nu. 500,000 submitted on a monthly basis

Additional information on the indicative volume of reports can be found in Section 14.3

The diagram below shows a detailed list of all notified REs in Bhutan and their supervisors, whose role is to issue guidelines and directives to REs that are under to their purview.

Figure 2 Reporting Entities

Additional information regarding the obligations of REs or the AML/CFT Act of 2018 can be found on the FID-Bhutan website (https://www.rma.org.bt/fid/)

3.2 LAW ENFORCEMENT AGENCIES

In the context of ML/TF the function of LEAs is to investigate the cases disseminated to them by FID-Bhutan. If sufficient evidence of illegal activity is found from this information, then the case is forwarded to the Office of Attorney General for prosecution. The LEAs investigate the financial cases and leads reported to them by FID-Bhutan to build stronger cases against suspected individuals and entities. Often LEAs request additional financial information regarding case they may be investigating. The information requested can include KYC data, bank account summaries and transaction overviews.

More information on LEAs can be found in Section 14.4.

https://www.rma.org.bt/fid/



4 SCOPE OF WORK

The scope of work for the vendor includes system implementation, historical processing of data, maintenance of the developed system and exit management. The implementation and historical processing of data is planned for three (3) months with a maintenance warranty period of three (3) months.

The envisaged OARS shall be a web based system comprising of user-specific functionalities and common features. The web based system and shall only be accessible to authorized users. Given that FID-Bhutan receives, analyses and disseminates highly sensitive information, it is important to ensure that only authorized users (with the appropriate login ID and password) can access the data.

The vendor shall need to do the appropriate solution design and sizing for the project as per the scope of work and other terms and conditions of this RFP.

4.1 SYSTEM DEVELOPMENT

1. The solution developed by the vendor will preferably utilize the existing hardware stack in FID-Bhutan (as detailed in Section 20). If the vendor believes that additional hardware is required for the solution, they shall include the specifications in the proposal submission. Procurement of additional hardware shall be at the sole discretion of FID-Bhutan.

2. Bidders to note that FID-Bhutan may replace the existing hardware available for the envisaged solution. If the new hardware has not been made available to the vendor during the contract period, then the solution will be deployed on the existing stack. When the new hardware has been procured, the on-boarded vendor will be responsible for a data migration activity and deploy the solution on the new stack, provided the procurement occurs prior to end of contract. The details regarding existing data volumes can be found in Section 14.3.

3. The design of the solution and architecture shall be finalized in consultation with FID-Bhutan

4. The vendor shall ensure creation, submission and updating of all documents listed in Section 11 during the course of project implementation as per agreed upon timelines with FID-Bhutan

5. The vendor shall conduct thorough and systematic testing including unit testing, integration testing and User Acceptance Testing (UAT) for all user groups, in line with industry standards and best practices, Proper documentation and sign offs should be obtained for all these tests.

6. FID-Bhutan shall retain the strategic control over the design, development and operations of the project through the full term of the project.

7. The vendor shall execute the project as per the timelines described in Section 10

4.2 HISTORICAL PROCESSING OF DATA

This period shall consist of the processing of all existing CTR, STR and other reports in FID-Bhutan. This module is essential since it will integrate the historical data in the new system. In addition, this data can also be used to test and check the robustness of the system. Overall, there shall be migration, integration, transformation and analysis of data. Historical data shall include fewer than 25 counts of STRs and approximately 500,000 CTRs, all reported via Excel formats.

The scope of work for the vendor includes –

1. The vendor shall use new processes and tools developed as a part of this project to re-process all available data in FID-Bhutan

2. All processes from cleaning the data to entity and relationship resolution shall be carried on as a part of the historical data processing activity



3. The new system shall be accepted for go-live only when 100% historical data is reprocessed, validated and sign offs obtained from FID-Bhutan

4. The new system shall maintain all old cases disseminated and the copy of cases shall not be tampered with and shall remain available and accessible to FID-Bhutan and authorized LEA users.

4.3 MAINTENANCE

After go-live, the vendor shall provide 3 months of maintenance. In addition, the vendor at the time of the proposal, shall provide the Annual Maintenance Contract (AMC) cost for the software in the template provided in Section 22.

The scope of work during this period includes –

1. On an ongoing basis, vendor shall be responsible for troubleshooting issues in the IT infrastructure solution to determine the areas where fixes are required and ensuring resolution of the same. The vendor shall address all the errors/bugs/gaps in any functionality in the envisaged system implemented by the vendor vis-à-vis the submitted and approved Functional Requirement Specifications (FRS) and System Requirement Specifications (SRS) at no additional cost during maintenance period.

2. Any changes/upgrades to the software performed during the support phase shall be subject to integration testing by the vendor to ensure that the changes implemented in the system meet the specified requirements and doesn’t impact any other function of the system.

3. Issue log for the errors and bugs identified in the solution and any change done in the solution shall be maintained by the vendor and periodically submitted to FID-Bhutan

4. The vendor shall implement and maintain Standard Operating Procedures (SOPs) for the maintenance of the IT infrastructure based on the policies formulated in discussion with FID-Bhutan and based on the industry best practices/frameworks. The vendor shall also create and maintain adequate documentation/checklists for the same.

5. An indicative list of maintenance activities to be performed by the vendor is given below –

a. Corrective maintenance spanning fixing of errors that are observed when the system is in use. The scope of work during this maintenance shall include bug fixing.

b. Adaptive maintenance including the implementation of changes in the system that have been impacted by other changes. The vendor shall be required to conduct performance tuning and fine tune the processes that have been impacted by prior fixes.

c. Preventive maintenance involving the activities performed to prevent the occurrence of errors

4.4 EXIT MANAGEMENT

The responsibilities of the vendor pertaining to transition and exit management activities include –

1. The vendor will ensure business continuity during the transition

2. All risks during this period shall be properly documented by the vendor and mitigation measures shall be planned in advance so as to ensure a smooth transition without any service disruption

3. At the end of the contract period, FID-Bhutan will operate the system with shadow support from the vendor for a period of 2 weeks



4. The vendor will provide necessary knowledge transfer and transition support to FID/RMA IT team including user manuals for REs, FID-Bhutan and LEAs. The key handover activities are indicated below –

a. Complete documentation of entire system handed over to FID-Bhutan

b. Handover of the list of complete inventory of all assets created for the project

c. Detailed walk-throughs and demos for the system

d. Hand-over of the entire software including source code, program files, configuration files, setup files, project documentation, user IDs, passwords, security policies, scripts etc.

e. Hand-over of the user IDs, passwords, security policies, scripts etc.

5. In case the vendor fails to observe any of the above points, the vendor shall not be released and all the pending payments shall be put on hold till the successful completion of the exit management to the satisfaction of the FID-Bhutan



5 FUNCTIONAL REQUIREMENTS

This section details the core services or the minimum functional requirements of the system.

The functional requirements for the envisaged system have been devised keeping in mind the stakeholder feedback obtained, operational and administrative issues identified, and the technological advancements to keep the system and processes abreast with industry best practices.

The figure given below shows the high level functional block of the envisaged system. All the blocks given are described in the subsequent sections

Figure 3: Functional Block Diagram

5.1 COMMON FUNCTIONALITIES

Within the new system, there are certain features, functionalities and processes that are common across for all stakeholder groups.

5.1.1 Enrolment and Registration

The system should enable enrolment and registration for all user groups and be scalable to ensure that new users can be registered as and when required.

1. At the time of enrolment a new user group and new user will be assigned a unique number.

2. The user will be sent an enrolment email with the registration link. The system should also enable FID-Bhutan users to send reminders as per a configurable time period.

3. At the time of registration, the new user group or a new user shall enter details, the indicative format for which has been given in Annexure 2, and shall be finalized with FID-Bhutan.

4. All users will be asked to create a password at the time of registration

5.1.2 User and Profile Management

This section details the various user roles and rights for each entity along with the basic functionalities of user management.



1. Users shall be allowed to update their details as and when required.

2. The system should ensure that data privacy is maintained through strong user passwords. The system should also require a password reset as per a configurable time period.

3. In case the user is unable to login to the portal, or if there are a series of unsuccessful logins, (decided in consultation with FID-Bhutan) the user shall be locked out and a forced password reset will occur. FID-Bhutan shall also be alerted of the forced password change.

4. FID-Bhutan users should be able to deactivate, reactivate or register other user accounts.

5. Profile verification of users should occur at a configurable time period through verification emails, activity monitoring or any other mode decided in consultation with FID-Bhutan.

6. The system should enable audit trails for configurable parameters. The indicative functionalities that may require an audit trail can include user logins, time of logins, data upload and download etc. Note: these functionalities are non–exhaustive and will be finalized in consultation with FID-Bhutan.

5.1.3 Notification and Alerts

The system shall be capable of sending out notifications and alerts to all stakeholders. The type of notifications will differ based on the entity and the user. All users will be able to view relevant notifications and alerts on the web-based system and on the optional mobile friendly version of the portal. The indicative list of notifications can be found in Annexure 3.

5.1.4 Compliance Assessment

1) Every request for additional info/ by RE shall be given a compliance rating basis indicative parameters like quality of data, adherence to timelines, etc. Other parameters like inspection ratings can also be configured in the system, after consultation with FID-Bhutan.

2) Notifications regarding compliance shall be visible to users.

3) Actions shall be taken for the non-compliant entities. The actions shall include but not be limited to:

A notification shall be sent to the user indicating their non-compliance.

Further non-compliance shall result in formal communication being sent to an official in the reporting entity. The email will detail the instances of non-compliance and the prior measure that had been taken to correct it.

Non-compliance, post sending of the formal communication, shall result in the non-compliant user being named on the portal. The portal login page shall detail the entity and the user that have been non-compliant, in an effort to encourage them to comply in the future.

5.1.5 Feedback

The section below details the indicative feedback will be captured by the system and how it will be exchanged:

1) There will be one feedback interaction in the core services package:

LEAs feedback to FID-Bhutan

2) The feedback shall be filled and submitted via the portal.

3) Indicative LEA’s feedback to FID-Bhutan can be found in Section 17.1



The feedback form shall be filled by LEAs in case they reject a case. If a case is rejected, the reason for rejection and the case number shall be included.

If a case is accepted, the feedback form shall be submitted once the case has been closed.

5.2 RES

This section shall detail the envisaged state of operations for REs relating to report creation, report submission, actions post submission and the LEA request response process. With report creation, red flag indicators will have to be added to enable identification of suspicious transactions, and reporting formats have been standardized. All report submissions and data exchange shall occur via the portal, and users shall be able to view the status of their submissions. Lastly, reporting entity users shall also have a request response functionality for situations where LEAs request for additional information.

5.2.1 Report Creation

REs are obligated to report all suspicious transactions and cash transactions above a defined threshold to the FID-Bhutan. The expected outcomes of the new system for REs include enhanced quality of reporting, improved data exchange and communication mechanisms and enhanced learning and awareness. Overall, the new system is expected to simplify reporting and improve compliance of REs.

5.2.1.1 Reporting Formats

Currently, FID-Bhutan has multiple reporting formats that are filed by different REs. Different categories of REs file different formats of the same reports, and different entities within the same categories also file different formats of the same reports. For example, two banks may file CTR reports with different fields that have been arranged in a different order, resulting in difficulties in analysis. Overall, the reports currently filed by the entities can be categorized into two broad types:

1) Threshold based reports: these are the cash transaction reports that are filed when a transaction exceeds the threshold as defined by law.

2) Alert based reports: Alert based reports or suspicious transaction reports are generated when transactions are flagged against one or more pre-defined rules or red flag indicators. The red flag indicators shall be provided to REs by FID-Bhutan, and will be updated periodically.

For the purpose of filing reports, there shall be four types of reporting formats, which shall be shared with the on boarded vendor.

New reporting formats have also been created for REs that FID-Bhutan has identified. With the implementation of the new system, these entities shall be on boarded and initiate reporting. In addition, a master format has been created for REs that will be on boarded in the future. Lastly, counterfeit currency reports have also been created and will be reported by banks on a monthly basis. These reports will be submitted on the same day as they submit the CTRs. The following section details the reporting formats that shall exist:

1) Cash Transaction Reports

Monthly Cash Transaction Report Format for Banks

2) All Transaction Reports (ATRs)

Monthly All Transaction Report Format for Insurance

Monthly All Transaction Report Format for Securities

Monthly Foreign Currency Exchange Report Format for Money Services

Monthly Currency Transfer Report Format for Money Value or Transfer Services and Inflows and Outflows



Monthly All Transaction Report for Real Estate Agents

Monthly All Transaction Report for National Pension and Provident Fund

Monthly All Transaction Report Master Format

3) Suspicious Transaction Reports

Suspicious Transaction Report Format

4) Counterfeit Currency Report

The table below details the indicative reporting formats that shall exist, and the REs that shall file them:

Name of Report

Banks Insurers Brokerage

Firms

Real Estate Agents

NPPF Money Service

Businesses

Money Value or Transfer Services

DNFBPs

Cash Transaction Report

✓ X X X X X X X

All Transaction Reports

X ✓ ✓ ✓ ✓ ✓ ✓ ✓

Suspicious Transactions Report

✓ X X X X X X X

Counterfeit Currency Report

✓ X X X X X X X

Figure 4: Reporting Formats by Entities

Note: Currently, all reporting formats are submitted in Excel format. However, the system should also support use of XML format and web based forms.

5.2.1.2 Red Flag Indicators

Red Flag Indicators (RFIs) are used by banks to identify and flag transactions. Given that FID-Bhutan shall also be identifying STRs basis RFIs, the system should enable configurable alerts that can identify a suspicious transaction.

Example: If individual or related accounts is transacting more than A times the average account balance for the last B months, given that the average account balance is above BTN C.

5.2.2 Report Submission

To facilitate ease of filing reports/transactions for the REs, the system should support Excel and XML based templates and web based forms. The system should also enable uploading of additional documents (KYC documents, account opening form etc.). A validate option shall be inbuilt in the template for the RE user to check values against all fields for errors as per the validations and business rules configured in the system, to be finalized in consultation with FID-Bhutan. After the submission of report/transaction by the RE user, the envisaged system shall display an acknowledgement for the ones that are submitted successfully and generate a unique ID for identification.



5.2.3 Action Post-Submission

The system should enable users to view the status of the report that has been submitted. The indicative status codes can be found in Section 18 and will be finalized after consultation with FID-Bhutan.

If the report has not yet been processed, the RE user can make modifications to the report and resubmit it. The original report will also be visible to FID-Bhutan users.

I. Report Modification

Modifications may occur when a RE user feels that the information entered is incorrect or not updated. Modifications may also occur when FID-Bhutan rejects a report for failing validation. The following details the indicative process for modification of reports in the two cases:

A. Case 1: Recall or resubmission initiated by RE

1) In situations where RE feels that they might have sent erroneous data, they can initiate a recall or resubmission of the details entered.

2) The system shall provide options for recall and modifications against the original report/transaction itself.

3) A justification shall be provided if any of these options are used.

4) The status of the report shall be updated according to the action taken by the RE user with the date and time stamps.

B. Case 2: Recall or resubmission triggered by FID-Bhutan

1) Recall or resubmission shall be triggered by the FID-Bhutan in cases of rejection of the report due to validation checks

2) The RE user shall recall or modify the report and submit the updated document.

3) The status of the report shall be updated according to the action taken by the RE user with the date and time stamps.

4) Timelines for rectification and resubmission of the reports shall be decided in consultation with FID-Bhutan.

5.2.4 LEAs Request-Response

During the analysis or investigation of a case there may be a situation where either FID-Bhutan or LEAs need additional information. In such a case FID-Bhutan will send a request to REs via the portal. In addition, there may also be cases where LEAs are investigating a case that was not disseminated to them by FID-Bhutan and need financial information. In this situation, a request shall be sent to FID-Bhutan who will ask the relevant RE to provide the information. This data exchange of information shall have defined timelines (to be decided in consultation with FID-Bhutan) and all communication will occur via the portal.

It is important to note that for both additional information and reactive requests, LEAs and REs shall have no interaction amongst themselves. Rather the communication shall occur with FID-Bhutan.

For all processed transactions and reports, there can be one or more than one requests for additional information which are generated either by FID members or LEAs. There may be requests regarding new reports/transaction or other information which may be required by LEAs or FID members for analysis and investigation. The system shall generate notifications for all such requests. All LEA requests shall be visible to the FID members.

Priorities should be assigned to the requests by the request initiator and alerts shall be triggered according to the priorities assigned and the defined ‘response time’.



The indicative status codes for the request raised to the REs are detailed in Section 18 and shall be finalized in consultation with FID-Bhutan

5.3 FID-BHUTAN

Once the reports/transactions have been submitted by the RE, cases have to be created by the system and presented to the FID members for analysis and dissemination to LEAs. Another key requirement of the system is to optimize the process of creation, analysis and dissemination of cases to LEAs.

Overall, the expected outcomes of the envisaged system for FID-Bhutan include enhanced data analysis, improved communication and simplification of data exchange. In addition, it is also expected that the IT transformation of FID-Bhutan shall strengthen and facilitate interaction between all stakeholders.

The section below shall detail the envisaged state of operation for FID-Bhutan’s processes. It shall include data collection, case assignment, analysis, and compliance assessment. In addition, it shall also detail the envisaged interaction with additional stakeholders and the LEA-FID interface.

5.3.1 Data Collection

1) Once the REs have uploaded the reports, the files shall automatically get integrated from the portal to the server.

2) The key process of this system is extraction, transformation and loading (ETL) of data. The ETL module in the data collection system is responsible for pre-processing of data ingested. The ETL process deals with the basic validations, data cleansing and standardization. Data validation shall be added on FIDs end giving them an option to reject reports that are not in the correct format. This shall create two layers of validation, one at the end of REs and the other at FID-Bhutan. The system shall streamline all steps of data transformation including validation, standardization and cleansing.

3) The system should enable FID users to enrich and validate the data.

5.3.2 Case Assignment

This section details the case assignment functionality of the system. With the system reports shall be downloaded on to the FID-Bhutan server. If FID-Bhutan choses they can assign certain cases to certain individuals. These rules shall be configured in the system and can be updated as and when required. In addition, the user the case has been assigned to, can choose to share the report with other users within FID-Bhutan.

5.3.3 Analysis

The primary function of FID-Bhutan is to analyse the data that is reported by REs and disseminate the analysis of the reports to LEAs. By conducting analysis, FID-Bhutan can use data to discover useful information and connections, develop insights to help with decision making and make informed conclusions. Overall, the system must show all reported data on a person, account and legal person which shall be displayed in multi-dimensional data views that allow for data filtering, dynamic run-time clustering on multiple dimensions and display of aggregated information.

The following section details the indicative analytical functionalities present in the core services package. These features will enhance the quality of analysis and data that is disseminated to LEAs.

5.3.3.1 Rule Based Analysis

Rule-based analysis can enable FID-Bhutan to identify non-compliant activity. The system shall use a set of defined rules to present existing knowledge as actionable insights.

1) The rules engine shall scan for all historical and current data stored in the system.



2) All data that matches certain rules as defined by FID-Bhutan shall be identified.

3) These rules can consist of facts, circumstances, patterns of behaviour etc.

4) These rules shall be configured in the system and regularly updated.

5) All identified reports that match the circumstances defined in the rules shall be flagged and displayed to FID-Bhutan users. In case of a report being flagged, an alert will be issued to FID-Bhutan users.

6) Examples of the rules (to be finalized in consultation with FID-Bhutan) can include:

Change in transaction pattern

Occupation category

Nature of business category

Geographical location

Monthly income range

Source of Funds

Purpose for loans

Type of transaction

5.3.3.2 Risk Profiling

The section below details the operation of the risk profiling functionality of the system:

1) The system shall compute and display risk categories for individuals, entities, accounts and other parameters decided by FID-Bhutan. The purpose of the risk assessment is to provide an in-depth view of how vulnerable a given entity/individual is towards money laundering and to flag high risk cases for immediate action.

2) Risk profiling will be conducted against the following indicative entities:

Individuals/Entities

REs

Sector/Industry

Geography/location (using reporting data)

3) Based on the data sources, risks categories will be assigned. These will be high risk, medium risk and low risk.

4) The list below details some of the variables that will be used for creating risk profiles. The variables include but are not limited to

Individual/Entity

Example: Person/entity linked to individuals with STR: related individual shall be high risk, and individuals with no linkage shall be low risk. There shall be no medium risk.

Sector

Example: Maturity of sector

Reporting Entity



Example: Number of individuals with high risk ratings: on the basis of the number, high, medium and low risks shall be assigned

Geographical Location

Example: Distance of location from sensitive border areas

5.3.3.3 Historical Data

Currently, FID-Bhutan has a backup of all data from 2013. This backup includes the reports disseminated in the past along with FID-Bhutan’s analysis of the same. Analysing and searching through the historical data is an essential aspect in analysis and can enable FID-Bhutan to find trends and patterns.

1) All historical data, currently stored in Excel files should be consolidated and integrated into the new system.

2) Once consolidated, the historical data should be used as a base for analysis. Past records should be used to identify trends, create risk profiles, link relationships and forecast.

3) All incoming reports should also be permanently stored

5.3.3.4 Trends

Efficient and accurate identification of patterns and trends of money laundering can be used to augment preventive measures in the ecosystem. In addition, trends can be used to forecast and make projections.

Indicative examples of trends, to be finalized in consultation with FID-Bhutan may include –

1. Sector trends: frequency of reports, volume of transactions, income levels

2. Acceptance and rejection rate of a case from each LEA

5.3.3.5 Relationship/Entity Linkage

Link analysis shows entity relationships and their strength. With entity linkage, the dashboard shall visually illustrate interactions of people, entities, bank accounts, geographical locations etc. The user shall be able to view the network and flow of relationships and transactions and identify hidden relationships.

The entity and relationship resolution feature shall capture all unique entities and relationships present in the reports/transactions filed by the REs and the data inputs from external data sources (if available).

1) Information including but not limited to the following shall be collected and analysed

Data on unique entities

Data on relationships and the degree of the relationship

Occupational data

Location data

2) The system shall identify confirmed and probable linkages between entities using reports which are being filed and optional external data/information which is being gathered by the system.

3) All linkages and relationships shall be displayed with a percentage (%) probability score/confidence level.

4) The envisaged system shall resolve and present entities and relationships with the following key objectives –



Establish and compute meaningfulness of the relationship/linkage on the basis of different attributes (personal, professional etc.)

Develop a 360° financial profile of an individual and perform risk assessment of the same

Identification of Ultimate Beneficial Owner (UBO) in case of business entities and complex relationships

7) Visualization tools including but not limited to relationship trees and timelines shall be employed to depict entities and relationships resolved. FID-Bhutan users shall also have the option to analyse all linkages by examining the underlying logic which generated the linkage.

8) The system should identify relationships across different entity types as well (between accounts and individual, individuals and businesses etc.) through comparison between multiple attributes like name, addresses, Citizen Identity (CID) Card number etc.

9) The envisaged system shall store all uniquely identified relationships and entities and compare all incoming reports with this list as well.

10) Alerts will be generated for all existing cases for which new entities or relationships have been identified.

11) In addition, FID-Bhutan users shall be able to define additional relationships or correlate entities on the basis of their own analysis. All such additional relationships shall be captured, validated and updated by the system.

12) In addition to the aforementioned requirements, the envisaged system shall also be able to function effectively in cases like the following:

Process and correlate records without exact match which may be due to poor data quality and should be taken care by probabilistic and imperfect matching. Process and correlate records despite interchange in elements, abbreviations, or equivalences. For example, Sonam Tshering or Tshering shall be considered for matching provided other parameters are similar as well

Maintain and update a list of ‘noise’ words or words which do not add value to the processing.

Generate and show interactive path(s) or similarity(s) between two separate entities in terms of the people they know or are related to, businesses they are involved in etc.

5.3.3.6 Clustering

With regards to AML/CFT activities, clustering can be used to group transactions that have the most similarities with each other. These techniques can help FID-Bhutan detect patterns in suspicious transaction or identify high risk accounts and customers.

The indicative sources used for clustering should include:

1) All historical data

2) All current data

3) External databases, including CID, if available

5.3.3.7 Watch List

Every LEA will create a watch list consisting of potential leads. These leads may be in the form of CID numbers, phone numbers, addresses or names. This list will be disseminated to FID-Bhutan and updated regularly by the LEAs. Overall, the system shall allow for creation of watch lists that will act as



profiles on selected target of interest and provide FID-Bhutan with an overview of the information on the selected physical or legal person and related accounts.

The following details the process and functionality of watch lists:

1) An alert will be issued indicating the submission of a watch list by an LEA.

2) FID-Bhutan shall have access to CID and RoC databases. The system should enable inputs from these databases to enrich the analysis.

3) Using imperfect matching techniques, a match despite variations in spelling will be noted, in case of an error.

4) FID-Bhutan will request for all transaction data for the individuals on the watch list every two days

5) When an STR or CTR is reported, the watch list will be scanned. In case of a match, the individual’s case will be disseminated on a priority basis to the LEA who added the person on the list.

In addition, FID-Bhutan shall also create their own watch list. Individuals and entities on this watch list shall be assessed on a priority basis. If individual on CTR is deemed to be suspicious, a case shall be submitted to the relevant LEA. In addition, if individual is named in a STR, then the case shall be disseminated within a configurable duration decided by FID-Bhutan.

5.3.3.8 Macro Level Analysis

In order to develop insights, the system will conduct macro-level analysis and display to FID-Bhutan users on the dashboard. Macro level analysis can enable FID-Bhutan to understand and mitigate the risks of AML/CFT activities.

1) The following indicative inputs, to be finalized with FID-Bhutan shall be analysed by the system:

Volume of transactions

Value of transactions

Typologies of money laundering

Red flag indicators

Case disseminated to LEAs

Inflow and outflow of money

Geographical locations

Remittances

2) Information can be given about a certain month, and the user will be able to analyse how many transactions occurred in a certain city and at what volumes.

5.3.4 Dashboards

The system shall provide dashboards for FID-Bhutan. The dashboards for FID-Bhutan users shall display a high level view of the overall system, and trends and statistics for different user functionalities. These indicative statistics shall include data regarding number of pending cases to be analysed, number of user administration requests pending action, performance of FID users, number of open LEA requests etc. In addition, it will also include trends, charts and risk profiles to enable analysis.



The content to be displayed in each of the dashboards mentioned above are indicative and shall be finalized in consultation with FID-Bhutan.

5.3.4.1 General Features of the Dashboard

The following details the general features of the dashboard for all user profiles across entities:

1) The dashboard should support drill-through/hypertext links

2) The data displayed in all dashboards shall be updated in a timely manner and the user shall be given an option to view trends over a selected period of time. The trend span shall be configurable by the dashboard user.

3) A section highlighting critical issues and red flags shall be present within the dashboard. Any exception like breach of a deadline or a low compliance of a reporting entity shall be specifically highlighted in this section.

The following details the indicative data to be displayed of the FID-Bhutan dashboard which shall be finalized in consultation with FID-Bhutan:

1) RE compliance: All REs will be regularly assessed for compliance on the basis of certain variables. This compliance assessment shall be updated periodically and accessible to all FID-Bhutan users.

2) User activity: FID-Bhutan users will be able to view the user login behavior of REs, FID-Bhutan users and LEAs users Indicative variables that can be assessed include- abnormally high number of logins per day, untimely login beyond office hours etc.

3) Incoming report details: indicative variables, to be finalized in consultation with FID-Bhutan include incoming reports, entity that filed the report etc. This data shall be useful in identifying frequency and volume of reports and assessing where the reports are coming from.

4) Analysis details: FID-Bhutan users shall also dashboards detailing the analysis that has been conducted by the system. This analysis will be displayed in a visual format, to enhance the comprehension of data. The dashboards can be used during analysis to develop insights, view trends and patterns etc.

5) Dissemination details including indicative variables, to be finalized in consultation with FID-Bhutan, like time taken to disseminate a case, the LEA the case was disseminated to etc.

6) User group details: information regarding patterns of RE and LEA users

5.3.5 LEA-FID-Interface

LEAs and FID-Bhutan interact for two central objectives:

I. Dissemination of Cases:

1) All cases shall be disseminated to the LEAs within the defined timeline via the portal.

2) FID users shall be able to upload the case on the portal and select the LEA to disseminate the case to.

3) The LEA user shall be able to access the case and either accept or reject the case. In case of rejection a reason shall be given.

The format for case dissemination shall include the inputs from the REs along with details of analysis of FID-Bhutan. The case dissemination format will be shared with the vendor after on-boarding.



II. Dissemination of Reactive Information

For reactive requests, all cases shall be disseminated and made available to the corresponding LEAs through the envisaged system, within forty eight (48) hours of the request being raised, or configurable duration decided in consultation with FID-Bhutan.

Requests for information can be of two types:

A. Reactive Requests

1) Reactive requests correspond to requests from LEAs for dissemination of STRs based on a specific criteria.

2) The system shall automate dissemination of all such cases and route them through the system itself. The FID member shall be able to view requests through the portal.

3) The FID-Bhutan members shall be able view whether the information regarding the request is available with them. If not, then they shall reach out to the REs for the required information.

4) If information is available within FID-Bhutan then they shall revert back within a configurable timeline. In case the information is not available, requests shall be sent to the RE within a configurable timeline, decided in consultation with FID-Bhutan. Once FID-Bhutan receives the information from the REs, they shall disseminate to the LEAs

5) The envisaged system shall keep track of user actions against all requests and update the status automatically.

6) The system shall issue periodic reminders to the recipient REs. The response time of REs may be recorded and used as an input to assess compliance.

7) Once the response is received from the recipient RE, the envisaged system shall present the data to FID-Bhutan users for subsequent dissemination.

B. Requests for additional information

1) FID members shall also be allowed to raise requests and direct the same to one or more REs.

2) The requests once received shall be automatically assigned to one or more REs.

3) The envisaged system shall issue periodic reminders to the recipient REs. The response time of REs should be recorded and used as an input to assess compliance.

4) The status code for the exchange should be updated by the system.

5.4 LEAS

Currently, the dissemination occurs manually via hard copy and the decision to disseminate and LEA selection is subjective. In addition, LEAs face difficulties in getting information, and there is no standardized process for requesting information. Often, banks also send incorrect information and details that were not requested, leading to further difficulties in investigation. Lastly, there is scope for improvement regarding adoption of financial investigation. Overall, there is potential for intervention in the dissemination and investigation processes of LEAs.

5.4.1 Data Exchange

Data exchange between FID-Bhutan and LEAs currently occurs via hard copy. As part of the IT transformation, a key objective is to build a system that allows for seamless communication between the two entities, and to ensure that this mode of communication allows for secure dissemination of cases. The mode of exchange that shall be used for dissemination is a portal based dissemination. Authorized users of the recipient LEA can access, view, and download cases in PDF formats, or other formats decided in consultation with FID-Bhutan.



Note: FID-Bhutan has existing Standard Operating Procedures (SOPs) with LEAs for data exchange. These SOPs have led to the creation of multiple forms used for requesting and disseminating information. The vendor will be responsible for ensuring that the system is compliant with the SOPs and the required forms for interaction with LEAs are configured in the system. The existing forms will be shared with the vendor during the requirements phase.

The section below details how LEA users will access the portal

1) There shall be multiple users within the LEAs although all of them shall have the same rights. After the enrolment of the LEAs, access to the portal shall be allowed. A simple login through password shall be there.

2) In case a user has forgotten their password, the system will display a link to reset the password. Upon clicking the link, the system will prompt the user to enter the e-mail ID to receive the password reset link. The link shall redirect the user to the password reset page. The user can change the password and login successfully to the portal.

5.4.2 Case Viewer

The section details the case viewer functionality of LEAs. It details how LEAs can respond to a case and the download and export options.

A. Incoming Reports

When accessing a case the system shall enable the LEA user to accept or reject a case, with a notification of acceptance or rejection being sent to the FID user.

B. Download and Export

For ease of use, the system should also allow users to download and export reports as necessary. The feature can be included in the case view functionality, wherein users can download cases. Security measures should be taken to ensure that confidentiality is maintained and information is not leaked. However, measures should also be taken to ensure that if an information leak occurs, there is a way to trace the individual in question.

5.4.3 Request from LEAs

Requests from LEAs can be of two types:

1) Additional information for investigation: this occurs when LEAs are investigating a case disseminated to them by FID-Bhutan and require additional information for proper investigation.

2) Reactive reporting: reactive reporting occurs when LEAs investigate a case that FID-Bhutan has not disseminated to them.

Indicative status codes for these processes can be found in Section 18

The section below details the functionality for requesting information:

1) Reporting formats should be created for additional information requests, in consultation with FID-Bhutan/

2) This request format will be used by all LEAs and uploaded via the portal.

3) The LEAs shall assign a priority rating to the requests.

4) In addition, the system should also allow for tracking of the reactive report request. LEAs will be notified when they submit a request, when the RE is notified, when the information is with FID-Bhutan etc. The indicative status codes will be issued against all such requests and notifications corresponding to each of these status changes shall be triggered and sent to FID-Bhutan and the corresponding LEA user.



5.4.4 Watch List Management

The section below details the structure and functionalities of the watch list:

1) Each LEA will create a watch list of people and entities that they consider to be high risk or suspicious

2) The watch list will be uploaded onto the system by each LEA and sent to FID-Bhutan. The name of the agency where the watch list is coming from is specified.

3) The system shall match the individual with their CID and other available databases to build the complete profile of the individual. Only the LEA users shall be able to create a watch list.

4) FID Bhutan will request transaction data of watch listed individuals from REs on a periodic basis. This data shall be analysed and stored in the system. If necessary this data shall be shared with the LEA.

5) When FID-Bhutan receives a case, the watch list CID numbers will be scanned, and in case of a match the report will be flagged. The flagged report will be analysed and disseminated on a priority basis to the agency that watch listed the CID. In case two agencies watch listed the same CID, the case will be disseminated to both.

6) Historical CTRs shall also be scanned to identify and flag any potential matches.

7) Each LEA will be able to update the watch lists on a regular basis.



6 TECHNICAL REQUIREMENTS

This section provides the broad technical requirements of the envisaged system. The vendor should ensure that the technical solution proposed addresses all scope of work, functional, technical and operational requirements of the envisaged system.

6.1 KEY DESIGN PRINCIPLES

The following key design principles needs to be taken care while building the architecture for the envisaged system –

1. Manageability: The envisaged system is expected to have multiple modules, processes and interface with the users. Given the system complexity, hardware failure, network outage, or software crashes are inevitable. Hence the system architecture should be able to handle these failures suitably, or be resilient to failures and fix the issue with minimal human intervention. For complete lights out operation, all the modules of the system should be managed through automation.

2. Configurability: The IT system discussed will act as an interface for REs, LEAs and FID team. Hence the usability and configurability becomes a crucial success factor for the system. The decision makers, FID in this case should be able to add or modify/delete any existing rules with appropriate permissions and audit trace.

3. Security: Security and privacy of data within the system will be foundational keeping in view the sensitivity of data and critical nature of the intelligence infrastructure proposed to be built. The system will ensure privacy and data integrity and must disseminate data to authenticated and authorized users only (both internal and external users). The envisaged system should be compliant with data security and privacy laws in Bhutan.

4. Systemic Development: In the world of evolving technology, the system developed should be aligned naturally to adapt to new technologies, concepts and ideas especially in FIUs globally, since they have to be ahead of the financial criminals in technological advance. The vendor will have to ensure that the system has loosely coupled components enabling changes in sub-system level without affecting the other parts of the system. The proposed system architecture should be highly decoupled, multi layered and integrated solution.

5. Scalability: The solution selected should be flexible and designed to handle the growing demands of data volume and complexity in future. The simplified reporting processes and ease of compliance is expected to increase the reports filed with FID-Bhutan and thus, the system needs to scale horizontally to large volume of data. The vendor will have to ensure that it is well-positioned to handle the growing demands of the envisaged system

6. Reliability: The system must have appropriate controls and validation to ensure processing reliability of the data received and accessed through the solution. As this is a very crucial system and data are of high sensitivity, the data transfer and data management should be reliable to maintain the confidence of the stakeholders. It will be necessary that the following issues be taken care properly-

a. Prevent processing of duplicate incoming files / data

b. Prevent unauthorized access and alteration of the data uploaded

7. It is also proposed that the entire solution should have flexible and scalable architecture with well-defined presentation layer, business logic layer and centralized data source layer to support the efficient handling of data and business logic, and enable streamlined delivery across various access channels.



8. While the key features have been specified at each layer, it is a necessary requirement that the solution should enable complete integration between different modules to enable building of workflows which may leverage information across the modules. The functionalities and features of the system should be granular and modular enough for the administrators to enable or disable any particular functionality, at any given time, as per the requirement

9. Additionally, the following requirements of the solution from a design perspective and features should be complied with –

a. The key expectations from the solution are that it is user friendly, intuitive, and the underlying components are loosely coupled and scalable to meet the future loads.

b. All hardware and software products should not intentionally or unintentionally misbehave to send sensitive and configuration data outside FID-Bhutan



6.2 LOGICAL ARCHITECTURE

This section provides an illustrative view of the solution architecture at a high level for the system requirements. The diagram below details the logical architecture.

Note: The architecture below is illustrative and the modules defined may not be physically separate.

Figure 5: Logical Architecture



Data providers: Data providers of the system consists of various REs and other departments sharing complementary databases for analysis like CID, RoC etc. The reporting format can be Excel and XML in case of RE reports, however other departments can report in other formats like database backup files, MS Access etc. whichever is suitable and agreed.

Data Sourcing Mechanism: There are only two data sourcing mechanism defined for the new system. Most of the data sharing will happen from the web portal system both by REs and Other departments. However the departments sharing complementary databases to support investigation may choose offline database exchange depending on the suitability, frequency and preference.

Staging Layer: Once the reports are shared through the web portal or offline database mechanism, the raw data will be stored in staging area acting as an intermediate storage area used for data processing during the ETL process. There should be different databases in this layer for RE and other complementary database since they both will have different ETL processes.

Data Transformation: This layer will be responsible to perform ETL process involving data extraction from multiple sources, cleansing/transforming to enrich the raw data and then storing it in an appropriate format for querying and analysis purposes. Data validation check will also be included to check the quality of reports submitted specially by the REs.

Core Data Repository: After the preprocessing of data, the data is stored in standard formats in the suitable layers like master data, transaction and audit data. The audit layer will also store the data pertaining to user activity on web portals. The layer of Master, transaction and audit data will not be exposed to internet and hence two different data marts are proposed which will act as a subset of the core data repository to be accesses on the web portal by external users like LEA and RE. The data marts will only contain data relevant to LEA and RE reporting and other sensitive data may not be exposed over the internet for security purposes

Analytics Layer: this layer will act as the core data analytics section of the system. It will be responsible for carrying out several analysis like rule based, clustering, typologies, macro level, link analysis, risk profiling etc. This section will also be augmented by Alerts and Rule engine which can help uncover suspicious cases and manage watch list better.

Presentation Layer: The input to this layer will be from data sourcing, data transformation, core data repository and analytics engine. This layer will cater to all the reporting needs like user activity reports, data quality report, operational reports, analytics insights, case reporting etc.

User Layer: This will act as an interface to all the users who can access the reports shared with them. There will be majorly 3 types of users namely RE, FID and LEA users.

6.3 KEY SOLUTION COMPONENTS

The sections below provide an indicative list of functionalities for the minimum number of components needed for the envisaged system

6.3.1 Email Service

Email services are envisaged to be made available as part of the solution design to send alerts / intimations / automated messages to registered email ids, based on preferences set up / opted by individual users. The e-mail service should be equipped with standard e-mail functionalities like compose mail, save as draft etc.

6.3.2 Web Portal

The web portal shall be an interface to the REs, FID users as well as LEAs. There shall be password controlled access to the users before serving the dashboard as the home page. The contents of the



dashboard are decided based on functions and relevance of users. Multiple logins shall not be allowed to any user under any circumstances.

Some of the specifications of the web portal are provided below –

1) The UI layer should not have its data

2) The portal should support workflows

3) The portal should support all leading browsers such as Internet Explorer, Firefox, and Chrome etc. on all devices and form factors.

4) The portal should be able to expose / publish functional applications seamlessly

5) The portal should provide support for comprehensive audit trail features

6.3.3 MIS, Business Reporting and Business Intelligence

The system would receive, store and process data from REs across the country. Over a period of time, this data shall provide information for useful analysis both for compliance as well as to discover patterns and exceptions. It is desirable to make use of an appropriate BI tool to analyse and correlate the data and generate reports in various forms which would provide necessary inputs and enable FID members and LEAs of the country to derive fruitful information. The BI and analytics platform would comprise of the following components:

1) Data ware housing and analytics

a. The data warehousing platform should have the capability to handle incremental load at various frequencies (daily, monthly, real time etc.)

b. The data warehousing platform should have the ability to understand, map and define rules for migration from different sources.

c. The solution should have data quality and data profiling capacities.

d. Data cleansing techniques should be included to enrich data at all levels.

e. The tool should be capable to handle ETL of both structured and unstructured data from various data sources.

f. The solution should be integrated with data mining tool, which would have capacity for different techniques of statistical modelling.

g. The solution should have inbuilt analytics and statistical tools capable of performing statistical modelling and analysis on data

h. The proposed solution should have support for large data sources. The solution should be able to analyse large volume of data and generate visualizations on the fly, without any performance degradation.

i. The proposed solution should be capable of anomaly detection (outlier detection) to identify unusual values that might be data error or issue that requires further verification.

2) Visualization and Reporting

a. The solution should have robust interactive visualizations such as graphs, charts, and histograms.

b. The solution should be able to provide reports around geographic, spatial and time dimensions.

c. The MIS reports generated by the proposed solution shall contain the name of the person generating the report along with date or timestamp in form of watermark.



d. The reports generated by the system should be made accessible through the portal to be viewed by the authorized users.

e. The interface for the authorized users should be web browser based and simple with user friendly features.

f. The proposed solution should have the capability of raising exception alarms.

g. The proposed solution should have user friendly GUI to allow easy generation of reports and exporting capabilities (ability to export resulting data to PDF format)

h. The proposed solution should be able to distribute reports and also have the ability to save data for later use. It should support offline viewing. It should be able to send reports electronically to other users.

6.3.4 Business Process Management

The envisaged should be equipped with workflows, with possible routing/ exchange of information, and involving all the stakeholders of the system along with FID users. The workflows should be flexible and allow upward flow and downward flow of processes and inclusion of new users. These factors – the dynamic nature of business requirements, need for multi-users and workflows, involvement of multiple stakeholders in a business process/ workflow, would require a BPM in the overall architecture of the solution. Following are the minimum requirements–

1) The proposed solution should act as a single central repository for managing business processes.

2) These workflows shall require and support integration with external systems.

3) Workflows should be able to handle navigation, authorization, notification and critical-path analysis of defined business processes.

4) The proposed solution should have the provision of regular monitoring of different business processes as meaningful dashboards. These reports should be integrated with the overall Business Intelligence (BI) solution proposed.

5) The proposed solution must implement process governance (e.g. access control, version control and audit trail).

6) The proposed solution should analyse process metrics and optimize processes.

7) A key requirement of the proposed solution is mechanism for seamless process definition. It should support easy workflow configuration, its maintenance, and need based modification, addition alteration of the steps and support process modelling.

8) The proposed solution should offer both process activity monitoring and performance monitoring features.

9) The proposed solution shall be capable of identifying, reporting inefficient processes and operations and/or those with high level of error and omission.

10) The proposed solution should have capabilities to allocate and distribute generated tasks to users and user groups.

6.3.5 Rule Engine (Configuration and Management)

Considering the business context of the envisaged system, one of the key design principles for guiding the solution approach is that the technology choices and implementation approach should be built for change i.e. to architect the solution which is acceptable to change with negligible business disruption. The envisaged system would involve complex rules for validation, computation and matching. A rule



engine needs to be leveraged for implementation of these business rules and to create parameterized and configurable business rules.

1. Solution which will be capable of handling all business rules, from simple to complex workflows shall be proposed.

2. The proposed solution should provide a rule engine and a management platform.

3. The proposed solution should support automated message and information routing capabilities based on pre-defined rules like sequential routing, parallel routing, rule based routing etc.

6.3.6 Case Management

1) The system shall generate a unique identification number i.e. case ID for each of the cases developed and displayed on the case inspector tool.

2) The system should be able to record, track and monitor all the updates against each of the case ID and shall maintain such records.

3) The system should be able to allocate case IDs to FID users through a standard case allocation scheme decided by FID-Bhutan.

4) The system shall provide for assigning of status by a particular user for each of the case IDs assigned to him/her.

5) The system must facilitate alerts and messaging to the users regarding allocation, time extension and withdrawal and reallocation (only to the user to whom the case is allocated) as per the case may be.

6.3.7 Entity and Relationship Resolution

1) The solution should access, store, and analyse structured and unstructured data from various sources.

2) The solution should have predefined rules for performing direct matching.

3) The solution should have predefined algorithms/rules for matching, based on fuzzy logic, in addition to direct values.

4) The solution should be able to classify the entities into same, similar or different clusters

5) The solution should present information to users in visually intuitive manner

6) The solution should also have the ability to add more links to the existing relationships and de-link the disjoin matches (manually or rule based)

7) The system should be capable of handling variations in the attributes on account of spelling mistakes, abbreviation, sequence variation, missing/extra parts, differences in date/month/year, variations in locality/sub localities etc.

6.3.8 Solution for ETL

The solution shall have the facility to extract data from multiple data sources, transform the data to make it accessible for analysis, and load the same to multiple target(s) if needed.

1) The solution should allow for bulk movement of data to the server storage and the database.

2) The solution should provide the facility for error handling and reporting through alerts for the likes of data related errors and tool related errors producing an event log containing information like time/status of operation/reason for failure etc.

3) The solution should have the facility to profile data within the data quality, name and address enrichments tools and then directly use those results for cleansing.



4) The solution should provide the facility of configuring and using user defined rules for data validation.

5) The solution should be able to define and update rules for sufficiency, correctness and enrichment of input data.

6) The solution should also have the following functionalities:

a. Formatting input values in consistent and standard layouts

b. Generate output files in multiple formats

c. Capability to secure sensitive data by data masking techniques / algorithms so as to facilitate development and testing efforts without compromising data security

7) The solution should have the facility for an administrative console having an end to end process designer with viewing of metadata, tables and columns and records in the system. This should also include design, view, and management tools to facilitate various role-based functions spanning process design/development/testing/refining, administration and configuration, performance monitoring, metadata management, and reporting/analysis.

6.3.9 Data Confidentiality

To ensure data is securely accessed only by required teams and applications, the following principles are to be adhered–

1) All the databases must be accessed by individual user accounts and user accounts cannot be shared by multiple persons or as a team based accounts. All accounts should uniquely identify individuals and access to be provided to limited/authorized users only. The access policy shall be finalized in consultation with FID-Bhutan.

2) All the databases/systems must be integrated for centralized control. This should also enable disabling of user accounts when a person leaves the organization

3) The core system and FID-Bhutan’s portal shall be hosted on the intranet and only accessible to authorized users.

4) There shall be account monitoring through log generation



7 OPERATIONAL REQUIREMENTS

This section describes the operational requirements of which includes acceptance testing, solution maintenance, design, support, man power deployment etc.

7.1 PROJECT MANAGEMENT AND REPORTING

1) Creation and Approval of Project Plan

a. Define an organised set of activities for the engagement with defined timelines and schedules

b. Establish and measure resource assignments and responsibilities

c. Construct, communicate and obtain sign-off on a project plan schedule with milestones

2) Periodic Reporting

a. The vendor shall generate periodic progress reports and share the same with ADB, FID-Bhutan and the project management consultant. The frequency of reporting shall be decided in consultation with the project management consultant.

b. The progress report should clearly highlight milestones accomplished, cumulative deviations from schedule, planned corrective actions foreseen risks, mitigation plans etc.

c. In case the vendor is proposing a revision to planned schedule provided such revision is necessitated by reasons beyond the control of the vendor, the progress report should clearly mention that.

3) Risk Management: the vendor shall maintain detailed risk register with mitigation plans and escalate risks when required

4) Quality Assurance (QA): A thorough quality check is proposed for the system and its modules. The vendor is expected to lay down a robust QA program for testing of the developed application for its functionalities, performance and security before putting in the production environment. The program must include an overall plan for testing and acceptance of system, in which specific methods and steps should be clearly indicated and approved by the stakeholders. The vendor shall share the QA management plan with FID-Bhutan and project management consultant. The vendor must undertake the following –

a. Define QA approach including quality planning and control methodology.

b. Map project processes against the stakeholder expectations, planned QA activity, frequency and the responsible resource.

c. Define the various levels or types of testing that will be performed for system including but not limited to unit testing, system integration testing and user acceptance testing.

d. Provide necessary checklist/documentation that will be required for testing the system.

e. Describe any technique that will be used for testing the system.

f. Indicate / demonstrate to stakeholders that all applications installed in the system have been tested.

5) Documentation and Version Control

a. The vendor shall ensure that the audit trail, version control and searchable history of all project documents presented and approved shall be maintained in a single secure



repository where the administrator access shall be in the custody of authorised personnel finalized in consultation with FID-Bhutan.

b. The vendor shall prepare documents including but not restricted to approach documents, detailed design (both High Level Design Document (HLD) and Low Level Design Document (LLD)) documents, test cases and results etc. The list of all documents required is given in Section 11

c. All artefacts should be stored in editable as well as print ready formats with review history.

d. The vendor shall update the design document through the engagement

e. The vendor shall keep a detailed record of all observations provided on outputs/deliverables and incorporate stakeholder comments

7.2 SOLUTION MAINTENANCE AND SUPPORT

The following section describes some indicative areas of responsibility of the vendor–

1. During the project and subsequent warranty period, vendor shall be responsible for defect free functioning of the application and shall resolve any issues that include but is not limited to bug fixing, improvements in the user interface for a period of 3 months

2. The vendor shall provide the latest updates, patches/ fixes, version upgrades relevant for all solution components. The vendor shall be responsible for software version management, and software documentation management reflecting current features and functionalities of the envisaged system.

3. Any changes/upgrades to the software performed during the operations and maintenance phase shall be subject to the comprehensive and integrated testing by the vendor to ensure that the changes implemented in the system meets the desired and specified requirements of FID-Bhutan and doesn’t impact any other function of the envisaged system.

4. The vendor shall ensure continuity in operations of all functionalities of the system while performing the tasks mentioned above.

5. Security management including continuously monitoring security and intrusions into the system

6. Monitor and track server and network performance and take corrective actions to optimise the performance on a daily basis.

7. System administration tasks such as managing the access control system, creating and managing users as per the relevant policy and other related work

8. Data storage management activities including regular backup and restore if need be



8 ADVANCED SERVICES PACKAGE

As indicated in the Note to Bidders, the scope of work in this RFP has been bifurcated into core services and advanced services. Although the advanced services package is not compulsory in the proposal submitted by bidders, bidders will be given additional marks for the value added services that they provide. The following indicates the evaluation for the advanced services package as compared to the core services package –

S.No Criteria Maximum Additional

Marks Provided

1. Mobile Friendly Portal 70

2. Trainings and E-learns 70

3. Helpdesk 50

4. Report Monitoring 60

5. Additional analytics modules for FID-Bhutan*

150

6. Value Add proposed by vendor 200

7. Additional onsite deployment 100

Total 700

Figure 6: Advanced Services Package Evaluation

Note 1: The overall evaluation criteria can be found in Section 13

Note 2: The maximum marks that will be provided for the technical proposal is 1000. The maximum marks provided for the advanced services package will be 100. The formula used for calculation of the bidders score shall be= 100x/700, where x is the score that the bidder receives basis Figure 6. The figure below details an example of the normalized score-

S.No Technical Score Calculation Normalised Technical Score 1 50 100(50)/700 7.14 2 200 100(200)/700 28. 58

Note 3*: if the vendor provides additional analytics modules, beyond those detailed in Section 5.3.3, they shall be awarded higher marks in the technical evaluation

8.1 MOBILE FRIENDLY PORTAL

The system will have a mobile friendly interface, which will be accessible from the internet application on all mobile devices. Functionalities such as dynamic content and simplified images should be included to ensure user-friendliness. Content on the mobile friendly version of the portal shall be limited to ensure data security. Access lists shall also be utilized to ensure data security standards are upheld.

8.2 TRAINING AND E-LEARNS

The system shall incorporate a solution via which the core operation people are trained using technology. Thus, E-learns shall be included in the system to address improvement areas identified by



FID-Bhutan. Modules for online self-paced learning should be created and administered through the portal itself.

The following details the key features of the e-learns:

1) The training shall be created in a way that ensures widespread access for users across REs, FID-Bhutan and LEAs.

2) The trainings will be disseminated via the portal in the form of PDF, videos and pamphlets.

3) The trainings will include ample visual content to enhance learning. They may also include audio and video content as optional features. This content can include how-to videos and step-by-step guides. How to guides and FAQs will also be available.

8.3 HELPDESK

The new system will also have a simple helpdesk feature available to all reporting entity and LEAs users. The helpdesk will consist of a ticketing system where the user shall be able to raise a ticket via the portal. Routine support tasks like need for registration email, or forgetting of password will be automated to reduce manual intervention.

The system will also automatically assign tickets to improve workflow. All tickets from a reporting entity will be assigned to the individual who is the relationship manager for that entity. Tickets from LEAs will also be similarly divided up after consultation with FID-Bhutan.

Additionally, once a ticket is acted upon, it will be marked as resolved, so as to avoid repetition of work. The user will also be allowed to save replies to common questions. In case a question is asked frequently, the user can save a response and insert it as a reply when necessary.

8.4 REPORT MONITORING

There will be 5 different responses that will be monitored and evaluated. These responses and their associated timelines can be found in Annexure 6.

The responses and their associated timelines will be monitored by the system. In case of consistent non-adherence to timelines by REs, FID-Bhutan may choose to take action at their own discretion.

8.5 ANALYTICS MODULES FOR FID-BHUTAN

The solution proposed by the bidder can include analytics modules beyond those in Section 5.3.3.

Some of the modules that the solution can include are detailed below.

8.5.1 Typologies of Money Laundering

The system should enable study and assessment of typologies of money laundering. Typologies of money laundering should be analysed and tracked to measure and assess any changes. Example: the frequency of a certain typology should be tracked.

8.5.2 External Data Integration

With external data integration, the bidder will integrate external databases in the system and enable functionality like fuzzy and phonetic matching.

Direct matching shall be used when there is a common ID, registration number etc. Fuzzy and phonetic matching shall be used when distinct IDs cannot be used to identify a match.



8.6 VALUE ADDED SERVICE PROPOSED BY BIDDER

The solution proposed by the bidder can also include any functionality not detailed in the RFP. The bidder will be evaluated favourably for innovation and provision of value added services at no additional cost.



9 EXPERTISE REQUIRED

This section details firm and expert qualifications and the minimum onsite deployment.

9.1 FIRM QUALIFICATION

The IT bidding firm must meet the following qualification criteria –

1. As on date of submission of the bid, the bidder should not be involved in any conflict of interest situation

2. A consulting firm or individual consultant sanctioned or temporarily suspended by ADB in accordance with ADB’s Anticorruption Policy(1998, as amended to date) and Integrity Principles and Guidelines (2015, as amended from time to time) shall be ineligible to participate in or be awarded an ADB-administered contract or to benefit from an ADB-administered contract, financially or otherwise, during the period determined by ADB

3. Both individual firms and consortiums can qualify for this engagement

9.2 TEAM COMPOSITION AND EXPERT QUALIFICATION

The consulting firm must have at the least the following key experts with respective qualifications –

Resources Key Activities Qualifications

Project Manager

Drive meetings and interactions with external stakeholders

Oversee the project team and the performance closely

Manage exit management and transition activities

Manage the project operations, timeliness, and quality of deliverables submitted

Provide timely intervention in case of issues requiring support

Overall experience of at least 5 years including IT system implementation and operations

Experience in leading the development of web-based applications (at least 3 projects)

Experience in leading analytics driven projects (at least 2 projects)

Experience in countries in similar geographic area

Experience with AML/CFT systems will be preferred

Data Integration Expert

Develop ETL process and rule engine for analysis

Automate processes of data exchange and case analysis

Perform historical processing of data

Overall experience at least 3 years spanning data integration, ETL, data standardization, data integration and similar domains

Experience of working as an ETL developer (at least 2 projects)

Web Developer

Develop and maintain web portal for multiple stakeholders

Conduct unit and integration testing

Develop uploading, downloading, user

Overall experience of at least 3 years spanning across IT system implementation, development of web applications etc.

Experience in projects involving development of web-based systems (at least 2 projects)

Experience of development of systems involving integration with multiple systems/data sources (at least 1 projects)

https://www.adb.org/sites/default/files/institutional-document/31317/anticorruption-integrity-policy-strategy.pdf

https://www.adb.org/sites/default/files/institutional-document/32131/integrity-principles-guidelines.pdf

https://www.adb.org/sites/default/files/institutional-document/32131/integrity-principles-guidelines.pdf



Resources Key Activities Qualifications

registration etc. functionality

Data Visualization Expert

Develop and present dashboards using visualization tools

Overall experience of at least 4 years spanning data visualization, data warehousing and business intelligence, dashboard creation etc.

Experience of working on projects involving visualization and reporting (at least 2 projects)

Analytics Expert

Develop analytics models like clustering, classification etc. for analysis

Overall experience spanning analytics projects, web applications, visualizations and similar domains for at least 3 years

Experience in data analytics projects (in at least 2 projects)

Figure 7: Required Resources

9.3 DELIVERY MODEL

1) For the purpose of this engagement a hybrid delivery model will be followed, whereby system development will occur both onsite and offsite

2) It is expected that the key personnel will be intermittently deployed during the engagement

3) During the user acceptance test, all required resources will be deployed onsite

4) During the maintenance track, onsite deployment will be required when requested by FID-Bhutan, with a maximum of seven onsite man days per month.

5) The minimum number of onsite deployment for the project manager, spread across on-boarding, UAT and go-live is 7 days.

6) The minimum number of onsite deployment for other resources, spread across UAT, go live and exit management is 9 person days



10 PROJECT IMPLEMENTATION AND

TIMELINES

This section outlines the project plan and timelines for this project. It details a series of activities that shall be required, including design and development of the systems, transition, providing support etc.

Given the scope of the project, the key solution components and the system that has to be designed, the following model has been selected as the most suitable for the project implementation:

1) The design and development of the application, besides the delivery of services, are part of the scope for the vendor for a period of 3 months with 3 month maintenance period.

2) There shall be a total of 2 tracks:

a. Track 1 or the IT implementation track: here, the vendor shall design and develop the system, perform historical processing of data and ensure go-live of system

b. Track 2 or the support track: here, the vendor will provide maintenance for a period of 3 months and perform exit management activities including knowledge transfer and handover of all documents

3) A phase module based approach has been selected, and each track shall consist of different modules. The modules shall include all tasks relating to a particular category. E.g. development of RE module shall include the design of all specifications and functionalities relating to REs. This approach shall ensure that activities occur in parallel and there is sufficient time for testing.

4) The implementation track of the project will be managed by through a dedicated unit established for the purpose. The role of this unit shall be to monitor the performance of the vendor, ensure compliance with service level metrics and regularly monitor outputs.

5) The support track of the project will be managed by FID-Bhutan

6) The overall implementation of the new system has been envisaged to be for 3 months followed by a maintenance period for 3 months. The beginning of the maintenance track shall include the exit of the vendor and transition of FID-Bhutan as the operating entity of the system.

7) As detailed in Section 9.3, a hybrid delivery model will be utilized for this engagement.

8) During the user acceptance testing, all resources will be deployed onsite, to ensure that system requirements are in line with the RFP and stakeholder needs are met

Assuming T to be a time in calendar when the new vendor is on-boarded at FID-Bhutan (specifically the day of issuance of the notice to proceed), the project implementation can be summarized in the following table –

Phase/Milestone From To Key activities

On-boarding T T+7 days

The vendor shall be on boarded

Kick-off meeting with all stakeholders

Submission of Deliverable 1: Approach Document



Phase/Milestone From To Key activities

Development of System

T T+ 90 days

The vendor will develop the system as per requirements and timelines

Submission of Deliverable 2: Design Document

Submission of Deliverable 3: Monthly Quality Assurance Report

Testing of System

At the end every week, starting at T+14 days

Unit and integration testing shall be performed as the system develops to ensure alignment

Historical Processing of Data

T+80 days T+87 days Historical processing of all CTRs/ STRs etc.

User Acceptance Testing

T+80 days T+ 87 days

A round of user acceptance testing shall be performed which will test the system as a whole with FID-Bhutan certifying that the requirements have been met

Vendor will make changes to the system, if required and submit reports if required by FID-Bhutan

Go-live T+90 days T+90 days

Go-live shall mean that from this point onwards the new system shall be live and perform all activities as per the requirements of this RFP.

Maintenance T+90 days T+180 days

The vendor shall submit maintenance reports to FID-Bhutan, every month

The vendor will perform maintenance duties as required

Exit Management

T+170 days T+180 days The vendor shall handover all documents and

final deliverables, scripts etc.

End of contract After T + 180 days The contract and warranty period shall come

to an end

Figure 8: Timelines

Note: Timelines have been defined in calendar days



11 PROJECT DELIVERABLES

The vendor has to deliver the following deliverables to FID-Bhutan as part of an assurance to fulfil the obligations under the requirements of this RFP. The timelines for producing each of these deliverables will be in line and closely linked with the overall project timeline as indicated in Section 10 of the RFP. Any conflict with respect to project and/or deliverable timelines will have to be resolved by the vendor in consultation and approval of FID-Bhutan. The approved timelines will have to be adhered to by vendor, unless specified otherwise.

S No. Track Deliverable Contents

1. Project Initiation Project plan and project charter

Detailed project plan

Resource deployment plan

List of key resources

Updated CVs for all resources to be deployed

Knowledge management plan

Communication plan

Project status reporting

RAID (Risk, Assumptions, Issues and Dependencies) log including risk management and mitigation approach

Exit and transition management

2. System Development

Architecture and design

Business architecture

Solution architecture

Enterprise architecture

Process flows

HLD Document

LLD Document

SRS

3. Quality Assurance Testing

Testing Documents

Test approach, test plans, test cases, test scripts, test data and rest results

Type of inputs (functional, performance, stress, acceptance, structural)

Test coverage and boundary conditions

Test assumptions

Exact test stimuli

Response time/ execution time / throughput reports



S No. Track Deliverable Contents

Plan for addressing issues identified during testing

4. User acceptance test and Go-Live

User acceptance cases and results

User acceptance test cases

User acceptance sign off

5. Go-live Go live manual Manual for go-live of all applications

6. Maintenance Maintenance manuals and reports

Maintenance manuals and documentation

MIS reports including but not limited to the following variables

o Response time

o Resolution time

o Re-opened tickets

o RCA (Root cause analysis) report

o Known error database report

Figure 9: List of project deliverables

1. The deliverables mentioned above are indicative and may not be exhaustive with respect to the scope of work of the vendor as envisaged under this RFP. The vendor shall provide all necessary deliverables to FID-Bhutan as may be required for the smooth functioning of the project at no extra cost.

2. The vendor shall update all design documents every fortnight or otherwise as agreed upon with FID-Bhutan.



12 DELIVERABLES AND PAYMENT SCHEDULE

S No

Key Activities/ Milestones Timeline/Frequency Payment

1 Submission of Project Initiation Document

T+ 7 days 10%

2 Acceptance of Design Document (HLD)

T + 30 days 20%

3 Acceptance of SRS T+45 days 5%

4 Submission of Monthly Quality Assurance Report

Within 7 working days from the last day of every month

15% (3 x 5)

5 Acceptance of Design Document (LLD)

T+ 60 days 20%

6 Historical processing of data T+87 days 5%

7 Go live and acceptance of system T+ 90 days 25%

Total 100%

Figure 10: Payment Terms

Note: timelines have been defined in calendar days



13 TECHNICAL EVALUATION CRITERIA

This project will follow ADB guidelines and processes for bid evaluation. Given that it is a fixed

budget selection, only the technical proposal will be evaluated.

The table below details the evaluation criteria for the technical proposal. The maximum score

awarded will be of 1000

S.No Criteria Maximum Additional

Marks Provided

1 Approach and Methodology 300

1.1 Quality of Approach and Work Plan 260

1.1.1 Proposed Solution 150

1.1.2 Work Plan 10

1.1.3 Value Add 100

1.2 Personnel Schedule 10

1.3 Proposal Presentation 30

2 Personnel (as listed in RFP) 700

2.1 Project Manager 180

2.2 Data Integration Expert 130

2.3 Web Developer 130

2.4 Data Visualization Expert 130

2.5 Analytics Expert 130

Figure 11: Advanced Services Package Evaluation



14 ANNEXURE 1: ADDITIONAL

STAKEHOLDER DETAILS

14.1 ORGANIZATION STRUCTURE OF FID-BHUTAN

Figure 12: Organizational Structure of FID-Bhutan

14.2 FUNCTIONS OF FID-BHUTAN

Policy formulation functions spanning –

Drafting and issuing new regulations, guidelines and directives

Facilitating and drafting agreements with international FIUs to facilitate exchange of intelligence. FID- Bhutan has signed Memorandums of Understanding (MoUs) with multiple countries, including India, Sri Lanka, Cambodia, Bangladesh, South Korea and Myanmar.

Facilitating domestic and international cooperation through coordination of meetings with relevant stakeholders, arranging of international exchange programs for transfer of learning, arranging evaluations and assessments with internationally recognized regulatory bodies etc.

Developing and managing information analysis systems

Performing advanced AML/CFT planning to guide the country’s efforts

Information Analysis functions involving –

Gathering all reports from REs and other stakeholders

Gathering additional information from REs, for the purpose of analysis or as reactive information requested by LEAs

Conducting operational and strategic analysis on the data submitted by REs to identify relevant cases



Sharing and disseminating intelligence reports and analysis relating to money laundering or terrorism financing to LEAs

Compliance and regulatory functions including –

Providing training on ML/TF issues to all stakeholders in the FID ecosystem

Educating all stakeholders on AML/CFT initiatives, compliance guidelines, best practices and regulations

Publishing annual reports detailing the activities that have been conducted and key trends and patterns of money laundering in Bhutan.

14.3 INDICATIVE REPORTING VOLUMES AND HISTORICAL DATA

S. No Parameter Number

1 Indicative volume of STRs filed in 2018 10-15/year

2 Range for indicative volume of CTRs filed by Banks

1,000-5,500/quarter

3 Range for indicative transaction volume of Banks

1,984-50,000/day

4 Range for indicative volume of CTRs filed by Insurance firms

1-90/quarter

5 Count of historical STRs 25+

6 Count of historical CTRs 500,000

Figure 13: Indicative Reporting Volumes

14.4 OVERVIEW OF LEAS

Today, there are five LEAs in Bhutan. These include –

Anti-Corruption Commission: The Anti-Corruption Commission (ACC) was established in January 2006 to promote awareness of anti-corruption, develop preventive measures, and investigate cases of corruption. In the last few years, ACC has undergone a technology-led transformation moving from an offline manual investigation to integrated online databases. On average, ACC registers 30-45 cases annually, and has access to more resources and capabilities owing to the criticality of their daily functions. ACC is a notified LEA for FID-Bhutan and is a key stakeholder in this project.

Department of Revenue and Customs: The Revenue Intelligence Department (RID), under the Department of Revenue and Customs (DRC) is responsible for all financial investigation in the Ministry of Finance. FID Bhutan disseminates all cases relating to DRC to RID for investigation. The RID was established in April, 2018 and is currently still in the emerging stages of developing their own system and processes for investigation. Currently, investigation is primarily offline and technical support is sought from other LEAs, and governmental bodies. DRC is a key stakeholder in the FID ecosystem, and investigates AML/CFT cases regarding tax evasion, fraud etc.

Bhutan Narcotics Control Authority: Bhutan Narcotics Control Authority (BNCA) was established in 2006 and is a regulatory and monitoring body that does not have investigative capabilities. Their mission is to control and combat the abuse and trafficking of drugs and other



controlled substances. BNCA depends on the Royal Bhutan Police for support in investigation and is also a member of the Technical Committee. BNCA is a key stakeholder in the FID ecosystem, and investigates AML/CFT cases regarding drug trafficking and other related crimes.

Royal Bhutan Police: The Royal Bhutan Police (RBP) is the entity responsible for maintaining law and order in Bhutan. RBP have the power to arrest, investigate, prosecute, search and seize, summon witnesses and regulate public assembly. Within the FID ecosystem RBP provides investigative support to other LEAs. The data they request includes bank statements, bank account details and transaction related data from reporting entities.

Office of Attorney General: The Office of Attorney General (OAG) is the prosecution arm, and legal advisor of the Bhutan Government. In addition, they also function as a representative in the judicial system of Bhutan. Their objective is to provide legal services and facilitate access to law. Since the OAG is the prosecution arm, it is not involved in any investigation of cases. OAG’s role in the FID environment is to verify and file the cases received from the other LEAs, and request supporting documents if necessary.



15 ANNEXURE 2: INDICATIVE REGISTRATION

FORMS

15.1 REGISTRATION FOR NEW USER GROUP

Name of Field Description

Registered name of user group Name as per Registrar of Companies (RoC) record

Registered number of user group As per RoC record

Category of user group As defined by FID-Bhutan

Registered Address of user group The registered address as per records

Name of primary user Name as per official records

Citizenship Identity Card For identity verification

Role Any one of the pre-defined roles by FID-Bhutan

Figure 14: Registration Process for Business Entity

15.2 REGISTRATION FOR NEW USER

Name of Field Description

Name of user Name as per official records

Citizenship Identity Card For identity verification

Role Any one of the pre-defined roles by FID-Bhutan

Figure 15: Registration Process for an Individual



16 ANNEXURE 3: INDICATIVE

NOTIFICATIONS AND ALERTS

The following table details the indicative types of notifications that each entity and its users will receive, which shall be finalized with FID-Bhutan:

Name of Entity

Type of Notifications

REs

The notifications received include but are not limited to:

1) Reactive reporting request

2) Request for additional information

3) Submission of all outgoing reports

4) Status of all submitted reports

5) Upcoming CTR deadline

6) Compliance assessment

7) Upcoming scheduled assessment

8) Presence of inactive user account

9) User account has been deactivated

10) User profile updates

11) Successful password change

FID-Bhutan


1) Incoming reports from REs

2) Incoming requests from LEAs

3) Upcoming deadline for reactive reporting requests

4) Submission of all outgoing reports

5) LEA report acceptance/rejection

6) LEA report rejection reason

7) Status of all reports and requests

8) Incoming watch list data

9) Compliance assessment check

10) Deviation from user behaviours

11) Incoming feedback response from LEAs

12) Relationship link identified

13) User profile updates



Name of Entity

Type of Notifications

14) Successful password change

15) Account is activated

16) Account is deactivated

17) Incoming watch list data

18) New user registration email sent

19) New user registered

LEAs


1) Report successfully accepted

2) Report successfully rejected

3) Watch list submitted

4) Upcoming watch list update due

5) New incoming case

6) Submission of reactive request reports

7) Submission of additional information requests

8) Submission of feedback for FID-Bhutan

9) Status of all requests

10) Incoming reactive reporting and data information

11) Upcoming Committee meeting

Figure 16: Notifications and Alerts



17 ANNEXURE 4: INDICATIVE FEEDBACK

FORMS

17.1 FEEDBACK FROM LEAS TO FID

This section details the indicative feedback from LEA to FID-Bhutan

Figure 17: Feedback from LEA

Questions Response options

Name of LEA

Anti-Corruption Commission

Bhutan Narcotics Control Authority

Office of Attorney General

Department of Revenue and Customs

Royal Bhutan Police

Case Number Mandatory

Reason for Rejection Mandatory (if applicable); Drop Down List

(with other and text field as an option)

Was this information useful Rating on a scale of 1-5, 5 being most useful;

Drop Down List

Was additional information requested

Yes

No

If yes, what was the nature of the information

Transaction details

KYC details

Summary account details

Other

If other, please specify



18 ANNEXURE 5: INDICATIVE STATUS CODES

18.1 REPORT SUBMISSION

The following details the indicative status codes for REs submitting reports to FID-Bhutan, to be finalized in consultation with FID-Bhutan:

Status code Description

Submitted Once the RE user generates a request, the status assigned is submitted

Recall If the RE user recalls the data due to incomplete/incorrect information

Rejected- Failed validation If erroneous data is submitted and report is rejected by FID Bhutan

Resubmitted When a recalled report is resubmitted by an RE

Accepted Once FID-Bhutan receives and accepts, the status should be changed to ‘accepted.

Figure 18: Status Code for REs

18.2 REACTIVE REQUESTS SENT TO RES

The following indicative status codes shall be displayed when the reactive information requested is not within FID-Bhutan:

Status Code Description

Submitted Once the LEA user generates a request, the status assigned is submitted

Initiated Once FID-Bhutan receives the request and informs the RE, the status should be changed to ‘Initiated’.

Response sent by RE Once the RE responds to the request, the status shall be changed to ‘Response sent by RE’

Response under review When the RE response is under review by FID-Bhutan, the status shall be changed to ‘Response under review’

Response sent When the RE response is sent by FID-Bhutan, the status shall be changed to ‘Response sent’

Closed

After receipt of the response, the user shall be notified to close the request if they are satisfied with the response. The status shall then be changed to ‘Closed’. The envisaged system shall issue reminders to the LEA user to close the request in pre-defined intervals once the status changes to ‘Response sent’. The LEA user shall also be provided an option to reopen the request in case they are not satisfied with the response received.



Figure 19: Status Code Reactive Information with RE

18.3 REACTIVE REQUESTS SENT TO FID-BHUTAN

The following details the process when the reactive information requested is within FID-Bhutan- in this case the information requested by the LEAs is already in the FID-Bhutan system and can be disseminated directly. The following table details the indicative status codes that shall be displayed when FID-Bhutan has the data, to be finalized in consultation with FID-Bhutan

Status code Description

Submitted Once the LEA user generates a request, the status assigned is submitted

Initiated FID-Bhutan receives the request and initiates preparation of response

Reactive request sent FID-Bhutan sends the file to the corresponding LEA

Received Confirmed receipt of the file by the LEA

Figure 20: Status Code Reactive Information with RE



19 ANNEXURE 6: INDICATIVE TIMELINES

FOR REPORT MONITORING

The following details indicative timelines for report monitoring the same is to be finalized in consultation with FID-Bhutan:

1) Timeline for REs for submitting reports:

Report Type Timeline Alerts

Cash Transaction Reports Monthly Alert will be issued 3 days before deadline

Suspicious Transaction Reports

Two days after identification

N/A

Counterfeit Currency Monthly Alert will be issued 3 days before deadline

Figure 21: Timeline for Reporting for REs

2) Timeline for REs providing additional information (for reactive reporting or analysis purposes):

Priority Rating Timeline Alerts

High 3 days Alert will be issued 24 hours before submission is due

Medium 5 days Alert will be issued 48 hours before submission is due

Low 7 days Alert will be issued 48 hours before submission is due

Figure 22: Timeline for Reactive Information from REs

3) Timeline for FID-Bhutan responding to reactive reporting requests

Priority Rating Data

Availability Timeline Alerts

High

Yes

1 working day

Alert will be issued when reactive report request is submitted

No Same working day

Alert will be issued when reactive report request is submitted

Medium

Yes 3 working days Alert will be issued 24 hours before submission is due

No 2 working days Alert will be issued 8 hours before submission is due.



Priority Rating Data

Availability Timeline Alerts

Low

Yes 5 working days Alert will be issued 48 hours before submission is due

No 3 working days Alert will be issued 24 hours before submission is due

Figure 23: Timeline for Reactive Information from FID-Bhutan

4) Timeline for FID-Bhutan to disseminate cases to LEAs:

Priority Rating

Timeline Comments Alerts

High 1 day

Individual/entity shall be high priority if they are watch listed by an LEA

Alert will be issued 24 hours before submission is due

Medium 4 days

Individual/entity shall be high priority if they are watch listed by FID-Bhutan


Low 7 days

All other cases shall be submitted one week after STR is submitted to FID-Bhutan


Figure 24: Timeline for case submission

5) Timeline for FID-Bhutan to disseminate data to RMA departments:

Report Type Timeline Alerts

Transaction Data 2 days after incoming reports

Alert will be issued 24 hours before submission

Figure 25: Timeline for dissemination to RMA departments



20 ANNEXURE 7- EXISTING HARDWARE

The existing stack comprises of –

1) Intel Xeon MP E7310 (1.6 GHz, 4 MB Cache, 1066 MHz FSB Quad core processor),

2) Intel 7300 chipset, 6 PCI/PCI Express

3) 8GB 667 MHz DDR2 FBD RAM upgradable up to 128 GB

4) 3X140 GB or more 10000 rpm SAS Hot Plug

5) Memory 16 GB

6) Disk Space 500 GB



21 ANNEXURE 8- TEMPLATE FOR

HARDWARE REQUIREMENTS FOR OARS

Product category Name of the Product

Proposed Version, Make and

Model Number of units



22 ANNEXURE 9: TEMPLATE FOR AMC COST

S. No. Original

equipment manufacturer

Product name Software AMC (USD)