CBI Vendor RFP 01102014 -Advanced Approaches

REQUEST FOR PROPOSAL (RFP)

For Procurement, Installation and Implementation of

Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management

Systems for Advanced Approaches under RBI/Basel‐II/Basel‐III Guidelines

RFP Reference: CO:RMD:BASEL:2014-15:509

Date: October 1, 2014

This document is the property of Central Bank of India. It may not be copied, distributed or recorded on

any medium, electronic or otherwise, without written permission thereof. The use of the contents of this

document, even by the authorized personnel/ agencies for any purpose other than the purpose specified

herein, is strictly prohibited and shall amount to copyright violation and thus, shall be punishable under

the Indian Law.

REQUEST FOR PROPOSAL (RFP) for Implementation of Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management Systems for Advanced Approach under RBI/ Basel II/Basel III Guidelines -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

2

Definitions of major terms / abbreviations used in the document:

Sr. No. Acronym/ Terms Used Definition

1. AMA Advanced Measurement Approach

2. Bank Central Bank of India

3. Basel II Framework for Capital Measurement and Capital Standards issued by Basel Committee on Banking Supervision (BCBS)

Working Paper No. 14 Studies on the Validation of Internal Rating Systems issued by Basel Committee on Banking Supervision in May 2005 (http://www.bis.org/publ/bcbs_wp14.pdf)

4. Basel III A global regulatory framework for more resilient banks and

banking systems and International framework for liquidity risk

measurement, standard and monitoring

5. Basel II RBI Guidelines Master Circular ‐ Prudential Guidelines on Capital Adequacy and Market Discipline‐ New Capital Adequacy Framework (NCAF)

Implementation of The Standardized Approach (TSA) for Calculation of Capital Charge for Operational Risk

Implementation of the Advanced Measurement Approach (AMA) for Calculation of Capital Charge for Operational Risk ‐ Guidelines

Capital Adequacy ‐ The Internal Ratings Based (IRB) Approach to Calculate Capital Requirement for Credit Risk

Prudential Guidelines on Capital Adequacy‐ Implementation of Internal Models Approach for Market Risk

6. Basel III RBI Guidelines Implementation of Basel III Capital Regulations in India

Guidelines on Liquidity Risk Management and Basel III Framework on Liquidity Standards

7. CO Commercial Offer/ Commercial Bid/ Price Bid

8. CRMS Credit Risk Management System

9. FGMO Field General Manager’s Office

10. Bancs24 Core Banking Application software used in bank

11. IMA Internal Model Approach

12. IPR Intellectual Property Right

13. IT Information Technology


3

Sr. No. Acronym/ Terms Used Definition

14. e-Treasury Software Solution for Treasury operations

15. KRI Key Risk Indicators

16. MIS Management Information System

17. NAS Network Attached Storage

15. NCAF New Capital Adequacy Framework

16. OEM Original Equipment Manufacturer – Product Vendor

17. ORMS Operational Risk Management System

18. RBI Reserve Bank of India

19. RCSA Risk and Controls Self-assessment

20. RFP Request for Proposal

21. RO Regional Office

22. TO Technical Offer

23. TSA The Standardized Approach

24. SLA Service level Agreement

25. NDA Non-disclosure Agreement


4

Contents 1. Introduction ............................................................................................................................................ 12

1.1 Overview: about the Bank .................................................................................................................. 12

1.2 Broad Scope of Work .......................................................................................................................... 13

1.2.1 Implementation .............................................................................................................................. 17

1.2.2 Facilities Management (FMS) and Helpdesk .................................................................................. 18

1.2.3 Integrations of existing system ....................................................................................................... 18

1.2.4 Information Security ....................................................................................................................... 19

1.3 Invitation for Bids ................................................................................................................................ 19

1.3.1 Disclaimer ....................................................................................................................................... 19

2. Instructions for Bid Submission .............................................................................................................. 21

2.1 General Instructions ........................................................................................................................... 21

2.1.1 Cost of Application/ Bid Document ................................................................................................ 21

2.1.2 Bid Security (E.M.D) ........................................................................................................................ 21

2.1.3 Registration of RFP Response ......................................................................................................... 22

2.1.4 Request for Additional Information ................................................................................................ 22

2.1.5 Pre‐Bid Meeting .............................................................................................................................. 23

2.1.6 Disqualification ............................................................................................................................... 23

2.1.7 Language of Bid ............................................................................................................................... 23

2.1.8 Period of Validity of Bids ................................................................................................................. 23

2.1.9 Amendment of Bidding Documents ............................................................................................... 23

2.1.10 Authorization to Bid ........................................................................................................................ 24

2.2 Documents Comprising the Bid .......................................................................................................... 25

2.3.1 Documents constituting the Bid ..................................................................................................... 25

2.3 Commercial Evaluation Process .......................................................................................................... 26

2.3.1 Key Guidelines ................................................................................................................................ 27

2.3.2 List of Documents ........................................................................................................................... 28

2.3.3 Sealing and Marking of Bids ............................................................................................................ 29

3. Additional Instructions for Bidders ......................................................................................................... 30

3.1 General Instructions ........................................................................................................................... 30


5

3.1.1 Nature of Bid ................................................................................................................................... 30

3.1.2 Source Code .................................................................................................................................... 30

3.1.3 Information Ownership .................................................................................................................. 31

3.1.4 Security Configuration, Monitoring and Audit ............................................................................... 31

3.1.5 Considerations for Proposed Hardware & Software to support the CRM System ......................... 32

3.1.6 Performance Guidelines ................................................................................................................. 34

3.1.7 Performance Security ..................................................................................................................... 35

3.1.8 SLA .................................................................................................................................................. 36

3.1.9 Liquidated Damages ....................................................................................................................... 38

3.2 Payment Terms ................................................................................................................................... 38

3.2.1 For Operational Risk & Credit Risk Management System .............................................................. 41

3.2.2 For Hardware, other Infrastructure components and Operating Systems .................................... 42

3.2.3 Environmental Software except RDBMS ........................................................................................ 42

3.2.4 Implementation Cost ...................................................................................................................... 43

3.2.5 Price Composition ........................................................................................................................... 43

3.2.6 Additional Training Cost .................................................................................................................. 44

3.2.7 Road Permit .................................................................................................................................... 44

3.2.8 Right to Alter Quantities ................................................................................................................. 44

3.2.9 Payment Term for Facilities Management ..................................................................................... 44

3.3 Warranty & Annual Maintenance ....................................................................................................... 44

3.3.1 Maintenance Standard during Warranty & Post Warranty Maintenance) .................................... 44

3.3.2 Termination .................................................................................................................................... 45

4. Evaluation Methodology ......................................................................................................................... 50

4.1 Opening of Bids by the Bank ............................................................................................................... 50

4.1.1. Normalization of Bids...................................................................................................................... 50

4.1.2. Opening of Technical Bids ............................................................................................................... 51

4.1.3. Committee for Bid Evaluation......................................................................................................... 51

4.1.4. Opening of Commercial Bids .......................................................................................................... 52

4.1.5. Determination of Successful Bidder and Awarding of Contract ..................................................... 52

4.2 Eligibility Criteria ................................................................................................................................. 52

4.3 Evaluation Criteria .............................................................................................................................. 54


6

4.3.1 Preliminary RFP Examination .......................................................................................................... 54

4.3.2 Technical Bid Evaluation Criteria .................................................................................................... 55

4.3.3 Disqualification Parameters in Technical Bid Evaluation ................................................................ 57

4.3.4 Functional & Technical Evaluation Criteria ..................................................................................... 58

4.3.4.1 For Operational Risk solution ......................................................................................................... 58

4.3.4.2 For Credit Risk Management Solution ............................................................................................ 61

4.3.5 Short listing of Technically Qualified Bidders ................................................................................. 64

4.3.6 Commercial Evaluation Process ...................................................................................................... 66

4.3.7 Evaluation Criteria ‐ Overall ............................................................................................................ 67

5. Other Terms & Conditions ...................................................................................................................... 68

5.1 Indemnity ............................................................................................................................................ 68

5.2 Penalty ................................................................................................................................................ 70

5.3 Insurance ............................................................................................................................................ 71

5.4 Inspection & Tests............................................................................................................................... 71

5.5 Warranty ............................................................................................................................................. 71

5.6 Delivery of servers – period ................................................................................................................ 71

5.7 AMC price Validity .............................................................................................................................. 71

5.8 Duty free Credit Scrips ........................................................................................................................ 72

5.9 Vendor’s liability ................................................................................................................................. 72

5.10 Change Management .......................................................................................................................... 72

5.11 Product Version .................................................................................................................................. 72

5.12 Independent Contractor: .................................................................................................................... 72

5.13 Escrow Mechanism ............................................................................................................................. 73

5.14 Confidentiality ..................................................................................................................................... 73

5.15 Intellectual property rights ................................................................................................................. 76

5.16 Violation of terms ............................................................................................................................... 77

5.17 Statutory and Regulatory Requirements ............................................................................................ 77

5.18 Visitorial Rights ................................................................................................................................... 77

5.19 Technological advancements.............................................................................................................. 77

5.20 Taxes ................................................................................................................................................... 78

5.21 Survival ................................................................................................................................................ 79


7

5.22 Inspection, Audit & Visitations ........................................................................................................... 79

5.23 Change Request .................................................................................................................................. 80

5.24 Compliance with Laws ........................................................................................................................ 80

5.25 Assignment ......................................................................................................................................... 80

5.26 Publicity .............................................................................................................................................. 81

6. Scope of Work for Operational Risk Management ................................................................................. 82

6.1 Scope for Implementation of Operational Risk Management Solution ............................................. 84

6.2 Functional Requirements for Operational Risk Management Solution............................................ 103

6.3 Technical Requirements for Operational Risk Management Solution ............................................. 126

6.3.1 Additional Questions .................................................................................................................... 131

6.3.2 Hardware Requirements ............................................................................................................... 132

6.3.3 Training Requirements ................................................................................................................. 133

6.3.4 Project Management Methodology ............................................................................................. 135

7. Scope for Credit Risk Management Solution ........................................................................................ 138

7.1 Scope for Implementation of Credit Risk Management Solution ..................................................... 140

7.2 Functional Requirements for Credit Risk Management Solution ..................................................... 160

7.3 Technical Requirements for Credit Risk Management Solution ....................................................... 184

7.3.1 Additional Questions .................................................................................................................... 190

7.3.2 Hardware Requirements ............................................................................................................... 190



8. Integrated Capital Computation & Reporting Module ......................................................................... 196

8.1 Key Components ............................................................................................................................... 196

8.2 Details to be provided by the Bidder ................................................................................................ 196

9. Annexure ............................................................................................................................................... 197

9.1 Undertaking from Bidder .................................................................................................................. 197

9.2 Eligibility Criteria Format .................................................................................................................. 198

9.3 Cover Letter for Technical Bid .......................................................................................................... 200

9.4 Technical Bid Format ........................................................................................................................ 202

9.4.1 Functional Requirement Checklist – Operational Risk Management ........................................... 202

9.4.2 Technology Requirements Checklist – Operational Risk Management ........................................ 238


8

9.4.3 Hardware Requirements ‐ Operational Risk Management .......................................................... 247

9.4.4 Functional Requirement Checklist – Credit Risk Management .................................................... 248

9.4.5 Technology Requirements Checklist – Credit Risk Management ................................................. 286

9.4.6 Hardware Requirements ‐ Credit Risk Management .................................................................... 295

9.4.7 Hardware & Infrastructure Configurations for the Proposed Solution (both for CRM & ORM) . 297



9.5 Additional Details ‐ for both Credit Risk and Operational Risk Solutions ......................................... 311

9.6 Cover Letter for Commercial Bid ...................................................................................................... 313

9.7 Commercial Bid (Bill of Material) Format ......................................................................................... 315

9.7.1 Part I – Commercial Bid Format – CRM & ORM Solution (Amount in INR Lakhs) ........................ 315

9.7.2 Part I – Commercial Bid Format – CRM & ORM Solution (Masked) ............................................. 322

9.8 Bid Offer Covering Letter .................................................................................................................. 325

9.9 Reference Site Details ....................................................................................................................... 327

9.10 Particulars of Bidder ......................................................................................................................... 328

9.10.1 Profile of Bidder ............................................................................................................................ 328

9.10.2 Financial Position of Bidder for last 3 financial years (in Rs. Crores) ............................................ 328

9.11 Past Experience Details ..................................................................................................................... 330

9.11.1 Implementation in India ............................................................................................................... 330

9.11.1 Implementation Outside India ...................................................................................................... 330

9.12 Bank Guarantee for EMD & Performance Bank Guarantee Format ................................................. 331

9.12.1 Bank Guarantee for EMD .............................................................................................................. 331

9.12.2 Performance Bank Guarantee Format .......................................................................................... 333

9.13 Manufacturers’ / Producers’/ Authorization Form........................................................................... 336

9.14 Implementation Team Profile ........................................................................................................... 337

9.14.1 Vendor Implementation Capability .............................................................................................. 337

9.14.2 Team Profile .................................................................................................................................. 338

9.15 Important Project Timelines ............................................................................................................. 339

9.16 List of Existing Applications............................................................................................................... 340

9.17 List of Existing Applications from where Credit Risk Input data may be integrated ........................ 343

9.18 CONFORMITY LETTER........................................................................................................................ 344


9

9.19 Architecture ...................................................................................................................................... 346

9.20 Hardware for SAS Solution at DC ...................................................................................................... 347

9.21 Non-disclosure Agreement ............................................................................................................... 350

REQUEST FOR PROPOSAL (RFP) for Implementation of Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management Systems for Advanced Approach under RBI/ Basel II/Basel III Guidelines

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

10

Bid Details ‐ for implementation of Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management System for Advanced Approach under RBI/Basel II / Basel III Guidelines

Date of commencement of RFP

CO:RMD:BASEL:2014-15:509 01/10/014

Last date of submitting queries to the

RFP

10/10/2014 by 4:00PM

Date and time for pre‐bid meeting

15/10/2014 3.00 PM

Date and time for putting

clarifications on website

17/10/2014 4.00 PM

Last date and time for Receipt of

RFP Response

31/10/2014 up to 3.00 PM

Date and Time of Technical Bid

Opening

31 /10/2014 at 3.30 PM

Place of submission and opening of Bids

The General Manager, Central Bank of India, Risk Management Department, 1st Floor, Bajaj Bhavan, Nariman Point, Mumbai – 400 021

Address for communication

As above

Tel: +91-22-66387635 Email : [email protected]

Application Money Rs. 5,000/‐ (Rs. Five thousand only) to be paid at the time

of bid submission (if not purchased) in the form of

Demand Draft or Banker’s Cheque in favor of Central

Bank of India payable at Mumbai.

mailto:[email protected]


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

11

Bid security

Rs.25,00,000/- (Rs. Twenty five lacs only) in the form of

Demand Draft in favour of Central Bank of India,

Central Office payable at Mumbai or Bank Guarantee of

equivalent amount as Bid security. The Bid security

should be enclosed with Technical Bid.

Contact to Bidders

Interested Bidders are requested to send the email to

[email protected] and copy to

[email protected]

Containing following information, so that in case of any

clarification same may be issued to them: Name of company, contact person, Mailing address with

Pin Code, Telephone No., Fax No., email address, Mobile No.

etc.

Introduction Note:

1. In case of RFP document downloaded from the website, fees must be deposited along with the

RFP response.

2. Any offer without payment of RFP fee will not be considered.

3. The Bank reserves the right to change the dates mentioned above or in the RFP, which will be

communicated on the Bank’s web‐site.

4. RFP Response should be received by the officials indicated not later than 3.00PM PM IST on

31.10.2014 at Risk Management Department, Central Bank of India, Risk Management Department,

1st Floor, Bajaj Bhavan, Nariman Point, Mumbai – 400 021 as per the details given in the above

table, as mentioned in section 2.2 (Document comprising the bid).

5. The RFP document will be available on the Bank’s web‐site www.centralbankofindia.co.in



http://www.centralbankofindia.co.in/


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

12

1. Introduction

1.1 Overview: about the Bank

Central Bank of India, herein after referred to as the “Bank” - established in 1911, was nationalized in the

year 1969 and today is a leading public sector bank listed in BSE/NSE.

The organizational structure of The Bank consists of four tiers viz., Central Office (CO), Zonal Offices (ZO),

Regional Offices (RO) and Branches. The Bank has a network of 4500 plus branches, spread across the length

and breadth of the country with presence in all the States and Union Territories. The Bank has also

established its Wide Area Network at 4500 plus locations all over India covering administrative and branch

offices. As on the date, bank does not have any non-network branch.

The Bank also has specialized branches catering to the specific needs of Retail Customers, Industrial Units,

Corporate Clients, Forex Dealers, Exporters and Importers, Small Scale Industries and Agricultural sector. The

Bank has sponsorship in 3 Regional Rural Banks (RRB).

Bank has implemented Core Banking Solution B@ncs24 from Tata Consultancy Services Limited in all the

branches. Bank is using BaNCS Treasury Version 5.1 for treasury operations.

Risk Management in the post financial crisis has become a significant function in the banks across the

world. In the context of ongoing changes in financial landscape banks are required to be ever

more nimble and at the same time ensure that all the risks are managed or mitigated effectively.

Central Bank of India (hereon referred to as ‘Bank’) views the current market dynamics and resulting

regulatory requirements as an opportunity to create an integrated risk management framework that will

create shareholder value by aligning the Bank’s business strategy to its risk management policies,

processes and systems. Over a period of time, Central Bank of India has taken various initiatives for

strengthening risk management practices. Bank has an integrated approach for management of risk and in

tune with this, formulated policy documents taking into account the business requirements / best

international practices or as per the guidelines of the national supervisor. These policies address the

different risk classes viz., Credit Risk, Market Risk and Operational Risk.

Over the years, CENTRAL BANK OF INDIA has earned the reputation of being technology savvy and one of

the frontrunner among public sector banks in modern‐day banking trends. Having launched its Core

Banking Solution in 2005, CENTRAL BANK OF INDIA has all their branches on a single Core Banking

platform. Under this solution umbrella, all branches and ATMs of CENTRAL BANK OF INDIA have been

networked, with online Tele banking, net banking and mobile banking facility made available to both

its Core Banking Customers – individual as well as corporate. Regular banking services apart, the

customer can also avail of a variety of other value‐added services like Cash Management Service,

Insurance, Mutual Funds and Demat.

CENTRAL BANK OF INDIA has a strong network of over 4500 plus branches, 12 Field General Manager’s Offices, 80 Regional Offices and two foreign Representative Offices


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

13

1.2 Broad Scope of Work

Operational Risk, which is intrinsic to the bank in all its material products, activities, processes and

systems, is emerging as an important component of the enterprise‐wide risk management system.

Recognizing the importance of Operational Risk Management (ORM), the Bank has adopted a

Comprehensive Operational Risk Management Policy. This would entail the bank to move towards

enhanced level of sophistication in the years ahead and to capture qualitative and quantitative measure of

Operational Risk indicators in management of operational risk.

Credit Risk Management is an important part of bank’s operation. This would help the bank in keeping a

check on the asset quality at appraisal level as well as on an ongoing basis.

The Bank has a comprehensive system of internal controls, systems and procedures to monitor and

mitigate risk. The Bank has also institutionalized new product approval process to identify the risk

inherent in the new product and activities. The Bank has carried out a comprehensive Self‐Assessment

exercise spanning all the risk areas and evolved a road map to move towards implementation of

Basel II guidelines as per RBI’s guidelines. The program of Risk Management, Organizational Structure, Risk

measures, risk data compilation and reporting has been getting implemented for a period of time in the

Bank.

RBI has also indicated a tentative timeframe for banks to apply to RBI seeking permission to migrate to

advanced approaches of Capital Computation for all Risk areas (credit, market and operational risk). The

Bank has been in the process of enhancing its Risk Management practices and believes that aligning such

activities with the strategic aim of migration to advanced approaches would help achieve long term

benefits.

CENTRAL BANK OF INDIA has currently adopted the Basic Indicator Approach for Operational Risk

Regulatory Capital Calculation. Further the Bank has taken initiatives to progress towards adopting

advanced approaches. To achieve this objective, the Bank has planned to implement an Operational Risk

Management Solution (ORMS). CENTRAL BANK OF INDIA is also gearing up its risk management process

for migrating to next advanced approaches Basel II operational risk approach‐ Advanced Management

Approach (AMA)

For Market risk, CENTRAL BANK OF INDIA has already purchased SAS solution integrated with Treasury

system which is under implementation.

Currently bank plans to move to advanced approaches for its India Operations. However, system capabilities

i.e. functional and technical are from group consolidation perspective, in case, bank may decide to move to

advanced approaches for its group operations in future.

Bank has SAS solution which it has implemented for Credit Risk Management which is based on the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

14

Standardized approach as per the current status. The Bank now intends to adopt IRB and AIRB methods. At

present, Bank has license for SAS standardized approach. At present, there is no DR for standardized

approach.

The Bank has already taken steps in these directions and this RFP is intended to invite Techno‐Commercial

bids from eligible Bidders to provide end‐to‐end solution for implementation of Operational Risk

Management system in consonance with advanced approaches as per the Basel‐II RBI Guidelines, Credit Risk

Management System based on IRB and AIRB approaches again based on Basel II and RBI guidelines and

integration with existing system working in market risk area to have an integrated risk management frame

work.

Finally selected bidder based on this RFP terms and conditions should supply, install and commission a

comprehensive Operational Risk Management and Credit Risk Management Solutions and integrate

with existing market risk solutions to have an integrated risk frame work for the Bank. It should be

implemented at all branches and subsidiaries as decided by the Bank.

The solution offered should be web based, ‘Three Tier Architecture’, open platform and support data

transfer and consolidation both from the networked and standalone system either online or dial up. The

process should be automated with facility to schedule transfer of data. The solution should be scalable

and capable to handle increased volumes. It must support both centralized and hybrid deployment.

Use of Oracle as RDBMS is mandatory as Bank has procured ORCALE ULA. Since bank has procured ORACLE

ULA, the required number of licenses will be provided by Bank. However vender has to mention the number

of licenses for the project and will be responsible for installation & maintenance during the project period.

The Bidder will have to provide the necessary interface to all the applications as required. Hardware to host

this would be provided by the vendor.

The complete list of Bank’s existing applications is detailed later in Section 9.16: List of Existing

Applications of this document.

By means of diagrammatic / pictorial representations, the Bidder should provide complete details of the

hardware, software and network architecture of the Operational and Credit Risk Management System

for Advanced Approaches under Basel II (module and sub‐module wise), including source / method of data

capture and transfer, validation, updation and database maintenance for networked and non‐networked

branches. The proposed solution should cover all the existing branches/units/administrative offices as

decided by the Bank and have the capability to scale up for meeting future requirements.

Total time period for the project is 12 months (for both credit and operational risk implementation). Vendor

will have to complete project implementation including sample roll-out, training and documentation till

production migration within 12 months. Vendor will have to give a detailed project plan divided into

activities with dependency and those which can be done in parallel. Project period of 12 months will be


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

15

counted from the date of singing of the agreement with the vendor.

The solution will be implemented in all the branches/Administrative offices as decided by the Bank. The

Bidder should assist for implementation in 50 branches/units /administrative offices spread across the

country (along with all the Regional Offices and Corporate Office) on pilot basis. The Bidder should install

and commission the solution and integrate with the Bank’s applications at other foreign branches and

subsidiaries.

The system should be implemented in all the remaining units after its satisfactory working in 50 branches /

units / administrative offices and implementation in all the units should be completed within 12 months

signing of contract.

Final sign‐off will be given only after successful implementation of the project at Bank wide level.

Details of Implementation, Functional and Technical Requirements are provided in Section 6, Section 7 & Section 8: Implementation, Functional Requirements & Technical Requirements of this document.

The names of the CBS branches of the Bank are available on the Bank’s website.

The Bidder should provide hardware systems, operating system, ORMS (Operational Risk Management

System) application software, CRMS (Credit Risk Management System) application software and other

necessary software & hardware required for the successful implementation of the proposed solution

including DR site of equal capacity as live including data replication requirements (at the end

of day) along with data replication solution and a required Test server (Application & Database

Server). Network security is available at the Bank end however Bidder has to ensure all related security

controls under the scope of RFP. The Bidder has to ensure that vulnerabilities at application level in case

of any breach shall be handled by the offered application software.

Provision, implementation and maintenance of the replication link between DC & DR is out of scope of the

SI. Syncing between the servers at two locations is part of RFP.

Bank is looking for 100% replica of DC at DR. However the Test, Development & UAT will be at DC only.

Vendor should provide separate physical server for Database, Web Server & Application Server may be on

one physical server. However vendor should follow industry best practices. The proposed solution should

meet all the SLA requirements as per RFP document.

The bidder should propose the infrastructure which meets the SLA requirements of the RFP. Router and

firewall is in place. Switches & allied components need to be factored in the proposal.

The Bidder has to upgrade servers / storage at no extra cost to the Bank, in case the offered configuration

does not meet the requirements, for 7 years from the implementation start‐date.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

16

The data size expected in next 7 years is 12 TB for both credit risk and operational risk applications. The

total storage provided by the Bidder over the five year period should be a minimum usable space of 1 2

TB in RAID 5. The Bidder may propose a SAN (Storage Area Network) to meet the requirements. The

proposed hardware at the data center must be in active‐passive cluster with external SAN storage with

back up tape library and support RAID 0 to 5 with no single point of failure.

The data size expected in next 7 years is 12 TB for both credit Risk and Operational risk applications.

However it is the responsibility of the bidder to ensure that the utilization of the offered infrastructure in

terms of Hard disk utilization of 60% should not be exceeded. During the contract period of 7 years, if the

offered data size increases beyond 60%, necessary upgrade of hard disk and allied components needs to be

provided to the Bank at no extra cost.

A complete Bill of Material for the hardware required for the successful running of the solution should

also be provided by the Bidder, with full particulars like make, model, part numbers, proposed

configuration, including all details like memory type proposed with future expandability, processor

type, number of processors, processor speed, future expandability, bus speed, etc. and clearly show no

single point of failure. Please refer Section 9.7: Commercial Bid (Bill of Material) Format

The Bidder should specify the hardware requirement taking into consideration of efficiency level, response

time, data processing requirement, number of users, and all other parameters to ensure that the

efficiency of software system is not affected because of hardware. Bidder is to provide details for DR site –

Network and security requirements, switches, routers etc. The Bidder will certify that the hardware

specified is adequate for meeting performance standards set by the Bank, and it takes full responsibility of

upgrading hardware without any extra cost to the Bank, if at the time of implementation or any time

subsequently it is found that the hardware specified requires upgrade. At any point in time during the

contract period, the CPU utilization should neither exceed 70% nor should the Hard Disk utilization exceed

60% at the Primary Data Centre. In case the hard disk utilization exceeds 60%, the additional hardware has

to be provided by the Bidder at no further cost.

Switches, cabling CAT6 and allied network components are inclusive in RFP.

The Bidder must ensure no hardware equipment or software, for which ‘End‐of‐ Sale’ has been declared,

is offered as part of this RFP. None of the hardware or software should have an ‘End‐of‐Support’

mandated by the respective OEM within seven years from date of initial successful commissioning of

system.

The Bidder should also provide the Bank with the number of racks required for the servers / equipment

and associated infrastructure, as well as power requirements (average, peak and rated power) and

any other requirements for the servers / equipment (Network and security requirements, switches,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

17

routers etc.) and associated infrastructure for both DC (data center) & DR (Disaster Recovery) sites.

The cost of power cabling and passive cabling will be borne by the system integrator. WAN implementation,

set-up and maintenance at all the bank locations is out of the scope of the vendor.

Sizing of equipment, hardware etc. as required, depending on the functionalities required by the bank as

mentioned in the RFP, should be provided by the Bidders for processing of existing portfolio of the

Banks/Group with increase in volumes at approx. 20% p.a. and addition of new products / instruments

and data maintenance during the contractual period

Mailing solution & AV are out of scope.

The Bidder has to provide all related tools under the scope of RFP and No open source tool is acceptable as

per Security Policy of the Bank.

DC is at Navi Mumbai and DRC is at Hyderabad. The testing and development environment will be at Bank's

premises at Data Centre Belapur, Navi Mumbai.

The Bank proposes that system should have multiple sign-on capabilities in future which need to be

integrated during the 7 year contract, which should be factored in TCO.

The application is not expected to be accessed through handheld devices and mobile browsers.

Test environment may be logical replica of production environment and vendor to ensure that all conditions

of the solution are tested.

1.2.1 Implementation

1. The Bidder should implement an enterprise version of Operational and Credit Risk Management

System as per RBI / Basel II / Basel III Guidelines for Advanced Approaches at the Central Processing

Center (CPC), Head Office, all Zones / Regions, domestic and foreign branches and demonstrate their

capability (at least one on site demonstration).

2. Integration with existing Market Risk Solution. Vendor will be required to build interface with Bank’s

other source systems based on the requirement.

3. The Bidder is to give an undertaking to implement the solution at any location / branch identified

by Bank.

4. As part of implementation all data migration (as and when required) from the existing systems will be

done by the vendor.

5. Vendor will also support parallel run of the existing systems (as and when required) since both

standardized as well advanced approaches need to be run concurrently till RBI allows to switch over to

advanced approach with no additional cost. Support is required from the date of acceptance of PO.

Support required for hardware, software, application and FM and the support will be back-ended by the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

18

respective OEM and proof for the same should be submitted to the Bank.

All the open tickets will be resolved between bank and current SI. Bank will discuss the current SLA and transition agreement with the successful bidder. Bank will facilitate the knowledge transfer process (for existing systems both application and hardware). Any cost for the same needs to be borne by successful bidder. The vendor should have a well-documented BCP and Disaster Recovery Plan and also security and control practices.

1.2.2 Facilities Management (FMS) and Helpdesk

The Bidder is required to provide Helpdesk services till the completion of the implementation across all

administrative offices/units/branches. Facility Management services will be provided by the bidder till the

end of the project. The bidder is required to indicate the resource requirements for FMS in the Bill of

Material

1. Facilities Management: Facilities Management would include support for all hardware, application

software, etc. which would be provided by the Bidder. Bidder should elaborate on FMS like

number of resources required post implementation a lo n g w it h d et a i l s l i k e no . o f y e ar s ’

e x pe r i e nc e e t c . and mention it accordingly in Bill of Material. FMS services should be

provided for entire project duration. Support personnel should be technically qualified and

experienced in the same field / application. Facilities Management services should include Daily

maintenance and DBA activities. Onsite support during bank’s working hour on all business days

excluding Sunday / Holidays with exception as per Bank's requirement /exigencies on time to time.

FMS includes Hardware as well Software. FMS has to be on site on bank’s location. New solution will be

deployed on new hardware only

2. Helpdesk: Helpdesk refers to availability of resources to record and respond to events and incidents

related to the application, hardware & software implemented as per the scope of this RFP. Helpdesk

services should be only provided till implementation.

No helpdesk tool available at present and Post implementation all the H/W, application support would

be covered under Facility Management

1.2.3 Integrations of existing system

All integrations, integration development with understanding of existing Core Banking Solution B@ncs24 and

other application system running in the Bank will be the responsibility of the bidder. In addition,

understanding / integration of ALL the existing source systems as mentioned in Annexure 9.16 for which cost


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

19

if any, charged by any OEM/SI of these systems for understanding of the system will be borne by the bidder

and will be part of offered TCO”. No charges will be borne by the Bank for this activity.

1.2.4 Information Security

System should have standard input, communication, processing and output validations and controls. System

hardening should be done by vendor. Access controls at DB, OS, and Application levels should be ensured.

Vendor should comply with the Information Security Policy of the Bank. The Product offered should comply

with regulator’s guidelines.

The vendor shall disclose security breaches if any to the Bank, without any delay.

1.3 Invitation for Bids

CENTRAL BANK OF INDIA invites Request for Proposal (RFP) for a turnkey project for implementation of

Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management System for

advanced approaches under RBI/BASEL‐II/ BASEL‐III guidelines and integrate with existing Market Risk

Solution. The broad scope of the project envisages installation, customization, configuration,

parameterization, implementation, validation of models and processes & maintenance of application

software, system software, database, interfaces etc. as well as supply, installation & maintenance of related

hardware at primary and disaster recovery data centers of the Bank, with training to Bank’s designated

personnel.

Each Bidder should notify the Bank of any error, fault, omission, or discrepancy found in this RFP document

but not later than the date as specified in this RFP. The responses to the queries will be put on the website

after committee’s approval

The Bidders will, by responding to the Bank’s RFP document, be deemed to have accepted all the terms as

stated in this RFP document.

1.3.1 Disclaimer

The information contained in this Request for Proposal (RFP) document for implementation of

Operational and Credit Risk Management System for Advanced Approach under Basel II or information

provided subsequently to Bidder(s) or applicants whether verbally or in documentary form by or on

behalf of CENTRAL BANK OF INDIA, is provided to the Bidder(s) on the terms and conditions set out in this

RFP document and all other terms and conditions subject to which such information is provided. The RFP

document contains statements derived from information that is believed to be true and reliable at the

date obtained but does not purport to provide all of the information that may be necessary or desirable

to enable an intending contracting party to determine whether or not to enter into a contract or

arrangement with Bank in relation to the provision of services.

The RFP document is not a recommendation, offer or invitation to enter into a contract, agreement or any


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

20

other arrangement, in respect of the services. The provision of the services is subject to observance

of selection process and appropriate documentation being agreed between the Bank and any successful

Bidder as identified by the Bank, after completion of the selection process as detailed in this document. No

contractual obligation whatsoever shall arise from the RFP process unless and until a formal contract is

signed and executed by duly authorized officers of Central Bank of India with the Bidder. The purpose of this

RFP is to provide the Bidder(s) with information to assist the formulation of their proposals. This RFP does

not claim to contain all the information each Bidder may require. Each Bidder should conduct their own

investigations and analysis and should check the accuracy, reliability and completeness of the information in

this RFP and where necessary obtain independent advice.

CENTRAL BANK OF INDIA makes no representation or warranty and shall incur no liability under any law,

statute, rules or regulations as to the accuracy, reliability or completeness of this RFP. CENTRAL BANK OF

INDIA may in its absolute discretion, but without being under any obligation to do so, update, amend or

supplement the information in this RFP.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

21

2. Instructions for Bid Submission

2.1 General Instructions

2.1.1 Cost of Application/ Bid Document

Application Money of Rs. 5,000/‐ (Rupees five Thousand only) by way of Demand Draft/ Pay Order

favoring Central Bank of India, payable in Mumbai, which is non‐refundable, must be submitted

separately along with RFP response. The Bank may, at its discretion, reject any Bidder where the

application money has not been furnished with the RFP response. The RFP documents can be

downloaded from Bank’s Website and Govt. Web site. The cost of RFP should be deposited at the time of

submitting the responses.

All costs and expenses (whether in terms of time or material or money) incurred by the Recipient/Bidder in

anyway associated with the development, preparation and submission of responses, including but not

limited to attendance at meetings, discussions, demonstrations, etc. and providing any additional

information required by the Bank, will be borne entirely and exclusively by the Bidder.

2.1.2 Bid Security (E.M.D)

1. The Bidder shall furnish, as part of its Bid, a Bid security in the format as mentioned in Section

9.12.1: Bank Guarantee for EMD.

2. The Bid security is required to protect the Bank against the risk of Bidder’s conduct, which would

warrant the security’s forfeiture.

3. The Bid security shall be denominated in Indian Rupees and shall be one of the following forms:

a. Bank guarantee for Rs. 2 5 , 00 ,00 0/ - issued by a Schedule commercia l Bank (other

than Central Bank of India), acceptable to the Bank, as per format provided in the Section

9.12.1: Bank Guarantee for EMD, valid for One Hundred Eighty (180) days beyond the validity of

the Bid.

OR

a) Banker’s Cheque / Demand Draft, issued by Schedule commercial Bank, drawn in favor of

Central Bank of India payable at Mumbai and valid for a period of 90 days for a sum of Rs.

25,00,000/-

4. Any Bid not secured as detailed in above, will be rejected by the Bank, as non‐responsive. 5. Unsuccessful Bidders’ Bid security will be discharged or returned as promptly as possible. 6. The successful Bidder’s Bid security will be discharged upon the Bidder signing the Contract and

furnishing the performance security as per the format mentioned in Section 9.12.2: Bank Guarantee for EMD.

7. Bank reserves the right to forfeit the Bid security for the following reasons: a. If a Bidder withdraws its Bid during the period of Bid validity specified by the Bidder on the Bid

Form; or b. If a Bidder makes any statement or encloses any form which turns out to be false / incorrect at

any time prior to signing of Contract; or

c. In the case of a successful Bidder, if the Bidder fails:‐


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

22

i. To sign the Contract; OR ii. To furnish Performance Security as mentioned in Section 3.1.7: Performance Security

herein.

iii. To sign SLA based on RFP and subsequent addendum there on

2.1.3 Registration of RFP Response

Registration of RFP response will be done by the Bank by making an entry in a separate register kept for

the purpose upon Bank receiving the RFP response in the above manner. The registration must contain all

documents, information, and details required by this RFP. The submission should be in the format

outlined in this RFP and should be submitted only through hand delivery. If the submission to this RFP does

not include all the documents and information required or is incomplete or submission is through Fax

mode, the RFP is liable to be summarily rejected. All submissions, including any accompanying

documents, will become the property of Bank. The Recipient shall be deemed to have licensed, and granted

all rights to the Bank to reproduce the whole or any portion of their submission for the purpose of

evaluation, to disclose the contents of the submission to other Recipients who have registered a

submission and to disclose and/or use the contents of the submission as the basis for any resulting RFP

process, notwithstanding any copyright or other intellectual property right of the Recipient that may

subsist in the submission or accompanying documents.

RFP responses will remain valid and open for evaluation for a period of at least six (6) months from the RFP closing date.

2.1.4 Request for Additional Information

Recipients/ Bidders are required to direct all communications for any clarification related to this RFP, to the

designated Bank officials and must communicate the same in writing up to the date and time as

specified in this RFP. All queries relating to the RFP, technical or otherwise, must be in writing only. The

Bank will try to reply, without any obligation in respect thereof, every reasonable query raised by the

Recipients in the manner specified.

However, the Bank will not answer any communication reaching the bank later than 16.00 hours IST on

10.10.2014 before the pre‐bid meeting date this being the last date to receive clarifications.

The Bank may in its absolute discretion seek, but under no obligation to seek, additional information or

material from any Bidders after the RFP closes and all such information and material provided must be

taken to form part of that Bidder’s response. Bidders should invariably provide details of their email

addresses as responses to queries will be provided to all Bidders via email.

The Bank may in its sole and absolute discretion engage in discussion with any Bidder (or simultaneously

with more than one Bidder) after the RFP closes to clarify any response.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

23

2.1.5 Pre‐Bid Meeting

The Bank plans to hold a pre‐bid meeting on 15.10.2014 at 3.00 p.m. at the address specified in Bid

details under introduction note to bring utmost clarity on the scope of work and terms of the RFP being

floated. The Bidders are expected to use the platform to have all their queries answered.

Interested Bidders will be allowed to participate in the Pre‐Bid meeting. Also, bank will allow a maximum

of 2 representatives from each Bidder (including consortium partners) to participate in the pre‐bid

meeting.

Bidders are requested to send their queries relating to RFP to our office by email, well in advance (latest by

10.10.2014 up to 04.00 p.m.), so that the same could be discussed during the Pre‐Bid meeting with

interested Bidders.

Non‐attendance at the Pre‐bid Meeting will not be a cause for disqualification of a Bidder.

The Bank will have liberty to invite its technical consultant or any outside agency, wherever necessary, to be

present in the pre‐bid meeting to reply to the technical queries of the Bidders in the meeting.

2.1.6 Disqualification

Any form of canvassing/ lobbying/ influence/ query regarding short listing, status etc. will result in a

disqualification.

2.1.7 Language of Bid

The language of the bid response and any communication with the Bank must be in written English only.

Supporting documents provided with the RFP response can be in another language so long as it is

accompanied by an attested translation in English, in which case, for purpose of evaluation of the

bids, the English translation will govern.

2.1.8 Period of Validity of Bids

Bids should remain valid for the period of at least six (6) months from the last date for submission of bid

prescribed by the Bank. A bid valid for a shorter period shall be rejected by the Bank as non‐responsive. In

case the last date of submission of bids is extended, the Bidder shall ensure that validity of bid is

reckoned from modified date for submission.

2.1.9 Amendment of Bidding Documents

At least 7 days’ time prior to the last date for bid‐submission, the Bank may, for any reason, whether at its

own initiative or in response to clarification(s) sought from the prospective Bidders, modify the RFP


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

24

Contents / covenants by amendment. Clarification / amendment, if any, will be notified on Bank’s website.

No individual communication would be made in this respect.

2.1.10 Authorization to Bid

The proposal / bid being submitted would be binding on the Bidder. As such, it is necessary that

authorized personnel of the firm or organization sign the bid documents. The designated personnel should

be authorized by a senior official of the organization having authority.

1. All pages of the bid, shall be initialed by the person or persons signing the bid

2. Bid form shall be signed in full & official seal affixed.

3. Any inter‐lineation, erasure or overwriting shall be valid only if they are initialed by the person or

persons signing the Bid.

4. All such initials shall be supported by a rubber stamp impression of the Bidder’s firm.

The proposal must be accompanied with an undertaking letter duly signed by the designated personnel

providing a bid commitment. The letter should also indicate the complete name and designation of the

designated personnel.

In case the principal Bidder authorizes his business partners / authorize

distributors to bid on his behalf, a separate authorization letter as per format enclosed (Section 9.13:

Manufacturers’/ Producers’/ Authorization Form), with a commitment to fulfill the terms of the RFP

should be submitted. Necessary resolutions/authority available should be enclosed.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

25

2.2 Documents Comprising the Bid

2.3.1 Documents constituting the Bid

The Bidder has also to submit 2 copies of the response and a soft copy of the complete technical Bid in

Microsoft Office / Open Office/PDF format on a Compact Disc (CD) super‐scribing “Soft Copy of Technical

Bid against RFP– CENTRAL BANK OF INDIA/RMD/2014‐15/dated 01 Oct., 2014” along with the technical bid.

The Bidder will not furnish the softcopy of the commercial bid.

The Bid prepared by the Bidder should comprise the following three components viz. Eligibility,

Technical, Commercial:

1. ENVELOPE – I: Eligibility Criteria:

Separate envelopes with superscriptions as “Eligibility Criteria” should be included within the overall

Envelope. The Bidder should submit the following:

a) The sheet mentioning compliance / non‐compliance to all the eligibility criteria

specifications with remarks and other requirements given in Section 9.2: Eligibility Criteria

Format.

b) All the proofs required for eligibility criteria as mentioned in Section 9.2: Eligibility Criteria

Format

2. ENVELOPE – II: Technical Bid:

Bid Document cost and Bid Security: Separate envelopes with superscriptions as “Bid Document Cost and

Bid Security” should be included within the overall Envelope. The Bidder should submit the following:

a) Cost of Application / Bid Document

b) Bid Security (Earnest Money Deposit) and

c) Technical Bid

Technical Bid: Separate envelopes with superscriptions as “Technical Bid and Masked Commercial Bid”

should be included within the Envelope II.

a) Technical Bid b) Masked Commercial Bid

The Bidder should submit compliance / non‐compliance to all the specifications with remarks and other

requirements given in the Bid Document and Scope of Work. Submission of non-compliance should not be

construed as accepted to the bank, unless bank specifically notifies it in writing.

The Technical Bid should be complete in all respects and contain all information asked for, except

commercial prices. The Technical Bid should include all items asked for in bid document. The technical offer

should not contain any price information. The Technical Offer should be complete and indicate that all

products and services asked for are quoted. For example, the Technical Bid should mention that AMC


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

26

charges etc. are included in the Commercial Bid, without mentioning the actual amounts in the Technical Bid

and terms of Payment, Delivery and any other conditions, which may appear in the Commercial Bid.

The Bidder should enclose a copy of the Masked Commercial Bid (as per the format provided in section

9.7.2) as per price schedule without the prices (please put ‘X’ mark wherever prices are quoted) along with

other bid documents for evaluation purpose.

3. ENVELOPE – III: Commercial Bid:

The Commercial Bid should give all relevant price information and should not contradict the Technical Offer

in any manner. Please note that if any envelope is found to contain both technical and commercial bid

together, that bid will be rejected summarily

The details required in the Annexure shall also be enclosed. The Bank may reject any proposal not containing

all the requirements called for in various Annexure.

The Technical Bid of the eligible Bidders will be opened first for evaluation. Final bidder would be decided

by Techno – Commercial Evaluation

Prices quoted by the Bidder shall be fixed during the Bidder’s performance of the Contract and shall not be

subject to variation on any account, including exchange rate fluctuations, changes in taxes, duties, levies,

charges etc. A Bid submitted with an adjustable price quotation will be treated as nonresponsive and will

be rejected.

2.3 Commercial Evaluation Process

1. The technically qualified bidder will participate in the Commercial Evaluation process

2. For finalization of the most competitive offer, the Bank will calculate Relative Commercial Score (RCS)

for the Technically Qualified Bidders. A bidder will be qualified for commercial evaluation as per criteria

given in Section 4.3.5 of this document.

3. All costs proposed by the Bidder will have to be rational. In case of any irrational costs, the

Bank reserves the right to disqualify the Bidder from further consideration.

4. Details of total costs provided will have to be in line with the itemized costs.

5. In case of a Tie between two or more Bidders for Final Evaluation Score (FES), the Bid with higher

Relative Technical Score would be chosen at the discretion of the Bank.

6. The Highest Technical bidder shall not automatically qualify for becoming selected bidder and for award

of contract by the bank.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

27

7. The Lowest Commercial Bidder shall not automatically qualify for becoming selected Bidder and for

award of contract by the Bank.

8. The Bank shall not incur any liability to the affected Bidder on account of such rejection.

9. The Bidder whose technical & commercial Bid is accepted will be referred to as “Selected Bidder” and the

Bank will notify the same to the Selected Bidder.

10. The final decision on the vendor will be taken by Central Bank of India. The implementation of the

project will commence upon successful negotiation of a contract between Central Bank of India and

the selected bidder based on the Techno – Commercial evaluation.

2.3.1 Key Guidelines

1. Bidder’s proposal should strictly conform to the specifications.

2. Proposals not conforming to the specifications will be rejected subject to the Bank’s discretion. Any

incomplete or ambiguous terms / conditions / quotes may result in disqualification of the offer at bank’s

discretion. The Bidder has to offer specific remarks for technical requirements and clearly confirm

compliance. Any deviations on technical requirements should be clearly informed in Remarks column.

3. Deviation / comments on other terms prescribed by the Bank are to be provided in a separate

section in Technical Bid. The Bank is not bound to evaluate the deviations mentioned at any other

section of the bid.

4. For supplementary information a separate sheet should be used.

5. All pages should be numbered (like 1/xxx, 2/xxx where xxx is last page number of Bid document) and

signed under the company seal.

6. Technical Bid documents are to be properly filed in a box‐ file.

7. Central Bank of India reserves the right to reject any or all proposals. Similarly, it reserves the right not to

include any vendor in the final short‐list.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

28

2.3.2 List of Documents

Envelope Documents Reference

ENVELOPE – I:

Eligibility Criteria

Eligibility Criteria Section 9.2: Eligibility Criteria

ENVELOPE – II: Technical

Bid

Cost of Application/ Bid

Document

Section 2.1.1: Cost of Application/ Bid Document

Bid Security (Earnest Money

Deposit)

Section 2.1.2: Bid Security

(E.M.D)

Technical Bid

Undertaking from

Bidder

Section 9.1: Undertaking from Bidder

Bid Offer Covering

Letter

Section 9.8: Bid Offer Covering Letter

Cover Letter for

Technical Offer

Section 9.3: Cover Letter for

Technical Bid

Technical Bid Format Section 9.4: Technical Bid Format

Reference Site Details Section 9.9: Reference Site

Details

Particulars of Bidder Section 9.10: Particulars of

Bidder

Past Experience

Details

Section 9.11: Past Experience

Details

Manufacturers’/

Producers’/

Section 9.13: Manufacturers’/

Producers’/


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

29

Envelope Documents Reference

Authorization Form Authorization Form

Implementation Team

Profile

Section 9.14: Implementation Team

Profile

Project Timelines Section 9.15: Important

Project Timelines

Masked Commercial

Bid

Section 9.7.2: Commercial

Bid (Bill of Material) Format

ENVELOPE – III:

Commercial Bid

Commercial Bid

Cover Letter for

Commercial Bid

Section 9.6: Cover Letter for

Commercial Bid

Commercial Bid (Bill of

Material) Format

Section 9.7.1: Commercial

Bid (Bill of Material) Format

2.3.3 Sealing and Marking of Bids

1. The Bidder has to submit 2 copies of the response and a soft copy of the complete technical Bid

in Microsoft Office / Open Office format on a Compact Disc (CD) super‐scribing “Soft

Copy of Technical Bid against RFP– CENTRAL BANK OF INDIA/RMD/2014‐15/

dated 01 Oct. 2014” along with the technical bid. The Bidder will not furnish the softcopy of the

commercial bid.

2. The Bidder shall seal the envelopes containing “Envelope – I: Eligibility Criteria”, “Envelope – II:

Technical Bid” and “Envelope – III: Commercial Bid” separately and the three envelopes shall be

enclosed and sealed in a SINGLE OUTER ENVELOPE marked as “ORIGINAL: Implementation of

I n t e g r a t e d Risk M a n a g e m e n t S o l u t i o n : Specifically Operational and Credit Risk

Management System for Advanced Approach under RBI/Basel II /Basel III Guidelines‐FINAL BID”

3. The inner and outer envelopes shall:

a) be addressed to the Bank at the address given; and

b) bear the following in separate envelopes

i. “Implementation of Integrated Risk Management Solution: Specifically Operational and Credit Risk Management System for Advanced Approach under RBI/Basel II /Basel


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

30

III –Eligibility Criteria”

ii. “Implementation of Integrated Risk Management Solution: Specifically Operational and Credit Risk Management System for Advanced Approach under RBI/Basel II /Basel III – Non‐Price Bid (Technical Bid)”,

iii. “Implementation of Integrated Risk Management Solution: Specifically Operational and Credit Risk Management System for Advanced Approach under RBI/Basel II /Basel III – Price Bid (Commercial Bid)”,

c) All envelopes should indicate on the cover the name and address of the Bidder.

4. If the outer envelope is not sealed and marked, the Bank will assume no responsibility for the

bid’s misplacement or premature opening.

3. Additional Instructions for Bidders

3.1 General Instructions

3.1.1 Nature of Bid

a) Bids will be permitted only from a single entity.

b) Consortium bidding is not allowed.

3.1.2 Source Code

a) Bidder to agree to keep source code of proposed solution with approved / recognized escrow agency under escrow arrangements mutually acceptable to the bank and Bidder but at Bidder’s cost for entire project period.

b) The application software should mitigate Application Security Risks, at a minimum, those discussed in OWASP top 10 (Open Web Application Security Project)

c) The Bank has right to Audit the Application / Source Code by suitable Security Auditor.

d) The Bidder shall provide complete and legal documentation of all subsystems, licensed operating systems, licensed system software, and licensed utility software and other licensed software. The Bidder shall also provide licensed software for all software products whether developed by it or acquired from others. The Bidder shall also indemnify the Bank against any levies / penalties on account of any default in this regard.

e) In case the Bidder is coming with software which is not its proprietary software, then the Bidder must submit evidence in the form of agreement it has entered into with the software vendor which includes support from the software vendor for the proposed software for the full period required


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

31

by the Bank.

The bidder will be making changes to OEM Source Code based on the requirements of the Bank. The source

code of accepted signed off software by the Bank needs to be kept in the escrow arrangement to be entered

as tripartite agreement as per Section 5.1.13 of the RFP.

3.1.3 Information Ownership

All information processed, stored, or transmitted by successful Bidder equipment belongs to the Bank. By

having the responsibility to maintain the equipment, the Bidder does not acquire implicit access rights

to the information or rights to redistribute the information. The Bidder understands that civil, criminal,

or administrative penalties may apply for failure to protect information

appropriately, which is proved to have caused due to reasons solely attributable to bidder.

Any information considered sensitive by the bank must be protected by the successful Bidder from

unauthorized disclosure, modification or access. The bank’s decision will be final.

Types of sensitive information that will be found on Bank system’s which the Bidder plans to support

or have access to include, but are not limited to: Information subject to special statutory

protection, legal actions, disciplinary actions, complaints, IT security, pending cases, civil and criminal

investigations, etc.

The successful Bidder shall not publish or disclose in any manner, without the Bank’s prior written

consent, the details of any security safeguards designed, developed, or implemented by the Bidder or

existing at any of the Bank location. The Bidder will have to develop procedures and implementation plans

to ensure that IT resources leaving the control of the assigned user (such as being reassigned,

removed for repair, replaced, or upgraded) are cleared of all Bank data and sensitive application

software. The Bidder will have to also ensure that all subcontractors who are involved in providing such

security safeguards or part of it shall not publish or disclose in any manner, without the Bank’s prior

written consent, the details of any security safeguards designed, developed, or implemented

by the Bidder or existing at any Bank location.

3.1.4 Security Configuration, Monitoring and Audit

The baseline security configuration of Operating System, Database, Web server and all other applications

to be done by the bidder, according to the industry best practices

Compliance with security best practices may be monitored by periodic computer security audits performed

by or on behalf of the Bank. The periodicity of these audits will be decided at the discretion of the Bank.

Periodicity for Regulatory Audits would be required as per the rules and guidelines laid down by

the regulator or as required by the regulator. These audit plan to include, but are not limited to, a review

of: access and authorization procedures, physical security controls, input/output controls, DB controls,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

32

backup and recovery procedures, Network security controls and program change controls.

To the extent that the Bank deems it necessary to carry out a program of inspection and audit to

safeguard against threats and hazards to the confidentiality, integrity, and availability of data, the

Bidder shall afford the Bank’s representatives access to the Bidder’s facilities, installations, technical

resources, operations, documentation, records, databases and personnel. The Bidder must provide the Bank

access to various monitoring and performance measurement systems (both manual and automated). The

Bank has the right to get the monitoring and performance measurement systems (both manual and

automated) audited without prior approval / notice to the Bidder.

Audit shall be conducted within bidder business hours. Further, 15 days prior notice shall be given to

conduct audit.

3.1.5 Considerations for Proposed Hardware & Software to support the CRM System

1. Bank will provide Oracle as RDBMS as Bank has already acquired Oracle ULA. All other software should be of the latest version

2. The Bidder should provide the data sheets for all the hardware proposed.

3. Roadmap for the CPUs proposed for Database and Application servers should be presented.

4. All servers shall be configured with two numbers sufficient storage capacity of Internal Disk Drive with Mirroring and tape/ Digital Audio Tape (DAT) drives

5. The servers proposed should have 64‐bit Quad‐core processor and latest operating system like UNIX Operating System. The offered OS should be the Enterprise version of the 64 bit and should be the latest version.

6. All database servers should be of same capacity and models.

7. Application and Database Servers should be vertically scalable (‘in box’ upgradable) with respect to the number of CPUs configured and Memory Configured so as to meet the bank’s scalability requirements.

8. The CPU type offered should be of the same generation / architecture across all servers and should be of the latest generation.

9. The Memory Chipset should be of Double Data Rate 3 (DDR3) memory.

10. The Bidder is expected to provide SAN based storage facility for hosting Credit Risk Management and Operational Risk Management systems production, test and development data. All past and future data would be stored on a single infrastructure i.e. new SAN. The new SAN storage capacity is


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

33

required for 7 years for the data at the DC and DRS each. The new solution proposed by the Bidder should be capable of accessing the existing SAN for the purpose of data migration and data archival as and when required. The current core usable production data size on the existing SAN is approximately 2 TB.

11. If the solution suggested by the bidders necessitates additional capacity, then the bidder would need to provide accordingly to meet the RFP . The Service Level Agreement (SLA) will be finalized based on the RFP and subsequent clarifications.

12. The Bidder should design the hardware taking note of parameters for CPU utilization, memory utilization, disk Input/output capacity, and Storage capacity etc. as defined in the RFP so as to meet the business requirements of the bank as well as Service Level Agreement requirements defined in this RFP. The proposed SAN (Storage Area Network) and storage management solution should support combinations of mostly used RAID levels (e.g. RAID 0,1,5,6 etc.). The complete production data should be on a combination of RAID 5.

13. The tape library offered should be of the latest generation and of modular design to allow configuration, and addition of capacity to increase performance. Offered Tape Drives in the Tape Library should be LTO5 or better.

14. The Storage Array proposed by the Bidder should be Enterprise Class Monolithic Storage with no Single Point of Failure. (Monolithic implies that the storage should have capabilities of addition of Front End Boards, Back end Boards, Cache Boards etc.)

Bank requirement is for 12TB storage. The storage offered should meet the SLA requirement of the

project.

15. The Storage S y s t e m s h o u l d support industry standard applications / databases, including but not limited to MS SQL Server, Oracle, MySQL, DB2, Web and Application Servers, MS Exchange, Lotus Notes etc.

16. The storage system should support heterogeneous multi‐host connectivity. The system should facilitate connectivity to various flavours of Operating Systems (OS), including but not limited to, HP‐UX, IBM AIX, SUN Solaris, Linux, Microsoft Windows, etc.

17. The switch should have support of all leading SAN / NAS disk arrays and tape l ibrar ies and bidder should ensure connectivity of existing SAN to proposed SAN switches.

18. The hard disk proposed for production storage in the array should be FC (Fibre Channel) or SAS (serial attachment SCSI) drives only.

19. The proposed Tape Library should be offered with redundant power supplies and cooling fans.

20. Offered tape library/ tape drives in the library should have a minimum of two redundant connections to SAN switches.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

34

21. The Management console/interface of the proposed tape library shall provide the following functionalities:

• Manage Tape Drives and Cartridges

• Configure network parameters

• Should have GUI Front panel

22. All the components (hardware, software etc.) in the DC site should be replicated in the DR

(except Test and Development environment). The proposed solution should have full capability to

support database to database replication and storage to storage replication between DC and DR

with a Recovery Point Objective (RPO) of 30 minutes and Recovery Time Objective (RTO) of 4 hours.

The replication between DC and DR should be possible in both directions.

3.1.6 Performance Guidelines

The proposed solution should be able to comply with the following guidelines on performance and solution

components in minimum.

a) Bidder should clearly specify the detailed configuration and specifications of the

applications and corresponding hardware required at various levels of performance and supply a

detailed Bill of Materials (BoM) with the part numbers for the hardware based on the technical

requirements. The bidder should separately list down the reasons for the recommended hardware

configurations and specifications.

b) The bidder has to explain through proper calculations how the performance of the system vis‐à‐vis

business statistics, projected growth, redundancy, projected growth in functional requirements,

concurrent users, performance parameters expected on peak load, VaR or other parameter

calculations, transactions handled per second, month end , quarter‐end and year‐end activity etc.,

are ensured. The bidder should provide data on any other parameter which would be required.

c) Bidder to indicate the timing of the performance testing (before/after installation of hardware).

Bidder will do this at a mutually agreed location at his cost

Performance testing will be one of exercise; however system performance report needs to be

submitted on monthly basis at no extra cost to the bank.

d) Bidder should also provide data on the solution as how the individual components offered under

the solution (application and associated hardware) would be able to meet the current volumes as

well as the future scalability requirements.

e) The bidder should provide information on industry standard bench‐ marks for the system such as

TPC‐C certified by Transaction Processing Council and / or Oracle TPMC that is made available in


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

35

respective web‐ sites. The bidder has to furnish the details of the configuration of the servers, OS and

databases used in such benchmarking exercise for TPC‐C, Oracle TPMC, etc. and relate the same to

the server configurations proposed for Bank’s requirement.

f) The bidder should also provide the benchmarks with Risk Management application software

preferably conducted with real time loads for similar requirement or as acceptance test with

credential and details of references involved in conducting such bench‐marks. The Bidder has to

relate the same to the model and configuration of the hardware proposed for Bank’s

requirement.

Bidder has to provide briefs for the risk engines with considering full loads while running batch

applications.

g) Besides the above, the bidder may furnish the details of any other benchmarks either Industry

standard such as “SPEC” ratings or for other Financial Institutions with due relevance.

h) The bidder may also furnish certified performance details from past implementations of similar

nature.

i) Bank may advise the bidder to conduct the benchmark when the systems are ready for dispatch to

Bank’s site or after completion of installation and evaluate performance. It is for the bidder to

establish that the sizing is proper for the requirement and to demonstrate the performance to Bank’s

designated officials and consultants.

3.1.7 Performance Security

Within the period prescribed under Annexure 9.15 from date of receipt of notification of contract

award, the Bidder shall furnish to the bank as per Bank format enclosed herewith, the Performance

Security for an amount of 10% of the contract value which would be valid for the entire project period or

entire period of 7 years excluding claim period.

1. The proceeds of the performance security shall be payable to the Bank as compensation for any loss

resulting from the Bidder’s failure to complete its obligations under the Contract.

2. The Performance Security shall be denominated in Indian Rupees and shall be by way of Bank

Guarantee issued by a Scheduled / Nationalized bank in India (other than Central Bank of India),

acceptable to the bank in the Format.

3. The performance security will be discharged by the Bank and returned to the Bidder after 30 days

following the date of completion of the Bidder’s performance obligations under the contract.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

36

4. In the event of any contract amendment, the Bidder shall, within 30 days after receipt of such

amendment, furnish the amendment to the performance security, rendering the same valid for the

duration of the contract as amended.

3.1.8 SLA

Bank expects that the Bidder shall be bound by the Service Levels described in this document. Service Levels

will include Availability measurements and Performance parameters. SLA will be based on RFP and

subsequent clarifications. Bank requires the Bidder to provide reports for all availability and performance

parameters a log of all issues that have been raised and Closed/ Pending Closure by the Bidder. The

frequency of these reports would be Weekly, Monthly, Quarterly, Half-Yearly and Yearly. Apart from reports

on each availability and performance measurement parameter mentioned below, the reporting should also

include the following:

1. Utilization of CPU, RAM, Hard Disk, I/O (Peak and Average) 2. Percent of CPU utilized by the system and user activity. 3. CPU utilization broken down by user CPU and system CPU. Tabular report of CPU, Memory, NIC and

I/O utilization (peak and average) by application, if possible. 4. Percent of physical memory utilized by system and user processes. 5. Problem Trends 6. Call Resolution Time

However, all Availability and Performance Measurements will be on a monthly basis for the purpose of Service Level reporting.

Audits will normally be done on monthly/quarterly basis or as required by Bank and will be performed by

Bank or Bank appointed third party agencies.

Conformity Letter / undertaking to be submitted by bidder as per Format attached in Section 9.18

SLA for Hardware & Software

Availability Measurements Expected

Service Level

Base Amount on which

penalty will be calculated

Availability of Business Infrastructure (Core Application Servers, Core Database Servers, Storage, SAN Switch, Tape Library, Oracle RDBMS and related components etc.) in DC and DRC

98.5% Value of the said business infrastructure for DC or DRC, as the case may be.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

37

Availability Measurements Expected

Service Level

Base Amount on which

penalty will be calculated

Availability of all other infrastructure, all other software components and Test and Development infrastructure

95% Value of the relevant infrastructure

The term ‘business infrastructure’ mentioned in this document shall include all capital costs of hardware, associated software (at DC or DRC, as the case may be) delivered as of the point of time when the penalty is levied. The cost of AMC/ ATS from the second year onwards will not be treated as capital cost and therefore excluded. The business infrastructure shall also exclude the capital cost of all components related exclusively to other infrastructure and Test and Development infrastructure, for the purpose of penalty calculation.

Type of Infrastructure

Measurement Expected Service

Level

Base Amount on which penalty will be calculated

System

Response Time

End to End response time

within the DC or DR

(from the CRMS & ORMS

Application to the

Database and back)

should be <0.5ms

(milliseconds)

98.5% The bidder is to upgrade the Hardware

along with related software and services

without any additional cost to the Bank,

if service level not met Till Service level is

met, penalty will be charged on the value

of the business infrastructure at DC or

DRC, as the case may be.

Disaster Recovery Site Availability

Business operations to

resume from Disaster

Recovery Site within 4

hours of the Data Centre

failing and vice versa.

100% Penalty will be charged on the value of

the business infrastructure at DC or DRC,

as the case may be.

Data Point Availability

Recovery Point Objective

(RPO) of] 30 minutes.

100% Penalty will be charged on the value of

the business infrastructure at DC or DRC,

as the case may be.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

38

3.1.9 Liquidated Damages

1. If the successful Bidder/Vendor fails to perform the Services within the period(s) specified in

the Contract / SLA, the Bank shall, without prejudice to its other remedies under the Contract,

deduct penalty from the Contract Price, as Liquidated Damages (LD), for every such default in

service.

2. The Liquidated Damages (LD) shall be a sum equivalent to 1%of contract amount for each week or part

thereof of delay until actual delivery or performance. However, the total amount of Liquidated

Damages deducted will be pegged at 10% of the contract amount. Once the liquidated damages reach

10% of the contract amount, the bank may consider termination of the contract.

3. At that point, the contract price will stand reduced to the actual amount payable by the Bank.

Proportionately the payment payable to the Successful Bidder will also stand reduced. All the

deliverables given to the Bank at that instant will continue to be the property of the bank and the

bank plans to use the same for any purpose which it may deem fit.

3.2 Payment Terms

Project

Milestones

Hardware

& Operating

Systems

Environmental

Software other

than RDBMS

Operational and

Credit Risk

Management

System

Implementation

Cost

Delivery and

installation of

hardware & other

infrastructure

components (after

due inspection and

acceptance at DC &

DRC)

30%

‐

‐

‐


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

39

Project

Milestones

Hardware

& Operating

Systems

Environmental

Software other

than RDBMS

Operational and

Credit Risk

Management

System

Implementation

Cost

Successful

implementation

of the respective

software and on

providing all the

required manuals,

data libraries, data

dictionaries, data

upload templates,

reporting template,

UAT Scenarios and

any other documents

required under

this RFP

‐

30%

‐

‐

Successful

completion of

Current State

Assessment, Gap

Analysis (including

data gap analysis)

and Systems

Requirement

Specifications (SRS)

Sign-off

5%

5% 5% 5%


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

40

Project

Milestones

Hardware

& Operating

Systems

Environmental

Software other

than RDBMS

Operational and

Credit Risk

Management

System

Implementation

Cost

Successful

Completion of

Customization,

Configuration,

Parameterization,

Documentation and

Sign-off

(including of Bank’s

Models)

5% 5% 10% 10%

Successful

Completion of

Interface Building /

ETL, Documentation

and Sign-off

10%

10%

10%

10%

Successful

Completion of Data

Extraction,

Validation, Data

Migration,

Reconciliation,

Documentation and

Sign-off

10%

10%

10%

10%

Successful

Completion of end-

to-end UAT,

Documentation and

Sign-off

10% 10% 20% 20%


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

41

Project

Milestones

Hardware

& Operating

Systems

Environmental

Software other

than RDBMS

Operational and

Credit Risk

Management

System

Implementation

Cost

Successful

Completion of

Sample Roll-out and

Trainings,

Documentation and

Sign-off

- - 5% 5%

Successful

Completion of

Migration to

Production,

Documentation and

Sign-off

- - 10% 10%

9 months from

the date of

successful

implementation (i.e.

on Sign-off of Project

Implementation and

Production

Migration)

20%

20%

20%

20%

After Completion of

Warranty

10%

10%

10%

10%

Total 100% 100% 100% 100%

Note: The payment Terms for AMC, ATS and Facilities Management have been separately articulated in the respective sections.

3.2.1 For Operational Risk & Credit Risk Management System

1. 5% of the contract amount on successful completion of Current State Assessment, Gap Analysis

(including data gap analysis) and Systems Requirement Specifications (SRS) Sign-off

2. 10% of the contract amount on successful completion of Customization, Configuration,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

42

Parameterization, Documentation and Sign-off (including of Bank’s Models)

3. 10% of the contract amount on successful Completion of Interface Building / ETL, Documentation and

Sign-off

4. 10% of the contract amount on successful Completion of Data Extraction, Validation, Data Migration,

Reconciliation, Documentation and Sign-off

5. 20% of the contract amount on successful Completion of end-to-end UAT, Documentation and Sign-

off

6. 5% of the contract amount on successful Completion of Sample Roll-out and Trainings,

Documentation and Sign-off

7. 10% of the contract amount on successful Completion of Migration to Production, Documentation

and Sign-off

8. 20% of the contract amount after 9 months from the date of successful implementation (i.e. on

Sign-off of Project Implementation and Production Migration)

9. 10% of the contract amount after Completion of warranty period or against Bank Guarantee of

equivalent amount valid for the entire warranty period.

3.2.2 For Hardware, other Infrastructure components and Operating Systems

1. 30% of the contract amount for application licenses will be payable on delivery and installation of

hardware & other Infrastructure components (after due inspection and acceptance by the bank).

2. 5% of the contract amount for application licenses Successful completion of Current State Assessment,

Gap Analysis (including data gap analysis) and Systems Requirement Specifications (SRS) Sign-off.

3. 5% of the contract amount for application licenses on Successful Completion of Customization,

Configuration, Parameterization, Documentation and Sign-off (including of Bank’s Models).

4. 10% of the contract amount for application licenses on Successful Completion of Interface Building /

ETL, Documentation and Sign-off.

5. 10% of the contract amount for application licenses on Successful Completion of Data Extraction,

Validation, Data Migration, Reconciliation, Documentation and Sign-off.

6. 10% of the contract amount for application licenses on Successful Completion of end-to-end UAT,

Documentation and Sign-off.

7. 20% of the contract amount after 9 months from the date of successful implementation (i.e. on Sign-off

of Project Implementation and Production Migration).

8. The Balance 10% of the cost after completion of warranty period or against Bank Guarantee of


3.2.3 Environmental Software except RDBMS

1. 30% of the contract amount for application licenses will be payable on successful

implementation of the respective software and on providing all the required manuals, data libraries,

data dictionaries, data upload templates, reporting template, UAT Scenarios and any other documents


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

43

required under this RFP 2. 5% of the contract amount for application licenses Successful completion of Current State Assessment,

Gap Analysis (including data gap analysis) and Systems Requirement Specifications (SRS) Sign-off.

3. 5% of the contract amount for application licenses on Successful Completion of Customization,

Configuration, Parameterization, Documentation and Sign-off (including of Bank’s Models).

4. 10% of the contract amount for application licenses on Successful Completion of Interface Building /

ETL, Documentation and Sign-off

5. 10% of the contract amount for application licenses on Successful Completion of Data Extraction,

Validation, Data Migration, Reconciliation, Documentation and Sign-off

6. 10% of the contract amount for application licenses on Successful Completion of end-to-end UAT,

Documentation and Sign-off

7. 20% of the contract amount after 9 months from the date of successful implementation (i.e. on

Sign-off of Project Implementation and Production Migration)



3.2.4 Implementation Cost

1. 5% of the contract amount on successful completion of Current State Assessment, Gap

Analysis (including data gap analysis) and Systems Requirement Specifications (SRS) Sign-off.

2. 10% of the contract amount on Successful Completion of Customization, Configuration,

Parameterization, Documentation and Sign-off (including of Bank’s Models).

3. 10% of the contract amount on Successful Completion of Interface Building / ETL, Documentation and

Sign-off

4. 10% of the contract amount on Successful Completion of Data Extraction, Validation, Data Migration,

Reconciliation, Documentation and Sign-off

5. 20% of the contract amount on Successful Completion of end-to-end UAT, Documentation and Sign-off

6. 5% of the contract amount on Successful Completion of Sample Roll-out and Trainings, Documentation

and Sign-off

7. 10% of the contract amount on Successful Completion of Migration to Production, Documentation and

Sign-off

8. 20% of the contract amount after 9 months from the date of successful

implementation (i.e. on Sign-off of Project Implementation and Production Migration)



3.2.5 Price Composition

The Bidder is expected to quote unit price in Indian Rupees (without decimal places) for all components

(hardware, software etc.) and services on a fixed price basis as part of the commercial Bid inclusive of all

costs and taxes like customs duty, excise duty, import taxes, freight, forwarding, insurance, delivery,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

44

installation, training etc. at the respective delivery location of the bank but exclusive of only

applicable (in India) Sales Tax/VAT, Service Tax and Octroi / Entry Tax / equivalent local authority cess,

which shall be paid / reimbursed on actual basis on production of bills. Further, receipts of such

payments made to relevant authorities must be produced for Octroi / Entry Tax / equivalent local

authority cess. The Bank will not pay any other taxes, cost or charges.

3.2.6 Additional Training Cost

100% of the additional training cost would be paid on completion of training. The decision for additional

training would be taken by the bank and would be discussed with the selected Bidder.

3.2.7 Road Permit

In case of receiving of hardware to the area where Road Permit is required for transportation of goods, it

is the responsibility of the bidder to arrange for the same in advance without any extra cost to the bank.

3.2.8 Right to Alter Quantities

a. The bank will be free to either reduce or increase the quantity to be purchased by 25% on the same

terms and conditions.

b. The bank also reserves the right to place further / repeat order on the same terms and conditions

within a period of 24 months from the date of purchase order.

The decrease in quantity will not be applicable after acceptance of Purchase Order; however bank can

increase the quantity in first 24 months from the date of Purchase order at the same rate and terms &

conditions defined in the Purchase Order for any items.

3.2.9 Payment Term for Facilities Management

a. The payment will be released at the end of every quarter as per the payment terms in Section 3.2

3.3 Warranty & Annual Maintenance

3.3.1 Maintenance Standard during Warranty & Post Warranty Maintenance)

1. The warranty period for the solution (hardware & software) shall be for 3 years from the date of go

live of complete solution for Integrated Risk Management system. AMC/ATS period starts after

completion of warranty period.

2. AMC / ATS payment due shall be released after completion of quarter.

3. During Warranty Period/ AMC/ATS, Bidder/Vendor guarantees an Uptime of 98.5 % on monthly basis


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

45

for the entire turnkey solution provided. This will be subject to a ceiling of not more than 120

minutes s i n g le i n st a n ce downtime. Selected Bidder is expected to submit a report within a week

after expiry of every calendar quarter. Delays, if any, on account of procurement of spares will not

be exempted while reckoning the uptime SLA.

(Uptime: the amount of time that the system is available for normal use. Do note that planned maintenance would also be classified as normal use. )

4. During maintenance period also, the Bidder guarantees on monthly basis an uptime of 98.5% of the

entire solution provided. Accordingly it is expected that necessary redundancy is built into the

solution for all components whether software or hardware.

5. During the period of AMC/ATS, if the service provided by the Bidder is not satisfactory, the bank

reserves the right to terminate the AMC contract and appoint any other agency at the risk and cost of

the Bidder.

6. The maximum response time for a maintenance complaint from the site of installation (i.e. time

required for Bidder’s maintenance engineers to report to the installations after a request call / fax

/e‐mail is made or letter is written) shall not exceed One hour.

7. In the event of failure of maintaining the uptime SLA (based on point no. 3 & 4 above) liquidated

damages of 10,000/‐ per day would be levied up‐to max of 10% of overall value of the project.

3.3.2 Termination

1. Termination for Default

The Bank, without prejudice to any other remedy for breach of contract, by written notice of default

sent to the Successful Bidder, may terminate this Contract in whole or in part:

a. if the Successful Bidder fails to deliver any or all of the deliverables / milestones within the

period(s) specified in the Contract, or within any extension thereof granted by the Bank; or;

b. If the Successful Bidder fails to perform any other obligation(s) under the contract

c. If the Successful Bidder, in the judgment of the Bank has engaged in corrupt or fraudulent

practices in competing for or in executing the Contract

Corrupt practice means the offering, giving, receiving or soliciting of anything of value or

influence the action of a public official in the procurement process or in contract execution;

and “fraudulent practice” means a misrepresentation of facts in order to influence a

procurement process or the execution of a contract to the detriment of the Bank, and includes


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

46

collusive practice among Bidders (prior to or after bid submission)

designed to establish bid prices at artificial non‐competitive levels and to deprive the Bank

of the benefits of free and open competition.

2. In the event, the Bank terminates the Contract in whole or in part, the Bank may procure, upon such

terms and in such manner as it deems appropriate, Goods or Services similar to those undelivered, and

the Successful Bidder shall be liable to the Bank for any excess costs for such similar Goods or Services.

However, the Successful Bidder shall continue performance of the Contract to the extent not

terminated when the value of the liquidated damages exceed 10% of the contract value.

3. In case the contract is terminated then all undisputed payment will be given to vendor, but disputed

payment shall be adjusted by way of penalty from invoices or PBG.

4. Termination for Insolvency

If the Bidder becomes bankrupt or insolvent, has a receiving order issued against it, compounds

with its creditors, or, if the Bidder is a corporation, a resolution is passed or order is made for its

winding up (other than a voluntary liquidation for the purposes of amalgamation or reconstruction), a

receiver is appointed over any part of its undertaking or assets, or if the Bidder takes or suffers any

other analogous action in consequence of debt; then the Bank plans to, at any time, terminate

the contract by giving written notice to the Bidder. If the contract is terminated by the Bank in

terms of this Clause, termination will be without compensation to the Bidder, provided that such

termination will not prejudice or affect any right of action or remedy which has accrued or will

accrue thereafter to the Bank. In case, the termination occurs before implementation in all the

locations in terms of this clause, the Bank is entitled to make its claim to the extent of the amount

already paid by the Bank to the Bidder.

5. Termination – Key Terms & Conditions

The Bank shall be entitled to terminate the agreement with the Bidder / vendor at any time by giving

ninety (90) days prior written notice to the Bidder. The Bank shall be entitled to terminate the

agreement at any time by giving notice if the Bidder

a. has a winding up order made against it; or

b. has a receiver appointed over all or substantial assets; or

c. is or becomes unable to pay its debts as they become due; or

d. enters into any arrangement or composition with or for the benefit of its creditors; or

e. Passes a resolution for its voluntary winding up or dissolution or if it is dissolved.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

47

The Bidder shall have right to terminate only in the event of winding up of the Bank. Bank will

specify the period for remedying any defect.

6. Exit Option and Contract Re-Negotiation

a. The Bank reserves the right to cancel the contract in the event of happening one or more of the

following Conditions:

i. Failure of the selected Vendor to accept the contract and furnish the Performance Guarantee

within 10 days of receipt of purchase contract;

ii. Delay in delivery, performance or implementation of the solution beyond the specified period;

iii. Serious discrepancy in functionality to be provided or the performance levels agreed upon,

which have an impact on the functioning of The Bank. Inability of the Vendor to remedy the

situation within 60 days from the date of pointing out the defects by The Bank. (60 days will be

construed as the notice period)

b. In addition to the cancellation of purchase contract, Bank reserves the right to appropriate the

damages through encashment of Bid Security / Performance Guarantee given by the Vendor.

c. The Bank will reserve a right to re-negotiate the price and terms of the entire contract with the

Vendor at more favorable terms in case such terms are offered in the industry at that time for

projects of similar and comparable size, scope and quality.

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

such equipment is available at a lower price and the Vendor’s offer does not match such lower

price. Notwithstanding the foregoing, the Vendor shall continue to have the same obligations as

contained in this RFP in relation to such equipment procured from third-party suppliers.

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

the equipment was available at more favorable terms in the industry, and secondly,

The Equipment procured here from third parties is functionally similar, so that the Vendor can

maintain such equipment.

The modalities under this right to re-negotiate /re-procure shall be finalized at the time of

contract finalization.

d. Notwithstanding the existence of a dispute, and/or the commencement of arbitration proceedings, the

Vendor will be expected to continue the facilities management services and the Bank will continue to

pay for all products and services that are accepted by it provided that all products and services as

serving satisfactory, as per satisfaction of the Bank. The Bank shall have the sole and absolute

discretion to decide whether proper reverse transition mechanism over a period of 6 to 12 months,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

48

has been complied with. In the event of the conflict not being resolved, the conflict will be resolved

through Arbitration.

The Bank and the Vendor shall together prepare the Reverse Transition Plan. However, The Bank shall

have the sole decision to ascertain whether such Plan has been complied with.

Reverse Transition mechanism would typically include service and tasks that are required to be

performed / rendered by the Vendor to The Bank or its designee to ensure smooth handover and

transitioning of Bank’s deliverables, maintenance and facility management.

7. Force Majeure

a. The Vendor shall not be liable for forfeiture of its performance security, liquidated damages or termination for default, if any to the extent that its delay in performance or other failure to perform its obligations under the contract is the result of an event of Force Majeure.

b. For purposes of this Clause, "Force Majeure" means an event explicitly beyond the reasonable control of the Vendor and not involving the Vendor's fault or negligence and not foreseeable. Such events may include, Acts of God or of public enemy, acts of Government of India in their sovereign capacity and acts of war.

c. If a Force Majeure situation arises, the Vendor shall promptly notify The Bank in writing of such conditions and the cause thereof within fifteen calendar days. Unless otherwise directed by The Bank in writing, the Vendor shall continue to perform Vendor’s obligations under the Contract as far as is reasonably practical, and shall seek all reasonable alternative means for performance not prevented by the Force Majeure event.

d. In such a case the time for performance shall be extended by a period (s) not less than duration of such delay. If the duration of delay continues beyond a period of three months, The Bank and the Vendor shall hold consultations in an endeavor to find a solution to the problem. Notwithstanding the above the decision of the Bank shall be final and binding on the Vendor.

8. Resolution of Disputes

a. The Bank and the supplier Vendor shall make every effort to resolve amicably, by direct informal

negotiation between the respective project directors of The Bank and the Vendor, any

disagreement or dispute arising between them under or in connection with the contract.

b. If The Bank officials and Vendor project director are unable to resolve the dispute after thirty

days from the commencement of such informal negotiations, they shall immediately escalate

the dispute to the senior authorized personnel designated by the Vendor and Bank respectively.

c. If after thirty days from the commencement of such negotiations between the senior authorized

personnel designated by the Vendor and Bank, The Bank and the Vendor have been unable to

resolve amicably a contract dispute; either party may require that the dispute be referred for

resolution through formal arbitration.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

49

d. All questions, disputes or differences arising under and out of, or in connection with the contract

or carrying out of the work whether during the progress of the work or after the completion and

whether before or after the determination, abandonment or breach of the contract shall be

referred to arbitration by a sole Arbitrator: acceptable to both parties OR the number of

arbitrators shall be three, with each side to the dispute being entitled to appoint one arbitrator.

The two arbitrators appointed by the parties shall appoint a third arbitrator shall act as the

chairman of the proceedings. The award of the Arbitrator shall be final and binding on the

parties. The Arbitration and Reconciliation Act 1996 or any statutory modification thereof shall

apply to the arbitration proceedings and the venue of the arbitration shall be Mumbai. The

Language of Arbitration will be English and court of Mumbai shall have exclusive jurisdiction.

e. If a notice has to be sent to either of the parties following the signing of the contract, it has to be

in writing and shall be first transmitted by facsimile transmission by postage prepaid registered

post with acknowledgement due or by a reputed courier service, in the manner as elected by the

Party giving such notice. All notices shall be deemed to have been validly given on (i) the

business date immediately after the date of transmission with confirmed answer back, if

transmitted by facsimile transmission, or (ii) the expiry of five days after posting if sent by

registered post with A.D., or (iii) the business date of receipt, if sent by courier.

f. This RFP shall be governed and construed in accordance with the laws of India. The courts of

Mumbai alone and no other courts shall be entitled to entertain and try any dispute or matter

relating to or arising out of this RFP. Notwithstanding the above, The Bank shall have the right

to initiate appropriate proceedings before any court of appropriate jurisdiction, should it find it

expedient to do so.

9. Corrupt and Fraudulent Practices

As per Central Vigilance Commission (CVC) directives, it is required that Vendors / Suppliers / Contractors

observe the highest standard of ethics during the procurement and execution of such contracts in

pursuance of this policy:

“Corrupt Practice” means the offering, giving, receiving or soliciting of anything of values to influence the

action of an official in the procurement process or in contract execution AND

“Fraudulent Practice” means a misrepresentation of facts in order to influence a procurement process or

the execution of contract to the detriment of The Bank and includes collusive practice among Vendors

(prior to or after offer submission) designed to establish offer prices at artificial non-competitive levels and

to deprive The Bank of the benefits of free and open competition.

The Bank reserves the right to reject a proposal for award if it determines that the Vendor recommended

for award has engaged in corrupt or fraudulent practices in competing for the contract in question.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

50

The Bank reserves the right to declare a firm ineligible, either indefinitely or for a stated period of time, to

be awarded a contract if at any time it determines that the firm has engaged in corrupt or fraudulent

practices in competing for or in executing the contract.

4. Evaluation Methodology

Each Recipient acknowledges and accepts that the Bank may, in its sole and absolute discretion, apply

whatever criteria it deems appropriate in the selection of organizations, not limited to those selection

criteria set out in this RFP document.

The issuance of RFP document is merely an invitation to offer and must not be construed as any

agreement or contract or arrangement nor would it be construed as any investigation or review carried

out by a Recipient.

The Recipient unconditionally acknowledges by submitting its response to this RFP document that it has

not relied on any idea, information, statement, representation, or warranty given in this RFP document.

The objective of the evaluation process is to evaluate the bids to select an effective solution at a

competitive price.

Through this Request for Proposal, Bank aims to select a Bidder/ application provider who would

undertake the designing and implementation of the required solution. The Bidder shall be entrusted

with end‐to‐end responsibility for the execution of the project under the scope of this RFP. The

Bidder is expected to commit for the delivery of services with performance levels set out in this

RFP with a Service Level Agreement.

The Bank has adopted a two bid process in which the Bidder has to submit three envelopes

containing (1) Eligibility criteria (2) Technical Bid and (3) Commercial Bids separately but at a time

as stipulated.

The Bank shall evaluate the Technical Bids initially and based on Technical Bid evaluation shall

undertake evaluation of the Commercial bid of the technically qualified proposals only. This will be

followed by a commercial process for the technically qualified bidders.

The evaluation by the Bank will be undertaken by a Committee of Officials and External Consultants

formed by Bank and its decision is final.

4.1 Opening of Bids by the Bank

4.1.1. Normalization of Bids

The Bank will go through a process of technical evaluation and normalization of the bids to the extent

possible and feasible to ensure that Bidders are more or less on the same technical ground. After the

normalization process, if the Bank feels that any of the bids needs to be normalized and that such

normalization has a bearing on the commercial bid; the Bank may at its discretion ask all the

technically short‐listed Bidders to resubmit the technical and commercial bids once again for scrutiny .The

Bank can repeat this normalization process at every stage of technical submission or till the Bank is satisfied.

The Bidders agree that they have no reservation or objection to the normalization process and all the

technically short listed Bidders will, by responding to this RFP, agree to participate in the normalization


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

51

process and extend their co‐operation to the Bank during this process. The Bidders, by submitting the

response to this RFP, agree to the process and conditions of the normalization process.

4.1.2. Opening of Technical Bids

1. Those Bidders satisfying the eligibility criteria and accepting the terms and conditions of this

document shall be short‐listed for further evaluation. 2. The technical bids of Bidders who have furnished the EMD as mentioned above will be opened in the

presence of authorized representatives of the Bidders on the date and time specified in this RFP. 3. The Bank will open the Technical bid in the presence of Bidders’ representatives who choose to

attend. 4. A minimum of three Bids should have been received by the Bank. 5. The Bidders’ names, withdrawals and the presence or absence of requisite EMD and such other details

as the Bank, at its discretion, may consider appropriate, will be announced at the time of Technical Bid opening. No bid shall be rejected at the time of bid opening, except for late bids, which shall be returned unopened to the Bidder.

6. In case the bid opening date falls on a Bank holiday in Mumbai, the bids shall be opened at the same time on the next working day.

7. The Bank will examine the bids to determine whether they are complete, whether required information has been provided as stated in the bid document, whether the documents have been properly signed, and whether bids are generally in order subject to fit in eligibility criteria.

8. The evaluation shall include fulfillment of functionality requirements as given in the RFP. Any bid determined as not in order as per the specifications will be rejected by the Bank.

9. Any effort by Bidder to influence the Bank in the Bank’s bid evaluation, bid comparison or contract award decision may result in the rejection of the Bidders’ bid. Bank’s decision will be final and without prejudice and will be binding on all Bidders.

10. The Bank reserves the right to accept or reject any bid and annul the bidding process and reject all bids at any time prior to award of contract, without thereby incurring any liability to the affected Bidder or Bidders or any obligation to inform the affected Bidder or Bidders of the ground for the Bank’s action.

11. To assist in the examination, evaluation and comparison of bids the Bank plans to, at its discretion, ask the Bidders for clarification and response shall be in writing and no change in the price or substance of the bid shall be sought, offered or permitted.

12. Technically short listed Bidders shall be invited for a presentation of the solution at a date, time and venue to be conveyed separately. Final short listing for opening commercial bids shall be done based on the solution demonstration and meeting the functional requirements.

4.1.3. Committee for Bid Evaluation

1. The committee formed for evaluating the technical bids will examine the Bids to determine whether the documents are complete, are in the required formats, documents have been properly signed and the Bids are generally in order.

2. The above mentioned committee may, at its discretion, waive any minor infirmity, non-conformity, or irregularity in a Bid, which does not constitute a material deviation.

3. The above mentioned committee will examine whether the Bid and the Bidder is eligible in terms of


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

52

the Eligibility Criteria specified in the RFP and the decision of the Bank shall be final and binding on all bidders.

4. During evaluation of the Bids, the above mentioned committee, at its discretion, may ask a bidder for clarification of its bid. The request for clarification and the response shall be in writing, and no change in the price or substance of the bid shall be sought, offered or permitted.

4.1.4. Opening of Commercial Bids

1. The Bank will open Part II (Commercial Bid) of the bids short listed in the Technical evaluation in presence of the evaluation committee.

2. The Bidders’ names and bid prices will be recorded at the bid opening. 3. Commercial bids of technically non‐responsive Bidders shall be returned un‐opened.

4.1.5. Determination of Successful Bidder and Awarding of Contract

On Completion of evaluation process of Technical Bids, Bank will carry out commercial evaluation of

the bids only for technically qualified bidders as per business rules given in Sub Section 4.3 and terms

& conditions mentioned under Evaluation Criteria and the contract will be awarded to the bidder having

the highest Relative Commercial Score (RES) which is an outcome of Techno‐Commercial Evaluation

process.

Bidders are advised to refer to Section 4: Evaluation Methodology for details and methodology of

Evaluation Criteria

4.2 Eligibility Criteria

Sr.

No.

Eligibility Criteria Documentary Evidence to be submitted to

the bank

General Eligibility

1 The bidder should be in existence for 5 years as on

31st March 2014. (In case of

mergers/acquisitions/restructuring or name

change, the date of establishment of

earlier/Original firm would be taken into

consideration.)

Certificate of incorporation

2 The bidder should be a profit making entity for last

three financial years i.e. 2011-12,2012-13,2013-14

Copies of Annual Reports in case of listed

companies and Copies of audited balance

sheets and P&L statements in case of others

for past 3 financial years.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

53

Sr.

No.


the bank

3 The Bidder (SI) must have a presence in India for at

least 3 years with an established set-up with

available support staff (related to the systems

covered by the RFP) and should have average

revenues in excess of INR 100 Cr. For the past 3

financial years i.e. 2011‐12, 2012‐13 and 2013-14.



sheets and P&L statements in case of others

for past 3 financial years.

Certificate of Commencement of business.

Details of offices in India

Details of available support staff in India

4 The Bidder (SI) and OEMs should not have been

blacklisted at the time of submission by the

Central/any of the State Governments/ statutory

body/ regulatory body/Indian Banks Association in

India

Self-declaration of SI and all the OEM’s

5 The Bidder should own the intellectual property

rights of the product / solution or he should have

rights from the owner, If not, the Bidder should

have in place proper tie‐ups, commercial

agreements, authorized implementation

partnership etc. for deployment/ resale/

customization of software with the product Bidder

or any other third party, whose software products

are offered.

Letter/ Certificate from OEM

Product Capabilities

6 Proposed credit risk solution should have been

procured by at least 1 scheduled commercial bank

in India or a bank abroad for implementation of

Advanced (IRB) approaches (only standardized

approach would not be eligible)

Credential letter on bank’s letter head

7 Proposed operational risk solution should have

been procured by at least 1 scheduled commercial

bank in India or a bank abroad for implementation

of Advanced (AMA) approaches (only BIA/TSA




-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

54

Sr.

No.


the bank

8 The proposed Credit risk solution and Operational

risk solution should have been implemented by a

Bank operating in jurisdictions where Advanced

(IRB/ AMA) have been approved by the regulator

for the Bank.


9 The proposed Credit risk and Operational risk

solution should be positioned in the leader’s

quadrant of Chartis research report/Gartner’s

magic quadrant.

Gartner report and Chartis report

10 The proposed bidder should have experience of

implementing Credit risk IRB and operational risk

AMA solutions in a Bank in India or Abroad


4.3 Evaluation Criteria

4.3.1 Preliminary RFP Examination

The evaluation by the Bank will be undertaken by an Internal Committee formed by the Bank. The bank may

consider recommendations made by External Experts/Consultants on the Evaluation. The decision of the

committee shall be final.

Bank may call for any clarifications/additional particulars required, if any, on the technical/ commercial bids

submitted. The bidder has to submit the clarifications/ additional particulars in writing within the specified

date and time. The bidder’s offer may be disqualified, if the clarifications/ additional particulars sought are

not submitted within the specified date and time. Bank reserves the right to call for presentation/s, product

walkthroughs, on the features of the solution offered etc., from the bidders based on the technical bids

submitted by them. Bank also reserves the right to conduct Reference Site Visits at the bidder’s client sites.

Based upon the final technical scoring, short listing would be made of the eligible bidders for final

commercial evaluation. Through this Request for Proposal, Bank aims to select a Bidder/ application provider

who would undertake the designing and implementation of the required solution. The Bidder shall be

entrusted with end‐to‐end responsibility for the execution of the project under the scope of this RFP. The

Bidder is expected to commit for the delivery of services with performance levels set out in this RFP with a

Service Level Agreement.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

55

4.3.2 Technical Bid Evaluation Criteria

The proposal submitted by the Bidders shall be evaluated on technical grounds covering various

components of the projects as follows:

1. Implementation Requirements: detailed implementation requirements at all stages of the project

has been mentioned. These requirements are integral part of the scope and vendor will have to

implement all those requirements. In the response to this RFP, vendor is required to give approach

and methodology as to how vendor is going to execute all the requirements.

2. Functional requirements: The minimum functional specifications for the ORMS

(Operational Risk Management System) and CRMS (Credit Risk Management System)

software are given in Section 6.2: & Section 7.2: Functional Requirements. All the

requirements are mandatory. Bidder shall indicate in column 3 the availability of each

requirement as a Readily Available (A) or Work around (W) or Customization Required (C)

or Not Available (N). The Software solution offered, however, should have at least 85% of the

f u n c t i o n a l requirements as a part of the standard product. The remaining shall be

customized before the completion of pilot run at no extra cost to the Bank.

Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% for - Work around (W)’, ‘50% for - Customization (C)’ and ‘0 for - Not available(N)’.

3. Technical Requirements: The minimum technical specifications for the ORMS and CRMS software

are given in Section 6.3 & Section7.3: Technical Requirements. All the requirements are mandatory.

Bidder shall indicate in column 3 the availability of each requirement as a readily available (A), work

around (R) or customization (C) or not available (N). The Software solution offered, however, should

have at least 85% of the requirements as a part of the standard product. The remaining shall

be customized before the completion of pilot run at no extra cost to the Bank.

Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% marks for - Work

around (W)’, ‘50% for - Customization (C) and ‘0 for - Not Available (N)’.

4. Product Demonstration & Bid Presentation: Eligible Bidders are required to make presentations to

supplement their bids and show a detailed product demonstration. The Bank will schedule

presentations and the time and location will be communicated to the Bidders. Failure of a Bidder to

complete a scheduled presentation to the Bank may result in rejection of the proposal.

Vendor will have to make presentation basis the outlines / expectation given for coverage in the

presentation.

The same criteria (as Evaluation for functional specifications) will be applied to Product

Demonstration also.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

56

Technical score will be finalized based on both ‐ response provided by vendor and product

demonstration.

5. Past Experience:

a) The Bidder should provide details of past experience in implementing Advanced

Operational Risk Management Solution (ORMS) and Advanced Credit Risk Management Solution

(CRMS)

b) The Bidder’s past experience shall be evaluated and the score obtained by the Bidder shall be

considered for evaluation as given in Section 9.11: Past Experience Details

c) The Bidder should provide the details of all the implementations in Banks including details of

scope of project, period when project was done, details of the bank, number of branches with

breakup of the role and proof of implementation.

d) Experience at co‐operative banks (State Co‐operative banks, District Central co‐operative banks,

Urban Co‐operative banks, etc.) shall not be considered for evaluation.

e) Credentials are to be provided in English only.

6. Approach and Methodology

a) Reference site visit/ Tele conference: a committee of people from the Bank would carry out

Reference Site Visits and/or Telephonic interviews with the existing customers of the Bidder.

The inputs that have been received from the Customer would be considered by the Bank and

this might not need any documentary evidence. This rating would be purely on the inputs

(like satisfaction of the organization of the product, timeliness of implementation,

promptness of support services etc.) provided by the Bidder’s customers and score would

be assigned to Bidder as mentioned in Section 9.9: Reference Site Details.

The Bank at its discretion may reject the proposal of the Bidder without giving any reasons

whatsoever, in case the responses received from the Site Visits are negative.

b) Team Strength:

i. Bidder responses to each point under Team Strength in Section 9.14: Implementation Team Profile, including the team profile provided by the Bidder, would be evaluated.

ii. The Bidder should ensure that the people above the role of the Team Lead who are proposed for this project should have worked on projects in Indian Banks earlier.

iii. Bidder should specify role of each profile such as Project Manager, Technical Team Member, Functional Team Member, ORM or CRM or both streams, experience in years, areas of experience, qualification, details of the relevant projects, their roles on the project etc.

iv. Bidder should specify out of the profile provided, who are going to be part of the project team with their role on the project.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

57

v. Bidder should specify if the resource committed for the project is full time or part time. A percentage involvement can be specified.

c) Project Management:

i. Bidders are required to respond to each point under Project Management in annexure and each question will be evaluated for suitability of response.

ii. The Bidder should provide explanation on the Project Management process that is proposed for the Bank including details of how the same was applied in a similar project.

d) Training: the Bidder will be responsible for training the Bank’s employees in the areas of

implementation, operations, management, error handling, system administration, etc. with

respect to the implementation of ORMS/CRMS without extra cost to the Bank, except not

specifically agreed between parties

The core team training will include functional as well as technical training and shall be

considered within the scope of the Bidder

The end user training should be also included in the scope. The end user must be trained on all

functionalities required for efficient daily operations of the ORMS / CRMS

i. The quality of the Bidder’s training program shall form an integral part of the final

evaluation and selection of the Bidder. The RFP has a sheet in the Section 9.4.8: Training

Requirements provided separately which the Bidder shall need to complete to allow

Bank to evaluate the responses and assign scores against them.

ii. The questions pertain to the training techniques, course details provided by the

Bidder and the educational qualifications and experience of the trainers

4.3.3 Disqualification Parameters in Technical Bid Evaluation

1. The Bank at its discretion may reject the proposal of the Bidder without giving any reason

whatsoever, if in the Bank’s opinion, the Solution Sizing was not made appropriately to meet the

performance criteria as stipulated by the Bank.

2. The Bank at its discretion may reject the proposal of the Bidder without giving any reasons

whatsoever, in case the responses received from the Site Visits are negative.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

58

4.3.4 Functional & Technical Evaluation Criteria

4.3.4.1 For Operational Risk solution

S.

No. Evaluation Criteria

Basis of Evaluation Sub-scores

Max. Total

Score


1

Compliance of the

product with the

functional

requirements stated

in the RFP

Bidders responses in RFP

response against each line

item of the functional

requirements

Live demonstration of the

product to the Bank.

As per bank’s

evaluation 250

2

Compliance of the

product with the

technical

requirements stated

in the RFP




requirements


product to Bank.

150

3

Credential: Offered

solution is

Implemented or

under

implementation in

Scheduled Banks in

India or abroad

(If the solution is

under

implementation only

50% marks would be

counted. For 100%

marks, the vendor

Client credential letter stating

the status of implementation

A. 1 Bank – 50 marks

B. 2 Banks – 100 marks

C. More than 2 banks – 150 marks

150


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

59

S.



Max. Total

Score

should present a UAT

completion

certification for AMA

approaches.

Bidder’s Experience

4

Number of Scheduled

Commercial Banks in

India or abroad

where the bidder is

implementing /

implemented an

operational risk

solution for AMA

approaches.

(If the solution is

under

implementation only

50% marks would be

counted. For 100%

marks, the vendor


completion

certification for AMA

approaches.)

Client credential letter

stating the status of

implementation

A. 1 Bank – 50 marks

B. 2 Banks – 100 marks

C. More than 2 banks – 150 marks

150

Implementation Capabilities

5

Implementation

Approach

The bidder would be

required to present

following for each of

the implementation

requirements

1. Responses to

implementation

requirements section on

the RFP response

2. Vendor presentation (The

presentation should be

made by the proposed

engagement team, as

mentioned in the RFP

As per bank’s

evaluation 175


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

60

S.



Max. Total

Score

specified in the RFP

a. Approach for implementation in the proposed solution

b. Assumptions made

c. Estimated efforts for implementation of each requirement

d. Bidder’s experience of solving implementation challenges (especially in Indian PSU environments)

e. Proposed project plan and approach taken to address implementation challenges

response)

6

Project team

experience

a. Experience of operational risk AMA system implementation

b. Awareness of public sector bank Risk infrastructure

c. Number of years of relevant experience

Evaluation of CV provided in

the RFP response

Project team’s presentation &

responses to Bank’s queries in

presentation As per bank’s

evaluation

75

7 Reference site visit Response of reference bank As per bank’s 50


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

61

S.



Max. Total

Score

evaluation

Total Marks 1000

4.3.4.2 For Credit Risk Management Solution

S.



Max. Total

Score


1

Compliance of the

product with the

functional

requirements stated

in the RFP




requirements


product to the Bank.

As per bank’s

evaluation 250

2

Compliance of the

product with the

technical

requirements stated

in the RFP




requirements


product to Bank.

150

3

Credential: Offered

solution is

Implemented or

under

implementation in

Scheduled Banks in

India or abroad

Client credential letter stating

the status of implementation D. 1 Bank – 50 marks

E. 2 Banks – 100 marks

F. More than 2 banks – 150 marks

150


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

62

S.



Max. Total

Score

(If the solution is

under

implementation only

50% marks would be

counted. For 100%

marks, the vendor


completion

certification for IRB

approaches.

Bidder’s Experience

4

Number of Scheduled

Commercial Banks in

India or abroad

where the bidder is

implementing /

implemented a credit

risk solution for IRB

approaches.

(If the solution is

under

implementation only

50% marks would be

counted. For 100%

marks, the vendor


completion

certification for IRB

approaches.)

Client credential letter

stating the status of

implementation

D. 1 Bank – 50 marks

E. 2 Banks – 100 marks

F. More than 2 banks – 150 marks

150

Implementation Capabilities

5

Implementation

Approach

The bidder would be

3. Responses to

implementation

requirements section on

the RFP response

As per bank’s

evaluation 175


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

63

S.



Max. Total

Score

required to present

following for each of

the implementation

requirements

specified in the RFP

f. Approach for implementation in the proposed solution

g. Assumptions made

h. Estimated efforts for implementation of each requirement

i. Bidder’s experience of solving implementation challenges (especially in Indian PSU environments)

j. Proposed project plan and approach taken to address implementation challenges

4. Vendor presentation (The

presentation should be

made by the proposed

engagement team, as

mentioned in the RFP

response)

6

Project team

experience

d. Experience of Credit risk IRB system implementation

e. Awareness of public sector bank Risk infrastructure

Evaluation of CV provided in

the RFP response

Project team’s presentation &

responses to Bank’s queries in

presentation

As per bank’s

evaluation

75


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

64

S.



Max. Total

Score

f. Number of years of relevant experience

7 Reference site visit Response of reference bank As per bank’s

evaluation 50

Total Marks 1000

4.3.5 Short listing of Technically Qualified Bidders

Evaluation of technology and technical bids will be done by a committee. The bidders who qualify in the

technical bid will be shortlisted. The commercial bid will be opened in the presence of representatives of

bidders who are shortlisted in the technical bid.

Initially only the ‘Technical Bids’ will be opened and evaluated. All technical bids will be evaluated and a

technical score would be arrived at.

The scoring methodology for technical bid components is explained in the following paragraphs of this

section. The Credit and Operational Risk System implementation involves various components including

implementation of necessary Application Software, RDBMS, development of interfaces and

customizations where necessary, setting up of all necessary applications in the Disaster Recovery Centre

for the roll-out, training of end users, performing data migration activities, providing implementation

services, and rolling out the system at various locations of Bank and provide maintenance services under

Facilities Management for a period of 7 years from go-live of last location. The proposal submitted by the

Bidders shall, therefore, be evaluated on the following parameters:

a) Functional Requirements (FR) b) Technical Requirements (TR) c) Approach and Methodology (AM) d) Past Experience (PE)

Scores for the above individual parameters shall be normalized to a percentage value. Each parameter has

been assigned a weight. The weighted scores shall be summed up to determine the technical scores of the

bidders. Bidders scoring at least 85% in both the Credit Risk Management and Operational Risk

Management in the technical-b i d evaluation will be short‐listed for commercial evaluation.

The minimum functional and technical specifications are given in Annexure 9.4. All the requirements are


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

65

mandatory. Bidder shall indicate in column 4 the availability of each requirement as a Readily Available

(A), Work around (W), Customization required (C) or Not available (N).

The following is the scoring methodology:

Description Percentage

A- Readily Available 100%

W- Work around 75%

C-Customization required 50%

N-Not available 0

Responding to the functional requirements by using responses other than A / W / C / N (such as “OK”,

“Accepted”, “Noted”, “Compliance” etc.) will be treated as non-compliance and no marks will be allotted

for such responses during technical evaluation.

Scoring Methodology for Implementation Requirements (AM)

The bidder is expected to provide, as a part of the technical bid, a detailed document that explains the

approach and methodology proposed by the bidder for the implementation requirements listed in the

RFP.

The “Approach and Methodology” adopted for the Implementation would be evaluated by the Bank and

would at the minimum cover:

a) Approach for implementation in the proposed solution

b) Assumptions made by the bidder

c) Estimated efforts for implementation of each requirement (to assess whether the right efforts

have been budgeted by the vendor)

d) Bidder’s experience of solving implementation challenges (especially in Indian PSU environments)

e) Proposed project plan and approach taken to address implementation challenges

These aspects would be cross checked through evaluation of responses from reference site visits and

project team experience evaluation to be done in bid presentations.

Technically qualified Bidders will be shortlisted based on the following criteria:

Bidders scoring at least 85% in both the Credit Risk Management and Operational Risk Management in

the technical-b id evaluation will be short‐listed for commercial evaluation.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

66

For qualification in technical-bid:

a) Bidder will have to score at least 85% (out of 850 marks in each risk) in both credit risk and

operational risk management for functional requirements. Functional requirements here also

include marks for product presentation, past experience and team profile.

AND

b) Bidder will have to score at least 85% (out of 150 marks in each risk) in both credit risk and

operational risk management for technical requirements.

Bidder scoring as per criteria in para (a) and (b) both above; will be a qualified bidder for the

purpose of commercial evaluation.

Bidder will have to score as per above criteria for both operational risk and credit risk. Bidder who

scores as per above criteria only in one risk will not be a qualified bidder for commercial

evaluation.

However, in case there are less than 3 Bidders who score 85% or above, the Bank may, at its discretion,

choose the top 3 scoring Bidders.

4.3.6 Commercial Evaluation Process

The Bids which are qualified in Technical Section – 4.3.5 would be considered for Commercial Bid

evaluation. The vendor should furnish their price for the project in their Commercial Bid to facilitate the

commercial evaluation process.

ONLY technically qualified bidder will be eligible for commercial bid evaluation.

Computation Methodology for Commercial Score

The Relative Commercial Score (RCS) for each shortlisted Consultant will be calculated as given below:

RCS = L1 / L * 100

Where,

RCS: Relative Commercial Score

L: Amount quoted by the current proposal


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

67

L1: Lowest Amount quoted by lowest quoted (L1) proposal

4.3.7 Evaluation Criteria ‐ Overall

The final selection of a Bidder will be based on the outcome of the Commercial Evaluation process for the

qualified bidders in the Technical Bid round.

The Relative Commercial Score (RCS) will be assigned the rank as follows:

Illustrative Only

Sr. No Bidders Commercial Bid Amount (Rs.) Relative Commercial Score (RCS) Ranking

1 A 70,000 71.43 L2

2 B 50,000 100 L1

3 C 90,000 55.56 L3

In the above example, all three bidders A, B and C are technically qualified and bidder B has the highest

relative Commercial Score (RCS), hence bidder B will be selected.

Bank reserves the right to select the next ranked Bidder if the selected Bidder withdraws his proposal after

selection or at the time of finalization of the contract or disqualified on detection of wrong or misleading

information in the proposal


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

68

5. Other Terms & Conditions

5.1 Indemnity

1. The Bidder shall indemnify the Bank, and shall always keep indemnified and hold the Bank, its

employees, personnel, officers, directors, harmless from and against any and all losses, liabilities,

claims, actions, costs and expenses (including attorney’s fees) relating to, resulting directly or

indirectly from or in any way arising out of any claim, suit or proceeding brought against the Bank as a

result of:

i. Bank’s authorized / bona fide use of the Deliverables and/or the Services provided by Bidder under this RFP or any or all terms and conditions stipulated in the SLA(Service level Agreement or PO; and/or

ii. An act or omission of the Bidder, employees, agents, sub-contractors in the performance of the

obligations of the Bidder under this RFP or, any or all terms and conditions stipulated in the SLA(Service level Agreement or PO; and/or

iii. Claims made by employees or subcontractors or subcontractors’ employees, who are deployed by the Bidder, against the Bank; and/or

iv. Breach of any of the term of this RFP or breach of any representation or false representation or inaccurate statement or assurance or covenant or warranty of the Bidder under this RFP or; any or all terms and conditions stipulated in the SLA(Service level Agreement or PO; and/or

v. Any or all Deliverables or Services infringing any patent, trademarks, copyrights or such other Intellectual Property Rights; and/or

vi. Breach of confidentiality obligations of the Bidder contained in this RFP or; any or all terms and conditions stipulated in the SLA(Service level Agreement or PO; and/or

vii. Negligence or gross misconduct attributable to the Bidder or its employees, agent or sub‐contractors.

2. The Bidder will have to at its own cost and expenses defend or settle any claim against the Bank that

the Deliverables and Services delivered or provided under this RFP infringe a patent, utility model,

industrial design, copyright, trade secret, mask work or trade mark in the country where the Deliverables

and Services are used, sold or received, provided the Bank:

i. Notifies the Bidder in writing; and

ii. Cooperates with the Bidder in the defense and settlement of the claims.

3. The Vendor shall compensate the Bank for such direct financial loss suffered by the Bank if the Vendor


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

69

fails to fix bugs, provide the Modifications / Enhancements / Customization as required by the Bank as

per the terms and conditions of this RFP and to meet the Service Levels as per satisfaction of the Bank.

4. Additionally, the Vendor shall indemnify, protect and save the Bank against all claims, losses, costs,

damages, expenses, action, suits and other proceedings,

(i) that the Deliverables and Services delivered or provided under this Agreement infringe a patent,

utility model, industrial design, copyright, trade secret, mask work or trademark in any country where

the Deliverables and Services are used, sold or received; and/or (ii) resulting from infringement of any

patent, trade-marks, copyrights etc. or such other statutory infringements under any laws including the

Copyright Act,1957 or Information Technology Act, 2000 or any Law, rules, regulation, bylaws,

notification time being enforced in respect of all the Hardware, Software and network equipment or

other systems supplied by them to the Bank from whatsoever source, provided the Bank notifies the

Vendor in writing as soon as practicable when the Bank becomes aware of the claim however:

a) the Vendor has sole control of the defense and all related settlement negotiations. b) the Bank provide the Vendor with the assistance, information and authority reasonably necessary

to perform the above and c) Vendor aware the rights to make any statements or comments or representations about the claim

by Bank or any regulatory authority. Indemnity would be limited to court or arbitration awarded damages and shall exclude indirect, consequential and incidental damages and compensations.

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

incidental damages. However indemnity would also cover damages, loss or liabilities, compensation

suffered by the Bank arising out of claims made by regulatory authorities.

6. The Bank do hereby indemnify the Vendor, and should keep indemnified and hold the Vendor harmless

from and against any and all losses, liabilities, claims, actions, costs and expenses (including reasonable

attorneys' fees) relating to, resulting directly from or in any way arising out of any claim, suit or

proceeding brought by third-parties against the Vendor as a result of:

a) third party infringement claims resulting from unauthorized equipment modification by the Bank

or equipment use prohibited by Specifications for Hardware and Software; b) third-party infringement claims resulting from a breach of Software license terms by the Bank in

respect of Software directly supplied by the Vendor.

7. The Bidder / vendor will not be liable for defects or non‐conformance resulting from Bank’s failure to

comply with any mutually agreed environmental specifications:

8. The total liability of the selected Bidder / vendor under the contract shall not exceed total cost of the

project / agreement.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

70

5.2 Penalty

The Bank expects the Vendor to complete the scope of the project as mentioned in 1.2 Broad Scope of Work of this document and in details mentioned in Functional Specifications within the timeframe specified in Project Timelines of this document. Inability of the Vendor to either provide the requirements as per the scope or to meet the timelines as specified would be treated as breach of contract and would invoke the penalty clause. The proposed rate of penalty shall be 1 % of the value of the affected service or product per week or part thereof, of delay or non-compliance subject to an upper limit of 10% of value of affected services or product. Notwithstanding anything contained in this agreement overall cap for all penalties under this agreement shall be limited to the contract value of the Agreement

For example, if the Vendor is not able to supply a server at DC or the supplied server requires some

more parts for its functioning, then the penalty levied will be 1% of the cost of “That server” per week or

part thereof, of delay.

Inability of the Vendor to provide services at the service levels defined would result in breach of contract

and shall invoke the penalty clause as mentioned in – Service Levels.

Notwithstanding anything contained above, no such penalty will be chargeable on the Vendor for the inability occasioned, if such inability is due to reasons entirely attributable to The Bank.

If the maximum amount that may be levied by way of penalty shall exceed 10 % of the Total Contract

value, the Bank reserve the rights-either cancel the contract or to accept the performance subject to this

Agreement. If any act or failure by the Bidder/Vendor under the agreement results in failure or inoperability of

systems and if The Bank has to take corrective actions to ensure functionality of its property, The

Bank reserves the right to impose penalty, which may be equal to the cost it incurs or the loss it suffers

for such failures.

The Bank plans to impose penalty to the extent of damage to its any equipment, if the damage was due

to the actions directly attributable to the any staff/contractor of Bidder/vendor.

The Bank shall implement all penalty clauses after giving due written notice to the Bidder/vendor.

If the Bidder/vendor fails to complete the due performance of the contract in accordance with the

specification and conditions of the offer document, The Bank reserves the right either to cancel the

order / agreement or to recover a suitable amount as deemed reasonable as Penalty / Liquidated

Damage for nonperformance.

Penalties, if any shall be calculated for every month and will be deducted / adjusted in subsequent

invoices from the vendor.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

71

The right to invoke the penalty clause is in addition to and without prejudice to other right available to

the Bank such as termination of contract, invocation of indemnity and recovery of amount paid etc.

Failure to maintain uptime SLA will attract penalty as given in Section 3.1.9: Liquidated Damages.

5.3 Insurance

The equipment (hardware, software etc.) supplied under the contract shall be fully insured by the successful

Bidder against loss or damage incidental to manufacture or acquisition, transportation, storage, delivery

and installation. The insurance shall be obtained by the Bidder naming Central Bank of India as the

beneficiary, for an amount Equal to 100% of the invoiced value of the goods on “all risks" basis. The

period of insurance shall be up to the date the supplied components are accepted and the all rights of the

property are transferred to the Bank in the Bank’s premises.

Should any loss or damage occur, the selected Bidder shall: ‐

i. initiate and pursue claim till settlement and

ii. Promptly make arrangements for repair and / or replacement of any damaged item irrespective of settlement of claim by the underwriters.

5.4 Inspection & Tests

a. Bank shall have the right to inspect and / or test the goods to check their conformity to the contract

specifications at no extra cost to the purchaser.

b. The inspection and test may be done on the premises of the supplier or at the point of delivery.

5.5 Warranty

The offer must include comprehensive on‐site warranty of 3 year from the date of go live of complete

solution for Integrated Risk Management system. Bidder must provide warranty for all equipment,

accessories etc.

5.6 Delivery of servers – period

The goods are to be delivered within 8 weeks from the date of acceptance of purchase order.

5.7 AMC price Validity

The prices finalized shall remain valid for six months from the date of purchase order. However, AMC

price will remain valid for 3 years post warranty period. AMC cost should be clearly further bifurcated into

license cost, maintenance of hardware, etc.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

72

5.8 Duty free Credit Scrips

Bank has received Duty Free Credit Scrips (DFCS) issued by Directorate General of Foreign Trade, Government of India against eligible Forex earnings by the BANK. The same can be utilized for import / purchase of any capital goods, office equipment office furniture etc. towards payment of Custom Duty / Excise Duty.

Bank will issue the DFCS to set off the Excise Duty/ Customs Duty which must be acceptable to the SP / Vendor. While preparing the Bills/ Invoices, the excise Duty/ Customs Duty components, if any, must be mentioned separately and the Duty Free Credit Scrips must be acceptable by the SP / Vendor towards the payment

5.9 Vendor’s liability

The Vendors aggregate liability in connection with obligations undertaken as a part of the project regardless of the form or nature of the action giving rise to such liability (whether in contract, tort or otherwise), shall be at actuals and limited to the value of the contract. The Vendors liability in case of claims against the Bank resulting from misconduct or gross negligence of the Vendor, its employees and subcontractors or from infringement of patents, trademarks, copyrights or such other Intellectual Property Rights or breach of confidentiality obligations shall be unlimited. The Bank shall not be held liable for and is absolved of any responsibility or claim/litigation arising out of the use of any third party software or modules supplied by the Vendor as part of this RFP. In no event shall the Bank be liable for any indirect, incidental or consequential damages or liability, under or in connection with or arising out of this tender and subsequent agreement or the hardware or the software delivered hereunder, howsoever such liability may arise, provided that the claims against customers, users and service providers of the Bank would be considered as a direct claim. The vendor should ensure that the due diligence and verification of antecedents of employees/personnel deployed by him for execution of this contract are completed and is available for scrutiny by the Bank

5.10 Change Management

Post implementation, rate of any change request in terms of man days to be specified clearly, cost of 100 such man days will be part of offered TCO. Bank will pay on actual man-days basis.

5.11 Product Version

All relevant product versions and/or identifications to be mentioned in technical bid

5.12 Independent Contractor:

Nothing herein contained will be construed to imply a joint venture, partnership, principal-agent relationship

or co-employment or joint employment between the Bank and Vendor. Vendor, in furnishing services to the

Bank hereunder, is acting only as an independent contractor. Vendor does not undertake by this Agreement

or otherwise to perform any obligation of the Bank, whether regulatory or contractual, or to assume any


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

73

responsibility for the Bank’s business or operations. The parties agree that, to the fullest extent permitted by

applicable law; Vendor has not, and is not, assuming any duty or obligation that the Bank may owe to its

customers or any other person. The vendor shall follow all the rules, regulations statutes and local laws and

shall not commit breach of any such applicable laws, regulations etc.

In respect of sub-contracts, as applicable – If required by the Vendors, should provide complete details of any

subcontractor/s used for the purpose of this engagement. It is clarified that notwithstanding the use of sub-

contractors by the Vendor, the Vendor shall be solely responsible for performance of all obligations under

the SLA/NDA irrespective of the failure or inability of the subcontractor chosen by the Vendor to perform its

obligations. The Vendor shall also have the responsibility for payment of all dues and contributions, as

applicable, towards statutory benefits including labour laws for its employees and sub-contractors or as the

case may be. Vendor should take bank’s prior written permission before sub-contracting / resource

outsourcing of any work related to the performance of this RFP or as the case may be.

5.13 Escrow Mechanism

The Bank and the Vendor shall agree to appoint an escrow agent to provide escrow mechanism for the

deposit of the source code for the Complete Solution for Operational Risk and Credit Risk, and all the 3rd

party applications supplied/procured by the Vendor to the Bank in order to protect its interests in an

eventual situation. In case of a disagreement between the Bank and the Vendor regarding appointment of an

escrow agent, the Bank shall appoint an escrow agent in its entire discretion which shall be final and binding

on the Vendor.

The Bank and the Vendor shall enter into a tripartite escrow agreement with the designated escrow agent,

which will set out, inter alia, the events of the release of the source code and the obligations of the escrow

agent. Costs for the Escrow will be borne by the Vendor. As a part of the escrow arrangement, the final

selected Vendor is also expected to provide a detailed code documentation of the Complete Solution for

Operational Risk and Credit Risk, and all other 3rd party applications which have been duly reviewed by an

external independent organization. The Escrow will be released to and become the property of the Bank in

the event that the agreement is terminated for either default or insolvency or amalgamation or should the

vendor cease, or give notice of intention to cease to provide maintenance or technical support service for the

solution as required by the agreement.

5.14 Confidentiality

“Confidential Information” means any and all information that is or has been received by the Vendor

(“Receiving Party”) from the Bank (“Disclosing Party”) and that: relates to the Disclosing Party; and is

designated by the Disclosing Party as being confidential or is disclosed in circumstances where the Receiving

Party would reasonably understand that the disclosed information would be confidential or is prepared or

performed by or on behalf of the Disclosing Party by its employees, officers, directors, agents,

representatives or consultants.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

74

Without limiting the generality of the foregoing, Confidential Information shall mean and include any

information, data, analysis, compilations, notes, extracts, materials, reports, drawings, designs, specifications,

graphs, layouts, plans, charts, studies, memoranda or other documents, or materials relating to the licensed

software, the modules, the program documentation, the source codes, the object codes and all

enhancements and updates, services, systems processes, ideas, concepts, formulas, methods, know how,

trade secrets, designs, research, inventions , techniques, processes, algorithms, schematics, testing

procedures, software design and architecture, computer code, internal documentation, design and function

specifications, product requirements, problem reports, analysis and performance information, business

affairs, projects, technology, finances (including revenue

projections, cost summaries, pricing formula), clientele, markets, marketing and sales programs, client and

customer data, appraisal mechanisms, planning processes etc. or any existing or future plans, forecasts or

strategies in respect thereof.

“Confidential Materials” shall mean all tangible materials containing Confidential Information, including,

without limitation, written or printed documents and computer disks or tapes, whether machine or user

readable. Information disclosed pursuant to this clause will be subject to confidentiality for the term of

contract plus two years.

Nothing contained in this clause shall limit Vendor from providing similar services to any third parties or

reusing the skills, know-how and experience gained by the employees in providing the services, subject to

strict confidential obligation, contemplated under this clause, provided further that the Vendor shall at no

point use the Bank’s confidential information or Intellectual property.

5.1.14.1 The Vendor Party shall, at all times regard, preserve, maintain and keep as secret and confidential all

Confidential Information and Confidential Materials of the Disclosing Party howsoever obtained and agrees

that it shall not, without obtaining the written consent of the Bank.

5.1.14.2 Disclose, transmit, reproduce or make available any such Confidential Information and materials to

any person, firm, Company or any other entity other than its directors, partners, advisers, agents or

employees, sub-contractors and contractors who need to know the same for the purposes of maintaining and

supporting the Software provided as a part of centralized Banking Project. The Receiving Party shall be

responsible for ensuring that the usage and confidentiality by its directors, partners, advisers, agents or

employees, sub-contractors and contractors is in accordance with the terms and conditions and requirements

of this tender; or

5.1.14.3 Unless otherwise agreed herein, use of any such Confidential Information and materials for its own

benefit or the benefit of others or do anything prejudicial to the interests of the Disclosing Party / Bank or its

customers or their projects.

5.1.14.4 In maintaining confidentiality hereunder the Receiving Party / Vendor on receiving the confidential

information and materials agrees and warrants that it shall:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

75

Take at least the same degree of care in safeguarding such Confidential Information and materials as it

takes for its own confidential information of like importance and such degree of care shall be at least,

that which is reasonably calculated to prevent such inadvertent disclosure

Keep the Confidential Information and Confidential Materials and any copies thereof secure and in

such a way so as to prevent unauthorised access by any third party

Limit access to such Confidential Information and materials to those of its directors, partners, advisers,

agents or employees, sub-contractors and contractors who are directly involved in the

consideration/evaluation of the Confidential Information and bind each of its directors, partners,

advisers, agents or employees, sub-contractors and contractors so involved to protect the Confidential

Information and materials in the manner prescribed in this document

Upon discovery of any unauthorised disclosure or suspected unauthorised disclosure of Confidential

Information, promptly inform the Disclosing Party of such disclosure in writing and immediately return

to the Disclosing Party all such Information and materials, in whatsoever form, including any and all

copies thereof

The Receiving Party who receives the confidential information and materials agrees that on receipt of

a written demand from the Disclosing Party / Bank

a. Immediately return all written Confidential Information, Confidential materials and all copies

thereof provided to, or produced by it or its advisers, as the case may be, which is in Receiving

Party’s possession or under its custody and control

b. To the extent practicable, immediately destroy all analyses, compilations, notes, studies,

memoranda or other documents prepared by it or its advisers to the extent that the same

contain, reflect or derive from Confidential Information relating to the Disclosing Party

c. So far as it is practicable to do so immediately expunge any Confidential Information relating to

the Disclosing Party or its projects from any computer, word processor or other device in its

possession or under its custody and control

d. To the extent practicable, immediately furnish a certificate signed by its director or other

responsible representative confirming that to the best of his/her knowledge, information and

belief, having made all proper enquiries the requirements of this paragraph have been fully

complied with

e. The rights in and to the data / information residing at the Bank’s premises, including at the DRC

even in the event of disputes shall at all times solely vest with the Bank

f. The Vendor represents and agrees that during the Term of this RFP or until the Bank takes over

the Deliverables from the Vendor, whichever is earlier, the Bank shall not be responsible for any

loss/damage (including malfunctioning or non-functioning of Deliverables) caused to the

Deliverables for any reason, unless such loss/damage (including malfunctioning or non-functioning

of Deliverables) is caused due to the willful act or gross misconduct of the Bank or any of its

personnel as certified jointly by the Project Directors of the Parties. In such an event, the Vendor

shall promptly repair and/or replace the non-performing Deliverable with a suitable replacement,

if required, without affecting the service level standards in this RFP without any additional cost to

the Bank.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

76

The restrictions in the preceding clause shall not apply to:

a. Any information that is publicly available at the time of its disclosure or becomes publicly available

following disclosure (other than as a result of disclosure by the Disclosing Party / Bank contrary to

the terms of this document); or any information which is independently developed by the

Receiving Party / Vendor or acquired from a third party to the extent it is acquired with the valid

right to disclose the same

b. Any disclosure required by law or by any court of competent jurisdiction, the rules and regulations

of any recognised stock exchange or any enquiry or investigation by any governmental, statutory

or regulatory body which is lawfully entitled to require any such disclosure provided that, so far as

it is lawful and practical to do so prior to such disclosure, the Receiving Party / Vendor shall

promptly notify the Disclosing Party / Bank of such requirement with a view to providing the

Disclosing Party / Bank an opportunity to obtain a protective order or to contest the disclosure or

otherwise agree to the timing and content of such disclosure

c. The Confidential Information and materials and all copies thereof, in whatsoever form shall at all

times remain the property of the Disclosing Party / Bank and its disclosure hereunder shall not

confer on the Receiving Party / Vendor any rights whatsoever beyond those contained in this

document

The confidentiality obligations shall survive the expiry or termination of the agreement between the Vendor

and the Bank. The Vendor shall execute NDA (Non-disclosure Agreement) with Bank as format shared

provided in this RFP.

The Vendor shall be fully responsible for any breach of data confidentiality of customer related information.

This liability shall be applicable even after the contract expires or gets terminated.

The vendor shall provide a non-disclosure and integrity pact

5.15 Intellectual property rights

The Vendor claims and represents that it has obtained appropriate rights to provide the Deliverables upon

the terms and conditions contained in this RFP. The Bank agrees and acknowledges that save as expressly

provided in this RFP, all Intellectual Property Rights in relation to the Software and Documentation and any

adaptations, translations and derivative works thereof whether protectable as a copyright, trade mark,

patent, trade secret design or otherwise, provided by the Vendor during, in connection with or in relation to

fulfilling its obligations under this RFP belong to and shall remain a property of the Vendor or its licensor.

The Vendor represents that a separate RFP is required to be entered into by the Bank with Third-party

Vendors either for statutory or proprietary reasons, notwithstanding the Vendor’s obligations for

performance.

During the Term of this Project and, if applicable, during the Reverse Transition Period, Bank grants Vendor a

right to use at no cost or charge the Software licensed to the Bank, solely for the purpose of providing the

Services.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

77

The Vendor shall be responsible for obtaining all necessary authorizations and consents from third party

licensors of Software used by Vendor in performing its obligations under this Project.

If a third party's claim endangers or disrupts the Bank’s use of the Software, the Vendor shall at no further

expense, charge, fees or costs to the Bank, (i) obtain a license so that the Bank may continue use of the

Software in accordance with the terms of this tender and subsequent Agreement and the

license agreement; or (ii) modify the Software without affecting the functionality of the Software in any

manner so as to avoid the infringement; or (iii) replace the Software with a compatible, functionally

equivalent and non-infringing product.

All third party software / service provided by the bidder in the scope of the RFP will be the responsibility of

the bidder.

5.16 Violation of terms

The Bank clarifies that the Bank shall be entitled to an injunction, restraining order, right for recovery, specific

performance or such other equitable relief as a court of competent jurisdiction may deem necessary or

appropriate to restrain the Vendor from committing any violation or enforce the performance of the

covenants, obligations and representations contained in this RFP. These injunctive remedies are cumulative

and are in addition to any other rights and remedies the Bank may have at law or in equity, including without

limitation a right for recovery of any amounts and related costs and a right for damages.

5.17 Statutory and Regulatory Requirements

The solution must comply with all applicable requirements defined by any regulatory, statutory or legal body which shall include but not be limited to RBI or other Regulatory Authority, judicial courts in India and as of the date of execution of Agreement. This requirement shall supersede the responses provided by the Vendor in the technical response. During the period of warranty / AMC, Bidder / Vendor should comply with all requirements including any or all reports without any additional cost, defined by any regulatory authority time to time and which fall under the scope of this RFP / Agreement. All mandatory requirements by regulatory / statutory bodies will be provided by the bidder under change management at no extra cost to the bank during the tenure of the 7 year contract.

5.18 Visitorial Rights

The Bank and its authorized representatives reserve the right to visit any of the Vendor’s premises without

prior notice to ensure that data provided by the Bank is not misused. The Vendor shall cooperate with the

authorized representative/s of the Bank and shall provide all information/ documents required by the Bank.

5.19 Technological advancements

The Vendor shall take reasonable and suitable action, taking into account economic circumstances, at

mutually agreed increase / decrease in charges, and the Service Levels, to provide the Services to the Bank at


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

78

a technological level that will enable the Bank to take advantage of technological advancement in the

industry from time to time.

5.20 Taxes

The consolidated fees and charges required to be paid by the Bank against each of the specified components

under this Agreement shall be all-inclusive amount with currently applicable taxes. The Vendor shall provide

the details of the taxes applicable in the invoices that shall be raised on the Bank. Accordingly, the Bank shall

deduct at source, all applicable taxes from the payments due/ payments to vendor which includes TDS. The

service tax shall be paid by the vendor to the concerned authorities.

In case of any variation (upward or down ward) in Government levies / taxes / VAT/cess / excise / custom

duty etc. up-to the date of providing services , the benefit or burden of the same shall be passed on or

adjusted to the Bank. If the Vendor makes any conditional or vague offers, without conforming to these

guidelines, the Bank will treat the prices quoted as in conformity with these guidelines and proceed

accordingly. Local entry taxes or octroi whichever is applicable, if any, will be paid by the Bank on production

of relative payment receipts / documents. Necessary documentary evidence should be produced for having

paid the customs / excise duty, sales tax, if applicable, and or other applicable levies. “Variation” would also

include the introduction of any new tax /cess /excise.

If any Tax authorities of any state, including, Local authorities like Corporation, Municipality etc. or any Government authority or Statutory or autonomous or such other authority imposes any tax, charge or levy or any cess / charge other than entry tax or octroi and if the Bank has to pay the same for any of the items or supplies made here under by the Vendor, for any reason including the delay or failure or inability of the Vendor to make payment for the same, the Bank has to be reimbursed such amounts paid, on being intimated to the Vendor along with the documentary evidence. If the Vendor does not reimburse the amount within a fortnight, the Bank shall adjust the amount out of the payments due to the Vendor from the Bank along with the interest calculated at commercial rate.

Privacy and security safeguards

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

ii. The Vendor hereby agrees and confirms that they will disclose, forthwith, instances of security breaches.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

79

iii. The Vendor hereby agrees that they will preserve the documents and data in accordance with the legal/regulatory obligation of the Bank in this regard.

5.21 Survival

Any provision or covenant of this RFP/Agreement, which expressly, or by its nature, imposes obligations

beyond the expiration, or termination, shall so survive after termination or expiration.

5.22 Inspection, Audit & Visitations

Right to Inspect, Examine and Audit: All OEM/Vendor records with respect to any matters / issues covered under the scope of this RFP shall be made available to the Bank at any time during normal business hours, as often as the Bank deems necessary, to audit, examine, and make excerpts or transcripts of all relevant data. Such records are subject to examination. The Bank’s auditors would execute confidentiality agreement with the Vendor, provided that the auditors would be permitted to submit their findings to the Bank, which would be used by the Bank. The cost of such audit will be borne by the Bank. The scope of such audit would be limited to Service Levels covered under this RFP, and financial information would be excluded from such inspection, which will be subject to the requirements of statutory and regulatory authorities. The OEM/Vendor’s records and sites managed for the Bank shall also be subject to RBI inspection and audit. Vendor shall permit audit by internal/external auditors of the Bank or RBI to assess the adequacy of risk management practices adopted in overseeing and managing the outsourced activity/arrangement made by the Bank. Monitoring Compliance with Information security best practices may be monitored by periodic Information security audits performed by or on behalf of the Bank and by the RBI. The periodicity of these audits will be decided at the discretion of the Bank. These audits may include, but are not limited to, a review of: access and authorization procedures, physical security controls, backup and recovery procedures, network security controls and program change controls. To the extent that the Bank deems it necessary to carry out a program of inspection and audit to safeguard against threats and hazards to the confidentiality, integrity, and availability of data, the Vendor shall afford the Bank’s representatives access to the Vendor’s facilities, installations, technical resources, operations, documentation, records, databases and personnel. The Vendor must provide the Bank access to various monitoring and performance measurement systems (both manual and automated). The Bank has the right to get the monitoring and performance measurement systems (both manual and automated) audited without prior approval / notice to the Vendor.

Visitations The Bank shall be entitled to, either by itself or its authorized representative, visit any of the Vendor’s premises without prior notice to ensure that data provided by the Bank is not misused. The Vendor shall cooperate with the authorized representative(s) of the Bank and shall provide all information/ documents required by the Bank.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

80

5.23 Change Request

Any requirement beyond RFP will be processed as change request as per prevalent standard change request process of the Bank. However no additional cost would be payable for change request suggested by Statutory Authority/Regulatory Authority.

5.24 Compliance with Laws

1. Compliance with all applicable laws: Vendor shall undertake to observe, adhere to, abide by,

comply with and notify the Bank about all laws in force or as are or as made applicable in future,

pertaining to or applicable to them, their business, their employees or their obligations towards

them and all purposes of this scope of work and shall indemnify, keep indemnified, hold harmless,

defend and protect the Bank and its employees/officers/staff/ personnel/representatives/agents

from any failure or omission on its part to do so and against all claims or demands of liability and all

consequences that may occur or arise for any default or failure on its part to conform or comply

with the above and all other statutory obligations arising there from.

2. Compliance in obtaining approvals/permissions/licenses: Vendor shall promptly and timely obtain

all such consents, permissions, approvals, licenses, etc., as may be necessary or required for any of

the purposes of this project or for the conduct of their own business under any applicable Law,

Government Regulation/Guidelines and shall keep the same valid and in force during the term of

the project, and in the event of any failure or omission to do so, shall indemnify, keep indemnified,

hold harmless, defend, protect and fully compensate the Bank and its employees/ officers/ staff/

personnel/ representatives/agents from and against all claims or demands of liability and all

consequences that may occur or arise for any default or failure on its part to conform or comply

with the above and all other statutory obligations arising there from and the Bank will give notice

of any such claim or demand of liability within reasonable time to Company.

3. This indemnification is only a remedy for the Bank. Vendor is not absolved from its responsibility of

complying with the statutory obligations as specified above.

5.25 Assignment

Bank may assign the Project and the solution and services provided therein by Vendor in whole or as part of

a corporate reorganization, consolidation, merger, or sale of substantially all of its assets. The Bank shall

have the right to assign such portion of the facilities management services to any of the sub-contractors, at

its sole option, upon the occurrence of the following: (i) Vendor refuses to perform; (ii) Vendor is unable to

perform; (iii) termination of the contract with Vendor for any reason whatsoever; (iv) expiry of the

contract.

Such right shall be without prejudice to the rights and remedies, which the Bank may have against Vendor.

Vendor shall ensure that the said subcontractors shall agree to provide such services to the Bank at no less

favorable terms than that provided by Vendor and shall include appropriate wordings to this effect in the

agreement entered into by Vendor with such sub-contractors. The assignment envisaged in this scenario is

only in certain extreme events such as refusal or inability of Vendor to perform or termination/expiry of the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

81

contract.

5.26 Publicity

Any publicity by either party in which the name of the other party is to be used should be done only with

the explicit written permission of such other party.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

82

6. Scope of Work for Operational Risk Management

Operational Risk Management and Measurement System offered under this RFP should comply with all the conditions mentioned below including functional and technical requirements.

The scope of Operational Risk Management System should include but not limited to:

i. Supply, installation, customization, configuration, parameterization, implementation,

documentation, maintenance / support and training of an Operational Risk Management System (ORMS) in the Bank as per the scope, implementation, functional and technical requirements as given in this RFP.

ii. Development of AMA models and validation iii. Generation of reports as per regulatory guidelines and MIS iv. Provide required data / information as provided in the scope of this RFP v. Impart hands on training to the officials identified by the Bank in using and maintaining the

solution & Database Administration. System should be able to implement all the components of bank’s operational risk management and measurement framework at solo and group wide level in compliance with applicable RBI and Basel II / Basel III requirements for advanced measurement approach (AMA). If there is any change in regulatory such as RBI / Basel II / Basel III guidelines and in bank’s ORM framework, system should be able to comply with those changes including required customization to be done in the system and implemented by the system vendor. Bank will provide relevant requirements and related clarifications to the vendor if required. Vendor will do at no extra cost to the bank. If there is any version upgrade of the system, vendor will provide to the bank at no extra cost to the bank. The capabilities of the Operational Risk Management System should include but not limited to:

i. To comply with RBI and Basel II / Basel III requirements for AMA approach for operational risk including both qualitative and quantitative requirements and subsequent guidelines prescribed by RBI / BCBS, in future, if any.

ii. System should support full as well as partial roll-out, if bank decides to do so, as allowed under regulatory requirements

iii. Configuration and parameterization of system for bank’s legal entities, internal governance / o r g a n i z a t i o n structure, product, process, risk entities, systems and other dimensions which are required for the management and measurement of operational risk including their inter-relations and mapping such as on parent-child / tree structure.

iv. Configuration and implementation of bank’s RCSA framework including planning, scheduling, identification, assessment, consolidation and reporting including workflow, validation and approval process.

v. Support of RCSA approach as adopted by the way and the mechanism in which implemented by the bank. The interpretation of the bank with respect to RCSA approaches such as risk based, questionnaire based and hybrid approach shall be final. Since there is no single consensus on the definition of approach of RCSA hence approach as per bank’s framework has to be implemented by whatever nomenclature it is called.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

83

vi. Risk and Control Data Library as a single repository for capturing bank wide operational risks and controls and mapping thereof at various dimensions such as risk entity, business line, loss event type, process, product, system, risk drivers, location, legal entity, vendor, control type (preventive / detective), control frequency, control mode (automated, manual) etc.

vii. Implementation of Key Risk Indicators framework a s to its identification, definition, assignment, calculation, threshold / triggers, monitoring, reporting and Indexing.

viii. KRI Library as a single repository for capturing bank wide KRIs and mapping thereof at various dimensions such as loss event type, risk entity, business line, process, product, system, risk drivers, location, legal entity, or any other applicable dimension(s) etc.

ix. Internal and external loss data management capturing all the information for the management and measurement of operational risk including configuration of workflow and requirements for data validation, approval, scaling, filtering and adjustment.

x. External loss data library as a single repository which are relevant to the Business and Risk Profile and Indian Banking Jurisdiction. External loss data shall be duly mapped to all the dimensions and required information so as to enable AMA modelling and improving internal control environment.

xi. External Loss Data so provided shall be stored in the system and user should be able to see at the front end of the system and should be able to download it.

xii. Implementation of Scenario analysis framework and its use in the capital quantification process.

xiii. Scenario data library mapped to all required dimensions as per business and risk profile of the bank, relevant to Indian banking jurisdiction, having all the information for AMA modelling purpose.

xiv. Business Environment and Internal Control Factors (BEICF): their definition and use in the capital

quantification process including approach for identification, measurement and use in AMA

modelling

xv. Risk and Control, KRI, Scenario, External Loss Data – all will be provided by the vendor with the

mapping with the relevant dimensions as required for AMA modelling and operational risk

management

xvi. Operational Risk Capital Calculation as per AMA approach including loss data threshold

modeling, determining operational risk categories (ORCs), determining appropriate mix of four

elements i.e. internal data, relevant external operational risk data, scenario analysis, and BEICFs,

loss frequency; severity & aggregate distribution, goodness of fit test, correlation modeling,

diversification benefit modeling, insurance as risk mitigant, sensitivity analysis, back testing, stress

testing, model validation and reporting of results etc.

xvii. To provide and support the validation techniques including identifying and justifying the

assumptions as well as evaluate the AMA model’s sensitivity to these assumptions.

xviii. Analysis of results of operational risk management and measurement processes.

xix. Regulatory as well as Management Reporting for all the stakeholders in the bank including

flexibility of creation of new reports by the vendor, customization / configuration of reports as

required by the bank. Report should be of all types such as graphical, tabular, dash-board, heat

map with drill down capability to the most granular level.

xx. Bank will require ad-hoc reports other than standard configured reports which vendor will create

in the system, if already not available, at no extra cost to the bank. Bank will only provide reporting

requirements to the vendor for ah-hoc reports.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

84

xxi. Administration of the module in terms of access to the system as per job profile of the employee

with function specific controls.

xxii. Ability of the system to be interfaced with bank’s source system, staging area and data warehouse

in an automated manner.

xxiii. Flexibility to upload the data into the system such as loss event, KRI, risk and controls using Bank

provided templates etc.

xxiv. Configuration of templates into the system as per operational risk management framework of the

bank

xxv. Flexibility in defining and use of the scales for assessment and consolidation as per Bank’s

operational risk management framework e.g. for RCSA, KRI, Scenario Analysis

xxvi. System should be capable of doing Stress testing (including reverse stress testing) and back testing

xxvii. Compliance with bank’s system security standards

6.1 Scope for Implementation of Operational Risk Management Solution

Following will be the selected Vendor’s responsibilities for the implementation of system offered under this

RFP for Operational Risk Management. Vendor will have to submit specified deliverables under each stage

mentioned below.

A. System Installation and Creation of UAT Environment

Supply and install necessary hardware, database, operating system, and IT infrastructure necessary for

the proposed solutions. The entire IT Infrastructure for the proposed solutions would be required to be

configured and installed before commencement of UAT at the Bank’s Data Centre in Mumbai.

Deliverables

a. Sign-off by the Bank’s IT Department for successful installation of all the IT components

B. Current State Assessment and Data Gap Analysis

Understanding of bank’s operational risk management and applicable regulatory requirements is must as

selected bidder will have to implement bank’s risk management framework including all its components in

compliance with RBI / Basel II / Basel III requirements for Advanced Measurement Approach.

For implementation purpose, interpretation of RFP by the bank will be final.

To understand and assess (to the extent available):

o bank’s operational risk management governance, framework, policies and procedures, approach

& methodology, tools, models (if any), quantification approach & methodology, workflow,

reports, historical data, approval workflow, staffing, business lines, departments, organization

structure, product, processes, consolidation

o methodology for conducting RCSA, implementation of KRI and collection of loss data

o applicable RBI guidelines by RBI and BCBS for moving to AMA


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

85

o bank’s plan for moving to advanced approaches AMA with existing framework and data

o any constraint, decision and assumptions such as related to data, portfolio, business line,

process, system, geography, exemption, partial roll-out, roll-out of and AMA together etc.

o audit and regulatory queries / issues

Conduct gap analysis with system functionalities as required within the scope of this RFP and prioritize

the gaps

Conduct data gap analysis for the data requirements under IRB implementation with data available in

bank’s various source systems and manual files

Discuss and agree on the gaps and related customization requirements in the vendor system

Suggest workaround for resolution of the gaps in a time bound manner

Prepare a plan for completion of customization

Deliverables

a. Current State Understanding and Gap Assessment Report including Gaps in Bank’s Framework vis a vis

RBI AMA Requirements and recommendation for enhancements in RCSA, KRI, Loss Data, AMA Modelling,

Scenario Analysis etc. Framework

b. Data Gap Report including Recommendations / Work-around for their Resolution

c. Customization Plan including timelines

C. Review and Enhance the ORM Framework of the Bank

Vendor will review and enhance bank’s OR framework as per AMA requirements of RBI / Basel II / Basel III

guidelines which would include:

Assist in enhancements of ORM framework basis the bank’s implementation experience, regulatory

queries, audit observations, new regulatory guidelines, development in business environment, and

leading practices. Review will include:

o Operational Risk Management Governance and Policy

o RCSA Framework

o KRI Framework

o Loss Data Management framework

o Scenario Assessment Framework

o Business Line Mapping

o Operational Risk Monitoring & Reporting framework

o Alignment of Risk Based Internal Audit framework and Operational Risk Management framework

o Use Test Framework for ORM results in business as usual such as capital computation, decision

support system, enhancing internal control environment, process improvements etc.

Refreshing the RCSA registers for all the business and support functions of the bank including review of

the risks and controls depending on the change in the processes, systems, business and regulatory


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

86

environment

Refreshing the KRIs registers for all the business and support functions of the bank including review of

the risk indicators and their thresholds depending on the change in the processes, systems, new &

emerging risks, regulatory and business environment

Facilitate development of Risk and Control Registers for material Risks that impact important business

lines, geographic locations and operations which contribute significantly to the business. Design Risk and

Control Self-assessment process along with all the accompanying templates and guides for Bank staff to

assess Risks and Controls in all products and processes of the Bank. The key business should include but

not limited to: Treasury, Retail banking, Trade finance and corporate banking, Rural/Priority sector, IT,

International Banking, Commercial Banking.

Enhance methodology/guidelines/attributes for identification of KRI in all business products and

processes.

Uploading the Risk and Control register and KRIs in the System with QA as to its completeness and

accuracy

Review of the ORM system as to compliance with bank’s ORM updated framework and highlight gaps

with recommendations for enhancements etc.

Assisting bank in RCSA planning and conducting workshop as per bank’s methodology and through

bank’s implemented system

Assist in loss data collection process such as data sourcing from the risk entities, ensuring their

classification and recording, validation & approval, reporting and analysis of the issues to decide

corrective actions

Assisting in the review of the actions plans implemented and their tracking process for closure

Assist in the reconciliation process of the loss data base with the general ledger where the operational

loss are captured and booked respectively

Review of adequacy of scenarios basis bank’s business and risk profile and general business environment

and update the scenario register.

Enhancement of scenario framework, identification of new or enhancement of existing scenarios and

conducting workshop for scenario assessment.

Review or assist in - business line mapping, GL classification, data sourcing and validation / reconciliation

Review and enhance data management and quality assurance framework as to how bank maintains data

related to ORM

Review of monitoring and reporting framework such as types of report, frequency, and content of the

report to board, board committees, ORMC, Regulator and enhance, wherever required.

Review management of non-compliance issues by ORMD

Review of the existing ORM framework for AMA including information / data, models / systems & their

current use, consolidation requirements, business units / lines to be exempted if bank plans for partial

roll-out etc.

Enhancement of AMA framework at bank and solo level as well as at group level


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

87

Deciding the approach for AMA Modelling by suitable use of existing data / input, use of qualitative

results of RCSA / KRI etc., constraints such as Scenario based, Hybrid using Scenario and Internal Loss

Data etc.

Enhancement / Development of model validation, back-testing and stress testing framework

Enhance / develop excel based AMA model (prototype) with complete documentation for internal and

external review, audit and validation. AMA model should be developed for various input availability

scenarios such as (i) only scenario based & BEICF (ii) Pre-dominantly scenarios but with inadequate

internal loss data and BEICF (iii) Pre-dominantly internal loss data and scenarios, external loss data and

BEICF ((iv) internal loss data, scenarios, external loss data and BEICF (v) (ii) Pre-dominantly scenarios but

with inadequate internal loss data, external loss data and BEICF

Configuration of the AMA proto-type on bank’s ORM system, if any i.e. bank’s AMA model will be

configured on the ORM systems so that bank can use system for capital computation

Capital computation using bank’s data on the configured system using AMA Models developed on Bank’s

data

Development of use test framework of AMA framework as well as results such as use of Capital in risk

based pricing, performance evaluation etc.

Assisting bank in preparation of AMA application to RBI including in responding queries raised by the

regulator, if any

D. System Requirement Specification Preparation (SRS)

Following are the inclusive factors to be considered by the vendor for SRS preparation:

Structure the SRS in the modules as grouped in this RFP from implementation perspective

Conduct a detailed system walk-through before SRS workshops including demo of each module with

workflow, demo of reports already configured in the system, data requirements and their templates etc.

Conduct and lead SRS workshops for requirements finalization

Document all the clarification taken from the bank and incorporate in SRS including information / data

gathered during gap assessment phase

Incorporate all the functionalities as per bank’s ORM Framework, Model, Approach, Methodology, Tools,

Data, System, Templates, Workflow, Approvals, Exceptions, Reports, Analysis, Monitoring, Sources,

Regulatory Requirements, etc.

Incorporate all the requirements of the RFP in the SRS

Consider customization plan in SRS

Consider reporting – regulatory and MIS in the SRS

Consider system security requirements as specified by the bank

Consider user access and system administration requirements as required by the bank

Discuss with the bank and agree on interface requirements

Suggest any areas which can make system implementation effective and better (acceptance of the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

88

suggestion so provided is at bank’s discretion)

Incorporate on ad-hoc reporting requirements including its mechanism and responsibility for

configuration in the system

Incorporate BCP / DRP requirements

Consider all the details taken at Current State Assessment and Gap Analysis

Bank will review SRS prepared by the system vendor and provide its comments and highlight issues for

resolution by the system vendor.

For any requirement which is part of the scope, bank’s decision will be final in terms of its interpretation and

mechanism of implementation.

SRS will be prepared by the vendor basis the enhanced ORM framework as per Section ‘C’ above

SRS will be complete on sign-off by the bank

Deliverables

a. System Requirements Specifications (SRS) which should include detailed documentation of

implementation of all the functionalities including workflows, processes, approval matrices

E. Customization / Configuration / Parameterization

Customization of the RFP requirements which the vendor has confirmed for its availability in the system

as standard but not available or confirmed as “Requires Customization”. Bank will be the final authority

to decide if requirement is available in the system or not as per its expectation.

Customization would be done as per bank’s operational risk management framework and all its

components

Requirement for customization would be identified at Gap Assessment Phase and SRS preparation phase

Vendor will complete the required customization including its testing within the planned timeframe of

implementation and testing

Customization should not delay the implementation timelines of the system

Vendor will install the pre-configured system in compliance with all the AMA requirements as per RBI

and BCBS guidelines irrespective of bank may use or may not use at the time of installation

Vendor will parameterize the system as per bank specific requirements such as master data e.g. defining

organization structure, process, product, business lines, risk entities, locations, branches, regions, zones,

and all other master data required for implementation of qualitative and quantitative requirements in

the RFP

Vendor will configure and parameterize bank’s AMA model into the system. For which bank may provide

its AMA framework in descriptive format (not a model prototype or can ask to build standard models as

per AMA requirements under different data / input situations. Responsibility for building the AMA model

basis the input data available in the bank will be of the vendor including its complete documentation.

Bank will provide the data in its own format and vendor will prepare the data into up-loadable format


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

89

Define the situations and process for change management

Vendor will conduct a detailed walk-through for customization, configuration and parameterization for

the bank

Deliverables

a. Document on Configuration and Parameterization (with relevant screen-shots). This should be bank

specific customization, configuration and parameterization and not System User Manual

b. Change Management Process for Configuration and Parameterization including matrix for areas where

change management would be required

F. Interface / ETL Building

Depending upon the current state of automation in the bank, availability of the data and feasibility & ease of

extracting the data from a particular source, bank can define one or more options for building interface such

as:

a. Directly from the Source System

b. Interface with a Staging Area

c. Interface with Data Ware-house

The Bidder will be responsible for identifying the detailed interface requirements for integrating the proposed packages to bank’s existing systems.

The Bidder will present to the Bank the interface requirements for review.

The Bidder will be responsible for developing, testing and maintaining the interfaces. In case of any subsequent change, modification or alteration to the Banks existing Application software packages, the Bank will obtain the API for such existing Application and provide the same to The Bidder for interface. The Bank has envisaged all the interfaces to be on an online secure mode with Straight through Processing. The Bidder needs to factor the same in the pricing.

Vendor will have to develop the interface with any one or combination of above

Interface design by the vendor will include to define all the logics and develop the interface

Bank will assist wherever required such as clarification on certain issues, making required infrastructure

available including approvals, involvement of bank’s IT personal wherever required

Vendor will test the interface so developed to ensure that all the required data are flowing correctly and

timely

Vendor will define the change management process including responsibilities

Take support of the OEM, in building interfaces to the said applications

The solution software should have proper interface for incorporating digital certificates, i.e. PKI-enabled.

The Bidder must ensure that all interfaces are automated with minimal or no manual intervention.

The Bidder will ensure and incorporate all necessary security and control features within the Application, operating system, data base, etc. so as to maintain integrity and confidentiality of data at all times.

The Bidder will be responsible for setting up the test environment for interface testing.

The Bidder will help / assist the Bank in preparing the test cases for the testing. Bidder shall ensure that the test cases meet all the testing requirements of the Bank.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

90

All errors, bugs, enhancements / modifications required during and after testing will be immediately resolved by the Bidder (maximum of 5 working days), and sign – off for the same will be obtained from the Bank. However workaround solution should be provided on the same day, in respect of errors and bugs affecting the functioning of the Bank.

Decision of the bank in terms of which options to use for development of interface will be final.

In case direct interface with source system is not possible, then vendor will provide ISO data templates to the

bank. Bank will extract the data in the designated template and put at a stage area for automated interface

with vendor system. Bank’s decision in this respect will be final.

Deliverables

a. Interface Development Documents (including Change Management Process and the areas where change

management would be required)

G. Data Extraction, Preparation, Validation, Migration and Reconciliation

Data extraction and its complete migration to the system is an important step in the entire process of system

implementation. Scope of data migration as per activities in this section includes historical data of the bank

currently in systems and / or manual files. Vendor will be responsible for end to end migration of historical

data. Currently Bank maintains RCSA, KRI, Loss data in MS-Excel. Bank has internal loss data in MS Excel

format for the last 8 years.

Bank has operational risk management related data manually or in the system.

Following will be responsibilities of the system vendor:

Vendor will be responsible for formulating the “Data Migration Strategy” and process documents which will have to be reviewed and signed – off by the Bank prior to commencement of the data migration exercise.

Vendor to share the data upload format with the bank on start of the project

Vendor to conduct walk-through of the data requirements with the bank

Vendor to conduct data gap analysis (under gap assessment stage), provide recommendations including work-around

Vendor to extract the data from the system in case there is interface between the source system, staging area or data warehouse, as applicable

Vendor to validate the extracted data and highlight any data deficiency such as incomplete / missing data, inaccurate data etc.

Vendor to complete the extracted the data on correction of deficiency by the bank

Vendor to suggest the work-around to deal with data deficiency such as removal of mandatory field tag to upload the available data, defining the time frame for the bank to correct the data in the system over a period of time, develop and run required scripts to correct the data as a whole such as putting some common values in all the fields etc.

Vendor to liaise, interact, develop tools, correspond etc. of current solutions to obtain the data as desired by the proposed solutions and also upload the same. The Bank will provide the available data as existing from its legacy systems/paper formats

Vendor to ensure that extracted data / manual data provided by the bank is converted into the uploadable format to the Operational Risk Management System


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

91

Vendor will be responsible to format the data as per the software / upload format required by the solution.

Vendor to convert them into uploadable format, if data is available in manual file such as excel / word etc.

Vendor to highlight deficiency in manual data to the bank and on correction by the bank, incorporate in the manual files for upload into the system

Data includes loss data, RCSA results, KRI results, scenarios, reports etc. which can be in excel / Word / PDF etc. file format

Vendor to ensure complete migration of bank’s data to the ORM system

Vendor will prepare bank’s process data by distinctly identifying them, sub-dividing them, mapping them with products / business lines / any other applicable dimensions, converting them into uploadable format and will upload into the system. A process can have sub-process, sub-sub-process followed by process activities. Bank will provide its process documentation, in as is status, for all its business areas

Vendor to ensure complete migration of bank’s data including processes as prepared above, in the system

Vendor to develop process of reconciliation of system data with the course system and implement the process on the uploaded data

Vendor to document the process of data migration including the change management process

In the event of any gaps in the field mapping reports, the same would be discussed with the Bank and the

agreed solution would be documented by the Bidder and signed off from the Bank. The Bidder would give the

Bank adequate time for the review of the agreed solution and incorporate the modifications as suggested by

the Bank.

The Bidder shall ensure that workarounds or default values moved to the production database as a result of

gaps in the field mapping are duly taken care of after successful migration to proposed solutions and the

Bank officials informed of the same in writing.

It will be the responsibility of The Bidder to convey to the Bank, at Current State Assessment and Gap

Assessment Phase, all the mandatory fields required for the functioning of the proposed applications that are

not available in the legacy systems and that needs to be obtained by the Bank.

In the event the Bank is unable to obtain all the mandatory fields as conveyed by The Bidder, The Bidder shall

suggest the most suitable workaround to the Bank. The Bidder shall document the suggested workaround

and sign-off will be obtained from the Bank for the suggested workaround.

The Bidder is expected to provide the bank with data capture utilities to capture missing data for all the

modules as would be required to capture the data. The Bidder will have to train the bank personnel to use

these utilities for them to be in a position to capture the required data.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

92

The Bidder will be responsible for uploading the data entered by the Bank through the manual data entry

screens, programs / applications.

The Bidder shall develop the data conversion programs to convert Bank’s data to proposed solution upload

format. The Bidder shall perform mock data migration tests to validate the conversion programs.

The Bidder will be responsible for assisting the Bank in conducting the acceptance testing and in verifying the

completeness and accuracy of the data migrated from the legacy applications to the proposed systems.

The Bank reserves the right “to audit” / “appoint an external auditor to audit” the process of data migration

and / or the completeness and accuracy of the data migrated during the entire exercise of data migrations.

Any gaps / discrepancy observed will be reported in writing to The Bidder, who will act upon it and resolve

the same immediately or within 5 working days from the day of reporting the same.

Deliverables

a. Data Extraction, Preparation, Validation, Migration and Reconciliation

b. Documentation of entire Data Migration including Change Management Process

c. Business Process Documentation in the System Up-loadable Format

H. Report

Vendor should ensure that all the required reports by the regulator and MIS including ad-hoc reports are

created, customized, configured and parameterized in the system including the work-flow.

Bank will test all the reports as part of the UAT. If regulatory reports are not issued by RBI then vendor will

provide them the time RBI issues the requirements for AMA approach.

The Bidder shall provide for all subsequent changes to reports as suggested by the statutory and regulatory

bodies from time to time immediately to the Bank at no additional cost to the Bank throughout the period of

the contract.

Vendor will make all above reports available at no extra cost to the bank.

Deliverables

a. Development, creation and configuration of regulatory, MIS and Ad-hoc reports into the system as no

extra cost to the bank

b. Reporting Templates


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

93

I. User Acceptance Testing

The Bank proposes to conduct a “User Acceptance Test” (“UAT”) testing for the purpose of ensuring that all the functionality requested for by the Bank is available and is functioning accurately.

The Bidder will convey to the Bank that all the customizations that are required to “Go Live”, as agreed upon and signed off by the Bank are completed and the solution is ready for testing.

The Bidder will set up a test server(s), to accommodate a minimum of 10 concurrent users and install the Applications including the customizations, parameterize it as per Bank’s requirement. The Bank expects the test environment to be available to the Bank at all times, for the purpose of testing. The Bank expects The Bidder to set up the required solutions and provide connectivity to test server at DC at the desired testing center of the Bank for the purpose of testing. The Bank shall not pay any additional amounts to The Bidder for the purpose of creating the test environment.

It will be The Bidder’s responsibility to establish connectivity of the test PC’s to the Test server for facilitating UAT. The test PCs will be provided by the Bank.

The Bidder will prepare the test plans, test calendars, test schedules (day- end, month-end etc.), test cases, defining the acceptance criteria, monitoring the testing on a day to day basis’, timely resolution of gaps, errors, bugs reported during testing and providing continuous support to the users for the UAT and acceptance testing. The acceptability rests with the Bank but the end to end support for the same will have to be provided by The Bidder. Bank will review and manage the entire UAT process to its satisfaction.

Vendor will be responsible for conducting the entire UAT under the supervision and management of the

bank.

Vendor will provide UAT Test Cases for all the module of the offered system for AMA requirements

Bank will review test cases provided by the vendor and can give its comments for modification, deletion

or addition of new test cases which vendor will do.

Final set of test cases after incorporation of bank’s review comments will be provided by the vendor

Vendor will also prepare expected results of all the UAT test cases prepared by him which will be

reviewed and approved by the bank

Bank will sign-off the test cases and expected results

Vendor will convert the test cases into UAT data for uploading and execution in the system

Vendor will conduct UAT using bank’s data as well as hypothetical data, which will be decided by the

bank

Vendor will prepare UAT environment and will be responsible for all the activities related to UAT

Vendor will give expected results to the bank for verification in a format and manner which can be

understood by bank’s business users

Bank will verify the results and highlight the issues / observations for vendor to analyse, troubleshoot

and resolve within the timeframe of UAT

Any deviations / discrepancies / errors observed during the testing phase will be formally reported to the

Bidder and the Bidder will have to resolve them immediately or within 2 working days

Bank will review and resolution done including its documentation

Vendor will document the entire UAT process including all the UAT issues


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

94

UAT test cases, expected results, test data, system results, issue tracker and any other UAT document

shall be prepared by the vendor in a proper manner which can be understood by any third person such

as auditor, regulator etc.

Vendor will do UAT using bank’s production data

Bank will review the complete UAT documentation prepared by the vendor and then will provide sign-off

Deliverables

a. UAT Approach, Process and Plan

b. UAT Test Cases including their Expected Results

c. UAT Data

d. UAT Results

e. Issue Tracker

f. UAT Documentation

J. System Roll-out

After successful UAT of the System, vendor will roll-out all the components of the system using bank’s data

covering the following:

Conducting 10 RCSA Workshop with the use of System and analysing results and preparing final reports

Conducting 5 KRI workshops for different business lines

Conducting 5 Scenario Workshops, one is for a selected business line and other is for bank as a whole.

Generation of the reports for all the areas above using roll-out results

AMA Modelling and Capital Computation

Vendor will conduct all the workshops above on the vendor ORM system.

Deliverables

a. 10 RCSA Workshops

b. 5 KRI Workshops

c. 5 Scenario Workshops

d. AMA Model Results including Capital Computation

e. Reports on the Workshop conducted


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

95

K. Training / Workshop and Knowledge Transfer

The Bidder will be responsible for training the Bank’s employees in the areas of implementation, operations, management, error handling etc. The Bidder needs to provide a comprehensive training methodology document and the training should at least cover the following areas:

o Functionality available in the solution o System & Application Administration at Risk Management Department

The Bidder will be responsible to train all users in the Risk Management Department of the Bank.

The Bidder must ensure that proficient personnel conduct the training. The Bidder shall ensure trainers are proficient and experienced enough in the topic of training. The Bidder should ensure that the end user training is scheduled and completed at least a week prior to the proposed solution go-live.

Provide 5 trainings to the bank personal on all the modules. This will be in addition to implementation

workshops. Estimated number of participants in each training will be between 35 to 45

In addition to the 5 trainings as mentioned above, vendor will conduct 2 Scenario Training and AMA

Modelling & Capital Computation Training to ORMD with detailed deck where all stages of modelling are

to be supported by the screen shots and with prototypes built under various situations such as only

scenarios, scenarios plus internal loss data, adequate internal loss data supported by scenarios, internal

loss data plus external loss data plus scenarios etc. All the models mentioned will be with BEICF, Risk

Mitigation, Co-relation and Diversification benefits modelling.

In addition to above, vendor will provide 2 trainings to technical and admin users. Estimated number of

participants in each training would be approximately 20

Training and workshops should include all the aspects related to AMA and should be incorporated in the

training and workshop deck

The Bank expects The Bidder to provide a detailed training schedule for the Bank’s IT Personnel and then provide training in:

o Application Management; o User Management; o Backup & Recovery Operation & management;

Training material / Presentation / Deck / Document shall be prepared by the vendor specific to bank

requirement and it should not be generic in nature.

Deliverables

a. Training Presentations / Material

b. Workshop / Training Session as specified by the Bank

L. Production Migration

To complete all the activities required to completed before migration to the production as per scope in

this RFP

Ensure that all the activities / tasks required for production migration are completed by the vendor


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

96

Deliverables

a. Documentation on Production Migration

M. System Maintenance

Perform daily maintenance activities like day – end, month end, quarter ends, and year ends, uploads,

downloads trouble shooting, problem resolution, servicing and maintenance etc.

Adhere to service levels as mentioned in the RFP

N. System Version Migrations and Regulatory Changes

Vendor to perform version migrations and updates during the period of the contract at no extra cost to

the Bank. r

Vendor will have to provide changes in the system if there are changes in the regulatory guidelines and

same are no0t supported by the system. If due to regulatory changes, system is required to be enhanced,

customized, or modified, then vendor will do for the bank at no extra cost.

O. Workshops and Handholding for Migration to AMA Approach Besides the User Training to be provided for the software, conduct training / workshops to familiarize the

ORMD staff regarding the relevant frameworks for Operational Risk Management. Conduct workshops to

sensitize representative business units / process / branch heads on the techniques for ensuring timely and

quality event reporting. Provide support for applying to RBI till accreditation for migrating to the AMA

approach is obtained from RBI.

P. Documentation Vendor to provide model documentation, detailing of statistical/mathematical models used, theory,

assumptions, empirical data used to estimate the model and the circumstances under which model will not

work along with out of time and out of sample performance test.

If bank requires any other documentation in addition to what is specifically stated in this RFP, vendor will

have to prepare and provide the same to the bank at no extra cost. Documentation may be required in

model validation purpose, stress testing, to response regulatory and audit queries, to understand system

logic etc.

Q. Other Requirements

Maintain and support the solution by providing dedicated personnel to the Integrated Risk Management

Department throughout the contract period. The dedicated personnel are to be posted at Mumbai.

Implement the solution as per the defined timelines i.e. within 12 months of signing of the agreement

with the selected bidder.

Adhere to Service Levels as mentioned in the RFP.

Garner the support of the OEM in building interfaces and during the entire implementation period to the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

97

said applications

Support the interfaces, hardware and other infrastructure at Data Centre & Disaster Recovery Centre as

proposed and provided as part of this project.

Be a single point of Contact to the Bank

The Bidder will ensure that they have the necessary infrastructure and people in place to resolve all the

gaps within the time lines agreed, for the implementation.

The Bidder shall customize all gaps observed in the Functional RFP, Product Demo, Current Systems

Study, Training and UAT and pilot rollout. The cost of customization should be included in the price bid.

The Bank will not pay any additional customization costs. The Bidder shall document all gaps observed by

the Bank at various stages of implementation including their solution and monitor and track the status of

the same though out the implementation.

In addition to above implementation requirements, following is the module wise scope of implementation

Sr. No. Implementation Requirements Bidder’s Implementation

Approach

1 General

1.1 Configuration / Parameterization of the System such as master

data and other dimensions

1.2 Workshop on Bank's Operational Risk Management Framework

1.3 Development of SRS / FRS - Mapping of Business Requirements

with System Requirements and recommendation / solution for

issues / observations on SRS

2 Loss Data Management

2.1 Configuration of Bank's loss data framework / Approach

2.2 Migration of bank's loss data to the system using bank specific

template

2.3 Assisting in building external loss data adjustment methodology

such as filters, scaling etc.

3 Risk and Control Self-assessment

3.1 Migration of Bank's existing Risk and Control Register such as

conversion of Excel based data into System Specific Template

(data enrichment as per product requirement would be Vendor's

responsibility)

3.2 Configuration of the workflow as per bank's RCSA Framework /

Approach including assessment criteria, scales, rating,

consolidation of results etc.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

98


Approach

3.3 Vendor should update the existing RCSA data of the Bank. The

bank has carried out RCSA across Retail liabilities, Retail Assets,

Treasury, IT, Rural Banking, SME Banking, International Banking,

Currency Chest, Commercial Banking. The system should be able

to store this data in its risk and control library.

3.4 Vendor should design questionnaires based on the updated

assessments

3.5 Vendor should conduct workshops for branches and units to

familiarize the questionnaires collect responses for the

questionnaires and compile the same

3.6 Migration of existing RCSA Reports to the System

3.7 Vendor based the above assessments should provide

recommendations for risk mitigation and control optimization

3.8 Vendor based the above assessments should provide

assessments on control benefits in each process

4 KRI (Key Risk Indicator)

4.1 Configuration of KRI workflow as per Bank's framework /

Approach

4.2 Define / Migrate bank's already defined KRIs

4.3 Define / Migrate bank's KRI reports i.e. data, results

4.4 Developing interface with data source

4.5 Vendor should assist in extracting past historical source data for

KRIs, carry out the required analysis and suggest thresholds

4.6 Vendor should accordingly identify data source, data format and

data transforming logic for KRI and thresholds from various

systems for automation of KRI

4.7 Vendor should provide data collection template for KRIs where

data is not available within the Bank’s systems

5 Scenario Analysis

5.1 Configuration of bank's scenario analysis framework / approach

5.2 Migration of bank's scenarios, existing pilot scenario reports such

as data, results etc.

5.3 Conducting scenario assessment workshop on sample basis

6 Capital Computation


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

99


Approach

6.1 Vendor should assist in mapping of business lines as per RBI

requirements

6.2 Vendor should carry out Bank wide Scenario Assessments and

document the Scenarios. These Scenarios should be uploaded in

the system to compute Scenario based VaR

6.3 Configuration and building the AMA Model as per Bank's

framework (primary model) such as configuration of use of a

particular statistical test

6.4 Configuration and building the alternate AMA Model i.e.

challenger model for benchmarking the above model Vendor

should provide detailed documentation of the model, which

should include the key assumptions and key sensitivities of the

model del configured based on Bank's frameworks

6.5 Vendor should carry out sensitivity testing and back testing and

report the output for various business units / bank wide results

6.6 Vendor should document the approach, rationale and

assumptions used in above computations

6.7 The Vendor should assist the Bank in putting together the

application to RBI for the AMA approach

7 Risk and Control Data Library, KRI Data Library, External Loss

Data Library, Operational Risk Scenarios, and UAT Test Cases for

the Offered ORM System under this RFP

7.1 Risk and Control Data Library:

Vendor should provide detailed Operational Risk and Control

Data Library which can be uploaded into the offered solution.

Risk and Control Data Library should:

Be designed in such a manner that it can be used as a

direct input to the bank’s RCSA framework except

validations of the risk event.

Specify number of Risk and Controls

Relevance to Indian Banking

Relevance to Bank’s portfolio and operations and support

functions

Mapping to process, product, system, compliance

standard / guidelines, outsourcing, risk type, business line,


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

100


Approach

causal factor, risk drivers, significant / non-significant etc.

and control should be mapped to its frequency, type

(preventive & detective) etc. i.e. Basel II and Bank’s

internal taxonomy

Formatting and uploading into the offered system

Ease of understanding to bank personal

Bank will review the relevance of Risk and Control Data Library to

see its validity and usability to the bank. If Risk and Control

Library provided is not as per Bank’s all portfolios and Support

Functions, Vendor will have to develop additional risks

Vendor should also specify the approximate number of risks and

controls in the proposed library as per above criteria

7.2 Key Risk Indicator Data Library:

Vendor should provide detailed KRI Library which can be

uploaded into the offered solution. KRI library should:

Be relevant to Indian Banking

Relevance to Bank’s portfolio, operations and support

functions

Mapping to all Basel dimensions plus business

dimensions such as risk type, business lines, product, etc.



Bank will review the relevance of KRI Library to see its validity

and usability to the bank. If KRI Library provided is not as per

Bank’s all portfolios and Support Functions, Vendor will have to

develop additional KRIs.

Vendor should also specify the approximate number of KRIs in

the proposed library as per above criteria.

7.3 Operational Risk Scenarios:

Vendor should provide detailed Operational Risk Scenarios which

can be uploaded into the offered solution. Scenarios should:

be relevant to Indian Banking


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

101


Approach

Relevant to Bank’s portfolio and operations

Relevance to AMA Modelling

Mapping to all Basel dimensions plus business dimensions



Bank will review the relevance of scenarios to see its validity and

usability to the bank. If the scenarios provided are not as per

Bank’s all portfolios and regulatory requirements, Vendor will

have to develop additional Scenarios.

Vendor should also specify the approximate number of scenarios

in the proposed library.

7.4 External Loss Data:

Vendor should provide detailed External Loss data which can be

uploaded into the offered solution. External Loss Data should:

be relevant to Indian Banking

relevant to Bank’s portfolio, operations and support

functions

relevant to AMA Modelling

mapping to all Basel dimensions plus business dimensions



Bank will review the relevance of external loss data to see its

validity and usability to the bank.

Vendor should also specify the approximate number of external

loss data in the proposed library

7.5 Test Cases for the Offered Solution:

Vendor should develop / provide test cases for all the

functionalities covered under this RFP. Test cases should:

Specify the number

Relevance to Indian Banking

Relevance to Bank’s portfolio, operations and support

functions


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

102


Approach

Relevance to AMA requirements – Qualitative and

Quantitative

Test cases for qualitative and quantitative requirements

both as per RBI / Basel II guidelines.

Mapping to all Basel dimensions plus business dimensions

Availability of expected results



Bank will review the relevance of test cases to see its validity and

usability to the bank. Vendor will have to enhance, modify and

develop new scenarios as per bank’s review feedback.

Vendor should also specify the approximate number of test cases

in the proposed library with expected results.

8 Reports

8.1 Vendor will have to provide at least 50 reports in the system (pre-

configured / standard) which must include all the qualitative and

quantitative requirements provided under AMA and report

should be for all levels board / senior management/ ORMD and

business users. These 50 reports should be MIS and does not

cover regulatory reports. Vendor will have to provide all the

regulatory reports as per AMA / Basel II / Basel III guidelines. If

Regulatory has not provided reporting templates than vendor will

have to provide when regulator issues reporting templates at no

cost to the bank. If any of the report is not there in the system,

vendor will have to create, configure, customize, and

parameterize in the system and provide to the bank for testing.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

103

6.2 Functional Requirements for Operational Risk Management Solution

The detailed minimum functional requirements for this system are as under. If any of the requirements mentioned in RBI / Basel II / Basel II Guidelines with respect to AMA approach but not specifically covered here, system must support them too and same are part of the scope of this RFP.

Sr. No.

Functionalities Required Group Weight (on a Scale of

250)

1 General Requirements 30

1.1 Configurations of the bank’s legal, governance and business structure such as

group, legal entities, organization and governance structure, risk entities, product,

processes, systems, locations, business lines, outsourcing vendors etc. all other

dimensions enabling operational risk management and measurement

(As mentioned in the vendor responsibilities for ORM Implementation, vendor will

prepare entire process documentation for uploading into the system)

(For all the above dimensions , bank will provide the data in as is format and vendor

will convert them into uploadable format and then will configure / parameterize and

upload into the system)

2

1.2 Manual upload facility of the historical data, interface with external system such as

CORDEX, interface with bank’s integral source system / staging area / data warehouse,

and enable integration with KRI, RCSA, Scenario loss data, etc.

External loss data can be from CORDEX or any other source which vendor should be

uploadable into the system through from the front-end through graphical user

interface, if direct or staging area interface is not done as per decision taken by the

bank.

(Direct automated interface with external source such as CORDEX but data should be

visible to the user on the front end of the system and user should also be able to

download the data).

Interface with external third party system can be real time as well as batch.

Data upload templates can be in various files formats such as Excel, CSV, txt, open

office but not limited to them.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

104

Sr. No.


250)

1.3 Configuration of bank’s operational risk management framework in terms of

methodology, work-flow, templates, consolidation, models, tools, analysis, monitoring

and reporting.

1

1.4 Administration of the module in terms of access to the system as per job profile of the

employee with functional specific controls such as restricted access to reports, no

deletion rights etc. Access can be given and controlled at various dimensions such as

location, geography, employee, department / unit etc.

1

1.5 Complete audit trail including reports generation thereof. Audit log of the changes

made in assumptions, methodology, process, statistical model/ formulae used along

with reasons/ logic for change should be available chronologically.

2

1.6 Exceptional reports including bank specified exceptional reports.

(Bank specified exceptional reports will be created and configured by the vendor in the

system, at no extra cost to the bank, Bank will provide requirements only)

1

1.7 Flexibility for system enhancement due to change in regulatory requirements, bank’s

policy and procedures and due to good risk management practices, as determined and

specified by the bank.

(If any new development or customization is required, it will be done by the vendor at

no extra cost to the bank. Its implementation will also be done by the vendor at no

extra cost to the bank.)

2

1.8 Use of results of operational risk management processes for the purpose of

operational risk capital quantification e.g. BEICF factors

(vendor needs to demonstrate that how the results of RCSA, KRI, Loss Data are linked

to AMA Modelling / OR Capital Quantification)

Deliverables:

Vendor needs to provide a document as to how results of qualitative processes of

operational risk management in the system facilitates in the AMA Modelling / Capital

Quantification including data flow and use of information)

1

1.9 Multi-lingual, which can help to roll-out in multiple jurisdiction. This is not a very strict

requirement but can be counted as a good feature in the system. Currently, at least

English should be supported.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

105

Sr. No.


250)

1.10 The system should have ‘help’ function to assist the user in understanding the system

functionality through navigation.

Deliverable:

vendor should provide Help Manual too

1

1.11 System should facilitate alerts, reminders, notifications at various stages of ORM

framework implementation such as RCSA, KRI, Loss data etc. by various channels such

as e-mails, SMS etc.

2

1.12 Functionality with respect to record such as create, approve, save, submit, reject,

view, print, download, upload, de-activate, delete at appropriate places of the work-

flow attached to the user rights matrix as specified by the bank.

2

1.13 System should give relevant error message such as on data upload, on execution of

wrong command etc. including generation of log

1

1.14 System should provide search facility of various records using fields or combination

thereof which are used to define that particular record.

1

1.15 The system should provide at least 15 dimensions of structures or hierarchies such as

organization structure, product, process / sub-process, business lines, loss event type,

geographies,

Each hierarchy should be able to be defined in parent-child / tree structure.

2

1.16 System should facilitate split, change, merge, edit and creation of units and codified

data points. For example, with business changes there should be the ability to split or

merge loss and risk data/MIS.

2

1.17 System should have the capability to maintain inventory of processes and reports

at least for seven years

Each process is to be defined with mapping to product, organization structure, internal

and Basel business lines, ownership etc.

2

1.18 System should support the break‐down of processes into logical process steps with

linkages to underlying procedures, unit responsibility and they should be able to be

linked to RCSA, KRI and Loss event

System should be able to capture process in a parent-child / tree structure e.g.

process, sub process, activities etc.

1

1.19 The system should have scalability to take care of any changes brought in by BASEL

guidelines/Regulator

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

106

Sr. No.


250)

1.20 System should be web based where functioning of the proposed solution will be

checked at server site as well as different locations of the bank as users of the system

would branches, regions, zones and head-office hence web-based system should work

effectively.

1.21 System should be able to map bank’s income / expenses and products to Basel II

business lines and should be able to generate report of income and expenses as per

Basel II business line wise.

2

2 Risk and Control Self-Assessment 45

2.1 System should be able to customize and / or support bank's RCSA framework in terms

of methodology, approach, use of templates, work-flow, approvals, use of scale,

consolidation, analysis and reporting etc. and use of RCSA results for capital

computation purpose.

Results of Current Assessment shall be used for the purpose.

System to be implemented for Operational Risk Management should automate Risk

and Control Self-Assessment. Facilitate roll out of RCSA across a representative

sample of Business Lines and Geographic locations through the implemented system.

The system should support monitoring of progress achieved in RCSA and should

enable analysis of the quality of data provided by the representative sample. Provide

Recommendations regarding improvement of the RCSA quality.

3

2.2 There should be upload / download facility such as upload of RCSA assessment, plan,

schedule download of respective templates, etc.

1

2.3 RCSA methodology such as risk based, Questionnaire based and hybrid, all should be

supported.

(Under Risk based Methodology, Risk Assessment will have Risk and Controls for the

underlying risk entity and each risk and control is to be assessed. Risk and Control

Assessment (using frequency and impact scale) can be done such as: (i) Inherent Risk

Assessment, Control Assessment & Testing, Residual Risk Assessment / Derivation (ii)

Control Assessment / Testing and Residual Risk Assessment / Derivation (iii) Residual

Risk Assessment

(under Questionnaire based Risk Assessment, risk and controls will be assessed basis

set of defined questions)

(Hybrid approach means combination of Risk based Methodology and Questionnaire

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

107

Sr. No.


250)

based Methodology and bank can use both at one point of time for different risk

entities.

(Risk Entity for which RCSA is to be done can be defined with any combination such as

a single branch can be a risk entity, combination of branch and other offices combined

can be a risk entity, a geography can be a risk entity, an entity can be a risk entity, a

business line can be a risk entity, a product or process can be a risk entity. In essence

risk entity can be defined at any dimension in isolation or in combination as per

business & risk profile and materiality involved)

2.4 Planning within the system in an automated manner for RCSA by considering various

parameters such as risk profile, business size of the risk entity, audit findings, actual

loss experience, inherent criticalness of the business operations and various other

parameters considered relevant by the bank. There should be flexibility in defining

new parameter and modifying existing one.

Planning will ensure identification of risk entities for assessment over the RCSA period

such as within a Financial Year. Planning can also be done for some of the processes

for a particular risk entity e.g. under a particular RCSA schedule, bank may decide not

to cover all the processes of the branch or may decide different processes for each

branch.

1

2.5 Assessment scheduling is to be done through the system as to when RCSA is to be

done over defined RCSA period. System should have capabilities of sending auto

reminders through emails when the schedule for RCSA is due and escalation for delay

in completing the assessment to various levels. Scheduling will ensure timing of the

RCSA of a particular risk entity in the RCSA period. System should support assigning

ownership for each RCSA schedule.

1

2.6 It should create RCSA template for risk and control assessment which should be

customizable as per risk entity, as all risk-entity may not have same number of risk

events and approach

1

2.7 RCSA template should be at process, product e.g. new product, risk entity level,

outsourced vendor or any other dimension as defined by the bank. E.g. System should

support RCSA just for a new product or process without planning or scheduling. System

should also support RCSA on ad-hoc basis such as occurrence a fraud in a risk entity

triggering for unplanned / unscheduled RCSA

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

108

Sr. No.


250)

2.8 It should have facility to roll-out of the same template to multiple risk entities due to

similarities in the risk profile e.g. rural branches can have similar type of template

1

2.9 Template should be designed with appropriate classification, sub-classification,

sequencing, grouping and sub-grouping of risk events as specified by the bank e.g.

logical sequencing of first processes and then risks and controls within a particular

process.

1

2.10 Risk and Controls in the template should come from the Risk and Control Library to

avoid repetitive preparation of templates. A risk and control template for a risk entity

should be able to be saved with version control within the system for further use.

1

2.11 It should have flexibility to enter any risks identified and corresponding controls in all

the operations and activities of the bank including in the support functions. Risk and

controls so identified should be stored in the risk and control data library.

1

2.12 Risk and controls should be mapped to respective classification such as risk entity,

process, product, Basel II classification, causal factors, risk drivers, significant / non-

significant risk, preventive / detective control, control frequency, risk identification by

(auditor / risk entity / ORMD / external events / others) etc.

1

2.13 System should facilitate performing RCSA can be in following ways i.e.

A. Under Risk Based RCSA Approach:

i) Inherent Risk Assessment, Control Assessment & Testing, Residual Risk

Assessment / Derivation

ii) Control Assessment / Testing and Residual Risk Assessment / Derivation

iii) Only Residual Risk Assessment

B. under Questionnaire based Risk Assessment, risk and controls will be assessed

basis set of defined questions

C. Hybrid approach means combination of Risk based Methodology and

Questionnaire based Methodology and bank can use both at one point of time for

different risk entities.

It should also facilitate control testing, if chosen by the bank as per its framework

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

109

Sr. No.


250)

2.14 While doing the risk assessment, user should be able to see the respective process /

activities under process. User should also be able to put any remark/suggestion against

process/ activities while doing the assessment.

1

2.15 If there are more than one users to do the RCSA for a specific risk entity, system should

consolidate the assessment as each level to produce final risk assessment such as

averaging the ratings

1

2.16 System should facilitate risk assessment should be done on probability and impact

scale

2

2.17 Scale for risk assessment available in the system should be customizable by the bank

with appropriate color coding where each color should bear a different meaning.

2

2.18 Residual risk should be rated as a result of probability and impact assessment by the

system i.e. product of probability and impact

1

2.19 There should be facility to review and approval of the RCSA assessment i.e. through

maker checker. There can be more than one level of review and approval. Under

review and approval, person should be able to change the assessment with reasons

recorded. System should support bank specified work-flow for RCSA.

1

2.20 System should rate the individual risk / process / risk entity / region /zone / bank /

group, through logical consolidation of results.

Consolidation of all the results should be done and a consolidated RCSA Index to be

created by the system

2

2.21 A heat-map should be generated for RCSA results with drill-down capabilities. Heat-

map should be multi-dimensional such as for a risk entity, region, zone, Inherent risk /

Residual Risk , bank, group, risk type, only critical / key risk events, risk events with

action plan etc. the system should have capability to customize logic used for creating

Heat maps.

1

2.22 Dash-board facility to view the risk profile by risk entity, business unit / business line,

and the bank as a whole. A dashboard can have trend, current assessment, critical

risks, action plan status in just one report and same can be populated for risk entity,

business lines, geography, bank, group etc.

1

2.23 Summarizes the assessment results by process, product, risk entity, region, zone, bank,

group, location, risk type etc.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

110

Sr. No.


250)

2.24 Trend analysis of RCSA results using historical data such as comparison between

entities, trend of risks of a risk-entity, trend of a particular risk type, trend of a

particular geography, trend of key risks etc.

2

2.25 Detailed action plan report i.e. all open action plans on a particular date with their

owners with their status and if delay then number of days delayed by

1

2.26 Action Plan Report with status e.g. action plan which has breached the timelines and

escalation work flow

1

2.27 Exceptional reports such as risk entities which has not completed RCSA as per

schedule, Completion with Delay, RCSA initiated but not yet completed etc.

1

2.28 Reports for internal audit, compliance, information security etc. to share the results

such as action plan report can be given to internal audit which can validate the

implementation in the next audit / review, Critical Risk can be shared for detailed

control testing etc.

2

2.29 RCSA validation report which will show the number of changes in the RCSA assessment

based on third party review such as audit, compliance, regulator etc. System should

facilitate to put independent rating of that particular risk or risk entity such as done by

internal audit or external agency for validation purpose.

1

2.30 It should facilitate creation of action plan with a particular reference and linked to the

risk event e.g. which has been assessed such as critical

1

2.31 Action plan should include information such as task to be done, original target date,

revised target date, number of revisions done in the target date, owner for action plan,

link with the respective risk event etc. System should support defining more than one

task under one action plan ID.

1

2.32 ORMD should be able to change the RCSA rating based on validation results or on

occurrence of some risk event within or outside the bank. Change in RCSA rating

should happen with reasons recorded in writing. Rating can be changed of a risk,

process, risk entity etc. System should notify change in rating to the respective owner

1

2.33 There should be a document upload facility to substantiate the RCSA. 1

2.34 System should provide monitoring of RCSA status to various users such as ORMD

where they can view by branch, region, zone, bank, group level for a given time period.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

111

Sr. No.


250)

2.35 Vendor should conduct a sample run of the entire RCSA exercise as per the scope and

process mentioned by the Bank.

1

3 Key Risk Indicators (KRIs) 25

3.1 Implementation of bank’s KRI Framework at bank wide level including all its

geographies, business units and overseas operations.

The Operational Risk Management system should help automate the definition of

KRIs, allow for periodic capture of relevant KRI measurement related data and thus

enable monitoring. The system should be flexible enough to allow configuration of

different values for KRI attributes at the central, Zonal and branch level. E.g. the

system should enable configuration of a different value for a KRI threshold at the

Branch and then the Zonal level and should also provide framework for back testing

of KRI.

3

3.2 Provide for the upload of data manually as well as download of data to various file

formats such as word, excel pdf etc. The data upload includes KRI calculation data at

defined frequency and data related to KRI definition and assignment. For upload of

data, vendor should provide the templates.

1

3.3 Definition of the KRI in the system should be independent of its assignment to various

risk entities so that one single KRI can be assigned to more than one risk entities as per

applicability. Defining KRI means creating KRI into the system and then allocating for

monitoring to various risk entities as per applicability.

1

3.4 Provide interface with bank's various source system / staging area / data warehouse,

as applicable and decided by the bank, to extract data in an automated manner. Also

the system should have ability to take values from different users and consolidate

them at various levels such as business function, location and business line – this

situation may arise when data to be used for KRI are to be derived by combination of

various data points. Ideally this should be handled by the vendor at interfacing stage.

2

3.5 Definition of KRI with its mapping with various dimensions and classifications e.g. KRI

name, description, mapping with process, activity, product, risk entity, risk event type

classification, unit of measurement, calculation criteria, data attributes etc.

KRI so defined in the system will be part of KRI database which can be used to assign

KRI to various risk entities.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

112

Sr. No.


250)

3.6 System should provide facility to assign KRI to various risk entities with specification of

threshold, triggers, calculation frequency, and KRI review frequency.

Risk entity here means dimension at which KRI is to be calculated such as risk entity,

business line, region, bank, product, process etc.

In essence, KRI can be monitored at various dimensions in the bank and system should

support this.

2

3.7 System should facilitate different thresholds for a single KRI assigned to different risk

entities.

1

3.8 Trigger should be mapped with various level of automated notification and escalation

at various hierarchies e.g. through e- mails, SMS etc.

2

3.9 Compute KRI value on the defined frequency based on the data uploaded / extracted

as per job scheduling.

1

3.10 On the KRI review frequency, allow changes to be done after validation of KRIs such as

whether that particular KRI is relevant or to be discontinued

1

3.11 System should facilitate creation of action plan for those KRIs which have breached the

threshold or on reaching a critical trigger level

1



link with the respective risk event etc.

1

3.13 Compare computed value of KRI with the thresholds set and then provide alerts to the

respective notification / escalation level

1

3.14 Generation of reports at multiple dimension such as for individual KRI level, risk entity

level, business unit, KRI sensitivity level (e.g. High, Medium, Low), region / zone / bank

/ group level, risk type, product, process etc.

1

3.15 KRI Report should be of all types heat map, dash board, tabular, graphical etc. 1

3.16 Provide report with respect to trend analysis of KRIs such as movement of same KRI,

comparison of KRIs of one entity with another entity, new breaches than before to

show emerging risks, movement of KRI Index, KRI index from risk entity to bank level

etc.

1

3.17 Dash-board of KRIs for risk entity, region, zone, bank and group. Dashboard should

show KRI breached, critical risks, action plan status, new KRIs in critical zone etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

113

Sr. No.


250)

3.18 Results of KRIs are to be aggregated using bottom-up approach and a bank level KRI

Index should be derived by the system.

1

3.19 System should provide for comparison of KRI results with benchmarked KRIs along

with capturing of benchmarked KRI in the system itself. Benchmark could be industry,

peers, or others.

1

3.20 Vendor should conduct a sample run of the KRI Scope as per the Bank specified

process.

1

4 Loss Data Management (Internal and External both) 30

4.1 System must support all the requirements of RBI and Basel II with respect to internal

and external loss data management in terms of operational risk management as well

as measurement and modeling.

The system to be implemented should automate capture of actual, near miss and

potential loss events. There should be provision for capturing financial details related

to the loss event and subsequent recoveries from different sources such as insurance,

cash recovery etc. to estimate the gross and net loss. The system should support a

maker-checker mechanism for capturing, reviewing and approving loss event

information provided. The system should also support mapping of losses to Basel loss

event types and Business Lines The system should have a provision of data upload and

allow scaling/upload of external loss data.

2

4.2 Loss Data Module should be comprehensive enough to record all the information for

the purpose of operational risk management as well measurement as per advanced

measurement approach.

Management of loss event also includes capturing intermittent status of risk event

such as investigation status, recovery status, so that end to end flow of risk event can

be monitored as to its progress and closure i.e. capturing the life-cycle of loss event

with all the status.

System should have facility to capture near-miss events, gains arising from operational

risk loss event and opportunity cost.

It should capture all information which would help the bank in management of

operational risk.

Information with respect to risk event should be captured such as date of risk event

occurrence, event end date, date of discovery, date of providing contingent liability,

date of accounting / provisioning, description of risk event, location, product, process,

risk entity, root-cause analysis (RCA), causal factors, risk drivers, mapping with

business line and loss event type as per Basel II classification, bank’s internal

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

114

Sr. No.


250)

classification etc.

It should be able to capture loss data from all geographies and departments /

operations of the bank.

4.3 It should have download and upload facility for loss risk events in a specified template 1

4.4 System should be able to customize, bank's loss data management framework,

template, work-flow, approval, reports etc.

1

4.5 It should be able to migrate the existing internal loss data of the bank through upload

facility with the actual time recording through Bank provided templates

1

4.6 It should have strong internal control around loss data such as access, restricted

access, view or print rights, audit trails, exceptional reports etc.

1

4.7 It should be able to do scaling, judgment overrides or other adjustments to the internal

loss estimates

1

4.8 System should flag events as loss event, near-miss, external loss data, operational gain

and opportunity cost for distinct identification of each entry. Opportunity costs / lost

revenues would mean operational risk events that prevent undetermined future

business from being conducted (e.g. unbudgeted staff costs, forgone revenue, and

project costs related to improving processes), are important for risk management but

not for quantification.

1

4.9 It should enable identification of related loss events over time i.e. grouping of related

loss events over a period of time. This will also help deciding materiality of risk events

as a single risk event may be below AMA modelling threshold hence may not be

considered but if similar risk events as a whole are above threshold then it should be

considered for AMA modelling. System should support such grouping and linking the

same with AMA modelling.

1

4.10 It should have facility to arrive at the Gross Loss, inter alia, including any direct charges

to reserves due to operational losses, all expenses incurred as a consequence of

operational risk events, provisions made, penalty and fines etc.

1

4.11 System should differentiate the status of loss such as estimated, contingent liability,

provision made, loss accounted for with appropriate GL reference, Cost / Profit Centre,

currency of the Loss if different from currency of accounting / booking

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

115

Sr. No.


250)

4.12 It should record loss type such as Legal Cost / Regulatory Penalties / Loss or Damage to

Assets / Restitution / Loss of Recourse / Write Downs

Loss information should include type of valuation such as book value, replacement

cost, Mark to Mark (MTM) etc.

1

4.13 Allocation of losses to business lines and loss event type categories along with the

methods used to allocate the losses

1

4.14 It should enable classification of risk events as boundary events to specify it as credit

risk related or market risk related

1

4.15 It should be able to record recovery from all sources (from insurance and other

recovery such as from employees, third parties, vendor, customer etc.) with clear

identification

1

4.16 Status of recovery can also be included such as recovery process initiated but yet to be

received

1

4.17 It should be able to produce loss as gross loss, loss net of all other recoveries other

than insurance, loss net of all recoveries including insurance etc.

1

4.18 It should be able to identify the risk events which are covered in the existing

operational risk insurance policies

1

4.19 It should facilitate creation of action plan with a particular reference / linking to the

risk event

1

4.20 External loss data from all sources e.g. public data / pooled industry data / vendor

data, all should be supported by the system

1

4.21 System should capture External loss data in the similar manner as used for internal loss

data with flagging as internal loss data. External loss data can be interfaced with

external system such as CORDEX and / or uploaded manually

1

4.22 User should be able to view and download in reporting format of external loss data.

External loss data should be visible like internal loss data with flagging as external loss

data.

1

4.23 System should be able to do scaling, adjustments (qualitative as well as quantitative)

to internal and external data wherever applicable as per AMA requirements. The

scaling process should be systematic, statistically tested and generate outcome

consistent with the operational risk profile of the bank. System should have pre-built

scaling parameters which bank will select as applicable; Secondly, system should be

able to define new parameters as suggested by the bank. Vendor should ensure all the

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

116

Sr. No.


250)

required parameters have been configured in the system.

4.24 System should facilitate appropriate filtering process to ensure the relevance of data.

The filtering process should be applied consistently and any exceptions thereto should

be documented and supported with rationale

1

4.25 It should facilitate validation of loss data through review and approval e.g. maker-

checker and there can be more than one level of review and approval

1

4.26 It should facilitate reconciliation of loss data with other source data such as GL entries

etc. For the purpose of reconciliation, system should compare GL data with system loss

data for reconciliation for defined period of time. GL data can either be extracted or

uploaded into the system.

1

4.27 System should have a comprehensive analysis and reporting mechanism for review

and monitoring

It should be able to analyze data on multiple dimensions such as risk entity, product,

process, business lines, risk type, causal factor, risk drivers

Analysis should include trend analysis, comparison with past data and peers data using

various dimension entity, risk entity, business line, risk type, geography, period, cost /

profit center etc. i.e. analysis should be done basis the fields used to record the loss

data.

1

4.28 Apart from standard reports in the system, vendor should also define, create and

configure ad-hoc reports required by the bank

Reports should be in all formats tabular, graphical, dash-board, heat map etc. Bank will

provide requirements for reports to the vendor.

Reports should be with drill-down facility up to most granular level including loss

information into 8*7 matrix of loss types and business lines.

User should be able to extract the data based on applied filters e.g. loss between a

particular period

Format used for capturing operational losses should be customizable by the Bank.

1

5 Action Plan 10

5.1 System should provide for recording of action plan due to RCSA, KRI, Loss Data,

Scenarios, External Events etc.

The system should allow definition of corrective actions that need to be taken to

mitigate identified risks. A mechanism of defining such actions, allocating it to specific

business units / branches and monitoring of the same should also be provided.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

117

Sr. No.


250)

5.2 Action plan should capture information such as task, start date, original target date,

revised target date, number of revisions done, reason for revision, owner, action plan

type (long terms/ short term/medium term), status, reference of risk event / KRI / Loss

event due to which it was raised.

2

5.3 It should provide a direct link from the respective RCSA, KRI, Scenarios and Loss Data

module when action plan is required to be created as well as direct access to the

module

1

5.4 It should facilitate creation of action plan without any reference to a particular risk

event, KRI and loss event as in certain situations, action plan can be created due to

external events as well such as a big fraud happened in another bank.

2

5.5 System should generate reports on the status, action plan which has breached

timelines, with open status, owner by action plan, risk entity / unit wise etc.

2

5.6 It should be able to customize bank specific reporting requirements at no extra cost to

the bank

1

6 Operational Risk Measurement / AMA Modeling 75

6.1 Support operational risk measurement and modeling as per RBI and Basel II

requirements under Advanced Measurement Approach (AMA).

The Operational Risk Management system should have the provision for modeling

frequency and severity of losses and should support modeling of Scenario and RCSA

data. The system should allow users to select the appropriate distribution for

frequency and severity of losses. Based on the distribution used for modeling

frequency and severity, the system should generate the expected and unexpected

loss estimates for Operational Risk. The unexpected loss estimate should be based on

the Value at Risk framework as well as any other framework that is compliant with

the Advanced Measurement Approach of Basel II. The system should support

computation of capital requirement based on internal loss data, external loss data,

scenario analysis and business environment & internal control factors.

2

6.2 Calculation of unexpected loss (UL) at 99.9 percent one-tailed confidence interval over

one year time horizon or at multiple holding period and also at various other

confidence levels e.g. 95%, 99%, etc.

2

6.3 Consideration of all types of risk events i.e. low frequency high severity (LFHS), high

frequency low severity (HFLS), low frequency low severity (LFLS), high frequency high

severity (HFHS).

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

118

Sr. No.


250)

6.4 AMA model should creation of ORCs basis statistical analysis / approach.

System should be sufficiently granular to capture the major drivers of operational risk

affecting the shape of the tail of the loss estimates i.e. statistical distribution of loss

event types and business lines to ensure that bank's ORMS and AMA model are

sufficiently granular (i.e. the number of ORCs are neither too few nor too large) to

capture the major drivers of operational risk affecting the shape of the tail of the loss

estimates. An Operational Risk Category (ORC) or unit of measure is the level (for

example, organizational unit, operational loss event type, risk category, etc.) at which

the bank's quantification model generates a separate distribution for estimating

potential operational losses. This term identifies a category of operational risk that is

homogeneous in terms of the risks covered and the data available to analyze those

risks. Within ORCs losses are independent and identically distributed.

Granularity should be adequately supported by quantitative and qualitative analysis.

Statistical or other analysis to support the choice of granularity and the assumptions

that choice of granularity implies, and not justify their choice only on the basis of data

availability.

Calculation of risk measures separately for each ORC and aggregation of each ORC to

calculate bank wide VaR.

2

6.5 The system should have advanced analytics functions such as: system capability to

carry out structured stress testing including reverse stress testing (providing Stress

VaR estimates for each Operational Risk Categories, business lines and the

Bank level), make qualitative and quantitative adjustments for BEICFs, extrapolate

from the distribution of observed total loss points curve to determine the likely

amount of total losses, etc.

2

6.6 Modeling of one or more appropriate de-minimis gross loss thresholds which may vary

across business lines or loss event types, for the collection of internal loss data as per

RBI / Basel II requirements.

2

6.7 Systems should facilitate scenario analysis of expert opinion 1

6.8 The system should support defining, capturing and assessment of the scenarios. 1

6.9 System should support AMA modeling basis the inputs available such as basis the

scenarios, internal loss data, scenarios & internal loss data, scenarios plus internal loss

data plus external loss data.

System should do AMA modelling basis the appropriate mix of four input elements.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

119

Sr. No.


250)

6.10 Use of assumptions in scenario analysis based on empirical evidence 1

6.11 Periodic Review and validation of scenarios should be supported by the system as and

when required by the Bank.

1

6.12 Pre-identified and configured BEICFs including approach for their determination and

use. This should include their linkages with the operational risk management

framework of the bank such as RCSA, KRI etc.

2

6.13 Translation of BEICF factors into quantitative measures for measurement, validation

and verification

1

6.14 Flexibility for use of BEICF as directly or indirectly in the capital calculation process

(VaR Calculator) or as upward / downward adjustment to operational risk capital, and

indirectly to the scenario analysis process. The system should have capability of

calculation of capital before and after consideration of BEICF factors.

2

6.15 Four elements required for operational risk measurement are internal data, relevant

external operational risk data, scenario analysis, and business environment and

internal control factors (BEICFs).

Use of standard statistical techniques for combining four elements in the process of

generation of the operational risk capital measure along with expert judgment of the

bank.

2

6.16 System should determine and justify statistically how the AMA elements are weighted

and combined.

1

6.17 Exploratory Data Analysis (EDA) for each of the ORCs to get an idea of the statistical

properties of the data and select the most appropriate distribution

1

6.18 Estimation techniques to fit the operational risk models to historically available

operational loss data

1

6.19 Goodness of the fit testing for the chosen distribution using visual test could be but not

limited to Quantile-Quantile Plots (Q-Q), Mean Excess Plots, Autocorrelation Plot, Hill

Plot estimations, etc.

2

6.20 Common formal tests for the goodness of fit could be but not limited to Likelihood

Ratio Test, Chi - square test, Maximum-likelihood Estimation (MLE), Kolmogorov -

Smirnov Goodness of fit test, Anderson-Darling Test, Cramer-Von Mises Test, Quantile

Distance Estimation method

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

120

Sr. No.


250)

6.21 The system should have statistical capabilities for estimation of information criteria

such as AIC (Akaike information criterion ) , BIC(Bayesian information criterion ) etc.

2

6.22 The system should allow to conduct parametric and non - parametric bootstrapping

process

2

6.23 To provide commonly used frequency distributions but not limited to the poisson,

binomial and negative binomial distribution. The system should be able to provide

graphical outputs for the fitted distributions.

1

6.24 Provide for Single Severity Distribution and Piece-wise Distribution. 1

6.25 System should be able to use more than one approach to estimate severity of the

body, tail and entire distribution

1

6.26 To provide commonly used severity distributions but not limited to Gamma,

Lognormal, Weibull, Pareto, Generalised Pareto and Generalised Pareto distribution

(with Block Maxima Model and Peak Over Threshold Model).

The system should be able to provide graphical outputs for the fitted distributions.

2

6.27 The system should support extreme value theory (EVT) 1

6.28 The system should display the parameters that are used for fitting the distributions. It

should rank and report all the test statistics

2

6.29 When selecting a severity distribution, positive skewness and leptokurtosis and other

statistical properties of the data should be specifically taken into consideration. In the

case of heavy tailed data, sub-exponential distributions whose tails decay slower than

the exponential distributions may be more appropriate.

2

6.30 Determination of appropriate body-tail modeling threshold for modeling the body and

tail of the loss distribution separately

2

6.31 Computing aggregate loss distribution with appropriate methods such as but not

limited to Monte carlo-simulations, Panjer's Recursive Method, Fourier Transforms and

Single Loss Approximation. Simulations, numerical or approximation methods may be

necessary to derive aggregate loss distributions.

2

6.32 Apply robust statistical techniques to test the reasonableness of the assumptions

about the underlying distributions.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

121

Sr. No.


250)

6.33 It should have capacity to model the correlations/ dependence between various ORCs

in order to get the diversification benefit of operational risk exposures across various

business lines and loss event types.

1

6.34 Provide for modeling correlations/dependence using various methods but not limited

to Independence , Clayton , Gumbel , Frank Guassian T copulas

1

6.35 The system should have the ability to generate kendell tau, spearmen rank correlation

and upper and lower tail dependence index for the chosen correlation

1

6.36 Model documentation should identify and justify assumptions as well as evaluate the

AMA model’s sensitivity to these assumptions related to correlations/dependence

1

6.37 The correlation/dependence assumptions should be validated using appropriate

quantitative and qualitative techniques. These should be substantiated by empirical

analysis of data where the modeling is primarily based on internal and external data.

1

6.38 Estimation of diversification benefits factored in at the Solo level , group-wide level

and at the banking subsidiary level

1

6.39 System should consider in AMA Modelling recoveries and insurance settlement as risk

mitigant.

2

6.40 Provide for capturing information related to insurance policies with all the data

requirements which helps to establish the eligibility of the insurance as risk mitigant

for operational risk. Data could be details of insurance policy, risks covered, minimum

claims paying ability rating, initial term, residual terms, minimum notice period of

cancellation, insurance provider being a third party, the uncertainty of claim payment

etc.

2

6.41 Mapping of insurance coverage to the exposures in bank's operational risk profile.

Mapping is required to generate an estimate of the probability of insurance recovery

and the possible timeframe for receipt of payments by insurers. This will assist the

bank in meeting the requirement that its operational risk model is capable of

evaluating the risk mitigation provided by insurance on a gross and net basis.

2

6.42 Mapping of insurance policies to Basel II event types for risk mitigation 2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

122

Sr. No.


250)

6.43 Calculation of capital on a gross- and net-of-insurance basis for each capital

calculation, and possibly at a level of granularity such that termination of any one

policy could be immediately recognized for its effect on capital

2

6.44 Provide for the validation of the AMA measurement model through back testing and

statistical testing. Stress testing including reverse stress testing.

2

6.45 Vendor should assist in getting the models validated/approved by the regulators

(especially in case of the underlying logic being proprietary).

2

6.46 Sensitivity analysis must include consideration of the sensitivity of the bank's

ORCC(Operational Risk Capital Charge) to change in modeling choices, assumptions

and data inputs (including internal data, relevant external operational risk data,

scenario analysis, and business environment and internal control factors)

2

6.47 It should allow for the allocation of capital to business lines. 2

7 Analysis and Reporting 35

7.1 System should have a comprehensive set of standard reports for all the stakeholders,

which should cover all the functionalities covered in this RFP and all the stakeholders

such as business function, risk function, senior management and board. RFP response

should cover detailed list of standard reports available in the system for all the

functionalities.

Putting in place a system for reporting operational risk profile, control effectiveness,

loss trends and distribution by loss category and by business units. Reporting KRI

trends and status of required actions to business unit management, senior

management and to the Board.

The system should provide at least 10 dimensions of structures or hierarchies: Basic

organization of the information onto any one or more of at least a selection of 10

hierarchy structures. (For example: business units hierarchy, process Structure,

product Structure, risk library Structures).

System should provide Multi- Hierarchy Structure Management that permits data to

be viewed and managed across more than one dimension.

Vendor will have to provide at least 50 reports in the system (pre-configured /

standard) which must include all the qualitative and quantitative requirements

provided under AMA and report should be for all levels board / senior management/

ORMD and business users. These 50 reports should be MIS and does not cover

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

123

Sr. No.


250)

regulatory reports. Vendor will have to provide all the regulatory reports as per AMA

/ Basel II guidelines. If Regulatory has not provided reporting templates than vendor

will have to provide when regulator issues reporting templates at no cost to the bank.

If any of the report is not there in the system, vendor will have to create, configure,

customize, and parameterize in the system and provide to the bank for testing.

7.2 Report should be of all types such as graphical, heat-map, dashboard, tabular etc.

with drill-down facility to the most granular level. Provide detailed response on this.

2

7.3 Reporting should have flexibility to be generated using multiple dimensions and

combinations of them such as risk entity, legal entity, geography / location, process,

product, risk type etc.

Note: It should be shown during product demo

2

7.4 There should be pre-configured standard reports for each of the modules as well as a

consolidated risk profile which can be created at various dimensions such as branch /

region / zone / bank / group etc.

Note: Key Reports should be covered during Product Demo

2

7.5 System should be flexible to configure ad – hoc reports in the manner and form

required by the bank at no extra cost to the bank. New reports are to be created in the

system by the vendor on providing the requirements by the bank.

2

7.6 It should support both regulatory as well as management reports such as risk profiling

of branch, region, zone, bank, group.

If regulator comes with reporting templates in future then vendor will create those

reports in the system, if not already available.

2

7.7 Reports should cover qualitative i.e. results of operational risk management processes

and quantitative i.e. capital calculation processes and combination of them

1

7.8 It should provide a robust analytical framework such as comparison of RCSA, KRI and

Loss Data results, capital consumption vis a vis risk experience, trend analysis,

comparison with peer banks etc.

2

7.9 It should provide facility to access, view, download and print the reports as per user

access rights

1

7.10 Report should be downloadable in excel, word, pdf etc. file formats 1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

124

Sr. No.


250)

7.11 Operational Risk Management and Measurement Reports should be generated at

multiple dimensions such as ORM capital as per each business line etc.

1

7.12 The system should generate periodic reports highlighting the findings of RCSA, Audit,

Losses experienced, Potential loss and Near Miss data, KRI status and Scenario

approach

1

7.13 The system should be capable of generating performance measurement reports

measured vis‐a‐vis RCSA results, KRI status and action taken by units/business lines.

1

7.14 System should provide linkages between RCSA, KRI, loss data and audit processes as

required by the Bank and generate report accordingly

1

7.15 The system should report the operational risk charge before and after any reduction in

capital resulting from the use of insurance.

1

7.16 System should support the generation of various MIS reports such as Loss matrix,

Trend analysis, Issues and action plan status report etc., as per the requirements of the

Bank

1

7.17 System should provide capital charge drill down at each ORC level, which would

provide a split of LDA VAR and Scenario VAR

1

7.18 The system should display capital before BEICF adjustments and capital after BEICF

adjustments and highlight the impact of BEICF

1

7.19 The system should display capital before diversification and capital after

diversification effect and highlight the diversification impact

2

7.20 The system should be able to aggregate the RCSA profiles of each of the products and

business lines to arrive at a Bank wide RCSA profile

1

7.21 The vendor should be able to provide post implementation support, configuration

training and end user training.

1

7.22 The system should generate summarized reports regarding the verification and

validation exercise and highlight any outstanding issues. Such reports shall be

customized to be of assistance for reporting to the regulator.

1

7.23 Following is the inclusive list of reports / requirements which system should have:

The system should provide periodic reports on loss event types highlighting the

findings of RCSA, Audit, Loss, Potential loss and Near Miss data, KRI and Scenarios.

5


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

125

Sr. No.


250)

Capable of generating performance measurement reports on the basis of logic

provided and on the basis of RCSA results, KRI monitoring and action taken by

units/business lines.

There should be a link between RCSA, KRI, loss data and audit findings.

The system should provide a drill through heat map

The system should provide drill down reporting

The system should report Capital charges, total and by business lines

The system should have adequate graphical reporting tools for reporting loss event

data

System should support KRI dials for the dashboard reporting

System supports to build various MIS reports Loss matrix, Trend analysis, Issues

and action plan status report etc., as per the requirements of the Bank

System should support Slice and dice of structure values and filtering of risk areas

simultaneously

The system should aggregate the RCSA scores of risk events to arrive at a Bank

wide RCSA profile

The system should generate reports outstanding issues at any given date

The system should generate reports for processes that has loss data but no KRI /

RCSA and for processes that have adverse RCSA events but no KRI

The vendor should provide post implementation support, configuration training

and end user training. The system should report operational risk charge before and

after any reduction in capital resulting from the use of insurance.

The system should provide capital charge drill down at each cell level, which

should provide estimates for loss data and Scenario data and From total Scenario

VAR the system should provide drill down to VAR of each Scenario

The system should display capital before BEICF adjustments and capital after BEICF


The system should display capital before diversification and capital after


The system should display the parameters that are used for fitting the distribution

The system should rank and report all test statistics

Total 250


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

126

6.3 Technical Requirements for Operational Risk Management Solution

Sr. No.

Technology Requirements Max.

Marks

1 User Interface 25

1.01 The system should provide a consistent and easy to use graphical user interface 2

1.02 The system should be capable of interfacing with mail clients (Lotus

Note server) to generate notifications and auto‐mailers.

2

1.03 The system should provide the facility to upload/download data to/from peripheral systems to be provided as and when required.

2

1.04 Report Creation utility should be provided for the user to generate new reports 1

1.05 The system should provide user‐friendly design, short‐cuts, smart tags and other productivity features

2

1.06 The system should support configurable graphical display of historical, current and forecast figures and analysis

2

1.07 The system should provide tools for validation of data inputs that are captured from the existing applications of the bank

2

1.08 The system should provide for validation of data inputs that are subject to re‐entry or manual intervention

1

1.09 System should provide users with the option to print, i.e. print to files of various formats, print to printer etc.

2

1.1 The functionalities should be menu driven. The menu structure of the system should be standard

2

1.11 The system should provide online help facility which is context sensitive at field, screen etc.

2

1.12 The system should have a flat file import and export functionality to import and export transaction data and/or static data in any of the following formats but not limited to:‐

3 ● Microsoft Excel Format (.XLS)

● Comma separated values (.CSV)

● Text file (.TXT)

● Microsoft Word (.DOC)

● Adobe Reader (.PDF)

● ASCII (Flat File)

● Web Page(.HTML)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

127

Sr. No.


Marks

● Extended Markup Language(.XML)

1.13 The system should provide intelligible edit error messaging to assist correction and re‐entry of data

1

1.14 The system should generate intelligent error messages based on pre‐defined parameters

1

2 System Architecture 10

2.01 The solution should be in web based technology in a three tier architecture

3

2.02 System should be able to Extract, Transform and Load data from the source systems, Staging Area and Data Warehouse as decided appropriate by the bank

2

2.03 The system architecture should be modular; separate modules of the system should run independently

2

2.04 Bidder to provide all updates/modifications on account of regulatory requirements affecting domestic or international operations in respect of the Operational Risk Management System, including Advanced Approaches under Basel II without any additional deve lopment , licensing, implementation and customization costs to the bank during the implementation and AMC period.

3

Up‐gradation to Basel III should be possible with the proposed solution

3 Data Archiving Back up & Recovery 25

3.01 System should support archiving of data that are beyond a specified time horizon, to prevent long term speed concerns.

2

3.02 The system should allow have a day‐end back‐up process 3

3.03 The system should also have recovery features in case of system failures 3

3.04 Back‐up should be possible in external media (CD, tapes, DVD) for off‐site storage 3

3.05 System should support archiving of data that are beyond a specified time horizon with facility to parameterize.

3

3.06 Export of data to secondary storage device should be supported by the system without down‐time. Secondary storage is for backup purposes. (Retention policy should be as per regulatory guidelines. Backup window should be during off-peak hours.)

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

128

Sr. No.


Marks

3.07 System should support data retrieval – from the specified archives. The archival and retrieval programs should facilitate easier analysis of old data.

3

3.08 The system should generate error logs if the calculation fails during time of data processing

2

3.09 The error logs should be descriptive enough to allow traceability of the data/function error to the most granular level

2

3.10 The solution should have suitable Business Continuity Plan and structure to achieve “solution availability”.

2

4 Security management 30

4.01 The system should provide for user profiles to be controlled by a specific administrator

2

4.02 System access should be permitted only through password verification with all user IDs being unique

2

4.03 Addition of new software features should be allowed only through a properly revised upgrade and data migration method. Proper Change Management System should be followed.

2

4.04 The system should have the ability to provide or restrict access privileges based upon hierarchy and multiple criteria

2

4.05 The system should allow for setting of each user profile from front end screens. User privileges to be defined on need to know basis.

2

4.06 Standard password management features should be configurable as per Bank's policies e.g.

3

● Automatic user disabling after three successive erroneous tries

● Automatic user time‐out on inactivity for a predefined time duration

4.07 System should provide for creation, deletion and modification of users, upgrades of users and data access rights

3

4.08 User id and login should determine level of access to data e.g. read/view data, print data, write/modify data, delete data etc.

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

129

Sr. No.


Marks

4.09 There should be a maker‐checker facility for key functions in the system 2

4.10 System should allow data access to users only through screens 2

4.11 The system should maintain the audit trail with details like user id, date‐time etc. 2

4.12 The audit trail should be at the granular level, and track the user across each activity 2

4.13 The system should have the ability to store and track all system events, including corrections and cancellations by multiple criteria

3

5 Reporting & Others 20

5.01 The calculation formulae, data flows and processes associated with the risk measurement system should be transparent and easily accessible. In particular, it is necessary that auditors and supervisory authorities are in a position to have easy access, whenever they judge if necessary and under appropriate procedures to the system’s specifications and parameters

2

5.02 Exception reports should be sent to pre‐defined users either through auto‐mailers via the e‐mail client or via pop‐ups within the system

2

5.03 The system should be flexible in allowing users to specify the exact layout of the required report including selection of data fields, location of data fields, header, footer, page numbering, title etc. No additional technical effort should be required to develop reports by the end user.

2

5.04 The system should allow reports to be exported into Microsoft Excel, Adobe PDF

format and other databases

1

5.05 The system should allow users to print reports directly from the system 1

5.06 The system should allow users to save reports to a disc in a non‐ editable as well as an editable format

1

5.07 The system should generate reports in various types of files like:

2 ● View Mode

● Excel Mode

● Text Mode

● HTML Table

● CSV format

● Word File


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

130

Sr. No.


Marks

● PDF format

● XBRL format

5.08 The system should allow for generation of pre‐defined end‐of‐day, end‐of week and end‐of month reports and ad‐hoc reports a s a n d when required

2

5.09 Reports generated in periodical wise or as defined by the Bank: 3

● Daily

● Weekly

● Fortnightly

● Monthly

● Quarterly

● Half‐yearly

● Annual

5.10 The system should allow for archiving of external reports in the following formats:

2 ● Adobe PDF

● Microsoft Excel

● Microsoft Word

● Microsoft Access


5.11 Archiving of reports should be possible in a pre‐defined format to facilitate ease of retrieval

1

5.12 Reports generated by the system should be in XBRL format whereas system should have capability to generate internal reports in PDF format.

1

6 General 15

6.01 The system should process, track and account for the necessary range of traded and non‐traded currencies which includes USD, INR, EUR, AUD, JPY, GBP, CAD etc.

3

6.02 The system should handle all types of day count basis including 30/360, Actual/360, Actual/365, Actual/Actual, 30E/360

3

6.03 The system should load calendar schedules from external sources including but not limited to Bank Hol iday , SWIFT, International Holiday schedule and Bloomberg holiday schedule etc.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

131

Sr. No.


Marks

6.04 The system should handle multiple entities that includes branches, subsidiaries etc. 1

6.05 The Bidder should provide a Data Mart to generate analytical reports to be used / viewed by the Bank.

3

6.06 The proposed Data Mart should be able to integrate with the Enterprise‐wide Data warehouse solution which is going to be implemented in the future. Bank is still implementing DWH, date of completion will be provided at time of SRS.

3

7 Integration 15

7.01 Integration with other systems should be facilitated by the following modes but not limited to:

15

● Batch processing

● Online processing

● Real time processing (calculation to be done with time lag of 1 day on the basis of day-end data)

8 Documentation 10

8.01 Please list the availability of various documentations provided with your product(s) such as

7 a) User manuals; Will be provided to the bank as per the standard documents available

b) System Administration manual‐ Standard Technical manual will be provided to the users.

c) System manuals – Architectures, Entity‐Relationship diagrams, Source code.

d) Documents narrating the mathematics, the assumption in all the Models/Pricing engines used in the software

8.02 Comprehensive documentation with indices or glossaries targeted at specific audience of users, systems manager/administrator.

3

Total 150

6.3.1 Additional Questions

Refer to sub‐section 9.5 in Annexure Section for required additional details on the proposed solution


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

132

6.3.2 Hardware Requirements

The Bidder must specify complete details of Hardware and other systems required for successful

implementation of the offered Solution, in the following format.

Sr.

No

.

Module/ Item Module Description Requirement Quantity

1. Hardware

2. Operating System

licenses(Windows or

any other)

3. Oracle licenses

4. Third party

utilities

5. Any other

requirement

Note:

1. Cost of ETL tools as part of proposed solution should be borne by Vendor 2. The hardware and infrastructure sizing should be done with registered users 5000, Concurrent user base

of 500. Registered users for operational users to increase @5% per annum. Please mention Make / Model (if any), type and number of processors, Memory, bus speed, hard disk & Operating System number of users, license type, version etc. Concurrent users are the no. of users who will be hitting the database at a particular point of time irrespective of the actual users logged in.

3. Detailed Bill of Materials (Line item wise mentioning technical specifications) to be submitted for all the


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

133

above modules 4. Detailed Technical sheets of the above modules to be submitted 5. Bidder to also provide detailed specifications for replication methodology for DR site 6. System should be capable enough not to allow Multiple Logins in the system. 7. Application user: pan India 8. Workload will peak over a particular period of time 9. OpVar 5 Concurrent Session should be supported

6.3.3 Training Requirements

Please provide descriptive answers to the following questions.

Sr.

No

.

Requirements Response

1 How many Implementation trainings (ORMS)

have been undertaken by the Bidder so far?

2 Please provide a brief description on the

Training approach taken by the Bidder.

3 Please provide the following details for

training :

3.1 Number of man‐days / duration for

completion of training

3.2 Optimum batch size

3.3 Total efforts for conducting the training

3.4 Location


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

134

Sr.

No

.


3.5 Frequency of training offered

3.6 Pre‐requisites / Preparations required before training

4 Please answer the following about the

trainers in‐charge of conducting the training

on behalf of the Bidder for the Bank:

4.1 Median experience of all trainers with the

Bidder who would be involved with the

Project

4.2 Median experience of all trainers involved

with the Project as trainers


with the Project, working / training on the

solution proposed by the Bidder

5 Please provide a sample training response and

feedback from previous implementations?

Also, please give details of the following:

5.1 Name of the Bank where product was

implemented and the training conducted

5.2 Date and place where training conducted

5.3 Training audience

5.4 Indicative rating [if any provided]


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

135

Sr.

No

.


Note: Please attach the feedback in a separate document with proper cross‐referencing.

6 Please specify the various modes through

which the training will be delivered? [e.g.

Classroom training, Online self‐help training

modules within application / e‐

learning modules, Quiz, etc.]

6.3.4 Project Management Methodology

Sr.

No

.


1 Details of methodology / approach

The methodology section should

adequately address the following stages of

the project:

1.1 Frequency and approach for

periodic reporting on the progress of the

project and actual status vis‐ à‐vis scheduled

status

1.2 Detailed Study of Current State and Gap

Analysis, with detailed work steps and

deliverables as per scope of this RFP

1.3 System Requirement Specification Preparation

(SRS)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

136

Sr.

No

.


1.4 Customization, Configuration

Parameterization, development and necessary

work around

1.5 Building up of interfaces / ETL with

various applications / source systems / staging

area / data warehouse etc. currently used by

the Bank

1.6 Setting up of the data center and the

disaster recovery site

1.7 Data Extraction, Preparation, Validation,

Migration and Reconciliation

1.8 User acceptance testing

1.9 Sample Roll-out, Training / Workshop and

Knowledge Transfer

Planning for roll‐out and identification of key issues that may arise along with proposed solutions

1.10 Production Migration

2 Timelines

3 Project management activities

4 Roles and responsibilities of

proposed personnel both from the vendor

and bank end

5 Following details with respect to the

methodology followed by the vendor in

Project Management for a Public Sector Bank

Project Name


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

137

Sr.

No

.


Project Location

Client Name

Client address

Client contact/reference person(s)

Project started (month/year)

Project elapsed time – months

Man‐months effort

Project Size (No. of branches,

modules covered and any other) relevant

details)

Name of senior project staff

Nature of the Project

Project Management Methodology used

Role of the Bidder, whether complete end‐to‐

end involvement or for a particular module

Project detail (Broad detail –

information about all activities handled,

modules forming part of the Operational

Risk Project of the Client Bank, associated

activities, time lines activity‐wise and module‐

wise may be detailed.)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

138

7. Scope for Credit Risk Management Solution

The Bank aims to migrate to the Internal Ratings based Approaches (IRB) for Credit risk as per Basel‐

II /Basel III RBI guidelines.

The solution should support compliance with all the RBI and Basel II / Basel III guidelines to move to IRB

Approaches including asset classification, securities classification, estimation of all risk components,

capital calculations and report generation (regulatory & economic).

The solution should be able to meet the Pillar‐I, II and III requirements as per Basel‐II / RBI guidelines

and Basel‐III guidelines. The solution should be capable of supporting all the required statistical,

analytical, risk modeling and reporting requirements.

Solution must be able to support IRB Approach (e.g. March 2015 Credit Risk Capital Calculation by the Bank using IRB Approach using the system) as bank may calculate capital on parallel run basis and / or may decide to move to IRB approach on selective basis as per requirements given by RBI.

If there is any change in regulatory such as RBI / Basel II guidelines and in bank’s CRM framework, system should be able to comply with those changes including required customization to be done in the system and implemented by the system vendor. Bank will provide relevant requirements and related clarifications to the vendor if required. Vendor will do at no extra cost to the bank. If there is any version upgrade of the system, vendor will provide to the bank at no extra cost to the bank.

Credit Risk Management and Measurement System offered under this RFP should comply with all the conditions mentioned below including functional requirements.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

139

The scope of Credit Risk Management System should include but not limited to:

i. Supply, installation, customization, configuration, parameterization, implementation, documentation, maintenance / support and training of an Credit Risk Management System (CRMS) in the Bank as per the scope, implementation, functional and technical requirements as given in this RFP.

ii. Risk estimation model developments and their validations

iii. Generation of reports as per regulatory guidelines and MIS

iv. Provide required data / information as provided in the scope of this RFP

v. Impart hands on training to the officials identified by the Bank in using and maintaining the solution & database administration.

System should be able to implement all the components of bank’s credit risk management and measurement framework at solo and group wide level in compliance with applicable RBI and Basel II / Basel III requirements for IRB approach. The capabilities of the Credit Risk Management System should include but not limited to:

i. To comply with RBI and Basel II / Basel III requirements for IRB approach for credit risk including both qualitative and quantitative requirements and subsequent guidelines prescribed by RBI / BCBS, in future, if any.

ii. System should support full as well as partial roll-out, if bank decides to do so, as allowed under regulatory requirements

iii. Data Management: the solution needs to be integrated with the existing CBS and rating solutions and extract required data from those, perform data cleansing as required for the modelling exercise specified in detailed functional requirements.

iv. Model Development: develop (using bank’s production data) PD, LGD, EAD models for retail and non-retail portfolios. The retail portfolio should be segregated in homogeneous retail pools based on various retail portfolios. The model development methodology for PD, LGD, EAD and pooling should be in compliance with RBI / BCBS guidelines and which needs to be implemented in the CRMS solution by the vendor

v. Number of models to be developed and configured should be commensurate to bank’s business and risk profile and portfolio of the bank. Bank would decide and sign-off on the number of models required for risk estimation, retail pooling etc.

vi. Vendor to validate all the models of the bank such as rating models, score cards and risk estimation models and basis validation output, enhance / modify / develop new models

vii. The system should satisfy all the validation methodology mentioned in Basel II Working Paper 14 at minimum including validation of rating models, scorecards, PD, LGD, and EAD and should support assessing stability of pools.

viii. RWA Computation: The vendor needs to study and map Bank’s asset classes and map them to Basel II Asset classes and compute IRB capital requirements accordingly for various asset classes and approach adopted

ix. ICAAP, Capital Management and Stress Testing: the system should support necessary computations for assessment of concentration risk capital charges, stress testing methodology


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

140

based on macroeconomic risk driver model and latest RBI Circular (DBOD.BP.BC.No, 75/21.04.103/2013-14 dated 2nd December, 2013). Inclusion of various stress scenarios in the system should be permitted. Impact of various scenarios of capital requirement and P&L is to be captured.

x. Configuration and parameterization of system for bank’s legal entities, internal governance / organization structure, product, process, securities / collaterals, rating, recovery, costs, capital structure, facilities, customer, systems and other dimensions which are required for the management and measurement of credit risk including their inter-relations and mapping such as on parent-child / tree structure, wherever required.

xi. Report Generation: the vendor is supposed to provide facility for generating various regulatory report generations such as RCA3 returns, Pillar 3 disclosures and Basel II IRB submissions and also support internal MIS report generations. Vendor should create, define and configure those reporting templates in the system and make to the bank available for testing.

xii. Regulatory as well as Management Reporting for all the stakeholders in the bank including flexibility of creation of new reports by the vendor, customization / configuration of reports as required by the bank.

xiii. Vendor to provide reporting templates, and create & configure those reports in the system, if already not there. Report should include all the aspects of credit risk management and for all the stakeholders in the bank.

xiv. Bank will require ad-hoc reports other than standard configured reports which vendor will create in the system, if already not available, at no extra cost to the bank. Bank will only provide reporting requirements to the vendor for ah-hoc reports. Regulatory / MIS / Ad-hoc requirements can be given anytime during the course of implementation, warranty period and AMC period.

xv. Vendor to provide UAT Test cases with expected results as mentioned in the implementation section for credit risk management. Test cases should be as per bank’s business and risk profile covering all the IRB requirements as per RBI / Basel II / Basel III guidelines.

xvi. Administration of the module in terms of access to the system as per job profile of the employee with function specific controls.

xvii. Ability of the system to be interfaced with bank’s source system, staging area and data warehouse in an automated manner.

xviii. Flexibility to upload the data into the system using Bank provided templates etc.

xix. System should be capable of doing Stress testing (including reverse stress testing) and back testing

xx. Compliance with bank’s system security standards

7.1 Scope for Implementation of Credit Risk Management Solution

Following will be the Vendor’s responsibilities for the implementation of system offered under this RFP for

Credit Risk Management. Vendor will have to submit specified deliverables under each stage mentioned

below.

A. System Installation and Creation of UAT Environment Supply and install necessary hardware, database, operating system, and IT infrastructure necessary for the proposed solutions. The entire IT Infrastructure for the proposed solutions would be required to be configured and installed before commencement of UAT at the Bank’s Data Centre in Mumbai.

Deliverables


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

141

b. Sign-off by the Bank’s IT Department for successful installation of all the IT components

B. Current State Assessment and Gap Analysis

Understanding of bank’s credit risk management framework and applicable regulatory requirements (RBI /

Basel II) is must as selected bidder will have to implement bank’s credit risk management framework

including all its components as per IRB requirements.

For implementation purpose, interpretation of RFP by the bank will be final.

To understand and assess (to the extent available):

o bank’s credit risk management governance, framework, policies and procedures, approach &

methodology, tools, rating models, retail score cards, behavioural models, risk quantification

approach & methodology (PD, LGD, EAD, Effective Maturity), risk quantification models (PD, LGD,

EAD etc.), asset classification and mapping as per Basel II classifications, securities / collateral

classification and mapping with Basel II classifications, model validations, capital computation as

per std. and IRB approach etc.

o workflow, reports, approval, staffing, business lines / departments, organization structure,

product, processes, consolidation

o IT architecture, existing systems, data, data architecture, interfaces, data-warehouse, data

issues, interface issues etc.

o Applicable RBI / BCBS guidelines for moving to Std. and IRB and bank’s plan for moving to

advanced approaches Std. and IRB with existing framework and data

o any constraint, decision and assumptions such as related to data, portfolio, models, tools,

business line, process, system, geography, exemption, partial roll-out, roll-out of Std. and IRB

together etc.

o Audit and regulatory queries, if any

Conduct gap analysis with system functionalities as required within the scope of this RFP and prioritize

the gaps

Conduct data gap analysis for the data requirements under IRB implementation with data available in

bank’s various source systems and manual files

Discuss and agree on the gaps and related customization requirements in the vendor system

Suggest workaround for resolution of the gaps in a time bound manner

Prepare a plan for completion of customization

Deliverables

a. Current State Understanding cum Gap Assessment Report including Gaps in Bank’s Framework vis a vis

RBI IRB Requirements and recommendation for enhancements

b. Data Gap Report including Recommendations / Work-around for their Resolution

c. Customization Plan including timelines


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

142

C. Credit Risk Models and Validations

Vendor will do the validation of existing credit rating models, retail score cards; risk estimation models (PD,

LGD and EAD) for retail and non-retail portfolios, development of stress testing models and will submit the

validation report to the bank. Validation will include the following tasks:

Perform qualitative validation of the current rating models for both retail and non-retail to assess the

model design, performance, governance, documentation, and justify continued usage of models in

business decision making.

take required data from the system to the extent available in the bank’s sources system(s)

Conduct an awareness workshop on the data collection requirements to the Bank.

Perform quantitative validation to assess the discriminatory power (in case of borrower ratings only),

calibration and stability of the models.

Provide recommendation on the usability of the current models in Basel II implementation, need for re-

calibration or re-building of models.

Based on the results of qualitative and quantitative validation, provide recommendations to enhance the

credit rating and scoring models.

Conduct discussions with the Credit department and the Risk department on the proposed

enhancements for the credit rating and scoring models.

Modify, enhance or develop the credit rating models and / or retail score cards basis the agreed

validation results and recommendations with the bank

Develop behavioural models as per bank’s business and risk profile

Develop PD, LGD and EAD models for retail and non-retail portfolios

Provide validation framework for PD, LGD and EAD predictor models

Develop stress testing models

Conduct stress testing on PD, LGD and EAD models

Submit the validation report to the bank with recommendations

Vendor will configure bank’s PD / LGD and EAD models in the system including all its logic. Bank should

be able to use vendor system for PD/LGD and EAD models

Provide training on model development and validation with training materials / presentations

Deliverables

a. Model Validation Reports

b. Enhanced / Modified / New Models

c. PD/LGD/EAD Models for Retail and Non-retail Portfolios including detailed Development Documentation

and Manual

d. Model Validation Framework for Credit Rating Models, Score Cards, PD/LGD/EAD Models

e. Behavioural Models


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

143

f. Stress Testing Model

g. Stress Testing Results

h. Training Materials

D. System Requirement Specification Preparation (SRS)

Following are the inclusive factors to be considered by the vendor for SRS preparation:

Structure the SRS in the modules as grouped in this RFP from implementation perspective

Conduct a detailed system walk-through before SRS workshops including demo of each module with

workflow, demo of reports already configured in the system, data requirements and their templates etc.

Conduct and lead SRS workshops for requirements finalization

Document all the clarification taken from the bank and incorporate in SRS including information / data

gathered during gap assessment phase

Incorporate all the requirements of the RFP in the SRS

Incorporate all the functionalities as per bank’s CRM Framework, Model, Approach, Methodology, Tools,

Data, System, Products, Portfolios, Interfaces, Templates, Workflow, Approvals, Exceptions, Reports,

Analysis, Monitoring, Sources, Regulatory Requirements, Regulatory / Audit queries etc.

Consider customization plan in SRS

Consider reporting – regulatory, MIS and ad-hoc in the SRS

Consider system security requirements as specified by the bank

Consider user access and system administration requirements as required by the bank

Discuss with the bank and agree on interface requirements and method and mechanism

Suggest any areas which can make system implementation effective and better (acceptance of the

suggestion so provided would be at bank’s discretion)

Incorporate on ad-hoc reporting requirements including its mechanism and responsibility for

configuration in the system

Incorporate BCP / DRP requirements

Consider all the details taken at Current State Assessment and Gap Analysis

Bank will review SRS prepared by the system vendor and provide its comments and highlight issues for

resolution by the system vendor.

For any requirement which is part of the scope, bank’s decision will be final in terms of its interpretation and

mechanism of implementation.

SRS will be complete on sign-off by the bank

Deliverables

a. System Requirements Specifications (SRS) which should include detailed documentation of

implementation of all the functionalities including workflows, processes, approval matrices


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

144

E. Customization / Configuration / Parameterization

Customization of the RFP requirements which the vendor has confirmed for its availability in the system

as standard but not available or confirmed as “Requires Customization”. Bank will be the final authority

to decide if requirement is available in the system or not as per its expectation.

Customization would be done as per bank’s Credit risk management framework and all its components

Requirement for customization would be identified at Gap Assessment Phase and SRS preparation phase

Vendor will complete the required customization including its testing within the planned timeframe of

implementation and testing

Customization should not delay the implementation timelines of the system

Vendor will install the pre-configured system in compliance with all the Std. / IRB requirements as per

RBI and BCBS guidelines irrespective of bank may use or may not use at the time of installation. This also

includes configuration of the risk estimation models, reports etc.

Vendor will parameterize the system as per bank specific requirements such as master data e.g. legal

entities, asset classes, counterparties, products / services, collaterals, organization structure, process,

business lines / functions / departments, locations, branches, regions, zones, and all other master data

required for implementation of qualitative and quantitative requirements in the RFP

Vendor will configure and parameterize bank’s IRB model(s) / descriptive requirements into the system.

For which bank may provide its IRB framework in descriptive format (not a model prototype or can ask to

build standard models as per IRB requirements under different data / input situations / scenarios.

Models could be related to PD / LGD / EAD / Effective Maturity / Retail Pooling etc.

Bank will provide the data in its own format and vendor will prepare the data into system uploadable

format

Vendor will define the situations and process for change management

Vendor will conduct a detailed walk-through for customization, configuration and parameterization for

the bank

Deliverables

a. Document on Configuration and Parameterization (with relevant screen-shots).This should be bank

specific customization, configuration and parameterization and not System User Manual

c. Change Management Process for Configuration and Parameterization including matrix for areas where

change management would be required

F. Interface / ETL Building

Depending upon the current state of automation in the bank, availability of the data and feasibility & ease of

extracting the data from a particular source, bank can define one or more options for building interface such

as:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

145

a. Directly from the Source System

b. Interface with a Staging Area

c. Interface with Data Ware-house

The Bidder will be responsible for identifying the detailed interface requirements for integrating the proposed packages to bank’s existing systems.

The Bidder will present to the Bank the interface requirements for review.

The Bidder will be responsible for developing, testing and maintaining the interfaces. In case of any subsequent change, modification or alteration to the Banks existing Application software packages, the Bank will obtain the API for such existing Application and provide the same to The Bidder for interface. The Bank has envisaged all the interfaces to be on an online secure mode with Straight through Processing. The Bidder needs to factor the same in the pricing.

Vendor will have to develop the interface with any one or combination of above

Interface design by the vendor will include to define all the logics and develop the interface

Bank will assist wherever required such as clarification on certain issues, making required infrastructure

available including approvals, involvement of bank’s IT personal etc.

Vendor will test the interface so developed to ensure that all the required data are flowing correctly and

timely

Vendor will define the change management process including responsibilities

The solution software should have proper interface for incorporating digital certificates, i.e. PKI-enabled.

The Bidder must ensure that all interfaces are automated with minimal or no manual intervention.

The Bidder will ensure and incorporate all necessary security and control features within the Application, operating system, data base, etc. so as to maintain integrity and confidentiality of data at all times.

The Bidder will be responsible for setting up the test environment for interface testing.

The Bidder will help / assist the Bank in preparing the test cases for the testing. Bidder shall ensure that the test cases meet all the testing requirements of the Bank.

All errors, bugs, enhancements / modifications required during and after testing will be immediately resolved by the Bidder (maximum of 5 working days), and sign – off for the same will be obtained from the Bank. However workaround solution should be provided on the same day, in respect of errors and bugs affecting the functioning of the Bank.

Decision of the bank in terms of which options to use for development of interface will be final.

In case direct interface with source system is not possible, then vendor will provide ISO data templates to the

bank. Bank will extract the data in the designated template and put at a stage area for automated interface

with vendor system. Bank’s decision in this respect will be final.

Deliverables

a. Interface Development Documents (including Change Management Process) and the areas where change

management would be required)

G. Data Extraction, Preparation, Validation, Migration and Reconciliation

Data extraction and its complete migration to the system is an important step in the entire process of system


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

146

implementation. Scope of data migration as per activities in this section includes historical data of the bank

currently in systems and / or manual files. Vendor will be responsible for end to end migration of historical

data.

Bank has credit risk management related data manually or in the system. Following will be responsibilities of

the system vendor:

Vendor will be responsible for formulating the “Data Migration Strategy” and process documents which will have to be reviewed and signed – off by the Bank prior to commencement of the data migration exercise.

Vendor to share the data upload format with the bank on start of the project

Vendor to conduct walk-through of the data requirements with the bank

Vendor to conduct data gap analysis (under gap assessment stage), provide recommendations including work-around

Vendor to extract the data from the system in case there is interface between the source system, staging area or data warehouse, as the case may be

Vendor to validate the extracted data and highlight any data deficiency such as incomplete / missing data, inaccurate data etc.

Vendor to complete the extracted data on correction of deficiency by the bank

Vendor to suggest the work-around to deal with data deficiency such as removal of mandatory field tag to upload the available data, defining the time frame for the bank to correct the data in the system over a period of time, develop and run required scripts to correct the data as a whole such as putting some common values in all the fields etc.

Vendor to liaise, interact, develop tools, correspond etc. of current solutions to obtain the data as desired by the proposed solutions and also upload the same. The Bank will provide the available data as existing from its legacy systems/paper formats

Vendor to ensure that extracted data / manual data provided by the bank is converted into the uploadable format to the Credit Risk Management System

Vendor will be responsible to format the data as per the software / upload format required by the solution

Vendor to convert them into uploadable format, if data is available in manual file such as excel / word etc.

Vendor to highlight deficiency in manual data to the bank and on correction by the bank, incorporate in the manual files for upload into the system

Data includes facility data, securities / collateral data, customer data, rating data, reports and all other data required for implementation of IRB approach, which can be in excel / Word / PDF file format

Vendor to ensure complete migration of bank’s data to the ORM system

Vendor to develop process of reconciliation of system data with the source system and implement the process on the uploaded data

Vendor to document the process of data migration including the change management process

In the event of any gaps in the field / data mapping reports, the same would be discussed with the Bank and

the agreed solution would be documented by The Bidder and signed-off from the Bank. The Bidder would

give the Bank adequate time for the review of the agreed solution and incorporate the modifications as

suggested by the Bank.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

147

The Bidder shall ensure that workarounds or default values moved to the production database as a result of

gaps in the field mapping are duly taken care of after successful migration to proposed solutions and the Bank

officials informed of the same in writing.

It will be the responsibility of The Bidder to convey to the Bank, at Current State Assessment and Gap

Assessment Phase, all the mandatory fields required for the functioning of the proposed applications that are

not available in the legacy systems and that needs to be obtained by the Bank.

In the event the Bank is unable to obtain all the mandatory fields as conveyed by The Bidder, The Bidder shall

suggest the most suitable workaround to the Bank. The Bidder shall document the suggested workaround

and sign-off will be obtained from the Bank for the suggested workaround.

The Bidder is expected to provide the bank with data capture utilities to capture missing data for all the

modules as would be required to capture the data. The Bidder will have to train the bank personnel to use

these utilities for them to be in a position to capture the required data.

The Bidder will be responsible for uploading the data entered by the Bank through the manual data entry

screens, programs / applications.

The Bidder shall develop the data conversion programs to convert Bank’s data to proposed solution upload

format. The Bidder shall perform mock data migration tests to validate the conversion programs.

The Bidder will be responsible for assisting the Bank in conducting the acceptance testing and in verifying the

completeness and accuracy of the data migrated from the legacy applications to the proposed systems.

The Bank reserves the right “to audit” / “appoint an external auditor to audit” the process of data migration

and / or the completeness and accuracy of the data migrated during the entire exercise of data migrations.

Any gaps / discrepancy observed will be reported in writing to the Bidder, who will act upon it and resolve the

same immediately or within 5 working days from the day of reporting the same.

Bidder will be responsible for documentation of the entire process of data extraction to migration and

reconciliation in a manner which can be understood by the auditor / regulator / bank etc. as data

management sign-off is one of the RBI IRB requirement.

Deliverables

a. Data Extraction, Preparation, Validation, Migration and Reconciliation

b. Documentation of entire Data Migration including Change Management Process

H. Report

Vendor should ensure that all the required reports by the regulator and MIS including ad-hoc reports are

created, customized, configured and parameterized in the system including the work-flow.

Bank will test all the reports as part of the UAT. If regulatory reports are not issued by RBI then vendor will

provide them at the time RBI issues the requirements for IRB and Std. approach.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

148

The Bidder shall provide for all subsequent changes to reports as suggested by the statutory and regulatory

bodies from time to time immediately to the Bank at no additional cost to the Bank throughout the period of

the contract, warranty and AMC.

Vendor will make all above reports available at no extra cost to the bank.

Deliverables

a. Development, creation and configuration of regulatory, MIS and Ad-hoc reports into the system as no

extra cost to the bank

b. Reporting Templates

I. User Acceptance Testing

The Bank proposes to conduct a “User Acceptance Test” (“UAT”) testing for the purpose of ensuring that all the functionality requested for by the Bank is available and is functioning accurately.

The Bidder will convey to the Bank that all the customizations that are required to “Go Live”, as agreed upon and signed-off by the Bank are completed and the solution is ready for testing.

The Bidder will set up a test server(s), to accommodate a minimum of 10 concurrent users and install the Applications including the customizations, parameterize it as per Bank’s requirement. The Bank expects the test environment to be available to the Bank at all times, for the purpose of testing. The Bank expects The Bidder to set up the required solutions and provide connectivity to test server at DC at the desired testing center of the Bank for the purpose of testing. The Bank shall not pay any additional amounts to The Bidder for the purpose of creating the test environment.

It will be The Bidder’s responsibility to establish connectivity of the test PC’s to the Test server for facilitating UAT. The test PCs will be provided by the Bank.

The Bidder will prepare the test plans, test calendars, test schedules (day- end, month-end etc.), test cases, defining the acceptance criteria, monitoring the testing on a day to day basis’, timely resolution of gaps, errors, bugs reported during testing and providing continuous support to the users for the UAT and acceptance testing. The acceptability rests with the Bank but the end to end support for the same will have to be provided by The Bidder. Bank will review and manage the entire UAT process to its satisfaction.

Vendor will be responsible for conducting the entire UAT under the supervision and management of the

bank.

Vendor will provide UAT Test Cases for all the module of the offered system for IRB requirements

Bank will review test cases provided by the vendor and can give its comments for modification, deletion

or addition of new test cases which vendor will do.

Final set of test cases after incorporation of bank’s review comments will be provided by the vendor

Vendor will also prepare expected results of all the UAT test cases prepared by him which will be

reviewed and approved by the bank

Bank will sign-off the test cases and expected results

Vendor will convert the test cases into UAT data for uploading and execution in the system

Vendor will convert UAT using bank’s data as well as hypothetical data, which will be decided by the

bank


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

149

Vendor will prepare UAT environment and will be responsible for all the activities related to UAT

Vendor will give expected results to the bank for verification in a format and manner which can be

understood by bank’s business users

Bank will verify the results and highlight the issues / observations for vendor to analyse, troubleshoot

and resolve within the timeframe of UAT

Any deviations / discrepancies / errors observed during the testing phase will be formally reported to the

Bidder and the Bidder will have to resolve them immediately or within 2 working days

Bank will review and resolution done including its documentation

Vendor will document the entire UAT process including all the UAT issues

UAT test cases, expected results, test data, system results, issue tracker and any other UAT document

shall be prepared in a proper manner which can be understood by any third person such as auditor,

regulator etc.

Bank will review the complete UAT documentation prepared by the vendor and then will provide sign-off

Deliverables

a. UAT Approach, Process and Plan

b. UAT Test Cases including their Expected Results

c. UAT Data

d. UAT Results

e. Issue Tracker

f. UAT Documentation

J. Sample Roll-out,

After successful UAT of the System, vendor will roll-out all the components of the system using bank’s data

covering the following:

Asset class mapping

Securities mapping

Configuration and parameterization of risk estimation model in the CRM system including building of

the models used by the bank

Bank’s risk estimation models (PD, LGD, EAD and M for retail and non-retail portfolios) creation /

configuration on the system and demo using bank’s own data

Capital computation as per IRB and Std. approach

Model validation for risk estimation models, retail pooling etc.

Stress Testing

Generation of regulatory and MIS reports (all the reports configured in the system)

For sample roll-out, bank will decide business unit / product / geography


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

150

Deliverables

a. Model Configuration Documentation

b. Model Validation Report

c. Capital Computation Results and Reports

d. Stress Testing Results and Reports

e. Regulatory and MIS Reports for all the activities mentioned above

K. Training / Workshop and Knowledge Transfer

The Bidder will be responsible for training the Bank’s employees in the areas of implementation, operations, management, error handling etc. The Bidder needs to provide a comprehensive training methodology document and the training should at least cover the following areas:

o Functionality available in the solution o System & Application Administration at Risk Management Department

The Bidder will be responsible to train all users in the Risk Management Department of the Bank.

The Bidder must ensure that proficient personnel conduct the training. The Bidder shall ensure trainers

are proficient and experienced enough in the topic of training. The Bidder should ensure that the end

user training is scheduled and completed at least a week prior to the proposed solution implementation.

Provide 5 trainings to the bank personal on all the modules and each training may have 25 participants.

Training should cover all the aspects such as configuration, parameterization, risk estimation modelling,

asset class mapping, securities mapping, and capital computation, model validation, stress testing,

ICAAP, Basel III and all other areas covered under CRM scope.

In addition to above, vendor will provide 2 trainings to technical and admin users. Number of participants

in each training would be approximately 20.

Conduct 3 number of workshops on PD / LGD / EAD, Effective Maturity, BEEL, Capital Computation under

IRB to Credit Risk Management Department

The Bank expects The Bidder to provide a detailed training schedule for the Bank’s IT Personnel and then provide training in:

o Application Management; o User Management; o Backup & Recovery Operation & management;

Training material / Presentation / Deck / Document shall be prepared by the vendor specific to bank

requirement and it should not be generic in nature.

Vendor should plan sufficient time for the training so that all the aspects can be covered considering the

level of the participants.

Deliverables

a. Training Presentations

b. Workshop / Training Session as specified by the Bank


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

151

L. Production Migration

To complete all the activities required to completed before migration to the production as per scope in this RFP

Ensure that all the activities / tasks required for production migration are completed by the vendor

Deliverables

a. Documentation on Production Migration

M. System Maintenance

Perform daily maintenance activities like day – end, month end, quarter ends, and year ends, uploads, downloads trouble shooting, problem resolution, servicing and maintenance etc.

Adhere to service levels as mentioned in the RFP

N. System Version Migrations

Vendor to perform version migrations and updates during the period of the contract at no extra cost to

the Bank.

Vendor will have to provide changes in the system if there are changes in the regulatory guidelines and

same are no0t supported by the system. If due to regulatory changes, system is required to be enhanced,

customized, or modified, then vendor will do for the bank at no extra cost.

O. Workshops and Handholding for Migration to IRB Approach Besides the User Training to be provided for the software, conduct training workshops to familiarize the RMD

staff regarding the relevant frameworks for Credit Risk Management. Provide support for applying to RBI till

accreditation for migrating to the IRB approach is obtained from RBI.

P. Documentation Vendor to provide model documentation, detailing of statistical/mathematical models used, theory,

assumptions, empirical data used to estimate the model and the circumstances under which model will not

work along with out of time and out of sample performance test.

If bank requires any other documentation in addition to what is specifically stated in this RFP, vendor will

have to prepare and provide the same to the bank at no extra cost. Documentation may be required in

model validation purpose, stress testing, to response regulatory and audit queries, to understand system

logic etc.

Q. Other Requirements

Maintain and support the solution by providing dedicated personnel to the Integrated Risk Management

Department throughout the contract period. The dedicated personnel are to be posted at Mumbai.

Implement the solution as per the defined timelines i.e. within 12 months of signing of the agreement


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

152

with the selected bidder.

Adhere to Service Levels as mentioned in the RFP.

Garner the support of the OEM in building interfaces and during the entire implementation period to the

said applications

Support the interfaces, hardware and other infrastructure at Data Centre & Disaster Recovery Centre as

proposed and provided as part of this project.

Be a single point of Contact to the Bank

The Bidder will ensure that they have the necessary infrastructure and people in place to resolve all the

gaps within the time lines agreed, for the implementation.

The Bidder shall customize all gaps observed in the Functional RFP, Product Demo, Current Systems

Study, Training and UAT and pilot rollout. The cost of customization should be included in the price bid.

The Bank will not pay any additional customization costs. The Bidder shall document all gaps observed by

the Bank at various stages of implementation including their solution and monitor and track the status of

the same though out the implementation.

In addition to above, 0ther specific implementation requirements for Credit Risk management are as

follows:

Sr.

No.

Implementation Requirements Bidder’s Implementation

Approach

1 Data management

1.1 The software should be interfaced with the source systems such

as CBS (Bancs24) for transactional & master data of the

exposure & borrower; also the collateral & recovery data has to

be sourced from Bancs24 to Capital computation engine.

The software should also be interfaced with Credit Rating

system for internal credit rating for non-retail borrowers and

scores of retail borrowers.

(bank will decide mode of interface such as direct with the

source system, staging area or data warehouse or combination

of all)

1.2 The solution should be able to extract required data from the

existing systems as mentioned above and perform data

cleansing / validation as required. It should create a data

repository for all the subsequent implementation requirements.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

153

Sr.

No.


Approach

2 IRB Model development: As part of this module, the vendor would develop PD/LGD/EAD models for retail and non-retail portfolios of the bank. Bank will review and sign-off the models development including their documentation and methodology. This would cover: a) Data extraction: Extract of required historical from source

systems required for model development. The Bank's IT department would support the vendor in terms of data system understanding and facilitate extraction of data requested by vendor.

b) Model development: Develop the required models using the Bank approved model development methodology in the proposed system through GUI screens and perform pre-implementation testing. All the statistical tests should be run out of the proposed system.

c) Model documentation: Develop detailed model development documentation for the developed model covering the data extracted and transformations applied, step by step model development process and results at each step, final model, expert judgment applied in modelling process.

d) Implement the model for capital computation process The vendor is required to develop and implement the following

models in the proposed system.

2.1 PD calibration for non-Retail borrowers. the methodology would

be either calibration curve fitting or LDP calibration depending

on number of data points available for each portfolio

2.2 LGD estimation models for non-Retail borrowers - models

would be required based on workout LGD methodology

(recovery cash flow data collection, workout period estimation,

cash-flow discounting, realized LGD computation and LGD

estimation model fitting)

2.3 EAD estimation models for non-retail borrowers -models would

be required to estimate CCF or revolving facilities and off-

balance sheet facilities.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

154

Sr.

No.


Approach

2.4 Retail Pooling and PD computation model based on clustering

techniques

2.5 LGD estimation models for retail portfolio using work out LGD

method

2.6 Supervisory slotting criteria model for each infrastructure/

specialized lending asset class (5)

2.7 Behavioral scorecards based on standard statistical scorecard

development techniques for the retail portfolio. These

behavioral scorecards to be used as input for retail pooling as

well as PD calibration for retail borrowers.

3 IRB Model Validation: the vendor should configure the standard model validation techniques in the system. Post development of the IRB models as listed above, the vendor is required to develop quantitative model validation test results for each of the model and provide documentation for the same. Following tests should be performed in the system and results documented: a) PD, LGD & EAD models: back testing results b) Behavioral scorecards: Factor level and model level

Information value, gini, population stability index, KS Statistic results for in-sample and out of samples.

4 RWA computation rules

4.1 Study the bank's asset class, product types and create the

mapping to RBI defined asset classes within the system. The

asset class allocation methodology would have to be developed

by the vendor and configured in the proposed system which

would cover all the asset classes the Bank has exposure to.

(Corporate, Bank, Sovereign, Retail, purchased receivables).

4.2 Configure the rules to perform credit risk mitigation both under

F-IRB and A-IRB approaches as per RBI guidelines.

4.3 Configure rules to assign PD, LGD & EAD to each exposure based

on the models configured in the system in the previous module.

5 Capital management, ICAAP, Stress Testing: For the purpose of


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

155

Sr.

No.


Approach

Capital management, stress testing and development of ICAAP,

the Bank has developed various models. The vendor is required

to develop and implement these models in the proposed system

as per the following steps:

5.1 This would cover a) Data extraction: Extract of required historical from source

systems required for model development. The Bank's IT department would support the vendor in terms of data system understanding and facilitate extraction of data requested by vendor.

b) Model development: Develop the required models using the Bank approved model development methodology in the proposed system through GUI screens and perform pre-implementation testing

c) Model documentation: Develop detailed model development documentation for the developed model covering the data extracted and transformations applied, step by step model development process and results at each step, final model, expert judgment applied in modelling process.

d) Implement the model for ongoing usage and report generation.

The following models/analytical approaches are to be

developed and implemented in the system

5.2 Credit concentration risk assessment (HHI, Gini) and

quantification model for single name (Granularity adjustment)

and Sectoral concentration (Multi-factor adjustment) Model.

This model is applicable only for corporate segment.

5.3 RAROC model for risk based pricing and performance

measurement

5.4 Stress testing: The vendor is supposed to implement the RBI

guidelines on stress testing for the Credit risk portfolio of the

Bank. The Bank would provide its stress testing policy and broad

methodology adopted for various credit risk portfolios and the

scenarios.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

156

Sr.

No.


Approach

5.5 Configure the regulator specified sensitivity and scenarios in the

system and assess their impact on Capital, liquidity and

profitability

5.6 Configure the Bank specific stress scenarios in the system

5.7 Develop and implement the following stress testing models in the system: a) Macroeconomic time series models for stress testing of NPA

position of corporate portfolio, Retail portfolio, SME portfolio and Agriculture portfolio through time series regression modelling

b) Models to quantify the impact of stress scenario on profitability, capital and Liquidity position of the Bank.

6 Report configuration: The vendor is supposed to configure the

mandatory regulatory reports and internal monitoring reports

and dashboards. For each report/dashboard, the bank would

provide the business requirements.

6.1 The following steps are expected to be adopted for report development and configuration a) Develop a prototype of the report/dashboard and obtain

functional signoff b) Develop the report/dashboard by defining the report

format and defining the right underlying data c) Implement the report for periodic report generation on an

automated basis. The vendor is expected to develop and implement the following

reports

6.2 Regulatory mandatory reports: The vendor is develop and implement a) Pillar 3 quantitative disclosures reports b) RCA3 returns reports c) Basel II IRB submissions to Regulator d) Basel III Reports

6.3 Internal reports: The vendor is expected to create (in the

system) at least 40 reports and at least 10 CXO level

dashboards. The formats of the reports and dashboards will be


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

157

Sr.

No.


Approach

shared by the successful bidder which bank will review and

approve.

Reports should be comprehensive to cater management,

portfolio and bank wide requirements and provide last

granularity of the transaction with drill-down facility). Vendor is

to give a detailed write-up on this in their response clearly

identifying number of reports, areas covered and their

granularity.

- Number of Reporting Templates

- Coverage of all the areas of IRB requirements

- Relevance to Indian Banking

-Relevance to Bank’s products, geographies, asset classes,

business units, portfolio and operations

- Purpose and value addition of each report

- Mapping to all Basel dimensions plus business dimensions

- Formatting and uploading into the offered system

- Ease of understanding

(All the reports provided and approved by the bank will be

created, configured, customized by the bidder)

(Bank will discuss and evaluate all the reporting templates provided by the bidder, It can modify the templates provided by the bidder in order to customize them as per bank’s business and risk profile) For regulatory report, if RBI has not yet issued reporting

templates, then vendor will provide them at a later stage

without any extra cost to the bank. Vendor will define, configure

and parameterize regulatory reports in the system and they will

be accepted by the bank after their UAT

6.4 Vendor to provide additional detailed reporting templates for

creation into the system. Reports should be comprehensive to


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

158

Sr.

No.


Approach

cater management, portfolio and bank wide requirements and

provide last granularity of the transaction with drill-down

facility). Vendor is to give a detailed write-up on this in their

response clearly identifying number of reports, areas covered

and their granularity.

- Number of Reporting Templates


- Relevance to Indian Banking

- Relevance to Bank’s products, geographies, asset classes,

business units, portfolio and operations

- Purpose and value addition of each report




(All the reports provided and approved by the bank will be

created, configured, customized by the bidder itself)

(Bank will discuss and evaluate all the reporting templates provided by the bidder, It can modify the templates provided by the bidder in order to customize them as per bank’s business and risk profile) Vendor to provide 30 reporting templates in addition to

reporting requirements required by RBI for IRB approach. If RBI

has not yet issued reporting templates, then vendor will provide

them at a later stage without any extra cost to the bank. Vendor

will define, configure and parameterize regulatory reports in the

system and they will be accepted by the bank after their UAT

7 The vendor should configure the advanced approach

computation rules as per the latest RBI guidelines (December

22, 2011). The Vendor should also configure methods to

compute capital using multiple Basel II Advanced approaches for


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

159

Sr.

No.


Approach

multiple jurisdictions

8 Vendor to provide detailed test scenarios and test cases with

their expected results duly formatted and having all the

required information and mappings as per Basel II & RBI

requirements.

Test cases must include all the requirements of RBI / Basel II

guidelines for IRB approach and specific scope items covered

above. Bank will review them, modify (add, delete to suit its

business and risk profile) and sign them off.

- Number of Test Cases


-Relevance to Indian Banking and bank’s business and risk

profile

-Relevance to Bank’s products, asset classes portfolio and

operations


- Calculation of expected results



(Bank will discuss and evaluate all the test cases provided by the

bidder and vendor will modify the test cases basis the review

comments provided by the bidder in order to customize them as

per bank’s business and risk profile

9 Documentation Requirements

9.1 The vendor should provide extensive documentation on the

following areas of the software:

9.2 Application Architecture


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

160

Sr.

No.


Approach

9.3 Database Schema, Entity Relationship Diagram & Data

dictionary

9.4 User Manuals, Administrator manuals

9.5 Error Messages and their Meanings

9.6 Training Manuals

9.7 Additions / changes to the documents after upgrades

7.2 Functional Requirements for Credit Risk Management Solution

The detailed minimum functional requirements for this system are as under. If any of the requirements mentioned in RBI / Basel II / Basel III Guidelines with respect to IRB approach but not specifically covered here, system must support them too and same are part of the scope of this RFP.

Sr. No. Credit Risk Functional Requirements Maximum Marks


1.1 The system should be able to capture and receive the required data (data entry, m a n u a l file uploads, direct transfers, i n t e r f a c e w i t h b a n k ’ s s y s t e m s , batch processes, etc.) from various source systems (internal and external to the bank) like Core Banking Solutions, Internal Rating models / Systems, Data Warehouse, Staging Area, etc. and support various formats (viz. .txt, .XBRL, .CSV, .XML, excel, PDF etc.)

System should have a capability to take data (through manual data upload facility, if direct interface i s n o t p o s s i b l e o r i f b a n k d e c i d e s n o t t o d o d i r e c t i n t e r f a c e ) related to balance sheet, profit & loss, cash flow statements o r a n y o t h e r d a t a w h i c h a r e m a i n t a i n e d m a n u a l l y , using pre‐defined excel sheets and other data formats (viz. .txt, .XBRL, .CSV, .XML) apart from the different systems that Bank is using.

4

1.2 The bank already has internal credit rating models and score cards which

are system driven. Hence, bank does not intend to purchase any new

rating models at present.

0

1.3 The proposed software solution should be capable of interfacing with

existing and future credit rating systems / score cards / Models, Internal

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

161


(such as CBS, LAS, FTP, CLASS, RAM etc.) and External Source Systems of

the bank in an automated manner – through direct interface with the

rating / scoring source systems, through staging area or through data

warehouse as decided by the bank without any manual intervention.

1.4 The proposed software solution should have flexibility to add any

number of rating models and scorecards in future through automated

interface and / or through manual processes.

2

1.5 System should have the capability of interfacing with the proposed

market risk solution presently in use as well as in future to generate

customized reports which may include an overall dashboard for risk

capital numbers or other such reports at bank‐wide level.

The system should be able to support an interface with Treasury systems

from where the VaR numbers can be fetched

Interface with external third party system will be of batch processing.

2

1.6 System should have ability to track and store account‐wise previous credit

ratings (external and internal) / scores and LGD.

2

1.7 The system should be able to store a l l the data for at least seven

years extendable up to 15 Years.

Data can be related to customer, security, transaction / facility, credit

rating, credit scoring, defaults, risk components modelling such as PD, LGD

& EAD, retail pooling, capital computation, retail pooling, models

validation, MIS and regulatory reporting including reports itself etc.

Data can be related to FIRB / AIRB Approaches. The bidder is required to

size the storage up to the contract period of 7 years.

Data can be input as well as put data both.

2

1.8 The system should have the provision to run FIRB/ AIRB approach for

certain asset classes in the same execution / cycle for one legal entity as

bank may adopt partial implementation approach as per Basel II / RBI

Guidelines.

3

1.9 System should have capabilities to host the models developed by the bank

AND if any new model is to be developed then system should have

statistical capabilities to develop all the models regarding capital

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

162


computation as per IRB requirements, Stress Testing and ICAAP. This

model hosting and development on the system should support all the

approaches as specified by RBI / Basel II / Basel II guidelines under IRB

approach and should consider data available with the bank including other

constraints and assumptions. Model hosting and development must

support expert judgment models, statistical models and hybrid models

based on the data available with the bank.

2 Risk Modelling Capabilities 105

2.1 Scorecard/ Rating model development capabilities 5

2.1.1 The system should enable development of credit scorecards and credit rating models using following statistical techniques (inclusive): 1. Linear regression 2. Logistic regression 3. Clustering

3

2.1.2 The system should provide GUI (Graphical User Interface) to provide the

standard scorecard development steps like data cleansing, single factor

analysis, multifactor analysis, log-odds scaling and final scorecard

generation. Lack of GUI would be treated as non-compliance.

2

2.2 Probability of default modelling: The system should enable development

and configuration of

20

2.2.1 Calibration curve fitting approach 3

2.2.2 Low default portfolio calibration approach for large corporate 3

2.2.3 The solution should provide the ability to estimates Probability of Default

(PD) / long run PDs using internal rating grades and default history across

all exposure types.

4

2.2.4 The solution should be capable for computing PD based on Internal loss

history, External rating based, Statistical based approaches as per Basel II

/ RBI Guidelines for IRB approaches (e.g. - as per all RBI / Basel II

Guidelines). Vendor to develop at least 8 PD models for Non-retail portfolio

using bank’s data and bank’s portfolio and as per Basel II and RBI

guidelines.

4

2.2.5 The solution should be capable of computing Through‐the‐cycle PD and 3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

163


Point‐in‐time PD. The system should be capable to convert a PIT PD to

TTC PD and vice versa.

2.2.6 The solution should support estimation of PD for low default and low

data portfolios

3

2.3 Loss given default (LGD) modeling: The system should enable LGD

modeling using workout LGD methodology and provide ability to perform

the following steps

20

2.3.1 The solution should support both the Foundation as well as

Advanced approaches for collection of LGD data components and

estimation of facility wise Loss Given Default (LGD) –

both economic LGD and accounting LGD‐ across all exposure types (On

and Off Balance sheet exposures), both for defaulted/ restructured

accounts. The system should be capable of computing LGD using market

based LGD, implied LGD and work‐out method as per the nature,

applicability and data availability of credit risk exposures. Further, the

system should be able to drill down the LGD estimation into

industry wise, vertical wise, product wise, workout method wise, year

wise/quarter wise/Other frequencies/, collateral‐wise and offer additional

drilldown options and reports. It should also support analytics for

estimating PD & LGD correlation. Vendor to develop at least 8 LGD models

using bank’s data and as per bank’s portfolio as per Basel II and RBI

guidelines.

3

2.3.2 The system should be able to fetch default and recovery information from

various source systems and data cleansing

2

2.3.3 Choose a discount rate for discounting of recovery cash-flows and recovery

costs

2

2.3.4 Compute the workout period for each portfolio 2

2.3.5 Compute discounted LGD 2

2.3.6 Develop LGD prediction models using 1. Linear regression 2. Logistic regression 3. Clustering

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

164


2.3.7 Support GUI interface for end to end LGD modeling 1

2.3.8 The solution should distinguish between senior and subordinated facilities

allocating required LGD to unsecured portion of the facility as per IRB

guidelines

2

2.3.9 The solution should provide for effective LGD where the Bank is having

other financial/AIRB collaterals and pool of collaterals

2

2.3.10 The system should be able to compute Downturn default weighted LGD as

per RBI/ Basel guidelines.

2

2.4 Exposure at Default (EAD) 10

2.4.1 The solution should provide for EAD / CCF and Effective Maturity (M)

calculation for both on and off balance sheet items.

Vendor will develop at least 7 EAD models for bank’s portfolio as per Basel

II and RBI guidelines.

For estimation of EAD & CCF, it should also do undrawn analysis, UGD

(Usage Given Default) analysis etc. and generate reports

2

2.4.2 The system should have capabilities to capture outstanding and limit

information for all revolving and off-balance sheet exposures

2

2.4.3 The system should have capabilities to compute realized CCF (Credit

Conversion Factor) for defaulted exposures

2

2.4.4 Capability to develop CCF prediction models using 1. Linear regression 2. Logistic regression 3. Clustering

4

2.5 Retail Pooling (as per RBI / Basel II IRB Requirements) 20

2.5.1 The system should support the below techniques (at minimum) for statistical clustering (Applicable for Retail Pooling) inclusive - 1) CART (Classification and Regression Tree) 2) CHAID (Chi-Squared Automatic Interaction Detector)

3

2.5.2 The system should also allow the user to specify pooling criteria based on

the expert judgment. The system should generate decile based results

based on the user provided risk drivers and let the user define judgmental

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

165


thresholds.

In addition to this; System should have a capability to develop expert

defined models / scorecards, statistically developed models/score cards

and hybrid models and provide application and behavioral scorecards

2.5.3 The system should be able to store the data for at least five years at an

account/transaction level to perform the pooling process.

2

2.5.4 The system should be able compute various statistical measures to

demonstrate homogeneity within a pool and heterogeneity across the

pools (E.g.: Gini ratio, Information value etc.)

Vendor to ensure that homogenous pools of retail exposures formed in

consultation with the Bank in compliance with IRB guidelines.

Vendor should have a capability to demonstrate that retail pooling models

and methodology are compliant with the requirement of IRB

Approaches as per RBI / Basel II guidelines.

The system should be capable of performing pooling based on statistical

analysis, application/ behavioral scores and expert judgment. At a

minimum the system should support clustering techniques such as CART,

CHAID and regression trees etc. The logic of pooling should be configurable

in the system. The pooling logic is subject to change on at least at a

yearly basis. Hence the pooling logic should be defined by user interface

through graphical presentation and should not require any

programming or vendor assistance.

2

2.5.5 The system should have the capability to assign/map new exposures into

the created pools.

The system should have the ability to capture retail exposures at an

account level, assign each exposure to a particular retail pool based on

well-defined risk drivers such as borrower type, demographics,

products, collateral, delinquencies etc. (not limited to these dimensions)

to estimate Pool PD, LGD and EAD.

2

2.5.6 The system should be able to estimate the PD, LGD and EAD for retail

exposures at a pool level. Vendor will develop 30 PD and 30 LGD models for

bank’s retail portfolio as per Basel II and RBI guidelines.

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

166


2.5.7 The system should generate reports to monitor/track pool stability and

accuracy.

2

2.5.8 The system should be able to update the pool allocation on a periodical

basis based on latest behavioral information

System should have a capability to compute behavioral score for the

retail products as a whole on a periodic basis

3

2.6 Basic modeling techniques: The system should support the following

basic modeling steps

5

2.6.1 Sampling techniques (Simple, stratified, random etc.) 1

2.6.2 Missing value imputation 1

2.6.3 Outlier detection and elimination 1

2.6.4 Variable transformation (Transformations like natural log, exponential,

inverse, sin, root etc. should be available)

1

2.6.5 The Regression modellings like below should be supported 1) Simple, 2) Multiple, 3) Logit, 4) Probit, 5) GLM (Generalized Linear Model) 6) GLMM (Generalized Linear Mixed Model) etc.

1

2.7 Model Validation: The software should be capable to support

quantitative model validation techniques as prescribed in Basel II

Working Paper 14. In particular, the software should support conducting

the following tests at Model level and each individual factor level:

15

2.7.1 Discriminatory power tests - Gini Curve, Accuracy Ratio, ROC Curve, Area

Under Curve, Comparison of Goods and Bad (Comparison of average model

score in case of defaulted and non-defaulted borrowers)

3

2.7.2 Calibration Test - Hosmer Lemeshow Test, Kolmogorov-Smirnov (KS) Test,

Concentration Analysis in rating grades and individual factor scores.

2

2.7.3 Stability Test - Population Stability Index (PSI) Test 2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

167


2.7.4 Additionally, the system should provide other factor level tests such as

Good vs. Bad analysis, Log-odds trend analysis

2

2.7.5 The software should provide the results of above tests in pre-defined

report formats (tabular and graphical formats)

2

2.7.6 Back testing techniques for PD, LGD & EAD models 2

2.7.7 The system should have the capabilities / Functionalities / Tools to validate

credit rating models / score cards / risk estimation Models (PD, LGD and

EAD) / Retails Pools on continuous basis and the same is to be done in

compliance with RBI / BCBS Guidelines.

The system should provide documented methodology and tools for

validation of above on continuous basis.

The validation process should help the Bank to meet regulatory

requirements of RBI / BCBS.

Validation process should enable the Bank to assess the

performance of internal rating and risk estimation methods

consistently and meaningfully.

Vendor should give complete documentation of validation methodology

including user manuals.

2

2.8 Maturity(M) 5

2.8.1 The system should be able to calculate Effective Maturity for corporate

exposures

2

2.8.2 The system should interface with CBS to capture the individual cash flow

information (Cash flow amount, data, type etc.) for corporate exposures

3

2.9 Modelling – Other Requirements 5

2.9.1 The solution should provide necessary treatment for repo style

transactions/ guarantees/ credit derivatives under both foundation as well

as advanced approaches

1

2.9.2 The solution should provide exposure adjustment by segmenting it into

portions covered by different collateral and guarantee types and portion

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

168


remaining unsecured as per Basel‐II/ RBI guidelines

2.9.3 The system should have the ability to capture and map PD, LGD, EAD and

Maturity for the FIRB/AIRB asset classes and apply the same in capital

calculations.

1

2.9.4 The solution should support development of multiple PD, LGD & EAD

models and should enable for validation.

1

2.9.5 The solution should be able to generate PD, EAD, LGD for sub‐ portfolio

like industry, sector, Geography etc.

1

3 Capital Computation Rules 50

3.1 Capital Computation General 10

3.1.1 At present Bank is following Standardized Approach.

The solution should support multiple approaches simultaneously for

multiple legal entities for the banking group for a given point of time.

The solution should support multiple approaches IRB as well as Std.

Approach both simultaneously within one legal entity for a given point of

time as bank may adopt partial roll-out for certain asset classes.

System should allow this partial roll-out on all the criteria as given in RBI

Guidelines for IRB approach

2

3.1.2 System should support computation of capital with exemption to certain

portfolio(s). System should be able to exclude exempted exposures in the

capital computation but still taking data from bank source systems as it

may be required for reporting purposes

2

3.1.3 The system should be able to perform firm‐size adjustment for small

and medium size entities

1

3.1.4 The solution should provide methodology for computation of Expected

Loss (EL), best estimate of Expected Loss, UL, and RWAs for Credit risk

under both foundation as well as advanced approaches for defaulted / non-

defaulted exposures

1

3.1.5 The system should support VaR model (99th percentile, one tailed), i.e. the

system should have the ability to build VaR Model. The system should be

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

169


able to take the equations as per regulatory formulas and perform capital

calculations

3.1.6 The system should be able to compute expected/unexpected

portfolio losses incorporating:

Default risk/transition probabilities

Recovery rates

Correlation and diversification effects between counter parties

1

3.1.7 The system should be able to capture Failed Trades ('Delivery versus

Payment' and 'Non Delivery versus Payment') i.e. unsettled securities and

foreign exchange transactions) and should be able to calculate capital as

per Basel II Guidelines

1

3.1.8 The system should be able to calculate capital requirement individual account‐wise and also units‐wise such as:

Entire Bank

Region/zone

Geography

Industry

Business segments

Products

Rating wise

Branch

Relationship Manager

1

3.2 Asset classification: This section covers all the system requirements

pertaining to capture of bank data and assigning each credit exposure

into one of the RBI defined asset classes (Corporate, Bank, Sovereign,

Retail, Purchased receivables and Securitization)

10

3.2.1 The system should provide a graphical user interface to enable the business

users to alter the risk weighted asset computation rules as per the

directives of RBI released in future.

There should no back-end programming required for performing asset

classification based on the source system data. If this requirement is not

yet available, score for this entire section would be zero

All the asset classes as defined in RBI circular should be supported by the

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

170


system for IRB approach

3.2.2 The system should provide GUI to perform mapping of : a) Bank asset class to Basel asset class b) bank product type to Basel product type c) Bank security type to Basel security type

The solution should have the ability to map the internal risk grades of the

specialized lending subclasses (PF, OF, CF, IPRE and HVCRE) to supervisory

categories as per Basel‐II guidelines.

Enable the user to define multiple portfolios or asset classes based on

multiple dimensions (such as borrower constitution, industry, product

type, loan amount etc. but not limited to) and associate borrower rating

model and facility rating models to the user defined portfolios.

The system should provide business user friendly graphical user

interfaces (GUI) to perform bank classes to Basel II data mappings.

Map Bank customer types to Basel II customer types

Map Bank product types to Basel II product types

Map Bank security/collateral types to Basel II collateral types

Map Bank asset type/guarantor type to Basel II asset type

Any other mapping as required under RBI/ Basel II guidelines

Above mapping should not involve coding, involvement of technical

configuration, customization etc.

2

3.2.3 The software should be flexible for the business user to use multiple

factors such as customer constitution code, product type, exposure

amount, legal status etc. to perform Basel II asset classification.

The solution should be able to capture all the Bank Customer Types, Bank

Product Types, and should be able to reclassify/categorize them as Basel

asset class wise.

The solution should support categorization of asset classes and sub

classes as defined under IRB approaches as given the Basel II Accord / RBI

guidelines (Corporate, Sovereign, Bank, SME, SL classes, Retail, QRRE,

equity, purchased receivables, securitized etc.).

The software should be flexible for the business user to use

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

171


multiple factors such as customer constitution code, product type,

exposure amount, legal status etc. to perform Basel II asset

classification and Basel II collateral classification.

The system should be able to define portfolio based upon the

following aggregation possibilities such as:

Counter‐party or combination of counter parties

Industry / Sub-industries

Tenor

Product

Geography

Issuer

Credit rating

Currency

Any internal hierarchy

Combination of above dimensions

And should allow drill down capabilities up to transaction level

3.2.4 The user should be able to view the entire asset classification schema and it

should be printable to be submitted for regulatory inspections and audits.

2

3.3 Credit risk mitigation 15

3.3.1 The system should support all the credit risk mitigation techniques

specified in the RBI circular on NCAF and IRB guidelines.

Along with the eligible financial collateral recognized in the

Standardized approach, the solution should recognize the other eligible

FIRB/AIRB collaterals and provide necessary treatment as outlined in the

Basel II accord/RBI guidelines.

1

3.3.2 The system should have the ability to map the Collateral/Security Types

(which the bank uses for internal reporting) into collaterals types as per RBI

Guidelines (Cash, Gold, KVP, Life Insurance, Debt Securities, and Mutual

Funds etc.)

The solution should be able to capture all types of risk mitigation inputs

and should have the ability to reclassify/categorize the bank’s risk

mitigation tools / mechanisms into Basel defined risk mitigation inputs

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

172


types as per Basel II Guidelines/ RBI guidelines. The solution should be able

to allocate different collaterals to different facilities using multiple

algorithms, approaches (Simple, comprehensive, FIRB, AIRB) and Basel‐II

guidelines by RBI.

3.3.3 Provide a GUI to define the hair-cuts for various collateral types as defined

in RBI guidelines.

The solution should have the ability to compute, make estimates, and

apply haircuts on collaterals and exposures as per Basel‐II accord/ RBI

guidelines on IRB approach.

1

3.3.4 The system should be able to apply supervisory haircut on exposures and

mitigants, and compute capital after applying Credit Risk Mitigation

techniques as per RBI Guidelines.

1

3.3.5 System should support collateral optimization as well as pre-defined ranks

provided by the bank both.

1

3.3.6 The system should have the ability to assign the risk weights for Guarantors

as per RBI Guidelines.

1

3.3.7 The system should be able to capture the relevant data fields for Currency

and Maturity Mismatch calculations and should also be able to apply the

haircuts as per RBI Guidelines.

1

3.3.8 The system should be able to capture collateral which is a basket of

collaterals and should also be able to calculate the haircut on the basket of

collateral. Haircuts applicable on the basket of assets should be taken into

account while calculating the capital as per RBI Guidelines.

The system should be capable of applying a weighted average of haircut

if the collateral is basket of assets as per RBI / Basel II guidelines.

1

3.3.9 The system should be able to perform on balance sheet netting and capital

calculation based on the net credit exposure.

1

3.3.10 The system should be able to apply haircut scaling formula (based on

holding period and frequency of reimagining/revaluation period) as

prescribed by RBI Guidelines.

The solution should make adjustments for different holding periods based

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

173


on the quality of collaterals and non‐daily mark to market or re‐margining

3.3.11 The system should be able to capture guarantee, counter guarantee and

credit derivative details and should be able to calculate capital as per RBI

Guidelines.

1

3.3.12 The system should be capable of computing the collateralization levels and

FIRB rules based on the collateral information.

The system should allow user to compute for eligible IRB collaterals (viz.

minimum ‐ collateralization or over‐collateralization or under‐

collateralization)

1

3.3.13 The system should have pre-build rules for double default framework for

hedged portfolio, capital computation

The solution should be able to use double default methodology for capital

computation.

The system should be able to apply double default treatment for the

hedged portion and compute capital requirement for double default

In case of maturity mismatch for double default transactions and other

transactions, then the system should be able to perform the maturity

adjustment as per Basel II Guidelines.

The system should be able to do calculations for currency mismatches also

1

3.3.14 System should be able to do collateral optimization as well as bank defined

mapping / ranking of collaterals against an exposure

2

3.4 RWA computations 15

The system should come with pre-build rules for computation of RWA for: 0

3.4.1 Corporate – Non SME 2

3.4.2 Corporate – SME 2

3.4.3 Bank 1

3.4.4 Sovereign 1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

174


3.4.5 Retail 2

3.4.6 Equity Exposures through 1. Market based 2. Simple risk weight 3. PD/LGD approach 4. Internal Models Method The system should support interface with treasury/market risk systems to

fetch equity related data.

2

3.4.7 Securitized exposures: the system should be able to 1. Capture the bank roles (e.g. Originator, investor etc.) for the

securitization exposures(on balance sheet, off balance sheet, drawn and undrawn portions), and should calculate the capital as per RBI Guidelines

2. Apply CCF's and calculate capital for securitization exposures with early amortization features.

3. Supervisory formula for capital computation

1

3.4.8 The system should be able to calculate capital for Traditional and Synthetic Securitization exposures.

1

3.4.9 The system should be able to capture the bank’s role (e.g. Originator, investor etc.) for the securitization exposures, various credit enhancements and should calculate the capital as per Basel II Guidelines

1

3.4.10 The system should have CCF's models and calculate capital for securitization exposures with early amortization features The system should be able to apply the supervisory formula for capital calculation of Securitized Exposures as per Basel II / RBI Guidelines.

1

3.4.11 Purchased receivables for corporate and retail. The computation

capabilities should cover default risk and dilution risk.

For Default risk, the system should be able to apply Top‐down

Approach or Bottom- up Approach for both corporate and retail

exposures (purchase – receivable asset class wise). Also based on the

exposure type, the system should be able to apply retail or corporate

risk weight functions to arrive at the default risk weight

1

4 Stress testing 15

4.1 The stress testing module of the proposed solution should be in

compliance with the RBI circular on Stress testing (DBOD.BP.BC.No,

75/21.04.103/2013-14 dated 2nd December, 2013) and support the

following aspects:

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

175


4.2 The system should have the ability to perform the stress tests (for all the

asset classes) for PD, LGD, EAD, CCF and Maturity. System should be

able to Simulate stress test on various parameters like PD, EAD, and LGD

for Capital requirement & RAROC. Examples of scenarios that could be

used are:

Economic or industry downturns

Market Risk events

Liquidity conditions

Vendor should provide all the scenarios for the purpose of stress testing for

bank’s review and confirmation for stress testing above

2

4.3 Creation of sensitivity tests 1

4.4 Creation of multi factor scenarios based on historical scenarios,

hypothetical forward looking scenarios based on macroeconomic data

points

2

4.5 Capability to develop and deploy stress testing models which would assess the impact of multiple macroeconomic factors on the portfolio risk parameters like PD, LGD, EAD, loss rate etc. The solution should support the following statistical modeling capabilities: 1. Time series and regression techniques (Simple, Logistic, GLM, GLMM etc.) 2. Standard Probability distributions (normal, student-t etc.)

2

4.6 Capability to compute the correlation structure between various risk silos using: 1. Variance covariance approach 2. Copula approaches

1

4.7 Capability to assess second order impact of risk silos (E.g., Impact of

reputational risk on Credit risk)

1

4.8 Support reverse stress testing 2

4.9 System should be capable of computing the impact of stress scenarios

through the stress testing models on Capital, Liquidity and Profitability

metrics of the Bank.

2

5 Capital efficiency monitoring, Capital planning and management, risk 10


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

176


based pricing and performance measurement

5.1 The system should be able to capture necessary information like interest

income, interest expense, provisions, capital, operating expense to

compute RAROC on an ex-post basis for performance measurement and

capital allocation purposes

1

5.2 The system should be able to compute RAROC and SVA (Shareholder Value

Added) for each facility on an ex-post basis. The RAROC and SVA should

also be computed for each user defined portfolio. (For example, Corporate

Portfolio, Home Loan Portfolio, Rating grade 2, etc.)

2

5.3 Calculation of Risk Adjusted Return on Capital (RAROC) based on

regulatory capital as well as economic capital.

1

5.4 The system should support capital allocation based on RAROC. 2

5.5 The system should support to capture data and configure reports to

monitor capital efficiency parameters at various levels (bank, region, circle,

branch level). The capital efficiency parameters would range from RAROC,

unutilized CC limits, unrecognized government guarantees, unrated

exposures etc.

2

5.6 The system should be able to compute the risk premium to be charged at a

rating grade level, product level and transaction level based on incremental

capital required to fund the transaction using both Std. Approach and IRB

Approach.

1

5.7 System should have the capability to compute CVA (Credit Value

Adjustment) under RBI /Basel‐III Guidelines.

1

6 Reporting capabilities 35

6.1 The proposed system should comprise of a Business Intelligence tool, in

which a reporting data mart can be created and business users can

generate any type of reports, graphs, and dashboards through front-end.

The system should support reporting for:

5

6.1.1 Regulatory reports (pertaining to Basel II, Basel III)

Pillar III Disclosures: The system should have pre‐built pillar 3 reports as

per Basel / RBI guidelines on Basel‐II and Basel‐III.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

177


6.1.2 Origination metrics 1

6.1.3 Capital efficiency monitoring 1

6.1.4 Basel II & III parameter reports 1

6.1.5 The BI reporting utility should enable the bank to generate reports at 1. Bank level 2. Region/Circle level 3. Branch level 4. Counterparty level 5. Transactional level

1

6.2 System should provide the following reports and requirements related to

reports

30

6.2.1 System should support regulatory and MIS reports on all the dimensions used for defining the asset classes, securities / collaterals, regulatory, risk component, capital computation etc.

RBI has not yet issued IRB reporting formats hence vendor must define create and customize them as and when RBI issues reporting templates without any extra cost. It will be Vendor’ responsibility to create those reports in the system.

Bank may require ad-hoc reports which either system must support by

enabling business user to create by using defined dimensions without any

intervention of technology, coding, programming. User should be able to

create through graphical user interface. If it is not possible then vendor

should create and customize ad-hoc reports in the system.

3

6.2.2 The system should have the pre‐built & configured templates and should also have the functionality for a business user to define and customize new Credit Risk MIS across all matrix dimensions such as:

Counter‐party

Portfolio

Product

Geography – country/ state/zone/branch

Industry

Concentrations

Risk Profiles

Rating wise

Delinquency buckets

PD Bands

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

178


LGD Bands etc.



6.2.3 The solution should be able to generate Risk Profile Template as per RBI

guidelines and other regional/branch‐wise risk profile templates for credit

risk as per Bank’s internal requirements

2

6.2.4 The system should be capable of generating various Bank‐ defined reports

like:

Borrower Information report

Industry Analysis report

Monitoring (Account‐wise report to cover rating transition & trend in

critical identified parameters)

Peer group Analysis report

Rating wise reports

Portfolio reports

Borrower‐wise risk score report

Borrower‐wise risk grade report

Borrower‐wise year wise risk score report

Borrower‐wise year wise risk grade report

Industry Concentration Report

Industry‐ wise risk grade report

Region wise Concentration Report

Region ‐ wise risk grade report

Quick mortality Report

Defaulted Account Report (Grade wise/ Industry wise/ year wise/

ownership wise/ size wise/ on‐balance sheet / off‐balance sheet

exposure wise for a date range etc.)

RAROC reports‐ vertical wise, geography wise, rating grade wise etc.

Capital Charge‐credit risk (Regulatory and economic) – expected

and unexpected losses

Exposure Reports (Portfolio exposure by

Sector/ industry/credit rating/ Client/ Loan Size/

Maturity/ country/currency/On‐balance sheet/ off‐balance sheet

exposure/interest rate wise/floating rate wise – internal and

external benchmark /fixed rate wise etc. after including/ excluding

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

179


CRM – giving NPA position separately under each of these

categories along with reports on accounts which have been

upgraded from NPA and which have slipped to NPA from standard

Position, of restructured accounts under each of the categories

along with reports on accounts which have been upgraded from

restructured and which have slipped to NPA from restructured

status

Report on restructured exposures, repeated restructured accounts and

drill down options like industry‐wise, rating‐grade wise, curing‐wise,

tenor wise, sacrifice wise, product‐wise, vertical‐ wise, region‐wise,

branch‐wise, asset class‐wise.

6.2.5 The reports should be able to cut- across asset classes and give

combined reports, if needed, while analyzing industry‐wise, product‐

wise, sector‐wise reports (e.g.: exposure to cement

industry report should be combined and render a consolidated report on

all exposures under various asset classes)

1

6.2.6 Collateral Reports (Collateral wise exposure report (total exposure

after netting that is covered by 1. Eligible financial collateral 2 .

Other e l ig ib le A I R B c o l l a t e r a l 3. Guarantees etc.) including current

market value of collateral wherever applicable as per policy of the Bank

1

6.2.7 Expiry reports on collateral (Due to expire/expired) -

bank/zone/branch/account wise

1

6.2.8 Residual Contractual Maturity Breakdown of the whole portfolio

broken down by major type of Credit Exposures

1

6.2.9 Exposure weighted average LGD/EAD for each borrower category 1

6.2.10 Securitization disclosure (total outstanding exposure securitized by bank

broken-down by type of securitization (traditional/Synthetic), exposure

type.

1

6.2.11 Amount of NPA securitized broken down by exposure type 1

6.2.12 Securitization exposure retained/purchased broken down by exposure

type. (This report would be generated for user defined period and as of

date).

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

180


6.2.13 Report on capital market exposure as required as per RBI requirement –

account wise as per limit and outstanding exposure – on and off balance

sheet

Report on exposure to Real Estate – commercial and residential –

direct and indirect

Report on exposure to commodities

1

6.2.14 Report on Interest rate wise break up of advances – segment wise (term

loans, project finance, bills purchased/discounted or negotiated,

demand loans, CC, staff loans etc.) as per user defined range of rate of

interest

1

6.2.15 Report on Interest rate wise break up of advances – segment wise ‐ as per

user defined range of rate of interest

1

6.2.16 Report on position of unsecured exposure – public

sector/private sector/rating wise/interest rate wise/maturity wise

Report on break up of term loans, project finance, bills

purchased/discounted or negotiated, demand loans – as per residual

maturity

1

6.2.17 Report on pre- payment of total/instalment of term loans, project

finance, bills purchased/discounted or negotiated, demand loans

1

6.2.18 Report on segment wise exposure – Report on future draw down

schedule for term loans, project finance and infrastructure projects

Report on single borrower/group borrower exposure – user defined

number of top exposure vis‐à‐vis prudential exposure limits fixed by

bank/regulator

1

6.2.19 Export formats for MIS report –

‐.TXT

‐.XLSX

‐.PDF

‐.DOCX

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

181


‐.PPTX

‐.XML

‐.XBRL

6.2.20 Overrides performance reports – performance of accounts where there

is rating over‐ride or downgrades (Branch wise / region wise

/geography wise/level wise/approving user wise rating cases processed,

approved, rejected and pending for user defined period.

1

6.2.21 The system should support portfolio‐based calculation like Limits

Management: Bank may define a limit cap (may be absolute or % terms)

to an industry, borrower, individual exposure, and bank, sovereign,

rating.

The system would check the same and generate reports. What

if/Incremental risk analysis by addition of individual loan portfolio for

decision making purpose.

Portfolio based calculation should take into account industry correlation

to arrive at capital requirement.

The system should be able to perform portfolio analysis by fixing and

measuring exposures and limits inclusive of correlation effects within

portfolio parameters

1

6.2.22 The system should provide facility to generate customized report for user

like Top Mgmt., Risk Management Dept., Branch Manager, and

Relationship Manager etc. Graphical representation of reports, wherever

required.

Access to certain reports would be restricted to certain groups.

1

6.2.23 The system should be able to generate risk maps, risk charts, trend analysis

etc. for Pillar‐I and Pillar‐II risks, various risk dashboards for the users and

top management.

The solution should have the flexibility of viewing the reports at an

aggregated level or at granular level

1

6.2.24 System should have the capability to generate back dated reports 1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

182


Audit log report

7 ICAAP 10

7.1 The system should have a Pillar‐II module which supports ICAAP analysis

of all material Pillar‐II risks of the Bank and do capital computation, for

risks like concentration risk (branch wise, Zone wise, state wise, industry/

sector wise, product wise, vertical wise rating‐grade wise, interest rate

wise, group‐wise, borrower‐wise etc.), reputation risk, strategic

risk, compliance risk, underestimation of risk under standardized

approach, model risk, liquidity risk, interest rate risk, forex risk etc., as

per relevant RBI/ Basel guidelines on Pillar‐II.

Data required for the preparation of ICAAP document has to be generated

through the system.

2

7.2 The system should perform stress testing for each of the credit, market,

interest rate, forex, liquidity, concentration risk on individual basis

and aggregate the results of stress testing.

The system should at the same time assist in reporting, back testing and

assessment of capital for Pillar‐II risks.

Additionally, the system should also support aggregation of Pillar‐II capital

into Bank‐wide capital (regulatory & Economic capital) assessed.

2

7.3 The System should be able to support and have the necessary statistical

tools to validate the material risk estimation

methodologies and stress testing methods under Pillar‐2.

2

7.4 The system should have capital planning and budgeting modules for

est imat i n g bank‐wide capital for future, stress testing by changing

assumptions/ macro‐economic scenarios, allocation across business

units, geographies, products etc., if needed.

2

7.5 The system should be able to generate risk maps, risk charts, reports,

trend analysis etc. for Pillar‐II risks, various risk dashboards for the users

and top management.

2

8 Basel III Requirements 5

8.1 The system should have the capability for computation of non‐risk based 3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

183


leverage ratio as per RBI/ Basel‐III guidelines.

The system should have the flexibility to enable reporting and estimation

of each capital components like common equity, Additional Tier‐1, Tier‐2

etc. as per prescribed guidelines of RBI under Basel‐III.

The Pillar‐1, Pillar‐2 and Pillar‐3 modules should be compliant with RBI’s

Basel‐III requirements also.

8.2 System should facilitate capital computation and computation of

leverage ratio as per Basel II & III guidelines

2

Total Marks 250


184

7.3 Technical Requirements for Credit Risk Management Solution

Sr. No.

Technology Requirements Max. Marks

1 User Interface 25




2


2



2


2


2


1


2


2


2


3

● Microsoft Excel Format (.XLS)





185

Sr. No.




● Web Page(.HTML)



1


1



3


2


2

2.04 Bidder to provide all updates/modifications on account of regulatory requirements affecting domestic or international operations in respect of the Credit Risk Management System, including Advanced Approaches under Basel II without any additional deve lop ment , licensing, implementation and customization costs to the bank during the implementation and AMC period.

2



3.01 System should support archiving of data that are beyond a specified time horizon, to prevent long term speed concerns. Bank needs a separate data archival solution and query on archived data is required.

2





3

3.06 Export of data to secondary storage device should be supported by the system without down‐time.

2


186

Sr. No.



3


2


2


2



2


2


2


2


2


3




3


3



187

Sr. No.






3



2


2


2

5.04 The system should allow reports to be exported into Microsoft Excel, Adobe PDF format and other databases

1

5.05 The system should allow users to present outputs from reports in The system should allow users to print reports directly from the system

1

5.06 The system should allow users to save reports to a disc in a non‐editable as well as an editable format

1

5.07 The system should generate reports in various types of files like: ● View Mode ● Excel Mode ● Text Mode ● HTML Table ● CSV format ● Word File ● PDF format ● XBRL format

2


188

Sr. No.


5.08 The system should allow for generation of pre‐defined end‐of‐day, end‐of week and

end‐of month reports and ad‐hoc reports a s a n d when required

2

5.09 Reports generated in periodical wise or as defined by the Bank: ● Daily ● Weekly ● Fortnightly ● Monthly ● Quarterly ● Half‐yearly ● Annual

3

5.10 The system should allow for archiving of external reports in the following formats: ● Adobe PDF ● Microsoft Excel ● Microsoft Word ● Microsoft Access ● Comma separated values (.CSV)

2


1

4


1

6 General 20


3


3

6.03 The system should load calendar schedules from external sources including but not limited to Bank Ho l iday , SWIFT, International Holiday schedule and Bloomberg holiday schedule. etc.

2



3


189

Sr. No.


6.06 The proposed Data Mart should be able to integrate with the Enterprise‐wide Data warehouse solution which is going to be implemented in the future.

3

7 Integration 15


15



● Real time processing (calculation to be done with time lag of 1 day on the basis of day-end data) 8 Documentation 10


7

a) User manuals; Will be provided to the bank as per the standard documents available





3

Total 150


190

7.3.1 Additional Questions

Refer to sub‐section 9.5 in Annexure Section for required additional details on the proposed solution

7.3.2 Hardware Requirements

The Bidder must specify complete details of Hardware and other systems required for

successful implementation of the offered Solution, in the following format.

Sr.

No.


1. Hardware

2. Operating System

licenses(Windows or

any other)

3. Database licenses

4. Third party

utilities

5. Any other

requirement

Note:

1. Cost of ETL tools as part of proposed solution should be borne by Vendor 2. The hardware and infrastructure sizing should be done with registered user of 20, current concurrent

user base of 10. At present, total number of accounts in loan portfolio of the bank is: (a) number of fund based accounts – approx. 35 lacs (b) number of non-fund based accounts 1 lacs (c) Number of securities 50 Lacs (d) average number of securities per account is 1. Loan portfolio is expected to increase @ 15% per annum and expected customer growth around 10% per annum.

3. Please mention Make / Model (if any), type and number of processors, Memory, bus speed, hard disk & Operating System number of users, license type, version etc.

4. Detailed Bill of Materials (Line item wise mentioning technical specifications) to be submitted for all the above modules

5. Detailed Technical sheets of the above modules to be submitted 6. Bidder to also provide detailed specifications for replication methodology for DR site 7. Application user: pan India 8. Batch frequency: daily


191

9. Historical reporting requirements for Credit Risk Management: Quarterly 10. Extracts from the source systems will happen daily 11. Data refresh frequency: daily 12. Workload will peak over a particular period of time 13. Bidder to provide ETL processing 14. Time window for running the pre-configured workflows is 25 hours 15. Bank case use Banking DDS and map to source systems both


Please provide descriptive answers to the following questions.

Sr.

No.


1 How many Implementation trainings (CRM)

have been undertaken by the Bidder so far?

2 Please provide a brief description on the

Training approach taken by the Bidder.

3 Please provide the following details for

training :

3.1 Number of man‐days / duration for

completion of training



3.4 Location


3.6 Pre‐requisites / Preparations


192

Sr.

No.


required before training

4 Please answer the following about the

trainers in‐charge of conducting the training

on behalf of the Bidder for the Bank:


Bidder who would be involved with the

Project


with the Project as trainers


with the Project, working / training on the

solution proposed by the Bidder

5 Please provide a s a m p l e training response

and feedback from previous

implementations?

Also, please give details of the

following:






Note: Please attach the feedback in a separate document with proper cross‐referencing.


193

Sr.

No.


6 Please specify the various modes through

which the training will be delivered? [e.g.

Classroom training, Online self‐help training

modules within application / e‐

learning modules, Quiz, etc.]


Sr.

No.



The methodology section should

adequately address the following stages of

the project:

1.1 Frequency and approach for

periodic reporting on the progress of the

project and actual status vis‐ à‐vis scheduled

status

1.2 Detailed Study of Current State and Gap

Analysis, with detailed work steps and

deliverables as per scope of this RFP

1.3 System Requirement Specification Preparation

(SRS)

1.4 Customization, Configuration

Parameterization, development and

necessary work around


194

Sr.

No.


1.5 Building up of interfaces / ETL with

various applications / source systems / staging

area / data warehouse etc. currently used by

the bank

1.6 Setting up of the data center and the

disaster recovery site

1.7 Data Extraction, Preparation, Validation,

Migration and Reconciliation


1.9 Sample Roll-out, Training / Workshop and

Knowledge Transfer Planning for roll‐out

and identification of key issues that may arise

along with proposed solutions

1.10 Production Migration

2 Timelines


4 Roles and responsibilities of

proposed personnel both from the vendor

and bank end


methodology followed by the vendor in

Project Management for a Public Sector Bank

Project Name


195

Sr.

No.


Project Location

Client Name

Client address




Man‐months effort

Project Size (No of branches,

modules covered and any other relevant

details)




Role of the Bidder, whether

complete end‐to‐end involvement or for a

particular module

Project detail (Broad detail –

information about all activities handled,

modules forming part of the Operational

Risk Project of the Client Bank, associated

activities, time lines activity‐wise and module‐

wise may be detailed.)


196

8. Integrated Capital Computation & Reporting Module

As the capital computation for credit risk, market risk and operational risk will be done by separate system / application, the bank needs a module to extract and collate the individual capital calculations and report the integrated capital.

8.1 Key Components

The key component of this module should include: a) A reporting Tool with a presentation layer b) An ETL tool for extraction of capital computed from the three respective systems (CRMS, ORMS

and Market Risk System)

8.2 Details to be provided by the Bidder

a) The bidder is expected to include the functional and technical details of this module in the proposed solution and the integrated system architecture.

b) The vendor is also expected to provide the details (both technical and commercial) for required hardware and other infrastructure components for this module in the defined format of Section 9.4 and Section 9.7 of this RFP document

For Liquidity Risk, Interest Rate Risk, Forex Risk and any other risk, other than scope of credit risk and operational risk as given in this RFP, all the computation will be done by the existing systems (e.g. ALM, Market Risk Systems). However, proposed systems for CRM and ORM should have capabilities to take input / outputs from the existing systems of the bank. This includes taking input / output through manual files as well. Proposed solution should also be able to interface with the above systems to enable automated flow for further calculation and reports generation Vendor needs to provide how proposed systems are going to take care of above aspects and the same will be evaluated as part of the respective system functionalities. It is the responsibility of vendor to ensure that there are no gaps on data availability and performance issues for the integrated system, However Bank will advise Market Risk Solution vendor to coordinate and any cost involved is to be borne by the vendor and factored in the TCO.


197

9. Annexure

9.1 Undertaking from Bidder

Note: This Undertaking from the Bidder should be on the letterhead of the Bidder and should be signed by the authorized signatory

Date

To,

Risk Management Department,

Central Bank of India,

First Floor, Bajaj Bhavan,

Nariman Point ‐ Mumbai 400 021

Dear Sirs,

We have sized the proposed Hardware, Database and Application licenses based on the terms

defined in the RFP. However, if the same fails to achieve the required performance as defined,

we agree to supply additional hardware, , software licenses and support to meet the

performance requirements as defined in the RFP at no incremental cost to the Bank.

Yours faithfully,

(Name of Authorized Signatory)

(Designation)

(Name of Producers)


198

9.2 Eligibility Criteria Format

The Bidder must satisfy the following minimum eligibility criteria

Sr.

No.


the bank

General Eligibility

1 The bidder should be in existence for 5 years as on

31st March 2014. (In case of

mergers/acquisitions/restructuring or name

change, the date of establishment of

earlier/Original firm would be taken into

consideration.)

Certificate of incorporation

2 The bidder should be a profit making entity for

last three financial years i.e. 2011-12,2012-

13,2013-14



sheets and P&L statements in case of

others for past 3 financial years.

3 The Bidder (SI) must have a presence in India for

at least 3 years with an established set-up with

available support staff (related to the systems

covered by the RFP) and should have average

revenues in excess of INR 100 Cr. For the past 3

financial years i.e. 2011‐12, 2012‐13 and 2013-14.



sheets and P&L statements in case of

others for past 3 financial years.

Certificate of Commencement of business.

Details of offices in India

Details of available support staff in India

4 The Bidder (SI) and OEMs should not have been

blacklisted at the time of submission by the

Central/any of the State Governments/ statutory

body/ regulatory body/Indian Banks Association in

India

Self-declaration of SI and all the OEM’s

5 The Bidder should own the intellectual property

rights of the product / solution or he should have

rights from the owner, If not, the Bidder should

have in place proper tie‐ups, commercial

agreements, authorized implementation

Letter/ Certificate from OEM


199

Sr.

No.


the bank

partnership etc. for deployment/ resale/

customization of software with the product Bidder

or any other third party, whose software products

are offered.


6 Proposed credit risk solution should have been

procured by at least 1 scheduled commercial bank

in India or a bank abroad for implementation of

Advanced (IRB) approaches (only standardized



7 Proposed operational risk solution should have

been procured by at least 1 scheduled commercial

bank in India or a bank abroad for implementation

of Advanced (AMA) approaches (only BIA/TSA



8 The proposed Credit risk solution and Operational

risk solution should have been implemented by a

Bank operating in jurisdictions where Advanced

(IRB/ AMA) have been approved by the regulator

for the Bank.


9 The proposed Credit risk and Operational risk

solution should be positioned in the leader’s

quadrant of Chartis research report/Gartner’s

magic quadrant.

Gartner report and Chartis report

10 The proposed bidder should have experience of

implementing Credit risk IRB and operational risk

AMA solutions in a Bank in India or Abroad



200

9.3 Cover Letter for Technical Bid

Date:

To,


Central Bank of India, Risk Management Department, 1st Floor, Bajaj Bhavan, Nariman Point, Mumbai – 400 021

Ref.: Procurement of Integrated Risk Management Solution: Specifically Operational Risk and Credit

Risk Management Systems under RBI/Basel II /Basel III Guidelines

Ref: Your Ref: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Having examined the Bidding Documents, the receipt of which is hereby duly acknowledged, we, the

undersigned, offer to supply, deliver and implement the Solution for Operational Risk and Credit Risk

Solution under RBI / Basel II / Basel I I I advanced approach, in conformity with the said Bidding

documents.

We undertake, if our Bid is accepted, to deliver, install, commission and implement the Solution in

accordance with the delivery schedule specified in the Schedule of Requirements.

If our Bid is accepted, we will obtain the guarantee of a bank in a sum equivalent to 10 percent of the

Contract Price for the due performance of the Contract, in the form prescribed by the Bank.

We agree to abide by the Bid and the rates quoted therein for the orders awarded by the Bank up

to the period prescribed in the Bid, which shall remain binding upon us.

Until a formal contract is prepared and executed, this Bid, together with your written acceptance

thereof and your notification of award, shall constitute a binding Contract between us.

We undertake that, in competing for (and, if the award is made to us, in executing) the above

contract, we will strictly observe the laws against fraud and corruption in force in India namely

“Prevention of Corruption Act 1988”.

We understand that you are not bound to accept the lowest or any Bid you may receive.

Dated this ....... day of ............................ 2014

(Signature) (Name) (In the capacity of)


201

Duly authorized to sign Bid for and on behalf of


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

202

9.4 Technical Bid Format

9.4.1 Functional Requirement Checklist – Operational Risk Management

All the requirements are mandatory. Bidder shall indicate in column 3 the availability of each requirement as a readily available (A), work

around (R) or customization (C) or not available (N). The Software solution offered, however, should have at least 85% of the requirements

as a part of the standard product. The remaining shall be customized before the completion of pilot run at no extra cost to the Bank.

Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% marks for - Work around (W)’, ‘50% for - Customization (C) and ‘0 for - Not Available (N)’.

Sr. No.


250)

A/W/C/N Comments


1.1 Configurations of the bank’s legal, governance and business structure such as

group, legal entities, organization and governance structure, risk entities, product,

processes, systems, locations, business lines, outsourcing vendors etc. all other

dimensions enabling operational risk management and measurement

(As mentioned in the vendor responsibilities for ORM Implementation, vendor will

prepare entire process documentation for uploading into the system)

(For all the above dimensions , bank will provide the data in as is format and vendor

will convert them into uploadable format and then will configure / parameterize and

upload into the system)

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

203

Sr. No.


250)

A/W/C/N Comments

1.2 Manual upload facility of the historical data, interface with external system such as

CORDEX, interface with bank’s integral source system / staging area / data warehouse,

and enable integration with KRI, RCSA, Scenario loss data, etc.

External loss data can be from CORDEX or any other source which vendor should be

uploadable into the system through from the front-end through graphical user

interface, if direct or staging area interface is not done as per decision taken by the

bank.

(Direct automated interface with external source such as CORDEX but data should be

visible to the user on the front end of the system and user should also be able to

download the data).

Interface with external third party system can be real time as well as batch.

Data upload templates can be in various files formats such as Excel, CSV, txt, open

office but not limited to them.

2

1.3 Configuration of bank’s operational risk management framework in terms of

methodology, work-flow, templates, consolidation, models, tools, analysis, monitoring

and reporting.

1

1.4 Administration of the module in terms of access to the system as per job profile of the

employee with functional specific controls such as restricted access to reports, no

deletion rights etc. Access can be given and controlled at various dimensions such as

location, geography, employee, department / unit etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

204

Sr. No.


250)

A/W/C/N Comments

1.5 Complete audit trail including reports generation thereof. Audit log of the changes

made in assumptions, methodology, process, statistical model/ formulae used along

with reasons/ logic for change should be available chronologically.

2

1.6 Exceptional reports including bank specified exceptional reports.

(Bank specified exceptional reports will be created and configured by the vendor in the

system, at no extra cost to the bank, Bank will provide requirements only)

1

1.7 Flexibility for system enhancement due to change in regulatory requirements, bank’s

policy and procedures and due to good risk management practices, as determined and

specified by the bank.

(If any new development or customization is required, it will be done by the vendor at

no extra cost to the bank. Its implementation will also be done by the vendor at no

extra cost to the bank.)

2

1.8 Use of results of operational risk management processes for the purpose of

operational risk capital quantification e.g. BEICF factors

(vendor needs to demonstrate that how the results of RCSA, KRI, Loss Data are linked

to AMA Modelling / OR Capital Quantification)

Deliverables:

Vendor needs to provide a document as to how results of qualitative processes of

operational risk management in the system facilitates in the AMA Modelling / Capital

Quantification including data flow and use of information)

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

205

Sr. No.


250)

A/W/C/N Comments

1.9 Multi-lingual, which can help to roll-out in multiple jurisdiction. This is not a very strict

requirement but can be counted as a good feature in the system. Currently, at least

English should be supported.

1

1.10 The system should have ‘help’ function to assist the user in understanding the system

functionality through navigation.

Deliverable:

vendor should provide Help Manual too

1

1.11 System should facilitate alerts, reminders, notifications at various stages of ORM

framework implementation such as RCSA, KRI, Loss data etc. by various channels such

as e-mails, SMS etc.

2

1.12 Functionality with respect to record such as create, approve, save, submit, reject,

view, print, download, upload, de-activate, delete at appropriate places of the work-

flow attached to the user rights matrix as specified by the bank.

2

1.13 System should give relevant error message such as on data upload, on execution of

wrong command etc. including generation of log

1

1.14 System should provide search facility of various records using fields or combination

thereof which are used to define that particular record.

1

1.15 The system should provide at least 15 dimensions of structures or hierarchies such as

organization structure, product, process / sub-process, business lines, loss event type,

geographies,

Each hierarchy should be able to be defined in parent-child / tree structure.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

206

Sr. No.


250)

A/W/C/N Comments

1.16 System should facilitate split, change, merge, edit and creation of units and codified

data points. For example, with business changes there should be the ability to split or

merge loss and risk data/MIS.

2

1.17 System should have the capability to maintain inventory of processes and reports

at least for seven years

Each process is to be defined with mapping to product, organization structure, internal

and Basel business lines, ownership etc.

2

1.18 System should support the break‐down of processes into logical process steps with

linkages to underlying procedures, unit responsibility and they should be able to be

linked to RCSA, KRI and Loss event

System should be able to capture process in a parent-child / tree structure e.g.

process, sub process, activities etc.

1

1.19 The system should have scalability to take care of any changes brought in by BASEL

guidelines/Regulator

1

1.20 System should be web based where functioning of the proposed solution will be

checked at server site as well as different locations of the bank as users of the system

would branches, regions, zones and head-office hence web-based system should work

effectively.

1.21 System should be able to map bank’s income / expenses and products to Basel II

business lines and should be able to generate report of income and expenses as per

Basel II business line wise.

2

2 Risk and Control Self-Assessment 45


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

207

Sr. No.


250)

A/W/C/N Comments

2.1 System should be able to customize and / or support bank's RCSA framework in terms

of methodology, approach, use of templates, work-flow, approvals, use of scale,

consolidation, analysis and reporting etc. and use of RCSA results for capital

computation purpose.

Results of Current Assessment shall be used for the purpose.

System to be implemented for Operational Risk Management should automate Risk

and Control Self-Assessment. Facilitate roll out of RCSA across a representative

sample of Business Lines and Geographic locations through the implemented system.

The system should support monitoring of progress achieved in RCSA and should

enable analysis of the quality of data provided by the representative sample. Provide

Recommendations regarding improvement of the RCSA quality.

3

2.2 There should be upload / download facility such as upload of RCSA assessment, plan,

schedule download of respective templates, etc.

1

2.3 RCSA methodology such as risk based, Questionnaire based and hybrid, all should be

supported.

(Under Risk based Methodology, Risk Assessment will have Risk and Controls for the

underlying risk entity and each risk and control is to be assessed. Risk and Control

Assessment (using frequency and impact scale) can be done such as: (i) Inherent Risk

Assessment, Control Assessment & Testing, Residual Risk Assessment / Derivation (ii)

Control Assessment / Testing and Residual Risk Assessment / Derivation (iii) Residual

Risk Assessment

(under Questionnaire based Risk Assessment, risk and controls will be assessed basis

set of defined questions)

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

208

Sr. No.


250)

A/W/C/N Comments

(Hybrid approach means combination of Risk based Methodology and Questionnaire

based Methodology and bank can use both at one point of time for different risk

entities.

(Risk Entity for which RCSA is to be done can be defined with any combination such as

a single branch can be a risk entity, combination of branch and other offices combined

can be a risk entity, a geography can be a risk entity, an entity can be a risk entity, a

business line can be a risk entity, a product or process can be a risk entity. In essence

risk entity can be defined at any dimension in isolation or in combination as per

business & risk profile and materiality involved)

2.4 Planning within the system in an automated manner for RCSA by considering various

parameters such as risk profile, business size of the risk entity, audit findings, actual

loss experience, inherent criticalness of the business operations and various other

parameters considered relevant by the bank. There should be flexibility in defining

new parameter and modifying existing one.

Planning will ensure identification of risk entities for assessment over the RCSA period

such as within a Financial Year. Planning can also be done for some of the processes

for a particular risk entity e.g. under a particular RCSA schedule, bank may decide not

to cover all the processes of the branch or may decide different processes for each

branch.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

209

Sr. No.


250)

A/W/C/N Comments

2.5 Assessment scheduling is to be done through the system as to when RCSA is to be

done over defined RCSA period. System should have capabilities of sending auto

reminders through emails when the schedule for RCSA is due and escalation for delay

in completing the assessment to various levels. Scheduling will ensure timing of the

RCSA of a particular risk entity in the RCSA period. System should support assigning

ownership for each RCSA schedule.

1

2.6 It should create RCSA template for risk and control assessment which should be

customizable as per risk entity, as all risk-entity may not have same number of risk

events and approach

1

2.7 RCSA template should be at process, product e.g. new product, risk entity level,

outsourced vendor or any other dimension as defined by the bank. E.g. System should

support RCSA just for a new product or process without planning or scheduling. System

should also support RCSA on ad-hoc basis such as occurrence a fraud in a risk entity

triggering for unplanned / unscheduled RCSA

1

2.8 It should have facility to roll-out of the same template to multiple risk entities due to

similarities in the risk profile e.g. rural branches can have similar type of template

1

2.9 Template should be designed with appropriate classification, sub-classification,

sequencing, grouping and sub-grouping of risk events as specified by the bank e.g.

logical sequencing of first processes and then risks and controls within a particular

process.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

210

Sr. No.


250)

A/W/C/N Comments

2.10 Risk and Controls in the template should come from the Risk and Control Library to

avoid repetitive preparation of templates. A risk and control template for a risk entity

should be able to be saved with version control within the system for further use.

1

2.11 It should have flexibility to enter any risks identified and corresponding controls in all

the operations and activities of the bank including in the support functions. Risk and

controls so identified should be stored in the risk and control data library.

1

2.12 Risk and controls should be mapped to respective classification such as risk entity,

process, product, Basel II classification, causal factors, risk drivers, significant / non-

significant risk, preventive / detective control, control frequency, risk identification by

(auditor / risk entity / ORMD / external events / others) etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

211

Sr. No.


250)

A/W/C/N Comments

2.13 System should facilitate performing RCSA can be in following ways i.e.

D. Under Risk Based RCSA Approach:

iv) Inherent Risk Assessment, Control Assessment & Testing, Residual Risk

Assessment / Derivation

v) Control Assessment / Testing and Residual Risk Assessment / Derivation

vi) Only Residual Risk Assessment

E. under Questionnaire based Risk Assessment, risk and controls will be assessed

basis set of defined questions

F. Hybrid approach means combination of Risk based Methodology and

Questionnaire based Methodology and bank can use both at one point of time for

different risk entities.

It should also facilitate control testing, if chosen by the bank as per its framework

2

2.14 While doing the risk assessment, user should be able to see the respective process /

activities under process. User should also be able to put any remark/suggestion against

process/ activities while doing the assessment.

1

2.15 If there are more than one users to do the RCSA for a specific risk entity, system should

consolidate the assessment as each level to produce final risk assessment such as

averaging the ratings

1

2.16 System should facilitate risk assessment should be done on probability and impact

scale

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

212

Sr. No.


250)

A/W/C/N Comments

2.17 Scale for risk assessment available in the system should be customizable by the bank

with appropriate color coding where each color should bear a different meaning.

2

2.18 Residual risk should be rated as a result of probability and impact assessment by the

system i.e. product of probability and impact

1

2.19 There should be facility to review and approval of the RCSA assessment i.e. through

maker checker. There can be more than one level of review and approval. Under

review and approval, person should be able to change the assessment with reasons

recorded. System should support bank specified work-flow for RCSA.

1

2.20 System should rate the individual risk / process / risk entity / region /zone / bank /

group, through logical consolidation of results.

Consolidation of all the results should be done and a consolidated RCSA Index to be

created by the system

2

2.21 A heat-map should be generated for RCSA results with drill-down capabilities. Heat-

map should be multi-dimensional such as for a risk entity, region, zone, Inherent risk /

Residual Risk , bank, group, risk type, only critical / key risk events, risk events with

action plan etc. the system should have capability to customize logic used for creating

Heat maps.

1

2.22 Dash-board facility to view the risk profile by risk entity, business unit / business line,

and the bank as a whole. A dashboard can have trend, current assessment, critical

risks, action plan status in just one report and same can be populated for risk entity,

business lines, geography, bank, group etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

213

Sr. No.


250)

A/W/C/N Comments

2.23 Summarizes the assessment results by process, product, risk entity, region, zone, bank,

group, location, risk type etc.

2

2.24 Trend analysis of RCSA results using historical data such as comparison between

entities, trend of risks of a risk-entity, trend of a particular risk type, trend of a

particular geography, trend of key risks etc.

2

2.25 Detailed action plan report i.e. all open action plans on a particular date with their

owners with their status and if delay then number of days delayed by

1

2.26 Action Plan Report with status e.g. action plan which has breached the timelines and

escalation work flow

1

2.27 Exceptional reports such as risk entities which has not completed RCSA as per

schedule, Completion with Delay, RCSA initiated but not yet completed etc.

1

2.28 Reports for internal audit, compliance, information security etc. to share the results

such as action plan report can be given to internal audit which can validate the

implementation in the next audit / review, Critical Risk can be shared for detailed

control testing etc.

2

2.29 RCSA validation report which will show the number of changes in the RCSA assessment

based on third party review such as audit, compliance, regulator etc. System should

facilitate to put independent rating of that particular risk or risk entity such as done by

internal audit or external agency for validation purpose.

1

2.30 It should facilitate creation of action plan with a particular reference and linked to the

risk event e.g. which has been assessed such as critical

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

214

Sr. No.


250)

A/W/C/N Comments



link with the respective risk event etc. System should support defining more than one

task under one action plan ID.

1

2.32 ORMD should be able to change the RCSA rating based on validation results or on

occurrence of some risk event within or outside the bank. Change in RCSA rating

should happen with reasons recorded in writing. Rating can be changed of a risk,

process, risk entity etc. System should notify change in rating to the respective owner

1

2.33 There should be a document upload facility to substantiate the RCSA. 1

2.34 System should provide monitoring of RCSA status to various users such as ORMD

where they can view by branch, region, zone, bank, group level for a given time period.

1

2.35 Vendor should conduct a sample run of the entire RCSA exercise as per the scope and

process mentioned by the Bank.

1

3 Key Risk Indicators (KRIs) 25


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

215

Sr. No.


250)

A/W/C/N Comments

3.1 Implementation of bank’s KRI Framework at bank wide level including all its

geographies, business units and overseas operations.

The Operational Risk Management system should help automate the definition of

KRIs, allow for periodic capture of relevant KRI measurement related data and thus

enable monitoring. The system should be flexible enough to allow configuration of

different values for KRI attributes at the central, Zonal and branch level. E.g. the

system should enable configuration of a different value for a KRI threshold at the

Branch and then the Zonal level and should also provide framework for back testing

of KRI.

3

3.2 Provide for the upload of data manually as well as download of data to various file

formats such as word, excel pdf etc. The data upload includes KRI calculation data at

defined frequency and data related to KRI definition and assignment. For upload of

data, vendor should provide the templates.

1

3.3 Definition of the KRI in the system should be independent of its assignment to various

risk entities so that one single KRI can be assigned to more than one risk entities as per

applicability. Defining KRI means creating KRI into the system and then allocating for

monitoring to various risk entities as per applicability.

1

3.4 Provide interface with bank's various source system / staging area / data warehouse,

as applicable and decided by the bank, to extract data in an automated manner. Also

the system should have ability to take values from different users and consolidate

them at various levels such as business function, location and business line – this

situation may arise when data to be used for KRI are to be derived by combination of

various data points. Ideally this should be handled by the vendor at interfacing stage.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

216

Sr. No.


250)

A/W/C/N Comments

3.5 Definition of KRI with its mapping with various dimensions and classifications e.g. KRI

name, description, mapping with process, activity, product, risk entity, risk event type

classification, unit of measurement, calculation criteria, data attributes etc.

KRI so defined in the system will be part of KRI database which can be used to assign

KRI to various risk entities.

1

3.6 System should provide facility to assign KRI to various risk entities with specification of

threshold, triggers, calculation frequency, and KRI review frequency.

Risk entity here means dimension at which KRI is to be calculated such as risk entity,

business line, region, bank, product, process etc.

In essence, KRI can be monitored at various dimensions in the bank and system should

support this.

2

3.7 System should facilitate different thresholds for a single KRI assigned to different risk

entities.

1

3.8 Trigger should be mapped with various level of automated notification and escalation

at various hierarchies e.g. through e- mails, SMS etc.

2

3.9 Compute KRI value on the defined frequency based on the data uploaded / extracted

as per job scheduling.

1

3.10 On the KRI review frequency, allow changes to be done after validation of KRIs such as

whether that particular KRI is relevant or to be discontinued

1

3.11 System should facilitate creation of action plan for those KRIs which have breached the

threshold or on reaching a critical trigger level

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

217

Sr. No.


250)

A/W/C/N Comments



link with the respective risk event etc.

1

3.13 Compare computed value of KRI with the thresholds set and then provide alerts to the

respective notification / escalation level

1

3.14 Generation of reports at multiple dimension such as for individual KRI level, risk entity

level, business unit, KRI sensitivity level (e.g. High, Medium, Low), region / zone / bank

/ group level, risk type, product, process etc.

1

3.15 KRI Report should be of all types heat map, dash board, tabular, graphical etc. 1

3.16 Provide report with respect to trend analysis of KRIs such as movement of same KRI,

comparison of KRIs of one entity with another entity, new breaches than before to

show emerging risks, movement of KRI Index, KRI index from risk entity to bank level

etc.

1

3.17 Dash-board of KRIs for risk entity, region, zone, bank and group. Dashboard should

show KRI breached, critical risks, action plan status, new KRIs in critical zone etc.

1

3.18 Results of KRIs are to be aggregated using bottom-up approach and a bank level KRI

Index should be derived by the system.

1

3.19 System should provide for comparison of KRI results with benchmarked KRIs along

with capturing of benchmarked KRI in the system itself. Benchmark could be industry,

peers, or others.

1

3.20 Vendor should conduct a sample run of the KRI Scope as per the Bank specified

process.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

218

Sr. No.


250)

A/W/C/N Comments

4 Loss Data Management (Internal and External both) 30

4.1 System must support all the requirements of RBI and Basel II with respect to internal

and external loss data management in terms of operational risk management as well

as measurement and modeling.

The system to be implemented should automate capture of actual, near miss and

potential loss events. There should be provision for capturing financial details related

to the loss event and subsequent recoveries from different sources such as insurance,

cash recovery etc. to estimate the gross and net loss. The system should support a

maker-checker mechanism for capturing, reviewing and approving loss event

information provided. The system should also support mapping of losses to Basel loss

event types and Business Lines The system should have a provision of data upload and

allow scaling/upload of external loss data.

2

4.2 Loss Data Module should be comprehensive enough to record all the information for

the purpose of operational risk management as well measurement as per advanced

measurement approach.

Management of loss event also includes capturing intermittent status of risk event

such as investigation status, recovery status, so that end to end flow of risk event can

be monitored as to its progress and closure i.e. capturing the life-cycle of loss event

with all the status.

System should have facility to capture near-miss events, gains arising from operational

risk loss event and opportunity cost.

It should capture all information which would help the bank in management of

operational risk.

Information with respect to risk event should be captured such as date of risk event

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

219

Sr. No.


250)

A/W/C/N Comments

occurrence, event end date, date of discovery, date of providing contingent liability,

date of accounting / provisioning, description of risk event, location, product, process,

risk entity, root-cause analysis (RCA), causal factors, risk drivers, mapping with

business line and loss event type as per Basel II classification, bank’s internal

classification etc.

It should be able to capture loss data from all geographies and departments /

operations of the bank.

4.3 It should have download and upload facility for loss risk events in a specified template 1

4.4 System should be able to customize, bank's loss data management framework,

template, work-flow, approval, reports etc.

1

4.5 It should be able to migrate the existing internal loss data of the bank through upload

facility with the actual time recording through Bank provided templates

1

4.6 It should have strong internal control around loss data such as access, restricted

access, view or print rights, audit trails, exceptional reports etc.

1

4.7 It should be able to do scaling, judgment overrides or other adjustments to the internal

loss estimates

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

220

Sr. No.


250)

A/W/C/N Comments

4.8 System should flag events as loss event, near-miss, external loss data, operational gain

and opportunity cost for distinct identification of each entry. Opportunity costs / lost

revenues would mean operational risk events that prevent undetermined future

business from being conducted (e.g. unbudgeted staff costs, forgone revenue, and

project costs related to improving processes), are important for risk management but

not for quantification.

1

4.9 It should enable identification of related loss events over time i.e. grouping of related

loss events over a period of time. This will also help deciding materiality of risk events

as a single risk event may be below AMA modelling threshold hence may not be

considered but if similar risk events as a whole are above threshold then it should be

considered for AMA modelling. System should support such grouping and linking the

same with AMA modelling.

1

4.10 It should have facility to arrive at the Gross Loss, inter alia, including any direct charges

to reserves due to operational losses, all expenses incurred as a consequence of

operational risk events, provisions made, penalty and fines etc.

1

4.11 System should differentiate the status of loss such as estimated, contingent liability,

provision made, loss accounted for with appropriate GL reference, Cost / Profit Centre,

currency of the Loss if different from currency of accounting / booking

1

4.12 It should record loss type such as Legal Cost / Regulatory Penalties / Loss or Damage to

Assets / Restitution / Loss of Recourse / Write Downs

Loss information should include type of valuation such as book value, replacement

cost, Mark to Mark (MTM) etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

221

Sr. No.


250)

A/W/C/N Comments

4.13 Allocation of losses to business lines and loss event type categories along with the

methods used to allocate the losses

1

4.14 It should enable classification of risk events as boundary events to specify it as credit

risk related or market risk related

1

4.15 It should be able to record recovery from all sources (from insurance and other

recovery such as from employees, third parties, vendor, customer etc.) with clear

identification

1

4.16 Status of recovery can also be included such as recovery process initiated but yet to be

received

1

4.17 It should be able to produce loss as gross loss, loss net of all other recoveries other

than insurance, loss net of all recoveries including insurance etc.

1

4.18 It should be able to identify the risk events which are covered in the existing

operational risk insurance policies

1

4.19 It should facilitate creation of action plan with a particular reference / linking to the

risk event

1

4.20 External loss data from all sources e.g. public data / pooled industry data / vendor

data, all should be supported by the system

1

4.21 System should capture External loss data in the similar manner as used for internal loss

data with flagging as internal loss data. External loss data can be interfaced with

external system such as CORDEX and / or uploaded manually

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

222

Sr. No.


250)

A/W/C/N Comments

4.22 User should be able to view and download in reporting format of external loss data.

External loss data should be visible like internal loss data with flagging as external loss

data.

1

4.23 System should be able to do scaling, adjustments (qualitative as well as quantitative)

to internal and external data wherever applicable as per AMA requirements. The

scaling process should be systematic, statistically tested and generate outcome

consistent with the operational risk profile of the bank. System should have pre-built

scaling parameters which bank will select as applicable; Secondly, system should be

able to define new parameters as suggested by the bank. Vendor should ensure all the

required parameters have been configured in the system.

1

4.24 System should facilitate appropriate filtering process to ensure the relevance of data.

The filtering process should be applied consistently and any exceptions thereto should

be documented and supported with rationale

1

4.25 It should facilitate validation of loss data through review and approval e.g. maker-

checker and there can be more than one level of review and approval

1

4.26 It should facilitate reconciliation of loss data with other source data such as GL entries

etc. For the purpose of reconciliation, system should compare GL data with system loss

data for reconciliation for defined period of time. GL data can either be extracted or

uploaded into the system.

1

4.27 System should have a comprehensive analysis and reporting mechanism for review

and monitoring

It should be able to analyze data on multiple dimensions such as risk entity, product,

process, business lines, risk type, causal factor, risk drivers

Analysis should include trend analysis, comparison with past data and peers data using

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

223

Sr. No.


250)

A/W/C/N Comments

various dimension entity, risk entity, business line, risk type, geography, period, cost /

profit center etc. i.e. analysis should be done basis the fields used to record the loss

data.

4.28 Apart from standard reports in the system, vendor should also define, create and

configure ad-hoc reports required by the bank

Reports should be in all formats tabular, graphical, dash-board, heat map etc. Bank will

provide requirements for reports to the vendor.

Reports should be with drill-down facility up to most granular level including loss

information into 8*7 matrix of loss types and business lines.

User should be able to extract the data based on applied filters e.g. loss between a

particular period

Format used for capturing operational losses should be customizable by the Bank.

1

5 Action Plan 10

5.1 System should provide for recording of action plan due to RCSA, KRI, Loss Data,

Scenarios, External Events etc.

The system should allow definition of corrective actions that need to be taken to

mitigate identified risks. A mechanism of defining such actions, allocating it to specific

business units / branches and monitoring of the same should also be provided.

2

5.2 Action plan should capture information such as task, start date, original target date,

revised target date, number of revisions done, reason for revision, owner, action plan

type (long terms/ short term/medium term), status, reference of risk event / KRI / Loss

event due to which it was raised.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

224

Sr. No.


250)

A/W/C/N Comments

5.3 It should provide a direct link from the respective RCSA, KRI, Scenarios and Loss Data

module when action plan is required to be created as well as direct access to the

module

1

5.4 It should facilitate creation of action plan without any reference to a particular risk

event, KRI and loss event as in certain situations, action plan can be created due to

external events as well such as a big fraud happened in another bank.

2

5.5 System should generate reports on the status, action plan which has breached

timelines, with open status, owner by action plan, risk entity / unit wise etc.

2

5.6 It should be able to customize bank specific reporting requirements at no extra cost to

the bank

1

6 Operational Risk Measurement / AMA Modeling 75

6.1 Support operational risk measurement and modeling as per RBI and Basel II

requirements under Advanced Measurement Approach (AMA).

The Operational Risk Management system should have the provision for modeling

frequency and severity of losses and should support modeling of Scenario and RCSA

data. The system should allow users to select the appropriate distribution for

frequency and severity of losses. Based on the distribution used for modeling

frequency and severity, the system should generate the expected and unexpected

loss estimates for Operational Risk. The unexpected loss estimate should be based on

the Value at Risk framework as well as any other framework that is compliant with

the Advanced Measurement Approach of Basel II. The system should support

computation of capital requirement based on internal loss data, external loss data,

scenario analysis and business environment & internal control factors.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

225

Sr. No.


250)

A/W/C/N Comments

6.2 Calculation of unexpected loss (UL) at 99.9 percent one-tailed confidence interval over

one year time horizon or at multiple holding period and also at various other

confidence levels e.g. 95%, 99%, etc.

2

6.3 Consideration of all types of risk events i.e. low frequency high severity (LFHS), high

frequency low severity (HFLS), low frequency low severity (LFLS), high frequency high

severity (HFHS).

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

226

Sr. No.


250)

A/W/C/N Comments

6.4 AMA model should creation of ORCs basis statistical analysis / approach.

System should be sufficiently granular to capture the major drivers of operational risk

affecting the shape of the tail of the loss estimates i.e. statistical distribution of loss

event types and business lines to ensure that bank's ORMS and AMA model are

sufficiently granular (i.e. the number of ORCs are neither too few nor too large) to

capture the major drivers of operational risk affecting the shape of the tail of the loss

estimates. An Operational Risk Category (ORC) or unit of measure is the level (for

example, organizational unit, operational loss event type, risk category, etc.) at which

the bank's quantification model generates a separate distribution for estimating

potential operational losses. This term identifies a category of operational risk that is

homogeneous in terms of the risks covered and the data available to analyze those

risks. Within ORCs losses are independent and identically distributed.

Granularity should be adequately supported by quantitative and qualitative analysis.

Statistical or other analysis to support the choice of granularity and the assumptions

that choice of granularity implies, and not justify their choice only on the basis of data

availability.

Calculation of risk measures separately for each ORC and aggregation of each ORC to

calculate bank wide VaR.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

227

Sr. No.


250)

A/W/C/N Comments

6.5 The system should have advanced analytics functions such as: system capability to

carry out structured stress testing including reverse stress testing (providing Stress

VaR estimates for each Operational Risk Categories, business lines and the

Bank level), make qualitative and quantitative adjustments for BEICFs, extrapolate

from the distribution of observed total loss points curve to determine the likely

amount of total losses, etc.

2

6.6 Modeling of one or more appropriate de-minimis gross loss thresholds which may vary

across business lines or loss event types, for the collection of internal loss data as per

RBI / Basel II requirements.

2

6.7 Systems should facilitate scenario analysis of expert opinion 1

6.8 The system should support defining, capturing and assessment of the scenarios. 1

6.9 System should support AMA modeling basis the inputs available such as basis the

scenarios, internal loss data, scenarios & internal loss data, scenarios plus internal loss

data plus external loss data.

System should do AMA modelling basis the appropriate mix of four input elements.

2

6.10 Use of assumptions in scenario analysis based on empirical evidence 1

6.11 Periodic Review and validation of scenarios should be supported by the system as and

when required by the Bank.

1

6.12 Pre-identified and configured BEICFs including approach for their determination and

use. This should include their linkages with the operational risk management

framework of the bank such as RCSA, KRI etc.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

228

Sr. No.


250)

A/W/C/N Comments

6.13 Translation of BEICF factors into quantitative measures for measurement, validation

and verification

1

6.14 Flexibility for use of BEICF as directly or indirectly in the capital calculation process

(VaR Calculator) or as upward / downward adjustment to operational risk capital, and

indirectly to the scenario analysis process. The system should have capability of

calculation of capital before and after consideration of BEICF factors.

2

6.15 Four elements required for operational risk measurement are internal data, relevant

external operational risk data, scenario analysis, and business environment and

internal control factors (BEICFs).

Use of standard statistical techniques for combining four elements in the process of

generation of the operational risk capital measure along with expert judgment of the

bank.

2

6.16 System should determine and justify statistically how the AMA elements are weighted

and combined.

1

6.17 Exploratory Data Analysis (EDA) for each of the ORCs to get an idea of the statistical

properties of the data and select the most appropriate distribution

1

6.18 Estimation techniques to fit the operational risk models to historically available

operational loss data

1

6.19 Goodness of the fit testing for the chosen distribution using visual test could be but not

limited to Quantile-Quantile Plots (Q-Q), Mean Excess Plots, Autocorrelation Plot, Hill

Plot estimations, etc.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

229

Sr. No.


250)

A/W/C/N Comments

6.20 Common formal tests for the goodness of fit could be but not limited to Likelihood

Ratio Test, Chi - square test, Maximum-likelihood Estimation (MLE), Kolmogorov -

Smirnov Goodness of fit test, Anderson-Darling Test, Cramer-Von Mises Test, Quantile

Distance Estimation method

2

6.21 The system should have statistical capabilities for estimation of information criteria

such as AIC (Akaike information criterion ) , BIC(Bayesian information criterion ) etc.

2

6.22 The system should allow to conduct parametric and non - parametric bootstrapping

process

2

6.23 To provide commonly used frequency distributions but not limited to the poisson,

binomial and negative binomial distribution. The system should be able to provide

graphical outputs for the fitted distributions.

1

6.24 Provide for Single Severity Distribution and Piece-wise Distribution. 1

6.25 System should be able to use more than one approach to estimate severity of the

body, tail and entire distribution

1

6.26 To provide commonly used severity distributions but not limited to Gamma,

Lognormal, Weibull, Pareto, Generalised Pareto and Generalised Pareto distribution

(with Block Maxima Model and Peak Over Threshold Model).

The system should be able to provide graphical outputs for the fitted distributions.

2

6.27 The system should support extreme value theory (EVT) 1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

230

Sr. No.


250)

A/W/C/N Comments

6.28 The system should display the parameters that are used for fitting the distributions. It

should rank and report all the test statistics

2

6.29 When selecting a severity distribution, positive skewness and leptokurtosis and other

statistical properties of the data should be specifically taken into consideration. In the

case of heavy tailed data, sub-exponential distributions whose tails decay slower than

the exponential distributions may be more appropriate.

2

6.30 Determination of appropriate body-tail modeling threshold for modeling the body and

tail of the loss distribution separately

2

6.31 Computing aggregate loss distribution with appropriate methods such as but not

limited to Monte carlo-simulations, Panjer's Recursive Method, Fourier Transforms and

Single Loss Approximation. Simulations, numerical or approximation methods may be

necessary to derive aggregate loss distributions.

2

6.32 Apply robust statistical techniques to test the reasonableness of the assumptions

about the underlying distributions.

1

6.33 It should have capacity to model the correlations/ dependence between various ORCs

in order to get the diversification benefit of operational risk exposures across various

business lines and loss event types.

1

6.34 Provide for modeling correlations/dependence using various methods but not limited

to Independence , Clayton , Gumbel , Frank Guassian T copulas

1

6.35 The system should have the ability to generate kendell tau, spearmen rank correlation

and upper and lower tail dependence index for the chosen correlation

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

231

Sr. No.


250)

A/W/C/N Comments

6.36 Model documentation should identify and justify assumptions as well as evaluate the

AMA model’s sensitivity to these assumptions related to correlations/dependence

1

6.37 The correlation/dependence assumptions should be validated using appropriate

quantitative and qualitative techniques. These should be substantiated by empirical

analysis of data where the modeling is primarily based on internal and external data.

1

6.38 Estimation of diversification benefits factored in at the Solo level , group-wide level

and at the banking subsidiary level

1

6.39 System should consider in AMA Modelling recoveries and insurance settlement as risk

mitigant.

2

6.40 Provide for capturing information related to insurance policies with all the data

requirements which helps to establish the eligibility of the insurance as risk mitigant

for operational risk. Data could be details of insurance policy, risks covered, minimum

claims paying ability rating, initial term, residual terms, minimum notice period of

cancellation, insurance provider being a third party, the uncertainty of claim payment

etc.

2

6.41 Mapping of insurance coverage to the exposures in bank's operational risk profile.

Mapping is required to generate an estimate of the probability of insurance recovery

and the possible timeframe for receipt of payments by insurers. This will assist the

bank in meeting the requirement that its operational risk model is capable of

evaluating the risk mitigation provided by insurance on a gross and net basis.

2

6.42 Mapping of insurance policies to Basel II event types for risk mitigation 2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

232

Sr. No.


250)

A/W/C/N Comments

6.43 Calculation of capital on a gross- and net-of-insurance basis for each capital

calculation, and possibly at a level of granularity such that termination of any one

policy could be immediately recognized for its effect on capital

2

6.44 Provide for the validation of the AMA measurement model through back testing and

statistical testing. Stress testing including reverse stress testing.

2

6.45 Vendor should assist in getting the models validated/approved by the regulators

(especially in case of the underlying logic being proprietary).

2

6.46 Sensitivity analysis must include consideration of the sensitivity of the bank's

ORCC(Operational Risk Capital Charge) to change in modeling choices, assumptions

and data inputs (including internal data, relevant external operational risk data,

scenario analysis, and business environment and internal control factors)

2

6.47 It should allow for the allocation of capital to business lines. 2

7 Analysis and Reporting 35

7.1 System should have a comprehensive set of standard reports for all the stakeholders,

which should cover all the functionalities covered in this RFP and all the stakeholders

such as business function, risk function, senior management and board. RFP response

should cover detailed list of standard reports available in the system for all the

functionalities.

Putting in place a system for reporting operational risk profile, control effectiveness,

loss trends and distribution by loss category and by business units. Reporting KRI

trends and status of required actions to business unit management, senior

management and to the Board.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

233

Sr. No.


250)

A/W/C/N Comments

The system should provide at least 10 dimensions of structures or hierarchies: Basic

organization of the information onto any one or more of at least a selection of 10

hierarchy structures. (For example: business units hierarchy, process Structure,

product Structure, risk library Structures).

System should provide Multi- Hierarchy Structure Management that permits data to

be viewed and managed across more than one dimension.

Vendor will have to provide at least 50 reports in the system (pre-configured /

standard) which must include all the qualitative and quantitative requirements

provided under AMA and report should be for all levels board / senior management/

ORMD and business users. These 50 reports should be MIS and does not cover

regulatory reports. Vendor will have to provide all the regulatory reports as per AMA

/ Basel II guidelines. If Regulatory has not provided reporting templates than vendor

will have to provide when regulator issues reporting templates at no cost to the bank.

If any of the report is not there in the system, vendor will have to create, configure,

customize, and parameterize in the system and provide to the bank for testing.

7.2 Report should be of all types such as graphical, heat-map, dashboard, tabular etc.

with drill-down facility to the most granular level. Provide detailed response on this.

2

7.3 Reporting should have flexibility to be generated using multiple dimensions and

combinations of them such as risk entity, legal entity, geography / location, process,

product, risk type etc.

Note: It should be shown during product demo

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

234

Sr. No.


250)

A/W/C/N Comments

7.4 There should be pre-configured standard reports for each of the modules as well as a

consolidated risk profile which can be created at various dimensions such as branch /

region / zone / bank / group etc.

Note: Key Reports should be covered during Product Demo

2

7.5 System should be flexible to configure ad – hoc reports in the manner and form

required by the bank at no extra cost to the bank. New reports are to be created in the

system by the vendor on providing the requirements by the bank.

2

7.6 It should support both regulatory as well as management reports such as risk profiling

of branch, region, zone, bank, group.

If regulator comes with reporting templates in future then vendor will create those

reports in the system, if not already available.

2

7.7 Reports should cover qualitative i.e. results of operational risk management processes

and quantitative i.e. capital calculation processes and combination of them

1

7.8 It should provide a robust analytical framework such as comparison of RCSA, KRI and

Loss Data results, capital consumption vis a vis risk experience, trend analysis,

comparison with peer banks etc.

2

7.9 It should provide facility to access, view, download and print the reports as per user

access rights

1

7.10 Report should be downloadable in excel, word, pdf etc. file formats 1

7.11 Operational Risk Management and Measurement Reports should be generated at

multiple dimensions such as ORM capital as per each business line etc.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

235

Sr. No.


250)

A/W/C/N Comments

7.12 The system should generate periodic reports highlighting the findings of RCSA, Audit,

Losses experienced, Potential loss and Near Miss data, KRI status and Scenario

approach

1

7.13 The system should be capable of generating performance measurement reports

measured vis‐a‐vis RCSA results, KRI status and action taken by units/business lines.

1

7.14 System should provide linkages between RCSA, KRI, loss data and audit processes as

required by the Bank and generate report accordingly

1

7.15 The system should report the operational risk charge before and after any reduction in

capital resulting from the use of insurance.

1

7.16 System should support the generation of various MIS reports such as Loss matrix,

Trend analysis, Issues and action plan status report etc., as per the requirements of the

Bank

1

7.17 System should provide capital charge drill down at each ORC level, which would

provide a split of LDA VAR and Scenario VAR

1

7.18 The system should display capital before BEICF adjustments and capital after BEICF


1

7.19 The system should display capital before diversification and capital after


2

7.20 The system should be able to aggregate the RCSA profiles of each of the products and

business lines to arrive at a Bank wide RCSA profile

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

236

Sr. No.


250)

A/W/C/N Comments

7.21 The vendor should be able to provide post implementation support, configuration

training and end user training.

1

7.22 The system should generate summarized reports regarding the verification and

validation exercise and highlight any outstanding issues. Such reports shall be

customized to be of assistance for reporting to the regulator.

1

7.23 Following is the inclusive list of reports / requirements which system should have:

The system should provide periodic reports on loss event types highlighting the

findings of RCSA, Audit, Loss, Potential loss and Near Miss data, KRI and Scenarios.

Capable of generating performance measurement reports on the basis of logic

provided and on the basis of RCSA results, KRI monitoring and action taken by

units/business lines.

There should be a link between RCSA, KRI, loss data and audit findings.

The system should provide a drill through heat map

The system should provide drill down reporting

The system should report Capital charges, total and by business lines

The system should have adequate graphical reporting tools for reporting loss event

data

System should support KRI dials for the dashboard reporting

System supports to build various MIS reports Loss matrix, Trend analysis, Issues

and action plan status report etc., as per the requirements of the Bank

System should support Slice and dice of structure values and filtering of risk areas

simultaneously

The system should aggregate the RCSA scores of risk events to arrive at a Bank

5


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

237

Sr. No.


250)

A/W/C/N Comments

wide RCSA profile

The system should generate reports outstanding issues at any given date

The system should generate reports for processes that has loss data but no KRI /

RCSA and for processes that have adverse RCSA events but no KRI

The vendor should provide post implementation support, configuration training

and end user training. The system should report operational risk charge before and

after any reduction in capital resulting from the use of insurance.

The system should provide capital charge drill down at each cell level, which

should provide estimates for loss data and Scenario data and From total Scenario

VAR the system should provide drill down to VAR of each Scenario

The system should display capital before BEICF adjustments and capital after BEICF


The system should display capital before diversification and capital after


The system should display the parameters that are used for fitting the distribution

The system should rank and report all test statistics

Total 250


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

238

9.4.2 Technology Requirements Checklist – Operational Risk Management




Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% marks for - Work around (W)’, ‘50% for - Customization (C) and ‘0 for - Not Available (N)’.

Sr. No.


A/W/C/N Comments

1 User Interface 25




2


2



2


2


2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

239

Sr. No.


A/W/C/N Comments


1


2


2


2


3







● Web Page(.HTML)



1


1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

240

Sr. No.


A/W/C/N Comments



3


2


2

2.04 Bidder to provide all updates/modifications on account of regulatory requirements affecting domestic or international operations in respect of the Operational Risk Management System, including Advanced Approaches under Basel II without any additional deve lopment , licensing, implementation and customization costs to the bank during the implementation and AMC period.

3



3.01 System should support archiving of data that are beyond a specified time horizon, to prevent long term speed concerns.

2





-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

241

Sr. No.


A/W/C/N Comments


3

3.06 Export of data to secondary storage device should be supported by the system without down‐time. Secondary storage is for backup purposes. (Retention policy should be as per regulatory guidelines. Backup window should be during off-peak hours.)

2


3


2


2


2



2


2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

242

Sr. No.


A/W/C/N Comments


2


2


2


3



Sr. No.


A/W/C/N


3


3




-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

243

Sr. No.


A/W/C/N Comments




3



2


2


2

5.04 The system should allow reports to be exported into Microsoft Excel, Adobe PDF

format and other databases

1

5.05 The system should allow users to print reports directly from the system 1


1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

244

Sr. No.


A/W/C/N Comments

5.07 The system should generate reports in various types of files like:

2

● View Mode

● Excel Mode

● Text Mode

● HTML Table

● CSV format

● Word File

● PDF format

● XBRL format

5.08 The system should allow for generation of pre‐defined end‐of‐day, end‐of week and end‐of month reports and ad‐hoc reports a s a n d when required

2

5.09 Reports generated in periodical wise or as defined by the Bank: 3

● Daily

● Weekly

● Fortnightly

● Monthly

● Quarterly

● Half‐yearly

● Annual

5.10 The system should allow for archiving of external reports in the following formats:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

245

Sr. No.


A/W/C/N Comments

● Adobe PDF 2

● Microsoft Excel

● Microsoft Word

● Microsoft Access



1


1

6 General 15


3


3

6.03 The system should load calendar schedules from external sources including but not limited to Bank Hol iday , SWIFT, International Holiday schedule and Bloomberg holiday schedule. etc.

2



3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

246

Sr. No.


A/W/C/N Comments

6.06 The proposed Data Mart should be able to integrate with the Enterprise‐wide Data warehouse solution which is going to be implemented in the future. Bank is still implementing DWH, date of completion will be provided at time of SRS.

3

7 Integration 15


15




8 Documentation 10


7






3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

247

Sr. No.


A/W/C/N Comments

Total 150

9.4.3 Hardware Requirements ‐ Operational Risk Management

The Bidder must specify complete details of Hardware and other systems required for successful implementation of the offered Solution, in the

following format.

Sr.

No.


1. Hardware

2. Operating System

licenses(Windows or any

other)


4. Third party utilities

5. Any other requirement

Note:

1 Cost of ETL tools as part of proposed solution should be borne by Vendor

2 Please mention Make / Model (if any), type and number of processors, Memory, bus speed, hard disk & Operating System number of

users, license type, version etc.

3 Detailed Bill of Materials (Line item wise mentioning technical specifications) to be submitted for all the above modules

4 Detailed Technical sheets of the above modules to be submitted

5 Bidder to also provide detailed specifications for replication methodology for DR site


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

248

9.4.4 Functional Requirement Checklist – Credit Risk Management




Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% marks for - Work around (W)’, ‘50% for - Customization (C) and

‘0 for - Not Available (N)’.

Sr.

No.

Credit Risk Functional Requirements Group Weight

(on a scale of

250)

A/W/C/N Comments


1.1 The system should be able to capture and receive the required data (data entry, m a n u a l file uploads, direct transfers, i n t e r f a c e w i t h b a n k ’ s s y s t e m s , batch processes, etc.) from various source systems (internal and external to the bank) like Core Banking Solutions, Internal Rating models / Systems, Data Warehouse, Staging Area, etc. and support various formats (viz. .txt, .XBRL, .CSV, .XML, excel, PDF etc.)

System should have a capability to take data (through manual data upload facility, if direct interface i s n o t p o s s i b l e o r i f b a n k d e c i d e s n o t t o d o d i r e c t i n t e r f a c e ) related to balance sheet, profit & loss, cash flow statements o r a n y o t h e r d a t a w h i c h a r e m a i n t a i n e d m a n u a l l y , using pre‐defined excel sheets and other data formats (viz. .txt, .XBRL, .CSV, .XML) apart from

4


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

249

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

the different systems that Bank is using.

1.2 The bank already has internal credit rating models and score cards

which are system driven. Hence, bank does not intend to purchase

any new rating models at present.

0

1.3 The proposed software solution should be capable of interfacing with

existing and future credit rating systems / score cards / Models,

Internal (such as CBS, LAS, FTP, CLASS, RAM etc.) and External Source

Systems of the bank in an automated manner – through direct

interface with the rating / scoring source systems, through staging area

or through data warehouse as decided by the bank without any

manual intervention.

2

1.4 The proposed software solution should have flexibility to add any

number of rating models and scorecards in future through automated

interface and / or through manual processes.

2

1.5 System should have the capability of interfacing with the proposed

market risk solution presently in use as well as in future to

generate customized reports which may include an overall

dashboard for risk capital numbers or other such reports at bank‐wide

level.

The system should be able to support an interface with Treasury

systems from where the VaR numbers can be fetched

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

250

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

Interface with external third party system will be of batch processing.

1.6 System should have ability to track and store account‐wise previous

credit ratings (external and internal) / scores and LGD.

2

1.7 The system should be able to store a l l the data for at least seven

years extendable up to 15 Years.

Data can be related to customer, security, transaction / facility, credit

rating, credit scoring, defaults, risk components modelling such as PD,

LGD & EAD, retail pooling, capital computation, retail pooling, models

validation, MIS and regulatory reporting including reports itself etc.

Data can be related to FIRB / AIRB Approaches. The bidder is required

to size the storage up to the contract period of 7 years.

Data can be input as well as put data both.

2

1.8 The system should have the provision to run FIRB/ AIRB approach for

certain asset classes in the same execution / cycle for one legal entity

as bank may adopt partial implementation approach as per Basel II /

RBI Guidelines.

3

1.9 System should have capabilities to host the models developed by the

bank AND if any new model is to be developed then system should

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

251

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

have statistical capabilities to develop all the models regarding capital

computation as per IRB requirements, Stress Testing and ICAAP. This

model hosting and development on the system should support all the

approaches as specified by RBI / Basel II / Basel II guidelines under IRB

approach and should consider data available with the bank including

other constraints and assumptions. Model hosting and development

must support expert judgment models, statistical models and hybrid

models based on the data available with the bank.

2 Risk Modelling Capabilities 105

2.1 Scorecard/ Rating model development capabilities 5

2.1.1 The system should enable development of credit scorecards and credit rating models using following statistical techniques (inclusive): 1. Linear regression 2. Logistic regression 3. Clustering

3

2.1.2 The system should provide GUI (Graphical User Interface) to provide

the standard scorecard development steps like data cleansing, single

factor analysis, multifactor analysis, log-odds scaling and final

scorecard generation. Lack of GUI would be treated as non-

compliance.

2

2.2 Probability of default modelling: The system should enable 20


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

252

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

development and configuration of

2.2.1 Calibration curve fitting approach 3

2.2.2 Low default portfolio calibration approach for large corporate 3

2.2.3 The solution should provide the ability to estimates Probability of

Default (PD) / long run PDs using internal rating grades and default

history across all exposure types.

4

2.2.4 The solution should be capable for computing PD based on Internal loss

history, External rating based, Statistical based approaches as per

Basel II / RBI Guidelines for IRB approaches (e.g. - as per all RBI / Basel II

Guidelines). Vendor to develop at least 8 PD models for Non-retail

portfolio using bank’s data and bank’s portfolio and as per Basel II and

RBI guidelines.

4

2.2.5 The solution should be capable of computing Through‐the‐cycle PD and

Point‐in‐time PD. The system should be capable to convert a PIT PD

to TTC PD and vice versa.

3

2.2.6 The solution should support estimation of PD for low default and

low data portfolios

3

2.3 Loss given default (LGD) modeling: The system should enable LGD

modeling using workout LGD methodology and provide ability to

20


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

253

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

perform the following steps

2.3.1 The solution should support both the Foundation as well as

Advanced approaches for collection of LGD data components and

estimation of facility wise Loss Given Default (LGD)

– both economic LGD and accounting LGD‐ across all

exposure types (On and Off Balance sheet exposures), both for

defaulted/ restructured accounts. The system should be capable of

computing LGD using market based LGD, implied LGD and work‐out

method as per the nature, applicability and data availability of credit

risk exposures. Further, the system should be able to drill

down the LGD estimation into industry wise, vertical wise, product

wise, workout method wise, year wise/quarter wise/Other

frequencies/, collateral‐wise and offer additional drilldown options

and reports. It should also support analytics for estimating PD & LGD

correlation. Vendor to develop at least 8 LGD models using bank’s data

and as per bank’s portfolio as per Basel II and RBI guidelines.

3

2.3.2 The system should be able to fetch default and recovery information

from various source systems and data cleansing

2

2.3.3 Choose a discount rate for discounting of recovery cash-flows and

recovery costs

2

2.3.4 Compute the workout period for each portfolio 2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

254

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2.3.5 Compute discounted LGD 2

2.3.6 Develop LGD prediction models using 1. Linear regression 2. Logistic regression 3. Clustering

2

2.3.7 Support GUI interface for end to end LGD modeling 1

2.3.8 The solution should distinguish between senior and subordinated

facilities allocating required LGD to unsecured portion of the facility

as per IRB guidelines

2

2.3.9 The solution should provide for effective LGD where the Bank is

having other financial/AIRB collaterals and pool of collaterals

2

2.3.10 The system should be able to compute Downturn default weighted

LGD as per RBI/ Basel guidelines.

2

2.4 Exposure at Default (EAD) 10

2.4.1 The solution should provide for EAD / CCF and Effective Maturity

(M) calculation for both on and off balance sheet items.

Vendor will develop at least 7 EAD models for bank’s portfolio as per

Basel II and RBI guidelines.

For estimation of EAD & CCF, it should also do undrawn analysis,

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

255

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

UGD (Usage Given Default) analysis etc. and generate reports

2.4.2 The system should have capabilities to capture outstanding and limit

information for all revolving and off-balance sheet exposures

2

2.4.3 The system should have capabilities to compute realized CCF (Credit

Conversion Factor) for defaulted exposures

2

2.4.4 Capability to develop CCF prediction models using 1. Linear regression 2. Logistic regression 3. Clustering

4

2.5 Retail Pooling (as per RBI / Basel II IRB Requirements) 20

2.5.1 The system should support the below techniques (at minimum) for statistical clustering (Applicable for Retail Pooling) inclusive - 1) CART (Classification and Regression Tree) 2) CHAID (Chi-Squared Automatic Interaction Detector)

3

2.5.2 The system should also allow the user to specify pooling criteria based

on the expert judgment. The system should generate decile based

results based on the user provided risk drivers and let the user define

judgmental thresholds.

In addition to this; System should have a capability to develop expert

defined models / scorecards, statistically developed models/score

cards and hybrid models and provide application and behavioral

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

256

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

scorecards

2.5.3 The system should be able to store the data for at least five years at an

account/transaction level to perform the pooling process.

2

2.5.4 The system should be able compute various statistical measures to

demonstrate homogeneity within a pool and heterogeneity across the

pools (E.g.: Gini ratio, Information value etc.)

Vendor to ensure that homogenous pools of retail exposures formed

in consultation with the Bank in compliance with IRB guidelines.

Vendor should have a capability to demonstrate that retail pooling

models and methodology are compliant with the

requirement of IRB Approaches as per RBI / Basel II guidelines.

The system should be capable of performing pooling based on

statistical analysis, application/ behavioral scores and expert

judgment. At a minimum the system should support clustering

techniques such as CART, CHAID and regression trees etc. The logic of

pooling should be configurable in the system. The pooling logic is

subject to change on at least at a yearly basis. Hence the pooling

logic should be defined by user interface through graphical

presentation and should not require any programming or vendor

assistance.

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

257

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2.5.5 The system should have the capability to assign/map new exposures

into the created pools.

The system should have the ability to capture retail exposures at an

account level, assign each exposure to a particular retail pool based

on well-defined risk drivers such as borrower type,

demographics, products, collateral, delinquencies etc. (not limited to

these dimensions) to estimate Pool PD, LGD and EAD.

2

2.5.6 The system should be able to estimate the PD, LGD and EAD for retail

exposures at a pool level. Vendor will develop 30 PD and 30 LGD

models for bank’s retail portfolio as per Basel II and RBI guidelines.

3

2.5.7 The system should generate reports to monitor/track pool stability and

accuracy.

2

2.5.8 The system should be able to update the pool allocation on a

periodical basis based on latest behavioral information

System should have a capability to compute behavioral score for the

retail products as a whole on a periodic basis

3

2.6 Basic modeling techniques: The system should support the following

basic modeling steps

5

2.6.1 Sampling techniques (Simple, stratified, random etc.) 1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

258

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2.6.2 Missing value imputation 1

2.6.3 Outlier detection and elimination 1

2.6.4 Variable transformation (Transformations like natural log, exponential,

inverse, sin, root etc. should be available)

1

2.6.5 The Regression modellings like below should be supported 1) Simple, 2) Multiple, 3) Logit, 4) Probit, 5) GLM (Generalized Linear Model) 6) GLMM (Generalized Linear Mixed Model) etc.

1

2.7 Model Validation: The software should be capable to support

quantitative model validation techniques as prescribed in Basel II

Working Paper 14. In particular, the software should support

conducting the following tests at Model level and each individual

factor level:

15

2.7.1 Discriminatory power tests - Gini Curve, Accuracy Ratio, ROC Curve,

Area Under Curve, Comparison of Goods and Bad (Comparison of

average model score in case of defaulted and non-defaulted

borrowers)

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

259

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2.7.2 Calibration Test - Hosmer Lemeshow Test, Kolmogorov-Smirnov (KS)

Test, Concentration Analysis in rating grades and individual factor

scores.

2

2.7.3 Stability Test - Population Stability Index (PSI) Test 2

2.7.4 Additionally, the system should provide other factor level tests such as

Good vs. Bad analysis, Log-odds trend analysis

2

2.7.5 The software should provide the results of above tests in pre-defined

report formats (tabular and graphical formats)

2

2.7.6 Back testing techniques for PD, LGD & EAD models 2

2.7.7 The system should have the capabilities / Functionalities / Tools to

validate credit rating models / score cards / risk estimation Models

(PD, LGD and EAD) / Retails Pools on continuous basis and the same is

to be done in compliance with RBI / BCBS Guidelines.

The system should provide documented methodology and tools for

validation of above on continuous basis.

The validation process should help the Bank to meet regulatory

requirements of RBI / BCBS.

Validation process should enable the Bank to assess the

performance of internal rating and risk estimation methods

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

260

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

consistently and meaningfully.

Vendor should give complete documentation of validation

methodology including user manuals.

2.8 Maturity(M) 5

2.8.1 The system should be able to calculate Effective Maturity for corporate

exposures

2

2.8.2 The system should interface with CBS to capture the individual cash

flow information (Cash flow amount, data, type etc.) for corporate

exposures

3

2.9 Modelling – Other Requirements 5

2.9.1 The solution should provide necessary treatment for repo style

transactions/ guarantees/ credit derivatives under both foundation as

well as advanced approaches

1

2.9.2 The solution should provide exposure adjustment by segmenting it

into portions covered by different collateral and guarantee types and

portion remaining unsecured as per Basel‐II/ RBI guidelines

1

2.9.3 The system should have the ability to capture and map PD, LGD, EAD

and Maturity for the FIRB/AIRB asset classes and apply the same in

capital calculations.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

261

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2.9.4 The solution should support development of multiple PD, LGD & EAD

models and should enable for validation.

1

2.9.5 The solution should be able to generate PD, EAD, LGD for sub‐

portfolio like industry, sector, Geography etc.

1

3 Capital Computation Rules 50

3.1 Capital Computation General 10

3.1.1 At present Bank is following Standardized Approach.

The solution should support multiple approaches simultaneously for

multiple legal entities for the banking group for a given point of time.

The solution should support multiple approaches IRB as well as Std.

Approach both simultaneously within one legal entity for a given point

of time as bank may adopt partial roll-out for certain asset classes.

System should allow this partial roll-out on all the criteria as given in

RBI Guidelines for IRB approach

2

3.1.2 System should support computation of capital with exemption to

certain portfolio(s). System should be able to exclude exempted

exposures in the capital computation but still taking data from bank

source systems as it may be required for reporting purposes

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

262

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

3.1.3 The system should be able to perform firm‐size adjustment for

small and medium size entities

1

3.1.4 The solution should provide methodology for computation of

Expected Loss (EL), best estimate of Expected Loss, UL, and RWAs

for Credit risk under both foundation as well as advanced approaches

for defaulted / non-defaulted exposures

1

3.1.5 The system should support VaR model (99th percentile, one tailed), i.e.

the system should have the ability to build VaR Model. The system

should be able to take the equations as per regulatory formulas and

perform capital calculations

1

3.1.6 The system should be able to compute expected/unexpected

portfolio losses incorporating:

Default risk/transition probabilities

Recovery rates

Correlation and diversification effects between counter parties

1

3.1.7 The system should be able to capture Failed Trades ('Delivery

versus Payment' and 'Non Delivery versus Payment') i.e. unsettled

securities and foreign exchange transactions) and should be able to

calculate capital as per Basel II Guidelines

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

263

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

3.1.8 The system should be able to calculate capital requirement individual account‐wise and also units‐wise such as:

Entire Bank

Region/zone

Geography

Industry

Business segments

Products

Rating wise

Branch

Relationship Manager

1

3.2 Asset classification: This section covers all the system requirements

pertaining to capture of bank data and assigning each credit exposure

into one of the RBI defined asset classes (Corporate, Bank, Sovereign,

Retail, Purchased receivables and Securitization)

10

3.2.1 The system should provide a graphical user interface to enable the

business users to alter the risk weighted asset computation rules as

per the directives of RBI released in future.

There should no back-end programming required for performing asset

classification based on the source system data. If this requirement is

not yet available, score for this entire section would be zero

All the asset classes as defined in RBI circular should be supported by

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

264

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

the system for IRB approach

3.2.2 The system should provide GUI to perform mapping of : a) Bank asset class to Basel asset class b) bank product type to Basel product type c) Bank security type to Basel security type

The solution should have the ability to map the internal risk grades of

the specialized lending subclasses (PF, OF, CF, IPRE and HVCRE) to

supervisory categories as per Basel‐II guidelines.

Enable the user to define multiple portfolios or asset classes based on

multiple dimensions (such as borrower constitution, industry,

product type, loan amount etc. but not limited to) and associate

borrower rating model and facility rating models to the user

defined portfolios.

The system should provide business user friendly graphical user

interfaces (GUI) to perform bank classes to Basel II data mappings.

Map Bank customer types to Basel II customer types

Map Bank product types to Basel II product types

Map Bank security/collateral types to Basel II collateral types

Map Bank asset type/guarantor type to Basel II asset type

Any other mapping as required under RBI/ Basel II guidelines

Above mapping should not involve coding, involvement of technical

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

265

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

configuration, customization etc.

3.2.3 The software should be flexible for the business user to use multiple

factors such as customer constitution code, product type, exposure

amount, legal status etc. to perform Basel II asset classification.

The solution should be able to capture all the Bank Customer Types,

Bank Product Types, and should be able to reclassify/categorize them

as Basel asset class wise.

The solution should support categorization of asset classes and sub

classes as defined under IRB approaches as given the Basel II Accord /

RBI guidelines (Corporate, Sovereign, Bank, SME, SL classes, Retail,

QRRE, equity, purchased receivables, securitized etc.).

The software should be flexible for the business user to use

multiple factors such as customer constitution code, product type,

exposure amount, legal status etc. to perform Basel II asset

classification and Basel II collateral classification.

The system should be able to define portfolio based upon the

following aggregation possibilities such as:

Counter‐party or combination of counter parties

Industry / Sub-industries

Tenor

Product

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

266

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

Geography

Issuer

Credit rating

Currency

Any internal hierarchy



3.2.4 The user should be able to view the entire asset classification schema

and it should be printable to be submitted for regulatory inspections

and audits.

2

3.3 Credit risk mitigation 15

3.3.1 The system should support all the credit risk mitigation techniques

specified in the RBI circular on NCAF and IRB guidelines.

Along with the eligible financial collateral recognized in the

Standardized approach, the solution should recognize the other

eligible FIRB/AIRB collaterals and provide necessary treatment as

outlined in the Basel II accord/RBI guidelines.

1

3.3.2 The system should have the ability to map the Collateral/Security

Types (which the bank uses for internal reporting) into collaterals types

as per RBI Guidelines (Cash, Gold, KVP, Life Insurance, Debt Securities,

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

267

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

and Mutual Funds etc.)

The solution should be able to capture all types of risk mitigation

inputs and should have the ability to reclassify/categorize the bank’s

risk mitigation tools / mechanisms into Basel defined risk mitigation

inputs types as per Basel II Guidelines/ RBI guidelines. The solution

should be able to allocate different collaterals to different facilities

using multiple algorithms, approaches (Simple, comprehensive, FIRB,

AIRB) and Basel‐II guidelines by RBI.

3.3.3 Provide a GUI to define the hair-cuts for various collateral types as

defined in RBI guidelines.

The solution should have the ability to compute, make estimates,

and apply haircuts on collaterals and exposures as per Basel‐II

accord/ RBI guidelines on IRB approach.

1

3.3.4 The system should be able to apply supervisory haircut on exposures

and mitigants, and compute capital after applying Credit Risk

Mitigation techniques as per RBI Guidelines.

1

3.3.5 System should support collateral optimization as well as pre-defined

ranks provided by the bank both.

1

3.3.6 The system should have the ability to assign the risk weights for

Guarantors as per RBI Guidelines.

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

268

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

3.3.7 The system should be able to capture the relevant data fields for

Currency and Maturity Mismatch calculations and should also be able

to apply the haircuts as per RBI Guidelines.

1

3.3.8 The system should be able to capture collateral which is a basket of

collaterals and should also be able to calculate the haircut on the

basket of collateral. Haircuts applicable on the basket of assets should

be taken into account while calculating the capital as per RBI

Guidelines.

The system should be capable of applying a weighted average of

haircut if the collateral is basket of assets as per RBI / Basel II

guidelines.

1

3.3.9 The system should be able to perform on balance sheet netting and

capital calculation based on the net credit exposure.

1

3.3.10 The system should be able to apply haircut scaling formula (based on

holding period and frequency of reimagining/revaluation period) as

prescribed by RBI Guidelines.

The solution should make adjustments for different holding periods

based on the quality of collaterals and non‐daily mark to market or re‐

margining

1

3.3.11 The system should be able to capture guarantee, counter guarantee

and credit derivative details and should be able to calculate capital as

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

269

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

per RBI Guidelines.

3.3.12 The system should be capable of computing the collateralization levels

and FIRB rules based on the collateral information.

The system should allow user to compute for eligible IRB collaterals

(viz. minimum ‐ collateralization or over‐collateralization or under‐

collateralization)

1

3.3.13 The system should have pre-build rules for double default framework

for hedged portfolio, capital computation

The solution should be able to use double default methodology for

capital computation.

The system should be able to apply double default treatment for the

hedged portion and compute capital requirement for double default

In case of maturity mismatch for double default transactions and

other transactions, then the system should be able to perform the

maturity adjustment as per Basel II Guidelines.

The system should be able to do calculations for currency mismatches

also

1

3.3.14 System should be able to do collateral optimization as well as bank

defined mapping / ranking of collaterals against an exposure

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

270

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

3.4 RWA computations 15

The system should come with pre-build rules for computation of RWA

for:

0

3.4.1 Corporate – Non SME 2

3.4.2 Corporate – SME 2

3.4.3 Bank 1

3.4.4 Sovereign 1

3.4.5 Retail 2

3.4.6 Equity Exposures through 1. Market based 2. Simple risk weight 3. PD/LGD approach 4. Internal Models Method The system should support interface with treasury/market risk systems

to fetch equity related data.

2

3.4.7 Securitized exposures: the system should be able to 4. Capture the bank roles (e.g. Originator, investor etc.) for the

securitization exposures(on balance sheet, off balance sheet, drawn and undrawn portions), and should calculate the capital as per RBI Guidelines

5. Apply CCF's and calculate capital for securitization exposures with

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

271

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

early amortization features. 6. Supervisory formula for capital computation

3.4.8 The system should be able to calculate capital for Traditional and Synthetic Securitization exposures.

1

3.4.9 The system should be able to capture the bank’s role (e.g. Originator, investor etc.) for the securitization exposures, various credit enhancements and should calculate the capital as per Basel II Guidelines

1

3.4.10 The system should have CCF's models and calculate capital for securitization exposures with early amortization features The system should be able to apply the supervisory formula for capital calculation of Securitized Exposures as per Basel II / RBI Guidelines.

1

3.4.11 Purchased receivables for corporate and retail. The computation

capabilities should cover default risk and dilution risk.

For Default risk, the system should be able to apply Top‐down

Approach or Bottom- up Approach for both corporate and retail

exposures (purchase – receivable asset class wise). Also based on

the exposure type, the system should be able to apply retail or

corporate risk weight functions to arrive at the default risk weight

1

4 Stress testing 15

4.1 The stress testing module of the proposed solution should be in

compliance with the RBI circular on Stress testing (DBOD.BP.BC.No,

75/21.04.103/2013-14 dated 2nd December, 2013) and support the

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

272

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

following aspects:

4.2 The system should have the ability to perform the stress tests (for all

the asset classes) for PD, LGD, EAD, CCF and Maturity. System

should be able to Simulate stress test on various parameters like PD,

EAD, and LGD for Capital requirement & RAROC. Examples of

scenarios that could be used are:

Economic or industry downturns

Market Risk events

Liquidity conditions

Vendor should provide all the scenarios for the purpose of stress

testing for bank’s review and confirmation for stress testing above

2

4.3 Creation of sensitivity tests 1

4.4 Creation of multi factor scenarios based on historical scenarios,

hypothetical forward looking scenarios based on macroeconomic data

points

2

4.5 Capability to develop and deploy stress testing models which would assess the impact of multiple macroeconomic factors on the portfolio risk parameters like PD, LGD, EAD, loss rate etc. The solution should support the following statistical modeling capabilities: 1. Time series and regression techniques (Simple, Logistic, GLM, GLMM etc.)

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

273

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

2. Standard Probability distributions (normal, student-t etc.)

4.6 Capability to compute the correlation structure between various risk silos using: 1. Variance covariance approach 2. Copula approaches

1

4.7 Capability to assess second order impact of risk silos (E.g., Impact of

reputational risk on Credit risk)

1

4.8 Support reverse stress testing 2

4.9 System should be capable of computing the impact of stress scenarios

through the stress testing models on Capital, Liquidity and Profitability

metrics of the Bank.

2

5 Capital efficiency monitoring, Capital planning and management, risk

based pricing and performance measurement

10

5.1 The system should be able to capture necessary information like

interest income, interest expense, provisions, capital, operating

expense to compute RAROC on an ex-post basis for performance

measurement and capital allocation purposes

1

5.2 The system should be able to compute RAROC and SVA (Shareholder

Value Added) for each facility on an ex-post basis. The RAROC and SVA

should also be computed for each user defined portfolio. (For example,

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

274

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

Corporate Portfolio, Home Loan Portfolio, Rating grade 2, etc.)

5.3 Calculation of Risk Adjusted Return on Capital (RAROC) based on

regulatory capital as well as economic capital.

1

5.4 The system should support capital allocation based on RAROC. 2

5.5 The system should support to capture data and configure reports to

monitor capital efficiency parameters at various levels (bank, region,

circle, branch level). The capital efficiency parameters would range

from RAROC, unutilized CC limits, unrecognized government

guarantees, unrated exposures etc.

2

5.6 The system should be able to compute the risk premium to be charged

at a rating grade level, product level and transaction level based on

incremental capital required to fund the transaction using both Std.

Approach and IRB Approach.

1

5.7 System should have the capability to compute CVA (Credit Value

Adjustment) under RBI /Basel‐III Guidelines.

1

6 Reporting capabilities 35

6.1 The proposed system should comprise of a Business Intelligence tool,

in which a reporting data mart can be created and business users can

generate any type of reports, graphs, and dashboards through front-

5


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

275

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

end. The system should support reporting for:

6.1.1 Regulatory reports (pertaining to Basel II, Basel III)

Pillar III Disclosures: The system should have pre‐built pillar 3 reports

as per Basel / RBI guidelines on Basel‐II and Basel‐III.

1

6.1.2 Origination metrics 1

6.1.3 Capital efficiency monitoring 1

6.1.4 Basel II & III parameter reports 1

6.1.5 The BI reporting utility should enable the bank to generate reports at 1. Bank level 2. Region/Circle level 3. Branch level 4. Counterparty level 5. Transactional level

1

6.2 System should provide the following reports and requirements

related to reports

30

6.2.1 System should support regulatory and MIS reports on all the dimensions used for defining the asset classes, securities / collaterals, regulatory, risk component, capital computation etc.

RBI has not yet issued IRB reporting formats hence vendor must define create and customize them as and when RBI issues reporting

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

276

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

templates without any extra cost. It will be Vendor’ responsibility to create those reports in the system.

Bank may require ad-hoc reports which either system must support by

enabling business user to create by using defined dimensions without

any intervention of technology, coding, programming. User should be

able to create through graphical user interface. If it is not possible then

vendor should create and customize ad-hoc reports in the system.

6.2.2 The system should have the pre‐built & configured templates and should also have the functionality for a business user to define and customize new Credit Risk MIS across all matrix dimensions such as:

Counter‐party

Portfolio

Product

Geography – country/ state/zone/branch

Industry

Concentrations

Risk Profiles

Rating wise

Delinquency buckets

PD Bands

LGD Bands etc.



2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

277

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

6.2.3 The solution should be able to generate Risk Profile Template as per

RBI guidelines and other regional/branch‐wise risk profile templates

for credit risk as per Bank’s internal requirements

2

6.2.4 The system should be capable of generating various Bank‐ defined

reports like:

Borrower Information report

Industry Analysis report

Monitoring (Account‐wise report to cover rating transition &

trend in critical identified parameters)

Peer group Analysis report

Rating wise reports

Portfolio reports

Borrower‐wise risk score report

Borrower‐wise risk grade report

Borrower‐wise year wise risk score report

Borrower‐wise year wise risk grade report

Industry Concentration Report

Industry‐ wise risk grade report

Region wise Concentration Report

Region ‐ wise risk grade report

Quick mortality Report

Defaulted Account Report (Grade wise/ Industry wise/ year wise/

ownership wise/ size wise/ on‐balance sheet / off‐balance sheet

3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

278

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

exposure wise for a date range etc.)

RAROC reports‐ vertical wise, geography wise, rating grade wise

etc.

Capital Charge‐credit risk (Regulatory and economic) –

expected and unexpected losses

Exposure Reports (Portfolio exposure

by Sector/ industry/credit rating/ Client/ Loan

Size/ Maturity/ country/currency/On‐balance sheet/ off‐

balance sheet exposure/interest rate wise/floating rate wise –

internal and external benchmark /fixed rate wise etc. after

including/ excluding CRM – giving NPA position separately

under each of these categories along with reports on

accounts which have been upgraded from NPA and which have

slipped to NPA from standard Position, of restructured accounts

under each of the categories along with reports on accounts

which have been upgraded from restructured and which have

slipped to NPA from restructured status

Report on restructured exposures, repeated restructured accounts

and drill down options like industry‐wise, rating‐grade wise, curing‐

wise, tenor wise, sacrifice wise, product‐wise, vertical‐ wise, region‐

wise, branch‐wise, asset class‐wise.

6.2.5 The reports should be able to cut- across asset classes and give

combined reports, if needed, while analyzing industry‐wise, product‐

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

279

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

wise, sector‐wise reports (e.g.: exposure to

cement industry report should be combined and render a

consolidated report on all exposures under various asset classes)

6.2.6 Collateral Reports (Collateral wise exposure report (total exposure

after netting that is covered by 1. Eligible financial collateral 2 .

Other e l ig ib le A I R B c o l l a t e r a l 3. Guarantees etc.) including

current market value of collateral wherever applicable as per policy of

the Bank

1

6.2.7 Expiry reports on collateral (Due to expire/expired) -

bank/zone/branch/account wise

1

6.2.8 Residual Contractual Maturity Breakdown of the whole portfolio

broken down by major type of Credit Exposures

1

6.2.9 Exposure weighted average LGD/EAD for each borrower category 1

6.2.10 Securitization disclosure (total outstanding exposure securitized by

bank broken-down by type of securitization (traditional/Synthetic),

exposure type.

1

6.2.11 Amount of NPA securitized broken down by exposure type 1

6.2.12 Securitization exposure retained/purchased broken down by

exposure type. (This report would be generated for user defined

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

280

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

period and as of date).

6.2.13 Report on capital market exposure as required as per RBI

requirement – account wise as per limit and outstanding exposure –

on and off balance sheet

Report on exposure to Real Estate – commercial and residential

– direct and indirect

Report on exposure to commodities

1

6.2.14 Report on Interest rate wise break up of advances – segment wise

(term loans, project finance, bills purchased/discounted or

negotiated, demand loans, CC, staff loans etc.) as per user defined

range of rate of interest

1

6.2.15 Report on Interest rate wise break up of advances – segment wise ‐ as

per user defined range of rate of interest

1

6.2.16 Report on position of unsecured exposure –

public sector/private sector/rating wise/interest rate wise/maturity

wise

Report on break up of term loans, project finance, bills

purchased/discounted or negotiated, demand loans – as per

residual maturity

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

281

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

6.2.17 Report on pre- payment of total/instalment of term loans, project

finance, bills purchased/discounted or negotiated, demand loans

1

6.2.18 Report on segment wise exposure – Report on future draw down

schedule for term loans, project finance and infrastructure projects

Report on single borrower/group borrower exposure – user defined

number of top exposure vis‐à‐vis prudential exposure limits fixed

by bank/regulator

1

6.2.19 Export formats for MIS report –

‐.TXT

‐.XLSX

‐.PDF

‐.DOCX

‐.PPTX

‐.XML

‐.XBRL

1

6.2.20 Overrides performance reports – performance of accounts where

there is rating over‐ride or downgrades (Branch wise / region

wise /geography wise/level wise/approving user wise rating cases

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

282

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

processed, approved, rejected and pending for user defined period.

6.2.21 The system should support portfolio‐based calculation like Limits

Management: Bank may define a limit cap (may be absolute or %

terms) to an industry, borrower, individual exposure, and bank,

sovereign, rating.

The system would check the same and generate reports. What

if/Incremental risk analysis by addition of individual loan portfolio for

decision making purpose.

Portfolio based calculation should take into account industry

correlation to arrive at capital requirement.

The system should be able to perform portfolio analysis by fixing and

measuring exposures and limits inclusive of correlation effects within

portfolio parameters

1

6.2.22 The system should provide facility to generate customized report for

user like Top Mgmt., Risk Management Dept., Branch Manager, and

Relationship Manager etc. Graphical representation of reports,

wherever required.

Access to certain reports would be restricted to certain groups.

1

6.2.23 The system should be able to generate risk maps, risk charts, trend

analysis etc. for Pillar‐I and Pillar‐II risks, various risk dashboards for

1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

283

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

the users and top management.

The solution should have the flexibility of viewing the reports at an

aggregated level or at granular level

6.2.24 System should have the capability to generate back dated reports

Audit log report

1

7 ICAAP 10

7.1 The system should have a Pillar‐II module which supports ICAAP

analysis of all material Pillar‐II risks of the Bank and do capital

computation, for risks like concentration risk (branch wise, Zone

wise, state wise, industry/ sector wise, product wise, vertical wise

rating‐grade wise, interest rate wise, group‐wise, borrower‐wise

etc.), reputation risk, strategic risk, compliance risk,

underestimation of risk under standardized approach, model risk,

liquidity risk, interest rate risk, forex risk etc., as per relevant RBI/

Basel guidelines on Pillar‐II.

Data required for the preparation of ICAAP document has to be

generated through the system.

2

7.2 The system should perform stress testing for each of the credit,

market, interest rate, forex, liquidity, concentration risk on

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

284

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

individual basis and aggregate the results of stress testing.

The system should at the same time assist in reporting, back testing

and assessment of capital for Pillar‐II risks.

Additionally, the system should also support aggregation of Pillar‐II

capital into Bank‐wide capital (regulatory & Economic capital)

assessed.

7.3 The System should be able to support and have the necessary

statistical tools to validate the material risk

estimation methodologies and stress testing methods under

Pillar‐2.

2

7.4 The system should have capital planning and budgeting modules for

est imat i n g bank‐wide capital for future, stress testing by changing

assumptions/ macro‐economic scenarios, allocation across business

units, geographies, products etc., if needed.

2

7.5 The system should be able to generate risk maps, risk charts, reports,

trend analysis etc. for Pillar‐II risks, various risk dashboards for the

users and top management.

2

8 Basel III Requirements 5

8.1 The system should have the capability for computation of non‐risk 3


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

285

Sr.

No.


(on a scale of

250)

A/W/C/N Comments

based leverage ratio as per RBI/ Basel‐III guidelines.

The system should have the flexibility to enable reporting and

estimation of each capital components like common equity, Additional

Tier‐1, Tier‐2 etc. as per prescribed guidelines of RBI under Basel‐III.

The Pillar‐1, Pillar‐2 and Pillar‐3 modules should be compliant with

RBI’s Basel‐III requirements also.

8.2 System should facilitate capital computation and computation of

leverage ratio as per Basel II & III guidelines

2

Total Marks 250


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

286

9.4.5 Technology Requirements Checklist – Credit Risk Management




Marks will be awarded as ‘Maximum Marks for - Readily Available (A)’, ‘75% marks for - Work around (W)’, ‘50% for - Customization (C) and ‘0

for - Not Available (N)’.

Sr. No.


A/W/C/N Comments

1 User Interface 25




2


2



2


2


2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

287

Sr. No.


A/W/C/N Comments


1


2


2


2


3







● Web Page(.HTML)



1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

288

Sr. No.


A/W/C/N Comments


1



3


2


2

2.04 Bidder to provide all updates/modifications on account of regulatory requirements affecting domestic or international operations in respect of the Credit Risk Management System, including Advanced Approaches under Basel II without any additional deve lop ment , licensing, implementation and customization costs to the bank during the implementation and AMC period.

3



3.01 System should support archiving of data that are beyond a specified time horizon, to prevent long term speed concerns. Bank needs a separate data archival solution and query on archived data is required.

2





-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

289

Sr. No.


A/W/C/N Comments


3

3.06 Export of data to secondary storage device should be supported by the system without down‐time.

2


3


2


2


2



2


2


2


2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

290

Sr. No.


A/W/C/N Comments


2


3




3


3






3



-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

291

Sr. No.


A/W/C/N Comments


2


2


2

5.04 The system should allow reports to be exported into Microsoft Excel, Adobe PDF format and other databases

1

5.05 The system should allow users to present outputs from reports in The system should allow users to print reports directly from the system

1


1


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

292

Sr. No.


A/W/C/N Comments

5.07 The system should generate reports in various types of files like: ● View Mode ● Excel Mode ● Text Mode ● HTML Table ● CSV format ● Word File ● PDF format ● XBRL format

2

5.08 The system should allow for generation of pre‐defined end‐of‐day, end‐of week and

end‐of month reports and ad‐hoc reports a s a n d when required

2

5.09 Reports generated in periodical wise or as defined by the Bank: ● Daily ● Weekly ● Fortnightly ● Monthly ● Quarterly ● Half‐yearly ● Annual

3

5.10 The system should allow for archiving of external reports in the following formats: ● Adobe PDF ● Microsoft Excel ● Microsoft Word ● Microsoft Access ● Comma separated values (.CSV)

2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

293

Sr. No.


A/W/C/N Comments


1

4


1

6 General 15


3


3

6.03 The system should load calendar schedules from external sources including but not limited to Bank Ho l iday , SWIFT, International Holiday schedule and Bloomberg holiday schedule. etc.

2



3

6.06 The proposed Data Mart should be able to integrate with the Enterprise‐wide Data warehouse solution which is going to be implemented in the future.

3

7 Integration 15


15


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

294

Sr. No.


A/W/C/N Comments




8 Documentation 10


7




d) Documents narrating the mathematics, the assumption in all the Models / Pricing engines used in the software

8.02 Comprehensive documentation with indices or glossaries targeted at specific audience of users, systems manager/administrator

3

Total 150


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

295

9.4.6 Hardware Requirements ‐ Credit Risk Management

The Bidder must specify complete details of Hardware and other systems required for successful implementation of the offered Solution, in the

following format.

Sr.

No.


1. Hardware

2. Operating System

licenses(Windows or

any other)


4. Third party

utilities

5. Any other

requirement

Note:

1. Cost of ETL tools as part of proposed solution should be borne by Vendor 2. The hardware and infrastructure sizing should be done with registered user of 20, current concurrent user base of 10. At present, total

number of accounts in loan portfolio of the bank is: (a) number of fund based accounts – approx. 35 lacs (b) number of non-fund based accounts 1 lacs (c) Number of securities 50 Lacs (d) average number of securities per account is 1. Loan portfolio is expected to increase @ 15% per annum and expected customer growth around 10% per annum.

3. Please mention Make / Model (if any), type and number of processors, Memory, bus speed, hard disk & Operating System number of users, license type, version etc.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

296

4. Detailed Bill of Materials (Line item wise mentioning technical specifications) to be submitted for all the above modules 5. Detailed Technical sheets of the above modules to be submitted 6. Bidder to also provide detailed specifications for replication methodology for DR site 7. Application user: pan India 8. Batch frequency: daily 9. Historical reporting requirements for Credit Risk Management: Quarterly 10. Extracts from the source systems will happen daily 11. Data refresh frequency: daily 12. Workload will peak over a particular period of time 13. Bidder to provide ETL processing 14. Time window for running the pre-configured workflows is 25 hours 15. Bank case use Banking DDS and map to source systems both


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

297

9.4.7 Hardware & Infrastructure Configurations for the Proposed Solution (both for CRM & ORM)

Configuration for the hardware and other infrastructure components required for the proposed solution should be provided in the table below.

It is important for the bidder to provide the details with a view for seven years. It should also provide the details for the deployment of each

component in a phased manner aligned with the expected volume growth.

Sl.

No.

Components Proposed Configuration Justification

I. Application Servers

1

Data Center Application

Servers

• CPU • Memory • Hard disc • Network Interface Cards • Mother board • Operating System

• Other Components

2

Disaster Recovery Center

Application Servers


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

298

Sl.

No.


• CPU • Memory • Hard disc • Network Interface Cards

• Mother board • Operating System • Other Components

II. Database Servers

3

Data Center database

Servers

• CPU

• Memory • Hard disc • Network Interface Cards • Mother board • Operating System • Other Components

4

Disaster Recovery Center


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

299

Sl.

No.


Database Servers

• CPU • Memory

• Hard disc • Network Interface Cards • Mother board • Operating System • Other Components

III. Test & Development Server

5

Test & Development

Servers

• ‐ CPU • ‐ Memory • ‐ Hard disc • ‐ Network Interface Cards • ‐ Mother board • ‐ Operating System

• ‐ Other Components


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

300

Sl.

No.


IV. Storage Solution

6

Storage Area Network

• SAN‐Modules

• Disk Arrays (including the raw

size. Provide complete technical

details of the proposed solution.)


SAN Switch

Tape Library

• Drives

• Tapes


Backup Server

• CPU


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

301

Sl.

No.


• Memory

• Hard discs

• Network Interface Cards

• Mother board

• Operating System


V. RDBMS Details

7

RDBMS – Licenses

• Name and Version of the

RDBMS • Licensing Mode ‐

(Processor Based/ Server Based / Others)

• No of Units

VI. Integrated Capital Computation & Reporting Module

8

ETL Tool – Name and

Version


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

302

Sl.

No.


• License Mode

• Server Requirement (Application / Database)

9

Reporting Tool ‐ Name and

Version

• License Mode

• Server Requirement

(Application / Database)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

303


Please provide descriptive answers to the following questions on Operational Risk management.

Sr.

No.


1 How many Implementation trainings (ORMS) have been

undertaken by the Bidder so far?

2 Please provide a brief description on the Training approach

taken by the Bidder.

3 Please provide the following details for training :

3.1 Number of man‐days / duration for completion of training



3.4 Location



4 Please answer the following about the trainers in‐ charge of

conducting the training on behalf of the Bidder for the Bank:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

304

Sr.

No.



Bidder who would be involved with the Project

4.2 Median experience of all trainers involved with the Project as

trainers

4.3 Median experience of all trainers involved with the Project,

working / training on the solution proposed by the Bidder

5 Please provide a sample training response and feedback from

previous implementations?

6 Also, please give details of the following:






Note: Please attach the feedback in a separate document with

proper cross‐referencing.

7 Please specify the various modes through which the training will

be delivered? [e.g. Classroom training, Online self‐help training


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

305

Sr.

No.


modules within application / e‐learning modules, Quiz, etc.]

Please provide descriptive answers to the following questions on Credit Risk management System.

Sr.

No.


1 How many Implementation trainings for Credit Risk Management

System (CRMS) have been undertaken

by the so far?

2 Please provide a brief description on the Training approach

taken by the Bidder.

3 Please provide the following details for training :

3.1 Number of man‐days / duration for completion of training



3.4 Location



-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

306

Sr.

No.



4 Please answer the following about the trainers in‐ charge of

conducting the training on behalf of the Bidder for the Bank:

4.1 Median experience of all trainers with the Bidder who would be involved with the Project

4.2 Median experience of all trainers involved with the Project as

trainers

4.3 Median experience of all trainers involved with the Project,

working / training on the solution proposed by the Bidder

5 Please provide a sample training response and feedback from

previous implementations?

6 Also, please give details of the following:






-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

307

Sr.

No.



Note: Please attach the feedback in a separate document with

proper cross‐referencing.

7 Please specify the various modes through which the training

will be delivered? [e.g. Classroom training, Online self‐help

training modules within application / e‐learning modules, Quiz,

etc.]


Sr.

No.



The methodology section should adequately

address the following stages of the project:

1.1 Frequency and approach for periodic reporting on the

progress of the project and actual status vis‐à‐vis scheduled

status

1.2 Detailed Study of Current State, with detailed


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

308

Sr.

No.


work steps and deliverables

1.3 Gap analysis including identification and

resolution of gaps

1.4 Customization, development and necessary work around

1.5 Building up of interfaces with various

applications currently used by the bank

1.6 Setting up of the data center and the disaster recovery site


1.8 Planning for roll‐out and identification of key issues

that may arise along with proposed

solutions

2 Timelines


4 Roles and responsibilities of proposed personnel both from the

vendor and bank end


methodology followed by the vendor in Project


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

309

Sr.

No.


Management for a Public Sector Bank

Project Name

Project Location

Client Name

Client address




Man‐months effort

Project Size (No of branches, modules covered and any other

relevant details)




Role of the Bidder, whether complete end‐to‐end involvement

or for a particular module

Project detail ((Broad detail – information about all activities

handled, modules forming part of the Operational Risk

Project of the Client Bank, associated activities, time lines

activity‐wise and module‐wise may be detailed.)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

310

Signature of Bidder:

Name:

Business Address:

Place:

Date:


311

9.5 Additional Details ‐ for both Credit Risk and Operational Risk Solutions

1. What is the hardware configuration required for optimal running of the software? Please

provide the configuration in line with project duration.

2. What is the current version and release date of the installed product?

3. Details of major enhancements planned.

4. What is the road map of your product for the next 3 to 7 years?

5. What is the next scheduled major release?

6. Describe the integration details and mechanism between the solution components if solution is

modular type

7. Provide a copy of any benchmarking studies performed on your product(s). Please provide layouts

that depict the environment producing these results.

8. Provide details of the product's scalability in order to

o Increase Workload

o Better Performance

o Add more Users

o Improve Network connectivity

9. Describe the integration capabilities of your system to integrate with external Systems. The system

should interface with other solutions for receiving inputs and sending outputs, such as automated

information pricing feeds including but not limited to:

o Reuters

o Negotiated Dealing System

o B@nc24

o Legacy banking applications used by the bank

o CRISIL System (Risk Assessment Model – RAM)

o Other Risk management software

o Data warehousing package (SDR)

o Liquidity management system

o Centralized Loan Appraisal System and Supervision (CLASS)


312

o Any other existing system

9. The integration should be through exposed APIs and not through change in code. Are there standard

API's available for integration with external systems?

10. Data transfer from external system from/to your solution should be automated. Please describe in

detail the capability of your system

11. Please describe the problem reporting and resolution mechanism that would be used if Bank

identifies a problem or change request with the system

12. What is maximum response time in case of problem/ help required?

13. Is the Hotline support with OEM is inclusive in the annual maintenance charge?

14. If charged on a per‐call basis, please provide cost with reference to Q13?

15. What amount of training is included with the acquisition of the proposed systems, in terms of

number of people type of course/agenda and number of man‐days

16. Please specify the details of the training course

o Cost if any

o Location

o Duration

o Frequency of offering

o Prerequisites

o Training description


313

9.6 Cover Letter for Commercial Bid

Date:

To,




1st Floor, Bajaj Bhavan,

Nariman Point, Mumbai – 400 021

Procurement of Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk Management Systems under RBI/Basel II /Basel III Guidelines

Ref: Your Ref: ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Having examined the Bidding Documents, the receipt of which is hereby duly acknowledged, we,

the undersigned, offer to supply, deliver & implement the solution for Operational and Credit Risk

Solution under RBI/Basel II advanced approach, in conformity with the said Bidding documents for

the sum of ...................………….. (Total Proposal amount in words and figures) or such other sums as

may be ascertained in accordance with the Schedule of Prices attached herewith and made part of

this Proposal.

We undertake, if our Proposal is accepted, to deliver, install, commission and implement the system,

in accordance with the delivery schedule specified in the Schedule of Requirements.

We agree to abide by the Proposal and the rates quoted therein for the orders awarded by the

Bank.

Until a formal contract is prepared and executed, this Proposal, together with your written

acceptance thereof and your notification of award, shall constitute a binding Contract between us.

We undertake that, in competing for (and, if the award is made to us, in executing) the above

contract, we will strictly observe the laws against fraud and corruption in force in India namely

“Prevention of Corruption Act 1988”.

We understand that you are not bound to accept the lowest or any Proposal you may receive.

Dated this ....... day of ............................ 2014


314

(Signature) (In the capacity of)

Duly authorized to sign Proposal for and on behalf of


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

315

9.7 Commercial Bid (Bill of Material) Format

9.7.1 Part I – Commercial Bid Format – CRM & ORM Solution (Amount in INR Lakhs)

Sr.

No.

Item Description No. of

Units (A)

Unit

Price

(B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/ Service

Tax)

Total Price

including Taxes

and Octroi

Total

Price

A Software (for both DC & DR site)

1 Operational Risk Management

System

2 Credit Risk Management System

3 Middleware (if any)

4 Third Party Utilities (if any)

5 Software/tools for SLA monitoring

SUB TOTAL A

B Environmental Software

(for both DC & DR)

(to be suggested by the bidder for proposed solution as per their need for the solution)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

316

Sr.

No.


Units (A)

Unit

Price

(B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/ Service

Tax)

Total Price

including Taxes

and Octroi

Total

Price

1 Environmental Software

SUB TOTAL B

C Hardware (for both DC & DR site)

1 Servers

2 Operating System

3 Storage (SAN)

4 Rack with KVM switch, power

supply , Network & security

requirements, switches, routers etc.

5 Hardware required for SLA

monitoring

SUB TOTAL C


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

317

Sr.

No.


Units (A)

Unit

Price

(B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/ Service

Tax)

Total Price

including Taxes

and Octroi

Total

Price

D Implementation, System Integration, Training

Integration of new system with

existing systems

SUB TOTAL (A+B+C+D)

E AMC & ATS cost as per Part II

F Facilities Management (both at DC & DR)

G Change Management Cost (Cost for 100 Man days)

Total Project Cost (A+B+C+D+E+F+G)

Total Project Cost (in word)

Rs……………………………………………………


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

318

Sr.

No.


Units (A)

Unit

Price

(B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/ Service

Tax)

Total Price

including Taxes

and Octroi

Total

Price

H Additional Training Cost (per Person per day

rate)

Important Notes: The detailed specifications of all software and the required hardware modules, components are to be attached separately in the

Technical Bid (Section 9.4.3, 9.4.6 and 9.4.7: Hardware Requirements), supported by Technical Literature/ Product Catalogues/

Brochures, etc. This is Mandatory.

1. All estimation to be done for both DC & DR

2. Bidder to clearly provide in the solution the training requirements – # of batches, participants in each batch, how much time, type

of training ‐ (functional or technical) and Incorporate them in the pricing

3. AMC & ATS charges to be given in the format prescribed below.

4. Price quoted should be inclusive of all costs and taxes like customs duty, excise duty, import taxes, freight, forwarding, insurance,

delivery, installation, training etc. at the respective delivery location of the bank but exclusive of only applicable (in India) Sales

Tax/VAT, Service Tax and Octroi /Entry Tax / equivalent local authority cess, which shall be paid / reimbursed on actual basis on

production of bills. Further, receipts of such payments made to relevant authorities must be produced for Octroi / Entry Tax /

equivalent local authority cess. The Bank will not pay any other taxes, cost or charges.

5. Service taxes will be paid extra and TDS will be deducted separately.

6. In case of discrepancy between figures and words, the amount in words shall prevail.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

319

7. No increase in costs, duties, levies, taxes, charges, etc., irrespective of reasons (including exchange rate fluctuations, etc.)

whatsoever, shall be admissible during the currency of the Contract.

8. All user licenses for operating system, database, application etc. should be as per Technical and Functional Requirements

9. For calculation of TCO, AMC costs for 1 year will be taken into account

Signature of Bidder‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Name ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Business address ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Place Date:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

320

Part II – Schedule for Annual Maintenance Cost (AMC) and Annual Technical Support (ATS) and Warranty Period

Sr.

No.

Module/ Item Description Annual charges per

period including upgrades

(if any) for each item (A)

Period 1yr

(B)

Total maintenance

charges

(A*B)

Total (to be carried forward to Part

I)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

321

Signature of Bidder‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

Name ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐

*The AMC Price should be valid for 3 years.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

322

9.7.2 Part I – Commercial Bid Format – CRM & ORM Solution (Masked)

Sr.

No.


Units (A)

Unit

Price (B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/

Service Tax)

Total Price

including

Taxes

and

Octroi

Total

Price

A Software (for both DC & DR site) X X X X X

1 Operational Risk Management

System

X X X X X

2 Credit Risk Management System X X X X X

3 Middleware (if any) X X X X X

4 Third Party Utilities (if any) X X X X X

5 Software/tools for SLA monitoring X X X X X

SUB TOTAL A X X X X X

B RDBMS & Environmental Software

(for both DC & DR)

1 Data Base Software License

2 Environmental Software

SUB TOTAL B X X X X X


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

323

Sr.

No.


Units (A)

Unit

Price (B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/

Service Tax)

Total Price

including

Taxes

and

Octroi

Total

Price

C Hardware (for both DC & DR Site)

1 Servers X X X X X

2 Operating System X X X X X

3 Storage (SAN) X X X X X

4 Rack with KVM switch, power

supply , Network and security

requirements, switches, routers etc.

X X X X X

5 Hardware required for SLA

monitoring

X X X X X

SUB TOTAL C X X X X X

D Implementation, System Integration, Training X X X X X


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

324

Sr.

No.


Units (A)

Unit

Price (B)

Sub‐

Total

Price

(A*B)

Total Price

including Taxes

(Sales

Tax/VAT/

Service Tax)

Total Price

including

Taxes

and

Octroi

Total

Price

Integration of new system with

existing systems

X X X X

SUB TOTAL (A+B+C+D) X X X X X

E AMC & ATS cost as per Part II X X X X X

F Facilities Management (both at DC & DR) X X X X X

Total Project Cost (A+B+C+D+E+F) X X X X X

Total Project Cost (in word)

Rs……………………………………………………

G Additional Training Cost (Person day rate) X X X X X


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

325

9.8 Bid Offer Covering Letter

Note: This Bid Offer Covering letter should be on the letterhead of the Bidder and should be signed by

authorized person

Date:

To,



1st Floor, Bajaj Bhavan,

Nariman Point, Mumbai – 400 021

Dear Sirs,

Subject: Response to RFP for implementation of Integrated Risk Management Solution: Specifically

Operational Risk and Credit Risk Management Systems under RBI/Basel II /Basel III Guidelines

1. With reference to the RFP, having examined and understood the instructions, terms and

conditions forming part of the RFP, we hereby enclose our offer for the implementation of

Operational and Credit Risk Management Solution for Advanced Approach under Basel II.

2. We acknowledge having received the following addenda to the bid document:

Addendum No. Dated

3. We agree and undertake that if our proposal is accepted, we shall provide the services comprised in

the contract within the timeframe specified, starting from the date of receipt of notification of

award from Central Bank of India.

4. We understand that the Bank is not bound to accept the offer and that the Bank has the right

to reject the offer without assigning any reasons whatsoever.

5. If the software, hardware, licenses sizing provided falls short of the projected growth rate for the

duration of the project as mentioned in the RFP, we will provide the additional required

software, hardware, licenses, etc. free of cost to the Bank and will also pay a penalty of 1% of the

total cost of the additional software, hardware, license, etc. to the Bank at every instance of

under sizing


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

326

6. We confirm that the offer is in conformity with the terms and conditions as mentioned in RFP

and it shall remain valid for 6 months from the last date of the acceptance of this bid.

7. The details of the Bid Cost / EMD are as follows:

Particulars DD No. / BG No Issuing Bank Amount

Bid Cost

EMD

Yours Faithfully,

(Name of Authorized Signatory)

(Designation)

(Name of Producers)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

327

9.9 Reference Site Details

The reference sites submitted must be necessarily of those banks where the proposed vendor/ OEM’s

product has been awarded the contract in the last two year prior to the Oct. 01, 2014. For those

references where the offered solution is accepted but implementation is not started, the acceptance

should be valid as on the last date for submission of bids at Central Bank of India. Reference site details

include only those where implementation of the proposed OEM solution has been done by the bidder

only. Capital computation as per standardized approach will be done in parallel i.e. in existing SAS system.

Please provide reference details in the format defined below:

Particulars Response

Name of the Bank/ Financial Institution

Country of Operation

Address of the Organization

Annual Turnover of the Organization for the Financial

Year 2013‐14

Date of commencement of Project

Date of completion of Project

Scope of Work for Solution

Number of concurrent users and the geographical spread of the

implementation

Average Team size for the entire project (Please mention the names

and roles of all the other third parties involved in case of

consortium)

Name of the contact person for reference


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

328

9.10 Particulars of Bidder

9.10.1 Profile of Bidder

Name of Bidder

Location

Registered Office

Controlling Office

Date of incorporation & date of

commencement of business

Major changes in Management in last

3 years (details to be provided)

Names of Banker/s

9.10.2 Financial Position of Bidder for last 3 financial years (in Rs. Crores)

2011‐12 2012‐13 2013‐14

Paid up capital

Tangible Net Worth (excluding

revaluation reserve)

Net Sales of the Company

Out of the above Net Sales, Net

Sales from Services

Gross Profit

Net Profit (Profit After Tax)

Note: Enclose

1. Copies of Audited Balance Sheets and P&L statements along with enclosures for last 3

financial years

2. copies of Articles of association and Memorandum of Association

3. copies of certificate of incorporation/certificate of commencement of business

4. copies of certificates of accreditation from ISO, SEI, CMM etc. as applicable

5. copies of teaming agreement (in case of consortium / sub-contracting)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

329

Place: Date:

Signature:

Name & Designation:

Business Address:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

330

9.11 Past Experience Details

9.11.1 Implementation in India

List of major customers where the offered ORMS and CRMS solution is implemented in the last 2 years

IN INDIA and their reference details

S

No.

Name and

complete Postal

Address of the

Customer

Brief Scope of

work (specify the size

of the bank, the

approaches supported

etc.)

Attach

reference

Letter

Project Status

(Completed/ Under

implementation)

1 2 3 4 5

9.11.1 Implementation Outside India

List of major customers where the offered ORMS and CRMS solution is implemented Outside India in the last 2 years and their references

S

No.

Name and

complete Postal

Address of the

Customer

Brief Scope of

work (specify the size

of the bank, the

approaches supported

etc.)

Attach

reference

Letter

Project Status

(Completed/ Under

implementation)

1 2 3 4 5

(Enclose necessary documentary proof)


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

331

9.12 Bank Guarantee for EMD & Performance Bank Guarantee Format

9.12.1 Bank Guarantee for EMD

BANK GUARANTEE

TO

_______________

_______________

_______________

Whereas ____________________ having its registered office at ________________________________

(hereinafter called “the Bidder”) has to submit its bid dated ___________ for the supply and installation of

Computer Hardware, Software and Peripherals as specified in Schedule of requirement against Tender

Reference NO.___________________________( hereinafter called “the Tender”)

KNOW ALL MEN by these presents that we _______________________ having our Corporate Office at

_______________ ( hereinafter called “the Bank”) are bound to Central Bank of India, ( hereinafter called

“The Purchaser”) in the sum of Rs._________ ( Rupees ____________________ only ) for which payment well

and truly to be made to the Purchaser, the Bank binds itself, its successors and assigns by these presents.

The conditions of this obligation are:

If the Bidder withdraws their Bid during the period of Bid validity specified in the Tender: OR

If the Bidder, having been notified of the acceptance of its Bid by the Purchaser during the period of Bid

validity -


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

332

Fails or refuse to execute the Contract or the Agreement/Forms as required OR

Fails or refuse to furnish the Performance Security, in accordance with the instruction to Bidder.

We, ____________________________________________________ under take to pay to the Purchaser up to

an amount of Rs.___________(Rupees ______________________ only) upon receipt of its first written

demand, without the Purchaser having to substantiate its demand, provided that in its demand the Purchaser

will note that the amount claimed by it is due to it owing to the occurrence of anyone or both of two

conditions specifying occurred condition or conditions.

Notwithstanding anything contained hereinabove;

Our liability under this Bank Guarantee shall not exceed Rs.__________ (Rupees _____________ only)

This Bank Guarantee shall be valid up to ___________

We are liable to pay the guaranteed amount or any part thereof under this Bank Guarantee only and only if

you serve upon us a written claim or demand on or before ___________. After which the bank shall be

discharged from its liabilities.

Date this -------------------- day of ------------------ 2014 at ----------

For and on behalf of -------------------------- Bank.

sd/- -----------------------------------------


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

333

9.12.2 Performance Bank Guarantee Format

PERFORMANCE BANK GUARANTEE

TO,

CENTRAL BANK OF INDIA

MUMBAI

-----------------.

In consideration of M/s Central Bank of India having Registered Office at Chandermukhi Building, Nariman

Point, Mumbai 400 021 (hereinafter referred to as “Purchaser”) having agreed to purchase computer

hardware (hereinafter referred to as “Goods”) from M/s ----------------------------- (hereinafter referred to as

“Contractor”) on the terms and conditions contained in their agreement/purchase order No------- dt.----------

-- (hereinafter referred to as the “Contract”) subject to the contractor furnishing a Bank Guarantee to the

purchaser as to the due performance of the computer hardware, as per the terms and conditions of the

said contract, to be supplied by the contractor and also guaranteeing the maintenance, by the contractor,

of the computer hardware and systems as per the terms and conditions of the said contract;

1) We, --------------------------- (Bank) (hereinafter called “the Bank”), in consideration of the premises and at

the request of the contractor, do hereby guarantee and undertake to pay to the purchaser, forthwith on

mere demand and without any demur, at any time upto --------------------- any money or moneys not

exceeding a total sum of Rs---------(Rupees-----------only) as may be claimed by the purchaser to be due from

the contractor by way of loss or damage caused to or would be caused to or suffered by the purchaser by

reason of failure of computer hardware to perform as per the said contract, and also failure of the

contractor to maintain the computer hardware and systems as per the terms and conditions of the said

contract.

2) Notwithstanding anything to the contrary, the decision of the purchaser as to whether computer

hardware has failed to perform as per the said contract, and also as to whether the contractor has failed to

maintain the computer hardware and systems as per the terms and conditions of the said contract will be

final and binding on the Bank and the Bank shall not be entitled to ask the purchaser to establish its claim

or claims under this Guarantee but shall pay the same to the purchaser forthwith on mere demand without

any demur, reservation, recourse, contest or protest and/or without any reference to the contractor. Any

such demand made by the purchaser on the Bank shall be conclusive and binding notwithstanding any


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

334

difference between the purchaser and the contractor or any dispute pending before any Court, Tribunal,

Arbitrator or any other authority.

3) This Guarantee shall expire on -----------------; without prejudice to the purchaser’s claim or claims

demanded from or otherwise notified to the Bank in writing on or before the said date i.e. --------- (this date

should be date of expiry of Guarantee).

4) The Bank further undertakes not to revoke this Guarantee during its currency except with the previous

consent of the purchaser in writing and this Guarantee shall continue to be enforceable till the aforesaid

date of expiry or the last date of the extended period of expiry of Guarantee agreed upon by all the parties

to this Guarantee, as the case may be, unless during the currency of this Guarantee all the dues of the

purchaser under or by virtue of the said contract have been duly paid and its claims satisfied or discharged

or the purchaser certifies that the terms and conditions of the said contract have been fully carried out by

the contractor and accordingly discharges the Guarantee.

5) In order to give full effect to the Guarantee herein contained you shall be entitled to act as if we are your

principal debtors in respect of all your claims against the contractor hereby Guaranteed by us as aforesaid

and we hereby expressly waive all our rights of suretyship and other rights if any which are in any way

inconsistent with the above or any other provisions of this Guarantee.

6) The Bank agrees with the purchaser that the purchaser shall have the fullest liberty without affecting in

any manner the Bank’s obligations under this Guarantee to extend the time of performance by the

contractor from time to time or to postpone for any time or from time to time any of the rights or powers

exercisable by the purchaser against the contractor and either to enforce or forbear to enforce any of the

terms and conditions of the said contract, and the Bank shall not be released from its liability for the

reasons of any such extensions being granted to the contractor for any forbearance, act or omission on the

part of the purchaser or any other indulgence shown by the purchaser or by any other matter or thing

whatsoever which under the law relating to sureties would, but for this provision have the effect of so

relieving the Bank.

7) The Guarantee shall not be affected by any change in the constitution of the contractor or the Bank nor

shall it be affected by any change in the constitution of the purchaser by any amalgamation or absorption

or with the contractor, Bank or the purchaser, but will ensure for and be available to and enforceable by

the absorbing or amalgamated company or concern.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

335

8) This guarantee and the powers and provisions herein contained are in addition to and not by way of

limitation or in substitution of any other guarantee or guarantees heretofore issued by us (whether singly

or jointly with other banks) on behalf of the contractor heretofore mentioned for the same contract

referred to heretofore and also for the same purpose for which this guarantee is issued, and now existing

un-cancelled and we further mention that this guarantee is not intended to and shall not revoke or limit

such guarantee or guarantees heretofore issued by us on behalf of the contractor heretofore mentioned for

the same contract referred to heretofore and for the same purpose for which this guarantee is issued.

9) Any notice by way of demand or otherwise under this guarantee may be sent by special courier, telex,

fax or registered post to our local address as mentioned in this guarantee.

10) Notwithstanding anything contained herein:-

i) Our liability under this Bank Guarantee shall not exceed Rs--------(Rupees---------

only);

ii) This Bank Guarantee shall be valid up to ----------------------; and

iii) We are liable to pay the Guaranteed amount or any part thereof under this Bank

Guarantee only and only if you serve upon us a written claim or demand on or

before -----------------(date of expiry of Guarantee).

11) The Bank has power to issue this Guarantee under the statute/constitution and the undersigned has

full power to sign this Guarantee on behalf of the Bank.

Date this -------------------- day of ------------------ 2014 at ----------

For and on behalf of -------------------------- Bank.

sd/- -----------------------------------------


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

336

9.13 Manufacturers’ / Producers’/ Authorization Form

Note: This letter of authority should be on the letterhead of all the original equipment

manufacturers and should be signed by a person competent and having the power of attorney to bind

the manufacturer.

(To be filled for hardware(s) / system software / any other suites, whatsoever applicable separately) No. ___________ dated______________ TO, The GM-IT Department Of Information Technology Central Bank of India CBD BELAPUR, NAVI MUMBAI-400614 Dear Sir / Madam, Tender Reference No:

Ref: Procurement of Integrated Risk Management Solution: Specifically Operational Risk and Credit Risk

Management Systems under RBI/Basel II /Basel III Guidelines

We ____________________________________________who are established and reputed manufacturer ___________________________ having organization at_________ and __________ do hereby authorize M/s _________________________________ (Name and address of Partner /Agent/Dealer) to offer their quotation, negotiate and conclude the contract with you against the above tender. We hereby extend our full guarantee and warranty as per terms and conditions of the tender and the contract for the Procurement of Integrated Risk Management Solution: Specifically Operational Risk & Credit Risk Management System Hardware / Software (any other suits, please mention, if applicable) supply, installation, commissioning, implementation, services and support offered against this tender by the above firm. Yours faithfully, (Name) for and on behalf of M/s____________________ (Name of manufacturer/Developer) Note: This letter of authority should be on the letterhead of the manufacturer(s) and should be signed by a competent person representing the manufacturer.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

337

9.14 Implementation Team Profile

9.14.1 Vendor Implementation Capability

Requirement Response

Current strength of employees in the vendor

organization with experience on the proposed

product(s)

Current strength of employees in the vendor

organization with experience in similar projects

Does the team possesses in‐depth knowledge of

the industry and is thereby capable of bringing

independent market knowledge to the bank?

Certifications possessed by the Bidder in

connection with the quality of internal

processes and services delivered/

methodology used in delivery

Approach to ensure adequate quality control

throughout the course of the project

Certified professional of OEM with experience of

the offered application product in the team

OEM personnel to be part of implementation team.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

338

9.14.2 Team Profile

Name

Proposed Role on this Project

Designation

Professional Qualifications

Certified Professional of the product (Yes / No), If yes, specify?

Experience with the bidding firm

Experience with other companies

Membership in any professional body

Details of projects handled with details of client,

representing which organization, as

member of the team or team leader etc.

Note:

• Include details of team members who will be involved in the project.

• Relevant experience refers to the experience of the employee on either exactly the same product /

set of products being proposed or on similar projects.

• Proposed team structure with count, profile, experience Level and skills to be provider by bidder

along with proposed solutions profile, #, skills) etc. to be provided in RFP response


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

339

9.15 Important Project Timelines

Project Milestone Time lines

Period within which Performance Security or amendment thereto is to be

submitted by the successful Bidder upon notification of award of contract

21 days (grace

period of 4 days)

Period within which the successful Bidder should sign the contract after

receipt of the Form of Contract.

7 days

Project Period 7 Years (1 Year of implementation, 3 Year Warranty, 3 Years AMC)

Timeline for delivery of hardware from the date of signing of contract 4‐5 weeks

Period for the entire solution to be ready for

commissioning after the award of contract.

12 Months

Trainings As planned by the bank as per scope of this RFP


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

340

9.16 List of Existing Applications

S.

No.

Area of Operation Application Name Vendor/ Supplier Database Platform

1 Core Banking solutions (CBS) B@NCS24 TCS Oracle Sun Solaris

2 ATM-Switch Electra EFT Electra Card Services Oracle Sun Solaris

3 Anti-Money Laundering

Solution (AML)

FINDNA TCS Oracle Sun Solaris

4 Risk Assessment Model RAM CRISIL Oracle Windows

5 Internet Banking (Internet / Mobile / SMS Banking)

e-Bankworks TCS Oracle Sun Solaris

6 Lending Automation

System (CLASS)

CLASS SysArc Pvt. Ltd. DB2 Windows

7 Mobile Payment (IMPS) IMPS / NPCI TCS Oracle 11G Sun Solaris

8 Asset Liability

Management (ALM) – SDR

SUNGARD IBM DB2 AIX

9 HRMS People Soft-HCM9.1 (People Tool 8.50)

IBM Oracle 11G R2 AIX 6.1

10 Direct Taxes B@NC24 TCS Oracle Sun Solaris


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

341

S.

No.


11 Excise Duty & Service Tax B@NC24 TCS Oracle Sun Solaris

12 VAT, CST, State & Govt.

Taxes

Internet Banking TCS Oracle Sun Solaris

13 Treasury BANCS Treasury TCS Oracle Sun Solaris

14 Market Risk SAS TCS Oracle Sun Solaris

15 Asset Classification,

Provisioning & Report

Generation of Loans &

Advances

B@NC24 TCS Oracle Sun Solaris

16 Credit Risk SAS TCS Oracle Sun Solaris

17 Cash Management

System

iCashPro Aurion Pro MS-SQL Windows

18 Data Archival Solution Data Archival for B@ncs Virmati Oracle Windows

19 MIS B@NC24 TCS Oracle Sun Solaris


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

342

S.

No.


20 Demat DP-Secure CMC Oracle Windows

21 Financial Transaction Management software

M-Queue IBM / TCS DB2 AIX

22 Payments NEFT IDRBT Oracle Windows

23 Payments RTGS RBI Oracle Windows

24 Payments PDO-NDS RBI Oracle Windows

25 Trade Finance Exim Bills CHINA SYSTEMS/TCS Oracle Sun Solaris

26 Credit Card Central Card IN SOLUTION GLOBAL Oracle Linux

27 Centralised Pension Payment System

CPPC INHOUSE MS-SQL Windows

28 Application Supported By Blocked Amount

ASBA TCS Oracle Windows

29 Rating Model for Retail Loans Credit Scoring Model INHOUSE MS-SQL Windows

30 Mail Messaging System IBM Lotus IBM /PCS Technologies IBM-Proprietary NSF system

Suse Linux & Windows

31 Electronic Data Interchange (EDI) ICES 1.0 CBEC Oracle Windows

32 International Funds Transfer SWIFT Cambridge Solution Oracle Windows & AIX

33 Biometric Authentication Biometric Smartchip MY-SQL RedHat Linux


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

343

9.17 List of Existing Applications from where Credit Risk Input data may be integrated

S.

No.


1 Core Banking solutions (CBS) B@NCS24 TCS Oracle Sun Solaris

2 Risk Assessment Model RAM CRISIL Oracle Windows

3 Lending Automation

System (CLASS)

CLASS SysArc Pvt. Ltd. DB2 Windows

4 Asset Liability

Management (ALM) – SDR

SUNGARD IBM DB2 AIX

5 Treasury BANCS Treasury version TCS Oracle Sun Solaris

6 Market Risk SAS TCS Oracle Sun Solaris

7 Asset Classification, Provisioning

& Report Generation of Loans

& Advances

B@NC24 TCS Oracle Sun Solaris

8 Credit Risk SAS TCS Oracle Sun Solaris 9 MIS B@NC24 TCS Oracle Sun Solaris

10 Trade Finance Exim Bills CHINA SYSTEMS/TCS Oracle Sun Solaris

11 Credit Card Central Card IN SOLUTION GLOBAL Oracle Linux

12 Rating Model for Retail Loans Credit Scoring Model INHOUSE MS-SQL Windows


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

344

9.18 CONFORMITY LETTER

CONFORMITY LETTER

Proforma of letter to be given by all the vendors participating in Implementation of Integrated Risk management Solution: Specifically Operational

Risk and Credit Risk management Systems for Advanced Approach under RBI/Basel II/Basel II RFP on their official letter-head

Date:

To

Deputy General Manager (IT),

Central Bank of India, Central Office,

Sector 11, CBD Belapur,

Navi Mumbai - 400614

Sir,

Sub: RFP for Implementation of Integrated Risk management Solution: Specifically Operational Risk and Credit Risk management Systems for

Advanced Approach under RBI/Basel II/Basel II

Further to our proposal dated XXXXXXX, in response to the RFP document (hereinafter referred to as “RFP DOCUMENT”) issued by Central Bank of

India (“Bank”) we hereby covenant, warrant and confirm as follows:

We hereby agree to comply / abide with all the terms and conditions / stipulations as contained in the RFP document and the related addendums

there on and other documents including the changes made by the Bank to the original tender documents.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

345

The Bank is not bound by any other extraneous matters or deviations, even if mentioned by us elsewhere either in our proposal or any subsequent deviations sought by us, whether orally or in writing, and the Bank’s decision not to accept any such extraneous conditions and deviations will be final and binding on us.

Yours faithfully,

Authorised Signatory

Designation

Vendor’s corporate name

Note: all the terms and conditions of the RFP and this addendum will not be diluted in the agreement / contract. SI has to submit the terms and conditions acceptance letter as per the enclosed format of RFP.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

346

9.19 Architecture


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

347

9.20 Hardware for SAS Solution at DC

Hardware For SAS Solution at DC

DC

Sr.

No.

Type Role Model / Type Serial No. Configuration Operating

System

Application /

Database

Server

1 Prod-Database Risk Mgmt.

Database

server

Sun Fire

V490

0904AM0127 2UltraSPARC-

IV+/8GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

Oracle 10g

2 Prod-Web &App Risk Mgmt.

Websphere

server

Sun Fire

V490


IV+/16GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

WebSphere

3 Prod-Compute Risk Mgmt

compute

Server

Sun Fire

V490


IV+/16GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

Oracle 10g

4 Prod-Metadata Risk Mgmt

Metadata

Sun Fire 0904AM0139 2UltraSPARC- Solaris 10 10/08 WebSphere


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

348

Server V490 IV+/8GB/146*2HDD s10s_u6wos_07b

5 Backup Risk Mgmt

Backup

Server

Sun Fire

T5120

BEL0851R8J 1UltraSPARC-

T2/8GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

EMC2 –

NETWORKER

6 UAT Risk Mgmt

Database

UAT server

Sun Fire

V490


IV+/8GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

Oracle 10g

7 UAT Risk Mgmt

Websphere

server

Sun Fire

V490


IV+/8GB/146*2HDD

Solaris 10 10/08

s10s_u6wos_07b

WebSphere

8 Prod SAN Storage StorageTek

2540

12 * 300 GB SAS HDD

with dual controller

9 Prod SAN Switch Brocade

SW200E

4Gbps*8 Ports

Activated

10 Prod Network

Switch

Cisco

Catalyst

24 Port *2


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

349

11 Prod Server Rack President 42U*2

12 Backup Tape Library SL24 1*LTO3 ultrium tape

drive with 24 slots

13 Backup Backup

Software

Netvault 1*Workgroup

license for Solaris.

1* Single

Heterogenous client

license

*** Operating System - Solaris 10 10/08 s10s_u6wos_07b


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

350

9.21 Non-disclosure Agreement

NON-DISCLOSURE AGREEMENT

This Agreement made at _______________, on this _____ day of __________________ 2014.

BETWEEN

________________________________ a company incorporated under the Companies Act, 1956 having its registered office at

___________________________ (hereinafter referred to as “-----” which expression unless repugnant to the context or meaning thereof be deemed

to include its successors and assigns) of the ONE PART;

AND

CENTRAL BANK OF INDIA, a body corporate constituted under the Banking Companies (Acquisition & Transfer of Undertakings) Act, 1970 and having

its head Office at Central Office, Chander Mukhi, Nariman Point, Mumbai – 400 021 (hereinafter referred to as “CBI” which expression unless

repugnant to the context or meaning thereof be deemed to include its successors and assigns) of the OTHER PART

and CBI are hereinafter individually referred to as party and collectively referred to as “the Parties”. Either of the parties which discloses or receives

the confidential information is respectively referred to herein as Disclosing Party and Receiving Party.

WHEREAS:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

351

The Parties intend to engage in discussions and negotiations concerning the establishment of a business relationship between them. In the course of

such discussions and negotiations, it is anticipated that both the parties may disclose or deliver to either of the Parties certain or some of its trade

secrets or confidential or proprietary information, for the purpose of enabling the other party to evaluate the feasibility of such business relationship

(hereinafter referred to as “the Purpose”).

NOW, THEREFORE, THIS AGREEMENT WITNESSETH AND IT IS HEREBY AGREED BY AND BETWEEN THE PARTIES HERETO AS FOLLOWS:

1. Confidential Information: “Confidential Information” means all information disclosed/ furnished by either of the parties to another Party in

connection with the business transacted/to be transacted between the Parties and/or in the course of discussions and negotiations between

them in connection with the Purpose. Confidential Information shall include customer data, any copy, abstract, extract, sample, note or module

thereof.

Either of the Parties may use the Confidential Information solely for and in connection with the Purpose.

Notwithstanding the foregoing, “Confidential Information” shall not include any information which the Receiving Party can show: (a) is now or

subsequently becomes legally and publicly available without breach of this Agreement by the Receiving Party, (b) was rightfully in the possession

of the Receiving Party without any obligation of confidentiality prior to receiving it

from the Disclosing Party, (c) was rightfully obtained by the Receiving Party from a source other than the Disclosing Party without any obligation

of confidentiality, or (d) was developed by or for the Receiving Party independently and without reference to any Confidential Information and

such independent development can be shown by documentary evidence.

1. Non-disclosure: The Receiving Party shall not commercially use or disclose any Confidential Information or any materials derived there from to any other person or entity other than persons in the direct employment of the Receiving Party who have a need to have access to and knowledge of the Confidential Information solely for the Purpose authorized above. The Receiving Party may disclose Confidential Information to consultants only if the consultant has executed a Non-disclosure Agreement with the Receiving Party that contains terms and conditions that are no less restrictive than these. The Receiving Party shall take appropriate measures by instruction and written agreement prior to disclosure to such employees to assure against unauthorized use or disclosure. The Receiving Party agrees to notify the Disclosing Party immediately if it learns of any use or disclosure of the Disclosing Party’s Confidential Information in violation of the terms of this Agreement. Further, any breach


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

352

of non-disclosure obligations by such employees or consultants shall be deemed to be a breach of this Agreement by the Receiving Party and the Receiving Party shall be accordingly liable therefore.

Provided that the Receiving Party may disclose Confidential information to a court or governmental agency pursuant to an order of such court or

governmental agency as so required by such order, provided that the Receiving Party shall, unless prohibited by law or regulation, promptly

notify the Disclosing Party of such order and afford the Disclosing Party the opportunity to seek appropriate protective order relating to such

disclosure.

3. Publications: Neither Party shall make news releases, public announcements, give interviews, issue or publish advertisements or publicize in any

other manner whatsoever in connection with this Agreement, the contents / provisions thereof, other information relating to this Agreement, the

Purpose, the Confidential Information or other matter of this Agreement, without the prior written approval of the other Party.

4. Term: This Agreement shall be effective from the date hereof and shall continue till establishment of business relationship between the Parties and execution of definitive agreements thereafter. Upon expiration or termination as contemplated herein the Receiving Party shall immediately cease any and all disclosures or uses of Confidential Information; and at the request of the Disclosing Party, the Receiving Party shall promptly return or destroy all written, graphic or other tangible forms of the Confidential Information and all copies, abstracts, extracts, samples, notes or modules thereof.

Notwithstanding anything to the contrary contained herein the confidential information shall continue to remain confidential until it reaches the

public domain in the normal course.

5. Title and Proprietary Rights: Notwithstanding the disclosure of any Confidential Information by the Disclosing Party to the Receiving Party, the

Disclosing Party shall retain title and all intellectual property and proprietary rights in the Confidential Information. No license under any

trademark, patent or copyright, or application for same which are now or thereafter may be obtained by such Party is either granted or implied

by the conveying of Confidential Information. The Receiving Party shall not conceal, alter, obliterate, mutilate, deface or otherwise interfere with

any trademark, trademark notice, copyright notice, confidentiality notice or any notice of any other proprietary right of the Disclosing Party on

any copy of the Confidential Information, and shall reproduce any such mark or notice on all copies of such Confidential Information. Likewise,

the Receiving Party shall not add or emboss its own or any other any mark, symbol or logo on such Confidential Information.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

353

6. Return of Confidential Information: Upon written demand of the Disclosing Party, the Receiving Party shall (i) cease using the Confidential

Information, (ii) return the Confidential Information and all copies, abstract, extracts, samples, notes or modules thereof to the Disclosing Party

within seven (7) days after receipt of notice, and (iii) upon request of the Disclosing Party, certify in writing that the Receiving Party has complied

with the obligations set forth in this paragraph.

7. Remedies: The Receiving Party acknowledges that if the Receiving Party fails to comply with any of its obligations hereunder, the Disclosing Party

may suffer immediate, irreparable harm for which monetary damages may not be adequate. The Receiving Party agrees that, in addition to all

other remedies provided at law or in equity, the Disclosing Party shall be entitled to injunctive relief hereunder.

8. Entire Agreement, Amendment, Assignment: This Agreement constitutes the entire agreement between the parties relating to the matters

discussed herein and supersedes any and all prior oral discussions and/or written correspondence or agreements between the parties. This

Agreement may be amended or modified only with the mutual written consent of the parties. Neither this Agreement nor any right granted

hereunder shall be assignable or otherwise transferable.

9. Governing Law and Jurisdiction: The provisions of this Agreement shall be governed by the laws of India. The disputes, if any, arising out of this Agreement shall be submitted to the jurisdiction of the courts/tribunals in Mumbai.

10. General: The Receiving Party shall not reverse-engineer, decompile, disassemble or otherwise interfere with any software disclosed hereunder.

All Confidential Information is provided “as is”. In no event shall the Disclosing Party be liable for the inaccuracy or incompleteness of the

Confidential Information. None of the Confidential Information disclosed by the parties constitutes any representation, warranty, assurance,

guarantee or inducement by either party to the other with respect to the fitness of such Confidential Information for any particular purpose or

infringement of trademarks, patents, copyrights or any right of third persons.

11. Indemnity: The receiving party should indemnify and keep indemnified, saved, defended, harmless against any loss, damage, costs etc. incurred

and / or suffered by the disclosing party arising out of breach of confidentiality obligations under this agreement by the receiving party etc.,

officers, employees, agents or consultants.

IN WITNESS WHEREOF, the Parties hereto have executed these presents the day, month and year first hereinabove written.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

354

For and on behalf of

__________________

Name of Authorized signatory:

Designation:

For and on behalf of

CENTRAL BANK OF INDIA

_____________________

Name of Authorized signatory:

Designation:


-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

355

End of Document