Request for Proposal and Quote - South Indian Bank SIB EWIRM V 1 0... · Request for Proposal and...

Request for Proposal and Quote

For

End to End Solution for Implementation of Enterprise-wide Integrated Risk Management

Architecture in accordance with the International Best Practices and Guidelines of RBI/BCBS on

Basel II, Basel- III, ALM and FTP

(Also referred to as Project in this RFP)

(Experience Next Generation Banking)

Integrated Risk Management Department

SIB House, 2nd

Floor, Mission Quarters,

Thrissur, Kerala-680001

Ph:-0487-2423858/2420020(Ext:-357)

Name of the Company : The South Indian Bank Limited

Date of issue of RFP document :

08/03/2014

RFP reference number : IRMD/ RFP /001/2014

Last Date and Time for receipt of Bid :

28/03/2014

Integrated Risk Management Department, The South Indian Bank Limited.

Disclaimer

The information contained in this Request for Proposal (RFP) document or information provided

subsequently to bidder(s) or applicants whether verbally or in documentary form by or on behalf

of The South Indian Bank Limited, 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.

This RFP document is not an agreement and is not an offer or invitation to bid by The South

Indian Bank Limited to any parties other than the applicants who are qualified to submit the bids

(“bidders”). The purpose of this RFP is to provide the bidder(s) with information to assist them in

formulation of their proposals. This RFP does not claim to contain all the information each bidder

may require. Each bidder should conduct its own investigations and analysis and should check the

accuracy, reliability and completeness of the information in this RFP and where necessary obtain

independent advice. The South Indian Bank Limited 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. The South Indian Bank Limited may in its absolute discretion, but

without being under any obligation to do so, update, amend or supplement the information in this

RFP.


Glossary

Sl. No. Acronym/ Term Used Definition

1. AFS Available For Sale

2. AGL Aggregate Gap Limit

3. AIRB Advanced Internal Ratings Based

4. ALM Asset And Liability Management

5. AMA Advanced Measurement Approach

6. AMFI Association Of Mutual Funds In India

7. ASCII American Standard Code For Information Interchange

8. ATS Annual Technical Support

9. Bank The South Indian Bank Ltd

10. BALM Banks Asset Liability Management System

11. Basel II Guidelines Framework for Capital Measurement and Capital Standards issued

by Basel Committee on Banking Supervision

12. Basel II RBI

Guidelines

Master Circular - Prudential Guidelines on Capital Adequacy and

Market Discipline- New Capital Adequacy Framework (NCAF)

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 (IMA) for Market Risk

13. Basel III Guidelines

A global regulatory framework for more resilient Banks and

Banking systems and International framework for liquidity risk

measurement, standard and monitoring

14. Basel III RBI

Guidelines

Guidelines on Implementation of Basel III Capital Regulations in

India Guidelines on Liquidity Risk Management and Basel III

Framework on Liquidity Standards, Capital Requirements for

Bank‟s Exposures to Central Counterparties

15. BCBS Basel Committee on Banking Supervision

16. BEICF Business Environment And Internal Control Factors

17. BIS Bank For International Settlements

18. BSE Bombay Stock Exchange

19. CASA Current & Savings Account

20. CBS Core Banking Solutions

21. CC Cash Credit

22. CCIL Clearing Corporation Of India Ltd.

23. CD Certificate Of Deposit/Compact Disc

24. CDS Credit Default Swap

25. CORDEX Credit & Operational Risk Loss Data Exchange

26. CRISIL Credit Rating Information Services Of India Limited

27. CRMS Credit Risk Management System

28. CRR Cash Reserve Ratio

29. CSV Comma-Separated Value

30. CVA Credit Valuation Adjustment


31. DGA Duration Gap Analysis

32. DICT Department Of Information & Communication Technology

33. DVD Digital Video Disc

34. DVP Delivery Versus Payment

35. EAD Exposure At Default

36. EDW Enterprise Data Warehouse

37. EWIRM Enterprise Wide Integrated Risk Management

38. FEDAI Foreign Exchange Dealers‟ Association Of India

39. FIFO First In First Out

40. FIMMDA Fixed Income Money Market And Derivatives Association Of India

41. FIRB Foundation Internal Ratings Based

42. FTP Fund Transfer Pricing

43. FX Foreign Exchange

44. GARCH Generalized Autoregressive Conditional Heteroskedasticity

45. GL General Ledger

46. GLM Generalised Linear Model

47. GLMM Generalised Linear Mixed Model

48. GUI Graphical User Interface

49. HFT Held For Trade

50. HRMS Human Resource Management System

51. HTM Held To Maturity

52. ICAAP Internal Capital Adequacy & Assessment Procedure

53. iCDMS Integrated Corporate Data Management System

54. IGL Individual Gap Limit

55. IMA Internal Model Approach

56. IMF International Monetary Fund

57. IR Interest Rate

58. iRAC Income Recognition And Asset Classification

59. IRB Internal Ratings Based

60. IRMD Integrated Risk Management Department

61. IRMS Integrated Risk Management System

62. IT Information Technology

63. KRI Key Risk Indicators

64. LDP Low Default Portfolio

65. LGD Loss Given Default

66. LIBOR London Interbank Offer Rate

67. LIFO Last In First Out

68. LOS Loan Origination System

69. M Effective Maturity

70. MIBOR Mumbai Interbank Offer Rate

71. MIS Management Information System

72. MRMS Market Risk Management System

73. MTM Marked To Market

74. MVA/E Market Value Of Asset/ Equity

75. MVS Market Value Sensitivity


76. NABARD National Bank For Agriculture And Rural Development

77. NAS Network Attached Storage

78. NCAF New Capital Adequacy Framework

79. NDS Negotiated Dealing System

80. NEFT National Electronic Funds Transfer

81. NII Net Interest Income

82. NIM Net Interest Margin

83. NOOP Net Overnight Open Position Limit

84. NPA Non-Performing Asset

85. NPV Net Present Value

86. NSE National Stock Exchange

87. OD Overdraft

88. OEM Original Equipment Manufacturer/ Product Vendor

89. ORMF Operational Risk Management Framework

90. ORMS Operational Risk Management System

91. OSMOS Off-Site Monitoring And Surveillance

92. OTC Over The Counter

93. PD Probability Of Default

94. PFE Potential Future Exposure

95. P&L Profit & Loss

96. PVBP Price Value Of A Basis Point.

97. QRRE Qualified Revolving Retail Exposures

98. RAPM Risk Adjusted Performance Measurement

99. RAROC Risk Adjusted Return On Capital

100. RBI Reserve Bank Of India

101. RCA Root Cause Analysis

102. RCSA Risk And Control Self-Assessment

103. RFP Request For Proposal

104. RO Regional Office

105. RTGS Real Time Gross Settlement

106. RWA Risk Weighted Assets

107. SI System Integrator

108. SIDBI Small Industries Development Bank Of India

109. SL Specialized Lending

110. SLA Service Level Agreement

111. SLR Statutory Liquidity Ratio

112. SLS Structural Liquidity Statement

113. SMM Standardized Measurement Method

114. SMS Short Message Service

115. SVaR Stressed Value At Risk

116. SWIFT Society For Worldwide Interbank Financial Telecommunication

117. TBO Treasury Back Office

118. TGA Traditional Gap Analysis

119. TMO Treasury Mid Office

120. TO Technical Offer


121. TSA The Standardized Approach

122. UAT User Acceptance Test

123. VaR Value At Risk

124. XML Extensible Mark-Up Language

125. WCDL Working Capital Demand Loan

126. ZCYC Zero Coupon Yield Curve

The term „Project period/duration of project/tenure of project‟ used in this RFP includes

Implementation period (1 year), Warranty period (2 years), AMC period (5 years) and any

further period remaining till the date of receipt of approval from RBI in respect of IRB, AMA

and IMA.

The term „GO LIVE date‟ used in this RFP refers the point of time in which the Banks is capable

of computing the capital charge under advanced approaches of Basel-II/Basel-III and conduct

ALM and FTP in tune with international best practices using banks‟ own data to the satisfaction

of top management. The banks‟ own data is defined as the financial/non-financial information of

the South Indian Bank Limited which is generally used for computation of CRAR under

Basel- II/Basel-III norms and performing ALM and FTP in tune with international best practices.

Further it is envisaged that as on GO-LIVE date the information residing in Finacle, Polaris,

LOS and any other source system should flow seamlessly into the IRMS to generate CRAR and

meet other functional requirements specified in this RFP.


TABLE OF CONTENT

I. INVITATION FOR BIDS: ............................................................................................... 9

II. ABOUT THE SOUTH INDIAN BANK LIMITED ...................................................... 13

III. BACK GROUND ........................................................................................................... 14

IV. SCOPE OF WORK......................................................................................................... 18

V. FUNCTIONAL REQUIREMENTS FOR CREDIT RISK ............................................. 25

VI. FUNCTIONAL REQUIREMENTS FOR OPERATIONAL RISK ............................... 42

VII. FUNCTIONAL REQUIREMENT FOR MARKET RISK ............................................ 51

VIII. FUNCTIONAL REQUIREMENTS IN RESPECT OF PILLAR- II, PILLAR- III &

BASEL III AND INTEGRATED CAPITAL COMPUTATION MODULE................. 69

IX. FUNCTIONAL REQUIREMENTS OF ALMS ............................................................. 72

X. TECHNICAL REQUIREMENTS .................................................................................. 82

XI. AMENDMENT OF RFP: ............................................................................................... 87

XII. INSTRUCTIONS FOR BID SUBMISSION.................................................................. 87

XIII. SUBMISSION OF BIDS ................................................................................................ 88

XIV. ADDITIONAL INSTRUCTIONS FOR BIDDERS ....................................................... 91

XV. TERMINATION ............................................................................................................. 99

XVI. ELIGIBILTY CRITERIA ............................................................................................. 104

XVII. SELECTION STRATEGY ........................................................................................... 107

XVIII. AWARD OF CONTRACT........................................................................................... 112


LIST OF ANNEXURES

Annexure-1 - Check List ............................................................................................................. 120

Annexure-2 - Authorization Letter Format ................................................................................. 121

Annexure-3 - Non-Disclosure Agreement Form ........................................................................ 122

Annexure-4 - Check list for submission of eligibility criteria .................................................... 128

Annexure-5- Profile of bidder/Partner ........................................................................................ 129

Annexure-6 - Implementation methodology ............................................................................... 131

Annexure-7 - Reference site details ............................................................................................ 132

Annexure-8 - Past Experience .................................................................................................... 133

Annexure-9 - Team profile ......................................................................................................... 134

Annexure-10 - Training .............................................................................................................. 136

Annexure-11 - Cover Letter for Commercial Bid....................................................................... 137

Annexure-12 - Format for furnishing the price of Software/Hardware ...................................... 139

Annexure-13 -Table for Arriving at the Total Ownership Cost ................................................ 144

Annexure-14 - Bid submission Covering Letter ......................................................................... 145

Annexure-15 - Notification of Acceptance ................................................................................. 147

Annexure-16 - Specimen contract form ...................................................................................... 148

Annexure-17 - Performance Bank Guarantee Format ................................................................ 155


I. INVITATION FOR BIDS:

The South Indian Bank Ltd, hereinafter called “The Bank” intends to invite Techno -Commercial

bids from eligible Bidder to provide end to end software solution for Implementation of

Enterprise-wide Integrated Risk Management Architecture in accordance with the International

Best Practices and Guidelines of RBI/BCBS on Basel II, Basel- III, ALM and FTP.

A complete set of Request for Proposal (RFP) can be obtained during office hours on all working

days either in person or by Post/E-mail on submission of a written application. Alternatively,

complete set of RFP for the above purpose can be downloaded from Bank‟s official website

www.southindianBank.com - Quick Access-Tender/auction-RFP for Implementation of EWIRM

solution .The bidder who has purchased/ downloaded the RFP is required to submit a non-

refundable fee of Rs.25, 000/- in the form of DD/RTGS, in favour of “The South Indian Bank

Ltd” payable at Thrissur during office hours within the last date and time of submission of bid,

failing which the bid of the concerned bidder will not be entertained. The hard copy of this

document (RFP) procured from the Bank or downloaded from the official website, will alone be

treated as authenticated copy for all purposes.

Bid Collection and submission details are given below.

Bid Reference number : RFP IRMD/001/2014

Date of issue of RFP : 08.03.2014

Last date and time for seeking

Clarification : 15.03.2014, 2.00 PM

Last date and time for submission of

Bids :

28.03.2014, 4.00 PM

Completion of Technical &

Commercial Bid evaluation by Bank

and last date for informing the

qualified bidders for presentation and

negotiation

: 30.04.2014

Last date for final negotiation with the

qualified bidders : 12.05.2014

Bid submission fee (non refundable) :

Rs. 25,000/- in the form of Demand Draft in

favor of “The South Indian Bank Ltd” payable

at Thrissur. The DD should be submitted along

with the Bid. Alternatively the bid submission

fee may be remitted through RTGS to Account

number 0299073000000710 (IFSC Code:

SIBL0000299). The bidders who opts payment

by way of RTGS should quote the UTR number

of the transaction.


Address for submission of bids :

The Chief General Manager (IRMD)

The South Indian Bank Ltd

Integrated Risk Management Department,

SIB House, Head Office,

2nd Floor, Mission Quarters

Thrissur , Kerala,

India – 680001

Contact Person : Ms Chithra H, AGM


Telephone and Fax :

Tele: 0487-2423858/2420020(Ext:-357)

Mobile: 9447904585

Fax: 0487-2424551

E– mail : [email protected], [email protected]

Note:-

Before bidding, the bidders are requested to carefully examine the RFP Document and the

terms and conditions specified therein. If any bidder requires any clarification on this RFP,

may notify the Bank in writing or by email at the Bank‟s mailing address indicated in the

RFP on or before 15.03.2014, 2 PM.

This RFP is being floated to seek appropriate solutions for the implementation of Enterprise-

wide Integrated Risk Management Architecture in accordance with the International Best

Practices and Guidelines of RBI/BCBS on Basel II, Basel- III, ALM and FTP. Bank invites

responses from bidder to propose a contractual arrangement for the provision,

implementation and after-sales support as described in this document.

The purpose of this RFP is to enable the bidder to communicate their qualifications and

product specifications to facilitate the selection of an appropriate risk management solution.

Bidders should notify the Bank of any error, omission, or discrepancy found in this RFP

document not later than 12.03.2014 4:00 PM.

The check list for submission of annexures to be attached along with the bid are given in

Annexure-1

All costs and expenses (whether in terms of time or money) incurred by the bidders in any

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

not limited to attendance at meetings, discussions, demonstrations and for providing any

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

bidders.

The bidders must conduct its own investigation and analysis regarding any information

contained in the RFP document and the meaning and impact of that information.

All bids (Technical & Commercial) must be submitted at the same time giving full particulars

in separate sealed envelopes at the Bank‟s address within the time period specified above.

The Bank reserves the right to accept or reject in part or full any or all the offers without

mailto:[email protected]

mailto:[email protected]


assigning any reasons whatsoever.

No further discussion/interface will be entertained with bidders whose bids have been

technically disqualified.

Those technically qualified bidders may depute their representative/s (not more than 3) to

attend the negotiation meeting held on or before 12-05-2014. The representative/s has/have to

submit an authority letter duly signed by the bidder, authorizing him to represent and attend

the negotiation process on behalf of the bidder. The format of the authorization letter is given

in Annexure-2.

The scope of the services specified under this RFP is governed by the guidelines issued by

RBI on implementation of IRB, IMA, TSA and AMA approaches of Basel- II & Basel III

guidelines and international best practices on ALM and FTP. Any change made by RBI on

these matters by way of amending the existing guidelines or issue of fresh guidelines on these

matters shall automatically enlarge the scope of work specified under this RFP and the duties

of selected bidder shall deemed to be discharged only when the Bank complies with the

revised guidelines issued on this matter.

The Bank expressly stipulates that the selection of bidder under this RFP is on the

understanding that this RFP contains only the principal provisions for the entire assignment

and the services rendered in accordance with the scope of work defined under this RFP are

only a part of the assignment. The bidder shall perform all such tasks, render requisite

services as may be required for successful completion of the project to the satisfaction of the

Bank at no additional cost to the Bank, to attain the underlying objectives for which this RFP

is floated.

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

communicated through the Bank‟s web‐site.

Any bid submitted without payment of Rs. 25,000, being the Bid Submission Fee, shall be

immediately rejected.

The discretion with regard to the procurement of hardware and ALM system lies with the

bank; however the bidder shall be bound to furnish all the particulars related to hardware and

ALM system as specified in this RFP.

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

commission a comprehensive solution in our Bank for implementing an Enterprise-wide

Integrated Risk management Architecture in accordance with the guidelines of RBI/BCBS on

Basel II Advanced Approaches.The proposed solution should cover all the branches/Regional

offices /administrative offices/departments as decided by the Bank and have the capability to

scale up for meeting future requirements.

A. Who can submit the bid?

a. The bid shall be submitted by either an OEM or a SI. The term bidder used in this RFP

refers to the entity who has submitted the bid.

b. One bidder cannot submit more than one bid.


c. The bidder is responsible to carry out the entire end to end implementation of the software

solution as per the scope of work specified in this RFP.

d. If the bidder intends to partner with another entity to complete the entire assignment, he

shall clearly specify in the bid the name of that entity (i.e. OEM/SI) with whom he proposes

to partner. Further the bid should clearly spell out the tasks proposed to be undertaken by the

partner. If any of the functional/technical requirements is achieved with the help of partner,

details of such requirements shall be mentioned in the bid and during the product

demonstration the partner shall display his capability in achieving the aforementioned

requirements. The partner is also required to fulfil the eligibility criteria specified in this

RFP and the bidder is responsible for furnishing the required details necessary to check the

eligibility of partner.

e. The Bank shall enter into separate contract with both parties and these contracts shall

clearly outline the obligations of each party to Bank in course of implementation and

thereafter.

f. One bidder in the capacity of SI can partner with multiple OEMs (for separate modules such

as credit risk, market risk, operational risk, ALM and FTP) to provide EWIRM Solution

through this bid.

g. One OEM vendor cannot act as partner of more than two SI‟s who submit the bid.

h. The Bank intends to procure Perpetual/Permanent Enterprise Licenses with fixed AMC. The

Bank should have the entitlement/ right to use these licenses without any restriction of any

nature and at all geographic locations. The bidder should also ensure that the official &

authentic license definition of software solution is shared with Bank.

i. All the new software release/version / upgrades or otherwise for any reason should be made

available to the Bank and the Bank is not liable to pay / oblige SI or any OEM any

additional charges / fees pertaining to third party royalty charges etc. And also this should

not be the reason to restrict the Bank from upgrading to the new release / new version of the

software.

j. In case when bid is submitted by SI, the OEM should endorse the hardware & related

software sizing, stating that technically their software can be deployed on the proposed

sizing. This can be through declaration or sharing authentic / official benchmark reports.

Chief General Manager



Thrissur


• Number of years in banking business84 Years

• Number of branches800

• Number of ATM‟s936

• Business as on 31.12.2013Rs. 78361 Crore

• Business Growth (Y – to – Y)14.43%

• Last 5 years business CAGR17.15%

• Net Profit for the year ended March 2013Rs.502.27 Crore

• Net Interest Margin (December 2013)3.02 %

• Capital Adequacy Ratio (Basel II –December 2013)12.35%

• Net Non-Performing Assets (December 2013)1.18%

II. ABOUT THE SOUTH INDIAN BANK LIMITED

The South Indian Bank Limited (website- www.southindianBank.com) is one of the leading

Scheduled commercial Banks having 800 branches spread across 29 States/ Union Territories in

India. The Head (Registered) Office of the Bank is situated at Thrissur, Kerala State. There are

Nineteen Regional Offices (ROs), geographically spread across the country, coming under the

administrative control of the Head Office.

The South Indian Bank Limited offers various customer services such as Anywhere-Any Time

Banking supported with online ATMs, Internet Banking, International ATM-Cum-Debit Cards,

Mobile Banking, online payment, on line trading etc. The Bank has already adopted significant

technological advancements and uses them to leverage business operations such as NDS-PDO,

RTGS, NEFT, Domestic ATM sharing, NPS, SWIFT, Treasury, Forex, POS, etc.

The Bank is using „Finacle‟ (from M/s. Infosys Technologies Ltd) as the Core Banking Solution

(CBS).The Bank achieved 100% roll out of Finacle as on March, 31, 2007. The Bank presently

uses Finacle 7.0.25 version and it proposes to upgrade the Core Banking Software to Finacle

version 10 by December 2014. The Bank has setup a robust scalable state-of-the art Wide Area

Network connecting its various branches and offices with its Data Centre. These branches are

connected to datacenter through dual redundant MPLS WAN connectivity.

The South Indian Bank Limited… At A Glance (As on 31.12.2013)


III. BACK GROUND

In terms of RBI guidelines vide circular DBOD.No.BP.BC.90/20.06.001/2006-07 dated April 27,

2007 and subsequent guidelines on the New Capital Adequacy Framework our Bank has adopted

following methods for calculation of Capital Adequacy under BASEL II norms.

Credit Risk Standardized Approach

Market Risk Standardized Measurement Method

Operational Risk Basic Indicator Approach

The Bank is presently using 19 internally developed rating models to measure the credit risk

associated with different exposures. The computation of risk weighted assets for credit risk under

standardized approach is done in Excel sheet after obtaining required information from Finacle

and external rating database. The capital charge for market risk is computed in Excel sheet using

M-Duration function after obtaining data from Treasury software and necessary market

information. The capital charge for operational risk is computed in Excel sheet, in accordance

with formula prescribed by regulator. In short, the computation of CRAR under standardized

approach is being done using MS- Excel and without use of any software solution.

To improve the risk management practices of Indian Banks, RBI has come out with guidelines &

time schedule for migrating to advanced approaches for all the above three risks. Hence we intend

to upgrade our existing risk management systems and processes and implement Enterprise-wide

Integrated Risk Management Solution compliant with the requirements prescribed under the

guidelines issued by RBI/BCBS and international best practices in respect of Basel-II, Basel- III,

ALM and FTP.

We intend to implement an Enterprise-wide Integrated Risk Management Architecture in

accordance with provisions of following circulars/guidelines and international best practices.

1. Master Circular - Prudential Guidelines on Capital Adequacy and Market Discipline - New

Capital Adequacy Framework (NCAF) RBI /2013-14/72 DBOD.No.BP.BC.

9 /21.06.001/2013-14 July 1, 2013

2. Implementation of the Internal Rating Based (IRB) Approaches RBI/2011-12/311

DBOD.No.BP.BC.67/21.06.202/2011-12 dated 22.12.2011 for Credit Risk.

3. Prudential Guidelines on Capital Adequacy - Implementation of Internal Models Approach

RBI/2009-10/384 DBOD.No.BP.BC.86 /21.06.001 (A)/2009-10 dated April 7, 2010 for

Market Risk.

4. Implementation of the Advanced Measurement Approach (AMA) RBI/2010-11/488

DBOD.No.BP.BC.88/21.06.014/2010-11

5. Master Circular – Basel III Capital Regulations RBI/2013-14/70 DBOD.No.BP.BC.2

http://rbi.org.in/scripts/NotificationUser.aspx?Id=3464&Mode=0


/21.06.201/2013-14 dated July 1, 2013.

6. RBI guidelines on Liquidity risk management by Banks RBI No 2012-13/285

DBOD.BP.No.56/21.04.098/ 2012-13 dated November 7, 2012.

7. RBI guidelines on Banks‟ Asset Liability Management Framework – Interest Rate Risk

RBI/2010-11/263 DBOD. No. BP. BC. 59 / 21.04.098/ 2010-11 dated November 4, 2010.

8. RBI Guidelines on stress testing- RBI / 2006-07/ 444

DBOD. No. BP. BC.101 / 21.04.103/ 2006-07 Dt. June, 26, 2007.

9. RBI Guidelines on stress testing- RBI/2013-14/390/ DBOD.BP.BC.No.75//21.04.103/2013-

14 Dated December 2, 2013.

10. Any other relevant guidelines from RBI/BCBS shall be applicable.

The Bank has already taken steps in this direction and appointed an external consultant for

providing assistance for migrating to advanced risk management approaches and for the

implementation of an Enterprise Wide Integrated Risk Management Architecture. This Request

For Proposal (RFP) is intended to invite Techno-Commercial Bids from eligible bidders to

provide end-to-end solution for implementation of Credit Risk Management System (CRMS),

Operational Risk Management System (ORMS), Market Risk Management System (MRMS) and

an Integrated Capital Computation and Reporting Module for the Standardized and Advanced

approaches under RBI Guidelines on Basel II and Basel III to have an integrated risk

management frame work, referred to as EWIRM Solution in this RFP. Bank also plans to

benchmark the ALM and FTP methodology in tune with leading international best

practices/extant RBI guidelines and upgrade our ALM systems for this purpose, if required.

A. Objective of RFP

The Bank has decided to float this RFP to achieve the following objective:

To invite techno-commercial bids from corporate body/ Public or Private Ltd

company/Public sector undertaking/ Partnership Firm/LLP, for undertaking the scope of

work as outlined in Point No:- IV.

To appoint a competent party through an open/hybrid (or combination of both) tendering

process for laying down an Enterprise-wide Integrated Risk Management Architecture

(EWIRM) in accordance with the International Best Practices and Guidelines of

RBI/BCBS on Basel II, Basel- III, ALM and FTP. The EWIRM shall exhaustively

accomplish the scope of work detailed in this RFP.

B. Responsibilities of Bidder:-

Successful bidder selected based on the evaluation criteria specified in this RFP should

1) Implement the solution at all branches, Regional offices and various departments as decided

by the Bank.

2) Implement an EWIRM solution which is capable of:

a. Supporting estimation of all risk components and capital calculations (regulatory &


economic) as per the guidelines issued by RBI and Basel under the Standardized and

advanced approaches of Basel norms.

b. Meeting the Pillar I, II, III and stress testing requirements as per RBI and Basel

guidelines on Basel II and Basel III.

c. Supporting all the required statistical, analytical, risk modelling, pricing and reporting

requirements as per Bank‟s internal requirements.

d. Performing back testing and stress testing

e. Achieving compliance with all RBI guidelines issued on liquidity management/ALM

and FTP.

f. Supporting ALM and FTP in accordance with best international practices

g. Computing LCR and NSFR as per RBI and BCBS guidelines

3) Set up, installation and testing of the required hardware and software within the Bank

including its data centers at Cochin and Disaster Recovery Site at Bangalore.

4) On awarding the contract, the bidder should gain understanding of the functioning of the

existing system from core users of the Bank. He shall prepare a Business requirement

Document based on the gap analysis and other requirements of the RFP. The bidder shall

undertake to obtain Bank‟s approval of the Business requirement documentation (over and

above Functional Requirements Specifications and System requirement Specifications) and

associated project plans before software customization work commences. The document

should provide the plan in detail based on the criticality of the requirements. The bidder

shall allow adequate time for review of the above documents by the Bank.

5) Ensure that the system is in compliance with RBI requirements for all Basel II advanced

approaches and Basel III and other relevant regulatory guidelines. Any instances of non-

compliance observed will need to be rectified at no additional cost and well within timelines

stipulated by the regulator

6) Ensure that software solution being supplied should be capable to get integrated with a Data

Ware housing solution; the Bank may go for later point of time. It needs to have standard

interfacing capabilities.

7) Identify Project Manager, Project Leaders and members of the development teams with

relevant skills. The bidder will intimate the Bank if there is any change in the project team.

The bidder will ensure proper back up of project leaders and manager and the plan should be

intimated to the Bank. The minimum experience of the project team personnel like Project

Manager, Project Leader and Programmers put on work preferably should be 2 years.

Systems study and all development activities will have to be undertaken at the Bank‟s

locations acceptable to Bank.

8) Provide Facilities Management support for EWIRM solution and associated IT

Infrastructure proposed by the bidder for the entire project duration.

9) Ensure that the solution offered should have all components mentioned clearly with its

license requirements

10) Impart training on EWIRM solution to designated personnel of the Bank and handling the

system and trainers.


11) Provide full fledged solution at the end of the mutually agreed period post UAT signoff.

12) Incorporate changes in system arising on impact of amendment to regulations/ Bank‟s

policy at no additional cost and well within timelines stipulated by the regulator.

13) Assist the Bank in conducting the User Acceptance tests by providing test plans, scenarios

and resolving gaps.

14) Provide complete module wise documentation including logic used, empirical analysis done,

methodology etc. as per regulatory and audit requirements.

15) Provide all statutory, regulatory Management Information System (MIS), adhoc MIS

(including development if needed) and Executive Information System (EIS) reports as

required by the Bank in the desired format as per regulatory and Bank‟s requirements.

16) Ensure that the system meets all functional and technical requirements specified in this RFP.

17) In case the product/ solution/ vendor/ OEM/SI are amalgamated/ dissolved the impact of

such an event should not have any adverse implication on the service level/ time line/cost

that is proposed for implementation of the solution. Such event would not dilute the

responsibility of the successful bidder in completing the implementation within mutually

agreed time lines.

18) The bidder shall provide the details of hardware including its indicative cost and its

configuration in the format given in Annexure-12.B. The cost of hardware will form part of

the evaluation process; only if t he Bank chooses to procure the hard ware through

successful bidder. Alternatively the Bank may also procure the hardware specified in

Annexure-12.B on its own. The Bank‟s decision in this regard shall be final.

19) Bidder should install & configure various components of the complete solution. The bidder

shall interface the proposed solution with other external systems in the Bank including Core

Banking (Finacle), Credence/Polaris, HRMS, iRAC, iRecovery, iCDMS, BALM (if

required) etc. The term external system also includes proposed systems such as LOS or other

data capture systems, workflow tools etc which the Bank uses from time to time.

20) Bidder should implement & maintain the application software in Main Data center, Near-by

data center and Disaster Recovery (DR) sites.

21) Bidder should provide Modular wise user manual as well as Administrator‟s manual, post-

implementation on-site support for 3 months from GO LIVE date and further support till the

end of agreed AMC period.

22) Data migration should be done by the bidder from the existing data already collected by the

Bank (available in various source systems) to the new system with consistency. After going

LIVE the incremental data shall be moved onto the Risk Management solutions on a

scheduled manner, bidder to provide necessary interface or tools for the same.

23) Reports for the migration of data as required by the Bank have to be developed and

generated during the migration with all required controls, balances and checks for the proper

migration.

24) The successful bidder shall provide technical support for the software application systems

supplied under this contract, and will have overall responsibility of the performance,

functionality and operation of the systems under this contract. Any supporting software


provided/installed/configured by the bidder shall be maintained /fine tuned/parameterized by

the bidder, time to time, so that the solution delivers optimal performance.

25) Security features should meet the standards and procedures as per Bank‟s IT Security Policy

and procedures should be followed, in line with prevailing Industrial Standards.

26) The bidder to provide the Bank with the proper backup and recovery procedure, with

necessary documents so as to meet any exigencies.

27) The bidder should ensure that all verification processes in the software solutions should be

governed by maker checker controls.

28) The bidder‟s overall responsibility includes offering suitable framework, supporting

software solution, recommending the appropriate hardware, impart necessary training and

supply the required documentations/manual.

29) The bidder shall be also responsible for the following:

Managing the activities of its personnel or sub-contracted personnel and will hold itself

responsible for any misdemeanours.

The Supplier's representative or the local office nearest to Thrissur/Cochin shall be the

contact point for the Bank and all the authentic status of Delivery and Installation should

be made available in writing.

Keep the Bank informed on the progress of the project as per the agreed reporting

schedules.

The bidder and the BANK together will prepare acceptance test plan, for which bidder

will station its officers in the BANK at no additional cost.

Incorporate the review comments received from the users.

Prepare contingency plans.

Customize software at the Bank‟s premises.

Incorporate change management as per mutual agreement.

Help in change management and implementation support at agreed costs, if so desired by

the Bank.

Inform the Bank about IT infrastructure required for implementation.

Treat as confidential all data and information about the Bank, obtained in the execution of

his responsibilities, in strict confidence and shall not reveal such information to any other

party without the prior written approval of the Bank/Purchaser. A non-disclosure

agreement should be signed between Bank and bidder. The format of non-disclosure

agreement form is given in Annexure-3.

IV. SCOPE OF WORK

A. Broad scope

The broad scope of the project envisages:

1. Installation, customization, configuration and maintenance of the software required for an


Enterprise Wide Integrated Risk Management (EWIRM) Solution to achieve compliance

with Basel- II/Basel- III norms. Any other hardware/software which is essential to run

application and not quoted will be supplied and installed at free of cost.

2. Parameterization, historical data management, verifying data quality, migrating data, user

acceptance testing, documentation, knowledge transfer and support

3. Interfacing with other external systems including core Banking software solution, validation

of models and processes and maintenance of application software, system software, database,

interfaces etc

4. Assistance in supply, installation and maintenance of related hardware at Primary, Near-by

and Disaster recovery data centers of the Bank.

5. Providing training to Bank‟s designated personnel and also provide Modular wise user

manual as well as administrator‟s manual, post-implementation on-site support for 3 months

from GO LIVE date and further support till the end of agreed AMC period

6. The solution/s offered should be web based, open platform and support data transfer and

consolidation from the networked systems either online or dial up.

The Project would be implemented at the Head office of the Bank, located at Thrissur, Kerala for

Credit and Operational Risk Management. Requisite modules would need to be rolled out to

Regional Offices, Branch Offices and other Head Office Departments. For Market Risk

Management, project would be implemented at the Banks‟ mid- offices in Treasury, Mumbai and

in International Banking Division (IBD) office at Cochin. Training of all users across various

locations (as necessary), would need to be provided. The hardware and the software products

shall be installed, implemented and maintained at the Banks data center, DICT Cochin and at the

Disaster Recovery Site, Bangalore. Technical support shall be extended from DICT and

functional and operations support shall be from other centres as the Risk Management

Framework demands.

B. Detailed scope

The detailed scope of assistance has been given below

Gap identification & Resolution

i. The selected bidder will be responsible for conducting the gap analysis for identifying

gaps in Bank‟s framework, policies, procedures, governance, and existing systems which

needs to be bridged prior to deployment of EWIRM architecture. The gap analysis should

be done in the context of Basel II, Basel III and other regulatory guidelines issued by

RBI etc. pertaining to Credit Risk Management, Operational Risk Management, Market

Risk Management, ALM & FTP and Integrated Capital Computation and Reporting.

ii. Provide the Bank with the gap identification report along with the recommendations and

estimated time frames to resolve the same.

iii. Provide various tools /utilities to bridge the gaps identified during GAP analysis phase


without any extra cost.

iv. Determine the customization requirements, in case a particular functionality requirement

is not supported by the existing version of the EWRIM solution;

v. Resolve gaps by customizing the proposed solution by way of modifications/

enhancements, as necessary.

vi. Facilitate data migration from the existing data already collected by the Bank to the new

system with consistency. All the details from the migration date till the date of LIVE

should also be migrated from the existing data to the proposed Risk Management

solutions.

Design of solution

i. The selected bidder is required to design the EWIRM Solution with the functionalities

identified in the Functional Requirements and Technical Solution Requirements for

Credit Risk Management, Operational Risk Management, Market Risk Management,

Asset Liability Management, Fund Transfer Pricing and Integrated Capital Computation

and Reporting as detailed in this RFP.

ii. Automated Interfaces required for the solution with other internal systems and external

systems has to be provided by the selected bidder to ensure satisfaction of the functional

and technical requirements. Bidder will be responsible for the procurement of any tool

required to develop the interface. Bidder will document the entire interface logic and

process with change management procedures in compliance with Bank‟s policies and

best international practices.

iii. The selected bidder is expected to leverage the Bank‟s existing data center services,

EDW infrastructure (as and when operational), storage, backup tape libraries, archival,

legacy data etc. With the endeavour to reduce the overall cost of procurement to the

Bank, the bidder shall also continuously explore avenues to reduce the cost and act in the

best interest of the Bank.

Parameterization, Configuration and Customization of software

i. To assist in bridging the identified data gaps for compliance with RBI/BCBS and other

relevant guidelines on integrated risk management framework.

ii. The Bidder shall be responsible for accuracy of the parameters set in the system

according to business needs of the Bank.

iii. The cost of all customizations is required to be included in the Commercial Bid and the

Bank will not make any additional costs for this throughout the term of the contract if the

same has been specified as a requirement of the Bank in this RFP. Thus, this is a fixed

bid and all necessary customizations based on the functional requirements specified in the

RFP will need to be conducted by the Bidder.

iv. Bidder needs to give detailed plan for customization. All customization has to be

completed within the project timelines.


v. The Bidder should ensure that the quality assurance and development standards outlined

in the development methodology of the EWIRM solution are adhered to and required

functionalities/reports related to same are generated and shared with the Bank team on a

regular basis

vi. Enhancements provided by the Bidder would include changes in the software due to

statutory and Regulatory changes and those required due to changes in industry practices

in India and/or abroad or any other requirements of the Bank related to the above, which

will need to be provided at no extra cost to the Bank for the entire period of the contract.

It will include, but not limited to, all the functionalities mentioned in the Functional

Requirements and at no additional costs.

vii. Before completing this phase, the bidder shall ensure that EWIRM solution/ architecture

proposed to be implemented/laid down is capable of meeting all functional and technical

requirements specified in this RFP.

Testing

i. The Bidder will be responsible for conducting system integration testing to verify that all

system elements have been properly integrated and that the system performs all its

functions.

ii. The Bank will conduct a “User Acceptance Test” (“UAT”) under guidance, review and

Supervision of the bidder to ensure that all the functionality required by the Bank as

mentioned in this RFP is available and is functioning accurately as per the expectations of

the Bank. Consequent to UAT, if some of the functionalities, specified in this RFP are not

present in tune with the Bank‟s expectations, the bidder shall make appropriate changes.

iii. Bidder will be responsible for setting and maintaining the test environment during the

entire period of project implementation. The bidder will ensure that test environment‟s

configuration and parameterization for conducting the UAT is in line with bank's risk

management framework and this RFP‟s requirements. The bidder shall ensure that the

test environment has the same configuration and functionalities as that of the production

environment.

iv. The Bidder will provide the scenarios for UAT and assist in preparing test cases

including the test data to support all the Business scenarios. The Bidder should dedicate

resources to work with the Bank‟s project team for this purpose.

v. The Bidder will assist the Bank in analyzing / comparing the results of testing.

vi. Bidder shall provide adequate resources for trouble-shooting during the entire UAT

process of the Bank.

vii. The Bidder will be responsible for maintaining appropriate program change control and

version control of the system as well as documentation of UAT and change of

configuration and parameterization after making changes in the system.

viii. All errors, bugs enhancements/ modifications required during and after testing will be

resolved within the overall timelines for implementation


ix. The Bidder will be responsible for using appropriate tools for logging, managing,

resolving and tracking issues and its progress, arising out of testing and ensuring that all

issues are addressed in a timely manner to the satisfaction of the Bank and as per

requirements mentioned in this RFP.

Training

i. The Bidder shall be responsible for training the employees of the Bank in the areas of

system administration, implementation, use / operations, management, database

management, error handling /troubleshooting, etc. of the EWIRM Solution.

ii. Structure of the training program covering number of trainings, locations and number of

participants etc. is to be advised by the bidder in writing.

iii. Bidder will also be responsible to develop training and reference materials for all the

functionality of the software. Training / reference materials should be designed separately

for operational staff / user, IT department and senior management. Training material

should comprehensively cover all the functionality of the proposed EWIRM solution and

be written in a user friendly manner with use of graphs, processes flows, screen-shots of

the actual system functionality etc.

iv. Bidder should provide Bank specific training material designed considering its

requirements in this RFP. Training material so provided will be subject to review and

sign-off by the Bank as a project deliverable.

v. The training should at least cover the following areas:

• Functionality available in the solution including logic and methodology of the same;

• Customization / Parameterization;

• Techniques for Slicing and dicing of data, information, and output

• Auditing techniques including generation of audit trail reports;

• Advanced trouble shooting techniques;

• Techniques for generation, view and reporting of intermittent results;

• Deployment of various processes, risk reporting and identification procedures,

Application of controls, analysis procedures provided as part of the solution;

• Techniques of Customization, development and configuration of required reports

including ad-hoc reports from the solution provided;

• Development and deployment of new functionalities using the proposed solution;

• System & Application Administration such as creation of user, user groups,

assigning rights, System Information Security Settings etc.

• Perform Impact Analysis using the solution;

• Business use of the solution

• Technical training to be provided to IT staff of the Bank, and this shall include

installation, technical architecture, configuration & setup , customization, report

generation, backup and recovery, trouble shooting, data synchronisation,

file uploads etc.

vi. The successful bidder is responsible for conducting training sessions for officers of risk


management Dept, branches, Treasury Dept, International Banking Division and regional

offices. Notwithstanding what is contained in point no (ii) above, the minimum number

of training sessions shall be decided by the Bank and the successful bidder is bound to

oblige.

vii. As per the requirements defined in this RFP, Bank may increase more areas of trainings

which bidder would be liable to provide, without any additional cost.

Implementation

i. The proposed solution should cover all the existing branches/Regional

offices/administrative offices as decided by the Bank and have the capability to scale up

for meeting future requirements. The solution should be scalable and capable to handle

increased volumes. In the event the Bank adds/changes/updates source/core Banking

systems in the future the solution should be flexible to handle such new source systems.

ii. Computation of regulatory and economic capital requirement for Credit, Market and

Operational Risk under Basel- II and Basel- III

iii. Generation of required reports (to be specified under functional requirements of RFP)

iv. Setting up of User Acceptance Test Environment, Live System and Disaster Recovery

System

v. To assist in obtaining any approvals from regulator or registration with any statutory

Body, if required, regarding the implementation of EWIRMS

vi. The Bidder will have to provide the necessary interface not needing manual intervention

to all the applications as required.

vii. At present, the Bank has various solutions running on both Windows and RISC platforms

with Oracle and SQL Server databases. The solution provided shall be capable to

integrate with these databases directly. Ultimately, the EWIRM Risk Solutions shall be

linked to Enterprise Data Warehouse (as and when operational). The solution should be

able to seamlessly integrate with upcoming Enterprise Data Warehouse and shall function

as a Data Mart to the EDW. The proposed solution should be compatible to the following

platforms i.e. Windows, Unix and Linux with Intel and/or RISC systems.

viii. By means of diagrammatic / pictorial representations, the Bidder should provide

complete details of the hardware, software and network architecture of the EWIRM

Solution (module and sub‐module wise), including source / method of Data capture and

transfer, validation, updating and database maintenance for networked branches. In this

regard the bidder should also provide logical architecture and high level diagram of

hardware/software/network architecture.

ix. The Bidder should assist for implementation in 50 branches/RO /administrative offices

on pilot basis. The Bidder should install and commission the solution and integrate with

the Bank‟s applications at all branches. The branches for pilot implementation would be

decided by the Bank.

x. The system should be implemented in all the remaining units after its satisfactory


working in 50 branches/R.Os/administrative offices and implementation in all the units

should be completed within 12 months from the date of signing of contract.

xi. The Bidder should recommend the operating system, hardware, database, data replication

requirements (at the end of day) along with data replication solution and a required Test

server for EWIRM solution. EWIRM solution comprises of CRMS application software,

ORMS application software, MRMS application software, Integrated Capital

Computation and Reporting module application software and other necessary software

for the successful implementation of the proposed solution.

xii. Firewall & Network Security will be provided by the Bank. The Bidder has to ensure that

vulnerabilities at application level in case of any breach shall be handled by the offered

application software. However the desired requirements of the Firewall and Network

Security should be specified by the bidder.

xiii. The total storage provided/ proposed by the bidder shall take into account incremental

growth of the Bank on a minimum, over the next 10 years. The Bidder may propose an

appropriate storage to meet the requirements as found suitable

xiv. A complete quote for the hardware required for the successful operation 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, bus speed,

etc. and clearly show no single point of failure.

xv. The Bidder should specify the hardware requirement taking into consideration the

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 should provide details for DR site such as network and security

requirements, switches, routers etc.

xvi. The Bidder will certify that the hardware specified is adequate for meeting performance

standards set by the Bank.

xvii. The Bidder must ensure no software, for which „End of Sale‟ has been declared or will be

declared in next 7 years, is offered as part of this bid. None of the software should have

an „End of Support‟ mandated by the respective OEM within seven years from date of

completion of the project and the bidder should ensure continuity at all times without

disruption of operations.

xviii. The Bidder should also recommend 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 specific requirements for the servers /

equipment (Network and security requirements, switches, routers etc.) and associated

infrastructure for both DC (Data Centre) & DR (Disaster Recovery) sites.

xix. 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 Bidder for processing of

existing portfolio of the Bank with increase in volumes at approximately 25% p.a. and

addition of new products/instruments and data maintenance for a minimum period of 7


years as per RBI guidelines.

xx. The Bidder has to give an undertaking to implement the solution at any location / branch

identified by Bank at no extra cost.

xxi. As part of implementation all data migration (as and when required) from the existing

systems to the system proposed will be done by the Bidder. The Bidder shall demonstrate

to the satisfaction of the Bank regarding accuracy and comprehensiveness of the data

migrated to the proposed system.

Facilities Management Services (FMS) and Helpdesk

i. The Bidder is required to provide Helpdesk services till the completion of the

implementation across Bank. Facility Management services will be provided by the

bidder till the end of the project and thereafter. The bidder is required to indicate the

resource requirements for FMS in the Annexure-12.

Facilities Management: Facilities Management would include support for all application

software, provided by the Bidder. Bidder should elaborate on FMS like number of

resources to be deployed post implementation and detail it accordingly in Annexure-12.

FMS services should be provided for entire project duration and thereafter. The resources

for facility management shall be deployed on site till „GO LIVE Date‟ and for the

remaining duration of project the FMS shall be provided from offsite.

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 provided till GO LIVE Date. At any point

of time during the day a minimum of two resources shall be available.

ii. Uninterrupted services of helpdesk shall be available to all the branches through their

respective working hours.

Information Security

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

and controls. System hardening should be done by bidder. Access controls at DB, OS,

and Application levels should be ensured in compliance to the Information Security

Policy of the Bank.

ii. The system should be in compliance with the recommendation of Gopalakrishna

Committee.

V. FUNCTIONAL REQUIREMENTS FOR CREDIT RISK

The Bank aims to migrate to the Internal Ratings based Approaches (IRB) for Credit risk as per

Basel II, Basel III and RBI guidelines. The solution should support estimation of all risk

components and capital calculations (regulatory & economic) as per the guidelines issued by


RBI and Basel under the standardized and IRB approaches. The solution should be able to meet

the Pillar I, II, III and stress testing requirements as per Basel-II / RBI guidelines and Basel-III

guidelines. The solution should be capable of supporting all the required statistical, analytical,

risk modelling, pricing and reporting requirements.

Sl. No Credit risk Functional requirement

A Standardized Approach

1 Bank data to Basel II Data Mapping*

1.1

The system should provide graphical user interfaces (GUI) to map bank data to Basel

II data. The following activities should be supported (but not limited to ):

a. Bank customer types to Basel II customer types

b. Bank product types to Basel II product types

c. Bank security/collateral types to Basel II collateral types

d. Bank asset type/guarantor type to Basel II asset/guarantor type

e. 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.

1.2 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.

*The mapping should be done with respect of both IRB and standardized approaches

2 External credit ratings

2.1 The system should have the ability to map the domestic and international rating to the

corresponding risk weight for all the asset class as specified under RBI Guidelines.

2.2

The system should be able to capture multiple rating details for the

obligors/exposures and risk weight assignment should happen as per RBI Guidelines

(i.e. If two ratings are available then the one with higher risk weight should be used,

and if more than two ratings are available then the lowest of higher two risk weights

should be used).

2.3 The system should support a user configurable interface with which multiple ratings

can be assigned for obligors/exposures.

2.4

The system should capture external rating details such as Rating Agency, Rating,

Type of Rating (Long or Short Term, Issue or Issuer Rating), and Rating Date etc.

from the Credit rating Software. Based on this information, the system should

determine the eligibility of external rating for use in capital computations based on

the rules specified in the RBI guidelines.If external rating details are not present in

CRS, the system should permit the direct keying in of data.

3 Credit Risk Mitigation

3.1

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

3.2 Provide a GUI to define the hair cuts for various collateral types as defined in RBI

guidelines.

3.3

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.4 The system should have the ability to assign the risk weights for Guarantors as per

RBI Guidelines.

3.5

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.6

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.

3.7 The system should be able to perform on balance sheet netting and capital calculation

based on the net credit exposure

3.8 The system should be able to apply haircut scaling formula (based on holding period

and frequency of /revaluation period) as prescribed by RBI Guidelines.

3.9 The system should be able to capture guarantee, counter guarantee and credit

derivative details

3.10

The system should have the ability to perform optimal allocation of collateral when

one or more collateral/guarantee is mapped to multiple exposure (many to many

relationship). The user should be able to view and modify the objective equation and

the constraints

4 CRAR computation

4.1 The system should have a user interface to capture the minimum Capital to Risk

Weighted Assets Ratio (CRAR) prescribed by the RBI.

4.2

The system should be able to capture and classify the regulatory retail exposures

based on the qualifying criteria's such as Granularity, Orientation, Product and Low

Value of Exposure

4.3 The system should be able to capture the aggregate exposure for Corporate, and the

risk weight should be assigned as per RBI Guidelines

4.4

The system should provide GUI based screens to define the capital computation rules

for the following areas based on RBI guidelines:

Corporate, Banks, Domestic Sovereigns, Foreign Sovereigns, Public sector entities,

Multilateral development banks, BIS, IMF, Indian Banks, Foreign Banks, Primary

dealers, Corporate, Retail (Regulatory Retail, Home Loans, Consumer loans),

Commercial Real estate, NPA, Venture Capital, Other assets, Off-balance sheet assets

and any other asset classification which RBI may come up from time to time

Assign Credit Conversion Factor's(CCF's) for off-balance sheet items, undrawn

portion of revolving loans as per RBI Guidelines

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 RBI Guidelines

4.5 The system should compute CRAR under standardized approach

4.6

The system should compute and report the gross exposure, value of risk mitigants, net

exposure, risk weight and minimum capital charge under Basel-II/Basel- III for each

account.

4.7 The system should report the risk weighted assets and capital charge under each asset

category as defined in Basel- II norms and at account level.


B. IRB Approach

1 Internal Rating System (applicable to all types of credit and investment

exposures)

1.1 The proposed software solution should have flexible user interface, capable of

interfacing with existing and future credit rating systems of the bank

1.2 The proposed software solution should provide a statistical package / tool for credit

risk Model Development and Validation.

1.3 The proposed software solution should have flexibility to add any number of rating

models and scorecards in future.

1.4 The system should have capability and statistical tools to create expert judgment,

statistical and hybrid type of rating models/ score cards.

1.5 The solution should fulfil requirements of Working Paper 14 of BCBS document for

the validation of the rating systems.

1.6

The model validation solution should be able to perform validation of:

Internal rating system for various portfolios

Scoring models and Probability of Default („PD‟) models (retail, corporates,

sovereign,equity and banks)

Loss Given Default („LGD‟) models (retail, corporates, sovereign and banks)

Exposure at Default („EAD‟) models (retail, corporates, sovereign and banks)

1.7 The system should have capability to generate reports pertaining to any kind of model

development and/or validation of rating models

1.8 The system should be able to compute PD, LGD, CCF, M and capital calculations for

the relevant asset classes as per FIRB and AIRB approach as per Basel II Guidelines.

1.9 The system should be capable of computing PD for each borrower rating grade, LGD

for each facility rating grade and EAD for each facility in case of corporate

1.10

System should support the PD modelling methods for corporate exposures, including

but not limited to the following methods:-

• Historical data based

• External rating mapping approach (in case of large corporate)

• Statistical PD model based approach (in case of SME)

1.11

The system should support statistical modelling to enable the users to develop and

deploy their own models for risk parameter estimation. The following statistical

modelling features should be supported (at minimum):

• Sampling techniques (Simple, stratified, random etc)

• Missing value imputation

• Outlier detection and elimination

• Variable transformation

• Regression modelling (Simple, Multiple, Logit, probit, GLM, GLMM etc)

2 Corporate, Sovereign and Bank Asset Class Models

2.1

System should have ability to track and store account-wise /customer-wise previous

credit ratings/ scores and LGD. The system should also capture date of rating, type of

rating, rating model and other related information.

2.2

System should 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.


2.3

System should have a capability to take data related to balance sheet, profit & loss

and cash flow statements from pre‐defined Excel sheets and other data formats (viz.

.txt, .XBRL, .CSV, .XML)

2.4

The system should be able to capture and receive the required data (Data entry, File

uploads, direct transfers, batch processes, etc) from various source systems like Core

Banking Solutions, Internal Rating models in various formats (viz. .txt, .XBRL, .CSV,

.XML, excel, PDF etc) and capital calculations (for all asset classes) as per RBI

Guidelines under Standardized Approach, FIRB, AIRB and all other asset class

specific approaches of Basel-II/ RBI.

2.5

The solution should have the ability to map the internal risk grades of the specialized

lending subclasses (PF, OF, CF, IPRE and HVCRE) to supervisory categories as per

Basel-II guidelines.

2.6

The solution should be able to support validation techniques, including statistical

tools, for the non retail rating models as per the requirements of working paper 14 of

Basel Committee on Banking Supervision (May 2005) or any modification thereof

and generate reports for the same for management oversight and effective portfolio

management. The system should have the tools to validate credit rating models on

continuous basis. Validation process should enable the Bank to assess the

performance of internal rating and risk estimation methods consistently and

meaningfully. The validation process should help the Bank to meet regulatory

requirements of RBI.

3 Retail Rating Models

3.1

System should have a capability to develop expert defined models/ scorecards,

statistically developed models/score cards and hybrid models and provide application

and behavioural scorecards. The solution should enable the users to input the required

details for application scorecard and compute the application score.

3.2

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. The system should form

Homogenous pools of retail exposures formed in consultation with the Bank in

compliance with IRB guidelines. The system should have capability to integrate

subsequent changes in Pooling criteria.

3.3

System should have a capability to compute behavioral score for the retail products as

a whole on a periodic basis. The solution should be capable to interface with multiple

data source systems (such as CBS, FTP) and fetch the required behavioral data and

compute behavioural score of each retail borrower.

3.4

The system should have a capability to generate reports and demonstrate that retail

pooling models and methodology are compliant with the minimum requirement of

IRB Approaches as per RBI guidelines.

3.5

The solution should be able to validate the retail score card/retail pooling models as

per the requirements of working paper 14 of Basel Committee on Banking

Supervision (May 2005) or any modification thereof and generate reports for the same

for management oversight and effective portfolio management.

The system should be able to compute and validate PD, EAD and LGD for each pool.

The system should provide methodology and tools to validate retail pooling/score

card models on continuous basis.( Validation process should enable the Bank to


assess the performance of retail pools, risk estimates and risk estimation methods

consistently and meaningfully. The validation process should help the Bank to meet

regulatory requirements of RBI. The vendor should help bank to get it validated

through independent third parties. By independent third parties, we mean parties

unrelated to vendor (not related parties/ subsidiaries, JVs etc) with satisfactory track

record and past experience in this field. In this regard, vendor should give the bank a

list of independent third parties acceptable to the bank and bank will retain the option

to choose the validation carrying company.)

3.6 The system should be capable to capture and receive relevant data from Rating

systems, CBS system etc without manual intervention.

4 Capital Computation

4.1 The system should separately compute RWA under FIRB/AIRB. The solution should

support Multiple Approaches and Multiple Jurisdictions, simultaneously, if required.

4.2

The solution should support categorization of asset classes and sub classes as defined

as per IRB approaches as given in the Basel II Accord / RBI guidelines (Corporate,

Sovereign, Bank, SME, SL classes, Retail, QRRE, equity, purchased receivables,

securitized etc.). The system should be capable of computing bank wide and asset

class wise (including sub-categories like product-wise, specialized lending, SME,

vertical wise etc) RWA, EL, UL and Capital (regulatory & economic)

4.3 The solution should provide the ability to estimates Probability of Default (PD)/long

run PDs using internal rating grades and default history across all exposure types.

4.4 The solution should be capable for computing PD based on Internal loss history,

External rating based, Statistical based approaches as described in the Basel II accord

4.5 The solution should be capable of computing Through-the-cycle PD and Point-in-time

PD. The system should be capable to convert a PIT PD to TTC PD and vice versa.

4.6 The solution should support estimation of PD for low default and low data portfolios.

4.7

The solution should support both the Foundation as well as Advanced approaches for

collection of LGD data components and estimation of facility wise Loss Given

Default (LGD) –both economic LGD and accounting LGD- across all exposure types

(On and Off Balance sheet exposures), both for defaulted/ restructured accounts. The

system should be capable of computing LGD using market based LGD, implied LGD

and work-out method as per the nature, applicability and data availability of credit

risk exposures. Further, the system should be able to drill down the LGD estimation

into industry wise, vertical wise, product wise, workout method wise, year

wise/quarter wise/Other frequencies/, collateral-wise and offer additional drilldown

options and reports. It should also support analytics for estimating PD & LGD

correlation.

4.8 The solution should distinguish between senior and subordinated facilities allocating

required LGD to unsecured portion of the facility.

4.9 The solution should provide for EAD and Effective Maturity (M) calculation for both

on and off balance sheet items.

4.10

The solution should be able to capture all types of risk mitigation inputs and should

have the ability to reclassify/categorize the bank‟s risk mitigation tools into Basel

defined risk mitigation inputs types as per Basel II Guidelines/ RBI guidelines. The

solution should be able to allocate different collaterals to different facilities using

multiple algorithms, approaches (Simple, comprehensive, FIRB, AIRB) and Basel-II

guidelines by RBI. The solution should be able to use double default methodology for


capital computation.

4.11

The system should compute and report the gross exposure, value of risk mitigants, net

exposure, PD, LGD, EAD and minimum capital charge under IRB approach of

Basel-II/Basel- III for each account

5 Bank data to Basel II Asset Class Mapping

5.1

In addition to 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. The system

should allow user to compute value of eligible IRB collaterals (viz. minimum -

collateralization or over - collateralization or under -collateralization).

5.2

The solution should have the ability to compute, make estimates, and apply haircuts

on collaterals and exposures as per Basel-II accord/ RBI guidelines on IRB approach.

The system should be capable of applying a weighted average of haircut if the

collateral is basket of assets.

5.3 The solution should make adjustments for different holding periods based on the

quality of collaterals and non-daily mark to market or re-margining.

5.4 The solution should provide for effective LGD where the Bank is having other

financial/AIRB collaterals and pool of collaterals.

5.5

The solution should provide exposure adjustment by segmenting it into portions

covered by different collateral and guarantee types and portion remaining unsecured

as per Basel-II/ RBI guidelines.

5.6 The solution should provide necessary treatment for repo style transactions/

guarantees/ credit derivatives under both foundation as well as advanced approaches.

5.7 The solution should be able to generate PD, EAD, LGD for sub-portfolio like

industry, sector, Geography etc.

5.8 The system should be able to compute Downturn default weighted LGD/ as well as

per RBI/ Basel guidelines.

5.9

The solution should support development of multiple PD, LGD & EAD models and

should enable for validation. The bidder should help bank to get these models

validated through independent third parties. In this regard, vendor should give the

bank a list of independent third parties acceptable to the bank and bank will retain the

option to choose the validation carrying company. Once the bank chooses the

validation carrying company, the vendor has to cooperate with the validation carrying

company and get the validation done. By independent third parties, Bank means

parties unrelated to vendor (not related parties/ subsidiaries, JVs etc) with satisfactory

track record and past experience in this field.

5.10 The system should provide statistical tools such as, HHI Index, Gini co-efficient,

Cumulative Accuracy profile, Receiver Operating Characteristic (ROC), etc.

5.11 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.

5.12 System should generate transition matrix for multiple period. Transition matrix should

be generated for asset classes, industry/region/country/product/business segment etc

5.13

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 definition of pooling logic should be


through a graphical user interface and should not require any programming or vendor

assistance. The system should have the capability to validate retail pools and generate

reports (as per the requirements of working paper 14 of Basel Committee on Banking

Supervision or any modification thereof).

5.14 System should generate correlation matrix for industries, ratings, zones, facility etc.

5.15 The system should have the provision to run FIRB/ AIRB approach for certain asset

classes and Standardized approach for other asset classes in the same execution.

5.16 The system should be able to store data for minimum seven years across all asset

classes, which in turn can be used for modeling the IRB risk components.

5.17 The system should be able to store minimum seven years of data for PD, LGD and

EAD modeling.

5.18 The system should be able to store the data for at least seven years at an

account/transaction level to perform the pooling process.

5.19 The system should have the ability to assign/map new exposures into the created

pools.

5.20 The system should generate reports to monitor/track pool stability and accuracy.

5.21 The system should be able to perform firm-size adjustment for small and medium size

entities.

5.22 The system should be able to apply double default treatment for the hedged portion

and guaranteed portion and compute capital requirement for double default.

5.23

In case of maturity mismatch for double default transactions and other transactions,

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.

5.24

The system should be able to perform capital calculation for equity exposures via the

following approaches:

• Market Based Approach

• Simple risk weight method

• Internal Models Method

• PD/LGD Based Approach

5.25

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.

5.26 The system should be able to support an interface with Treasury systems from where

the VaR numbers can be fetched.

5.27 The system should be able to calculate capital charges for default and dilution risk for

purchase receivables (corporate and retail exposures).

5.28

The solution should provide methodology for computation of Expected Loss (EL) and

Unexpected Losses (UL), RWAs for Credit risk under both foundation as well as

advanced approaches.

5.29 The solution should provide calculation of best estimate of Expected Loss; compute

RWA, capital for defaulted/NPA exposures as per RBI/ Basel IRB approaches.

5.30

For Default risk, the system should be able to apply Top-down Approach or Bottom

up Approach for both corporate and retail exposures (purchase – receivable asset class

wise). Also based on the exposure type, the system should be able to apply retail or

corporate risk weight functions to arrive at the default risk weight.


5.31 The system should be able to calculate capital for Traditional and Synthetic

Securitization exposures.

5.32

The system should be able to capture the bank‟s role (e.g. Originator, investor etc) for

the securitization exposures, various credit enhancements and should calculate the

capital as per Basel II Guidelines.

5.33 The system should have CCF's models and calculate capital for securitization

exposures with early amortization features.

5.34 The system should be able to apply the supervisory formula for capital calculation of

Securitized Exposures as per Basel II / RBI Guidelines.

5.35

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.

5.36 The system should be able to perform Stress testing and Back testing, which will

allow Justification of the capital computation for all the asset classes.

5.37

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

• Bank specific scenarios

5.38 System should be able to generate alerts for initiating management action in case of

stress situation.

5.39 Bidder should independently develop and validate the required models for PD, LGD,

EAD, CCF and Maturity for on and off-balance sheet exposures.

5.40 For estimation of EAD & CCF, it should also do undrawn analysis, UGD analysis etc

and generate reports.

5.41

The system should be able to define portfolio based upon the following aggregation

possibilities such as:

• Counter-party or combination of counter parties

• Industry

• Tenor

• Product

• Geography

• Issuer

• Credit rating

• Any internal hierarchy

And should allow drill down capabilities up to transaction level.

5.42

The system should be able to perform portfolio analysis by fixing and measuring

exposures and limits inclusive of correlation effects within portfolio parameters. This

should be in line with the Basel /RBI guidelines on correlation measurement such as

Default/Asset Price correlation.

6 Reporting

6.1 The system should be capable of generating various Bank- defined reports like:

(System should have the capability to generate back dated reports)


• Borrower Information report

6.2 • Industry Analysis report

6.3 • Monitoring (Account-wise report to cover rating transition & trend in critical

identified parameters)

6.4 • Peer group Analysis report

6.5 • Rating wise reports

6.6 • Portfolio reports

6.7 • Borrower-wise risk score report

6.8 • Borrower-wise risk grade report

6.9 • Borrower-wise year wise risk score report

6.10 • Borrower-wise year wise risk grade report

6.11 • Industry Concentration Report

6.12 • Industry- wise risk score report

6.13 • Industry- wise risk grade report

6.14 • Region wise Concentration Report

6.15 • Region wise risk score report

6.16 • Region - wise risk grade report

6.17 • Quick mortality Report

6.18 • Defaulted Account Report (Grade wise/ Industry wise/ year wise/ ownership wise/

size wise/ on-balance sheet/ off-balance sheet exposure wise for a date range etc)

6.19 • RAROC reports- vertical wise, geography wise, rating grade wise etc.

6.20 • Capital Charge-credit risk (Regulatory and economic) – expected and unexpected

losses

6.21

Exposure Reports:- Such reports generally include

The break up of total exposure based on Sector, industry, credit rating, Client, Loan

Size, Maturity, country, currency, on-balance sheet off-balance sheet exposure,

interest rate wise, floating rate wise, internal and external benchmark, fixed rate wise

etc.

6.22

The report giving NPA position separately under each of abovementioned categories

along with reports on accounts which have been upgraded from NPA and which have

slipped to NPA from standard,

6.23

The report showing position of restructured accounts under each of abovementioned

categories along with reports on accounts which have been upgraded from

restructured and which have slipped to NPA from restructured status etc

6.24

Report on restructured exposures, repeated restructured accounts and drill down

options like industry-wise, rating-grade wise, curing-wise, tenor wise, sacrifice wise,

product-wise, vertical-wise, region-wise, branch-wise, asset class-wise.

6.25

The reports should be able to cut across asset classes and give combined reports, if

needed, while analyzing industry-wise, product-wise, sector-wise reports (e.g.:

exposure to cement industry report should combined and render a consolidated report

on all exposures under various asset classes)

6.26

Collateral Reports (Collateral wise exposure report (total exposure after netting that

is covered by 1. eligible financial collateral 2. other eligible AIRB collateral 3.

guarantees etc). including current market value of collateral wherever applicable as

per policy of the Bank


6.27

Exception reporting:

• System should provide ability to monitor post facto limit exceptions, System

should be generate a list of accounts which are due for rating (i.e pending list of

accounts which are not rated in accordance with Bank‟s policy)

• System should be able to track and indicate loans contract expiring but still

unsettled

• System should be able to track exceptions for loans in which collateral coverage

falls below the required level

• System should be able to track exceptions for exposure exceeding the limit at

facility level

• System should be able to track exceptions for overdue for e.g. overdue for

principal, interest amount etc

• System should support tracking and breach generation of loans pending for

renewal

7 Collateral Management

7.1

The solution should have facilities for extracting, displaying and exporting the

following details, but not limited to, from the source systems (or enterprise data

warehouse as and when functional) vide user defined reports or system triggered

alerts

Collateral and Guarantor details

• Nature/description of collateral securities

• Data points to enable classification of collateral in to IRB eligible collateral as per:

• regulatory considerations along with classification outcome

• Collateral(s) and the list of related facilities

• Legal relationship between collateral provider and borrower

• Personal / Corporate guarantor information including means/net worth of

guarantor

7.2

Collateral Valuation

Valuation details including date of valuation, name of valuer, next valuation due

date, frequency of valuation based on type of collateral and margin details

7.3

Guarantees accepted /credit default swaps purchased by the Bank:

• Data points to assess eligibility of the same as means of credit protection along

with existing status of eligibility for capital relief under IRB regulatory guidelines

prescribed.

• Details of the guarantee taken as part of the loan including comprehensive details

of the guarantor(s).

• Value of the guarantee/CDS including the % of facility covered and exclusions in

guarantee/CDS agreement.

• Linkage between the guarantees and its facilities.

7.4

Collateral documentation and storage:

• Details of documents to be collected as per the legal opinion, name of the

empanelled lawyer providing opinion, etc. along with details of those already

collected- list of documents to be given by Legal Dept

• Details of the legal documents actually collected for each product type.

• Storage/despatch details of the documents of title to securities.

• Work flow Status for monitoring of the movement of the security documents from


the storage till the final release to the customer.

7.5

Legal aspects of collateral:

• Details of legal documentation collected pertaining to the facility including

deviations if any.

• Information from external sources like Ministry of Corporate Affairs, central

registry of properties.

7.6

Insurance:

• Details of the security- insurance company, validity of the policy, exclusions from

the policy, insured amount etc.

• Providing alerts when insurance pertaining to a collateral falls due for expiry

7.7 Expiry reports on collateral (Due for expiry/expired)- bank/region/branch/account

wise

7.8

Others:

• Details for treatment of pools of collateral, maturity and currency mismatches.

• Details of the actual realisation value during sale/auction of securities when they

are classified as NPA.

• Associated costs related to sale and recovery such as but not limited to legal costs,

administrative costs, haircuts and other disposal costs and related time for

completing sale of assets

8 Credit Risk Stress Testing and Event Identification

8.1

The system should have the capability to create, edit and maintain a scenario library

containing both bank-wide and business unit specific scenarios with assumptions,

portfolios and considered exclusion etc.

8.2

The system should have the ability to execute stress tests at a portfolio (or exposures

at a bank level) or a sub-portfolio or transaction level and should provide ability to

capture supporting information such as:

• Scenario description and key assumptions.

• Macroeconomic and industry specific data for specific stress testing themes based

on particular business groups and pre-defined scenarios.

8.3

The system should have the following capabilities with respect to the requirements

for Stress Testing:

• The system should have the ability to set triggers for industries based on

predetermined thresholds for Key Risk Indicators (KRIs) to alert the IRMD for

initiating stress tests.

• The system should have the capability to link the primary industries with the

identified ancillary or second-order industries based on correlations.

8.4

The credit risk stress testing module should support quantifying the impact of stress

scenarios on the following performance measures at the Bank level and for sub

portfolios (e.g. Corporate loans, Treasury Portfolios, etc.):

• Expected loss;

• Provisions on defaulted exposures;

• Unexpected loss;

• Risk weighted assets;

• Profitability;

• Growth in Non-Performing Assets on selected portfolios

• Growth Rates of the bank across Core Industries


• Total Income of the Bank

• Economic capital; and

• Capital Ratios (e.g. CRAR)

• Other parameters as decided by the bank

8.5

The system should support facility by facility and/or higher level portfolio or

geography level stress testing to exposures and credit risk parameters, as part of

overall stress testing scenario.

8.6 System should capture the management action recommended for the scenarios based

on the severity of the results of the scenarios.

8.7

The system should provide ability to compare the following measures for base and

stressed conditions: exposures, credit risk parameters and resulting capital and loss

estimates.

8.8 System should provide ability to apply stress test scenarios for the current as well as

simulated portfolios of the Bank.

8.9 The system should be capable of performing/supporting reverse stress testing

including linking potential scenarios to targeted capital or tail losses

8.10 System should have the ability to connect with authentic external sources to extract

information on economic factors, industry trends etc.

8.11

Based on extraction of data, the solution should be able to:

• Aggregate credit exposure and credit equivalents for non-funded products

including derivatives and other market based product exposures based on rules.

Maintain different rules for credit exposure aggregation for different purposes (for

e.g. regulatory capital purposes vs. economic capital calculations) and utilisation

visà- vis risk based limits.

• Ability to measure and distinguish direct, indirect and contingent exposure for

various portfolios and sub portfolios (e.g. borrower, borrower groups, industry,

country, product group, geographical clusters etc).

• Ability to aggregate and consolidate credit exposures across domestic and

international locations as per prudential norms set out by the regulator(s).

9 Model Validation capabilities

9.1

Solution should contain statistical package to support model validation tests and PD

validation tests such as:

• Discriminatory power test

• Frequency and cumulative distribution graphs for both defaulters and non-

defaulters Cumulative Accuracy Profile (CAP) and its summary index, the Accuracy

Ratio (AR) Receiver Operating Characteristic (ROC) or the Area Under Curve

(AUC) and its summary indices.

• the Gini

• KS Statistic

• Pairwise correlations

• Expert ranking correlation

• Kendall‟s τ and Somers‟ D (benchmarking)

• Brier Score

• Calibration accuracy test

• Observed default rates compared to PDs for overall portfolio and at each rating

grade.


• Binomial test

• Chi-square test

• Normal test

• Traffic lights approach

• Observed migration compared to projected migrations

• Stability analysis

• Population Stability Index (PSI)

• Rating migration matrix to illustrate rating stability

• Granularity

• Herfindahl Index (HHI)

• Concentration per rating over time

9.2

Solution should contain statistical package to support LGD model validation. The

techniques supported shall include but are not limited to:

• Discriminatory Power

• Frequency and cumulative distribution graphs for observed and actual losses per

LGD bucket (or percentile).

• Proxy Gini measure

• Pair-wise correlations

• Calibration

• Observed loss rates compared to average predicted LGD for the overall portfolio

and per loss bucket (or percentile)

• Applying ordinary least squares to fit the best linear regression, compare the

observed versus the predicted LGD

• R-squared, Correlation Observed versus predicted: recovery rate, cure rate,

collateral values post default,time to default, recovery costs

• Stability

• LGD migration between buckets (or percentiles)

• Population stability index of: Key risk drivers including recoveries, collateral

values (pre and post default), recovery cost, cure rate and time to default and Overall

output

• Granularity

• Herfindahl index

• Concentration per LGD bucket (or percentile) over time

9.3

Solution should contain statistical package to support EAD model validation. The

techniques supported shall include but are not limited to:

• Discriminatory Power

• Frequency and cumulative distribution graphs for observed and actual EADs.

• Calibration Accuracy

• Test if the average observed EAD equals the average predicted EAD

• Applying ordinary least squares to fit the best linear regression, compare the

observed versus the predicted EAD

• R-squared, Correlation

• Stability

• EAD migration between buckets (or percentiles)

• Population stability index of overall EAD outputs


9.4

The solution should include/support corporate and macro-economic variables

included in the pre-defined mart, allowing their use in models namely Altmans Z

through variables definitions and Pluto-Tasche method for LDP‟s

10 Credit Risk based Pricing

10.1

The system should support enable computation of Risk based Pricing as per the

methodology defined linking it to the Rating grades and the PD bands separately for

retail and corporate accounts.

10.2

The system should be able to aggregate cost of funds, operating expenses, cost of

capital and other costs, spread and risk premium as calculated using PD and

assumed LGD values.

10.3

The system should embed standard pricing calculations and policies into the loan

origination workflow, and understand the impact of each deal on the shareholder

value.

10.4

System should allow monitoring of deals that have been approved by the business

below the hurdle rate defined by the bank. This should include details such as reason

for override, amount of override, approver, relationship manager etc., along with

complete documentation on workflows and pricing calculations to assist in

improvement of the pricing process.

10.5

System should capture audit trails to satisfy regulatory requirements that the risks

inherent in loan products and services have been adequately accounted for in the

pricing of loans.

10.6

System should have adequate controls to ensure that loan pricing practices comply

with bank policies and strategy including authorization and also facilitate adequate

reporting to appropriate levels of all exceptions.

10.7

The tools for arriving at RAROC and Risk based pricing basis Regulatory and

economic capital to include all relevant relationship components (revenues and

expenses) and also carry capability to depict future profitability/returns

10.8

The comparison of pricing for different customer views e.g. industry, product,

geography, business unit, related MIS and reporting on the corporate portfolio

should be enabled at the Head office level

10.9

The system should enable branch / Relationship managers to price deals, offer,

alternatively deal structures, and respond to customer requests by direct input of

necessary details.

10.10 The system should calculate a price based on a target performance metric and

recalculate performance if a price override is granted

10.11

System should provide complete flexibility and control. It should pull in data from

third-party systems and internally built tools, as well as adjust the data to create a

differentiated pricing approach. It shall also retain audit trail

10.12

The system should have the flexibility to compute Risk-Based Capital (Capital at

Risk or Economic Capital) calculations based on aggregation of:

• Value at Risk

• Expected and unexpected losses from exposure, default rates and recoveries

10.13

Calculation of Risk Adjusted Return on Capital (RAROC) based on regulatory

capital as well as economic capital. The system should be able to calculate capital

requirement individual account wise and also units-wise such as:

• Entire Bank


• Region/zone

• Geography

• Industry

• Business segments

• Products

• Rating wise

• Branch

• Relationship Manager – Branch Manager/Field Functionary

10.14

• The system should be able to compute RAROC and SVA 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 ,

etc )

• The system should be able to interface with FTP system to fetch the cost of funds.

• 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

10.15

The system should be able to provide risk adjusted performance evaluation. The

evaluation should be across Business Units, portfolios and sub-portfolios. The

system should allow the user to incorporate further evaluation subjects.

The system should allow for input of expert judgement into the performance

evaluation system

10.17

The system should have the pre-built templates and should also have the

functionality for a business user to define and customize Credit Risk MIS across all

matrix dimensions such as:

• Counter-party

• Portfolio

• Product

• Geography – country/ state/zone/branch

• Industry

• Concentrations

• Risk Profiles

10.18

The solution should be able to generate Risk Profile Template as per RBI guidelines

and other branch-wise risk profile templates for credit risk as per Bank‟s internal

requirements.

11 Limit Setting and Approval

11.1

Provide capability to identify portfolios based on risk profile aggregation along with

ability to define and determine portfolio limits (across various dimensions e.g.

industry, sector, rating group) based on risk based approach (e.g. internal rating

scale)

11.2 Be able to develop and support optimization models (e.g. Hill Climbing Algorithms)

to determine credit limits.

11.3

Provide workflow mechanism to manage a rule-based limit approval process.

Ability to configure multiple approval workflows depending on business lines,

products and other considerations.

11.4 Maintain complete audit trail of the changes made with respect to change/approval

of limits.


11.5

Incorporate the effects of netting agreements, collateral and credit risk transfer

mechanisms (Credit Default Swap (CDS) and guarantees) while computing portfolio

risk for the bank.

11.6 Provide ability to calculate credit P/L for the portfolios considering default /

nodefault and rating-transitions.

11.7

Provide ability to compute credit portfolio metrics including Expected Loss (EL),

Unexpected Loss (UL), Credit VaR (CVaR) and Expected Shortfall (ES) on

marginal and standalone basis for various portfolios and sub portfolios.

11.8 Have capability to capture inputs of bank strategy across parameters such as growth

in exposure to specific sectors, regions, products etc.

11.9 Periodic alerts to users when limit is due for review

12 Exposure Calculation, Aggregation and Concentration Risk

12.1

Non-Fund Based Market Related Off balance sheet items

The system should be able to estimate exposure for different purposes:

Regulatory Capital calculations

Economic Capital Calculations

Credit Risk Control purposes (e.g. Limit setting, Concentration monitoring)

12.2

System should be able to determine Mark to Market (MTM) or replacement value

using full-revaluation approach for the following set of indicative products:

Derivative products – FRAs, Interest Rate Swaps, Cross Currency Swaps, FX

forward, and FX options;

Equities;

Mutual Fund units;

Corporate Bonds, Government Securities, Hybrid Securities;

Structured notes (e.g. CLNs, CDOs); and

Money market products – Commercial papers, Commercial deposits, repos, reverse

repos

12.3

System should provide ability to determine Potential Future Exposure (PFE) for off

balance sheet items including derivatives and other non-fund based banking

products for normal market conditions and stress market conditions. The system

should be able to compute the credit equivalent using current credit exposure

method.

12.4

System should be able to determine Potential Future Exposure using different

approaches:

Monte-Carlo simulation based approach.

Credit Conversion Factor (CCF) based approach (MTM + Add-on approach).

Any other relevant advanced methods that are widely in use Internationally

12.5 System should provide ability to compute Credit Value Adjustment (CVA) as

prescribed by RBI in Basel-III guidelines.

12.6 System should provide ability to compute CVA on marginal basis and standalone

basis at trade level and portfolio levels

12.7

Non Fund Based Non Market Related

The system should be able to estimate exposure for different purposes through CCF

estimation:

Regulatory Capital calculations

Economic Capital Calculations


Credit Risk Control purposes (e.g. Limit setting, Concentration monitoring)

12.8

Based on extraction of data, the solution should be able to:

Aggregate credit exposure and credit equivalents for non-funded products including

derivatives and other market based product exposures based on rules

12.9

Ability to measure and distinguish direct, indirect and contingent exposure for

various portfolios and sub portfolios (e.g. borrower, borrower groups, industry,

country, product group).

12.10

Maintain different rules for credit exposure aggregation for different purposes (for

e.g. regulatory capital purposes vs. economic capital calculations) and utilisation

visà- vis risk based limits.

12.11 Ability to aggregate and consolidate credit exposures across domestic and

international locations as per prudential norms set out by the regulator(s).

12.12

The system should be able to Support measurement of concentration risk across

different categories of exposures, for e.g. Top 20 single borrowers, Top 10 group

borrowers, Top 20 depositors etc

12.13 Model risk correlations among different borrowers /sectors /industries, etc. and

factor it in concentration risk management

12.14 Measure concentration risk using different measures, for e.g. Lorenz Curve,

Herfindahl-Hirschman Index (HHI), Gini coefficient.

12.15 Measure diversification benefit on a dynamic basis for the bank on a standalone and

consolidated basis

12.16 Integration with loan proposal and review systems for monitoring concentration

prior to sanction.

12.17 Provide workflow for approval of limit breaches with adequate audit trails.

12.18 Provide alerts on dynamic basis before exposure is sanctioned to identify breaches

VI. FUNCTIONAL REQUIREMENTS FOR OPERATIONAL RISK

The Bank aims to migrate to the Advanced Measurement Approaches (AMA) for operational

risk as per Basel II, Basel III and RBI guidelines. The solution should support estimation of all

risk components and capital calculations (regulatory & economic) as per the guidelines issued by

RBI and Basel under the Basic Indicator, The Standardized and Advanced measurement

approaches. The solution should be able to meet the Pillar I, II, III and stress testing requirements

as per Basel-II / RBI guidelines and Basel-III guidelines. The solution should be capable of

supporting all the required statistical, analytical, risk modelling and reporting requirements.

Sl No: Operational Risk Functional Requirements

1 Risk & Control Self Assessment (RCSA) as per RBI guidelines

1.1 The system should have the features to upload, plan and facilitate, track and report

the risk and control self assessment process on a firm wide basis.

1.2

System should have customized templates for rolling out RCSA across all the

operational/ functional/ administrative units. The vendor should assist in customizing

the RCSA templates to suit the requirements of the Bank.

1.3

The system should be capable of supporting different RCSA methodologies. The

system should support rollout of RCSA using multiple approaches such as top-down,

bottom-up, and hybrid as determined by the bank. Methodology may include


clustering/ grouping of risk entities by risk profile, geography or any other criteria

where each cluster can be treated as as one risk entity.

1.4 The system should have the capability to map the existing Organization Structure to

the relevant Business Lines as per Basel-II guidelines.

1.5

Assessment scheduling shall 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 scheduling is due and escalation for delay in

completing the assessment to various levels. System should support assigning

ownerhsip for each RCSA schedule.

1.6 End users should be able to rate the identified risks and controls

1.7 The system should have the ability to compute residual risk values based on the

ratings applied for risks and controls for each process step

1.8 The system should be able to re-run the past assessments based on the revised scale

when there is a change in the rating scales

1.9 The system should enable logical structuring of the self assessment scenarios into

units, departments and business lines

1.10

The system should be able to aggregate the different ratings and identify outliers.

The system should have the capability to automatically communicate the identifed

outliers to the respective users for further clarifications through bulk e-mail or other

appropriate modes.

1.11 The system should have the capability to reclassify/categorize the operational risk's

as per Basel/RBI Guidelines

1.12

The system should have the capability to generate heat maps automatically. The

system should have the capability to customize the logic used for creating Heat Maps

(preferably through a master user setting)

1.13 The system should have a dashboard facility to view the risk profiles by business

area, business unit, Basel business category etc

1.14 System should have the capability of rolling out RCSA through online (web based)

channels

1.15 System should have the capability to capture RCSA response planning and tracking

the same

1.16 The system should be able to follow up for unresolved action points and generate

status report for the same.

1.17

The system should be able to capture testing results. Risk and controls should be

mapped to respective classification such as risk entity, process, product, Basel II

classification, causal factors, risk drivers, significant/non significant risk,

preventive/detective control, control frequency, risk identification by (auditor/risk

entity/IRMD/external events/others) etc.

1.18 The system should generate heat maps based on testing results. The same should be

compared to initial heat maps to highlight the shift in risk levels.

1.19 The system should be able to generate test plan based upon timelines in action points

1.20 The system should have the capability to upload the existing RCSA data with the

Bank

1.21

Vendor should conduct a sample run of the entire RCSA exercise as per the process

mentioned by the Bank and Vendor should extend assistance in customizing various

reports and MIS


1.22

RCSA template must have the facility for creation of risk and control library. It

should have flexibility to enter any risks identified and corresponding controls in all

the operations and activities of the bank including in the support functions. Risk and

controls so identified should be stored in the risk and control data library.

1.23 Risk and Controls in the RCSA template should come from the Risk and Control

Library to avoid repetitive preparation of templates

2 Loss Data

2.1

The system should have the capability to capture operational losses as per the

threshold decided by the Bank. The loss capturing template should be customisable

for different stages of the workflow.

2.2

The format used for capturing operational risk losses should be customizable by the

Bank. The system should have download and upload facility for loss risk events in a

specified template.

2.3 The system should have dashboard facility to view the loss event in different impact

bucket by business area

2.4 System should have facility to capture near-miss events, gains arising from

operational risk loss event and opportunity cost.

2.5 System to have the capability to request for and track the reporting of data from

pre‐ defined responsible personnel at predefined frequencies

2.6 System should be able to escalate losses to the authorized personnel above a set

threshold. A master user setting should facilitate the input of the escalation structure.

2.7 The system should have a methodology to classify losses as per Basel loss events,

Classification logic should be customizable.

2.8

The system should be able to generate an 8X7 matrix of loss events and business

lines. And model the operational loss distribution for the entire 56 operational risk

cell.

2.9

The system should have the facility to customize/map loss data reports as per the

Bank's needs. Loss information should include type of valuation such as book value,

replacement cost, Mark to Mark (MTM) etc. Vendor should be able to link various

source system and report servers with loss modules for automation of certain types

of loss capture and under reporting analysis.

2.10 The system should be able to do scaling, judgment overrides or other adjustments to

the loss estimates.

2.11

Information with respect to risk event should be captured such as date of risk event

occurrence, event end date, date of discovery, date of providing contingent liability,

date of accounting / provisioning, description of risk event, location, product,

process, risk entity, root-cause analysis (RCA), causal factors, risk drivers, mapping

with business line and loss event type as per Basel II classification, bank‟s internal

classification etc.

2.12

System should flag events as loss event, near-miss, external loss data, operational

gain and opportunity cost for distinct identification of each entry. It should enable

identification of related loss events over time i.e. grouping of related loss events over

a period of time.


2.13

The system should have the capability to record recoveries and the category of

recoveries e.g. insurance. There must also be the ability to add or customize

categories and also to customize the recovery recording workflow as per the Bank's

needs.

2.14

The system 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.

2.15 System should have the ability to identify and approve "boundary issues" i.e. Credit

Risk and Market Risk related losses as per the logic provided by the Bank.

2.16

System should also facilitate, where relevant, the use of external data to enhance

scenario analysis, fit severity distributions or benchmark operational risk exposure

results.

2.17

The external loss data points in the external loss database should have the following

data points,

1. Loss information

2. Description

3. Supplementary analytic data (balance sheet size, revenue, etc)

4. Classification as per Basel-II standards

2.18

External loss data from all sources e.g. public data / pooled industry data / vendor

data, should be supported by the system. System should be able to do scaling,

adjustments (qualitative as well as quantitative). The scaling process should be

systematic, statistically tested and generate outcome consistent with the operational

risk profile of the bank.

2.19

System should facilitate validation of loss data through multiple levels of reviews

and approvals e.g. maker-checker and there can be more than one level of review

and approval.

2.20 System should facilitate reconciliation of loss data with other source data such as GL

entries etc.

2.21

Proposed solution should provide facility to seamlessly upload/ download data to

and from the Loss Data Exchange (CORDEX) setup by Indian Banks Association

(IBA)

3 KRI (Key Risk Indicator)

3.1

System should enable the authorized users to create new KRIs and edit as well as

map existing KRIs. The system should also be capable to interface with multi data

source systems (such as CBS, RBIA etc.) and extract the data from the same in an

automated manner.

3.2 The system should enable users to upload plan and facilitate tracking and reporting

on a firm-wide basis of the KRI process.

3.3

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.

3.4

The system should allow assignment of accountability to each KRI and list out

underlying common risk factors for the KRIs and should also be capable of

estimating/quantifying loss events based on the scenarios for underlying risk factors.


3.5

The system should have the ability to take values from different users and

consolidate them at various levels such as business function, location and business

line.

3.6 The system should be able to generate a dashboard, generate reports and analyze

trends based on logic approved by the Bank.

3.7

The system should allow setting up KRI specific tolerance threshold limits. The

system should provide for email/SMS alerts whenever KRI values breach the

acceptable threshold limits set for them.

3.8 System should cull out continuous red (high risk) and amber (medium risk)

indicators and automatically intimate the person responsible for that KRI.

3.9 The system should allow setting of different monitoring frequencies (weekly,

monthly etc.) for each KRI.

3.10

The system should record, suggest and monitor action points arising out of red and

amber indicators with agreed timelines. 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.

3.11 The system should be able to follow up (as per escalation matrix) for unresolved

action points and generate status report for the same

3.12 The system should allow reassessment of indicators and thresholds.

3.13

The system should have an algorithm for converting KRI data monitored across

branches, units, geographies into risk scores. The algorithm should also provide for

aggregating risk scores across business lines, geographies, branches and provide risk

scores at different levels for comparison

3.14 The vendor should extend assistance by conducting a sample run of the KRI process

as per the Bank specified process.

3.15 The vendor should extend assistance in customizing various reports and MIS

3.16 System should create a KRI Database which would store the Defined KRIs, which

can be used to assign KRI to various risk

4 Business Line Mapping & Capital Computation under TSA

4.1 The system should have the capability to map the existing Organization Structure to

the relevant Business Line as per Basel-II guidelines on TSA.

4.2 System should be able to map all activities of the bank into the eight level 1 business

lines in a mutually exclusive and jointly exhaustive manner.

4.3 The system shall also be capable to map the activities of the bank into level 2 & 3

mapping as envisaged by RBI.

4.4

When mapping gross income, if an activity cannot be mapped into a particular

business line, then the system should be capable of using an objective mapping

criteria in accordance with the Basel II guidelines.

4.5 System should be capable of defining the mapping of any new activities or products

introduced by the bank.

4.6 System should be capable of generating reports as envisaged by management. The

bidder should extend assistance in customizing various reports and MIS.

4.7 The bidder should also extend assistance by conducting a sample run of the Business

Line mapping process as per the Bank specified process.

4.8 System should allow the user to extract the data based on applied filters e.g. Gross

Income mapping for a particular period.


4.9

System should be able to compute gross income for different business lines as per

Basel II / RBI guidelines for TSA, by interacting with data warehouse or other

source systems.

4.10 System should incorporate validation checks such as reconciliation of income as per

GL/FS with income considered for capital computation.

4.11 System should be able to store documentation containing the rationale for mapping

of Income codes appearing in GL.

4.12 System should be able to calculate the operational risk capital as per RBI‟s TSA

guidelines by applying the Beta % prescribed by RBI for each Business line.

5 Scenario Analysis & BEICFs

5.1

Systems should facilitate scenario analysis of expert opinion to evaluate its exposure

to high-severity loss events e.g. including macro-economic scenarios for calculation

of operational risk capital and for operational risk management.

5.2 The system should support development of scenario related models under the

scenario based approach.

5.3 System should facilitate use of assumptions in scenario analysis based on empirical

evidence.

5.4 System should also facilitate review and validation of scenarios.

5.5

Solution should provide various methods for the identification and assessment of

Business environment and internal control factors and combining results thereof by

using bank‟s existing operational risk management framework and its

implementation results such as RCSA (Risk and Control Self-assessment) results,

KRI results and Audit Review findings, etc.

5.6

Solution should support flexibility for use of BEICF directly or indirectly in the

capital calculation process :

as upward / downward adjustment to operational risk capital

indirect input to the scenario analysis process

Solution should have capability of calculation of capital before and after

consideration of BEICF factors.

6 Capital Computation - Standardized Approach and AMA

6.1 System should be able to compute gross income for different business lines as per

RBI/Basel guidelines or any other alternate classification.

6.2

The system should be able to capture loss scenarios and map loss events and

business lines on the basis of low frequency high severity (LFHS), high frequency

low severity (HFLS), low frequency low severity (LFLS), high frequency high

severity (HFHS).

6.3 The system should be able to generate a 8X7 matrix of losses and business

6.4

The system should allow the user to fit various frequency distributions, including

Poisson, Binomial, Negative Binomial and any other distribution suggested/accepted

by RBI. The system should be able to provide graphical outputs for the fitted

distribution. Vendor should independently develop and validate the distributions

using statistical tools.

6.5

The system should allow the user to fit various severity distributions, including

Normal, Log normal, Pareto, Weibull, Beta, Gamma, Inverse Gaussian, Extreme

Value Theory and any other distribution suggested/accepted by RBI. The system

should be able to provide graphical outputs for the fitted distribution. Vendor should


independently develop and validate the distributions using statistical tools.

6.6

System should have capability to integrate all the data elements viz. external loss

data, internal loss data, scenario data, business environment and internal control

factors and generate capital numbers. Vendor should be able to provide the logic of

usage/ combination of the above data elements.

6.7

The system should have the capability to run the goodness of fit test for fitting

distribution as suggested by RBI and industry leading practices. Vendor should have

the capability to run the goodness of fit test.

6.8

The system should identify the relationship between losses and the provided drivers

based on various regression techniques and the system should rank the provided

drivers against the loss event categories based on the best fit computation of the

identified relationship parameters.

6.9 The system should allow user to define scaling methodology for losses at each cell

based on the above relationship

6.10

The system should support Monte Carlo simulation for combination of frequency

and severity distribution. Vendor should be able to provide the logic for combination

of frequency and severity distribution through Monte carlo simulation

6.11

The system should support Extreme Value theory for fat tail events (Low frequency

high severity -LFHS). Vendor should be able to develop operational VAR for LFHS

events using Extreme value theory

6.12

The system should have a functionality to combine frequency and severity

distributions via statistical techniques to form a total loss distribution for each loss

type/business line combination. Vendor should independently develop and validate

the mixing of frequency and severity distribution using statistical tools.

6.13

The system should have advanced analytics functions such as: system capability to

extrapolate from the distribution of observed total loss points curve to determine the

likely amount of total losses, etc. Vendor should be able to carry out Advanced

analytics function.

6.14

The system should support development of scenario related models under the

scenario approach. System should support identification/generation of scenarios and

their consequent analysis based on inputs received from Internal Loss Data, Relevant

External Loss Data and Business Environment and Internal Control Factors

(BEICFs) in line with the RBI AMA guidelines.

6.15

The system should have advanced analytics functions such as: system capability to

carry out structured stress testing, factor the impact of BEICF effect, extrapolate

from the distribution of observed total loss points curve to determine the likely

amount of total losses, etc.

6.16

System should support administration and facilitation of the templates designed for

respective assessors for various risk types and business lines. The templates should

be customizable

6.17

The system should generate VAR for each scenario as well as aggregated VAR at

Business line level and Bank wide level. Vendor should independently develop and

validate the VAR measures using statistical tools.

6.18

The system should fit various distributions based on pre set criteria for each

Scenario. Vendor should be able to fit the frequency/ severity distributions, generate

scenario based on Var and link the Var number to the number derived from internal

loss data.


6.19 The system should objectively combine LDA data / RCSA data with Scenario data to

arrive at Bank wide capital

6.20 The system should enable the user to define rules for combination of LDA data/

RCSA data and Scenario data

6.21

System should support the risk Var measure to reflect various confidence levels e.g.

95%, 99.9% etc. Vendor should independently develop and validate VAR using

statistical tools.

6.22

The system should be able to adjust capital based on RCSA /KRI / other quality

index and the system should identify the relationship and carry out sensitivity

analysis between RCSA / KRI / other quality index

6.23

System should enable validation of any parameters (loss rates, risk indicators, scale

indicators etc.) used in the system to ensure that the inputs to the regulatory capital

charge are reliable e.g. capability to allow the user to run sensitivity analysis

6.24 System should enable analyst to model operational risk capital charge with and

without the impacts of insurance

6.25 The system should be able to provide graphical outputs for the fitted distribution.

6.26

The system should support matrix multiplication, covariance-variance and copula

approaches for the purpose of aggregation of losses at each cell to arrive at bank

wide capital. Vendor should independently develop and validate the above

approaches using statistical tools.

6.27 System should enable capital re-allocation to the business lines based on the above

Aggregation

6.28 System should support back testing and vendor should be able to carry out back

testing specifying the scope and scale of backtesting.

6.29

The software should provide bulk data loading facilities to load the data in database.

Following is expected to be bulk loaded:

· Loss events with financial impacts (losses and recoveries)

· Business structures (business lines, risk categories, causes, management

organizations, legal organizations etc.)

· KRI (& RCSA ), Scenario data

6.30

All the processes of the system (including approaches for stress testing) should be

Adequately documented for ease of review and verification by the Bank, external

parties or by the regulator. Vendor should provide adequate assistance during such

reviews. All the documentation of models should include the key assumptions and

key sensitivities of the models. Vendor should be able to carry out stress testing

6.31

System should have the facility to define the model input and output ,parameter

estimation of each scenario, frequency and severity distribution and its aggregation ,

calculation of expected and unexpected losses.

7 Process Mapping and Reporting Structures

7.1

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

7.2

System should provide Multi- Hierarchy Structure Management: Multiple

hierarchies or structures permit data to be viewed and managed across more than one

dimension with adequate access and edit permissions as specified by the Bank.


7.3

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.

7.4 System should have the capability to maintain inventory of processes and reports at

least for seven years

7.5

System should support the break-down of processes into logical process steps with

linkages to underlying procedures, unit responsibility and they should be able to be

linked to RCSA, KRI and Loss event

8 Verification & Validation of processes

8.1 The system should have the capability to implement a Bank defined verification &

validation process and should fulfill all audit and compliance requirements.

8.2 The system should be able to intake the process flow as mentioned by the Bank

8.3

As per the process flow, the system should have the capability to initiate the

verification & validation process and track the progress of various process steps as

per the timelines provided by the Bank

8.4

The system as well as the vendor should have the capability to get the operational

risk measurement system (ORMS) validated by independent third parties to ensure it

is compliant with RBI guidelines.

8.5 System should provide all the information as may be required for independent

review of Operational Risk Management Framework (ORMF)

9 Risk Reporting

9.1 Periodic reports to be generated on loss event types highlighting the findings of

RCSA, Audit, Loss, Potential loss and Near Miss data, KRI and Scenarios

9.2

The system should be capable of generating performance measurement reports

measured vis-a-vis RCSA results, KRI status and action taken by units/business

lines. Solution should provide capability for the allocation of capital to business

lines, RAPM (Risk Adjusted Performance Measurement) and RAROC (Risk

Adjusted Return on Capital).

9.3 System should provide linkages between RCSA, KRI, loss data and audit processes

as required by the Bank.

9.4 The system should provide a drill through heat map. The system should provide drill

down reporting.

9.5 The operational risk charge before and after any reduction in capital resulting from

the use of insurance.

9.6 The system should have adequate graphical reporting tools for reporting loss event

data

9.7 System should support KRI dials for the dashboard reporting

9.8 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

9.9 System should support slice and dice of structure values and filtering of risk areas

simultaneously

9.10

The system should provide capital charge drill down at each cell level, which would

provide a split of LDA VAR and Scenario VAR and from Total Scenario VAR the

system should provide drill down to VAR of each Scenario

9.11 The system should display capital before diversification and capital after

diversification effect and highlight the diversification impact


9.12 The system should display capital before BEICF adjustments and capital after

BEICF adjustments and highlight the impact of BEICF

9.13 The system should aggregate the RCSA scores of risk events to arrive at a Bank

wide RCSA profile

9.14 The system should generate reports pertaining to outstanding issues and/or action

plans emanating from RCSA/KRI/Loss Data Analysis at any given date

9.15 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

9.16 The vendor should provide post implementation support, configuration training and

enduser training.

VII. FUNCTIONAL REQUIREMENT FOR MARKET RISK

The Bank aims to migrate to the Internal Model Approaches (IMA) for market risk as per Basel

II, Basel III and RBI guidelines. The solution should support estimation of all risk components

and capital calculations (regulatory & economic) as per the guidelines issued by RBI and Basel

under the Standardised Measurement and Internal Model approaches. The solution should be

able to meet the Pillar I, II, III and stress testing requirements as per Basel-II / RBI guidelines

and Basel-III guidelines. The solution should be capable of supporting all the required statistical,

analytical, risk modelling and reporting requirements.

Sl No Market Risk Functional Requirement

1 Preparation of capital charge computation report under SMM for market risk

1.1

The system should interface with external market information systems including

Reuters, Bloomberg, NSE, BSE, FIMMDA, CRISIL Bond valuer , CCIL, AMFI,

FEDAI and NDS to obtain pricing feeds

1.2

The system should extract position data from the treasury system by interfacing

without manual intervention to perform valuations whenever required by the user .

A single engine will be used for valuation. This engine will be from the market risk

system.

1.3

The system should be capable of validating data at the interface level to enable

perform of key reconciliation checks between position data in the treasury system

and market risk system

1.4

The system should segregate position data obtained from the treasury system in line

with the risk classifications prescribed for SMM i.e. equity, forex/ bullion, interest

rate risk and derivatives

1.5

The system should be in a position to compute modified duration based on for all

interest rate instruments including floating rate bonds and zero coupon bonds taking

into account the optionality attached to it. The system should be capable of

exempting certain investments from M-Duration computation and aggregation.

1.6

Computation of modified duration should be done based on external price data

extracted from the treasury system as well as for price data manually input into the

market risk system. The market risk system should provide a data capture field

where required for such an updation. However the requirement for manual input of

price data should be minimal and restricted to few products where valuation is

complex like OCCPRS and Unlisted securities


1.7 The system should be able to compute modified duration from PV01.

1.8

In case of interest rate derivatives, the system should be in a position to identify

back-to-back trading positions based on current RBI guidelines that are treated as

matched positions (i.e. having critical terms matching with a 15bps spread on the

fixed leg) and derivatives undertaken for hedging (other than to hedge trading book

positions). These should be excluded from the computation of market risk capital

charge.

1.9 In case of floating rate bonds, the system should perform the valuation in line with

current FIMMDA guidelines

1.10

Valuation of forex positions would be required to be undertaken based on FEDAI

rates on monthly basis and based on input from market data providers on daily basis.

System should be able to compute forward prices based on both

1) Interest Rate Parity method

2) Forward premiums available from market data vendor

1.11

The system should be in a position to capture the NOOP limit and treat the higher of

NOOP or actual open position in equivalent USD terms as the basis for computing

forex/ bullion position

1.12

The system should support the following three methods for determining the option

position and computing capital charge:

1) Simplified Approach

2) Delta- Plus Approach

3) Scenario Approach

1.13 The system should be in a position to bucket interest rate risk positions in different

time-bands zones as prescribed by RBI based on residual maturity.

1.14 The system should apply horizontal and vertical disallowances based on prevalent

RBI guidelines

1.15

The system should be able to treat interest rate swaps as a combination of two

equivalent securities for the purpose of determining risk position and computing

modified duration

1.16 For the floating leg of an interest rate swap, modified duration should be computed

based on the next reset

1.17 The system should be able to compute the modified duration based on the PV01 of

the floating leg of the interest rate swap

1.18 The system should be able to apply the relevant market risk capital charge

depending upon the portfolio classification

1.19

The system should be in a position to compute capital charges for the AFS portfolio

in the following manner:

- Compute general and specific charge as for HFT

- Compute alternative capital charge for specific risk

- Compute the higher of the two to determine capital charge

1.20 The system should be able to compute specific charge based on rating criteria

provided by the user and updated from time to time

1.21 The system should be able to differentiate specific charge for both rating criteria and

category of issuer

1.22 The system should enable reduction of risk position post netting of collateral for

determining specific charge. This should be parameterised by the user.


1.23 The system should aggregate capital charge across all risk categories

1.24 The system should report the market risk capital charge computation in the format

prescribed by RBI

1.25 The system should generate the quantitative disclosure report for market risk as

required by RBI

1.26 The system should be in a position to simulate the impact of incremental positions

on the market risk capital charge

1.27 The system should be able to compute risk positions in different currencies and

perform required capital charge computations by currency

1.28

The system should support the following valuation methodologies:

- Mark to market

- Mark to model

- Cost to close

1.29 The system should allow for adjusting valuations based on illiquidity premium

1.30 The system should be in a position to adjust valuation decrease caused due to

illiquidity premium from the available capital

1.31 The system should be in a position to compute capital charge for delayed

settlements based on the multipliers prescribed by RBI

1.32

In case of non-DVP transactions, the market risk system should be in a position to

collate overdue settlement beyond 1 day from the treasury system across all asset

classes

1.33

In case of non-DVP transactions, the market risk system should be in a position to

collate overdue settlement beyond 5 day from the treasury system across all asset

classes and reduce the same from the capital

2 Limit Monitoring

2.1

The system should allow the user to set the limits based on the notional principal,

VaR, risk sensitivity factors, MTM, book value, daily P&L and cumulative P&L for

individual scrips as well as the aggregated portfolios

2.2 The system should have the capability of setting and monitoring the following type

of product wise limits at the frequency defined along with it:

2.2.1 Fixed Income

Product wise and Overall Investment Limit (Real-time)

2.2.2 Limits on the size of the proprietary Trading book

2.2.3 Dealer-wise limit

2.2.4 PV01 based limits for Investment (under AFS + HFT)

2.2.5 Short Sale Limits

2.2.6 Deal size limits (Real-time)

2.2.7 Maturity wise limits (Real-time)

2.2.8 Rating-wise limits for rated instruments (Real-time)

2.2.9 Industry / sector wise limits (Real-time)

2.2.10 Portfolio as well as security level stop loss limit (Real Time)

2.2.11 Portfolio as well as security level Cumulative stop loss limit (Real Time)

2.2.12 VaR limit (Preferable near real time but can be at a batch process level)

2.2.13 Equity & Equity MF

Overall Investment limit (Real-time)

2.2.14 Deal size limit (Real-time)


2.2.15 Scrip-wise limits for Equity (Real-time)

2.2.16 Investment limit for Equity MF (Real-time)

2.2.17 Portfolio as well as scrip level stop loss limit (Real Time)

2.2.18 Portfolio as well as scrip level Cumulative stop loss limit (Real Time)

2.2.19 VaR limit (Preferable near real time but can be at a batch process level).End of day

Limit is preferable.

2.2.20 Foreign Exchange and Bullion

NOOP limit (End of the day)

2.2.21 Intraday (Daylight) Position Limits

2.2.22 Overseas Investment Limits

2.2.23 Tolerance Limit

2.2.24 Dealer-wise Open Position Limits

2.2.25 Aggregate gap limit (End of the day)

2.2.26 Deal size limits(for different products) (Real-time basis)

2.2.27 Portfolio as well as currency level stop loss limit (Real Time)

2.2.28 Portfolio as well as currency level Cumulative stop loss limit (Real Time)


2.2.30 Gold overnight position limit (real time)

2.2.31 Derivatives

Deal Size limits (Real Time)

2.2.32 Greek limits for options

2.2.33 Delta limits (Real time)

2.2.34 Overall Gamma (Real Time)

2.2.35 Gamma beyond 3 day (Real Time)

2.2.36 Vega (Real Time)

2.2.37 Rho (Real Time)

2.2.38 Phi (Real Time)

2.2.39 Maturity segment wise PV01 limits for interest rate derivatives

2.2.40 Stop loss limit (Real Time)

2.2.40

A Take Profit limit (Real Time)

2.2.41 Cumulative stop loss limit (Real Time)


2.2.43 IRS and FRA Exposure limits (Net Open Position)

2.2.44 Currency Options / Futures / Swaps – Foreign Currency : Exposure Limits (Gross

Open Position)

2.2.45 Rupee Options : Exposure Limits (Gross Open Position)

2.2.46 Interest Rate Swaps / Forward Rate Agreements / Futures – Rupee : Exposure limits

(Net Open Position)

2.2.47 Counter party limits

2.2.48 Liquid mutual fund;-Regulatory limit, external minimum rating for MF

Per Fund house limit Portfolio as well as scrip limit VaR limit etc

2.2.49 Liquid mutual fund;-Regulatory limit, external minimum rating for MF

Per Fund house limit Portfolio as well as scrip limit VaR limit etc

2.3 The system should have the functionality where dealers are able to view the current

limit utilization as well as the impact on limit utilization of a deal on a pre-deal basis


of Various Risk parameters including Deal wise VaR.

2.4

The system should have the facility of setting trigger levels for the limit breaches

(soft limits) where the system will generate alerts once the trigger level is reached to

pre-defined users.

2.5 The system should have a process flow built-in for authorization of limit

enhancements.

2.6

The System should be able to generate limit breach report as and when the limit

breaches happens and send the notification to the pre-defined set of people.

All major limits like Noop, Agl, Var, Stop loss and dealer wise positions should be

included in the report.

2.7 The system should be able to generate limit utilization report at the end of the day

and also for a historical period including any breaches.

2.8 The system should maintain audit trails for any changes in configuration of limits.

2.9 The system should be capable of monitoring VAR based stop loss limits.

2.10

The system should be capable of generating consolidated reports showing exception

if any under different risk parameters after making a comparison of actual and

limits as defined by the Mid office from time to time

2.11 The system should be capable of monitoring compliance with limits laid down in

Policy in respect of liquid investments

2.12 The system should be capable of computing the Beta in respect of different

portfolios

2.13 The system should be capable of monitoring compliance with Portfolio Beta Limits

and M-durartion limits

2.14

The system should be capable of monitoring investments in capital instruments of

Financial institutions and Banking sector daily basis as required under Basel III

norms

3 Valuation

3.1

Product Coverage

The system should be able to perform the pricing as well as MTM valuation of all

the products in the Bank‟s portfolio as well as the products that the Bank may wish

to deal in the future.

The system should be capable of doing valuation at least on a weekly basis.

The list of the products is provided below:

Foreign Exchange

FX Spot-Forwards(including both merchant and inter bank forwards)

European FX Options

ET FX Futures

ET FX Options on Futures

3.2

Interest Rate

Cash management bills

Securitisation (Pass through Certificate including investment for meeting priority

sector lending targets)

Call Money

Repos / Reverse Repos

Treasury Bills

Commercial papers


Certificates of Deposit

Short Term Notes

Promissory Notes

Single Cash flow

G-Secs

Fixed Coupon Bonds

Coupon stripping

Zero Coupon Bonds

Floating Rate Notes including but not limited to:

Plain Vanilla

Structured

Amortizing

Averaging

Capped / Floored

Callable / Putable

Inverse Floater (reverse)

Perpetual

3.3

Interest rate Derivatives

Forward Rate Agreements (FRAs)

Interest Rate Swaps (IRS)

Plain Vanilla

Cross Currency IR Swaps

Basis Swaps

Zero Coupon

OIS (MTM Calculation using daily reset and compounding)

Amortizing Swaps & swaps with different fixing and payment frequencies

Averaging Swaps

Constant Maturity Swaps

Interest Rate Swaptions

Caps, Floors and Collars

Interest Rate OTC exotic options (indicate which ones)

Callable / Putable Swaps

Convertible Bonds/Convertible preference shares

Dual Currency

Ex Coupon

Step-Up / Step-Down

Interest Rate Strips

Interest Rate Futures

3.4

Equities

Equity options, futures and swaps

Warrants

Equity shares(including Indian Depository receipts (IDR))

Non-convertible preference shares

Index options, futures and swaps

Note:- The system should have flexibility to use market prices of equities published


by two or more exchanges and take the lowest price

3.5 Commodities Options, Futures and Swaps

3.6 Credit Default Swaps

3.7

Generation of Term Structures

The system should be able to define an unlimited number of term structures for a

satisfactory coverage of the various markets within a specific currency (libor, bond,

swap, etc.)

The system should provide multiple yield curve data display for spread comparisons

between different markets

The system should support Yield curves

-generation from internal fund costing

-capture external benchmark curves

The system should provide option to construct and use yield curves using any one of

bid, offer or mid-rates

The system should provide the user with the functionality to choose, assign,

combine and link on the term structure the benchmark instruments quoted on the

market for:

Forward Rate Agreements (FRAs)

Treasury Bills

Commercial Papers

Repurchase Agreements

Interest Rate Futures

Interest Rate Swaps

Generic Bonds

The system should be able to imply the yield curve from FX Spot-Forward structure

also

Choose industry standard yield curve bootstrapping types:

Zero Coupon

Forwards

Proprietary

Chose industry standard interpolation/extrapolation methodologies:

Linear

Exponential

Logarithmic

Cubic spline

Proprietary

The system should accept upload from pre-calculated values from external

applications in the form of Vector of Discount Factors

The system should define/assign separately Discount Yield Curve and Forward

Estimation Yield Curve for structured pricing.

The system should be able to handle negative rates

The system should allow basic graphical term structures analysis for better

understanding of market conditions:

Based on historical information

Based on simultaneous curves comparison


3.8

Volatility Curves Generation:

The system should define an unlimited number of term structures for a satisfactory

coverage of the various markets

Across all currencies

Across all markets within a specific currency (caps, floors, bond options, swaptions,

exchange-traded options, puts and calls)

Across all Tenors

Across all strikes to include Term/Moneyness effect (Smile Effect)

Interest rate volatility structure

The system should choose, assign and combine on the term structure the benchmark

instruments quoted on the market

Caps

Floors

Options on Interest Rate Futures

Swaptions

Bond Options

The system should incorporate industry standard calculation methods in volatility

curve generation functionality like swaptions volatility Implied from correlations

with other markets (caps / floors)

The system should allow to chose interpolation methodology

Linear

Proprietary

Cubic spline

The system should upload pre-calculated values from external applications

Vector of Forward volatilities

FX volatility Structure

Chose industry standard interpolation methodology

Linear

Proprietary

3.9

FX Spot-Forward structure:

The system should define an unlimited number of FX structures for a satisfactory

coverage of the various markets.

FX Forward generation functionality:

Forward premium Quotes from the markets

FX Forwards implied from Yield Curve structure (Interest Rate Parity)

Yield Spread curves generation

The system should define term structure points as a spread over any of the

benchmark instruments

The system should define term structures as a spread over any other interest rate

term structure

The system should incorporate Securities, Equities and Commodities prices

The system should define for each benchmark instrument all key parameters

necessary for correct calculations (i.e. Day Count Basis, Business day Convention,

Holiday Conventions, etc.)

The system should be able to extend database model in order to handle new

instruments


The system should configure and customise any instrument parameters at the cash

flow level.

The system should define a new instrument by inheriting the logic of its constituent

instruments. The system should reuse existing functionality modules without

unnecessary code duplication and user re-definition.

3.10

Calculation Methods

Foreign Exchange Models (for Spots and Forwards):

Net Present Value

Marked To Market (Forward value comparison)

The system should conform to accrual and other accounting revaluation

methodologies:

Interest Rate Models and Indexes:

Net Present Value

Discount Curve

Forward Estimation Curve

Index Yield Curve

Calibration to market

The system should conform to accrual and other accounting revaluation

methodologies

Fixed Income / Securities

Marked To Market

NPV from any yield curve

Fixed spread over any yield curve

Fixed spread over Benchmark Bond

Incorporation of common optionality models

Marked to Market

Black – Scholes (BS)

The system should specify custom / in House pricing models

System should allow user to over write Fixings and Cash flows, which shall be

considered for P&L computation.

The system should display partial calculations results for reconciliation and model

risk analysis

3.11

Factor Sensitivity Analysis

The system should calculate factor sensitivities at trade, position and portfolio level

using:

”Par” Rates shift

Zero Coupon shift

First and Second Order Derivatives on NPV

The system should calculate sensitivities. Including but not limited to:

Interest Rate Delta:

Discount Delta (DF sensitivity)

Forward Delta (Forward rate sensitivity)

Delta Total

Interest Rate Gamma:

Discount Gamma

Forward Gamma


Gamma Total

Vega

Theta

Discount Theta

Option Theta

FX Spot Sensitivity

FX Delta

FX Gamma

FX Vega

Rho

Maturity bucket wise PV01

Phi

Vanna

Volga

The sensitivity factors should be netted according to the maturity for a portfolio

level sensitivity analysis.

3.12

Decision Support Tools

Portfolio optimization

Benchmarking relative to user defined indices and portfolios

Determination of Efficient frontier

Scenario analysis

What if analysis

Simulation Tools

Sensitivity analys

Hedge Effectiveness Testing

3.13

Profit & Loss Attribution

The system should decompose P&L into the constituent risk factors responsible for

the net portfolio value change:

IR Delta P&L

IR Gamma P&L

FX Vega P&L

IR Vega P&L

IR Time Decay (Theta)

Trade events

New trades

Amended trades

Void trades

The system should display and report Profit & Loss attribution using drill down

capabilities

The system should display and report Profit & Loss attribution using graphic

capabilities

System should allow TMO to over write Fixings and Cash flows, which shall be

considered for P&L computation.

4 VaR Calculation and Back testing

4.1 The system should be able to use the extracted position data and market data


4.2 The system should give the user the flexibility to choose the risk factors applicable

to compute VaR

4.3 The system should be able to retrieve historical data of the risk factors based on the

user-defined holding period.

4.4

The system should be able to calculate VaR using parametric approach, delta-

gamma approach, variance-Co-variance method, Monte-Carlo approach and

Historical simulation methods.

4.5 The system should be able to calculate parametric VaR using industry standard Risk

Metrics methodology.

4.6 The system should estimate VaR for Non-Gaussian risk

4.7 The system should be able to calculate volatilities using relative price changes,

absolute price changes and logarithmic price changes

4.8

The system should allow applying different volatility estimators and models:

moving averages, exponential with definition of Decay Factor, GARCH &

Stochastic Volatility estimates.

4.9

The system should have the ability to calculate correlation using historical data and

have the flexibility to set parameters to incorporate volatilities and correlation data

from external source.

4.10 The system should allow user-defined confidence intervals and holding periods as

well as decay factor for historical valuation method

4.11 The system should calculate Undiversified / Diversified / Partially Diversified VaR

to allow for risk factors correlations contribution.

4.12 The system should allow inclusion/exclusion of gamma and Vega factor sensitivities

for linear transactions and optionality

4.13 The system should perform calculations in "Real Time" or "Near Real Time" and

batch basis

4.14 The system should calculate and store the various components of VaR for further

drill down reporting capacity

4.15 For historical simulation, the system should support variants of Full Valuation for

performance issue enhancements

4.16

For Monte-Carlo approach, the system should have an accurate and sizeable (50000

numbers minimum) random number generator algorithm which can support multiple

probability distributions

4.17 The system should include standard processing methodologies for run time

performance enhancement, (e.g. Distributed / parallel processing)

4.18 The system should provide variance reduction techniques

4.19

The system should provide for multi-process Monte-Carlo processes ( i.e. to define

the length of Monte Carlo steps, the mean reversion and standard deviation for the

models used to describe risk factors relationships)

4.20

The system should display Monte Carlo price paths leading to losses greater than a

certain amount (user definable) in order to provide a better understanding /

interpretation of the market conditions that could generate such losses.

4.21

For incremental VaR, there is a need for a system that approximates VaR in an

additive form without recalculation of the complete firm-wide portfolio. (for intra-

day calculation)


4.22 The system should have the functionality to compute transaction level (Component)

VaR

4.23 The system should have functionality to aggregate VaR at any hierarchy level

4.24 The system should perform incremental calculations in real time

4.25 The system should have open architecture to allow link to external proprietary VaR

engines.

4.26 The system should allow user-defined scenarios to override-adjust historical pattern

assumptions (e.g. special events)

4.27 Allow combination of analytical and simulation methods based on product type for

performance enhancement

4.28 The system should allow combination of analytical and simulation methods based

on product type for performance enhancement

4.29 The system should select interval periods for comparing P&L and VaR (at least for

252 trading days)

4.30 The system should test parameters by simulating VaR on historical portfolios and/or

rates

4.31 The system should be able to generate exception reports.

4.32 The system should be able to classify the number of exceptions in green, yellow and

red zones as defined by the RBI and generate a report on that.

4.33 The system should be capable of computing VaR in respect of all financial

instruments dealt by bank presently and in future

4.34

The system should be capable of defining VaR reporting hierarchy like Treasury

VaR, Asset Class VaR, Portfolio VaR,Portfolio Asset class VaR, Instrument VaR

and Component VaR

4.35

The system should be capable of computing VaR in respect of equity positions and

interest rate sensitive positions( including those interest rate sensitive positions

which has credit risk)

4.36

The VAR models in the system should be capable of combined VaR in respect of

specific and general market risks for equity positions.Further it should be able to

isolate the VaR for each component so as to enable its back testing and day to day

risk management

4.37

In case of interest rate sensitive positions which has credit risks, the system should

be able to compute Incremental risk charge for default and migration risks , which

are generally not captured by the VaR model. Alternatively these risks may be

factored in the VaR model in a sensible manner

4.38 The system should be capable of computing and displaying the VaR measures which

are denominated in INR.

4.39 The system should be flexible in choosing the historical observation period and

different methodologies for computation of VaR

4.40 The system should facilitate frequent update of data sets in a flexible and convenient

maner

4.41 The system should have sufficient statistical tools to test the accuracy of VaR

models

4.42 The system should accommodate the application/usage of different VaR models for

different asset classes


4.43

In case of non- linear portfolio, which do not have identical and independent

normally distributed returns, VaR models should not use square root rule to scale up

VaR numbers

4.44 The system should be capable of incorporating risk factors used in pricing model

into the VaR Model

4.45 The VAR models should capture the Basis risk and correlation risk

4.46 The system should facilitate the risk adjusted performance measurement based on

VaR

4.47 The system should have utilities to mitigate model risks that may surface

subsequently or incorrect application

4.48 The system should be capable of computing liquidity adjusted VaR

4.49 The system should Back-Test the portfolio value change excluding / including new,

voided, amended trades

4.50 The system should be capable of performing back testing on actual as well as

hypothetical P&L.

4.51 The system should be capable of performing back testing on dirty as well as clean

(minus brokerage, commission etc.) P&L.

4.52 The system should have the functionality to perform sub-portfolio level back testing.

4.53 The system should have the functionality to perform back testing for multiple

confidence intervals.

4.54 The system should store the historical back testing exceptions for at least 3 years.

4.55

Back testing: specific risk

The system should have the capability to run the goodness of fit test for fitting

distribution as suggested by RBI and industry practices.

4.56 The model should be able to capture concentrations (magnitude and changes in

composition) in specific sectors and counterparties.

4.57

Incremental risk charge (IRC)

The IRC model in the system should appropriately reflect the issuer and market

concentration, concentration within and across product classes

4.58 The system should use Multi-period model to compute incremental risk, and it

should be capable of evaluating implied correlations

4.59

The system supports indirect methods of testing IRC model including at the

minimum stress testing, sensitivity analysis and scenario analysis to assess

qualititative and quatitative reasonableness

5 Stress Testing

5.1 The system should allow the user to define multiple portfolios and assign exposures

to each portfolio.

5.2 The user should be able to define multiple stress testing scenarios for each portfolio

5.3 The system should allow users to save the stress testing scenarios defined.

5.4 The user should have the entire list of scenarios defined available for him to select

the desired scenario for each portfolio at run-time.

5.5 The system should allow the user to define multiple risk factors for each stress test

scenario, depending on the nature of the portfolio.

5.6 The system should be able to upload multiple scenarios directly from excel/csv files

5.7 The system should have the ability to determine the correlation between risk factors

based on historic data


5.8 The system should have the ability to accept correlation information as user defined

parameters

5.9

The system should have the ability to conduct stress testing covering General

scenarios (for entire trading book) and Portfolio specific scenarios using single or

combination of risk factors.

5.10

The system should be capable of accepting risk factor shifts on:

Single term structure

Two or more term structure modelling relationships such as correlations between

curves and auto correlation , FX interest rate parity etc.

Two or more term structure assuming no correlations

5.11

At a minimum, the system should support stress testing based on shifts in the

following risk factors:

Yield curves (Parallel Shifts, Non Parallel Shifts, Changes in the

convexity of the curves & Changes in Basis)

Volatility curves

FX – Spot

FX – Forward structure

FX Volatility

Commodity curves

Equity Indices

Change in correlation and change in Distribution shall also be included.

5.12

The system should be capable of accepting the following calculation parameters

from the user:

Spreads over benchmark curves and between market curves.

Volatilities and correlations

5.13 The system should have the capability to execute multiple scenarios together and

determine the combined effects on the portfolio.

5.14

The system should be capable of accepting risk factor shifts in the form of:

Absolute figures

Percentages

Custom expressions

5.15 The system should have the capability to display the stress test results in tabular

form as well as graphical form

5.16

The system should have the capability to accept stress test limits at the following

granularities:

Complete trading book level

Portfolio level

5.17 The system should have the ability to raise exceptions in the event of a breach of

stress testing limits

5.18 The user should have the ability to schedule stress tests in the system and for report

generation of the stress test results.

5.19 The system should have the ability to create reports in a web-based dashboard

formats to enable senior management to access such reports remotely.

5.20 The system should accommodate testing of probabilistic , historical as well as

hypothetical scenarios(including macro-economic scenarios)


5.21 The system should be flexible to input and use historical data for specified period

and specified multiple sets of data for e.g 2007-2008 for computing stressed VaR.

5.22

The stress testing utility of system should be capable of addressing recovery rate

uncertainty implied correlation and skew risk and other risk factors that are not

captured in VaR model.

5.23

The system should be capable of using Monte- Carlo simulation in assessing the

stress testing shocks to be applied. Besides, while performing the Monte- Carlo

simulation the system should be capable of considering the anti-thetic data ( i.e

model should consider changes that are based on the magnitude of historical price

movements, applied in both directions- irrespective of the direction of the historic

movement.)

5.24

The model should be capable of assessing and applying shocks of the magnitude

experienced elsewhere although the bank was not exposed to such scenario;

provides the information on such scenarios are previously feeded into the system

6 Internal and Regulatory Reporting

6.1

The system should produce screen and print level reports within flexible user

defined hierarchies and business unit aggregation rules

At a minimum the following reports should be produced

6.2

Control Reports

Transaction inventory reports

Open Position reports based on any hierarchy level and any transaction/computed

values

6.3

Risk Reports

Produce position reports for various parameters: delta, gamma, vega, theta, etc.

based on internal hierarchy or sub-portfolios/trades.

Product limits and gaps reports based on risk parameters.

VaR reports disaggregated into various risk components (regulatory requirement)

Simulation/stress testing reports (with drill-down capability)

Portfolio Analysis

6.4 The system should generate reports using any stored historical data

6.5 The system should have a report writer where user may define the content and

format of any new reports.

6.6

Profit & Loss Reporting

The system should produce profit & loss report based on the net present value

approach, accruals and other accounting methodologies, etc. for any defined

portfolio with drill down capabilities to a transaction level

6.7

The system should include in profit & loss calculations: transaction costs (brokerage

fees, commissions, and other deal costs attached to the instrument cash flow

structure)

6.8 The system should also have the capability of cleaning the MTM (removing

transaction costs) for the purpose of back testing.

6.9 The system should calculate and display profit & loss results in local currency, base

currency, reference currency and any other user‟s currency.

6.10 The system should calculate and display profit & loss by year-to-date, month-to-

date, or any other two dates/periods real time or using historic data.

6.11 The system should produce graphical representation of profit & loss results


6.12

Drill Down Functionality

The system should aggregate / breakdown information at any level based on static

information (i.e. trades attributes). Including but not limited to:

Currency

Counterparty

Instrument type

Book

Trader

User-definable attribute

6.13

The system should aggregate / breakdown information at any level based on

dynamic Information (results categories) including but not limited to:

NPV

Delta

VaR

6.14 The system should aggregate / breakdown any combination of static and dynamic

information.

6.15 The system should display results in a Multi-dimensional format (e.g. Excel Pivot

Tables)

6.16

Reporting Requirements - IMA

The System should provide complete qualitative and quantitative disclosures

required for IMA approval.

6.17 High, mean and low VaR values over the reporting period and period – end;

6.18 High, mean and low stressed VaR values over the reporting period and period – end;

6.19 The System should provide Back Testing Exception reports

6.20

Reporting Requirements - Internal

The system should generate reports on:

Duration, M.Duration, Convexity, VaR, PV01, PVBP

Investment Operations

Summary of Banks aggregate exposures like Duration, Modified Duration/VaR,

Mismatches, Forex VaR etc.

Mark to Market Reports of Investment Portfolio, Foreign Currency Portfolio,

Derivatives Position

In addition to the above the system should generate following reports

Stress testing Reports

6.21 Limit Exceptions Reports

6.22 Market Risk Report

6.23 Mark to Market Reports (Investments/Forex/ Commodities)

6.24 Report on Duration, M-Duration, VaR (Investment Portfolio-wise)

6.25 Currency-wise forex GAP Reports (IGL/AGL)

6.26 Market Analysis Report (Volatility/Trends and other risk indicators)

6.27 Market Scenario/Strategy (Based on volatilities, correlations)

6.28 Open Position Report for Precious Metals

6.29 Risk Limit Tracking

6.30 VaR Reports (Forex/Domestic Treasury/ALM)

6.31 Report on assessment of Risk adjusted Earnings (RAROC)


7 Capital Computation

7.1

The System should be able to calculate market risk regulatory capital under IMA

consisting of the following two components, based on VaR measure:

General Market Risk Charge; and b) Specific Risk Charge [including Default Risk,

Credit Migration Risk, Credit Spread Risk, Incremental Risk etc. In addition, the

sytem should compute capital based on the VaR ,and Stressed VaR numbers on a

daily basis according to the framework defined by RBI.

7.2

The user should be able to define certain portfolios where capital will be entered

manually. However entry of capital manually should be an exception rather than a

rule.

7.3 The system should have the functionality to define the RBI allowed multiplication

factor as a default.

7.4 The multiplication factors should be user defined.

7.5 The system should be able to calculate capital for different asset classes as defined

by the user as well as for the aggregate Bank portfolio.

7.6 The system should be able to attribute the movement in capital to a risk factor level.

7.7

The system should be able to decompose the capital and attribute it to various asset

classes. It should be able to perform simulation where by changing the composition

of the portfolio, change in capital should be calculated.

7.8 The system should be able to generate a report as per RBI format for reporting of the

Capital.

8 Computation of Credit Value adjustment

8.1 The system should be able to access the position data (OTC Derivatives) and market

data stored in the table structure.

8.2 The system should segregate position data obtained from the treasury system

counterparty wise.

8.3 The system should interface with the Core Banking System to obtain counterparty

wise collateral information and other exposure mitigates such as margining.

8.4

The system should be able to perform MTM valuations in all the asset class viz.,

interest rate, equity, FX, credit and commodities for the existing portfolio of the

bank.

8.5 The system should be able to apply credit mitigates under a netting set (i.e. netting,

collateral, etc.)

8.6 The system should be able to interface with the credit risk system / core banking

system to obtain the rating for all the counterparties.

8.7

The system should be able to extract the tenor-wise PD/LGD data from the credit

risk system / core banking system or calculate it based on credit spreads of the

counterparties

8.8 The system should follow distributed processing to reduce calculation time

8.9 The system should be able to attribute the CVA for counterparty to instrument level.

8.10 System should provide ability to compute Credit Value Adjustment (CVA) as

prescribed by RBI in Basel-III guidelines.

8.11

The system should be capable of arriving at the Exposure at default and compute

capital risk charge using Current Exposure method at trade level as well as

counterparty level


8.12 The system should be able to classify trading positions into Interest rate and FX as

advised by RBI

8.13 The system should be able to apply the standard credit conversion factors as

prescribed by the RBI

8.14 System should provide ability to compute CVA on marginal basis and standalone

basis at trade level and portfolio levels

9 Control specification for the system

9.1 The system should have interface level controls for data extracted from the treasury/

market risk system

9.2

The system should allow for three levels of access:

- User administration access to parameterize the model

- IT administrator access to configure screen level rights

- GUI to review and view output from the system

9.3 The system should maintain an audit trail for data override functions used

9.4 Deviations in output from VaR models resulting from changing default

configurations should be logged by the system

9.5 In case of plug and play models used for VaR computation, the system should allow

for the same level of operational control as in-built models

9.6 Limits parameterized within the system should have auto-triggers and auto-mailers

to inform people specified within the user hierarchy

9.7 Pre-limit warning functions should be embedded with the system

9.8 Report on reconciliation showing difference in valuation between treasury and market risk

system if any should be generated in the market risk system

9.9

Access to data tables within the system should be possible only from pre-defined

interfaces or user entry screens. Ability to write to data tables by manual input at an

interface level is not acceptable.

9.10 Where RBI permits for reports to be uploaded to OSMOS, the system be able to

provide such an upload functionality

10 Other functional requirements

10.1

System should facilitate establishing a relationship between certain Credit and

Market risk drivers (such as Exposure amount / NPA % / PD % / VaR, etc) to

changes in macro-economic factors (such as GDP / Inflation / Interest rates, etc)

using statistical techniques such as regression

10.2 The system should be capable to model the Yield curve using minimum of six risk

factors to capture interest rate risk.

10.3 System should be able to divide the yield curves of, at a minimum, the major

currencies and markets into a minimum of six maturity segments

10.4

System should have an option whereby regulator/internal auditor is able to see all

the underlying data, trace its origins and understand how the risk models work with

other systems within the bank

10.5 The system should be able to interface with FTP system

10.6

The system should have the pre-built templates and should also have the

functionality for a business user to define and customize Market Risk MIS across all

matrix dimensions such as:

Counter-party

Portfolio


Product

Geography – country/ state/

Sectoral Concentrations

Risk Profiles

Rating wise

Delinquency buckets

VIII. FUNCTIONAL REQUIREMENTS IN RESPECT OF PILLAR- II, PILLAR- III &

BASEL III AND INTEGRATED CAPITAL COMPUTATION MODULE

Sl. No Pillar II, Pillar- III & Basel III & Integrated Capital Computation Module

Functional requirement

1 Reporting

1.1 A reporting Tool with a presentation layer

1.2 An ETL tool for extraction of capital computed from the four respective systems

(CRMS, ORMS, MRMS and ALM/FTP)

2 Data Model

2.1 The solution should provide a single data model to serve as a single repository for

all the Market Risk, Credit Risk, Operational Risk, ALM and FTP Solutions

2.2 Provide a Physical Data Model

2.3 Provide the ability to perform data transformation

2.4 Provide the ability to execute the calculation of each of the concerned applications

directly from the Data Model

2.5 provide a single framework for the definition of calculation runs across all

applications (Market Risk, Credit Risk, Operational Risk, ALM, FTP)

2.6 Provide a single mechanism for batch execution across applications

2.7 provide the ability to trace data calculations across the applications

3 Capital Planning

3.1

System should enable capture of requisite data and for user defined periods for

development of the capital plan at the bank and at sub portfolio levels such as but

not limited to:

• Balance sheet and PL estimates

• Anticipated growth in top line/revenue year on year, profitability margins, costs

• Increase in risk weighted assets

• Capital types, amounts, maturity (for non-equity), capital cost.

• Risk Adjusted performance measures across various business lines and products

3.2

The system should have capital planning and budgeting modules for estimating

bank-wide capital for future, stress testing by changing assumptions/

macroeconomic scenarios, allocation across business units, geographies, products

etc., if needed.

4 Market Disclosure/Pillar-3 Report (as per RBI guidelines on BASEL II/Basel-

III).

4.1

The system should generate all reports necessary for complying with Pillar-III of

Basel- II/Basel-III norms. These reports include but are not limited to:

Residual Contractual Maturity Breakdown of the whole portfolio broken down by

major type of Credit Exposures


4.2 Exposure -weighted average LGD/EAD for each borrower category.

4.3 Securitization disclosure (Total outstanding exposure securitized by bank broken

down by type of securitization (traditional/Synthetic), exposure type.

4.4 Amount of NPA securitized broken down by exposure type.

4.5 Securitization exposure retained/purchased broken down by exposure type. (This

report would be generated for user defined period and as of date).

4.6 Report on capital market exposure as required as per RBI requirement – account

wise as per limit and outstanding exposure – on and off balance sheet

4.7 Report on exposure to Real Estate – commercial and residential – direct and indirect

4.8 Report on exposure to commodities

4.9

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

4.10 Report on Interest rate wise break up of advances – segment wise - as per user

defined range of rate of interest

4.11 Report on position of unsecured exposure – public sector/private sector/rating

wise/interest rate wise/maturity wise

4.12 Report on break up of term loans, project finance, bills purchased/discounted or

negotiated, demand loans – as per residual maturity

4.13 Report on pre payment of total/ installment of term loans, project finance, bills

purchased/discounted or negotiated, demand loans

4.14 Report on segment wise exposure –Report on future draw down schedule for term

loans,project finance and infrastructure projects

4.15 Report on single borrower/group borrower exposure – user defined number of top

exposure vis-à-vis prudential exposure limits fixed by bank/regulator

4.16 Rating Wise Distribution of Credit Portfolio Report

4.17 Audit log report

4.18

Overrides performance reports – performance of accounts where there is rating

over-ride or downgrades (Branch wise / region wise /geography wise/level

wise/approving user wise rating cases processed, approved, rejected and pending for

user defined period.

4.19

The system should support portfolio-based calculation like Limits Management:

Bank may define a limit cap (may be absolute or % terms) to an industry, borrower,

individual exposure, and bank, sovereign, rating. The system would check the same

and generate reports. What if/Incremental risk analysis by addition of individual

loan portfolio for decision making purpose. Portfolio based calculation should take

into account industry correlation to arrive at capital requirement.

4.20

The system should provide facility to generate customized report for user like Top

Mgmt, Risk Management Dept, Regional office, Branch Manager, and Relationship

Manager etc. Graphical representation of reports, wherever required. Access to

certain reports would be restricted to certain groups.

4.21 The solution should have the flexibility of viewing the reports at an aggregated level

or at granular level.

4.22

The system should be capable of capturing the distinct elements of Tier-1 and Tier-2

capital under Basel-II/Basel-III norms and it should be able to report total Tier-1 and

Tier-II capital at any point of time.


4.23

The system should apply the discount factor in case of subordinated debt based on

RBI guidelines and only eligible portion of subordinated debt should be taken as

Tier- II capital

4.24

The system should facilitate the regulatory adjustments made to Common equity/

Tier-1/Tier-2 capital under Basel-II/Basel- III norms by appropriately linking with

source systems/facilitating manual entry. Examples of such regulatory adjustments

are reciprocal cross holdings, unamortized expenditure arising out of second pension

option etc.

4.25 Report on credit, market and operational risk information required for compiling the

risk profile template, which is furnished before RBI on a quarterly and annual basis

5 ICAAP and Pillar 2 Requirements

5.1

The system should have a Pillar-II module which supports ICAAP analysis of all

material Pillar-II risks of the Bank and do capital computation, for risks like

concentration risk (branch wise, RO wise, state wise, industry/ sector wise, product

wise, vertical wise rating-grade wise, interest rate-wise, group-wise, borrower-wise

etc), reputation risk, strategic risk, compliance risk, underestimation of risk under

standardized approach, model risk, liquidity risk, interest rate risk, forex risk etc, as

per relevant RBI/ Basel guidelines on Pillar-II.

5.2

The system should perform stress testing for each of the credit, market, interest rate,

forex, liquidity, concentration risk on individual basis and aggregate the results of

stress testing. The system should at the same time assist in reporting, back testing

and assessment of capital for Pillar-II risks including impact on account of stress

testing. Additionally, the system should also support aggregation of Pillar-II capital

into Bank-wide capital (regulatory & Economic capital) assessed.

5.3

The System should be able to support and have the necessary statistical tools to

validate the material risk estimation methodologies and stress testing methods under

Pillar-2.

5.4

The system should have capital planning and budgeting modules for estimating

bank-wide capital for future, stress testing by changing assumptions/ macro-

economic scenarios, allocation across business units, geographies, products etc, if

needed.

5.5 The system should be able to generate risk maps, risk charts, reports, trend analysis

etc for Pillar- II risks, various risk dashboards for the users and top management.

6 Basel-III Requirements

6.1

The system should have the capability for computation of non-risk based leverage

ratio as per RBI/ Basel-III guidelines. The system should have the flexibility to

enable reporting and estimation of each capital components like common equity,

Additional Tier-1, Tier-2 etc as per prescribed guidelines of RBI under Basel-III.

The Pillar-1, Pillar-2 and Pillar-3 modules should be compliant with RBI‟s Basel-III

requirements also.

6.2 The system should be capable to compute Liquidity ratios (LCR,NSFR and stock

approach ratios) as per Guidelines on Liquidity Management under Basel III

6.3 System should have the capability to compute CVA under Basel-III guidelines.

6.4 The system should be able to compute capital requirement for bank‟s exposure to

central counter parties


7 Overall Functionality

7.1

The solution should have the functionality to extract computed Credit Risk capital

numbers, computed Operational Risk capital numbers, computed Market Risk

capital numbers, Pillar-II capital numbers if any (e.g. for concentration risk), Pillar-

II stress testing capital and Pillar-III capital (if any) from the respective systems /

applications and compute the overall CRAR (Capital to Risk Weighted Assets

Ratio) of the Bank for regulatory and internal reporting

IX. FUNCTIONAL REQUIREMENTS OF ALMS

Sl. No. ALM Functional Requirements

1 Computation Requirements

1.1

generate cash flows for all assets and liabilities with or without embedded

optionality, by utilizing market or internal data, or by means of behavioral analysis

as appropriate

1.2

bucket each on- and off-balance sheet asset and liability in line with extant RBI

guidelines for SLS, Interest Rate Sensitivity – TGA and Interest Rate Sensitivity –

DGA. Also allow user to define custom buckets for additional analysis.

1.3

compute coupon, yield for each bucket and the macaulay duration, modified

duration and modified convexity as applicable to each on- and off-balance sheet

asset and liability in line with RBI guidelines on DGA computation, incorporating

data from market sources as well as bank internal sources

1.4

evaluate the bank‟s position with respect to various duration, maturity-mismatch and

any other limits established in the system by the Bank to monitor ALM position

across geographies, portfolios and jurisdictions

1.5 generate automated threshold alerts and drill-down reports on any breaches of limits

established in the system

1.6 Allow bank to define new products, new coupon/yield computation logic and new

bucketing rules without extensive rework and recoding.

2 Behavioral Analysis

2.1

allow user to configure behavioral analysis using RBI guidelines, trend analysis,

historic data and user inputs for at least the following assets and liabilities with no

contractual maturity, from the perspectives of SLS and IRS reporting:

Current and Savings Bank Deposits

Overdue Deposits

Term Deposits

Bills Payable

Cash Credit and Overdraft (CC/OD)

Prepayment of Term Loans

Un-availed Portion of CC/OD/WCDL

Devolvement of LCs/Guarantees.

2.2

provide a choice of statistical models to analyze behavior of assets and liabilities,

including but not limited to, the following:

Drawdown analysis

Rollover analysis

Prepayment/Early redemption analysis


Past due analysis

2.3

back test behavioral analysis assumptions by means of industry standard tests

(Conditional coverage tests, unconditional coverage tests, duration tests, etc.), in

order to assess accuracy of expected behavior.

2.4 compare and tabulate expected versus actual historic behavior and enable an

analysis of reasons for deviation, if any

2.5 allow user to tweak behavioral study assumptions and provide estimates of changed

behavior to enable accurate recalibration

3 Liquidity Risk Monitoring

3.1 Liquidity Risk

3.1.1

Monitor daily risk positions through cash flow gaps and maximum cumulative

outflow measurements. Intra-day bank liquidity position and currency-wise open

position reporting included in this requirement.

3.1.2

generate and monitor all ratios relevant to liquidity, including but not limited to, the

following:

Liquidity Coverage Ratio and Net Stable Funding Ratio in line with RBI guidelines

on Basel III implementation

Market Value of unencumbered High Quality Liquid Assets (HQLA) required for

the bank to meet regulatory liquidity coverage ratio requirements

Actual vis-à-vis regulatory levels of CRR and SLR

Regulatory monitoring ratios:

(Volatile liabilities – Temporary Assets)/(Earning Assets – Temporary Assets)

Core deposits/Total assets

(Loans + mandatory SLR + mandatory CRR + Fixed Assets)/Total Assets

(Loans + mandatory SLR + mandatory CRR + Fixed Assets)/Core Deposits

Temporary Assets/ Total Assets

Temporary Assets/ Volatile Liabilities

Volatile Liabilities/Total Assets

Impact of stress scenarios such as drying up of funding sources, increased market

volatility, bank-run, etc. on the bank‟s liquidity position

Utilization against contingency plan triggers and limits

Any other ratio required by the Bank from the perspective of stock approach

liquidity management (Swapped Fund Ratio, Credit Deposit Ratio, Loan losses to

net loans, etc.)

3.1.3 allow user to configure liquidity ratios and trigger/limit levels through a graphic user

interface, defining the numerator and denominator out of bank balance sheet inputs

3.1.4 provide an overall consolidated view of the total market liquidity risk faced by the

Bank by virtue of its current portfolio

3.2 Liquidity Stress Testing

3.2.1

possess a robust stress testing engine to simulate systemic and specific events

including but not limited to, the following

Deterioration in firm‟s credit rating

Run-off of non-contractual liabilities using statistical approaches

Periods of combinations of sudden and prolonged market volatility

Greater than expected drawdown of non-fund based exposures


3.2.2 should be capable of analyzing the impact of concentration of funds by source,

borrowers and currency to identify significant sources of market liquidity stress

4 Scenario Analysis

4.1 produce budgetary and customer scenarios defined by type of contract.

4.2 scenario-dependent projections of future earnings, balance, market values, yields,

cash-flows, etc.

4.3 measure earnings effects, future liquidity risk, and product-inherent optionality risk

4.4 allow user to simulate new business, by defining volume projections, instrument

characteristics, price rate models, and maturity schedules

4.5 perform income simulation: Future Earnings and capital requirements.

4.6

provide a robust cash flow engine as part of the system that supports at least, but not

limited to, the following:

Conventional amortization (EMI)

Annuity payments with fixed maturity

Annuity payments with variable annuity

Principal only

Balloon/Bullet/Staggered payments

Amortization for floating rate instruments

Customized (user-supplied) amortization schedules

Negative amortization

NPAs and Restructured accounts

Instruments such as Bonds, Swaps, Repos, Reverse Repos, CDS, futures, options

(cash-flow, swap, cap/floor) and forward rate agreements

Instruments without embedded optionality (E.g., CASA deposits)

Off-balance sheet assets and liabilities without defined maturities (E.g., LCs, LGs)

4.7

model instrument / account level prepayment assumptions by, but not limited to, the

following methods:

By specifying a constant flat percentage of the current balance

By specifying prepayment rates based on either age, term or rate characteristics

By specifying mathematical relationships between prepayment rates & bank lending

rates/spreads over base rate

By incorporating seasonality adjustment factors based on past xperience for

prepayments

4.8

support the choice of at least the following term structure models (including

noarbitrage

models):

Merton

Vasicek

Ho & Lee

Extended Vasicek

5 Data Requirements

5.1 Market Data Sourcing

i.

capture price/volatility/spread data relating to a broad range of products from

different data providers, to allow the Bank to record its current and likely future

treasury activities accurately, including, but not limited to, the following:

Fixed Income Investments (Central Government Securities, State Government


Securities, Other Approved/SLR Securities, Treasury Bills, Cash Management Bills,

Corporate Debt, Commercial Paper, Certificates of Deposit)

Stock Investments (Equity, Preference Shares and Mutual Funds)

Lending and Borrowing Operations (Repo Transactions, Reverse Repo

Transactions, Interbank Lending Operations, Central Bank Lending Operations, Call

Money, Notice Money, Refinancing operations - NABARD, SIDBI)

Over-the-counter and Exchange traded Derivatives (Exchange Traded Futures,

IR/Fx Swaps, Credit Derivatives, Cross currency swaps, Fx Options, Interest Rate

Options, Forward Rate Agreements)

ii. Allow addition of new market data sources. E.g., configure the system to obtain

equity price information from Bloomberg in addition to Reuters

iii. source time stamped market data (e.g., Open/ High/ Low/ Close) across multiple

markets, taking to account varying business hours

iv. allow user to configure intraday timings for sourcing market data

v. allow user to configure change in market data source as either temporary or

permanent

vi. allow user to configure alternative data source in case of failure of primary source

system (E.g., BSE prices when the NSE price feed suffers disruption)

vii.

Obtain information from external sources on historic values of various risk factors

(E.g., equity index and individual equity prices, forex prices, commodity prices,

spreads over benchmark curves for Bank/PSU/FI/Corporate rated bonds, etc.)

relevant to market risk computations. Historic data for at least last 5years should be

available.

viii. allow modification of input price/curve data as required by the pricing model, e.g.

transforming quarterly quotes into monthly prices

5.2 Static & Reference Data Sourcing

i.

source reference data from relevant sources including:

Instrument reference data for (past, current and future) traded products. (E.g.,

Bloomberg/Reuters/FIMMDA ticker, Index constituents, etc.)

Internal Desk/Book hierarchy data

Product hierarchy data (e.g. relationship of asset classes, instruments and

subproducts

Counterparty data including a standardized, organization-wide counterparty

hierarchy

Calendar / business day conventions

Static data values (e.g. country codes, currency codes etc.)

ii. allow definition of new reference data types and modification of pre-defined data

types (E.g., addition of a new level in the product hierarchy)

iii. allow sources of reference data to be changed, and the reference data should have an

attribute identifying data source

iv. support all types of day count basis including 30/360, Actual/360, Actual/365,

Actual/Actual, 30E/360

v.

support International Swaps and Derivatives Association (ISDA) -defined business

day conventions such as following, modified following, preceding, next month, this

month, average of the month etc.

vi. support user defined reprising to input changes in asset prices that do not flow from


data feeds

5.3 Holiday Calendars

i. load calendar schedules from external sources including but not limited to SWIFT,

International Holiday schedule and Bloomberg holiday schedule etc.

ii. allow users to set calendar schedules through interfaces/ patch updates

iii. allow configuration of multiple holiday tables for each currency and country

iv. allow users to input calendar schedules at least 7 years forward

v. edit and override global calendar and holiday tables

vi. flag trades executed on a global holiday through exception messages and exception

reports

vii. define settlement instructions based on emergency holidays

viii. model cash flows and interest accruals based on holiday calendar and standard day

roll conventions

5.4 Position Data

i. retrieve position data from treasury system to perform valuations

ii. allow user to create, save and load portfolios of bank‟s position in various

instruments/ currencies

iii. automatically recalculate the trade or portfolio value if (relevant) market rate

changes are detected

iv.

allow user, based on access rights, to create portfolios across all dimensions (E.g.,

Bank-wide, HFT/AFS/HTM, Trading Book, commodity, Risk factor, individual

position, Trader, currency, delivery location, Trade type, Time bucket, etc.)

v.

support different types of portfolio revaluation methodologies: marginal, full, no

recalculation, manual, timed (i.e. every 10 minutes, batch), etc., or any portfolio-

wise combination of the same

vi. provide various options to value the Bank‟s investment portfolio: current market

rates, freeze current market rates (snapshot), etc.

vii. facility to specify if portfolio should be loaded as of a specific date in the past

viii. select Position / Price / Liquidation methodology for aggregated positions: Average

Cost, LIFO, FIFO, Max Profit, Least Profit, User defined

ix. display information at trade and portfolio levels

x. display valuation results using drill down capabilities (e.g. Local Currency, Base

Currency, Reference Currency)

xi. display portfolio results, where possible, by a user definable maturity grid

xii.

bucket portfolio open positions into the maturity grid using industry standard

methodologies: Previous Bucket Point, Following Bucket Point, Proportional ,

Nearest, Delta Equivalent, Proprietary, etc.

xiii. create, name, save and load portfolio „views‟ as result of the previous choices

xiv.

provide Hedge Effectiveness Testing and Portfolio Optimization functionalities. I.e.,

the system should be able to compute the effectiveness of hedges as well as to

determine the optimal portfolio composition given various constraints (E.g.,

minimum/ maximum investments in certain assets)

5.5 Data Upload

i. time stamp and record data source for each data upload

ii. allow user to decide the frequency and mode of data upload, e.g., timed update or

continuous update


iii. upload position, rate and valuation information of the investment portfolios of local

as well as overseas branches to allow consolidated reporting

5.6 Data Overrides and Adjustments

i. allow users to apply adjustments to address erroneous values via single point

changes or mass updates

ii. log data corrections and communicate the same to relevant upstream/ downstream

systems

iii. maintain an audit trail of data changes made by users

iv. allow reversal of changes made based on access rights given to different levels of

users

5.7 Data Validation

i. validate user entered data at the time of data sourcing, preferably by field input

controls, e.g., format of input, date checks, etc.

ii.

support configurable data checks on consistency and integrity of all data inputs

(market data obtained from different data providers, position data from treasury

systems, etc.). The checks should be configurable on single data points as well as on

groups of data, e.g., curves

iii. support validation of uploaded data by means of business rules with configurable

parameters

iv. ensure that there are effective checks and controls to ensure that transactions are not

loaded multiple times in the host system, i.e., duplication checks

v. perform data validation to reconcile position data in the treasury system with market

risk system

5.8 Data Storage and Archival

i.

store on a daily basis the following information:

Position and transaction data at a granular level present in the Bank‟s portfolio

Market data (yield curves, volatility curves, Fx Spot and Forward prices , FX

volatilities)

Market prices (for quoted instruments) and book value for instruments that are not

traded often

Net Present Values(NPV), MTM and Greeks at transaction and aggregated levels

Value-at-Risk at transaction and aggregated levels

Scenario Results at transaction and aggregated levels

Profit & Loss results at transaction and aggregated levels

ii. import historical market prices files from external vendors for volatilities and

correlations calculations for transactions on new markets

iii.

import historical position information either directly from existing systems or in the

form of data upload files to allow easy system migration, generation of historical

results and also to mitigate the impact of incorrect data uploads

iv. store historical market rates information through automatic end-of-day procedures

and historical results for at least 10 years

v. store the complete set of data used as input to calculations performed by the system

vi. allow users to view complete data snapshot of any previous business day

vii. support storage of all current and historical position, market and reference data on a

daily basis, and allow users to view the complete set of data for any given day


viii. store system-generated data points (e.g. interpolated values), with configurable flags

determining whether or not data is stored

ix. transform data from source format to a standard format for storage/ archival

x. provide data mining functionalities (e.g. identifying from a set of historical data the

worst one month/quarter/year)

xi. support archiving of data that are beyond a specified time horizon

xii. export data to secondary storage device without down-time

xiii. support data retrieval from the specified archives. The archival and retrieval

programs should facilitate easier analysis of old data.

xiv. in-built Data warehousing capabilities or standard interface with Data warehousing

solutions

5.9 Data Quality and Statistics

i. provide an analysis of data quality, i.e., completeness and accuracy of inbound /

outbound data feeds and reporting on key data quality metrics

ii. provide a tool for automatic verification and validation of uploaded data with

appropriate measure of correction

6 Reporting Requirements

6.1 Aggregation and Drill-down Capabilities

6.1.1 record information to identify various dimensions of ALM reporting from the

perspective of aggregation, including, but not limited to:

i.

multiple currencies: To handle all currencies the Bank has rate-sensitive exposure

to. The system should also be able to convert all currencies to the Bank‟s reporting

currency (INR) using FEDAI spot rates

ii. multiple departments: To allow rule-based access to different departments as

required

iii. multiple products and product categories: To handle all risk sensitive assets and

liabilities that may be present in the Bank‟s portfolio

6.1.2 allow rule-based aggregation to identify exposures across each dimension above

6.1.3

drill-down from the interest rate sensitivity, structural liquidity and any other

analysis to a granular level (E.g., Product level, portfolio level, geography level,

etc.)

6.2 Reporting and Analysis

6.2.1 reporting should be compliant with regulatory requirements

6.2.2 predict possible business volumes, maturity patterns, etc. utilizing historical data

and simulation

6.2.3 report at any level of detail (drill down and aggregate)

6.2.4 build customizable hierarchical roll up structure

6.2.5 provide graphical representation of reports as appropriate report across product,

account, and business unit

6.2.6

perform the following analysis:-

Interest Rate Risk in the Banking Book and Trading Book: Interest Rate Sensitivity

Analysis – Traditional Gap Analysis and Duration Gap Analysis

Structural Liquidity Analysis

Re-pricing balance sheet/gap analysis

Cash flow balance sheet

Breakup of cash flow and balance sheet into deterministic (contractual assets and


liabilities) and dynamic (non-contractual assets and liabilities)

Market value balance sheet (present values)

Value effect: economic value sensitivity key rate duration

Scenario analysis (parallel shifts, non-parallel shifts)

Trend analysis

Static profitability analysis: yield report

Effective yields

Market Value Sensitivity (MVS)

Market Value of Equity (MVE)

NII and NIM analysis

Behavioral analysis for rate sensitivities with embedded optionality

6.2.7

generate standard reports for following:

RBI mandated Structural liquidity reports:

Domestic Currency – Indian Operations

Foreign Currency – Indian Operations

Combined Indian Operations – Domestic and Foreign Currency

Overseas branch Operations – Country-Wise

Consolidated Bank Operations

RBI mandated Interest Rate Sensitivity reports to monitor Interest Rate Risk in the

Banking Book and Trading Book:

Traditional (Static) Gap Analysis

Duration (Dynamic) Gap Analysis

RBI mandated Short Term Dynamic Liquidity Statement

Currency-wise mismatch reports

Cash flow projections

Bucket-wise mismatch reports

Variance analysis

Mark to market reports

Net Interest Income reports

Economic Value of Equity Analysis

Product/ Account Level Profitability Analysis

Line of Business Level Profitability Analysis

FTP Division of spread analysis, by lending, funding and interest rate risk spreads

Total Organizational Level Profitability Analysis

Cost of Fund by Product/Account

Net Interest Margin Analysis

Key early warning/risk indicators

Status of contingent funding sources

Interest Rate Risk Analysis/Reporting

Value at Risk Analysis and Reporting

Earnings at Risk Analysis and Reporting

Market Value - deterministic and stochastic

Scenario Income reports

Gaps statement based on contractual maturity

6.2.8 provide querying facilities to build own queries


6.3 Report Customization

i. provide a user-configurable ALM dashboard

ii. provide user-definable time buckets

iii. provide user-definable chart of accounts, classification, sub-classification, maturity

buckets, reference rates, yield curves, currencies etc.

iv. Ratio Builder, which allows users to define any number of categories and ratios

v. support custom report designing

vi. allow users to specify the exact layout of the required report including location of

fields, header, footer, page numbering, title etc.

vii. allow users to define structures and fields of each report by selecting fields from

databases of their choice

viii. provide a report writing wizard that provides users with step by step menus and

allows them to draw up reports in the required format

ix. allow users to present outputs from reports in the form of graphs, charts and other

graphical representations

x. allow for sorting of data in reports

xi. isolate and report errors and exceptions

xii. allow user defined filters

xiii. customize reports with respect to time period considered, portfolios considered,

levels of granularity, etc.

6.4 Scheduling of Reports

i. generate pre-defined end-of-day, end-of week and end-of month reports

ii. generate pre-defined reports with minimum user interference

iii. define a schedule for reports and reports should be generated as per the frequency

defined by the Bank

iv. allow defining the users to whom reports can be automatically sent

6.5 Archiving of Reports

i. archive historical reports

ii. archive historical rates extracted from market information systems

6.6 Ad hoc Reporting

i.

allow users to customize standard reports for their own profile (E.g., different

portfolio, specific time period, comparing with historic results), without affecting

reports generated by other users

ii. allow users to configure what-if analysis to analyze the impact of new positions,

amendments to existing positions, unwinding positions, etc.

6.7 General Requirements

i. generate all regulatory reports required in appropriate regulatory formats

ii. provide pre-configured internal reports in standardized templates, for effective

market risk management.

iii. allow user to configure and generate new ad hoc reports and save report

configuration in user profile

iv. retain historic report information to compare report outputs over a configurable time

period (E.g., previous day or previous month end)

v. distribute reports according to user-configurable distribution parameters, e.g., email

to a generic inbox, save to a server location, etc.


7 FTP Requirements

7.1

provide distinct modules to approach FTP, enabling the user to define the interest

rate environment, interface with the bank systems for information on the product

portfolio, establish costing rules at a desired level of granularity, analyze the cost of

source and use of funds and generate appropriate end user reports

7.2 provide flexibility to choose from multiple FTP methodologies (Cost of funds/ Net

Funding/Pooled Funding/Matched Maturity)

7.3

generate the Base FTP curve for each use and source of fund on the underlying

account or transaction attributes at the time of origin at a granular account-level

using matched maturity methodologies such as bullet, cash flow and weighted

average life funding

7.4

generate the base FTP curve by combination of multiple yield curves for different

maturities, as a combination of:

Treasury rates

Funds pool

Bank cost of funds

Target borrowing rate

Swap curves

CD rates

LIBOR/MIBOR

7.5

view FTP rates across at multiple granularities:

product

business unit

branch

Bank/ entity

7.6 analyze profitability at various levels by generating the economic value and the

corresponding FTP rates

7.7

calculate liquidity cost for:

on-balance sheet assets consuming liquidity based on tenor at origination date and

on marginal cost.

contingent liquidity risk (cost of holding stand-by liquidity buffer to cover

unexpected liquidity needs and cost of roll-over risk)

other categories of possible liquidity risk exposure (E.g., country risk cost due to

extension of funding to clients in non-fungible currencies)

7.8

calculate, assign / allocate FTP costs, behavioral models or pricing assumptions

based on the following:

Basis risk

Liquidity risk

Funding rates (Base Government ZCYC rate/ LIBOR/MIBOR)

Fixed rate structural funding cost

Option cost

On-balance sheet and off-balance sheet products

7.9 project and price undrawn off-balance sheet items, including contingent

commitments, by means of stress and scenario testing

7.10 quantify impact due to change in FTP rates, methodologies, behavioral models,

volumes, changes in key stress assumptions, etc.


X. TECHNICAL REQUIREMENTS

Sl No: Technical Requirements

1 User Interface

1.1 The system should provide a consistent and easy to use graphical user interface

1.2 The system should be capable of interfacing with mail clients to generate

notifications and auto-mailers.

1.3 The system should provide the facility to upload/download data to/from peripheral

systems to be provided as and when required.

1.4 Report Creation utility should be provided for the user to generate new reports

1.5 The system should provide user-friendly design, short-cuts, smart tags and other

productivity features

1.6 The system should support configurable graphical display of historical, current and

forecast figures and analysis

1.7 The system should provide tools for validation of data inputs that are captured from

the existing applications of the bank

1.8 The system should provide for validation of data inputs that are subject to re-entry

or manual intervention

1.9 System should provide users with the option to print, i.e. print to files of various

formats, print to printer etc.

1.10 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)

· Extended Markup Language(.XML)

1.13

The system should perform queries against database irrespective of the

technology/solution to be implemented. It should store and retrieve data from

existing systems and databases andf should provide an application programming

interface to access outside programs

1.14

System should have the provision to have Edit Check

• perform logical edit checks on all input fields

• provide intelligible edit error messaging based on pre-defined parameters to assist

correction and re-entry of data

• reject entries that cause edit errors

• provide ability to over-ride edited errors

1.15 The system should allow multiple users to access the system simultaneously


1.16 The users should have single point of access, to access all functionality available to

their user account through a single entry point.

1.17 The system should be able to generate reports as per the Automated Data Flow

(ADF) requirements of the bank.

1.18 The system should interface with accounting modules/systems in place at the bank

1.19 The system should incorporate customizable templates and Built-in data entry form

for the cases which are not captured through any other business application

2 System Architecture

2.1 The solution should be in web based technology in a three tier architecture

2.2

The system should provide for capture and utilization of static/dynamic data

associated with counterparties, products, accounts, etc, from the existing

applications in the Bank such as Core Banking Software, Treasury systems, HRMS,

FAMS etc.

2.3 System should be able to Extract, Transform and Load data from the source systems

2.4 The system architecture should be modular; separate modules of the system should

run independently

2.5

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 licensing costs during the implementation and AMC period.

Up-gradation to Basel III should be possible with the proposed solution

2.6 The solution should be flexible and Expandable to accommodate future up

gradation/ modifications.

2.7 System outage time due to events such as server down, application down etc. should

not exceed the minimum tolerable downtime defined by the bank for the application.

2.8 Overnight reports generated by end-of-day processing should be ready at a time

agreed in the system SLAs on business days for each time zone

2.9 In the case of a system failure with no loss of data, restore to an operational state

within standard hours of service as defined in the SLA.

2.10

In the case of a system failure and the loss of data integrity, restore to an operational

state with the most recently backed up data within an acceptable timeframe as

defined in the SLA.

2.11

In the case of a system failure mid-processing, resume all processes at an interim

point if possible and reasonable and if resulting in significant re-processing

computation time savings.

2.12

The system should support prioritization functionality to ensure standard processes

have sufficient resources to run within required timelines without being affected by

ad hoc user requests.

3 Data Archiving Back up & Disaster Recovery

3.1 System should support archiving of data that are beyond a specified time horizon, to

prevent long term speed concerns.

3.2 The system should allow have a day end back up process

3.3 The system should also have recovery features in case of system failures

3.4 Back up should be possible in external media (CD, tapes, DVD) for off‐ site storage

3.5 System should support archiving of data that are beyond a specified time horizon

with facility to parameterize.


3.6 Export of data to secondary storage device should be supported by the system

without down time.

3.7 System should support data retrieval – from the specified archives. The archival and

retrieval programs should facilitate easier analysis of old data.

3.8 The system should generate error logs if the calculation fails during time of data

processing

3.9 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”

3.11 The solution should support disaster recovery procedures to 'cutover' from a primary

site to a secondary site

3.12 The solution should resume processing using the disaster recovery secondary site

within the time limits stipulated by the bank from time to time

3.13 Performance requirements of the secondary disaster recovery site, when activated,

should exactly match those of the primary site

4 Security management & Audit Requirements

4.1 The system should provide for user profiles to be controlled by a specific

administrator

4.2 System access should be permitted only through password verification with all user

IDs being unique

4.3

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.4

The system should have the ability to provide or restrict access privileges based

upon hierarchy and multiple criteria eg. user access on weekends and holidays,

hours through which the system would be accessible etc

4.5 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.6

Standard password management features should be configurable as per Bank's

policies e.g.

Strong password control features such as minimum/maximum length, alpha-

numeric, special characters , history of passwords etc

· Automatic user disabling after a certain number of successive erroneous tries

prescribed by bank

· Automatic user time-out on inactivity for a predefined time duration

4.7 System should provide for creation, deletion and modification of users, upgrades of

users and data access rights

4.8 User id and login should determine level of access to data e.g. read/view data, print

data, write/modify data, delete data etc.

4.9 There should be a maker-checker 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, Date-time etc.

There should also be audit trail that includes details of databases accessed and

modified by the users.

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 such as user details, timestamp etc.

Changes made should be able to be rolled back to a previous state.

5 Reporting & Others

5.1 The system should provide all necessary regulatory reports pertaining to Banks as

required by the Reserve Bank of India and/or as requested by the Bank.

5.2

System should provide various other reports in the formats to be provided by the

Bank. Important MIS reports should have the facility for drill-down where necessary

in risk reporting, management reporting, internal capital allocations and risk analysis

5.3

The reporting functionality should cover all areas of risk exposures and different

types of reports should be structured for Strategic Business Units, Senior

Management and Board of Directors

5.4

The calculation formulae, data flows and processes associated with the risk

measurement system should be transparent and easily accessible. In particular, it is

necessary that auditors and supervisory authorities are in a position to have easy

access, whenever they judge if necessary and under appropriate procedures to the

system‟s specifications and parameters

5.5 The system should allow users to present outputs from reports in the form of graphs,

charts and other graphic representation in a user friendly set up

5.6

The system should have capability to report against multiple dimensions

simultaneously. The system should provide Dash boarding capabilities with specific

access rules defined for each user.

5.7

The reporting interface should be capable of interactive reporting with end user

having the option to create report across multiple dimensions in real time. The

system should be capable of generating alerts and trigger workflows based on

business events and notify stakeholders via their preferred medium and channel.

5.8 Exception reports should be sent to pre-defined users either through auto-mailers via

the email client or via pop ups within the system.

5.9

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.10 The system should allow reports to be exported into Microsoft Excel, Adobe PDF

format and other databases

5.11 The system should allow users to print reports directly from the system

5.12 The system should allow users to save reports to a disc in a non-editable as well as

an editable format

5.13

The system should generate reports in various types of files like:

· View Mode

· Excel Mode

· Text Mode

· HTML Table

· CSV format

· Word File

· PDF format

· XBRL format


BRL format

The system should allow for generation of pre-defined end-of-day, End-of week and

end-of month reports and ad-hoc reports when required

5.14

Reports generated in periodical wise or as defined by the Bank:

· Daily

· Weekly

· Fortnightly

· Monthly

· Quarterly

· Half-yearly

· Annual

5.15

The system should allow for archiving of external reports in the following formats

· Adobe PDF

· Microsoft Excel

· Microsoft Word

· Microsoft Access

· Comma separated values (.CSV)

5.16 Archiving of reports should be possible in a pre‐ defined format to facilitate ease of

retrieval

5.17 Reports generated by the system should be in XBRL format whereas system should

have capability to generate internal reports in PDF format.

6 General

6.1

The system should process, track and account for the necessary range of traded and

non traded currencies which includes USD, INR, EUR, AUD, CHF, JPY, GBP,

CAD, SGD, HKD, CNY,DKK, SEK etc.

6.2 The system should handle all types of day count basis including 30/360, Actual/360,

Actual/365, Actual/Actual, 30E/360

6.3

The system should load calendar schedules from external sources including but not

limited to SWIFT, International Holiday schedule and Bloomberg holiday schedule

etc.

6.4 The system should handle multiple entities that includes branches, subsidiaries etc.

6.5 The Bidder should provide a Data Mart to generate analytical reports to be used /

viewed by the Bank.

6.6 The proposed Data Mart should be able to integrate with the Enterprise-wide Data

warehouse solution which is going to be implemented in the future

6.7 The system should be capable to integrate with multiple types of transaction systems

and other existing applications of the bank

6.8 System should be capable to integrate with non transaction systems like Ratings

Data providers, Banks Internal Model/External model, CIF systems

6.9 System should be capable to integrate with standard domain controllers using

multiple integration mechanisms

6.10

Flexibility of system

• Allow for changes to be made to existing methodologies (e.g. reconfigure models,

change process steps in models etc.) and allow for the addition of new

methodologies via the necessary support intervention.


• Allow users to add, remove or amend data feeds, without requiring a change to the

system itself.

7 Integration

7.1

Integration with other systems should be facilitated by the following modes but not

limited to:

· Batch processing

· Online processing

· Real time processing

8 Documentation

8.1

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 – Application Architecture, Entity-Relationship diagrams, Data

base Scheme, Data dictionary, Source code.

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

engines used in the software

e) Error Messages and their meanings.

f) Training Manuals

8.2 Comprehensive documentation with indices or glossaries targeted at specific

audience of users, systems manager/administrator.

XI. AMENDMENT OF RFP:

At any time prior to the deadline for submission of bids, The South Indian Bank Limited, for

any reason, whether at its own initiative or in response to a clarification requested by a

prospective Bidder, may modify the RFP by amendment.

In order to afford prospective Bidders reasonable time in which to take the amendment into

account in preparing their bid, the Bank, at its discretion, may extend the deadline for the

submission of bid.

All bidders who have procured this RFP document from the Bank shall be notified of the

amendment in writing by e-mail or fax or post, and all such amendment(s) shall be binding

on them.

XII. INSTRUCTIONS FOR BID SUBMISSION

A. Request for Additional Information

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 (address for

communication is given in table titled „Bid collection and submission details‟ ). All queries

relating to the RFP, technical or otherwise, must be in writing only i.e. either via physical or

electronic mail. The Bank will try to reply, without any obligation in respect thereof, every


reasonable query raised by the Bidder in the manner specified.

However, the Bank will not answer any communication reaching the Bank later than 2.00 PM

on 15.03.2014.

B. Modification and Withdrawal of Bids

The bidder may modify or withdraw its bid after the bid‟s submission, provided that The

South Indian Bank Limited receives written notice addressed to CGM - Integrated Risk

Management Department, SIB House, 2nd Floor, Mission Quarters, Thrissur, and Kerala-

680001 of the modification or withdrawal, before the expiration of deadline prescribed for

submission of bids. In case of modifications, the bidder is expected to resubmit entire bid.

Only addendums/amendments will not be accepted.

C. Rejection / Acceptance of Bid

The South Indian Bank Limited reserves the right to accept or reject any or all the bids

without assigning any reason whatsoever. Any decision of The South Indian Bank Limited in

this regard shall be final, conclusive and binding on the bidder.

D. Cancellation of Bid

The South Indian Bank Limited reserves right to re-issue/re-commence the entire bid process

and or any part in case of any anomaly, irregularity or discrepancy in regard thereof without

assigning any reason whatsoever, at the sole discretion of The South Indian Bank Limited.

Any decision in this regard shall be final, conclusive and binding on the bidder.

E. Period of Validity of Bids

Validity Period: - Bids shall remain valid for 90 days from the last date specified for

submission of bis in this RFP. The South Indian Bank Limited holds the rights to reject a bid

valid for a period shorter than 90 days.

Extension of Period of Validity: - In exceptional circumstances, The South Indian Bank

Limited may solicit the Bidder‟s consent to an extension of the validity period. The request

and the response thereto shall be made in writing. Extension of validity period by the Bidder

should be unconditional and irrevocable.

XIII. SUBMISSION OF BIDS

A. Mode of submission

The bidder shall submit bid in a sealed and marked outer envelope. This outer envelope shall

be marked as “ORIGINAL: Implementation of Enterprise-wide Integrated Risk Management

Architecture in accordance with the International Best Practices and Guidelines of


RBI/BCBS on Basel II, Basel- III, ALM and FTP. In case the bidders opt to remit the non

refundable bid submission fee by way of DD, the DD shall be safely kept in the outer

envelope. If the bid submission fee is by way of RTGS, the UTR number shall be furnished.

In addition to the DD/UTR challan, this outer envelope shall contain following envelopes:

1. Envelope labelled as „Eligibility criteria‟:- This envelope shall contain the documentary

proof and annexure required if any in respect of each of the criterion listed out in Section-

XVI. The check list for submission of eligibility criteria is given in Annexure-4. This

envelope shall without fail contain the profile of bidder and his partner if any as specified in

Annexure-5

2. Envelope labelled as „Technical Bid‟: - The contents of this envelope shall assist us in

evaluation of technical and functional requirements of the software solution. This envelope

shall contain six inner envelopes, one each for Credit risk, Market risk, Operational risk,

ALM system and other functional capabilities (i.e integration, Pillar- 2, Pillar-3 and Basel-III)

and one for technical requirements. The inner envelopes shall contain the responses against

each of the functional/technical requirements under respective areas. The manner in which

the responses should be submitted is indicated in Section XVII.A. In addition to the hard

copy of the responses the envelope shall contain a CD containing the soft copy of responses.

It is mandatory to furnish the Technical & Functional Specification in the format attached in

the spread sheet uploaded along with this document. The hyperlink for downloading the

specifications is given below

Click on Logo to download

The correct information of the functional capabilities of product being offered should be

reflected in the responses. Any additional information available, though not included in the

form, may also be submitted. The format in the spread sheet has provision to indicate your

offer as well as deviation, if any.

In addition to the six envelopes mentioned above this envelope shall also contain a seventh

inner envelope. This seventh envelope shall contain all other contents of technical bid

specified in this section.

Content of technical bid

Implementation methodology as given in Annexure-6

Responses against functional and technical requirement specified in this RFP (as

indicated in above paragraphs).

Reference site details in the format specified in Annexure-7

Details of past experience as specified in the Annexure-8

http://www.southindianbank.com/UserFiles/file/RFP%20SIB%20EWIRM%20Functional%20and%20Technical%20Response.xlsx


The proposed project team profile as given in Annexure-9

The details of training programs conducted by the bidder in format specified in

Annexure-10.The documentary proof in support of these programmes in the customer-

Bank‟s letter head shall also be included in this envelope.

Any other relevant information

3. Envelope titled „Commercial Bid‟: - The commercial bid should be given by the vendors in

the format as shown in Annexure -12. 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, 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.

The price should be quoted for each item, each unit with total cost, module wise, if modular.

Prices for all items including optional items, if any, should also be mentioned. AMC for

each item year wise should be provided. The envelope labelled as commercial bid should

include the following:

The bid covering letter cum declaration format is given in Annexure-11

Details of cost of deliverables for each risk management system (also include cost of

integrated solution with all modules.)in the format given in Annexure-12

Annexure-13 containing the total cost of ownership computation

4. Envelope titled „Annexures‟: - This envelope shall contain all the Annexures specified in

this RFP, except for the annexures stipulated to be included in other envelopes. It shall also

include documentary proof required for substantiating the information given in Annexure, if

any. In addition to the annexures specifically listed out in this RFP this envelope shall also

include:

Technology, architecture of proposed solution, exact tools to be used

List of all software / tools to be used together with licensing details

Tentative project time schedule and plan

Project management, control and tracking mechanism

Quality control setup and procedures to be followed

Implementation & Training plan

Technical brochures and user manual

All envelopes should reach the Bank before 28th March 2014. All envelopes should be

securely sealed and stamped.


XIV. ADDITIONAL INSTRUCTIONS FOR BIDDERS

A. Source Code

i. Bidder has to keep source code of proposed solution with approved / recognized escrow

agency under escrow arrangements mutually acceptable to the Bank and Bidder but at

Bidder‟s cost.

ii. The application software should mitigate Application Security Risks, at a minimum; those

discussed in OWASP top 10 (Open Web Application Security Project)

iii. The Bank reserves the right to audit the Application / Source Code by suitable Security

auditor.

iv. The Bidder shall provide complete 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 as part of the project. The Bidder shall also indemnify the Bank

against any levies / penalties on account of any default in this regard.

v. In case the Bidder is coming with software or hardware which is not its proprietary software

or hardware, then the Bidder must submit evidence in the form of agreement it has entered

into with the software vendor or hardware vendor which includes support from the software

vendor or hardware vendor for the proposed software and hardware for the full period

required by the Bank.

vi. The bidder needs to produce certificates of quality control and security audit done on the

software in the recent past.

B. Software Delivery & Installation

The bidder will provide the complete compiled code. The bidder will supply the automated

Installation procedures. The bidder will install the application software on computers

(servers and selected desktops) of the BANK for Pilot implementation. Vendor will also

provide two sets of backup copies. The installation of the base product will be considered

complete only after demonstration of functional features of the software as given in RFP and

as per documented procedure and as acceptable to the Bank.

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.

C. Acceptance of software

The BANK will accept the developed/ customized software only after implementation of the

software with successful conduct of acceptance testing by users. Software will be considered

to be accepted only after the BANK issues an acceptance letter to the vendor. New Software


may be audited for risk analysis and security features by Bank‟s IS Audit team or a third

party vendor appointed by the BANK, if so desired by the BANK.

D. Inspection and Tests

i. Bank or its representative shall have the right to inspect and/or to test the software to

confirm their conformity to the requirements/specifications mentioned in this RFP at no

extra cost to the Bank.

ii. The inspections and test may be conducted on the premises of the vendor or its

subcontractor(s), at point of delivery and/or at the final destination. If conducted on the

premises of the vendor or its subcontractor(s), all reasonable facilities and assistance,

including access to drawings and production data, shall be furnished to the inspectors at no

charge to the Bank.

iii. Should any inspected or tested software fail to conform to the specifications, the Bank may

reject it, and the vendor shall either replace the rejected software or make alterations

necessary to meet specification requirements free of cost to the Bank.

iv. In case of failure to complete the testing for reasons attributable to the Vendor, all the

expenses incurred by the Bank or its representative towards travel, boarding and lodging in

this regard should be borne by the Vendor.

E. Information Ownership

i. All information processed, stored, or transmitted by successful Bidder‟s software belongs to

the Bank. By having the responsibility to maintain the software, 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.

ii. Any information considered sensitive by the Bank must be protected by the successful

Bidder from unauthorized disclosure, modification or access. The Bank‟s decision will be

final.

iii. Types of sensitive information that will be found on Bank system‟s which the Bidder plans

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

statutory protection, legal actions, disciplinary actions, complaints, IT security, pending

cases, civil and criminal investigations, etc. The successful bidder shall exercise adequate

judgment to decide if particular information is sensitive and consult with the Bank in case of

doubts.

iv. The successful Bidder shall not publish or disclose in any manner, without the Bank‟s prior

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

by the Bidder or existing at any of the Bank location. The Bidder will have to develop

procedures and implementation plans to ensure that IT resources leaving the control of the

assigned user (such as being reassigned, removed for repair, replaced, or upgraded) are

cleared of all Bank data and sensitive application software.


F. Adherence to Standards

The bidder should adhere to laws of land and rules, regulations and guidelines prescribed by

various regulatory, statutory and Government authorities in India. The Bank reserves the

right to conduct an audit/ongoing audit of the services provided by the bidder. The Bank

reserves the right to ascertain information from the Banks and other institutions to which the

bidders have rendered their services for execution of similar projects.

G. Security Configuration, Monitoring and Audit

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

applications should be done by the bidder, according to the industry best practices and the

Banks baseline Board approved documents.

ii. 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 audits

plan to include, but are not limited to, a review of: access and authorization procedures,

physical security controls, input/output controls, DB controls, backup and recovery

procedures, network security controls and program change controls.

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

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

data, the Bidder shall afford the Bank‟s representatives access to the Bidder‟s facilities,

installations, technical resources, operations, documentation, records, databases and

personnel. The Bidder must provide the Bank access to various monitoring and performance

measurement systems (both manual and automated). The Bank has the right to get the

monitoring and performance Measurement systems (both manual and automated) audited

without prior approval / notice to the Bidder.

H. Considerations for Proposed Hardware & Software to support the EWIRM Solution

i. All software like RDBMS should be of the latest tested proven bug-free version and should

be compatible to exiting RDBMS.

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

iii. Roadmap for the CPUs proposed for Database and Application servers should be well within

the time schedule for project implementation specified in this RFP.

iv. The proposed solution should facilitate application level encryption

v. Proposed solution shall be platform independent i.e. it should function both Intel based and

Risk based platform.

vi. 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 15 minutes and Recovery Time Objective (RTO) of 4 hours. The replication

between DC and DR should be possible in both directions.‟

vii. The bidder shall specify the suitable hardware and supporting software which shall deliver

the best throughput and performance considering the present volumes and the sizing

proposed should consider the probable increase in volumes for next 5 years. The necessary

information required by bidder to estimate sizing of the proposed may be obtained from the

bank (if required).

I. Performance Guidelines

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

solution components in minimum.

i. 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. The performance evaluation has

to be done considering SIB volumes and expansion pattern.

ii. The bidder has to explain through proper calculations how the performance of the system

vis-à-vis business statistics, projected growth, redundancy, projected growth in functional

requirements, concurrent users, performance parameters expected on peak load, VaR or

other parameter calculations, transactions handled per second, quarter end and year end

activity etc. are ensured. The bidder should provide data on any other parameter which

would be required.

iii. 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.

iv. 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.

v. The bidder should provide information on industry standard benchmarks for the system such

as TPC certified by Transaction Processing Council.

vi. The bidder has to furnish the details of the configuration of the servers, OS and databases

used in such benchmarking exercise for TPC etc. and relate the same to the server

configurations proposed for Bank‟s requirement.

vii. 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.

viii. The Bidder has to relate the same to the model and configuration of the hardware proposed

for Bank‟s requirement.

ix. 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.


x. The bidder may also furnish certified performance details from past implementations of

similar nature.

xi. Bank may advise the bidder to conduct the benchmark when the systems are ready for

dispatch to Bank‟s site or after completion of installation and evaluation of performance. It

is for the bidder to establish that the sizing is proper for the requirement and to demonstrate

the performance to Bank‟s designated officials and project consultants.

xii. It will be the responsibility of the selected bidder to coordinate with the Bank for the

successful integration with Core Banking Solution (existing or higher versions) and EDW

(as and when operational). Role of the Bank is limited to facilitating coordination between

the bidder (System integrator) and the system integrator for the EDW, if any(as and when

operational)

J. Service Level Agreement (SLA)

The bidder shall be bound by the Service Levels described in this document. Service Levels

will include Availability measurements and Performance parameters. 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 and Yearly as mutually agreed. Apart from

reports on each availability and performance measurement parameter mentioned below, the

reporting should also include the following:

Utilization of CPU, RAM, Hard Disk, I/O (Peak and Average)

Percentage of CPU utilized by the system and user activity.

CPU utilization broken down by user CPU and system CPU.

Percentage of physical memory utilized by system and user processes.

Problem Trends

Call Resolution Time

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.

The bidder is bound to provide on-site support to meet the requirements specified in SLA. In

other words, if the services rendered by the system falls short of standards stipulated in SLA,

the bidder shall provide on-site assistance.

K. SLA for Hardware & Software

Availability Measurements Expected

Service Level

Base Amount on which

penalty will be calculated Penalty*

Availability of Business

Infrastructure (Core Application

Servers, Core Database Servers,

Storage, SAN Switch, Tape

Library, RDBMS and related

components etc.) in DC and DRC

99.5%

Value of the said

Business infrastructure for

DC or DRC, as the case

may be.

10%


Availability of all other

infrastructure, all other software

components and Test

and Development infrastructure

99.5% Value of the relevant

Infrastructure 10%

The term „business infrastructure‟ mentioned in this document shall include all capital costs

of hardware, associated software and RDBMS (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

Performance

Measurement

Expected

Service Level

Base Amount on which

penalty will be calculated Penalty*

System

Response

Time

End to End

response time

within the DC Time or

DR (from the CRMS,

MRMS, ORMS,

ALMS &

IRMSApplication to

the Database and

back) should be

< 0.5 milliseconds

99.5%

The bidder is to

upgrade the Hardware along

with related software and

services without any

additional cost to the Bank,

if service level is not met.

Until Service level is met,

penalty will be charged on

the value of the business

infrastructure at DC

or DRC, as the case may be.

10%

Disaster

Recovery

Site

Availability

Business operations to

resume from

Disaster Recovery

Site within 4 hours

of the Data Centre

failing and vice versa.

100%

Penalty will be charged on


infrastructure at DC

or DRC, as the case may be.

10%

Data Point

Availability

Recovery Point

Objective (RPO) of15

minutes. 100%

Penalty will be charged on


infrastructure at DC or

DRC, as the case may be.

10%

* The amount indicated in this column represents the maximum penalty, which would be charged

in case of default. In the event of failure of maintaining the uptime SLA liquidated damages of

10,000/- per hour with a grace period of 120 minutes.


L. 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.

M. Time Schedule

The following time schedules should be adhered to for completion of the activities from the

date of the Purchase Order:

Business requirement study: 45 days

Software Installation: 45 Days

Interface development, integration, customization, UAT, Training and

operationalization: 120 days

Please note that maximum expected time frame of the project to GO LIVE is 7

months from the date of issuing Purchase Order*. Accordingly vendors have to

deploy the resources. Post-implementation on-site support should be provided for 3

months from Go Live date.

*Appropriate decision of extending the implementation period will be taken by bank, if

required.

All the proposals should be duly signed by authorized signatories and both the Envelopes

should be duly sealed and super-scribed at the top along-with bid submission covering letter

in the format shown in Annexure - 14.

N. Project Documentation and Manuals

All works related to the assignment handled are to be well documented and will form the

part of deliverables. They should be delivered both in hard copy and soft copy at the end of

the each stage.

O. REPORTING PROGRESS

The Bidder shall report progress of all the activities covered within the scope of work given

in this RFP. The monthly progress report shall be given free of cost about various aspect of

the works/Service(s) to The South Indian Bank Limited. The South Indian Bank Limited on

mutual agreement between both Parties may change the periodicity of such reports.

P. Warranty & Annual Maintenance

i. The warranty period for the Hardware and Software shall be for 2 years and 3 years

respectively from the GO LIVE date of the Enterprise Wide Integrated Risk Management

system. The AMC period start after completion of warranty period.

ii. AMC payment due shall be released yearly in advance against Financial Bank Guarantee for

the value of AMC amount or shall be released after completion of full year. This clause is

applicable only in respect of AMCs entered subsequent to the AMC period noted in the


project duration.

iii. During Warranty Period/ AMC, Bidder guarantees a minimum uptime of 99.5 % on monthly

basis for the entire turnkey solution provided. This will be subject to a ceiling of not more

than 120 minutes cumulative downtime. Successful Bidder is expected to submit a report

within a week after expiry of every calendar month in this regard. Delays, if any, on account

of procurement of spares will not be exempted while reckoning the uptime SLA.

iv. During maintenance period also, the Bidder guarantees on monthly basis an uptime of 99.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.

v. During the period of AMC, 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.

vi. The maximum response time for a maintenance complaint from the site of installation (i.e.

time required for Bidder‟s maintenance engineers to report to the installations after a request

call / fax /email is made or letter is written) shall not exceed One hour.

vii. In the event of failure of maintaining the uptime SLA liquidated damages of 10,000/- per

hour with a grace period of 120 minutes. The liquidated damages mentioned under this clause

shall be independent of liquidated damages/penalty mentioned in clause XVII.G of this RFP

Q. Terms and Conditions during Warranty and AMC Period

During the period of contract up to completion of Warranty and also during annual

maintenance, the selected bidder shall do the following:

a. Any software support like update/enhancement/software upgrade etc. released till the

completion of warranty and during annual maintenance shall be supplied, installed and

commissioned free of cost by the bidder. However, any such software support like update/

enhancement/upgrade shall be communicated to the Bank by the Bidder within a period of

one month from the date of release. The Bank reserves the right to procure the

update/enhancement/ System software upgrade.

b. If any software upgrades and updates are provided by the OEM as free of cost, it should be

provided and installed & configured by the selected bidder free of cost.

c. Any corruption in the Software or media shall be rectified during the full period of the

contract including Warranty and AMC, at no extra cost to the Bank.

d. The system services, as and when required, and complete maintenance of the software system

during warranty and AMC period shall be supported.

e. Service Support is defined specifically as helpdesk, update/enhancement, upgrade, technical

guidance, technical consultancy, enablement of features and functionality, problem solving

and troubleshooting, providing technical solution, rectification of bugs, enabling features of

the software already provided, providing additional user controlled reports, Changes in

configuration & settings, device configuration, enabling parameterized features, future

product information, migration, manpower resource allotment for pre-planned activity, co-


ordination for changes in structure, etc.

f. The support shall be given in person or through telephone, FAX, letter and E-mail within a

reasonable time as the case may be.

g. In future, if any configuration changes are required, it should be done by the bidder during

warranty and AMC period. However Bank will intimate the bidder well in advance for doing

such configuration changes. Configuration changes may be done either centrally or remotely

as decided by the bank when need arises. However if bidder‟s personnel is stationed at the

remote place the bidder should arrange the personnel to make such configuration change at

the respective location at bidders‟ own cost. However in case the bidder has any concerns, it

should be informed to the Bank in writing with reason for taking appropriate/ amicable/

mutually agreed decision in the matter.

h. The Bank reserves the right to modify/update the parameter files/configuration with required

awareness of its consequences and any such modification/ updation will be recorded for

information of the selected bidder without any impact on the media as per OEM descriptions.

i. Only licensed copies of software shall be supplied and ported. Further, all software supplied

shall be of latest tested proven version which is bug free. The Solution offered should have

all components which are bug free, no known vulnerabilities reported and of latest stable

version, which are having a 3 years clean track record.

j. The Bidder shall be bound to provide technical consultancy and guidance for successful

operation of the Risk Solutions and its expansion in future by the Bank during the warranty

and AMC period.

k. Preventive maintenance shall be compulsory during Warranty and AMC period. Preventive

maintenance activity should be completed every quarter and report should be submitted to the

Bank. Preventive maintenance activity should take care of physical verification, device

configuration verification, device health check up, cleaning of devices, fine-tuning the

configuration, security check up, verification of bugs/patches,etc. The preventive

maintenance report format shall be prepared by bidder in the format acceptable to Bank and

once confirmed, this format shall be strictly followed by the bidder and submit the same for

each location while claiming AMC payment.

l. The bidder shall provide centralized complaint booking facility to the Bank and the dash

board, if available, shall be provided to the Bank. The method of booking complaints shall be

through E-mail, Toll-free no, on line portal, web, etc.

XV. TERMINATION

A. 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 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 collusive practice among Bidders (prior to or after bid submission) designed to

establish bid prices at artificial non-competitive levels and to deprive the Bank of the

benefits of free and open competition.

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.

B. 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 may, 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.

C. Termination for convenience

The Bank, by written notice sent to the Bidder, may terminate the Contract, in whole or in

part, at any time at its convenience. The notice of termination shall specify that termination is

for the Bank‟s convenience, the extent to which performance of work under the Contract is

terminated and the date upon which such termination becomes effective


D. Termination – Key Terms & Conditions

The Bank shall be entitled to terminate the agreement with the Bidder at any time by giving

sixty (60) 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.

The Bidder shall have right to terminate only in the event of winding up of the Bank.

E. Consequences of Termination

In the event of termination of the Contract due to any cause whatsoever, [whether consequent

to the stipulated term of the Contract or otherwise], The Bank shall be entitled to impose any

such obligations and conditions and issue any clarifications as may be necessary to ensure an

efficient transition and effective business continuity of the Service(s) which the Bidder shall

be obliged to comply with and take all available steps to minimize loss resulting from that

termination/breach, and further allow the next successor Bidder to take over the obligations

of the erstwhile Bidder in relation to the execution/continued execution of the scope of the

Contract.

In the event that the termination of the Contract is due to the expiry of the term of the

Contract, a decision not to grant any (further) extension by the Bank, the Bidder herein shall

be obliged to provide all such assistance to the next successor Bidder or any other person as

may be required and as the Bank may specify including training, where the successor(s) is a

representative/personnel of the Bank to enable the successor to adequately provide the

Service(s) hereunder, even where such assistance is required to be rendered for a reasonable

period that may extend beyond the term/earlier termination hereof.

Nothing herein shall restrict the right of the Bank to invoke the Performance Bank Guarantee

and other guarantees, securities furnished and pursue such other rights and/or remedies that

may be available to the Bank under law or otherwise.

The termination hereof shall not affect any accrued right or liability of either Party nor affect

the operation of the provisions of the Contract that are expressly or by implication intended to

come into or continue in force on or after such termination.

F. Exit Option

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 successful Bidder to furnish the Performance Guarantee within 30 days

from the date of signing of the Contract by the Bank and the Bidder.

ii. Failure of the bidder to agree on the terms of the contract within 21 days from the date

of communication of award by the Bank and sharing of terms of contract by the Bank.

If the bidder does not meet these criteria, then the Bank may at its discretion declare the

next best bidder as the successful bidder.

iii. Failure of the successful Bidder to sign the contract within 7 days from the agreement

on the terms of the issue of Contract by the Bank

iv. Delay in completing installation / implementation and acceptance tests/ checks beyond

the specified periods;

v. Serious discrepancy in functionality to be provided or the performance levels agreed

upon, which have an impact on the functioning of the Bank.

In addition to the cancellation of contract, Bank reserves the right to appropriate the damages

through encashment of Performance Guarantee given by the Bidder.

The Bank and the Bidder shall together prepare the Reverse Transition Plan as part of Bidder

exit plan. However, the Bank shall have the sole discretion to ascertain whether such Plan has

been complied with.

Notwithstanding the existence of a dispute, and/or the commencement of arbitration

Proceedings, the Bidder will be expected to continue the facilities management services. The

Bank shall have the sole and absolute discretion to decide whether proper reverse transition

mechanism over a period of 6 to 12 months, has been complied with.

Reverse Transition mechanism would typically include service and tasks that are required to

be performed / rendered by the Bidder to the Bank or its designee to ensure smooth handover,

transitioning of application knowledge, Bank‟s deliverables, and maintenance and facility

management.

G. Termination of contract

Apart from the general grounds of default mentioned above, the Bank reserves its right to

cancel the order in the event of, but not limited to, one or more of the following specific

situations:

a) Unnecessary or unwarranted delay in execution of the work allotted.

b) Delay in providing the requisite manpower at the Bank‟s site.

c) Delay in submission of reports beyond the stipulated periods.

d) Change in the composition of staff as furnished in the bid

e) Breach of trust is noticed during any stage of the consultancy assignment.

f) The selected bidder commits a breach of any of the terms and conditions of the bid.

g) The selected bidder goes in to liquidation voluntarily or otherwise.

h) If it is found at any stage that the bidder has concealed any important information or

has submitted any false information or declaration particularly regarding any pending

legal action or blacklisting status.


i) The Bank reserves the right to recover any dues payable by the selected bidder from

any amount outstanding to the credit of the selected bidder, including the pending bills

and security deposit, if any, under this contract or any other contract/order.

j) The decision of the Bank as to whether or not any one or more of the above situation

has(have) arisen shall be final and binding on the vendor

In addition to the cancellation of order, The Bank reserves the right to appropriate the

damages from foreclosure of the Bank guarantee given by the bidder.

H. Termination of partner of Bidder

In case service of the partner of successful bidder are terminated due to any reasons

whatsoever including but not limited to the reasons mentioned above, the bidder shall be

responsible for identifying an alternative partner to execute the tasks unfinished by the

terminated partner.

The party identified by the successful bidder shall also comply with the eligibility criteria

listed out in this RFP.

I. Force Majeure

a. Notwithstanding the provisions of TCC (Terms & Conditions of the Contract), the Bidder

shall not be liable for forfeiture of its performance security, liquidated damages, or

termination for default if and 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 beyond the control of the

Bidder and not involving the Bidder‟s fault or negligence and not foreseeable. Such events

may include, but are not restricted to, Acts of God, wars or revolutions, fires, floods,

epidemics, quarantine restrictions, and freight embargoes.

c. If a Force Majeure situation arises, the Bidder shall promptly notify the Bank in writing of

such condition and the cause thereof. Unless otherwise directed by the Bank in writing, the

Bidder shall continue to perform its 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.

J. Resolution of disputes:

The Bank and the bidder shall make every effort to resolve amicably, by direct informal

negotiation, any disagreement or dispute arising between them under or in connection with

the contract. If after thirty days from the commencement of such informal negotiations, The

South Indian Bank Limited and the bidder are unable to resolve amicably a contract dispute;

either party may require that the dispute be referred for resolution by formal arbitration.


All questions, disputes or differences arising under and out of, or in connection with the

contract, shall be referred to two Arbitrators: one Arbitrator to be nominated by the Bank

and the other to be nominated by the Bidder. In the case of the said Arbitrators not agreeing,

then the matter will be referred to an umpire to be appointed by the Arbitrators in writing

before proceeding with the reference. The award of the Arbitrators, and in the event of their

not agreeing, the award of the Umpire appointed by them shall be final and binding on the

parties. The Arbitration and Conciliation Act 1996 shall apply to the arbitration proceedings

and the venue & jurisdiction of the arbitration shall be Thrissur.

The cost of arbitration (except the cost & fees of Advocates) shall be borne by each party in

equal proportion. The cost of the advocates shall be borne by respective party appointing the

Advocates.

XVI. ELIGIBILTY CRITERIA

The Bank is looking to identify a Risk Solution Provider who has demonstrable technical

competency for implementing Basel-II/Basel-III norms, ALM and FTP in tune with

RBI/BCBS guidelines and International Best Practices. The Bidder should have capability to

review the existing risk management framework of the Bank (including the prevailing

policies, structures, processes, etc), design and implement Basel II compliant Risk

Management Systems and instituting ICAAP. The Bidder is expected to have adequate

experience in implementation of software products/ projects compliant with the integrated

risk management framework for Basel II and ICAAP, and also possess high quality/ process

accreditation(s). The Bidder should be well established and have sound financial standing.

Only those Bidders who fulfill the following criteria are eligible to respond to the RFP. Any

effort by Bidder to influence the Bank in the Bank‟s bid evaluation, bid comparison or

contract award decision may result in the rejection of the Bidders‟ bid. Bank‟s decision will

be final and without prejudice and will be binding on all Bidders.

The bidders are required to meet the following eligibility criteria and provide adequate

documentary evidence for each of the criteria stipulated below. Only those bids satisfying all

the eligibility criteria would be further processed.

Co-operative Banks (State Co-operative Banks, District Central cooperative Banks, Urban

Co-operative Banks, etc.) shall not be considered for evaluation.

Sl No Eligibility criteria Details of Proof

1 Should be a Government Organization/

PSU /PSE / registered partnership

firm/LLP/ a limited company under Indian

Laws / an autonomous Institution promoted

by RBI/GOI

Reference of Act/Notification,

Registration Certificate or any document

evidencing the formation of entity

2 Should have existence in India for three

years as on 31.03.2013. (In case of mergers

Letter of Commencement of Business in

case of Public Company, Registration in



/ acquisitions / restructuring or name

change, the date of establishment of earlier /

original Partnership Firm / Limited

Company / Institution can be taken into

account).

case of others.

3 The Bidder should have average revenues

in excess of INR 10 Crore for the past three

financial years

Annual report, Balance Sheet / P&L

statement (Audited).

4 The Bidder should have demonstrated

Positive Net Worth, for the last three

financial years

Copy of audited balance sheets and

profit and loss statements for last three

financial years

5 The bidder and partner should have never

been blacklisted / barred / disqualified by

any regulator / statutory body.

Self Declaration subject to satisfaction

of South Indian Bank

6 The Bidder should own the intellectual

property rights of the product / solution or

should have rights from the owner. If not,

the Bidder should have in place proper tie-

ups, commercial agreements, authorized

implementation partnership etc. for

deployment/ resale/ customization of

software with the product Bidder or any

other third party, whose software products

are offered

In case where bidder is a SI

a. A. Self-Declaration from the Bidder

stating that proper tie up/ agreement for

for deployment/ resale/ customization of

software has been entered with OEM

B. An authorization letter from

manufacturer (OEM) to this effect

should be furnished and it shall give

mandate to participate in this RFP.

C. Self declaration specifying that the

bidder would be solely responsible for

designing, procuring, delivering,

customising and implementing the entire

solution to the satisfaction of Bank.

In case where bidder is an OEM A. Self declaration specifying that the

bidder would be solely responsible for

designing, procuring, delivering,

customising and implementing the entire

solution to the satisfaction of Bank.

B. The letter from the bidder specifying

that if any of its partners is not able to

meet its obligations as per contract

during contract period, the bidder will

meet the same to the satisfaction of

Bank.



7 The bidder and partner should have

complete understanding of Basel II norms

of BCBS and Reserve Bank of India

Guidelines on Basel- II, Basel- III, Risk

Management Systems and best practices to

guide the Bank to move to advanced

approaches.

Self Declaration subject to satisfaction

of South Indian Bank

8 The bidder must be in the business of

providing solutions for Credit/ Operational/

Market Risk Management under BASEL II/

III guidelines, for scheduled commercial

Banks in India or abroad for last three

years.

An undertaking to this effect (specifying

the Banks serviced, along with Bank‟s

confirmation) must be submitted on

bidder's letter head.

9 The Bidder must have installed and

implemented/or is in the process of

implementation of a solution* compliant

with Basel II AIRB for credit risk at least

one Scheduled Commercial Bank in India

or abroad OR the AIRB compliant solution

(OEM/ product) must have been

implemented for Basel II credit risk at least

one Scheduled Commercial Bank/ Financial

Institution in India or abroad.

OR

The Bidder must have installed and

implemented/in the process of

implementation of Basel II IMA solution*

for market risk for at least one Scheduled

Commercial Bank in India or abroad OR

the IMA compliant solution (OEM/

product) must have been implemented for

Basel II market risk in at least one

Scheduled Commercial Bank/ Financial

Institution in India or abroad.

OR

The Bidder must have installed and

implemented/ in the process of

implementation Basel II AMA solution* for

operational risk for at least one Scheduled

Copies of the credential letter from the

Bank(s) to establish that the successful

bidder has implemented/in the process

of implementation of Basel II AIRB

solution for credit risk.

OR




of implementation of Basel II IMA

solution for market risk.

OR




of implementation of Basel II AMA

solution for operational risk.



Commercial Bank/ Financial Institution in

India or abroad OR the AMA compliant

solution (OEM/ product) must have been

implemented for Basel II operational risk at

least one Scheduled Commercial Bank/

Financial Institution in India or abroad.

10 Disclosure of Conflict of Interest by bidder/

partner

Self-Declaration

*The solution in this context refers to solution which the bidder proposes to implement in

The South Indian Bank Limited.

XVII. SELECTION STRATEGY

The objective of the evaluation process is to evaluate the bids to select an effective and best

fit solution at a competitive price. The evaluation will be undertaken by an Internal Selection

Committee formed by the Bank. The Bank may consider recommendations made by

External Experts/Consultants on the evaluation. The committee or authorised official shall

recommend the successful bidder to be engaged for this assignment before Board and the

decision of our Board shall be final, conclusive and binding on the bidders.

Through this Request for Proposal, Bank aims to select a Bidder/ application provider who

would undertake the designing and implementation of the required solution. The Bidder

shall be entrusted with end to end responsibility for the execution of the project under the

scope of this RFP

The Bank will scrutinize the offers to determine whether they are complete, whether any

errors have been made in the offer, whether required technical documentation has been

furnished, whether the documents have been properly signed, and whether items are quoted

as per the schedule. The Bank may, at its discretion, waive any minor non- conformity or

any minor deficiency in an offer. This shall be binding on all Bidders and the Bank reserves

the right for such waivers and the Bank‟s decision in the matter will be final.

Bank may call for any clarifications/additional particulars required, if any, on the technical/

commercial bids submitted. The bidder has to submit the clarifications/ additional particulars

in writing within the specified date and time. The bidder‟s offer may be disqualified, if the

clarifications/ additional particulars sought are not submitted within the specified date and

time. Bank reserves the right to call for presentation/s, product walkthroughs, on the features

of the solution offered etc., from the bidders based on the technical bids submitted by them.

Bank also reserves the right to conduct Reference Site Visits at the bidder‟s client sites.

Based upon the final technical scoring, short listing would be made of the eligible bidders

for final commercial bidding.


.

A. Evaluation of Technical Bid:-

The proposal submitted by the Bidders shall be evaluated on the following group of

parameters.

Functional Requirements (FR)

Technical Requirements (TR)

Product Demonstration and Bid Presentation (PB)

Approach and Methodology (AM)

Past Experience (PE)

The marks are assigned for each individual parameter under these groups and marks scored

by each bidder under each parameter are aggregated to find out the total technical score of

the bidder.

The score for evaluation of different risk management systems /different modules of

integrated risk management systems shall be decided by the Internal Selection Committee.

The selection parameters are explained in following paragraphs.

a) Scoring Methodology for Functional Requirements (FR) and Technical

Requirements (TR)

The expected functional capabilities and marks allocated for each capability for the CRMS

(Credit Risk Management System), MRMS (Market Risk Management System) and ORMS

(Operational Risk Management System) software, Asset Liability Management Systems

(ALMS), Pillar- II, Pillar-III and Integrated capital computation module are given in

previous sections. All the functional and technical requirements for achieving regulatory

compliance are mandatory. Bidder shall indicate against each requirement/capability the

availability.

The means of indicating availability is given in the following table.

The type of

response/scale Expansion/meaning

S Standardized, this scale indicates that this feature is a

standard feature of the solution.

A Alternative available

C Customization required

U Unavailable

Any responses other than S/C/A/U are not acceptable and will be treated as U.

NOTE: The Bank's decision in respect of eligibility criteria, evaluation methodology and

short listing of bidders will be final and no claims, whatsoever in this respect, shall be

entertained.


While scoring, the scales namely S, A, C and U shall be assigned 100%, 75%, 50% and 0%

weight respectively. These percentages shall be applied on the maximum marks allocated

against each parameter to arrive at the score earned by the bidders under each parameter.

The Software solution offered, however, should have at least 70% of the requirements as

standardized. The remaining shall be customized before the completion of pilot run at no

extra cost to the Bank. The bidder shall score at least 70% of the maximum score under

technical parameters.

b) Scoring Methodology for Product Demonstration & Bid Presentation (PB)

Eligible Bidders will be required to make presentations to supplement their bids and show a

detailed product demonstration. The number of eligible bidders called for product

demonstration is purely a matter of discretion of the Bank. 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.

The marks assigned under this parameter shall be based on the effectiveness of the

demonstrations and presentations made by the bidder. The same criteria (as Evaluation for

functional specifications) will be applied to Product Demonstration also. However the marks

so scored shall be further multiplied with the proportion which number of requirements

against which S/A is indicated bears to total number of requirements.

c) Scoring Methodology for „Approach and Methodology (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 of

the proposed solution. The “Approach and Methodology” adopted for the Implementation

would be evaluated by SIB and would at the minimum cover Reference site visit/Tele

Conference, Team Strength, Project Management and Training.

i. Reference site visit/ Tele conference:

A committee of officials from the Bank would carry out Reference Site Visits and/or

Telephonic interviews with the existing customers of the Bidder. The inputs that have been

received from the Customer would be considered by the Bank and this might not need any

documentary evidence. This rating would be purely on the inputs (like satisfaction of the

organization of the product, timeliness of implementation, promptness of support services

etc.) provided by the Bidder‟s customers and score would be assigned to Bidder as

mentioned in 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.

These inputs will be used to assign marks under the parameter „Past experience‟


ii. Team Strength:

Bidder responses to each point under Team Strength in Proposed Team Profile, including the

team profile provided by the Bidder, would be evaluated. 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. The members of the proposed project team and

team lead should have a minimum experience of 2 years and 5 years respectively in

implementation of similar kind of projects in India /Abroad.

In addition to the profile of his team members, the bidder is bound to furnish the profile of

team members of his partner. The format for furnishing the team profile is given in

Annexure-9. The marks assigned under this parameter are based on the qualifications and

experience of team members.

iii. Project Management:

Bidders are required to respond to each point under Project Management in Annexure-6.

Each question will be evaluated for suitability of response. 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.

iv. Training:

The Bidder will be responsible for training the Bank‟s employees in the areas of

implementation, operations, management, error handling, system administration, etc. with

respect to the implementation of CRMS/MRMS/ORMS/ALMS.

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 CRMS/MRMS/ORMS/ALMS.

The quality of training programs already conducted by the Bidder shall form an integral part

of the final evaluation and selection of the Bidder. The detailed format for furnishing the

details of training is given in Annexure- 10.

The marks assigned under this parameter are based on the number of trainings conducted by

the bidder in previous assignments, as indicated in Annexure-10. Each of the training

programmes listed out in the Annexure-10 shall be supported by documentary proof in the

customer- Bank‟s letter head.

d) Scoring Methodology for Past Experience (PE)

The Bidder should provide details of past experience in implementing Market Risk

Management System (MRMS), Operational Risk Management System (ORMS), Credit Risk

Management System (CRMS) and Asset Liability Management System (ALMS).


The Bidder‟s past experience shall be evaluated and the score obtained by the Bidder shall

be considered for evaluation as given in the Annexure-8 „Past Experience‟. The Bidder

should provide the details of all the implementations in Banks including details of Scope of

Project, Number of Branches with breakup of the role and Proof of implementation.

e) Disqualification Parameters in Technical Bid Evaluation

The bidders who fail to score above or equal to 70% of the technical score shall be

disqualified. If only one bidder/none of the bidders qualify, Bank at its discretion may select

bidders with the top three technical scores for commercial evaluation.

Bank at its discretion may reject the proposal of the Bidder without giving any reason

whatsoever, if in Bank‟s opinion, the Solution Sizing was not made appropriately to meet

the performance criteria as stipulated by Bank. 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.

f) Short Listing of Technically Qualified Bidders

Technically qualified Bidders will be short listed based on the following criteria:

The technical score Tx = Score from Technical Evaluation for Credit Risk +

Score from Technical Evaluation for Market Risk +

Score from Technical Evaluation for Operational Risk +

Score from Technical Evaluation for ALM/FTP +

Score from Technical evaluation of Integrated Capital

Computation Module

The Relative Technical Score (RTS) for the Bidders will be calculated based on the

following basis:

RTSx = Tx/ T-high *100

Where,

RTSx : Relative Technical Score of each Bidder

Tx : Technical Score of the current proposal

T-high : Technical Score of the Bidder with Highest Technical Score

(Up to 2 decimal values will be considered for the score)

Example: If Bidder A scores 1800 points and has the highest technical score, then T-high = 1800

If Bidder B scores 1700 points, then Bidder B is TB = 1700

Hence,

RTSA = 1800/1800*100 = 100 %

RTSB = 1700/1800*100 = 94.44 %


B. Evaluation of Commercial Bid:-

The bidder is expected to submit the Commercial bid in Indian Rupees inclusive of all the

applicable taxes. The commercial bid shall contain separate quotes for each of the

modules/systems namely credit, market and operational risks and ALM /FTP module.

The Technically Qualified bidder with the lowest Commercial Bid after scrutiny and

normalization would be considered as C-LOW.

C. Techno-Commercial Scoring

Computation Methodology for arriving at “Best Price”:- The techno-commercial score

shall be calculated as follows:

Total Score = (C-LOW / C) * Cweight + (T / T-HIGH) * Tweight

Here C and T are the commercial and technical scores of the respective bidders. The scores

would be rounded-off to two decimal points.

Cweight & Tweight shall be decided based on the discretion of the Internal Selection Committee.

The Bank may at its sole discretion call the bidders who score highest combined score for

negotiation. The evaluation criteria mentioned in this RFP is tentative and the score earned

by the bidders in accordance with the evaluation parameters listed out above does not confer

them right to be called for negotiation. Further, the Bank has sole discretion in selection of

the successful bidder and decision of the Bank in this regard shall be final.

XVIII. AWARD OF CONTRACT

A. Notification of Acceptance of Bid

Before the expiry of the period of validity of the proposal, The South Indian Bank Limited

shall notify the successful bidder in writing by registered letter or by fax or by hand-delivery

or by email, that its bid has been selected. The bidder shall acknowledge in writing receipt of

the notification of selection and has to convey his absolute, unconditional and unqualified

acceptance and thereafter enter into agreement / Contract within 15 days from the date on

which selection is notified to bidder. The proposed format of notification of acceptance is

given in Annexure-15.

B. Project management:

The bidder will nominate a Project Manager immediately on acceptance of the order, who

will be the single point of contact for the project. The responsibilities and experience of

project manager is detailed under “Responsibilities of bidder” in Section III.B of this RFP.

The selected bidder cannot change the Project Manager or any other members of the team/s

during the entire period of execution of the implementation project unless consented in


writing by the Bank. In the eventuality of any such change the personnel brought in should

have equivalent or more exposure and qualifications compared to the personnel replaced and

it should be with the Bank‟s concurrence.

The selected bidder shall ensure that personnel deployed are competent, do not violate any

of the contractual obligations under this contract and while on the premises of the Bank

conduct them in a dignified manner & shall not behave in any objectionable manner

C. Signing of contract

Acceptance of selection shall be followed by signing of the Contract. However selection

committee may negotiate certain terms & conditions with successful bidder and obtain

necessary approvals from higher authorities, before signing of the Contract. The Bidders

should sign the Contract Form. A specimen of contract proposed to be executed with the

successful bidder is given in Annexure -16. Besides, the successful bidder should also sign a

non-disclosure agreement in the format specified in Annexure-3. The signing of Contract

will amount to award of contract and Bidder will initiate the execution of the work as

specified in the Contract. The signing of contract shall be completed within 30 days of

receipt of notification of the acceptance of bid. Annexure 3 and Annexure 16 may be

modified if deemed fit by the Bank.

The contract is signed for the entire duration of the project. Successful bidder shall

indemnify, protect and save the Bank against all claims, losses, costs, damages, expenses,

action, suits and other proceedings, resulting from infringement of any patent, trademarks,

copyrights etc or such other statutory infringements under the Copy Rights Act, 1957 or IT

Act 2008 or any Act in force at that time in respect of all the hardware, software and

network equipments or other systems supplied by bidder to the Bank from whatsoever

source.

D. Conditions precedent to contract

The Contract is subject to the fulfillment of the following conditions :-

Obtaining of all statutory, regulatory and other permissions, approvals, consents and no-

objections required under applicable laws or RBI for the performance of the service(s)

under and in accordance with the Contract.

Furnishing of such other documents as The South Indian Bank Limited may specify

E. Performance Bank Guarantee

The successful bidder shall submit a Performance Guarantee issued by a Scheduled

Commercial Bank in favour of The South Indian Bank Limited as per the format given in

Annexure -17 for 10 % value of the contract in Indian Rupees along with the letter of

acceptance of the assignment.

The Bidder shall furnish to the Bank, the Performance Guarantee within 30 days from the

date of signing of contract. The Performance Guarantee should be valid for the entire project


period or entire period of 8 years, whichever is longer. Project period includes

Implementation period (1 year), Warranty period (2 years), AMC period and any further

period remaining till the date of receipt of approval from RBI in respect of IRB, AMA and

IMA.

The proceeds of the performance Guarantee shall be payable to the Bank as compensation

for any loss resulting from the Bidder‟s failure to complete its obligations under the

Contract. The Performance Guarantee shall be denominated in Indian Rupees and shall be

by way of Bank Guarantee issued by a Private Sector/ Public Sector Banks in India (other

than The South Indian Bank), acceptable to the Bank.

The Bank guarantee will be returned to the selected bidder after the selected bidder‟s

performance obligations under the agreement are completed and accepted by the Bank.

The selected bidder shall be responsible for extending the validity date of the Bank

guarantees as and when it is due, on account of incompletion of the project.

The Bank shall invoke the Bank guarantee before the expiry of validity, if work is not

completed / the guarantee is not extended before the due date as the case may be, or if the

selected bidder fails to complete his obligations under the contract or if there is undue delay

in implementation of the project and achieving the respective milestones, or the bidder

becomes insolvent or goes into liquidation voluntarily or otherwise.

The Bank shall notify the selected bidder in writing before invoking the Bank guarantee. The

proceeds of the guarantee shall be payable to the Bank for any loss arising from the selected

Bidder‟s failure to complete his obligations under the contract.

In the event of any contract amendment, the Bidder shall, within 15 days after receipt of

such amendment, furnish the amendment to the performance guarantee, rendering the same

valid for the duration of the contract as amended.

F. Time period for completion of assignment

The contract will be for a period comprising of Implementation period (1 year), Warranty

period (2 years), AMC period and any further period remaining till the date of receipt of

approval from RBI in respect of IRB, AMA and IMA. It is further stipulated that the

contract period shall not end before the implementation of ALM/FTP system to the

satisfaction of Bank.

The bidder should also assist the Bank in finalization of the application for filing with the

regulator and responding to RBI queries and comments on the application for migration to

advanced approaches and making suitable changes to the Basel II implementation (if

necessary).

The Bank, at its option may extend the timeframe, depending on its requirements. Any new

guidelines given by RBI and Basel with regard to advanced approaches will automatically

form part of the contract

The successful bidder shall complete the project / perform and render the Services within the

agreed time frame starting from the date of award of Contract/Agreement.


G. Delay in adhering to the project timelines/Liquidated damages

The Successful Bidder must strictly adhere to the time schedule, as specified in the Contract,

executed between the Bank and the bidder, pursuant hereto, for performance of the

obligations arising out of the contract and any delay will enable the Bank to resort to any or

all of the following at sole discretion of the Bank.

(a) Penalty;

(b) Termination of the agreement fully or partly

If there is any delay in the implementation of the project due to bidder /partner‟s fault in

complying with time schedule furnished by the bidder and accepted by the Bank, it will

charge 1% on the total project implementation cost to the bidder for each week of delay as

penalty. Project Implementation cost in this context refers to total expenditure expected to be

incurred by the bank for procurement, design and implementation of software solutions

required to lay down Enterprise-wide Integrated Risk Management Architecture in

accordance with the International Best Practices and Guidelines of RBI/BCBS on Basel II,

Basel- III, ALM and FTP. The cost does not include Cost of Hardware procured for the

implementation. This penalty will be subject to an upper limit of 10% on the total project

implementation cost. Thereafter the order/contract may be cancelled and amount paid if any,

may be recovered with 1.25% interest per month. Any deviations from the norms would be

treated as breach of the contract by the bidder and will be dealt with accordingly. The delay

will be measured with reference to time schedule to be specified in the contract to be entered

with the successful bidder.

The Bank also reserves its right to claim damages for improper or incomplete execution of

the assignment.

H. Use of Contract Documents & Information

The successful bidder shall treat all documents, information, data and communication of and

with The South Indian Bank Limited as privileged and confidential and shall be bound by the

terms and conditions of the Non-Disclosure Agreement. The Bidder/implementation partner

shall execute the Non-Disclosure Agreement simultaneously at the time of execution of the

Contract.

The successful bidder shall not, without The South Indian Bank Limited‟s prior written

consent, disclose the Contract, or any provision thereof, or any specification, plan, sample or

information or data or drawings / designs furnished by or on behalf of The South Indian Bank

Limited in connection therewith, to any person other than a person employed by the Bidder in

the performance of the Contract.

Any document in any form it has been obtained, other than the Contract itself, enumerated in

this Bid Documents shall remain the property of The South Indian Bank Limited and shall

not be returned.


I. „NO CLAIM‟ Certificate

The bidder shall not be entitled to make any claim, whatsoever, against The South Indian

Bank Limited, under or by virtue of or arising out of, the Contract/Agreement, nor shall The

South Indian Bank Limited entertain or consider any such claim, if made by the Bidder after

he has signed a „No Claim‟ Certificate in favour of The South Indian Bank Limited in such

forms as shall be required by The South Indian Bank Limited after the implementation of risk

management software solution is completed to the satisfaction of the Bank.

J. PUBLICITY

Any publicity by the bidder in which the name of the Bank is to be used should be done only

with the explicit written permission of the Bank.

K. Payment Terms:

The payment shall be released in accordance with table given below

Project Milestones

Credit Risk

Management

System

(CRMS)

Market Risk

Management

System

(MRMS)

Operational

Risk

Management

System

(ORMS)

Asset

Liability

Management

(ALM) &

Fund

Transfer

Pricing

(FTP)

System

Successful completion of

current state assessment, gap

identification and resolution,

and systems requirement

specifications (SRS) sign off

1.00% 1.00% 1.00% 1.00%

Documentation of functional

capabilities of the software

and training reference

materials

1.50% 1.50% 1.50% 1.50%

Successful completion of

parameterization,

configuration and

customization of software.

7.50% 7.50% 7.50% 7.50%

Application Programming

Interface (API) development 5.00% 5.00% 5.00% 5.00%

Data Migration and Report

Generation 5.00% 5.00% 5.00% 5.00%


Training to all users (end

users and core users) &

Complete

Documentation(including

user manuals)

10.00% 10.00% 10.00% 10.00%

Final UAT sign off and ‟GO

LIVE ‟ 20.00% 20.00% 20.00% 20.00%

On completion of 1 year of

live implementation of the

corresponding module under

EWIRM solution

20.00% 20.00% 20.00% 20.00%

On completion of 2 years of

live implementation of the

corresponding module under

EWIRM solution

10.00% 10.00% 10.00% 10.00%

Retention Money will be

released one year after

successful approval by RBI

under Basel II

20.00% 20.00% 20.00% 20.00%

Total 100.00% 100.00% 100.00% 100.00%

Notes

1. The amount of payment released is determined by applying % referred above on the actual cost

/ proportionate cost quoted by the bidder. In case, if Bank chooses to purchase stand alone

systems for each risks and ALM / FTP, the % given above shall be applied on actual cost. In

other cases, proportionate cost for each module is worked out by multiplying the total price

quoted by the bidder in respect of integrated system with the proportion which price quoted in

respect of each individual system bears to the total price quoted.

2. The amount of payment kept aside for the stage titled „Application Programming Interface

(API) development‟ shall be released only when the implemented solution

performs/demonstrates the functional capabilities listed out under the head „Functional

requirements in respect of Pillar- II, Pillar- III and Basel III and integrated capital

computation module‟.

L. TAXES AND DUTIES:

The Successful Bidder will be entirely responsible to pay all taxes whatsoever in connection

with delivery of the services at the sites including incidental services and commissioning.

Wherever the laws and regulations require deduction of such taxes at the source of payment,

Bank shall effect such deductions from the payment due to the Bidder. The remittance of

amount so deducted and issue of certificate for such deductions shall be made by Bank as per

the laws and regulations in force.

Nothing in the contract shall relieve the Bidder from his responsibility to pay any tax that

may be levied in India/abroad on income and profits made by the Bidder in respect of this


contract.

M. GENERAL TERMS AND CONDITIONS

Bidder should compulsorily respond to any clarification (technical, functional, commercial)

letter/E-mail sent by the Bank.

The South Indian Bank Limited reserves the right to open the quotations soon after their

receipt from all the Bidders without waiting till the last date specified.

Continuity of project team members to be ensured during the period of project.

Presence of any incomplete or ambiguous terms/ conditions/ quotes will disqualify the offer.

The South Indian Bank Limited is not responsible for non-receipt of quotations within the

specified date and time due to any reason including postal holidays, or other types of delays.

The South Indian Bank Limited is not bound to place the order from the lowest price bidder

or the most competent bidder.

The bidder shall share its technology strategies and research & development efforts,

conducted in the course of this assignment with The South Indian Bank Limited.

All inquiries, communications and requests for clarification shall be submitted in Hard

copies/e-mail to The South Indian Bank Limited and response for the same shall be obtained

in writing. Only such documents shall be considered as authoritative.

The bidders should ensure that all points in the RFP document are taken into account before

submitting the Bid Documents.

The bidder should have implemented similar assignment and necessary verifiable references

in this effect should be submitted with the proposal.

Bidders are bound to make full disclosure of information required to judge them on the basis

of selection criteria specified in Section XVII.

N. LITIGATION

If it comes to the notice of the Bank that the bidder has suppressed any information either

intentionally or otherwise, or furnished misleading or inaccurate information, the Bank

reserves the right to disqualify the bidder. If such information comes to the knowledge of the

Bank after the award of work, The South Indian Bank limited reserves the right to terminate

the Contract unilaterally at the total cost and risk of the bidder. The Bank also reserves the

right to recover any dues payable by the selected bidder from any amount outstanding to his

credit, including the pending bills etc., if any. The Bank will also reserve the right to recover

any Advance paid.

Governing Law: - The Contract/Agreement shall be governed in accordance with the laws of

Republic of India. These provisions shall survive the Contract/Agreement.

Jurisdiction of Courts:-The courts of India at Thrissur have exclusive jurisdiction to

determine any proceeding in relation to the Contract/Agreement. These provisions shall

survive the Contract/Agreement.

Work under the Contract shall be continued by the selected bidder during the arbitration


proceedings unless otherwise directed in writing by the Bank unless the matter is such that

the works cannot possibly be continued until the decision of the arbitrator or of the umpire, as

the case may be, is obtained. Except as those which are otherwise explicitly provided in the

Contract/this document, no payment due or payable by the Bank, to the Bidder shall be

withheld on account of the ongoing arbitration proceedings, if any, unless it is the subject

matter or one of the subject matter thereof. The venue of the arbitration shall be at Thrissur,

Kerala State, India.

O. INFORMATION SECURITY

a. The Bidder and its personnel shall not carry any written material, layout, diagrams, floppy

diskettes, hard disk, storage tapes or any other media out of The South Indian Bank Limited‟

s premises without written permission from The South Indian Bank Limited.

b. The Bidder shall acknowledge that The South Indian Bank Limited‟s business data and

other proprietary information or materials, whether developed by The South Indian Bank

Limited or being used by The South Indian Bank Limited pursuant to a license agreement

with a third party (the foregoing collectively referred to herein as “proprietary information”)

are confidential and proprietary to The South Indian Bank Limited; and the Bidder shall

agrees to use reasonable care to safeguard the proprietary information and to prevent the

unauthorized use or disclosure thereof. The caution exercised by the bidder shall not be less

than that used by it to protect its own proprietary information. The Bidder recognizes that

the goodwill of The South Indian Bank Limited depends, among other things, upon Bidder

keeping such proprietary information confidential and that unauthorized disclosure of the

same by Bidder could damage The South Indian Bank Limited. Bidder shall use such

information only for the purpose of rendering the Service(s) to The South Indian Bank

Limited.

c. The Bidder‟s personnel shall follow The South Indian Bank Limited‟s Information System

security policy and instructions in this behalf.

d. The Bidder shall, upon termination of the Contract/Agreement for any reason, or upon

demand by The South Indian Bank Limited, whichever is earliest, return any and all

information provided to Bidder by The South Indian Bank Limited, including any copies or

reproductions, both hardcopy and electronic.


Annexure-1

Check List for Submission of Bid Documents

Check List

Sl No: Description Annexure No.

1. Authorization Letter Format 2

2. Non-Disclosure Agreement Form 3

3. Check list for submission of eligibility criteria 4

4. Profile of bidder/Partner 5

5. Implementation methodology 6

6. Reference site details 7

7. Past Experience 8

8. Team Profile 9

9. Training 10

10. Cover Letter for Commercial Bid 11

11. The format for furnishing the price of software and hardware 12

12. Table for Arriving at the Total Ownership Cost 13

13. Bid submission covering letter 14

14. Notification of Acceptance 15

15. Specimen contract form 16

16. Performance Bank Guarantee Format 17


Annexure-2

Authorization Letter Format

(On organization‟s letter head)

Place:

Date:

To






Thrissur, Kerala,

Dear Sir,

SUB: Authorization Letter for attending the Pre-bid negotiations.

REF: YOUR RFP NO: - IRMD/ RFP /001/2014 Dt 08.03.2014

This has reference to our above RFP for implementation of Enterprise-wide Integrated Risk

Management Architecture in accordance with the International Best Practices and Guidelines of

RBI/BCBS on Basel-II, Basel-III, ALM and FTP.

Mr. / Ms. ________________________________________ is hereby authorized to attend the

Pre-bid negotiations & to discuss with you on the subject RFP _____________ on

_____________ on behalf of our organization.

The specimen signature is attested below:______________________________

Specimen Signature of Mr. /Ms.

___________________________ __________________________

Signature of Authorizing Authority Name and designation of Authorizing Authority

____________________________

Name and designation of Attesting Authority

Attested

Photograph

of the Authorized

Representative


Annexure-3

Non-Disclosure Agreement Form

This Non-Disclosure Agreement made and entered into at …………………. this…….day of

……………….. 2014

BY AND BETWEEN

………………………………… Company Limited, a company incorporated under the

Companies Act, 1956 having its registered office at ….………. (hereinafter referred to as the

Implementation partner, which expression unless repugnant to the context or meaning thereof be

deemed to include its permitted successors) of the ONE PART;

AND

The South Indian Bank Limited, a company registered under the Companies Act, 1956 and a

Banking company within the meaning of the Banking Regulation Act, 1949 having its registered

office at SIB House, Mission Quarters, Thrissur, Kerala -680001 (hereinafter referred to as “The

South Indian Bank Limited” which expression shall unless repugnant to the context or meaning

thereof be deemed to include its successors and assigns) of the OTHER PART.

The Implementation partner and the South Indian Bank Limited are hereinafter collectively

referred to as “the Parties “and individually as “the Party”

WHEREAS:

1. The South Indian Bank Limited is engaged in Banking business and intends to appoint an

implementation partner for implementation of Enterprise-wide Integrated Risk Management

Architecture in accordance with the International Best Practices and Guidelines of

RBI/BCBS on Basel II, Basel- III, ALM and FTP the scope of which is specified in IRMD/

RFP /001/2014 Dt 08.03.2014. In the course of such assignment, it is anticipated that The

South Indian Bank Limited or any of its officers, employees, officials, representatives or

agents may disclose, or deliver, to the Implementation partner some Confidential

Information (as hereinafter defined), to enable the Implementation partner to carry out the

aforesaid exercise (hereinafter referred to as " the Purpose").

2. The Implementation partner is aware and confirms that the information, data and other

documents made available in the Agreement /Contract and thereafter regarding the services

delivered in this RFP or otherwise shall remain confidential.

3. The Implementation partner is aware that all the confidential information under the Bid

documents or those shared under the terms if this Agreement or Contract is privileged and

strictly confidential and/ or proprietary to The South Indian Bank Limited.


NOW, THEREFORE THIS AGREEMENT WITNESSETH THAT in consideration of the above

premises and the The South Indian Bank Limited granting the Implementation partner and or his

agents, representatives to have specific access to The South Indian Bank Limited property /

information and other data it is hereby agreed by and between the parties hereto as follows:

1. Confidential Information:

(i)“Confidential Information” means all information disclosed/furnished by The South Indian

Bank Limited or any such information which comes into the knowledge of the Implementation

partner during the course of engagement, whether orally, in writing or in electronic, magnetic or

other form for the limited purpose of enabling the Implementation partner to carry out the

assignment, and shall mean and include data, documents and information or any copy, abstract,

extract, sample, note or module thereof, explicitly designated as "Confidential"; Provided the

oral information is set forth in writing and marked “Confidential" within fifteen (15) days of

such oral disclosure.

(ii) Information such as (i) intellectual property information; (ii) technical or business

information or material not covered in (i); (iii) proprietary or internal information relating to the

current, future and proposed products or services of The South Indian Bank Limited including,

financial information, process/flow charts, business models, designs, drawings, data information

related to products and services, procurement requirements, purchasing, customers, investors,

employees, business and contractual relationships, business forecasts, business plans and

strategies, information the Parties provide regarding third parties; (iv) information disclosed

pursuant to this agreement including but not limited to Information Security policy and

procedures, internal policies and plans and Organization charts etc; and (v) all such other

information which by its nature or the circumstances of its disclosure is confidential

(iii) “Intellectual Property Rights” means any patent, copyright, trademark, trade name, design,

trade secret, permit, service marks, brands, propriety information, knowledge, technology,

licenses, databases, computer programs, software, know-how or other form of intellectual

property right, title, benefits or interest whether arising before or after the execution of this

Contract and the right to ownership and registration of these rights.

iv) The Implementation partner may use the Confidential Information solely for and in

connection with the Purpose and shall not use the Confidential Information or any part thereof

for any reason other than the Purpose stated above.

Confidential Information in oral form must be identified as confidential at the time of disclosure

and confirmed as such in writing within fifteen days of such disclosure.

Confidential Information does not include information which:

(a) Is or subsequently becomes legally and publicly available without breach of this Agreement.


(b) was rightfully in the possession of the Implementation partner without any obligation of

confidentiality prior to receiving it from The South Indian Bank Limited, or prior to entering into

this agreement, the recipient shall have the burden of proving the source of information herein

above mentioned and are applicable to the information in the possession of the recipient.

(c) was rightfully obtained by the Implementation partner from a source other than The South

Indian Bank Limited without any obligation of confidentiality,

(d) was developed by for the Implementation partner independently and without reference to any

Confidential Information and such independent development can be shown by documentary

evidence.

(e) the recipient knew or had in its possession, prior to disclosure, without limitation on its

confidentiality;

(f) is released from confidentiality with the prior written consent of the other party.

The recipient shall have the burden of proving hereinabove are applicable to the information in

the possession of the recipient.

Confidential Information shall at all times remain the sole and exclusive property of The South

Indian Bank Limited. Upon termination of this Agreement, Confidential information shall be

returned to The South Indian Bank Limited or destroyed at its directions. The destruction of

information if any, shall be witnessed and so recorded, in writing, by an authorised

representative of each of the Parties. Nothing contained herein shall in any manner impair or

affect rights of The South Indian Bank Limited in respect of the Confidential Information.

In the event Implementation partner is legally compelled to disclose any Confidential

Information, Implementation partner shall give sufficient notice to The South Indian Bank

Limited to prevent or minimize to the extent possible, such disclosure. Implementation partner

shall disclose to third party i.e. any Confidential Information or the contents of this Agreement

without the prior written consent of The South Indian Bank Limited. The obligations of this

Clause shall be satisfied by handling Confidential Information with the same degree of care,

which the Implementation partner will apply to its own similar confidential information but in no

event less than reasonable care. The obligations of this clause shall survive the expiration,

cancellation or termination of this Agreement.

2. Non-disclosure:

The Implementation partner 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 Implementation partner who have a need to have access to and knowledge of

the Confidential Information solely for the Purpose authorized above. The Implementation


partner shall take appropriate measures by instruction and written agreement prior to disclosure

to such employees to prevent unauthorized use or disclosure. The Implementation partner agrees

to notify The South Indian Bank Limited immediately if it learns of any use or disclosure of the

Confidential Information in violation of terms of this Agreement.

Notwithstanding the marking and identification requirements above, the following categories of

information shall be treated as Confidential Information under this Agreement irrespective of

whether it is marked or identified as confidential:

a) Information regarding „The South Indian Bank Limited‟ and any of its Affiliates, customers

and their accounts (“Customer Information”). For purposes of this Agreement, Affiliate means a

business entity now or hereafter controlled by, controlling or under common control. Control

exists when an entity owns or controls more than 50% of the outstanding shares or securities

representing the right to vote for the election of directors or other managing authority of another

entity; or

b) any aspect of The South Indian Bank Limited's business that is protected by patent,

copyright, trademark, trade secret or other similar intellectual property right; or

c) Business processes and procedures; or

d) Current and future business plans; or

e) Personnel information; or

f) Financial information.

g) Capital adequacy computation workings

3. Publications:

The Implementation partner shall not 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, including references whether through media, social network or otherwise, the

Purpose, the Confidential Information or other matter of this Agreement, without the prior

written approval of The South Indian Bank Limited.

4. Term:

This Agreement shall be effective from the date hereof and shall continue till expiration of the

Purpose or termination of this Agreement by The South Indian Bank Limited, whichever is

earlier. The Implementation partner hereby agrees and undertakes to The South Indian Bank

Limited that immediately on termination of this Agreement it would forthwith cease using the


Confidential Information and further as directed The South Indian Bank Limited promptly return

or destroy, under information to The South Indian Bank Limited, all information received by it

from The South Indian Bank Limited for the Purpose, whether marked Confidential or otherwise,

and whether in written, graphic or other tangible form and all copies, abstracts, extracts, samples,

notes or modules thereof. The Implementation partner further agrees and undertake to The South

Indian Bank Limited to certify in writing to The South Indian Bank Limited that the obligations

set forth in this Agreement have been fully complied with.

Obligation of confidentiality contemplated under this Agreement shall continue to be binding

and applicable without limit in point in time. The Implementation partner agrees and undertake

to treat Confidential Information as confidential for a period of [five (5)] years from the date of

receipt and in the event of earlier termination of the Contract/Agreement, the Parties hereby

agree to maintain the confidentiality of the Confidential Information for a further period of [two

(2)] years from the date of such early termination.

5. Title and Proprietary Rights:

Notwithstanding the disclosure of any Confidential Information by The South Indian Bank

Limited to the Implementation partner, the title and all intellectual property and proprietary

rights in the Confidential Information shall remain with The South Indian Bank Limited.

6. Remedies:

The Implementation partner acknowledges the confidential nature of Confidential Information

and breach of any provision of this Agreement by the Implementation Partner will result in

irreparable damage to The South Indian Bank Limited for which monetary compensation may

not be adequate and agrees that, if it or any of its directors, officers or employees should engage

or cause or permit any other person to engage in any act in violation of any provision hereof. The

South Indian Bank Limited shall be entitled, in addition to other remedies for damages & relief

as may be available to it, to an injunction or similar relief prohibiting the Implementation

partner, its directors, officers etc. from engaging in any such act which constitutes or results in

breach of any of the covenants of this Agreement. Any claim for relief to The South Indian Bank

Limited shall include The South Indian Bank Limited‟s costs and expenses of enforcement

(including the attorney's fees).

7. Governing Law:

The provisions of this Agreement shall be governed by the laws of India and the competent court

at Thrissur shall have exclusive jurisdiction in relation thereto even though other Courts in India

may also have similar jurisdictions.

8. Indemnity:

The Implementation partner shall defend, indemnify and hold harmless The South Indian Bank


Limited, its affiliates, subsidiaries, successors, assignees, and their respective officers, directors

and employees, at all times, from and against any and all claims, demands, damages, assertions

of liability whether civil, criminal, tortuous or of any nature whatsoever, arising out of or

pertaining to or resulting from any breach of representations and warranties made by the

Implementation partner. and/or breach of any provisions of this Agreement, including but not

limited to any claim from third party pursuant to any act or omission of the Implementation

partner, in the course of discharge of its obligations under this Agreement.

9. General:

The South Indian Bank Limited discloses the Confidential Information without any

representation or warranty, whether express, implied or otherwise, on truthfulness, accuracy,

completeness, lawfulness, and merchantability, fitness for a particular purpose, title, non-

infringement, or anything else.

In witness whereof, the Parties hereto have executed these presents the day, month and year first

herein above written.

For and on behalf of -------------------------- Ltd.

(Designation)

For and on behalf of The South Indian Bank Limited

(Designation)


Annexure-4

Check list for submission of eligibility criteria

Sl. No. Eligibility Criteria Compliance

(Yes/ No) Proofs to be enclosed

1.

2.

3.

4.


Annexure-5

Profile of bidder/Partner

Sl.No Particulars Response

1 Company Name

2 Date of Incorporation

3 Name of Indian representative/office (indicate: own, dealer, distributor,

JV)

4

Company Head Office address

* Contact person(s)

* Designation

* Phone Number

* Mobile Number

* Fax Number

* E-mail Address

5

Address of Indian representative/office

* Contact person(s)

* Phone Number

* Fax Number

* E-mail Address

6

Number of Employees supporting the project – In India:

India:

Marketing/Sales

Technical Support

Research and Development

Implementation

- Outside India: Marketing/Sales

Technical Support

Research and Development

Implementation

7

Ownership structure (e.g. Inc., partnership)

* Who are the primary shareholders?

* State the major shareholders with percentage holding in case of

limited companies.

8

Location:

Support (e.g. Asia Pacific, India )

Since when has the support centre existed in India?

9

Provide the range of services offered covering service description and

different schemes available for:

Customization

Implementation Support

Ongoing support (AMC,HelpDesk)

Training

Any Others (specify)


10

State pending or past litigation if any within the last 3 years with details

and explain reasons. Please also mention any claims/complaints

received in the last three years.

11 Enclose abstracts of the Balance sheet and P/L Account for the last

three years

12 Independent analyst research report (if any)

13 Major changes in Management for last 3 years


Annexure-6

Implementation methodology

Sl. No. Details of methodology / approach Response

1 The methodology section should adequately address the following

stages of the project:

i. Frequency and approach for periodic reporting on the progress of

the project and actual status vis à vis scheduled status

ii. Detailed Study of Current State, with detailed work steps and

deliverables

iii. Gap analysis including identification and resolution of gaps

iv. Customization, development and necessary work around

v. Building up of interfaces with various applications currently used

by the Bank

vi. Setting up of the data center and the disaster recovery site

vii. User acceptance testing

viii. Planning for roll out and identification of key issues that may arise

along with proposed solutions

2 Timelines

3 Project management activities

4 Roles and responsibilities of proposed personnel both from the

vendor and bank end.

5 Following details with respect to the methodology followed by the

vendor in Project Management for a Public/Private Sector Bank

i. Project Name

ii. Project Location

iii. Client Name

iv. Client address

v. Client contact/reference person(s)

vi. Project started (month/year)

vii. Project elapsed time – months

viii. Man months effort

ix. Project Size (No of branches, modules covered and any other

relevant details)

x. Name of senior project staff

xi. Nature of the Project

xii. Project Management Methodology used

xiii. Role of the Bidder, whether complete end to end involvement or

for a particular module

xiv.

Project detail ((Broad detail – information about all activities

handled, modules forming part of the Operational Risk Project of

the Client Bank, associated activities, time lines activity wise and

module wise may be detailed.)

The bidders are expected to provide crisp descriptive response against each point above.


Annexure-7

Reference site details

The reference sites submitted must be necessarily of those Banks where the proposed

Bidder/Proposed software solution has been awarded the contract in the last five years prior to

the last date for submission of bids at The South Indian Bank Ltd. 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 The South Indian Bank Ltd.

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 2012-13

Date of commencement of Project

Date of completion of Project

Scope of Work for Solution

Partner for the project

Project Start date and End date

List all the modules/components of the system being used

Type of Architecture in which the system has been implemented.

Implementation details e.g. Number of Sites, time taken for

Operationalization, volumes of processing etc.

State the duration of the implementation

Number of users and the geographical spread of the implementation

Average Team size on site for project implementation (SI & OEM Team)

Contact Details from the Bank/Financial Institution for reference

Name of the Contact Person

Designation

Phone Number/e-mail

Note:

The bidder has to submit a consent letter for conducting a reference site visit by the South

Indian Bank‟s project evaluation team. The letter has to be on the letter head of the

Bank/Financial Institution.


Annexure-8

Past Experience

List of major customers where the proposed CRMS, ORMS, MRMS, ALMS and Integrated

Capital Computation Module solution have been implemented/under implementation in

India/outside and their reference details

Sl.

No.

Name and

complete

Postal Address

of the

Customer

Name & Brief

scope of work

done by OEM

(specify the size

of the Bank, the

approaches

supported

etc.)

Name &

Brief scope

of work

done by SI

(specify the

size of the

Bank, the

approaches

supported

etc.)

Attach

reference

Letter

Contact

Details

(Name,

Designation,

Phone,

Email)

Project Status

(Completed/

Under

Implementation,

Start Date, End

Date)

*In cases where SI acts as bidder, while counting the number of Banks for the purpose of

assigning marks under this parameter only the number of Banks where SI has customized the

software of the OEM shall be taken.

(Enclose necessary documentary proof such as reference letter)


Annexure-9

Team profile

A. General information

The general information on staff strength of the bidder/partner should be furnished in the

following format.

Requirement Response

Current strength of employees in the bidder‟s organization with experience on

the proposed product(s)

Current strength of employees in the bidder‟s organization with experience in

similar projects

Certifications possessed by the Bidder in connection with the quality of internal

processes and services delivered/ methodology used in delivery

Organization‟s Competence for the Assignment:

No. of Risk Management Professionals

Proven track record and in-house technology skills for supporting

software by way of Availability of Quality certificates (ISO / SEI/

CMM etc.)

B. Specific information to be furnished in respect of each team member

Requirement Response

Name of Member on the Project Implementation Team.

Designation and Role

Area of Expertise (Subject Matter Expert)

Credit Risk

Market Risk

Operational Risk

ALM

FTP

Capital Computation

Role of Team Member – onsite or offsite. If onsite then no. of man days

expected to spend onsite during the implementation period

Organization Name (Bidder has to specify if the member is a part of the

Bidder‟s organization or partner‟s organization)

Professional Qualifications

Risk Management Experience with the bidding firm/OEM in terms of areas and

no of years of expertise

Risk Management Experience with other companies firm in terms of areas and

no of years of expertise (Mention if he/she has worked with Banks earlier)


IT Implementation and Project Management Expertise with the bidding firm/

OEM in terms of years and areas of expertise

IT Implementation and Project Management Expertise with other companies in

terms of years and areas of expertise

Certifications and Accreditations including Membership of any professional

body

Details of similar projects handled with details of client, representing which

organization, role of the member team or team leader etc. in India and

Internationally

Experience of the resource in the implementation of the Proposed solution

offered in this Bid


Annexure-10

Training

A. General Information


No: of Implementation trainings have been undertaken by the Bidder/partner

A brief description on the Training approach taken by the Bidder/partner

Names and experience of all trainers with the Bidder who would be involved

with the Project

B. Specific information to be furnished in respect of each training session*


Name of the Bank where product was implemented and the training conducted

Date and place where training conducted

Training audience

Duration of training

Location

*This information should be backed by the documentary proof in the customer-Bank‟s letter

head.


Annexure-11

Cover Letter for Commercial Bid

Note: This Cover Letter for Commercial Bid from the Bidder should be on the letterhead of the

Bidder and should be signed by an authorized person.

Date:

To,






Thrissur , Kerala,

India – 680001

Dear Sir/ Madam,

Subject: Response to RFP Ref No: IRMD/001/2014 for Solution to Implement of Enterprise

Wide Integrated Risk Management Architecture under Basel II and Basel III norms of

RBI/BCBS

Having examined the Bidding Documents, the receipt of which is hereby duly acknowledged,

we, the undersigned, offer to supply & deliver the Solution to Implement Enterprise Wide

Integrated Risk Management Solution under Basel II and Basel III, inconformity with the said

Bidding documents for the sum of ...................………….. (Total amount in words and figures) or

such other sums as may be ascertained in accordance with the commercial bid for hardware and

software and total cost of ownership (termed as Annexure-12 and Annexure-13 in your RFP)

attached herewith and made part of this Proposal.

We undertake, if our Proposal is accepted, to deliver, install and commission the system, in

accordance with Requirements specified within the RFP for Solution to Implement Enterprise-

wide Integrated Risk Management Architecture in accordance with the International Best

Practices and Guidelines of RBI/BCBS on Basel II, Basel- III, ALM and FTP

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 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 in force in India.


We understand that you are not bound to accept the lowest or any Proposal you may receive.

Dated this ....... day of ............................ 2014

_________________________________ _______________________________ _

(Signature) (Name) (In the capacity of)

Duly authorized to sign Proposal for and on behalf of

_________________________________


Annexure-12

Format for furnishing the price of Software/Hardware (Bill of Material)

A. The format for furnishing the price of software

The bidder shall furnish the price of each module namely, credit, operational, market and

ALM/FTP in the format given below. Further if he is planning to implement a single integrated

software solution, he shall in addition to the price of each module quote the price of entire

integrated system in the format given below

Sl.

No Item Description

Unit Price

in Indian

Rs.

Total Price

in Indian

Rupees

Comments

by Vendor

A Credit/Market/Operational/ALM/FTP risk

System

1

License cost If the software is sold

in modular format,

details of the cost of

each module must be

elaborated

2 Customization Cost If the software is sold

in modular format,


each module must be

elaborated

3 Implementation &

Project Management

cost

4

Cost of Application

Programming

Interface i.e.,

Interface

development

5 Cost of Training

6

Post-implementation

on-site support for 3

months from Go Live

date

7

Annual Maintenance/

support Contract

charges after

warranty period.

I year

II year

III year

IV year

V year

8

Charges for Data

migration to new

system


Sl.

No Item Description

Unit Price

in Indian

Rs.

Total Price

in Indian

Rupees

Comments

by Vendor

9

Any other charges

such as FMS etc not

covered above.

Please specify

10

Operating System

software for Primary

Site

11 Operating System

software for DR Site

12

Database software as

specified in the

response bid by the

vendors cum required

licences, ATS if any

for Primary Site

13

Database software as

specified in the

response bid by the


licenses, ATS if any

for DR Site

14

Environmental &

backup software as

specified in the

response by the



for Primary Site

15

Environmental &

backup software as

specified in the

response by the



for DR Site

16 Middleware

17 Any other cost not

included here. Give the details

TOTAL Cost of all

the above


B Capital Computation System

1

License cost If the software is sold

in modular format,


each module must be

elaborated

2 Customization Cost If the software is sold

in modular format,


each module must be

elaborated

3 Implementation &

Project Management

cost

4 Cost of Application

Programming

Interface i.e.,

Interface

development

5 Cost of Training

6 Post-implementation

on-site support for 3

months from Go Live

date

7 Annual Maintenance/

support Contract

charges after

warranty period.

I year

II year

III year

IV year

V year

8 Charges for Data

migration to new

system

9 Any other charges

such as FMS etc not

covered above.

Please specify

10 Operating System

software for Primary

Site

11 Operating System

software for DR Site

12 Database software as

specified in the

response bid by the


licences, ATS if any


for Primary Site

13 Database software as

specified in the

response bid by the



for DR Site

14 Environmental &

backup software as

specified in the

response by the



for Primary Site

15 Environmental &

backup software as

specified in the

response by the



for DR Site

16 Middleware

17 Any other cost not

included here.

Give the details

TOTAL Cost of all

the above

Note: Applicable taxes and Duties: Details of all applicable taxes to be paid by the Bank must

be specified like sale tax, service tax etc. Applicable Duties to include customs, Excise etc. All

taxes and duties to be given in Rupee value only.


Dated……

(Signature)

(In the capacity of)

Duly authorized to sign bid for & on behalf of

(Name & Address of the Bidder)

B. The format for furnishing the price of hardware*

Sl.

No Item Description

No: of

units

(A)

Unit

price

(B_)

Sub

Total

Price

(A x B)

Taxes

Total

price

including

taxes

1 Hardware (including for both

DC & DR Site)

Servers

Operating system

Storage (SAN)

Rack with KVM switch, power

supply, Network & security

requirements, switches, routers,

etc.

Hardware required for SLA

Monitoring

2 AMC & ATS cost as per Part II

3 Facilities Management (both

at DC & DR)

4 Other Cost** (if any)

Total

* In case the bidder is a SI, the hardware specification given in this part should be endorsed

by OEM whose software is proposed to be deployed by SI.

** Any other system upgradation requirements such as LAN, bandwidth etc to be part of the

total cost.

The hardware proposed should have a warranty period of 3 years.


Annexure-13

Table for Arriving at the Total Ownership Cost

TABLE-A: Cost of Software, Hardware Customization, Network, Training, etc

Sl. No Item description Unit Price Total Price Taxes / VAT

if any

Total

payable

GRAND TOTAL

TABLE-B: Cost of AMC after the warranty for Software, Customization, Network, etc

S.No Item description

AMC amount

for full period

after warranty

Service Taxes

if any Total payable

GRAND TOTAL

(Amt. in Indian Rupees only)

TOTAL PAYABLE IN INDIAN RUPEES AS PER TABLE A

TOTAL PAYABLE IN INDIAN RUPEES AS PER TABLE B

TOTAL BID PRICE.

Amount in words:

Date:


Annexure-14

Bid submission Covering Letter

Note: This Bid Offer Covering letter should be on the letterhead of the Bidder and should be

signed by an authorized person.

Date:

To,






Thrissur , Kerala,

India – 680001

Dear Sir/ Madam,

Subject: Response to RFP Ref No: IRMD/001/2014 for Solution to Implement of Enterprise

Wide Integrated Risk Management Architecture under Basel II and Basel III norms of

RBI/BCBS

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

Enterprise Wide Integrated Risk Management Solution: Credit Risk Management Solution,

Operational Risk Management Solution, Market Risk Management Solution, Asset Liability

Management System and Integrated Capital Computation and Reporting Module for

Advanced Approach under Basel II and Basel III.

2. We agree and undertake that, if our Bid is accepted, we shall deliver, install and commission

the Solution in accordance with the Requirements specified within the RFP for Solution to

Implement Enterprise-wide Integrated Risk Management Architecture under Basel II and

Basel III within the timeframe specified, starting from the date of receipt of notification of

award from The South Indian Bank Ltd.

3. We acknowledge having received the following addenda to the bid document:

4. If our Bid is accepted, we will obtain performance guarantee of a Bank for a sum equivalent

to 10 percent of the Contract Price for the due performance of the Contract, in the form

prescribed by the Bank

Addendum No. Dated


5. All the details mentioned by us are true and correct and if Bank observes any

misrepresentation of facts on any matter at any stage, Bank has the absolute right to reject

the bid / proposal and disqualify us from the selection process.

6. We confirm that the offer is in conformity with the terms and conditions as mentioned in

RFP and it shall remain valid for 90 days from the last date of the acceptance of this bid.

7. 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 in force in India.

8. We are also aware that The South Indian Bank has also right to re-issue / recommence the

bid, to which we do not have right to object and have no reservation in this regard; the

decision of The South Indian Bank in this regard shall be final, conclusive and binding upon

us.

9. We confirm that our company/system integrator/other partners participating in this bidding

as part of the consortium have not been black listed/banned by a regulatory authority and

any previous ban is not in force at present.

10. We enclose a Demand Draft /Bankers' Cheque bearing No……………. dated ……/ …../20

drawn by ……….. Bank, branch, in favour of The South Indian Bank, payable at Thrissur

for a sum of Rs 25,000/.(Rupees Twenty five thousand only) towards non-refundable Bid

Submission fee.

OR

We confirm that the UTR number for the remittance of non-refundable Bid Submission fee

of Rs. 25000/.(Rupees Twenty five thousand only) is …………………….

Dated this ....... day of ............................ 2014.

Yours faithfully,

(Name of Authorized Signatory)

(Designation)

Duly authorized to sign Bid for and on behalf of


Annexure-15

Notification of Acceptance

(On organization‟s letter head)

Place:

Date:

To






Thrissur, Kerala,

India – 680001

Dear Sir,

SUB: RFP No IRMD/ RFP /001/2014 Dt 08.03.2014

REF: Your Letter No: - _________________ Dt ________________.

This has reference to your letter on the subject, notifying us about the selection of our bid.

We hereby convey our absolute, unconditional and unqualified acceptance for the work and

activities as per the Scope of Work mentioned in the subject RFP.

Signature of Authorised Person

(Seal)


Annexure-16

Specimen contract form

THIS AGREEMENT (the Agreement) made at…………………the………day of

……………………. 2014.

BETWEEN

The South Indian Bank Limited a company registered under the Companies Act, 1956 (1

of1956) and a Banking company within the meaning of SECTION 5(c) of the Banking Regulation

Act, 1949 (10 of 1949) and having its registered office at The South Indian Bank Limited,

SIB House, Mission Quarters, Thrissur – 680 001 (hereinafter called “The South Indian Bank

Limited / Purchaser ” which expression shall unless it be repugnant to the subject, context or

meaning thereof shall be deemed to mean and include its successors and assigns) of the ONE

PART

AND

……………. (Name of successful Bidder) of …………………… (Please specify the registered

office of the (Implementation partner) (hereinafter called “the Implementation partner which

expression shall unless it be repugnant to the subject, context or meaning thereof shall be deemed

to mean and include its successors) of the OTHER PART.

The Purchaser and Implementation partner are hereinafter collectively referred to as "Parties".

WHEREAS the Purchaser invited bids for certain Services namely „Implementation of

Enterprise-wide Integrated Risk Management Architecture in accordance with the

International Best Practices and Guidelines of RBI/BCBS on Basel II, Basel- III, ALM and

FTP ‟

AND WHEREAS the purchaser has accepted a bid by the Implementation partner for rendering

of the Services for the sum of ………………………( Contract Price in Words and Figures)

(hereinafter called “the Contract Price”).

NOW THIS AGREEEMENT WITNESSETH AND IT IS HEREBY AGREED BY AND

BETWEEN THE PARTIES HERETO AS FOLLOWS

In consideration of the payments to be made by the South Indian Bank Limited to the

Implementation partner as hereinabove mentioned, the Implementation partner hereby agrees with

the Purchaser to provide or render the Services, to furnish necessary undertakings, etc. as

mentioned in the RFP documents, this Agreement (hereinafter collectively referred to as “the said

documents”) strictly in conformity in all respects with the provisions of the said documents

(1) In this Agreement words and expressions shall have the same meanings as are respectively


assigned to them in the terms and conditions of RFP / Contract / Agreement referred to.

(2) The RFP Document titled_________________________ shall be deemed to form and be

read and construed as part of this Agreement, which, inter alia, includes

a. Scope of Work

b. Objective of RFP document

c. Eligibility Criteria

d. Functional and Technical requirements

e. Payment terms

f. Submission of bids

(All the above are collectively referred to as "the said documents")

(3) The Purchaser hereby agrees and covenants to pay the Implementation partner in

consideration of the rendering of the Services and the remedying of defects, if any therein,

etc., the Contract price as may become payable under the provisions of the said documents at

the times and in the manner prescribed by the said documents

(4) The Implementation partner shall provide the services and documents and records as per the

scope of the service / work as contained in the said documents

(5) All applicable taxes shall be deducted by the South Indian Bank Limited at source according

to the tax rate prevalent at the time of making payment.

(6) The Contract price quoted by the implementation partner in Bid shall be finalized and

inclusive of all duties, service tax ,levies, other taxes, traveling expenses , lodging /boarding,

local conveyance or any other expenses of whatsoever nature for the said service.

(7) In order to induce The South Indian Bank Limited to enter into the Contract/Agreement, the

Implementation partner hereby make following representations

a. It is duly organized and validly existing organization under Indian Laws.

b. It has power and authority to execute and deliver this Agreement/Contract and has taken

all necessary steps to authorize execution, delivery and performance of this

Agreement/Contract

c. It has power and authority to do all things necessary and appropriate and to perform

Services contemplated under this Agreement/Contract

d. neither the execution and delivery by the Implementation partner of the

Contract/Agreement nor the Implementation partner's compliance with or performance of

the terms and provisions of the Contract/Agreement (i) will contravene any provision of

any applicable law or any order, writ, injunction or decree of any court or governmental


authority binding on the Implementation partner (ii) will conflict or be inconsistent with

or result in any breach of any of the terms, covenants, conditions or provisions of, or

constitute a default under any agreement, contract or instrument to which the

Implementation partner is a party or by which it or any of its property or assets is bound

or to which it may be subject or (iii) will violate any provision of the Memorandum and

Articles of Association/ partnership deed of the Implementation partner

e. has made or shall make all necessary arrangement for performance of the services. In

case of failure on the part of Implementation partner to provide any part of services as

mentioned The South Indian Bank Limited has a right not to pay for such particular part

of services

f. That the Implementation partner is a company/ partnership firm which has the requisite

qualifications, skills, experience and expertise to give service to third parties

g. That Implementation partner possesses the technical know-how, the financial

wherewithal, the power and the authority to enter into the Contract /Agreement.

h. That the Implementation partner is not involved in any litigation, potential, threatened

and existing, that may have an impact of affecting or compromising the performance of

Service under the Contract/Agreement. No inquiries or investigations have been

threatened, commenced or pending against the Implementation partner or its team

members by any statutory or regulatory or investigative agencies.

i. That the representations made by the Implementation partner in its bid are and shall

continue to remain true and fulfill all the requirements as are necessary for executing the

duties, obligations and responsibilities as laid down in the Contract/Agreement and the

Bid Documents and unless The South Indian Bank Limited specifies to the contrary, the

Implementation partner shall be bound by all the terms of the bid

j. That the Implementation partner has the professional skills, personnel and

resources/authorizations that are necessary for giving the Service or to perform its

obligations under the bid.

k. That the execution of the Service herein is and shall be in accordance and in compliance

with all applicable laws

l. That all conditions precedent under the Contract/Agreement / bid document have been

complied.

m. That the Implementation partner certifies that all registrations, recordings, filings and

notarizations of the Contract/Agreement and all payments of any tax or duty, registration

charges or similar amounts which are required to be effected or made by the


Implementation partner which is necessary to ensure the legality, validity, enforceability

or admissibility in evidence of the Contract/Agreement have been made.

n. That the Implementation Partner confirms that there has not and shall not occur any

execution, amendment or modification of any agreement/contract without the prior

written consent

of The South Indian Bank Limited , which may directly or indirectly have a bearing on

the Contract/Agreement

(8) Indemnity

Implementation partner shall indemnify and keep The South Indian Bank Limited harmless

and indemnified from and against all claims, liabilities, losses and incurred costs, fines,

penalties, expenses, taxes, assessment, punitive damages, fees (including advocate‟s/

attorney‟s fee), liabilities, judgments, awards, assessments, obligations, damages, etc., which

The South Indian Bank Limited may suffer or incur arising out of, or in connection with:

a) any act, neglect, default or omission on the part of the Implementation partner, its

subsidiaries or any person associated with the Implementation partner, including but not

limited to liabilities arising from non compliance of Standards and Regulations

prescribed by regulator, from time to time, unauthorized use or disclosure of Confidential

Information and failure to comply with data protection as prescribed from time to time;

b) any breach by the Implementation partner of the terms and conditions of its engagement

or its obligations under the said documents;

c) any breach by the Implementation partner of its obligations under any Law(s) or contract,

etc;

d) default or omission on the part of the Implementation partner to follow statutory

instructions and guidelines issued by the Government of India and any other

governmental authority.

In the event of a third party bringing a claim or action against The South Indian Bank, as a

consequence of the implementation or use of the software or solution provided by the

Implementation partner, the Implementation partner shall defend and / or assist The South

Indian Bank Limited in defending, at the Implementation partner cost, such claims or actions,

either in a legal proceeding or otherwise;

(9) Termination of Agreement /Contract

The South Indian Bank Limited may terminate this Agreement/Contract for any breach of the

terms and conditions of this Agreement/Contract / bid by giving 15 days notice to the


Implementation partner requiring it to make good the default(s) within notice period.

Termination of this Agreement/Contract shall not affect or prejudice any provisions of this

Agreement/Contract, which are expressly or by implication provided to continue in effect

after such termination

Without prejudice to the right to effect the penalty conditions mentioned within Service

Level Agreement mentioned within the said documents, The South Indian Bank Limited may

impose penalty, if there is any delay in the implementation of the project due to

implementation partner‟s fault in complying with time schedule specified in this contract.

The penalty shall be levied at 1% on the total project implementation cost to the bidder for

each week of delay. This penalty will be subject to an upper limit of 10% on the total project

implementation cost. Thereafter the order/contract may be cancelled and amount paid if any,

may be recovered with 1.25% interest per month. If the delay exceeds six weeks, The South

Indian Bank limited reserves the right to terminate the services Agreement unconditionally.

(10) Notices

All notices in connection with this Agreement/Contract, shall be given in writing hand

delivered or sent by courier or by facsimile transmission, confirmed by courier to the address

or fax number specified below, or to such other address or number which the parties may

have last specified. All such notices shall be effective upon receipt to

1. The Chief General Manager (IRMD)




2nd Floor, Mission Quarters, Thrissur , Kerala, India – 680001.

2. Implementation Partner,

Address.

Either of the parties hereto may by notice change the address to which such notices and

communication are to be delivered or transmitted

(11) Compliance with RBI and other Regulatory Requirements

The Implementation partner shall individually obtain the necessary regulatory approvals from

the RBI or other regulatory bodies, if any required, for the Contract .Any demand for

information regarding any of the matters to the extent mutually agreeable under this

Agreement called for by the RBI or any other regulatory body shall be promptly responded to

by the concerned Party. The Implementation Partner undertakes to comply all the statutory

and regulatory requirements under the applicable laws in connection with Service including

Labour and Industrial Laws. In the event of any default by the Implementation partner which

results in any actionable claim against The South Indian Bank Limited, the Implementation


partners shall keep The South Indian Bank Limited indemnified against all such claims and

actions.

(12) Governing Law

The provisions of this Agreement shall be governed by the laws of India and the competent

court at Thrissur shall have exclusive jurisdiction in relation thereto even though other Courts

in India may also have similar jurisdictions.

(13) Headings

The heading of various Articles and Sections herein are for convenience of reference and are

not deemed to affect the construction of the relative provisions

(14) Effective date and validity

This Agreement/Contract shall become binding on the parties on and from ____________. It

shall be in force until its termination or _____________________, whichever is earlier

(15) Force Majeure

If the performance as specified in this Contract/Agreement is prevented, restricted, delayed

or interfered by reason of: Fire, explosion, cyclone, floods, war, revolution, acts of public

enemies, blockage or embargo, any law, order, proclamation, ordinance demand or

requirements of any Government or authority or representative of any such Government or

regulations , strikes, shutdowns or labor disputes which are not instigated for the purpose of

avoiding obligations herein, then, notwithstanding anything here before contained, the party

affected shall be excused from its performance to the extent such performance relates to

prevention, restriction, delay or interference and provided the party so affected uses its best

efforts to remove such cause of non- performance and when removed the party shall continue

performance with utmost dispatch

If a Force Majeure situation arises, the Implementation partner shall promptly notify The

South Indian Bank Limited in writing of such conditions and the cause thereof. Unless

otherwise directed by The South Indian Bank Limited in writing, the Implementation partner

shall continue to perform its obligations under the Contract/Agreement as far as is reasonably

practical and shall seek all reasonable alternative means for performance not prevented by the

Force Majeure event. The South Indian Bank Limited may terminate the

Contract/Agreement, by giving a written notice of minimum 15 days to the Implementation

partner, if as a result of Force Majeure the Implementation partner is unable to perform a

material portion of the work assigned to him for a period of more than 30 days.


IN WITNESS WHEREOF the Parties hereto have caused this Agreement to be executed on the

day, month and year first above written.

Signed and Delivered by

The within named

The South Indian Bank Limited/ Purchaser

Signature:

Name

Date: - ….......................

IN THE PRESENCE OF

1. Signature : 2. Signature :

Name : Name :

Address : Address :

Signed and Delivered by ......... .........................

the within named

Implementation Partner

M/s. ..................................

.................................

Date :- .......................

IN THE PRESENCE OF :

1. Signature : 2. Signature :

Name : Name :

Address : Address :


Annexure-17

Performance Bank Guarantee Format

Bank Guarantee No. :

Bank Guarantee Amount :

Expiry Date :

Claim Period :

Account :

GUARANTEE FOR PERFORMANCE OF CONTRACT/AGREEMENT

THIS GUARANTEE AGREEMENT executed at ________ day of_____________ Two

Thousand Fourteen

BY :

______________________ bank, a body corporate constituted under _______________, having

its Registered Office/ Head Office at ______________, and a Branch Office

at_____________________________________________________ (hereinafter referred to as

“the Guarantor”, which expression shall, unless it be repugnant to the subject, meaning or

context thereof, be deemed to mean and include its successors and assigns)

IN FAVOUR OF:

The South Indian Bank Limited, a banking company, established under the Companies Act 1956

and having its Registered Office at SIB House, Mission Quarters, Thrissur, Kerala – 680001

(hereinafter referred to as “Bank” which expression shall unless it be repugnant to the subject,

meaning or context thereof, be deemed to mean and include its successors and assigns),

WHEREAS Bank had called for the bids for engagement of implementation partner who can

implement Enterprise-wide Integrated Risk Management Architecture in accordance with the

International Best Practices and Guidelines of RBI/BCBS on Basel II, Basel- III, ALM and FTP

(the “Project”)

AND WHEREAS M/s……………………… have been appointed as the Implementation partner

(hereinafter referred to as " Implementation partner") for the said Project and accordingly has

entered into Contract / Agreement on ……….. (Agreement) with Bank subject to the terms and

conditions contained in the said documents (defined herein below) and the Implementation

partner has duly confirmed the same.

AND WHEREAS pursuant to the Bid Documents, the Agreement, and the other related

documents (hereinafter collectively referred to as “the said documents”), the Bank has agreed to


avail from M/s……………………. and M/s……………………………. has agreed to provide to

the Bank, the Services more particularly described in the said documents (hereinafter

collectively referred to as “the Services”), subject to payment of the contract price as stated in

the said documents and also subject to the terms, conditions, covenants, provisions and

stipulations contained the said documents.

AND WHEREAS the Implementation partner has duly signed the said documents.

AND WHEREAS in terms of the said documents, inter alia, the Implementation partner is

required to procure an unconditional and irrevocable performance Bank guarantee, in favour of

the Bank, from a bank acceptable to the Bank for a sum of Rs…………………………………

(Rupess…………………………………………………….. Only) being 10% of the total contract

value for the faithful observance and performance by the Implementation partner of the terms,

conditions, covenants, stipulations, provisions of the Agreement /the said documents.

AND WHEREAS at the request of the Implementation partner, the Guarantor has agreed to issue

the guarantee in favour of the Bank for a sum of Rs. ………………………………

(Rupees………………………………………………..Only) being the 10% of the total Contract

value

AND WHEREAS at the request of the Implementation partner, the Guarantor has agreed to

guarantee the Bank that the Implementation partner shall faithfully observe and perform the

terms of the said documents

NOW THEREFORE THIS AGREEMENT WITNESSETH AS FOLLOWS:

In consideration of the above premises, the Guarantor hereby unconditionally, absolutely and

irrevocably guarantees to the Bank as follows:

(1) The Guarantor hereby agree and guarantee that the Implementation partner shall faithfully

observe and perform all the terms and conditions stipulated in the Contract/Agreement and the

said documents.

(2) The Guarantor hereby guarantees and undertakes to pay, on demand and without demur,

reservation, contest, recourse or protest or without any reference to the Implementation partner,

to the Bank at its office at Thrissur forthwith, and all monies payable by the Implementation

partner to the extent of Rs.………………………………………. against any loss, costs,

damages, etc. suffered by the Bank on account of default of the Implementation partner in the

faithful observance and performance of the terms, conditions, covenants, stipulations, provisions

of the said documents. Any such demand or claim made by the Bank, to the Guarantor shall be

final, conclusive and binding notwithstanding any difference or any dispute between the Bank

and the Implementation partner or any dispute between the Bank and the Implementation partner

pending before any Court, Tribunal, Arbitrator, or any other authority.


(3) The Guarantor agrees and undertakes not to revoke this Guarantee during the currency of

these presents, without the previous written consent of the Bank and further agrees that the

Guarantee herein contained shall continue to be enforceable until and unless it is discharged

earlier by the Bank, in writing.

(4) The Bank shall be the sole judge to decide whether the Implementation partner has failed to

perform the terms of the said documents for providing the Services by the Implementation

partner to the Bank, and on account of the said failure what amount has become payable by the

Implementation partner to the Bank under this Guarantee. The decision of the Bank in this behalf

shall be final, conclusive and binding on the Guarantor and the Guarantor shall not be entitled to

demand the Bank to establish its claim under this Guarantee but shall pay the sums demanded

without any objection, whatsoever.

(5) To give effect to this guarantee, the Guarantor will be deemed to be the Principal Debtor to

the Bank.

(6) The liability of the Guarantor, under this Guarantee shall not be affected by

(a) any change in the constitution or winding up of the Implementation partner or any absorption,

merger or

(b) amalgamation of the Implementation partner with any other company, corporation or

concern; or

(c) any change in the management of the Implementation partner or takeover of the management

of the Implementation partner by the Government or by any other authority; or

(d) acquisition or rationalization of the Implementation partner and/or of any of its

undertaking(s) pursuant to any law; or

(e) any change in the constitution of Bank / Implementation partner; or

(f) any change in the set up of the Guarantor which may be by way of change in the constitution,

(g) winding up, voluntary or otherwise, absorption, merger or amalgamation or otherwise; or the

absence or deficiency of powers on the part of the Guarantor to give Guarantees and/or

Indemnities or any irregularity in the exercise of such powers.

(7) This Bank guarantee shall be valid for 8 years from the date of signing the contract.

(8) Notwithstanding anything contained in this Guarantee, the Guarantor hereby agrees and

undertakes to extend the validity period of this guarantee for a further period as may be requested

by the Bank, from time to time.

(9) This guarantee shall be binding upon us and successors -in - interest and shall be irrevocable.


(10) For all purposes connected with this Guarantee and in respect of all disputes and differences

under or in respect of these presents or arising there from the courts of Thrissur where the Bank

has its Registered Office shall alone have jurisdiction to the exclusion of all other courts.

(11) Notwithstanding anything contained herein above

I. Our liability under this Bank Guarantee shall not exceed Rs……………………………….

(Rupees ……………………….. only)

III. This Bank Guarantee shall be valid up to………………………….

IV. We are liable to pay the guaranteed amount or any part thereof under this Bank Guarantee

only and only if you serve on us a written claim or demand on or

before ……………………………..…

IN WITNESS WHEREOF the Guarantor has caused these presents to be executed on the day,

month and year first herein above written as hereinafter appearing.

SIGNED AND DELIVERED BY

the within named Guarantor,

________________________________,

by the hand of Shri.____________________, its authorised official.

Request for Proposal and Quote - South Indian Bank SIB EWIRM V 1 0... · Request for Proposal and...

Documents

Transcript of Request for Proposal and Quote - South Indian Bank SIB EWIRM V 1 0... · Request for Proposal and...