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/BaselII/BaselIII 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
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
5.
Basel II RBI Guidelines
A global regulatory framework for more resilient banks and

banking systems and International framework for liquidity risk
measurement, standard and monitoring
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
7.
CO
Commercial Offer/ Commercial Bid/ Price Bid
8.
CRMS
Credit Risk Management System
9.
FGMO
Field General Managers Office
10.
Bancs24
Core Banking Application software used in bank
11.
IMA
Internal Model Approach
12.
IPR
Intellectual Property Right
13.
IT
Information Technology
Implementation of Basel III Capital Regulations in India

Guidelines on Liquidity Risk Management and Basel III
Framework on Liquidity Standards
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
25.
NDA
Service level Agreement

Non-disclosure Agreement
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
2.
Disclaimer ....................................................................................................................................... 19
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
PreBid 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
2.3
Documents constituting the Bid ..................................................................................................... 25

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.
3.1
Additional Instructions for Bidders ......................................................................................................... 30

General Instructions ........................................................................................................................... 30
4
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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

5
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Vendors 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
6
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
7.3.3
7.3.4
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

7
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.4.8
9.4.9
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

8
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 prebid meeting
15/10/2014 3.00 PM
Date
and
time
clarifications on website
17/10/2014 4.00 PM
for putting
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
Address for communication
The General Manager,

Central Bank of India,
Risk Management Department,
1st Floor, Bajaj Bhavan,
Nariman Point, Mumbai 400 021
As above
Tel:
Email :
Application Money
+91-22-66387635
agmrisk@centralbank.co.in
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 Bankers Cheque in favor of Central
Bank of India payable at Mumbai.
10
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Bid security
Contact to Bidders
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.
Interested Bidders are requested to send the email to
agmrisk@centralbank.co.in and copy to
purcppco@centralbank.co.in
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 Banks website.
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 Banks website www.centralbankofindia.co.in
11
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 modernday 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 valueadded 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 Managers
Offices, 80 Regional Offices and two foreign Representative Offices
12
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 enterprisewide
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 banks 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 SelfAssessment
exercise spanning all the risk areas and evolved a road map to move towards implementation of
Basel II guidelines as per RBIs 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
13
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 TechnoCommercial
bids from eligible Bidders to provide endtoend solution for implementation of Operational Risk
Management system in consonance with advanced approaches as per the BaselII 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 Banks 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 submodule wise), including source / method of data
capture and transfer, validation, updation and database maintenance for networked and nonnetworked
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
14
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 signoff 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 Banks 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 startdate.
15
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 activepassive 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 Endof Sale has been declared,
is offered as part of this RFP. None of the hardware or software should have an EndofSupport
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,
16
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks
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
17
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 l o n g w i t h d e t a i l s l i k e n o . o f y e a r s
e x p e r i e n c 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 banks 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 banks 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
18
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 regulators 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/BASELII/ BASELIII 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 Banks 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 committees approval
The Bidders will, by responding to the Banks 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
19
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
20
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 nonrefundable, 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 Banks 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 Bidders conduct, which would
warrant the securitys 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 , 0 0 , 0 0 0 / - issued by a Schedule comm ercial 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) Bankers 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 nonresponsive.
5. Unsuccessful Bidders Bid security will be discharged or returned as promptly as possible.
6. The successful Bidders 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:
21
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 prebid 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 Bidders 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.
22
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.1.5 PreBid Meeting

The Bank plans to hold a prebid 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 PreBid meeting. Also, bank will allow a maximum
of 2 representatives from each Bidder (including consortium partners) to participate in the prebid
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 PreBid meeting with
interested Bidders.
Nonattendance at the Prebid 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 prebid 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 nonresponsive. 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 bidsubmission, 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
23
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Contents / covenants by amendment. Clarification / amendment, if any, will be notified on Banks 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 interlineation, 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 Bidders 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.
24
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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) superscribing Soft Copy of Technical
Bid against RFP CENTRAL BANK OF INDIA/RMD/201415/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 / noncompliance
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 / noncompliance 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
25
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Bidders 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.
26
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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. Bidders proposal should strictly conform to the specifications.
2. Proposals not conforming to the specifications will be rejected subject to the Banks discretion. Any
incomplete or ambiguous terms / conditions / quotes may result in disqualification of the offer at banks
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 shortlist.
27
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
2.3.2 List of Documents

Envelope
Documents
ENVELOPE
I:
Eligibility Criteria
ENVELOPE II: Technical

Bid
Cost
of
Document
Reference
Section 9.2: Eligibility Criteria
Application/
Bid
Bid Security (Earnest Money

Deposit)
Section 2.1.1: Cost

of
Application/ Bid Document
Section 2.1.2: Bid Security
(E.M.D)
Technical Bid
Undertaking
Bidder
from
Bid
Offer
Letter
Covering
Cover
Letter
Technical Offer
for
Section 9.1: Undertaking from Bidder
Section 9.8: Bid

Letter
Offer Covering
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
Details
Section 9.11: Past Experience

Details
Experience
Manufacturers/
Producers/
28
Section 9.13: Manufacturers/

Producers/
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Envelope
ENVELOPE
III:
Commercial Bid
Documents
Reference
Authorization Form
Authorization Form
Implementation Team
Profile
Section 9.14: Implementation Team

Profile
Project Timelines
Section 9.15: Important

Project Timelines
Masked
Bid
Section 9.7.2: Commercial

Bid (Bill of Material) Format
Commercial
Commercial Bid
Cover
Letter
Commercial Bid
for
Commercial Bid (Bill of

Material) Format
Section 9.6: Cover Letter for

Commercial Bid
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)
superscribing Soft
Copy of
Technical
Bid
against RFP CENTRAL BANK OF INDIA/RMD/201415/
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 Ri s k 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 GuidelinesFINAL 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 Manag ement System for Advanced Approach under RBI/Basel II /Basel
29
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
III Eligibility Criteria

ii. Implementation of Integrated Risk Management Solution: Specifically Operational and
III NonPrice Bid (Technical Bid),
iii. Implementation of Integrated Risk Management Solution: Specifically Operational and
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
bids 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 Bidders cost
for entire project period.
b) The application software should mitigate Application Security Risks, at a minimum,
discussed in OWASP top 10 (Open Web Application Security Project)
those
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
30
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks decision will be final.
Types of sensitive information that will be found on Bank systems 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 Banks 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 Banks 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,
31
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks representatives access to the Bidders 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 64bit Quadcore 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 banks
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
32
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 multihost connectivity. The system should facilitate
connectivity to various flavours of Operating Systems (OS), including but not limited to, HPUX, IBM
AIX, SUN Solaris, Linux, Microsoft Windows, etc.
17. The switch should have support of all leading SAN / NAS disk arrays and tape libraries 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.
33
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 hasto explain through proper calculations how the performance of the system visvis
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 , quarterend and yearend 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
TPCC certified by Transaction Processing Council and / or Oracle TPMC that is made available in
34
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 TPCC, Oracle TPMC, etc. and relate the same to
the server configurations proposed for Banks 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 benchmarks. The Bidder has to
relate the same to the model and configuration of the hardware proposed for Banks
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
Banks 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 Banks
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 Bidders 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 Bidders performance obligations under the contract.
35
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Base
Service Level
penalty will be calculated

Value of the said business infrastructure for
DC or DRC, as the case may be.
Availability
of
Business
98.5%
Infrastructure
(Core
Application
Servers, Core Database Servers,
Storage, SAN Switch, Tape Library,
Oracle
RDBMS
and
related
components etc.) in DC and DRC
36
Amount
on
which
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Availability Measurements
Expected
Base
Service Level
Availability
of
all other
95%
infrastructure, all other software
components and Test
and
Development infrastructure
Amount
on
which

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
System
End to End response time 98.5%
The bidder is to upgrade the Hardware
Response
Time
within
DC or DR
along with related software and services
(from the CRMS & ORMS
without any additional cost to the Bank,
Application
if service level not met Till Service level is
the
Database
should
Business
resume
which
to
the
and
back)
met, penalty will be charged on the value
<0.5ms
of the business infrastructure at DC or
be
(milliseconds)
Disaster
Recovery Site
Availability
Base
Amount
on
DRC, as the case may be.
operations to 100%
from
Disaster
Penalty will be charged on the value of

the business infrastructure at DC or DRC,
Recovery Site within 4
as the case may be.
hours of the Data Centre

failing and
Data Point
Availability
vice versa.
Recovery Point Objective
100%
(RPO) of] 30 minutes.
Penalty will be charged on the value of

the business infrastructure at DC or DRC,
as the case may be.
37
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Delivery
and
installation
of
hardware & other
infrastructure
components (after
due inspection and
acceptance at DC &
DRC)
Hardware
& Operating
Systems
30%
Environmental
Software other
than RDBMS
Operational and
Credit Risk
Management
System
Implementation
Cost
38
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Project
Milestones
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
Successful
completion
of
Current
State
Assessment,
Gap
Analysis (including
data gap analysis)
and
Systems
Requirement
Specifications (SRS)
Sign-off
Hardware
& Operating
Systems
Environmental
Software other
than RDBMS
Operational and
Credit Risk
Management
System
Implementation
Cost
30%
5%
5%
5%
5%
39
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Project
Milestones
Successful
Completion
of
Customization,
Configuration,
Parameterization,
Documentation and
Sign-off
(including of Banks
Models)
Successful
Completion
of
Interface Building /
ETL, Documentation
and Sign-off
Successful
Completion of Data
Extraction,
Validation,
Data
Migration,
Reconciliation,
Documentation and
Sign-off
Successful
Completion of endto-end
UAT,
Documentation and
Sign-off
Environmental
Software other
than RDBMS
Operational and
Credit Risk
Management
System
Implementation
Cost
5%
5%
10%
10%
10%
10%
10%
10%
10%
10%
10%
10%
10%
10%
20%
20%
Hardware
& Operating
Systems
40
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Project
Milestones
Hardware
& Operating
Systems
Environmental
Software other
than RDBMS
Operational and
Credit Risk
Management
System
Implementation
Cost
5%
5%
Successful
Completion
of
Sample Roll-out and
Trainings,
Documentation and
Sign-off
Successful
Completion
of
Migration
to
Production,
Documentation and
Sign-off
20%
20%
20%
20%
10%
10%
10%
10%
100%
100%
100%
100%
9 months
from
the date
of
successful
implementation (i.e.
on Sign-off of Project
Implementation and
Production
Migration)
After Completion of
Warranty
Total
10%
10%
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 o n 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,
41
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
3.
4.
5.
6.
7.
8.
9.
Parameterization, Documentation and Sign-off (including of Banks Models)

10% of the contract amount on successful Completion of Interface Building / ETL, Documentation and
Sign-off
10% of the contract amount on successful Completion of Data Extraction, Validation, Data Migration,
Reconciliation, Documentation and Sign-off
20% of the contract amount on successful Completion of end-to-end UAT, Documentation and Signoff
5% of the contract amount on successful Completion of Sample Roll-out and Trainings,
Documentation and Sign-off
10% of the contract amount on successful Completion of Migration to Production, Documentation
and Sign-off
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)
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 Banks 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
1. 30%
Environmental Software except RDBMS

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
42
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Banks 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,
43
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
44
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
for the entire turnkey solution provided. This will be subject to a ceiling of not more than 120
minutes s i n g l e i n s t a n c e 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 Bidders maintenance engineers to report to the installations after a request call / fax
/email 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 upto 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
45
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
collusive
practice among
Bidders (prior
to
or after bid submission)
designed to establish bid prices at artificial noncompetitive 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.

46
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Vendors 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,
47
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Vendors 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.
48
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
49
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 endtoend 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
4.1.1.
Opening of Bids by the Bank

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 shortlisted 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
50
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
process and extend their cooperation 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 shortlisted 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 Banks bid evaluation, bid comparison or contract
award decision may result in the rejection of the Bidders bid. Banks 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
Banks 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
51
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 nonresponsive Bidders shall be returned unopened.
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 TechnoCommercial Evaluation
process.
Bidders are advised to refer to Section 4: Evaluation Methodology for details and methodology of
Evaluation Criteria
4.2
Sr.
No.
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
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.
52
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
3

the bank
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. 201112, 201213 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
The Bidder (SI) and OEMs should not have been Self-declaration of SI and all the OEMs
blacklisted at the time of submission by the
Central/any of the State Governments/ statutory
body/ regulatory body/Indian Banks Association in
India
The Bidder should own the intellectual property Letter/ Certificate from OEM
rights of the product / solution or he should have
rights from the owner, If not, the Bidder should
have in place proper tieups, 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.
Product Capabilities
6
Proposed credit risk solution should have been Credential letter on banks letter head
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)
Proposed operational risk solution should have Credential letter on banks letter head
been procured by at least 1 scheduled commercial
bank in India or a bank abroad for implementation
of Advanced (AMA) approaches (only BIA/TSA
53
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.

the bank
The proposed Credit risk solution and Operational Credential letter on banks letter head
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.
The proposed Credit risk and Operational risk Gartner report and Chartis report
solution should be positioned in the leaders
quadrant of Chartis research report/Gartners
magic quadrant.
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
Credential letter on banks letter head
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 bidders 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 bidders 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 endtoend 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.
54
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
55
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Bidders 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 cooperative banks (State Cooperative banks, District Central cooperative banks,
Urban Cooperative 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 Bidders 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.
56
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
v.
d) Training: the Bidder will be responsible for training the Banks 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.
ii.
The quality of the Bidders 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.
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 Banks 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.
57
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
4.3.4 Functional & Technical Evaluation Criteria

4.3.4.1 For Operational Risk solution
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
Max. Total
Score
Bidders responses in RFP

response against each line
Compliance of the item of the functional
product with the requirements
As per banks
functional
evaluation
requirements stated
in the RFP
Live demonstration of the
product to the Bank.
250

product with the
requirements
technical
requirements stated
in the RFP
product to Bank.
150
Credential: Offered Client credential letter stating

solution
is the status of implementation
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
58
A. 1 Bank 50
marks
B. 2 Banks 100
marks
C. More than 2
banks 150
marks
150
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
Max. Total
Score
should present a UAT

completion
certification for AMA
approaches.
Bidders Experience
Number of Scheduled
Commercial Banks in
India
or
abroad
where the bidder is
implementing
/
implemented
an
operational
risk
solution for AMA
approaches.
4
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
(If the solution is

under
implementation only
50% marks would be
counted. For 100%
marks, the vendor
completion
certification for AMA
approaches.)
150
Implementation Capabilities
Implementation
Approach
5
The bidder would be

required to present
following for each of
the implementation
requirements
1. Responses
to
implementation
requirements section on
the RFP response
As
per
2. Vendor presentation (The evaluation
presentation should be
made by the proposed
engagement team, as
mentioned in the RFP
59
banks
175
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
specified in the RFP
Max. Total
Score
response)
a. Approach
for
implementation
in the proposed
solution
b. Assumptions
made
c. Estimated efforts
for
implementation
of
each
requirement
d. Bidders
experience
of
solving
implementation
challenges
(especially
in
Indian
PSU
environments)
e. Proposed project
plan
and
approach taken
to
address
implementation
challenges
Project
team Evaluation of CV provided in
experience
the RFP response
a. Experience
of Project teams presentation &
operational risk responses to Banks queries in
As
per
AMA
system presentation
evaluation
implementation
b. Awareness
of
public
sector
bank
Risk
infrastructure
c. Number of years
of
relevant
experience
Response of reference bank As
Reference site visit
per
60
banks
75
banks
50
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
Max. Total
Score
evaluation
Total Marks
1000
4.3.4.2 For Credit Risk Management Solution

S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
Max. Total
Score

product with the
requirements
As per banks
functional
evaluation
requirements stated
in the RFP
product to the Bank.
250

Compliance of the
item of the functional
product with the requirements
technical
requirements stated
in the RFP
product to Bank.
150
Credential: Offered Client credential letter stating

solution
is the status of implementation
Implemented
or
under
implementation
in
Scheduled Banks in
India or abroad
61
D. 1 Bank 50
marks
E. 2 Banks 100
marks
F. More than 2
banks 150
marks
150
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
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.
Bidders Experience
Number of Scheduled
Commercial Banks in
India
or
abroad
where the bidder is
implementing
/
implemented a credit
risk solution for IRB
approaches.
4
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
(If the solution is

under
implementation only
50% marks would be
counted. For 100%
marks, the vendor
completion
certification for IRB
approaches.)
150
Implementation Capabilities
3. Responses
to
As
per
implementation
requirements section on evaluation
The bidder would be
the RFP response
Implementation
Approach
62
banks
175
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Sub-scores
Basis of Evaluation
Max. Total
Score
required to present 4. Vendor presentation (The

following for each of
presentation should be
the implementation
made by the proposed
requirements
engagement team, as
mentioned in the RFP
specified in the RFP
response)
f. Approach
for
implementation
in the proposed
solution
g. Assumptions
made
h. Estimated efforts
for
implementation
of
each
requirement
i. Bidders
experience
of
solving
implementation
challenges
(especially
in
Indian
PSU
environments)
j. Proposed project
plan
and
approach taken
to
address
implementation
challenges
Project
team Evaluation of CV provided in
experience
the RFP response
d. Experience
of Project teams presentation & As
per
Credit risk IRB responses to Banks queries in evaluation
system
presentation
implementation
e. Awareness
of
public
sector
bank
Risk
infrastructure
63
banks
75
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Evaluation Criteria
Basis of Evaluation
f.
Sub-scores
Max. Total
Score
Number of years
of
relevant
experience
Reference site visit
Response of reference bank
Total Marks
As
per
evaluation
banks
50
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)
b)
c)
d)
Functional Requirements (FR)

Technical Requirements (TR)
Approach and Methodology (AM)
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 shortlisted for commercial evaluation.
The minimum functional and technical specifications are given in Annexure 9.4. All the requirements are
64
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
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) Bidders 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 i d evaluation will be shortlisted for commercial evaluation.
65
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
66
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
70,000
71.43
L2
50,000
100
L1
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
67
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 attorneys 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.
Banks 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
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
subcontractors
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
68
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 nonconformance resulting from Banks 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.
69
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
70
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks premises.
Should any loss or damage occur, the selected Bidder shall:
i.
ii.
5.4
initiate and pursue claim till settlement and

Promptly make arrangements for repair and / or replacement of any damaged item irrespective of
settlement of claim by the underwriters.
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 onsite 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.
71
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Vendors 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
72
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
responsibility for the Banks 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 subcontractors 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 banks 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.
73
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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:
74
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Partys 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 Banks 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.
75
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Vendors 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.
76
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Vendors 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
77
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
78
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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/Vendors 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 Banks representatives access to the Vendors 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 Vendors
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.
79
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
80
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
81
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
ii.
iii.
iv.
v.
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.
Development of AMA models and validation
Generation of reports as per regulatory guidelines and MIS
Provide required data / information as provided in the scope of this RFP
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 banks 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 banks 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 banks 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 banks 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 banks framework has to be implemented
by whatever nomenclature it is called.
82
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
vi.
vii.
viii.
ix.
x.
xi.
xii.
xiii.
xiv.
xv.
xvi.
xvii.
xviii.
xix.
xx.
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.
Implementation of Key Risk Indicators framework a s to its identification, definition, assignment,
calculation, threshold / triggers, monitoring, reporting and Indexing.
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.
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.
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.
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.
Implementation of Scenario analysis framework and its use in the capital quantification process.
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.
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
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
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.
To provide and support the validation techniques including identifying and justifying the
assumptions as well as evaluate the AMA models sensitivity to these assumptions.
Analysis of results of operational risk management and measurement processes.
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.
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.
83
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Administration of the module in terms of access to the system as per job profile of the employee
with function specific controls.
Ability of the system to be interfaced with banks source system, staging area and data warehouse
in an automated manner.
Flexibility to upload the data into the system such as loss event, KRI, risk and controls using Bank
provided templates etc.
Configuration of templates into the system as per operational risk management framework of the
bank
Flexibility in defining and use of the scales for assessment and consolidation as per Banks
operational risk management framework e.g. for RCSA, KRI, Scenario Analysis
System should be capable of doing Stress testing (including reverse stress testing) and back testing
Compliance with banks system security standards
xxi.
xxii.
xxiii.
xxiv.
xxv.
xxvi.
xxvii.
6.1
Scope for Implementation of Operational Risk Management Solution
Following will be the selected Vendors 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 Banks Data Centre in Mumbai.
Deliverables
a. Sign-off by the Banks IT Department for successful installation of all the IT components
B. Current State Assessment and Data Gap Analysis
Understanding of banks operational risk management and applicable regulatory requirements is must as
selected bidder will have to implement banks 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
banks 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
methodology for conducting RCSA, implementation of KRI and collection of loss data
applicable RBI guidelines by RBI and BCBS for moving to AMA

84
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
banks plan for moving to advanced approaches AMA with existing framework and data
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.
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
banks 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 Banks 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 banks OR framework as per AMA requirements of RBI / Basel II / Basel III
guidelines which would include:
Assist in enhancements of ORM framework basis the banks 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
RCSA Framework
KRI Framework
Loss Data Management framework
Scenario Assessment Framework
Business Line Mapping
Operational Risk Monitoring & Reporting framework
Alignment of Risk Based Internal Audit framework and Operational Risk Management framework
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
85
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks ORM updated framework and highlight gaps
with recommendations for enhancements etc.
Assisting bank in RCSA planning and conducting workshop as per banks methodology and through
banks 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 banks 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
86
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks ORM system, if any i.e. banks AMA model will be
configured on the ORM systems so that bank can use system for capital computation
Capital computation using banks data on the configured system using AMA Models developed on Banks
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 banks 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
87
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
suggestion so provided is at banks 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, banks 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 banks 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 banks 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
88
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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.
89
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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. Banks 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
90
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks data to the ORM system
Vendor will prepare banks 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 banks 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.
91
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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
92
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Bidders responsibility to establish connectivity of the test PCs 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 (dayend, 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 banks 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 banks 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 banks 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
93
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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
94
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
K. Training / Workshop and Knowledge Transfer

The Bidder will be responsible for training the Banks 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 Banks 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
95
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
96
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Bidders Implementation
Approach
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
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.
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,
consolidation of results etc.

97
scales,
rating,
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
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 Banks systems
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
Capital Computation
98
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
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
Risk and Control Data Library, KRI Data Library, External Loss
Data Library, Operational Risk Scenarios, and UAT Test Cases for
7.1
the Offered ORM System under this RFP

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 banks RCSA framework except
validations of the risk event.
Specify number of Risk and Controls
Relevance to Indian Banking
Relevance to Banks portfolio and operations and support
functions
Mapping to process, product, system, compliance
standard / guidelines, outsourcing, risk type, business line,
99
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
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 Banks
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 Banks all portfolios and Support
Functions, Vendor will have to develop additional risks
Vendor should also specify the approximate number of risks and
7.2
controls in the proposed library as per above criteria

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 Banks 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
Banks all portfolios and Support Functions, Vendor will have to
develop additional KRIs.
Vendor should also specify the approximate number of KRIs in
7.3
the proposed library as per above criteria.

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

100
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Approach
Relevant to Banks 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
Banks all portfolios and regulatory requirements, Vendor will
have to develop additional Scenarios.
Vendor should also specify the approximate number of scenarios
7.4
in the proposed library.

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 Banks 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
7.5
loss data in the proposed library

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 Banks portfolio, operations and support
functions
101
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
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 banks review feedback.
Vendor should also specify the approximate number of test cases
8
8.1
in the proposed library with expected results.

Reports
Vendor will have to provide at least 50 reports in the system (preconfigured / 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.
102
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
General Requirements
Group
Weight (on
a Scale of
250)
30
1.1
Configurations of the banks 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)
1.2
Manual upload facility of the historical data, interface with external system such as
CORDEX, interface with banks 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.
103
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
1
1.3
Configuration of banks operational risk management framework in terms of

methodology, work-flow, templates, consolidation, models, tools, analysis, monitoring
and reporting.
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.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.
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.7
Flexibility for system enhancement due to change in regulatory requirements, banks

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.)
1.8
1.9
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)
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.
104
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.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.
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 workflow attached to the user rights matrix as specified by the bank.
1.13
System should give relevant error message such as on data upload, on execution of
wrong command etc. including generation of log
1.14
System should provide search facility of various records using fields or combination
thereof which are used to define that particular record.
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.

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.
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.
1.18
System should support the breakdown 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.19
The system should have scalability to take care of any changes brought in by BASEL
guidelines/Regulator
105
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 banks 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.
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.
There should be upload / download facility such as upload of RCSA assessment, plan,
schedule download of respective templates, etc.
RCSA methodology such as risk based, Questionnaire based and hybrid, all should be
supported.
2.2
2.3
(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
106
Group
Weight (on
a Scale of
250)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
based Methodology and bank can use both at one point of time for different risk
entities.
2.4
(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)
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.
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.
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
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
107
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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
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.
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.
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.
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 / nonsignificant risk, preventive / detective control, control frequency, risk identification by
(auditor / risk entity / ORMD / external events / others) etc.
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
108
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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
2.16
System should facilitate risk assessment should be done on probability and impact
scale
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.18
Residual risk should be rated as a result of probability and impact assessment by the
system i.e. product of probability and impact
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.
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.21
A heat-map should be generated for RCSA results with drill-down capabilities. Heatmap 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.
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.
2.23
Summarizes the assessment results by process, product, risk entity, region, zone, bank,
group, location, risk type etc.
2.17
109
Group
Weight (on
a Scale of
250)
1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.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
2.26
Action Plan Report with status e.g. action plan which has breached the timelines and
escalation work flow
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.
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.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.
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
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.
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
2.33
There should be a document upload facility to substantiate the RCSA.
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.
110
Group
Weight (on
a Scale of
250)
2
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
2.35
Vendor should conduct a sample run of the entire RCSA exercise as per the scope and
process mentioned by the Bank.
Key Risk Indicators (KRIs)
25
3.1
Implementation of banks 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.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.
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.
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.
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.
111
Group
Weight (on
a Scale of
250)
1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
2
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.
3.7
System should facilitate different thresholds for a single KRI assigned to different risk
entities.
3.8
Trigger should be mapped with various level of automated notification and escalation
at various hierarchies e.g. through e- mails, SMS etc.
3.9
Compute KRI value on the defined frequency based on the data uploaded / extracted
as per job scheduling.
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
3.11
System should facilitate creation of action plan for those KRIs which have breached the
threshold or on reaching a critical trigger level
3.12
link with the respective risk event etc.
3.13
Compare computed value of KRI with the thresholds set and then provide alerts to the
respective notification / escalation level
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.
3.15
KRI Report should be of all types heat map, dash board, tabular, graphical etc.
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.
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.
112
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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.
3.20
Vendor should conduct a sample run of the KRI Scope as per the Bank specified
process.
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.
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, banks internal
113
Group
Weight (on
a Scale of
250)
1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
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
4.4
System should be able to customize, bank's loss data management framework,

template, work-flow, approval, reports etc.
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
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.
4.7
It should be able to do scaling, judgment overrides or other adjustments to the internal

loss estimates
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.
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.
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.
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
4.10
4.11
114
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
Allocation of losses to business lines and loss event type categories along with the
methods used to allocate the losses
4.13
Group
Weight (on
a Scale of
250)
1
4.14
It should enable classification of risk events as boundary events to specify it as credit

risk related or market risk related
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
Status of recovery can also be included such as recovery process initiated but yet to be
received
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.
4.18
It should be able to identify the risk events which are covered in the existing
operational risk insurance policies
4.19
It should facilitate creation of action plan with a particular reference / linking to the
risk event
4.20
External loss data from all sources e.g. public data / pooled industry data / vendor
data, all should be supported by the system
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
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.
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
4.16
115
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
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
4.25
It should facilitate validation of loss data through review and approval e.g. makerchecker and there can be more than one level of review and approval
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.
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.
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.
Action Plan
4.27
4.28
5
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.
116
10
2
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.
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
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.
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.
5.6
It should be able to customize bank specific reporting requirements at no extra cost to

the bank
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.
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.
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).
5.4
117
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.4
AMA model should creation of ORCs basis statistical analysis / approach.
Group
Weight (on
a Scale of
250)
2
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.
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.
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.
6.7
Systems should facilitate scenario analysis of expert opinion
6.8
The system should support defining, capturing and assessment of the scenarios.
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.
118
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
1
6.10
Use of assumptions in scenario analysis based on empirical evidence
6.11
Periodic Review and validation of scenarios should be supported by the system as and
when required by the Bank.
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.
6.13
Translation of BEICF factors into quantitative measures for measurement, validation

and verification
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.
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.
6.16
System should determine and justify statistically how the AMA elements are weighted
and combined.
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
6.18
Estimation techniques to fit the operational risk models to historically available

operational loss data
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.
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
119
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.21
The system should have statistical capabilities for estimation of information criteria
such as AIC (Akaike information criterion ) , BIC(Bayesian information criterion ) etc.
6.22
The system should allow to conduct parametric and non - parametric bootstrapping
process
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.
6.24
Provide for Single Severity Distribution and Piece-wise Distribution.
6.25
System should be able to use more than one approach to estimate severity of the
body, tail and entire distribution
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.
6.27
The system should support extreme value theory (EVT)
6.28
The system should display the parameters that are used for fitting the distributions. It
should rank and report all the test statistics
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.
6.30
Determination of appropriate body-tail modeling threshold for modeling the body and
tail of the loss distribution separately
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.
6.32
Apply robust statistical techniques to test the reasonableness of the assumptions

about the underlying distributions.
120
Group
Weight (on
a Scale of
250)
2
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
6.34
Provide for modeling correlations/dependence using various methods but not limited
to Independence , Clayton , Gumbel , Frank Guassian T copulas
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
6.36
Model documentation should identify and justify assumptions as well as evaluate the
AMA models sensitivity to these assumptions related to correlations/dependence
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.
6.38
Estimation of diversification benefits factored in at the Solo level , group-wide level

and at the banking subsidiary level
6.39
System should consider in AMA Modelling recoveries and insurance settlement as risk
mitigant.
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.
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.
6.42
Mapping of insurance policies to Basel II event types for risk mitigation
121
Group
Weight (on
a Scale of
250)
1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
6.44
Provide for the validation of the AMA measurement model through back testing and
statistical testing. Stress testing including reverse stress testing.
6.45
Vendor should assist in getting the models validated/approved by the regulators

(especially in case of the underlying logic being proprietary).
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)
6.47
It should allow for the allocation of capital to business lines.
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
122
Group
Weight (on
a Scale of
250)
2
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
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.
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

7.4
7.5
7.6
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
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.
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.
Reports should cover qualitative i.e. results of operational risk management processes
and quantitative i.e. capital calculation processes and combination of them
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.
7.9
It should provide facility to access, view, download and print the reports as per user
access rights
7.10
Report should be downloadable in excel, word, pdf etc. file formats
7.7
123
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
7.11
Operational Risk Management and Measurement Reports should be generated at

multiple dimensions such as ORM capital as per each business line etc.
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
The system should be capable of generating performance measurement reports
measured visavis RCSA results, KRI status and action taken by units/business lines.
7.14
System should provide linkages between RCSA, KRI, loss data and audit processes as
required by the Bank and generate report accordingly
7.15
The system should report the operational risk charge before and after any reduction in
capital resulting from the use of insurance.
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
System should provide capital charge drill down at each ORC level, which would
provide a split of LDA VAR and Scenario VAR
7.18
The system should display capital before BEICF adjustments and capital after BEICF
adjustments and highlight the impact of BEICF
7.19
The system should display capital before diversification

diversification effect and highlight the diversification impact
and capital after
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
7.21
The vendor should be able to provide post implementation support, configuration

training and end user training.
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.
7.23
Following is the inclusive list of reports / requirements which system should have:
7.13
7.17
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.
124
Group
Weight (on
a Scale of
250)
1
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 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
125
Group
Weight (on
a Scale of
250)
250
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6.3
Technical Requirements for Operational Risk Management Solution
Sr.
No.
Technology Requirements
Max.
Marks
User Interface
25
1.01
The system should provide a consistent and easy to use graphical user interface
1.02
The system should be capable of interfacing with mail clients (Lotus

Note server) to generate notifications and automailers.
1.03
The system should provide the facility to upload/download data to/from peripheral
systems to be provided as and when required.
1.04
Report Creation utility should be provided for the user to generate new reports
1.05
The system should provide userfriendly design, shortcuts, smart tags and other
productivity features
1.06
The system
should
support
configurable
historical, current and forecast figures and analysis
1.07
The system should provide tools for validation of data inputs that are captured from
the existing applications of the bank
1.08
The system should provide for validation of data inputs that are subject to reentry
or manual intervention
1.09
System should provide users with the option to print, i.e. print to files of various
formats, print to printer etc.
1.1
The functionalities should be menu driven. The menu structure of the system should
be standard
1.11
The system should provide online help facility which is context sensitive at field,
screen etc.
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:
Microsoft Excel Format (.XLS)
Comma separated values (.CSV)
Text file (.TXT)
Microsoft Word (.DOC)
Adobe Reader (.PDF)
ASCII (Flat File)
Web Page(.HTML)
126
graphical
display
of
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
Extended Markup Language(.XML)
1.13
The system should provide intelligible edit error messaging to assist correction and re
entry of data
1.14
The system should generate intelligent error messages based on predefined

parameters
System Architecture
10
2.01
The solution should be in web based technology in a three tier architecture
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.03
The system architecture should be modular; separate modules of the system should
run independently
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
development,
licensing, implementation and customization costs to the bank during the
implementation and AMC period.
Upgradation to Basel III should be possible with the proposed solution
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.
3.02
The system should allow have a dayend backup process
3.03
The system should also have recovery features in case of system failures
3.04
Backup should be possible in external media (CD, tapes, DVD) for offsite storage
3.05
System should support archiving of data that are beyond a specified time horizon with
facility to parameterize.
3.06
Export of data to secondary storage device should be supported by the system

without downtime. Secondary storage is for backup purposes.
(Retention policy should be as per regulatory guidelines. Backup window should be

during off-peak hours.)
127
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
3.07
System should support data retrieval from the specified archives. The archival and
retrieval programs should facilitate easier analysis of old data.
3.08
The system should generate error logs if the calculation fails during time of data
processing
3.09
The error logs should be descriptive enough to allow traceability of the data/function
error to the most granular level
3.10
The solution should have suitable Business Continuity Plan and structure to achieve
solution availability.
Security management
30
4.01
The system should provide for user profiles to be controlled by a specific

administrator
4.02
System
access
should
be permitted
verification with all user IDs being unique
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.
4.04
The system should have the ability to provide or restrict access privileges based
upon hierarchy and multiple criteria
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.
4.06
Standard password management features should be configurable as per Bank's policies

e.g.
Max.
Marks
only
through
password
Automatic user disabling after three successive erroneous tries

Automatic user timeout 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
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.
128
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
4.09
There should be a makerchecker facility for key functions in the system
4.10
System should allow data access to users only through screens
4.11
The system should maintain the audit trail with details like user id, datetime etc.
4.12
The audit trail should be at the granular level, and track the user across each activity
4.13
The system should have the ability to store and track all system events, including
corrections and cancellations by multiple criteria
Reporting & Others
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 systems specifications and parameters
5.02
5.03
2
2
2
2
3
20
Exception reports should be sent to predefined users either through auto

mailers via the email client or via popups within the system
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.
5.04
The system should allow reports to be exported into Microsoft Excel, Adobe PDF
format and other databases
5.05
The system should allow users to print reports directly from the system
5.06
The system should allow users to save reports to a disc in a non editable as well as an
editable format
5.07
The system should generate reports in various types of files like:

View Mode
2
2
1
1
1
Excel Mode
Text Mode
HTML Table
CSV format
Word File
129
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
PDF format
XBRL format
5.08
The system should allow for generation of predefined endofday, endof week and
endof month reports and adhoc reports a s a n d when required
5.09
Reports generated in periodical wise or as defined by the Bank:

Daily
2
3
Weekly
Fortnightly
Monthly
Quarterly
Halfyearly
Annual
5.10
The system should allow for archiving of external reports in the following
formats:
Adobe PDF
Microsoft Excel
Microsoft Word
Microsoft Access
5.11
Archiving of reports should be possible in a predefined format to facilitate ease of

retrieval
5.12
Reports generated by the system should be in XBRL format whereas system should
have capability to generate internal reports in PDF format.
General
15
6.01
The system should process, track and account for the necessary range of traded and
nontraded currencies which includes USD, INR, EUR, AUD, JPY, GBP, CAD etc.
6.02
The system should handle all types of day count basis including 30/360, Actual/360,
Actual/365, Actual/Actual, 30E/360
6.03
The system should load calendar schedules from external sources including but not
limited to Ba nk Ho l i day , SWIFT, International Holiday schedule and Bloomberg
holiday schedule etc.
130
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
6.04
The system should handle multiple entities that includes branches, subsidiaries etc.
6.05
The Bidder should provide a Data Mart to generate analytical reports to be used /
viewed by the Bank.
6.06
The proposed Data Mart should be able to integrate with the Enterprisewide
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.
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 dayend data)
8
Documentation
10
8.01
Please list the availability of various documentations provided with your product(s)
such as
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, EntityRelationship 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.
Total
3
150
6.3.1 Additional Questions

Refer to subsection 9.5 in Annexure Section for required additional details on the proposed solution
131
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
Module/ Item
No
.
1. Hardware
2.
Operating
System
licenses(Windows or
any other)
3.
Oracle licenses
4.
Third
utilities
party
5.
Any
requirement
other
Module Description
Requirement
Quantity
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
132
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
above modules
Detailed Technical sheets of the above modules to be submitted
Bidder to also provide detailed specifications for replication methodology for DR site
System should be capable enough not to allow Multiple Logins in the system.
Application user: pan India
Workload will peak over a particular period of time
OpVar 5 Concurrent Session should be supported
4.
5.
6.
7.
8.
9.
6.3.3 Training Requirements

Please provide descriptive answers to the following questions.
Sr.
No
.
1
Requirements
Response
How many Implementation trainings (ORMS)

have been undertaken by the Bidder so far?
Please provide a brief description on the

Training approach taken by the Bidder.
Please provide the following details for

training :
3.1
Number of mandays
completion of training
3.2
Optimum batch size
3.3
Total efforts for conducting the training
duration for
3.4 Location
133
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
Requirements
No
.
3.5 Frequency of training offered
Response
3.6 Prerequisites / Preparations required before

training
4
Please answer the following about the

trainers incharge 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

with the Project, working / training on the
solution proposed by the Bidder
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]
134
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No
.
Requirements
Response
Note: Please attach the feedback in a separate

document with proper crossreferencing.
Please specify the various modes through
which the training will be delivered? [e.g.
Classroom training, Online selfhelp training
modules within
application / e
learning modules, Quiz, etc.]
6.3.4 Project Management Methodology

Sr.
No
.
1
Requirements
Response
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)
135
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No
.
1.4
Requirements
Response
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,

Migration and Reconciliation
1.8
User acceptance testing
Validation,
1.9 Sample Roll-out, Training / Workshop and

Knowledge Transfer
Planning
for
rollout and
identification of key issues that may arise along
with proposed solutions
1.10 Production Migration

2
Timelines
Project management activities
Roles
and
responsibilities
of
proposed personnel both from the vendor
and bank end
Following details with respect to the

methodology followed by the vendor in
Project Management for a Public Sector Bank
Project Name
136
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No
.
Requirements
Response
Project Location
Client Name
Client address
Client contact/reference person(s)
Project started (month/year)
Project elapsed time months
Manmonths 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 endto
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 activitywise and module
wise may be detailed.)
137
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 PillarI, II and III requirements as per BaselII / RBI guidelines
and BaselIII 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 banks 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.
138
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The scope of Credit Risk Management System should include but not limited to:
i.
ii.
iii.
iv.
v.
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.
Risk estimation model developments and their validations
Generation of reports as per regulatory guidelines and MIS
Provide required data / information as provided in the scope of this RFP
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 banks 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 banks 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 banks 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 Banks 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
139
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
x.
xi.
xii.
xiii.
xiv.
xv.
xvi.
xvii.
xviii.
xix.
xx.
7.1
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.
Configuration and parameterization of system for banks 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.
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.
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.
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.
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.
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 banks business and risk profile
covering all the IRB requirements as per RBI / Basel II / Basel III guidelines.
Administration of the module in terms of access to the system as per job profile of the employee
with function specific controls.
Ability of the system to be interfaced with banks source system, staging area and data
warehouse in an automated manner.
Flexibility to upload the data into the system using Bank provided templates etc.
System should be capable of doing Stress testing (including reverse stress testing) and back testing
Compliance with banks system security standards
Scope for Implementation of Credit Risk Management Solution
Following will be the Vendors 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 Banks Data Centre in Mumbai.
Deliverables
140
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
b. Sign-off by the Banks IT Department for successful installation of all the IT components
B. Current State Assessment and Gap Analysis
Understanding of banks credit risk management framework and applicable regulatory requirements (RBI /
Basel II) is must as selected bidder will have to implement banks 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
banks 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.
workflow, reports, approval, staffing, business lines / departments, organization structure,

product, processes, consolidation
IT architecture, existing systems, data, data architecture, interfaces, data-warehouse, data

issues, interface issues etc.
Applicable RBI / BCBS guidelines for moving to Std. and IRB and banks plan for moving to
advanced approaches Std. and IRB with existing framework and data
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.
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
banks 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 Banks 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
141
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 recalibration 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 banks 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 banks 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
142
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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, banks 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
143
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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:
144
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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. Banks 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
145
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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.
146
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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.
147
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Bidders responsibility to establish connectivity of the test PCs 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 (dayend, 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 banks 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 banks data as well as hypothetical data, which will be decided by the
bank
148
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 banks 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 banks 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
Banks risk estimation models (PD, LGD, EAD and M for retail and non-retail portfolios) creation /
configuration on the system and demo using banks 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
149
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks 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 Banks 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
150
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
151
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
1
1.1
Data management
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.
152
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 preimplementation 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 offbalance sheet facilities.
153
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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.
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.
Capital management, ICAAP, Stress Testing: For the purpose of

154
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 preimplementation 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.
155
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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
156
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 Banks 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 banks 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
157
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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 Banks 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 banks 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
158
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
multiple jurisdictions
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 banks business and risk
profile
-Relevance to Banks 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 banks 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
159
Approach
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
Approach
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.
1
1.1
Credit Risk Functional Requirements

Maximum Marks
20
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 predefined excel sheets and
other data formats (viz. .txt, .XBRL, .CSV, .XML) apart from 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.
1.3
The proposed software solution should be capable of interfacing with

existing and future credit rating systems / score cards / Models, Internal
160
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
(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.
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 bankwide level.
The system should be able to support an interface with Treasury systems

from where the VaR numbers can be fetched
1.6
1.7
Interface with external third party system will be of batch processing.

System should have ability to track and store accountwise previous credit
ratings (external and internal) / scores and LGD.
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.
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.
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
161
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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
2.1
Risk Modelling Capabilities
105
Scorecard/ Rating model development capabilities
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
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
Probability of default modelling: The system should enable development

and configuration of
20
2.2.1
Calibration curve fitting approach
2.2.2
Low default portfolio calibration approach for large corporate
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.
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 banks data and banks portfolio and as per Basel II and RBI
guidelines.
2.2.5
The solution should be capable of computing Throughthecycle PD and
162
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
Pointintime 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
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 workout 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/, collateralwise 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 banks data and as per banks portfolio as per Basel II and RBI
guidelines.
2.3.2
The system should be able to fetch default and recovery information from
various source systems and data cleansing
2.3.3
Choose a discount rate for discounting of recovery cash-flows and recovery

costs
2.3.4
Compute the workout period for each portfolio
2.3.5
Compute discounted LGD
2.3.6
Develop LGD prediction models using

3. Clustering
163
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
2.3.7
Support GUI interface for end to end LGD modeling
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.3.9
The solution should provide for effective LGD where the Bank is having
other financial/AIRB collaterals and pool of collaterals
2.3.10
The system should be able to compute Downturn default weighted LGD as

per RBI/ Basel guidelines.
Exposure at Default (EAD)
10
The solution should provide for EAD / CCF and Effective Maturity (M)
calculation for both on and off balance sheet items.
2.4
2.4.1
Vendor will develop at least 7 EAD models for banks 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.4.2
The system should have capabilities to capture outstanding and limit

information for all revolving and off-balance sheet exposures
2.4.3
The system should have capabilities to compute realized CCF (Credit

Conversion Factor) for defaulted exposures
2.4.4
Capability to develop CCF prediction models using

3. Clustering
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)
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
164
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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.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.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.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
banks retail portfolio as per Basel II and RBI guidelines.
165
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
2.5.7
The system should generate reports to monitor/track pool stability and

accuracy.
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
Basic modeling techniques: The system should support the following
basic modeling steps
2.6.1
Sampling techniques (Simple, stratified, random etc.)
2.6.2
Missing value imputation
2.6.3
Outlier detection and elimination
2.6.4
Variable transformation (Transformations like natural log, exponential,

inverse, sin, root etc. should be available)
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.
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)
2.7.2
Calibration Test - Hosmer Lemeshow Test, Kolmogorov-Smirnov (KS) Test,

Concentration Analysis in rating grades and individual factor scores.
2.7.3
Stability Test - Population Stability Index (PSI) Test
2.6
166
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
2.7.4
Additionally, the system should provide other factor level tests such as
Good vs. Bad analysis, Log-odds trend analysis
2.7.5
The software should provide the results of above tests in pre-defined

report formats (tabular and graphical formats)
2.7.6
Back testing techniques for PD, LGD & EAD models
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.8
Maturity(M)
2.8.1
The system should be able to calculate Effective Maturity for corporate

exposures
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
Modelling Other Requirements
2.9.1
The solution should provide necessary treatment for repo style

transactions/ guarantees/ credit derivatives under both foundation as well
as advanced approaches
2.9.2
The solution should provide exposure adjustment by segmenting it into

portions covered by different collateral and guarantee types and portion
2.9
167
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
remaining unsecured as per BaselII/ 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.
2.9.4
The solution should support development of multiple PD, LGD & EAD
models and should enable for validation.
2.9.5
The solution should be able to generate PD, EAD, LGD for sub portfolio
like industry, sector, Geography etc.
Capital Computation Rules
50
Capital Computation General
10
At present Bank is following Standardized Approach.
3
3.1
3.1.1
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
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
3.1.3
The system should be able to perform firmsize adjustment for small

and medium size entities
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 / nondefaulted exposures
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
168
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
able to take the equations as per regulatory formulas and perform capital
calculations
3.1.6
The system should be able

portfolio losses incorporating:
to
compute
expected/unexpected
Default risk/transition probabilities

Recovery rates
Correlation and diversification effects between counter parties

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
3.1.8
The system should be able to calculate capital requirement individual

accountwise and also unitswise such as:
Entire Bank
Region/zone
Geography
Industry
Business segments
Products
Rating wise
Branch
Relationship Manager
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
169
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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 BaselII 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.
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
170
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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:
Counterparty 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
3.3
3.3.1
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.
Credit risk mitigation
15
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.
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 banks risk
mitigation tools / mechanisms into Basel defined risk mitigation inputs
171
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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 BaselII
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 BaselII accord/ RBI
guidelines on IRB approach.
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.
3.3.5
System should support collateral optimization as well as pre-defined ranks

provided by the bank both.
3.3.6
The system should have the ability to assign the risk weights for Guarantors
as per RBI Guidelines.
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.
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.
3.3.9
The system should be able to perform on balance sheet netting and capital
calculation based on the net credit exposure.
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
172
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
on the quality of collaterals and nondaily mark to market or remargining

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.
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 overcollateralization or under
collateralization)
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
System should be able to do collateral optimization as well as bank defined
mapping / ranking of collaterals against an exposure
RWA computations
15
The system should come with pre-build rules for computation of RWA for:
3.4.1
Corporate Non SME
3.4.2
Corporate SME
3.4.3
Bank
3.4.4
Sovereign
3.3.14
3.4
173
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
3.4.5
Retail
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.
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
The system should be able to calculate capital for Traditional and
Synthetic Securitization exposures.
The system should be able to capture the banks role (e.g. Originator,
investor etc.)
for the securitization exposures, various credit
enhancements and should calculate the capital as per Basel II Guidelines
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.
Purchased receivables for corporate and retail. The computation
capabilities should cover default risk and dilution risk.
3.4.8
3.4.9
3.4.10
3.4.11
1
1
For Default risk, the system should be able to apply Topdown

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
4
4.1
Stress testing
15
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:
174
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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
banks review and confirmation for stress testing above
4.3
Creation of sensitivity tests
4.4
Creation of multi factor scenarios based on historical scenarios,

hypothetical forward looking scenarios based on macroeconomic data
points
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.)
4.6
Capability to compute the correlation structure between various risk silos

using:
1. Variance covariance approach
2. Copula approaches
4.7
Capability to assess second order impact of risk silos (E.g., Impact of

reputational risk on Credit risk)
4.8
Support reverse stress testing
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.
Capital efficiency monitoring, Capital planning and management, risk
10
175
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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
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.)
5.3
Calculation of Risk Adjusted Return on Capital (RAROC) based on

regulatory capital as well as economic capital.
5.4
The system should support capital allocation based on RAROC.
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.
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.
5.7
System should have the capability to compute CVA (Credit Value

Adjustment) under RBI /BaselIII Guidelines.
Reporting capabilities
35
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:
Regulatory reports (pertaining to Basel II, Basel III)
6
6.1
6.1.1
Pillar III Disclosures: The system should have prebuilt pillar 3 reports as
per Basel / RBI guidelines on BaselII and BaselIII.
176
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
6.1.2
Origination metrics
6.1.3
Capital efficiency monitoring
6.1.4
Basel II & III parameter reports
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
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.
6.2.2
The system should have the prebuilt & 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:
Counterparty
Portfolio
Product
Geography country/ state/zone/branch
Industry
Concentrations
Risk Profiles
Rating wise
Delinquency buckets
PD Bands
177
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
LGD Bands etc.


6.2.3
The solution should be able to generate Risk Profile Template as per RBI
guidelines and other regional/branchwise risk profile templates for credit
risk as per Banks internal requirements
6.2.4
The system should be capable of generating various Bank defined reports

like:
Borrower Information report

Industry Analysis report
Monitoring (Accountwise report to cover rating transition & trend in
critical identified parameters)
Peer group Analysis report
Rating wise reports
Portfolio reports
Borrowerwise risk score report
Borrowerwise risk grade report
Borrowerwise year wise risk score report
Borrowerwise 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/ onbalance sheet / offbalance sheet
exposure wise for a date range etc.)
RAROC reports vertical wise, geography wise, rating grade wise etc.
Capital Chargecredit risk (Regulatory and economic) expected
and unexpected losses
Exposure
Reports
(Portfolio
exposure
by
Sector/ industry/credit
rating/ Client/
Loan Size/
Maturity/ country/currency/Onbalance
sheet/ offbalance sheet
exposure/interest rate wise/floating rate wise internal and
external benchmark /fixed rate wise etc. after including/ excluding
178
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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 industrywise, ratinggrade wise, curingwise,
tenor wise, sacrifice wise, productwise, vertical wise, regionwise,
branchwise, asset classwise.
6.2.5
The reports should be able to cut- across asset classes and give
combined reports, if needed, while analyzing industrywise, product
wise, sectorwise
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 li g 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
6.2.7
Expiry reports on
collateral (Due to
bank/zone/branch/account wise
6.2.8
Residual Contractual Maturity Breakdown of the whole portfolio

broken down by major type of Credit Exposures
6.2.9
Exposure weighted average LGD/EAD for each borrower category
6.2.10
Securitization disclosure (total outstanding exposure securitized by bank

broken-down by type of securitization (traditional/Synthetic), exposure
type.
6.2.11
Amount of NPA securitized broken down by exposure type
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).
expire/expired)
179
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
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
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
6.2.15
Report on Interest rate wise break up of advances segment wise as per

user defined range of rate of interest
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
6.2.17
Report on pre- payment of total/instalment of term loans, project

finance, bills purchased/discounted or negotiated, demand loans
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 visvis prudential exposure limits fixed by
bank/regulator
6.2.19
Export formats for MIS report
.TXT
.XLSX
.PDF
.DOCX
180
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
6.2.20
Overrides performance reports performance of accounts where there

is rating override or downgrades (Branch wise / region wise
/geography wise/level wise/approving user wise rating cases processed,
approved, rejected and pending for user defined period.
6.2.21
The system should support portfoliobased 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.
.PPTX
.XML
.XBRL
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
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.

6.2.23
The system should be able to generate risk maps, risk charts, trend analysis
etc. for PillarI and PillarII 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
6.2.24
System should have the capability to generate back dated reports

181
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
Audit log report

7
7.1
ICAAP
10
The system should have a PillarII module which supports ICAAP analysis
of all material PillarII 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 ratinggrade wise, interest rate
wise, groupwise, borrowerwise 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 PillarII.
Data required for the preparation of ICAAP document has to be generated

through the system.
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 PillarII risks.
Additionally, the system should also support aggregation of PillarII capital
into Bankwide 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 Pillar2.
7.4
The system should have capital planning and budgeting modules for
e s t i m a t i n g bankwide capital for future, stress testing by changing
assumptions/ macroeconomic scenarios, allocation across business
units, geographies, products etc., if needed.
7.5
The system should be able to generate risk maps, risk charts, reports,
trend analysis etc. for PillarII risks, various risk dashboards for the users
and top management.
Basel III Requirements
The system should have the capability for computation of nonrisk based
8
8.1
182
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr. No.
Maximum Marks
leverage ratio as per RBI/ BaselIII guidelines.

The system should have the flexibility to enable reporting and estimation
of each capital components like common equity, Additional Tier1, Tier2
etc. as per prescribed guidelines of RBI under BaselIII.
The Pillar1, Pillar2 and Pillar3 modules should be compliant with RBIs
BaselIII requirements also.
8.2
System should facilitate capital computation and computation of

leverage ratio as per Basel II & III guidelines
Total Marks
183
250
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7.3
Technical Requirements for Credit Risk Management Solution
Sr.
No.
User Interface
Max.
Marks
25
1.01
1.02

1.03
1.04
1.05
1.06
The system
should
support
configurable
1.07
1.08
1.09
1.1
be standard
1.11
screen etc.
1.12

Text file (.TXT)
184
graphical
display
of
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
Adobe Reader (.PDF)

ASCII (Flat File)
Web Page(.HTML)
1.13
entry of data

parameters
System Architecture
10
2.01
2.02
2.03
run independently
1.14
2
2.04

requirements affecting domestic or international operations in respect of the Credit
Risk Management System, including Advanced Approaches under Basel II without
any additional d e v e l o p m e n t , licensing, implementation and customization costs
to the bank during the implementation and AMC period.

25
3.01
prevent long term speed concerns. Bank needs a separate data archival solution and
query on archived data is required.
3.02
3.03
3.04
3.05
3.06

without downtime.
185
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
3.07
3.08
processing
3.09
3.1
Security management
30
4.01

administrator
4.02
System
access
should
be permitted
4.03
followed.
4.04
4.05
4.06

e.g.
only
through
password

4.07
4.08
4.09
186
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
4.10
4.11
4.12
4.13
Reporting & Others
20
5
5.01
5.02

5.03
5.04
2
2
2
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
5.06
The system should allow users to save reports to a disc in a noneditable as well as an
editable format
5.07

View Mode
Excel Mode
Text Mode
HTML Table
CSV format
Word File
PDF format
XBRL format
187
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
5.08
5.09
5.10

Daily
Weekly
Fortnightly
Monthly
Quarterly
Halfyearly
Annual
The system should allow for archiving of external reports in the following formats:
Adobe PDF
Microsoft Excel
Microsoft Word
Microsoft Access
Max.
Marks
5.11

retrieval
5.12
General
6.01
6.02
The system should handle all types of day count basis including
30/360, Actual/360, Actual/365, Actual/Actual, 30E/360
4
3
6.03
limited to Ba nk Ho li d ay , SWIFT, International Holiday schedule and Bloomberg
holiday schedule. etc.
6.04
6.05
viewed by the Bank.
20
188
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
6.06
Integration
15
7.01
limited to:
15
Batch processing
Online processing
8
8.01
Real time processing (calculation to be done with time lag of 1 day on the basis of dayend
data)
Documentation
such as
10
7
available
users.
d) Documents narrating the mathematics, the assumption in all the Models/Pricing
engines used in the software
8.02

Total
189
150
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
7.3.1 Additional Questions

Refer to subsection 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.
Module/ Item
1.
Hardware
2.
Operating
System
licenses(Windows or
any other)
3.
Database licenses
4.
Third
utilities
party
5.
Any
requirement
other
Module Description
Requirement
Quantity
Note:
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
190
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
7.3.3 Training Requirements

Please provide descriptive answers to the following questions.
Sr.
No.
Requirements
Response
How many Implementation trainings (CRM)

have been undertaken by the Bidder so far?
Please provide a brief description on the

Training approach taken by the Bidder.
Please provide the following details for

training :
3.1
Number of mandays
completion of training
3.2
Optimum batch size
3.3
3.4
Location
3.5
Frequency of training offered
3.6
Prerequisites
duration for
Preparations
191
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
required before training

4
Please answer the following about the

trainers incharge 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

with the Project as trainers
4.3

with the Project, working / training on the
solution proposed by the Bidder
Please provide a s a m p l e training response

and feedback from
previous
implementations?
Also, please
following:
give
details
of
the
5.1
Name of the Bank where product was

5.2
5.3
Training audience
5.4
Indicative rating [if any provided]

Note: Please attach the feedback in a separate
document with proper crossreferencing.
192
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6
Requirements
Response
Please specify the various modes through

which the training will be delivered? [e.g.
Classroom training, Online selfhelp training
modules within
application / e
learning modules, Quiz, etc.]
7.3.4 Project Management Methodology

Sr.
No.
1
Requirements
Response

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
necessary work around
and
193
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
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,

Migration and Reconciliation
1.8
Validation,
Sample Roll-out, Training / Workshop and

Knowledge Transfer Planning for
rollout
and identification of key issues that may arise
along with proposed solutions
1.10 Production Migration
1.9
Timelines
Roles
and
responsibilities
of
proposed personnel both from the vendor
and bank end
Following details with respect to the

methodology followed by the vendor in
Project Management for a Public Sector Bank
Project Name
194
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
Project Location
Client Name
Client address

Manmonths effort
Project
modules
details)
Size
(No
covered and
of branches,
any other relevant

Role
of the Bidder,
whether
complete endtoend 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 activitywise and module
wise may be detailed.)
195
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
196
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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,
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)
197
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
The bidder should be a profit making entity for

last three financial years i.e. 2011-12,201213,2013-14

sheets and P&L statements in case of
others for past 3 financial years.
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. 201112, 201213 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
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
The Bidder should own the intellectual property Letter/ Certificate from OEM
rights of the product / solution or he should have
rights from the owner, If not, the Bidder should
have in place proper tieups, commercial
agreements,
authorized
implementation
198
Self-declaration of SI and all the OEMs
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Proposed operational risk solution should have Credential letter on banks letter head
been procured by at least 1 scheduled commercial
bank in India or a bank abroad for implementation
of Advanced (AMA) approaches (only BIA/TSA
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.
The proposed Credit risk and Operational risk

solution should be positioned in the leaders
quadrant of Chartis research report/Gartners
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
199
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.3
Cover Letter for Technical Bid
Date:
To,
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 / B a s el 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)

200
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Duly authorized to sign Bid for and on behalf of
201
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
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.4
9.4.1
Technical Bid Format

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.
Group
Weight (on
a Scale of
250)
30
1.1
Configurations of the banks 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)
202
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
1.2
Manual upload facility of the historical data, interface with external system such as
CORDEX, interface with banks integral source system / staging area / data warehouse,
and enable integration with KRI, RCSA, Scenario loss data, etc.
Group
Weight (on
a Scale of
250)
2
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.
1.3
Configuration of banks operational risk management framework in terms of

methodology, work-flow, templates, consolidation, models, tools, analysis, monitoring
and reporting.
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.
203
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
2
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.
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.7
Flexibility for system enhancement due to change in regulatory requirements, banks

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.)
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)
204
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
1.9
1.10
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.
The system should have help function to assist the user in understanding the system
functionality through navigation.
Deliverable:
vendor should provide Help Manual too
Group
Weight (on
a Scale of
250)
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.
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 workflow attached to the user rights matrix as specified by the bank.
1.13
System should give relevant error message such as on data upload, on execution of
wrong command etc. including generation of log
1.14
System should provide search facility of various records using fields or combination
thereof which are used to define that particular record.
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.
205
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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.
1.18
System should support the breakdown 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.19
The system should have scalability to take care of any changes brought in by BASEL
guidelines/Regulator
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 banks 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.
Risk and Control Self-Assessment
45
206
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
2.1
2.2
2.3
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.
There should be upload / download facility such as upload of RCSA assessment, plan,
schedule download of respective templates, etc.
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)
207
Group
Weight (on
a Scale of
250)
3
1
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
(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.
2.4
(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)
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.
208
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.
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
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
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
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.
209
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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.
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 / nonsignificant risk, preventive / detective control, control frequency, risk identification by
(auditor / risk entity / ORMD / external events / others) etc.
210
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
Group
Weight (on
a Scale of
250)
2
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.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.
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
2.16
System should facilitate risk assessment should be done on probability and impact
scale
211
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.18
Residual risk should be rated as a result of probability and impact assessment by the
system i.e. product of probability and impact
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.
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.21
A heat-map should be generated for RCSA results with drill-down capabilities. Heatmap 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.
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.
212
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
2.23
Summarizes the assessment results by process, product, risk entity, region, zone, bank,
group, location, risk type etc.
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.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
2.26
Action Plan Report with status e.g. action plan which has breached the timelines and
escalation work flow
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.
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.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.
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
213
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
2.31
link with the respective risk event etc. System should support defining more than one
task under one action plan ID.
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
2.33
There should be a document upload facility to substantiate the RCSA.
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.
2.35
Vendor should conduct a sample run of the entire RCSA exercise as per the scope and
process mentioned by the Bank.
Key Risk Indicators (KRIs)
25
214
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
3
3.1
Implementation of banks 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.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.
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.
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.
215
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
1
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.
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.
3.7
System should facilitate different thresholds for a single KRI assigned to different risk
entities.
3.8
Trigger should be mapped with various level of automated notification and escalation
at various hierarchies e.g. through e- mails, SMS etc.
3.9
Compute KRI value on the defined frequency based on the data uploaded / extracted
as per job scheduling.
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
3.11
System should facilitate creation of action plan for those KRIs which have breached the
threshold or on reaching a critical trigger level
216
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
3.12
link with the respective risk event etc.
3.13
Compare computed value of KRI with the thresholds set and then provide alerts to the
respective notification / escalation level
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.
3.15
KRI Report should be of all types heat map, dash board, tabular, graphical etc.
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.
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.
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.
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.
3.20
Vendor should conduct a sample run of the KRI Scope as per the Bank specified
process.
217
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
30
Loss Data Management (Internal and External both)
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.
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
218
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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, banks internal
classification etc.
4.3
It should be able to capture loss data from all geographies and departments /
operations of the bank.
It should have download and upload facility for loss risk events in a specified template
4.4
System should be able to customize, bank's loss data management framework,

template, work-flow, approval, reports etc.
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
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.
4.7
It should be able to do scaling, judgment overrides or other adjustments to the internal

loss estimates
219
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.
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.
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.
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
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.
4.10
220
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
4.13
Allocation of losses to business lines and loss event type categories along with the
methods used to allocate the losses
4.14
It should enable classification of risk events as boundary events to specify it as credit

risk related or market risk related
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
Status of recovery can also be included such as recovery process initiated but yet to be
received
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.
4.18
It should be able to identify the risk events which are covered in the existing
operational risk insurance policies
4.19
It should facilitate creation of action plan with a particular reference / linking to the
risk event
4.20
External loss data from all sources e.g. public data / pooled industry data / vendor
data, all should be supported by the system
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
4.16
221
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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.
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
4.25
It should facilitate validation of loss data through review and approval e.g. makerchecker and there can be more than one level of review and approval
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.
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
4.24
4.27
222
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
4.28
Group
Weight (on
a Scale of
250)
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.
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.
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.
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.
223
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
5.3
5.4
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
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.
Group
Weight (on
a Scale of
250)
1
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.
5.6
It should be able to customize bank specific reporting requirements at no extra cost to

the bank
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.
224
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
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).
225
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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.
226
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.
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.
6.7
Systems should facilitate scenario analysis of expert opinion
6.8
The system should support defining, capturing and assessment of the scenarios.
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.
6.10
Use of assumptions in scenario analysis based on empirical evidence
6.11
Periodic Review and validation of scenarios should be supported by the system as and
when required by the Bank.
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.
227
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.13
Translation of BEICF factors into quantitative measures for measurement, validation

and verification
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.
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.
6.16
System should determine and justify statistically how the AMA elements are weighted
and combined.
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
6.18
Estimation techniques to fit the operational risk models to historically available

operational loss data
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.
228
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
6.21
The system should have statistical capabilities for estimation of information criteria
such as AIC (Akaike information criterion ) , BIC(Bayesian information criterion ) etc.
6.22
The system should allow to conduct parametric and non - parametric bootstrapping
process
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.
6.24
Provide for Single Severity Distribution and Piece-wise Distribution.
6.25
System should be able to use more than one approach to estimate severity of the
body, tail and entire distribution
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.
6.27
The system should support extreme value theory (EVT)
229
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.28
The system should display the parameters that are used for fitting the distributions. It
should rank and report all the test statistics
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.
6.30
Determination of appropriate body-tail modeling threshold for modeling the body and
tail of the loss distribution separately
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.
6.32
Apply robust statistical techniques to test the reasonableness of the assumptions

about the underlying distributions.
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.
6.34
Provide for modeling correlations/dependence using various methods but not limited
to Independence , Clayton , Gumbel , Frank Guassian T copulas
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
230
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.36
Model documentation should identify and justify assumptions as well as evaluate the
AMA models sensitivity to these assumptions related to correlations/dependence
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.
6.38
Estimation of diversification benefits factored in at the Solo level , group-wide level

and at the banking subsidiary level
6.39
System should consider in AMA Modelling recoveries and insurance settlement as risk
mitigant.
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.
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.
6.42
Mapping of insurance policies to Basel II event types for risk mitigation
231
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
6.44
Provide for the validation of the AMA measurement model through back testing and
statistical testing. Stress testing including reverse stress testing.
6.45
Vendor should assist in getting the models validated/approved by the regulators

(especially in case of the underlying logic being proprietary).
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)
6.47
It should allow for the allocation of capital to business lines.
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.
232
Group
Weight (on
a Scale of
250)
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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.
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

233
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
7.4
7.5
7.6
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
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.
Group
Weight (on
a Scale of
250)
2
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.
Reports should cover qualitative i.e. results of operational risk management processes
and quantitative i.e. capital calculation processes and combination of them
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.
7.9
It should provide facility to access, view, download and print the reports as per user
access rights
7.10
Report should be downloadable in excel, word, pdf etc. file formats
7.11
Operational Risk Management and Measurement Reports should be generated at

multiple dimensions such as ORM capital as per each business line etc.
7.7
234
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
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
The system should be capable of generating performance measurement reports
measured visavis RCSA results, KRI status and action taken by units/business lines.
7.13
Group
Weight (on
a Scale of
250)
1
7.14
System should provide linkages between RCSA, KRI, loss data and audit processes as
required by the Bank and generate report accordingly
7.15
The system should report the operational risk charge before and after any reduction in
capital resulting from the use of insurance.
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
System should provide capital charge drill down at each ORC level, which would
provide a split of LDA VAR and Scenario VAR
7.18
7.19
The system should display capital before diversification

and capital after
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
7.17
235
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
7.21
The vendor should be able to provide post implementation support, configuration

training and end user training.
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.
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
236
Group
Weight (on
a Scale of
250)
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group
Weight (on
a Scale of
250)
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 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
237
250
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.4.2
Technology Requirements Checklist Operational Risk Management
Sr.
No.
1
Max.
Marks
User Interface
25
1.01
1.02

1.03
1.04
1.05
1.06
The system
should
support
configurable
1.07
graphical
238
display
of
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
1.08
1.09
1.1
be standard
1.11
screen etc.
1.12

Text file (.TXT)
Adobe Reader (.PDF)
ASCII (Flat File)
Web Page(.HTML)
1.13
entry of data
1.14

parameters
239
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
2
Max.
Marks
System Architecture
10
2.01
2.02
2.03
run independently
2.04

requirements
affecting domestic or international operations in respect
of the Operational Risk Management System, including Advanced Approaches
under Basel
II without
any additional
development,
licensing, implementation and customization costs to the bank during the
implementation and AMC period.
25
3.01
prevent long term speed concerns.
3.02
3.03
3.04
240
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
3.05
3.06

without downtime. Secondary storage is for backup purposes.
(Retention policy should be as per regulatory guidelines. Backup window should be

during off-peak hours.)
3.07
3.08
processing
3.09
3.10
Security management
30
4.01

administrator
4.02
System
access
should
be permitted
only
through
241
password
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
4.03
followed.
4.04
4.05
4.06

e.g.
A/W/C/N

Max.
Marks
Sr.
No.
4.07
4.08
4.09
4.10
2
2
242
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
4.11
4.12
4.13
Reporting & Others
5.01
5.02
5.03
2
2
3
20

5.04
5.05
The system should allow users to print reports directly from the system
5.06
editable format
243
2
2
1
1
1
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
5.07
Max.
Marks

View Mode
Excel Mode
Text Mode
HTML Table
CSV format
Word File
PDF format
XBRL format
5.08
5.09

Daily
Weekly
Fortnightly
Monthly
Quarterly
Halfyearly
Annual
5.10
The system should allow for archiving of external reports in the following
formats:
244
2
3
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
Adobe PDF
Microsoft Excel
Microsoft Word
Microsoft Access
5.11

retrieval
5.12
General
15
6.01
6.02
The system should handle all types of day count basis including
30/360, Actual/360, Actual/365, Actual/Actual, 30E/360
6.03
limited to Ba nk Ho l i day , SWIFT, International Holiday schedule and Bloomberg
6.04
6.05
viewed by the Bank.
245
1
3
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
6.06
7
7.01
Bank is still implementing DWH, date of completion will be provided at time of SRS.
Integration
limited to:
15
15
Batch processing
Online processing
8
Documentation
10
8.01
such as
available

users.
d) Documents narrating the mathematics, the assumption in all the Models/Pricing
8.02

246
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
Total
9.4.3
A/W/C/N
Comments
150
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.
Module/ Item
Sr.
No.
1.
Hardware
2.
Operating
licenses(Windows
other)
3.
Database licenses
4.
Third party utilities
5.
Any other requirement
Module Description
Requirement
Quantity
System
or
any
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
247
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
1
1.1
Group Weight
(on a scale of
250)
20
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 predefined excel
sheets and other data formats (viz. .txt, .XBRL, .CSV, .XML) apart from
248
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.
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.
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.
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 bankwide
level.
The system should be able to support an interface with Treasury

systems from where the VaR numbers can be fetched
249
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
Interface with external third party system will be of batch processing.
1.6
System should have ability to track and store accountwise previous

credit ratings (external and internal) / scores and LGD.
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.
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.
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
250
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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
2.1
Risk Modelling Capabilities
105
Scorecard/ Rating model development capabilities
2.1.1
The system should enable development of credit scorecards and credit

rating models using following statistical techniques (inclusive):
3. Clustering
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 noncompliance.
2.2
Probability of default modelling: The system should enable
20
251
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
development and configuration of

2.2.1
Calibration curve fitting approach
2.2.2
Low default portfolio calibration approach for large corporate
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.
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 banks data and banks portfolio and as per Basel II and
RBI guidelines.
2.2.5
The solution should be capable of computing Throughthecycle PD and

Pointintime 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
2.3
Loss given default (LGD) modeling: The system should enable LGD
modeling using workout LGD methodology and provide ability to
20
252
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 workout
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/, collateralwise 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 banks data
and as per banks portfolio as per Basel II and RBI guidelines.
2.3.2
The system should be able to fetch default and recovery information

from various source systems and data cleansing
2.3.3
Choose a discount rate for discounting of recovery cash-flows and

recovery costs
2.3.4
Compute the workout period for each portfolio
253
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
2.3.5
Compute discounted LGD
2.3.6
Develop LGD prediction models using

3. Clustering
2.3.7
Support GUI interface for end to end LGD modeling
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.3.9
The solution should provide for effective LGD where the Bank is
having other financial/AIRB collaterals and pool of collaterals
2.3.10 The system should be able to compute Downturn default weighted

LGD as per RBI/ Basel guidelines.
2.4
2.4.1
Exposure at Default (EAD)
10
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 banks portfolio as per
Basel II and RBI guidelines.
For estimation of EAD & CCF, it should also do undrawn analysis,
254
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.4.3
The system should have capabilities to compute realized CCF (Credit

Conversion Factor) for defaulted exposures
2.4.4
Capability to develop CCF prediction models using

3. Clustering
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)
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
255
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.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.)
scorecards
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.
256
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.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 banks retail portfolio as per Basel II and RBI guidelines.
2.5.7
The system should generate reports to monitor/track pool stability and

accuracy.
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
2.6
2.6.1
Basic modeling techniques: The system should support the following

basic modeling steps
Sampling techniques (Simple, stratified, random etc.)
257
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
2.6.2
Missing value imputation
2.6.3
Outlier detection and elimination
2.6.4
Variable transformation (Transformations like natural log, exponential,

inverse, sin, root etc. should be available)
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.
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)
258
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
2.7.2
Calibration Test - Hosmer Lemeshow Test, Kolmogorov-Smirnov (KS)

Test, Concentration Analysis in rating grades and individual factor
scores.
2.7.3
Stability Test - Population Stability Index (PSI) Test
2.7.4
Additionally, the system should provide other factor level tests such as
Good vs. Bad analysis, Log-odds trend analysis
2.7.5
The software should provide the results of above tests in pre-defined

report formats (tabular and graphical formats)
2.7.6
Back testing techniques for PD, LGD & EAD models
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
259
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
consistently and meaningfully.

Vendor should give complete documentation
methodology including user manuals.
2.8
of
validation
Maturity(M)
2.8.1
The system should be able to calculate Effective Maturity for corporate

exposures
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
Modelling Other Requirements
2.9.1
The solution should provide necessary treatment for repo style

transactions/ guarantees/ credit derivatives under both foundation as
well as advanced approaches
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 BaselII/ 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.
2.9
260
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
2.9.4
The solution should support development of multiple PD, LGD & EAD
models and should enable for validation.
2.9.5
The solution should be able to generate PD, EAD, LGD for sub
portfolio like industry, sector, Geography etc.
Capital Computation Rules
50
Capital Computation General
10
At present Bank is following Standardized Approach.
3
3.1
3.1.1
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
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
261
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
3.1.3
The system should be able to perform firmsize adjustment for

small and medium size entities
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
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
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

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
262
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
3.1.8
The system should be able to calculate capital requirement

individual accountwise and also unitswise such as:
Entire Bank
Region/zone
Geography
Industry
Business segments
Products
Rating wise
Branch
Relationship Manager
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
263
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 BaselII 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

264
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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:
Counterparty or combination of counter parties

Industry / Sub-industries
Tenor
Product
265
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
Geography
Issuer
Credit rating
Currency
Any internal hierarchy

3.2.4
3.3
3.3.1
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.
Credit risk mitigation
15
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.
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,
266
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 banks
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 BaselII 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 BaselII
accord/ RBI guidelines on IRB approach.
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.
3.3.5
System should support collateral optimization as well as pre-defined

ranks provided by the bank both.
3.3.6
The system should have the ability to assign the risk weights for
Guarantors as per RBI Guidelines.
267
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.
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.
The system should be able to perform on balance sheet netting and
capital calculation based on the net credit exposure.
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.
3.3.9
The solution should make adjustments for different holding periods

based on the quality of collaterals and nondaily 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
268
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 overcollateralization or under
collateralization)
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
3.3.14 System should be able to do collateral optimization as well as bank
defined mapping / ranking of collaterals against an exposure
269
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
3.4
Group Weight
(on a scale of
250)
RWA computations
15
The system should come with pre-build rules for computation of RWA
for:
3.4.1
Corporate Non SME
3.4.2
Corporate SME
3.4.3
Bank
3.4.4
Sovereign
3.4.5
Retail
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.
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
270
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.
3.4.9 The system should be able to capture the banks role (e.g. Originator,
investor etc.) for the securitization exposures, various credit
enhancements and should calculate the capital as per Basel II
Guidelines
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.
3.4.11 Purchased receivables for corporate and retail. The computation
capabilities should cover default risk and dilution risk.
1
1
For Default risk, the system should be able to apply Topdown

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
4
4.1
Stress testing
15
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
271
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 banks review and confirmation for stress testing above
4.3
Creation of sensitivity tests
4.4
Creation of multi factor scenarios based on historical scenarios,

hypothetical forward looking scenarios based on macroeconomic data
points
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.)
272
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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
4.7
Capability to assess second order impact of risk silos (E.g., Impact of

reputational risk on Credit risk)
4.8
Support reverse stress testing
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.
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
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,
273
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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.
5.4
The system should support capital allocation based on RAROC.
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.
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.
5.7
System should have the capability to compute CVA (Credit Value

Adjustment) under RBI /BaselIII Guidelines.
Reporting capabilities
35
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-
6
6.1
274
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 prebuilt pillar 3 reports
as per Basel / RBI guidelines on BaselII and BaselIII.
6.1.2
Origination metrics
6.1.3
Capital efficiency monitoring
6.1.4
Basel II & III parameter reports
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
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
275
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 prebuilt & 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:
Counterparty
Portfolio
Product
Geography country/ state/zone/branch
Industry
Concentrations
Risk Profiles
Rating wise
Delinquency buckets
PD Bands
LGD Bands etc.

276
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
6.2.3
The solution should be able to generate Risk Profile Template as per

RBI guidelines and other regional/branchwise risk profile templates
for credit risk as per Banks internal requirements
6.2.4
The system should be capable of generating various Bank defined

reports like:
Borrower Information report

Industry Analysis report
Monitoring (Accountwise report to cover rating transition &
trend in critical identified parameters)
Peer group Analysis report
Rating wise reports
Portfolio reports
Borrowerwise risk score report
Borrowerwise risk grade report
Borrowerwise year wise risk score report
Borrowerwise 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/ onbalance sheet / offbalance sheet
277
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
exposure wise for a date range etc.)

RAROC reports vertical wise, geography wise, rating grade wise
etc.
Capital Chargecredit risk (Regulatory and economic)
expected and unexpected losses
Exposure
Reports
(Portfolio
exposure
by Sector/ industry/credit
rating/ Client/
Loan
Size/ Maturity/ country/currency/Onbalance 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 industrywise, ratinggrade wise, curing
wise, tenor wise, sacrifice wise, productwise, vertical wise, region
wise, branchwise, asset classwise.
6.2.5
The reports should be able to cut- across asset classes and give
combined reports, if needed, while analyzing industrywise, product
278
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
wise,
sectorwise
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 el i gi b 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
6.2.7
Expiry reports on
collateral (Due to
bank/zone/branch/account wise
6.2.8
Residual Contractual Maturity Breakdown of the whole portfolio

broken down by major type of Credit Exposures
6.2.9
Exposure weighted average LGD/EAD for each borrower category
expire/expired)
6.2.10 Securitization disclosure (total outstanding exposure securitized by

bank broken-down by type of securitization (traditional/Synthetic),
exposure type.
6.2.11 Amount of NPA securitized broken down by exposure type
6.2.12 Securitization exposure retained/purchased broken down by

exposure type. (This report would be generated for user defined
279
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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
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
6.2.15 Report on Interest rate wise break up of advances segment wise as

per user defined range of rate of interest
position
of
unsecured
exposure
6.2.16 Report on
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
280
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
6.2.17 Report on pre- payment of total/instalment of term loans, project

finance, bills purchased/discounted or negotiated, demand loans
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 visvis prudential exposure limits fixed
by bank/regulator
6.2.19 Export formats for MIS report
.TXT
.XLSX
.PDF
.DOCX
.PPTX
.XML
.XBRL
6.2.20 Overrides performance reports performance of accounts where
there is rating override or downgrades (Branch wise / region
wise /geography wise/level wise/approving user wise rating cases
281
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
processed, approved, rejected and pending for user defined period.

6.2.21 The system should support portfoliobased 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
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.

6.2.23 The system should be able to generate risk maps, risk charts, trend
analysis etc. for PillarI and PillarII risks, various risk dashboards for
282
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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

7
7.1
ICAAP
10
The system should have a PillarII module which supports ICAAP

analysis of all material PillarII 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
ratinggrade wise, interest rate wise, groupwise, borrowerwise
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 PillarII.
Data required for the preparation of ICAAP document has to be

generated through the system.
7.2
The system should perform stress testing for each of the credit,
market, interest rate, forex, liquidity, concentration risk
on
283
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
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 PillarII risks.
Additionally, the system should also support aggregation of PillarII
capital into Bankwide 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
Pillar2.
7.4
The system should have capital planning and budgeting modules for
e s t i m a t i n g bankwide capital for future, stress testing by changing
assumptions/ macroeconomic scenarios, allocation across business
units, geographies, products etc., if needed.
7.5
The system should be able to generate risk maps, risk charts, reports,
trend analysis etc. for PillarII risks, various risk dashboards for the
users and top management.
Basel III Requirements
The system should have the capability for computation of nonrisk
8
8.1
284
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Group Weight
(on a scale of
250)
based leverage ratio as per RBI/ BaselIII guidelines.

The system should have the flexibility to enable reporting and
estimation of each capital components like common equity, Additional
Tier1, Tier2 etc. as per prescribed guidelines of RBI under BaselIII.
The Pillar1, Pillar2 and Pillar3 modules should be compliant with
RBIs BaselIII requirements also.
8.2
System should facilitate capital computation and computation of

leverage ratio as per Basel II & III guidelines
Total Marks
250
285
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.4.5
Technology Requirements Checklist Credit Risk Management
Sr.
No.
User Interface
Max.
Marks
25
1.01
1.02

1.03
1.04
1.05
1.06
The system
should
support
configurable
1.07
graphical
286
display
of
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
1.08
1.09
1.1
be standard
1.11
screen etc.
1.12

Text file (.TXT)
Adobe Reader (.PDF)
ASCII (Flat File)
Web Page(.HTML)
1.13
entry of data
287
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
1.14

parameters
System Architecture
10
2.01
2.02
2.03
run independently
2.04

requirements affecting domestic or international operations in respect of the Credit
Risk Management System, including Advanced Approaches under Basel II without
any additional d e v e l o p m e n t , licensing, implementation and customization costs
to the bank during the implementation and AMC period.

25
3.01
prevent long term speed concerns. Bank needs a separate data archival solution and
query on archived data is required.
3.02
3.03
3.04
288
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
3.05
3.06

without downtime.
3.07
3
3.08
3.09
3.1
4
processing
Security management
30
4.01

administrator
4.02
System
access
should
be permitted
4.03
followed.
4.04
only
through
289
password
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
4.05
4.06

e.g.

4.07
4.08
4.09
4.10
4.11
4.12
4.13
Reporting & Others
20
290
2
2
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
5.01
5.02

5.03
5.04
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.
The system should allow reports to be exported into Microsoft
Excel, Adobe PDF format and other databases
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
5.06
editable format
291
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
5.07
5.08
Max.
Marks
View Mode
Excel Mode
Text Mode
HTML Table
CSV format
Word File
PDF format
XBRL format
5.09
5.10

Daily
Weekly
Fortnightly
Monthly
Quarterly
Halfyearly
Annual
The system should allow for archiving of external reports in the following formats:
Adobe PDF
Microsoft Excel
Microsoft Word
Microsoft Access
292
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Max.
Marks
Sr.
No.
5.11

retrieval
5.12
General
6.01
6.02
The system should handle all types of day count basis including 30/360, Actual/360,
Actual/365, Actual/Actual, 30E/360
6.03
limited to Ba nk Ho li d ay , SWIFT, International Holiday schedule and Bloomberg
6.04
6.05
viewed by the Bank.
6.06
Integration
15
7.01
limited to:
15
15
4
293
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Max.
Marks
Batch processing
Online processing
8
8.01
Documentation
10
such as
available
users.
d) Documents narrating the mathematics, the assumption in all the Models / Pricing
8.02

audience of users, systems manager/administrator
Total
150
294
A/W/C/N
Comments
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
Module/ Item
1.
Hardware
2.
Operating
System
licenses(Windows or
any other)
3.
Database licenses
4.
Third
utilities
party
5.
Any
requirement
other
Module Description
Requirement
Quantity
Note:
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.
295
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
296
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
I.
1
Application Servers
Data
Center
Servers
Proposed Configuration
Application
CPU
Memory
Hard disc
Network Interface Cards
Mother board
Operating System
Other Components
Disaster
Recovery Center
Application Servers
297
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sl.
No.
Components
CPU
Memory
Hard disc
Mother board
Operating System
Other Components
II.
Database Servers
Data
Servers
Center
database
CPU
Memory
Hard disc
Mother board
Operating System
Other Components
Disaster
Recovery
Center
298
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sl.
No.
Components
Database Servers
III.
5
CPU
Memory
Hard disc
Mother board
Operating System
Other Components
Test & Development Server
Test
Servers
&
Development
CPU
Memory
Hard disc
Mother board
Operating System
Other Components
299
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sl.
No.
Components
IV.
6
Storage Solution
Storage Area Network

SANModules
Disk Arrays (including the raw
size. Provide complete technical
details of the proposed solution.)
Other Components
SAN Switch
Tape Library
Drives
Tapes
Other Components
Backup Server
CPU
300
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sl.
No.
Components
V.
7
Memory
Hard discs
Mother board
Operating System
Other Components
RDBMS Details
RDBMS Licenses
Name and Version of the
RDBMS
Licensing
Mode
(Processor Based/ Server Based

/ Others)
No of Units
VI.
8
Integrated Capital Computation & Reporting Module
ETL
Tool
Version
Name
and
301
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sl.
No.
Components
License Mode
Server Requirement (Application /
Database)
Reporting Tool Name and

Version
License Mode
Server
Requirement
(Application / Database)
302
Justification
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.4.8
Training Requirements
Please provide descriptive answers to the following questions on Operational Risk management.
Sr.
No.
Requirements
Response
How many Implementation trainings (ORMS) have been

undertaken by the Bidder so far?
Please provide a brief description on the Training approach

taken by the Bidder.
Please provide the following details for training :
3.1
Number of mandays / duration for completion of training
3.2
Optimum batch size
3.3
3.4
Location
3.5
3.6
Prerequisites / Preparations required before training
Please answer the following about the trainers in charge of

conducting the training on behalf of the Bidder for the Bank:
303
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
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
Please provide a sample training response and feedback from

previous implementations?
6.1
Name
of
the
Bank
where
6.2
6.3
Training audience
6.4
product
was
Note: Please attach the feedback in a separate document with

proper crossreferencing.
7
Please specify the various modes through which the training will
be delivered? [e.g. Classroom training, Online selfhelp training
304
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
modules within application / elearning modules, Quiz, etc.]
Please provide descriptive answers to the following questions on Credit Risk management System.
Sr.
No.
Requirements
Response
How many Implementation trainings for Credit Risk Management

System
(CRMS)
have
been undertaken
by the so far?
Please provide a brief description on the Training approach

taken by the Bidder.
Please provide the following details for training :
3.1
Number of mandays / duration for completion of training
3.2
Optimum batch size
3.3
3.4
Location
3.5
305
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
3.6
Requirements
Response
Prerequisites / Preparations required before training
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
Please provide a sample training response and feedback from

previous implementations?
6.1
Name
of
the
Bank
where
6.2
6.3
Training audience
product
was
306
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
6.4
Requirements
Response

Note: Please attach the feedback in a separate document with
proper crossreferencing.
9.4.9
Sr.
No.
1
Please specify the various modes through which the training

will be delivered? [e.g. Classroom training, Online selfhelp
training modules within application / elearning modules, Quiz,
etc.]
Project Management Methodology

Requirements
Response

The
methodology
section
should
address the following stages of the project:
adequately
1.1
Frequency and approach for periodic reporting on the

progress of the project and actual status visvis scheduled
status
1.2
Detailed Study of Current State, with detailed

307
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
work steps and deliverables

1.3
Gap
analysis
resolution of gaps
1.4
Customization, development and necessary work around
1.5
Building
up
of
interfaces
applications currently used by the bank
1.6
Setting up of the data center and the disaster recovery site
1.7
1.8
Planning for rollout and

that may arise
solutions
including
identification
with
and
various
identification of key issues

along
with proposed
Timelines
Roles and responsibilities of proposed personnel both from the

vendor and bank end
Following
details
with
respect
methodology followed by the vendor in Project
to
the
308
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Requirements
Response
Management for a Public Sector Bank

Project Name
Project Location
Client Name
Client address
Manmonths effort
Project Size (No of branches, modules covered and any other
relevant details)
Role of the Bidder, whether complete endtoend 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
activitywise and modulewise may be detailed.)
309
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Signature of Bidder:
Name:
Business Address:
Place:
Date:
310
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Add more Users
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
Negotiated Dealing System
B@nc24
Legacy banking applications used by the bank
CRISIL System (Risk Assessment Model RAM)
Other Risk management software
Data warehousing package (SDR)
Liquidity management system
Centralized Loan Appraisal System and Supervision (CLASS)

311
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 percall 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 mandays
16. Please specify the details of the training course
o
Cost if any
Location
Duration
Frequency of offering
Prerequisites
Training description
312
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.6
Cover Letter for Commercial Bid
Date:
To,
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
313
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
(Signature) (In the capacity of)

Duly authorized to sign Proposal for and on behalf of
314
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
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.7
Commercial Bid (Bill of Material) Format
9.7.1 Part I Commercial Bid Format CRM & ORM Solution (Amount in INR Lakhs)
Item Description
Sr.
No.
No.
of
Units (A)
Software (for both DC & DR site)

1
Operational
System
Risk
Management
Middleware (if any)
Third Party Utilities (if any)
Software/tools for SLA monitoring

SUB TOTAL A
Environmental Software
(for both DC & DR)
(to be suggested by the bidder for proposed
solution as per their need for the solution)
315
Unit
Price
(B)
Sub
Total
Price
(A*B)
Total
Price
Total
Price
including Taxes including Taxes
(Sales
and Octroi
Tax/VAT/ Service
Tax)
Total
Price
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Item Description
Sr.
No.
No.
of
Units (A)
SUB TOTAL B
Hardware (for both DC & DR site)

1
Servers
Operating System
Storage (SAN)
Rack with KVM

switch,
power
supply
,
Network
& security
requirements, switches,
routers etc.
Hardware
monitoring
required
for
SLA
SUB TOTAL C
316
Unit
Price
(B)
Sub
Total
Price
(A*B)
Total
Price
Total
Price
(Sales
and Octroi
Tax/VAT/ Service
Tax)
Total
Price
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Item Description
No.
of
Units (A)
Implementation, System Integration, Training
Integration
of
existing systems
new
system
with
SUB TOTAL (A+B+C+D)
AMC & ATS cost as per Part II
Facilities Management (both at DC & DR)
Change Management Cost (Cost for 100 Man

days)
Total Project Cost (A+B+C+D+E+F+G)

Total
Project
Cost
(in
Rs
word)
317
Unit
Price
(B)
Sub
Total
Price
(A*B)
Total
Price
Total
Price
(Sales
and Octroi
Tax/VAT/ Service
Tax)
Total
Price
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Item Description
No.
of
Units (A)
Unit
Price
(B)
Sub
Total
Price
(A*B)
Total
Price
Total
Price
(Sales
and Octroi
Tax/VAT/ Service
Tax)
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.
318
Total
Price
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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:
319
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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)
Total (to be carried forward to Part

I)
320
Period 1yr
(B)
Total
maintenance
charges
(A*B)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Signature of Bidder
Name
*The AMC Price should be valid for 3 years.
321
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.7.2 Part I Commercial Bid Format CRM & ORM Solution (Masked)
Item Description
Sr.
No.
No.
of
Units (A)
Software (for both DC & DR site)

Risk
Management
Unit
Price (B)
Sub
Total
Price
(A*B)
Total
Price
including Taxes
(Sales
Tax/VAT/
Service Tax)
Total
Price
Total Price
including
Taxes
and
Octroi
Operational
System
Middleware (if any)
Third Party Utilities (if any)
Software/tools for SLA monitoring
SUB TOTAL A
RDBMS & Environmental Software

(for both DC & DR)
1
Data Base Software License
SUB TOTAL B
322
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Item Description
Sr.
No.
No.
of
Units (A)
Sub
Total
Price
(A*B)
Total
Price
including Taxes
(Sales
Tax/VAT/
Service Tax)
Total
Price
Total Price
including
Taxes
and
Octroi
Hardware (for both DC & DR Site)
Servers
Operating System
Storage (SAN)
Rack with KVM

switch,
power
supply ,
Network
and
security
requirements, switches, routers etc.
Hardware
monitoring
required
for
SLA
SUB TOTAL C
D
Unit
Price (B)
Implementation, System Integration, Training
323
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sr.
No.
Item Description
Integration
of
existing systems
new
No.
of
Units (A)
system
Sub
Total
Price
(A*B)
Total
Price
including Taxes
(Sales
Tax/VAT/
Service Tax)
Total Price
including
Taxes
Total
Price
and
Octroi
SUB TOTAL (A+B+C+D)
AMC & ATS cost as per Part II
Facilities Management (both at DC & DR)
Total Project Cost (A+B+C+D+E+F)
Total
Project
Cost
(in
Rs
with
Unit
Price (B)
word)
Additional Training Cost (Person day rate)
324
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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,
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
325
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Bid Cost
EMD
Yours Faithfully,
(Name of Authorized Signatory)
(Designation)
(Name of Producers)
326
Amount
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.9
Reference Site Details
The reference sites submitted must be necessarily of those banks where the proposed vendor/ OEMs
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 201314
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
327
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.10 Particulars of Bidder

9.10.1 Profile of Bidder
Name of Bidder
Location
Registered Office
Controlling Office
Date
of incorporation
commencement of business
&
date
of
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)
201112
201213
201314
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)
328
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Place: Date:
Signature:
Name & Designation:
Business Address:
329
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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)
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
(Enclose necessary documentary proof)

330
Project
Status
(Completed/ Under
implementation)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 331
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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/- -----------------------------------------
332
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
333
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 purchasers 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 Banks 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.
334
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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/- -----------------------------------------
335
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
336
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 indepth 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.
337
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
338
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.15 Important Project Timelines

Project Milestone
Time lines
Period within which Performance Security or amendment thereto is to be 21

days
(grace
submitted by the successful Bidder upon notification of award of contract
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
45 weeks
Period
for
the
entire
solution
commissioning after the award of contract.
to
Trainings
be
ready
for
12 Months
As planned by the bank as

per scope of this RFP
339
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.16 List of Existing Applications

Area of Operation
S.
No.
Application Name
Vendor/ Supplier
Database
Platform
Core Banking solutions (CBS)
B@NCS24
TCS
Oracle
Sun Solaris
ATM-Switch
Electra EFT
Electra Card Services
Oracle
Sun Solaris
Anti-Money Laundering
Solution (AML)
FINDNA
TCS
Oracle
Sun Solaris
Risk Assessment Model
RAM
CRISIL
Oracle
Windows
Internet Banking (Internet /

Mobile / SMS Banking)
e-Bankworks
TCS
Oracle
Sun Solaris
Lending
Automation
System (CLASS)
CLASS
SysArc Pvt. Ltd.
DB2
Windows
Mobile Payment (IMPS)
IMPS / NPCI
TCS
Oracle 11G
Sun Solaris
Asset
Liability
Management (ALM) SDR
SUNGARD
IBM
DB2
AIX
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
340
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Area of Operation
Application Name
Vendor/ Supplier
Database
Platform
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,
B@NC24
Provisioning
&
Report
Generation of
Loans
&
Advances
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
341
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
S.
No.
Area of Operation
Application Name
Vendor/ Supplier
Database
Platform
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 ASBA

Amount
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
342
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.17 List of Existing Applications from where Credit Risk Input data may be integrated
S.
No.
Area of Operation
Application Name
Vendor/ Supplier
Database
Platform
Core Banking solutions (CBS)
B@NCS24
TCS
Oracle
Sun Solaris
Risk Assessment Model
RAM
CRISIL
Oracle
Windows
Lending
Automation
System (CLASS)
CLASS
SysArc Pvt. Ltd.
DB2
Windows
Asset
Liability
Management (ALM) SDR
SUNGARD
IBM
DB2
AIX
Treasury
BANCS Treasury version
TCS
Oracle
Sun Solaris
Market Risk
SAS
TCS
Oracle
Sun Solaris
Asset Classification, Provisioning B@NC24

& Report Generation of Loans
& Advances
TCS
Oracle
Sun Solaris
8
9
Credit Risk
MIS
SAS
B@NC24
TCS
TCS
Oracle
Oracle
Sun Solaris
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
343
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
344
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Banks decision not to accept any such extraneous conditions and deviations will be final
and binding on us.
Yours faithfully,
Authorised Signatory
Designation
Vendors 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.
345
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
9.19 Architecture
346
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
Prod-Database
Risk Mgmt.
Database
server
Sun Fire
V490
0904AM0127
2UltraSPARCIV+/8GB/146*2HDD
Solaris 10 10/08 Oracle 10g

s10s_u6wos_07b
Prod-Web &App
Risk Mgmt.
Websphere
server
Sun Fire
V490
0902AM0064
2UltraSPARCSolaris 10 10/08 WebSphere

IV+/16GB/146*2HDD s10s_u6wos_07b
Prod-Compute
Risk Mgmt
compute
Server
Sun Fire
V490
0902AM0018
2UltraSPARCSolaris 10 10/08 Oracle 10g

IV+/16GB/146*2HDD s10s_u6wos_07b
Prod-Metadata
Risk Mgmt
Metadata
Sun Fire
0904AM0139
2UltraSPARC-
347
Solaris 10 10/08
Application /
Database
Server
WebSphere
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Server
V490
IV+/8GB/146*2HDD
s10s_u6wos_07b
Backup
Risk Mgmt
Backup
Server
Sun Fire
T5120
BEL0851R8J
1UltraSPARCT2/8GB/146*2HDD
Solaris 10 10/08 EMC2

s10s_u6wos_07b NETWORKER
UAT
Risk Mgmt
Database
UAT server
Sun Fire
V490
0904AM0144
Solaris 10 10/08 Oracle 10g

s10s_u6wos_07b
UAT
Risk Mgmt
Websphere
server
Sun Fire
V490
0904AM0118
Solaris 10 10/08 WebSphere

s10s_u6wos_07b
Prod
SAN Storage
StorageTek
2540
12 * 300 GB SAS HDD

with dual controller
Prod
SAN Switch
Brocade
SW200E
4Gbps*8 Ports
Activated
10
Prod
Network
Switch
Cisco
Catalyst
24 Port *2
348
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
349
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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:
350
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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 Partys Confidential Information in violation of the terms of this Agreement. Further, any breach
351
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
352
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.
353
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
For and on behalf of
__________________
Name of Authorized signatory:
Designation:
For and on behalf of

CENTRAL BANK OF INDIA
_____________________
Name of Authorized signatory:
Designation:
354
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
End of Document
355

CBI Vendor RFP 01102014 - Advanced Approaches

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

CBI Vendor RFP 01102014 - Advanced Approaches

Transféré par

Droits d'auteur :

Formats disponibles

REQUEST FOR PROPOSAL (RFP)

For Procurement, Installation and Implementation of

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

Definitions of major terms / abbreviations used in the document:

Sr. No. Acronym/ Terms Used

Advanced Measurement Approach

Central Bank of India

Framework for Capital Measurement and Capital Standards

Basel II RBI Guidelines

A global regulatory framework for more resilient banks and

Master Circular Prudential Guidelines on Capital

Basel III RBI Guidelines

Commercial Offer/ Commercial Bid/ Price Bid

Credit Risk Management System

Field General Managers Office

Core Banking Application software used in bank

Internal Model Approach

Intellectual Property Right

Implementation of Basel III Capital Regulations in India

Sr. No. Acronym/ Terms Used

Software Solution for Treasury operations

Key Risk Indicators

Management Information System

Network Attached Storage

New Capital Adequacy Framework

Original Equipment Manufacturer Product Vendor

Operational Risk Management System

Reserve Bank of India

Risk and Controls Self-assessment

Request for Proposal

The Standardized Approach

Service level Agreement

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

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

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

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

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

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

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

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

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

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

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

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

PreBid Meeting .............................................................................................................................. 23

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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