rfp for audit management and risk monitoring system · floated for supply, implementation and...

RFP for Audit Management and Risk Monitoring System, RBI

Reserve Bank of India

Request for Proposal

For

Audit Management and Risk Monitoring System (AMRMS)

(January 25, 2016)

Inspection Department C-7, 8th Floor, Central Office, Bandra Kurla Complex, Bandra (E), Mumbai- 400 051, Maharashtra,

India

This document is the property of Reserve Bank of India (RBI). It may not be copied, distributed or recorded on any medium, electronic or otherwise, without the RBI’s written permission thereof, except for the purpose of responding to RBI for the said purpose. The use of the contents of this document, even by the authorized personnel / agencies for any purpose other than the purpose specified herein, is strictly prohibited and shall amount to copyright violation and thus, be punishable under the Indian Law.


Disclaimer & Disclosures Reserve Bank of India (RBI) has prepared this document to give background information on participating in RFP process of AMRMS Project from the five (5) short-listed bidders only, i.e; (i) Auditime Information Systems Pvt. Ltd., Mumbai (ii)NCSSoft Solutions Pvt. Ltd., Chennai (iii) PWC Pvt. Ltd., Mumbai (iv) Quadrant 4 Software Solutions Pvt. Ltd., Chennai and (v) Thomson Reuters Pvt. Ltd. Mumbai; based on Expression of Interest (EOI) evaluation. RFP Application received from any other bidder(s) will be summarily rejected. While RBI has taken due care in the preparation of this document and believe it to be accurate, neither RBI nor any of its authorities, agencies, officers, employees, agents or advisors give any warranty or make any representations, express or implied as to the completeness or accuracy of the information contained in this document or any information which may be provided in association with it. The information is not intended to be exhaustive. Interested parties are required to make their own inquiries and respondents will be required to confirm in writing that they have done so and they do not rely only on the information provided by RBI in submitting response to the RFP document. The information is provided on the basis that it is non–binding on RBI or any of its authorities, agencies, officers, employees, agents or advisors. RBI reserves the right not to proceed with the Project or to change the configuration of the Project, to alter the time table reflected in this document or to change the process or procedure to be applied. It also reserves the right to decline to discuss the matter further with any party expressing interest. No reimbursement of cost of any type will be paid to persons or entities expressing interest. The proposal should be signed and submitted by a person duly authorized to bind the bidder to the details submitted in the proposal. All pages of the RFP document are to be signed by the authorized signatory. Any clarification sought can be Email. Any product name / function used in this document are meant to be generic and do not refer to the product of any particular company. In case such proprietary terms have been inadvertently mentioned then such terms should be taken to refer to the generic technology.

mailto:[email protected]


Non-Disclosure Agreement: All shortlisted bidders must sign the Non-Disclosure Agreement (NDA) for participating in the Request for Proposal (RFP) process. Bidders must comply with all clauses mentioned in the NDA. No changes to the NDA are allowed. The NDA must be executed on the bidders’ company letterhead.

Draft of the NDA is as under.

(Letter head of the bidder)

Strictly Private and Confidential

Principal Chief General Manager [Date] Reserve Bank of India Inspection Department, Central Office C-7, 8th Floor, Bandra Kurla Complex, Bandra (East) Mumbai – 400 051

[Salutation]

Confidentiality Undertaking We acknowledge that during the course of bidding for Request for Proposal (RFP) floated for supply, implementation and maintenance of Audit Management and Risk Monitoring System (AMRMS) in Reserve Bank of India (RBI), we may have access to and be entrusted with Confidential Information. In this letter, the phrase "Confidential Information" shall mean information (whether of a commercial, technical, scientific, operational, administrative, financial, marketing, business, or intellectual property nature or otherwise), whether oral or written, relating to RBI and its business that is provided to us pursuant to this Agreement. We agree to the terms set out below:

1. We shall treat all Confidential Information as strictly private and confidential

and take all steps necessary (including but not limited to those required by this Agreement) to preserve such confidentiality.

2. We shall use the Confidential Information solely for the preparation of our response to the RFP and not for any other purpose.

3. We shall not disclose any Confidential Information to any other person or firm, other than as permitted by item 5 below.

4. We shall not disclose or divulge any of the Confidential Information to any other client or vendor /implementation partner]

5. This Agreement shall not prohibit disclosure of Confidential Information:

o To our partners/directors and employees who have a bona fide need to know such Confidential Information to assist with the bidding for RFP floated for Supply, Delivery, Installation, Support/ Services,


Training, Testing, Commissioning, Warranty and Maintenance of AMRMS

o To the extent that such disclosure is required by law or by any rule or requirement of any regulatory authority with which we are bound to comply, provided that before any such disclosure the Bank is informed of the same sufficiently in advance to enable the Bank to take appropriate action, and,

o To our professional advisers who have a bona fide need to know such Confidential Information for the purposes of providing advice to us. Such professional advisors will be informed of the need to keep the information confidential.

6. We shall deliver to you all Confidential Information, and copies thereof, that

is in documentary or other tangible form, including copies in electronic form, except:

• To the extent that we reasonably require to retain sufficient documentation that is necessary to support any advice, reports, or opinions that we may provide to you.

7. This Agreement shall not apply to Confidential Information that: • is in the public domain at the time it is acquired by us; • enters the public domain after that, otherwise than as a result of

unauthorized disclosure by us; • is already in our possession prior to its disclosure to us; and • is independently developed by us, in which case, if so required

we undertake to provide proof of the same. 8. This Agreement shall continue perpetually unless and to the extent that you

may release it in writing. 9. We acknowledge that providing Confidential Information by the Bank will not

form the basis of any contract between you and us. 10. We warrant that we are acting as principal in this matter and not as agent or

broker for any person, company, or firm. 11. We acknowledge that no failure or delay by you in exercising any right,

power or privilege under this Agreement nor shall any single or partial exercise thereof shall by itself operate as a waiver of such right, power or privilege nor the exercise of any other right, power, or privilege in lieu thereof.

12. This Agreement shall be governed by and construed in accordance with Indian law and any dispute arising from it shall be subject to the exclusive jurisdiction of the Mumbai courts.

We have read this Agreement fully and agree with its terms. Yours sincerely Authorized Signatory and Stamp of Company [Authorized Signatory (same assigning the proposal) – Implementation Partner]


Table of Contents 1. Schedule .................................................................................................................................... 1

2. Introduction ............................................................................................................................... 2

2. 1 Background .......................................................................................................................... 2

2.2 Purpose of the Document .................................................................................................... 4

3. Structure of RFP ....................................................................................................................... 5

3.1 Annexure Seeking Response for Evaluation ..................................................................... 5

3.2 Definition of terms ................................................................................................................ 6

4. Overview of Present Audit and Risk Monitoring Universe in the Bank ......................... 8

4.1 Overview of Audit Universe ................................................................................................. 8

4.2 Overview of Risk Monitoring Universe .............................................................................. 12

5. Existing Information Technology (IT) Set-up in the Bank .............................................. 14

5.1 Existing Application and Interfaces ................................................................................... 14

5.2 Existing Data Centre set-up ............................................................................................... 15

5.3 Software Licenses with the Bank ...................................................................................... 15

5.4 AMRMS Hardware Infrastructure ...................................................................................... 15

6 Requirement from AMRMS .................................................................................................... 16

6.1 Introduction ......................................................................................................................... 16

6.2 Detailed Scope of the Project:-.......................................................................................... 16

6.2.1 Planning: ...................................................................................................................... 16

6.2.2 Audit Input:- .................................................................................................................. 18

6.2.3 Audit Output/Reports: .................................................................................................. 19

6.2.4 Compliance Monitoring: .............................................................................................. 20

6.2.5 Risk Monitoring ............................................................................................................ 23

6.2.6 Incident Reporting ....................................................................................................... 24

6.2.7 Concurrent Audit & Statutory Audit: ........................................................................... 24

6.2.8 CSAA - Control Self-Assessment Audit : ................................................................... 25

6.2.9 External Auditors (IS/ IT / Other audits)..................................................................... 25

6.2.10 Other Requirements: ................................................................................................. 25

6.2.10.1 Risk Classification/ Parameterization of Audits ................................................... 25

6.2.10.2 Document Management ........................................................................................ 26

6.2.10.3 User Management .................................................................................................. 26

6.2.10.4 Backup and Archiving ............................................................................................ 28

6.2.10.5 Activity log management ....................................................................................... 28

6.3 Technology Requirements ................................................................................................. 28

6.4 Security Requirements ....................................................................................................... 29


6.5 Other expected requirements ............................................................................................ 30

7. Scope of Work......................................................................................................................... 32

7.1 Introduction ......................................................................................................................... 32

7.2 Process & System Study ................................................................................................... 33

7.3 Preparation of Control Specification Document ............................................................... 33

7.4 Proposed Hardware and Software procurement ............................................................. 35

7.5 Data Migration Strategy and Data Migration Activity ....................................................... 35

7.6 Implementation ................................................................................................................... 37

7.6.2 Interface with existing Applications ...................................................................... 38

7.6.3 Execution ................................................................................................................ 39

7.6.4 Project Management Deliverables by Bidder ...................................................... 40

7.7 Training and Preparation of Training Material.................................................................. 41

7.8 System Integration Testing (SIT) and Users Acceptance Testing (UAT) ..................... 42

7.9 Post Implementation .......................................................................................................... 42

7.9.1 Warranty ....................................................................................................................... 42

7.9.2 AMC .............................................................................................................................. 43

7.9.3 Change Management .................................................................................................. 44

7.10 Phase-wise Deliverables ................................................................................................. 45

7.11 Security ............................................................................................................................. 46

8 Responsibility of Bidder ........................................................................................................ 47

8.1 Partnering with the OEM .................................................................................................... 48

9. Payment Terms & Milestones .............................................................................................. 49

9.1 Application Cost .................................................................................................................. 49

9.2 Hardware Costs (DC & DRC for AMRMS & Other Third Party Applications)................ 50

9.3 Payment terms .................................................................................................................... 50

9.4 Other Payment Terms ........................................................................................................ 51

10.1 Terminologies Used ......................................................................................................... 54

10.2 Purpose and Objectives of SLA ...................................................................................... 54

10.3 Scope of Services ............................................................................................................ 55

10.4 Performance Tracking and Reporting ............................................................................. 56

10.5 Problem Management and Escalation Procedures ....................................................... 56

10.6 Penalties............................................................................................................................ 56

10.7 Penalties for Delayed Implementation ............................................................................ 57

11 Overall Liability of the Bidder ............................................................................................. 58

11.1 Broad Terms and Conditions .......................................................................................... 58

11.2 Application ........................................................................................................................ 58


11.3 Standards.......................................................................................................................... 59

11.4 Governing Language ....................................................................................................... 59

11.5 Applicable Law ................................................................................................................. 59

11.6 Notices .............................................................................................................................. 59

11.7 Right to alter the Requirements ...................................................................................... 60

11.8 Contract Amendments ..................................................................................................... 60

11.9 Use of Contract Documents and Information ................................................................ 60

11.10 Escrow ............................................................................................................................ 61

11.11 Indemnification ............................................................................................................... 61

11.12 Cancellation of Contract and Compensation .............................................................. 62

11.13 Earnest Money Deposit ................................................................................................. 62

11.14 Performance Bank Guarantee ...................................................................................... 63

11.15 Resolution of Disputes .................................................................................................. 64

11.16 Delays in the Bidder’s Performance............................................................................. 65

11.17 Liquidated Damages ...................................................................................................... 65

11.18 Force Majeure ................................................................................................................ 66

11.19 Ancillary Services........................................................................................................... 66

11.20 Audits .............................................................................................................................. 66

11.21 Prices .............................................................................................................................. 66

11.22 Taxes and Duties ........................................................................................................... 67

11.23 Non Negotiability on RFP .............................................................................................. 67

12 Evaluation Process ............................................................................................................... 68

12.1 Objective of Evaluation Process ..................................................................................... 68

12.2 Technical Bid Evaluation Process................................................................................... 69

12.3 Scoring Methodology for Functional Requirements ...................................................... 70

12.4 Scoring Methodology for Product Structured Walkthrough & Presentation based on PoC ............................................................................................................................................ 71

12.5 Scoring Methodology for Approach, Methodology & Implementation Strategy .......... 73

12.6 Scoring Methodology for Team Composition ................................................................. 74

12.7 Scoring Methodology for Past Experience(PE) in Banking Sector .............................. 75

12.8 Consolidated Score in Technical Bid Evaluation ........................................................... 75

12.9 Disqualification Parameters in Technical Bid Evaluation ............................................. 76

12.10 Commercial Bidding by Reverse Auction Process ..................................................... 76

12.11 Technical-Commercial Bid Evaluation .......................................................................... 79

13. Instructions for Tender submission ................................................................................. 81

13.1 Instructions for Tender submission ................................................................................. 81


13.2 General Guidelines .......................................................................................................... 82

13.3 Clarification on the Tender Document ............................................................................ 83

13.4 Amendments to Tender Documents ............................................................................... 83

13.5 Language of Bids ............................................................................................................. 84

13.6 Period of Bid Validity ........................................................................................................ 84

13.7 Format and Signing of Bid ............................................................................................... 84

13.8 Correction of Errors .......................................................................................................... 84

13.9 Acceptance and Rejection of Bid .................................................................................... 84

13.10 Duration and Condition of Engagement ....................................................................... 84

13.11 General Terms and Conditions ..................................................................................... 85

13.12 Other Terms and Conditions ......................................................................................... 86

13.13 Expenses incurred by Successful Bidder on the Project ............................................ 88

13.14 Evaluation and Comparison of Bids ............................................................................. 88

13.15 Notification of Awards .................................................................................................... 88

13.16 Authorized Signatory for Signing the Contract ............................................................ 88

13.17 Signing of Contract ......................................................................................................... 89

13.18 Vicarious Liability ............................................................................................................ 89

13.19 Assignment ..................................................................................................................... 89

13.20 Non-Solicitation .............................................................................................................. 89

13.21 No Employer– Employee Relationship ......................................................................... 90

13.22 Subcontracting................................................................................................................ 90

13.23 Design Ownership .......................................................................................................... 90

14. Annex 1 – 16 (Provided Separately) ......................................


1 Confidential and for Restricted Use

1. Schedule The following is an indicative timeframe for the overall process. The Bank

reserves the right to vary this time frame at its absolute and sole discretion and

without providing any notice/intimation or reasons thereof. Changes to the

timeframe will be relayed to the affected Respondents during the process.

Table1: Time frame for the Overall Process Process Date 1 Issue of RFP Document January 25, 2016

2 Last date and time for receipt of written queries for clarification from bidders

February 01, 2016

3 Date and Time of Pre-Bid Meeting February 03, 2016 at 11:00 AM

4 Date & Time of Final Submission of Bid in Sealed Cover February 17, 2016 by 4:00 PM

5 Date and Time of Technical Bid Opening February 18, 2016 at 11:00 AM

6 Technical Bid Presentation Before the Committee To be intimated later

7 Commercial Bid by Reverse Auction To be intimated later

I Place of opening of Bids/ Meetings /

Presentations Inspection Department, Central Office Conference Room, C-7, 7th Floor, Bandra Kurla Complex, Bandra East Mumbai – 400 051

II Any Queries to be mailed to [email protected]



2. Introduction Reserve Bank of India (hereinafter referred to as the RBI or the Bank) desires to

procure an Audit Management and Risk Monitoring System (AMRMS) for the Bank

from potential shortlisted solution providers. The AMRMS will be a comprehensive

package to facilitate Internal Audit and Risk Monitoring functions of the Bank.

The Bank has 33 Central Office Departments located at Mumbai and has 19

Regional Offices, most of them in state capitals and 9 Sub-Offices. In order to

provide adequate training from time-to-time, Bank has established 2 Training

Colleges and 4 Zonal Training Centers at different parts of the country. Inspection

Department, one of the Central Office Departments is entrusted with the work of

performing Inspection/ Internal Audit of the other Central Offices, Regional Office,

Training Colleges/Centers, Subsidiaries and Data Centers. The Risk Monitoring

Department (RMD) is entrusted with implementation of Enterprise-wide Risk

Management System in the Bank. RMD has two divisions looking after operational

risks and financial risks.

2. 1 Background The Bank has decided to implement AMRMS to carry out various audit and risk

monitoring related activities efficiently in a seamlessly integrated fashion, thereby

replacing the existing system which is partially computerized, mostly in regard to

compliance and follow up with regard to audit activities, and preparation of Risk

Register and Incident Reporting with regards to Risk monitoring activities. The

Inspection Department (ID) of the Bank currently uses separate templates for Risk

Ratings and also the Risk Registers provided by Risk Monitoring Department (RMD),

which, however, are not presently being kept at a single place for efficient usage and

updation. Further, there is no database readily available on risk scores and the same

is required to be manually prepared from hard / soft copies of reports. There is no

system for Auditee offices to check their compliance status or for the Department/

Top management to check the same independently.

The envisioned AMRMS should be capable of providing an end-to-end solution from

audit planning to final closure of the report. It envisages a centralized web-based

Application which is browser independent (preferably), which would be hosted at

Data Centre and seamlessly connect all stakeholders for its usage. The proposed



AMRMS will be useful for inspection resource planning, recording audit observations,

generating audit reports, preparation of Risk Registers, analysis of data, preparation

of MIS reports such as Incident Reporting, Heat Maps, Risk Scores etc., for effective

compliance processing and monitoring of audit and risk monitoring functions. The

AMRMS would require preparation of detailed and logically sequenced checklist for

various processes undertaken by the business owner/auditees. The scalability that

would be provided by AMRMS would enhance the ability of the Inspection

Department to assess risk and controls and provide risk assurance by evaluating the

incident report and checklist / Risk Register, etc. Users from Inspection Department,

RMD and auditee departments can be differentiated in terms of user rights.

RMD database on Risk Register and Incident Reporting system is currently being

operationalized and would be integrated with AMRMS. RMD would require a

separate front-end access to the database for preparation / updation of the Risk

Registers and reporting of incidents. AMRMS would primarily handle the

requirements of the stakeholders as mentioned in Diagram 1.



Diagram 1 – Audit and Risk Management Structure

2.2 Purpose of the Document The bidders desirous of taking up the project for supply of above mentioned solution

for the Bank are invited to submit their technical and commercial proposal in

response to this RFP. The criteria and the actual process of evaluation of the

responses to this RFP and subsequent selection of the successful bidder will be

entirely at Bank’s discretion. This RFP seeks proposal from shortlisted Bidders who

have the necessary experience, capability & expertise to provide the Bank a solution

for Audit Management, Risk Management / Monitoring, other types of audit, Off-site

Audit, Incident Reporting etc. adhering to Bank’s requirement outlined in this RFP.

This RFP is not an offer by the Bank, but an invitation to receive responses from the

Bidders. No contractual obligation shall arise from the RFP process unless and until

a formal contract is signed and executed by duly authorized official(s) of the Bank

with the selected Bidder.



3. Structure of RFP

This document is the master RFP consisting of:

• the overview of services to be provided by the selected Bidder;

• the current technology infrastructure in the Bank;

• an overview of the solution architecture, software, hardware and facilities

management services required from the Bidder;

• the technical and commercial evaluation methodology which shall be followed

to select the successful Bidder; and

• The terms and conditions to which this RFP and the Bidder responses shall

be subjected to. The Bank shall enter into a separate contract after selecting

the Bidder, which shall detail the terms and conditions.

3.1 Annexure Seeking Response for Evaluation

A detailed set of annexures is provided to the Bidder for formulation of responses for

evaluation covering sections such as functional requirements, technical

requirements, proposed team fitment/ strength, Data Migration and Project

Methodology, Training the Bank’s Personnel, etc. The list of such annexure is

provided below in the Table 2: Annexure Seeking response for Evaluation. Table 2: Annexure Seeking response for Evaluation

Annexure Content / Details

Annex 1 Pre-Qualification Criteria

Annex 2 Bank Guarantee Proforma

Annex 3 Work Plan Format

Annex 4 Conformity of Soft Copy

Annex 5 Bidder Undertaking

Annex 6 Experience Details

Annex 7 Confirmation to Deliver

Annex 8 Pre-Bid Query Format

Annex 9 Proposed Team Profile

Annex 10 Bidder Details

Annex 11 Undertaking Accepting Escrow Agreement

Annex 12 Functional Requirements

Annex 13 Compliance Certificate Commercial Bid



Annex 14 Commercial Bid Format

Annex 15 Check List

Annex 16 Abbreviation List

3.2 Definition of terms Definitions – Throughout this RFP, unless inconsistent with the subject matter or

context:

• Bidder/ Service Provider/ System Integrator – An eligible entity/firm submitting

a Proposal/Bid in response to this RFP

• Supplier/ Contractor/ Vendor – Selected Bidder/System Integrator under this

RFP.

• Bank/ Purchaser/ RBI - Reference to the “the Bank”, “Bank” and “Purchaser”

shall be determined in context and may mean without limitation

• Proposal/ Bid – the Bidder’s written reply or submission in response to this

RFP

• RFP – the request for proposal (this document) in its entirety, inclusive of any

addenda that may be issued by the Bank.

• Solution/ Services/ Work/ System – “Solution” or “Services” or “Work” or

“System” or “IT System” means all services, scope of work and deliverables to

be provided by a Bidder as described in the RFP and include services

ancillary to the development of the solution, such as installation,

commissioning, integration with existing systems, provision of technical

assistance, training, certifications, auditing and other obligation of the Supplier

covered under the RFP.

• Project Cost - Project cost would be initial cost/ one-time cost/ fees/

development Cost/ installation cost/ commissioning cost/ integration cost with

existing systems/ customization cost/ training cost/ technical assistance

excluding Hardware infrastructure cost.

• Warranty – The Bidder will be required to provide one year of on-site support,

extendable at the Bank’s discretion and two years of off-site support during

the Warranty Period. The date of start of warranty period would be the date of

issue of “Completion Certificate” by the Bank. During the Warranty period the

Bidder would be required to undertake all necessary modifications not falling



under the purview of change management such as updates, bug fixes or any

other support as and when required.

• Annual Maintenance Contract (AMC) - Post implementation support will be

required during the AMC period on an off-site basis generally, however, on-

site support on need basis would be required to resolve any issues on

immediate basis.

• Change Management – Any request by the Bank that results in changes in

the structure of the application or a new module is added would be considered

as Change Management. Any minor changes required in the application such

as addition / deletion / alteration of a row / column / field, additional report,

menu items will not be considered as part of Change Management.

• Man-day – 9 hours of work of a qualified person.

• Week – 7 Calendar days.

• T – Technical Score of the Bidder

• THigh - The Bidder with the highest technical score shall be ranked as T1 and

be considered as THigh for the technical-commercial score

• C – The final price quoted by the bidder after Reverse Auction.

• CLow - The lowest Commercial Bid after ‘Reverse Auction’ would be declared

as CLow.

• TC1 – The successful Bidder after the ‘techno-commercial’ Bidding process

A detailed list of abbreviations is provided in Annex 16.



4. Overview of Present Audit and Risk Monitoring Universe in the Bank

4.1 Overview of Audit Universe

Inspection Department is tasked with the mandate of providing an independent and

objective assurance/feedback on the operations/working of the offices of the Bank. It

examines/evaluates and reports on the adequacy and reliability of the Bank's internal

controls and governance process to provide risk assurance.

The ID is also the Secretariat to the Audit and Risk Management Sub-Committee

(ARMS) of the Central Board of the Bank and also reports its assessments to them.

Additionally, it places the findings of Information Systems (IS) audits before the

Information Technology Sub-Committee (ITSC) of the Board. Audit observations

which have been classified as High Risk are placed before the Executive Directors’

Committee (EDC) / ARMS for their review and guidance. The Internal Audit function

constitutes a key dimension in the Bank's governance architecture.

Streams of Inspection in the Reserve Bank

Presently, the following types of inspections are carried out/co-ordinated by ID:

• Risk Based Internal Audit (RBIA) • Information Systems Audit / Technology Audit • Vertical Audit • VA-PT • Concurrent Audit (CA) • Control Self-Assessment Audit (CSAA) • Statutory Audit (Limited Role)

Risk Based Internal Audit (RBIA) Under the Risk Based Internal Audit (RBIA), the ID provides independent and

objective opinion to the Top Management on whether or not the Bank's business

processes and risks are being properly managed. The RBIA reviews the outcomes of

all other audits. Audit of various business units viz. Central Office Departments

(CODs), Regional Offices (ROs), Training Establishments (TEs), Banking



Ombudsman Offices (BO) and Associate Institutions (AIs) are taken up at different

periodicities ranging from 12 to 24 months.

Information System Audit (ISA) / Technology Audit Information Security audit is carried out as part of the RBIA framework to evaluate

risk control measures in Information Systems used in the Bank. The Department also

carries out technology audit of computer applications/systems, technology platforms,

services, etc. These are carried out either at the directions of Central Board/ Audit

and Risk Management Sub-Committee (ARMS)/ Information Technology Sub-

Committee (ITSC)/ Top Management or on receipt of request from the Business

Owner Departments/ User Departments/ Department of Information Technology

(DIT), CO or as felt necessary by the Department considering the criticality/

importance of operations/systems.

Vertical Audit A vertical audit is when all / few processes of CODs / across ROs are audited at a

time. In this type of audit it can be easier to see how the same process(s) are

implemented across the Bank. Vertical audit may assist in identifying whether

different procedures are being adopted for the same process across the Bank.

Vulnerability Assessment and Penetration Testing (VA-PT) Audit Vulnerability Assessment and Penetration Testing (VA-PT) of the IT Systems /

Applications in the Bank enables to achieve a complete vulnerability analysis of

these systems in the Bank.

VA-PT discovers which vulnerabilities are present that can be exploited to cause

damage. Penetration tests attempt to exploit the vulnerabilities in a system to

determine whether unauthorised access or other malicious activity is possible and

identify which flaws pose a threat to the application. Penetration tests find exploitable

flaws and measure the severity of such flaws/ breaches.

The Bank generally outsources the conduct of VA-PT to an external service provider

which enables the IT security team of the Bank to focus on mitigating critical

vulnerabilities while the VA-PT provider continues to discover and classify

vulnerabilities.



Concurrent Audit (CA) As a part of internal control mechanism, all the business units at CODs / ROs / TEs

are required to get their transactions (mainly financial transactions) audited by

external chartered accountant firms, concurrently with the occurrence of such

transactions.

Control Self-Assessment Audit (CSAA) This is a self-assessment/ health check-up exercise to assess gaps in risk controls

so that timely reviews are made and corrective action taken/initiated to address the

gaps. The assessments are carried out by persons unconnected with the operations/

process being assessed. All business units are required to conduct CSAA at least

twice in a year, that is, for the half-year ended June and December every year. The

findings of the CSAA report is handled at the business unit level however the

exception report of CSAA is to be forwarded to ID for further action if any.

Statutory Audit (Limited Role) The findings / observations of the Statutory Audit of the Bank and its Offices may be

used by the ID as an input for its audit purposes.

Compliance, Follow-up and Reporting ID follow-ups on the audit observations (RBIA, ISA/ TA, CA, CSAA, Vertical Audit,

VA-PT etc.) to ensure that prompt corrective actions or risk mitigating counter-

measures are initiated. The Department undertakes off-site monitoring as well as on-

site evaluation, wherever necessary. Off-site monitoring is undertaken by obtaining

periodical returns from business units, analysing them and initiating follow-up as

deemed appropriate.

ARMS / EDC/ ITSC/ CB/ CCB Meetings The Department co-ordinates and arranges periodical meetings of Audit & Risk

Management Sub Committee (ARMS) and Executive Directors' Committee (EDC).

The meetings of ARMS and EDC are conducted generally once in three months. On

half yearly basis, the Department reports to Information Technology Sub-Committee

(ITSC) of the Board on Information Systems (including Security) audits undertaken

by the Department.



Current Audit Infrastructure The Department has been using locally developed in-house package, Compliance

Monitoring and Reporting System (COMORS) for its compliance processing.

COMORS serves as an MIS and as a repository of inspection findings gathered in its

database over the years. COMORS is an oracle based application hosted in a server

maintained by the Department. The access to the application is restricted to the

users of this Department. Overview of the COMORS system is as under:

1. The COMORS RIF is a web application. TOMCAT 5.5 is used as the

SERVLET container (Web server). The system uses Oracle 9i for the

persistent layer.

2. Java is the programming language and developed using the Eclipse 3.2 IDE.

JSP is used for view. Struts is the Framework implementing the MVC

structure in the application

Under RBIA, Fact sheets are prepared in excel/word format for each of the work

area (Department/Section at Auditee Office) and reports are prepared based on the

fact sheet observations. Report is divided into sub reports – Functional and

Information systems. Each sub report contain observations about all the departments

in following format

i. Department/Section Name ii. Functional Component Name iii. Running Serial Number iv. Observation v. Risk Rating vi. Fact Sheet reference number(s)

The IS Report has an additional column next to the Functional Component Name viz.

IS Domain Name.

Diagram 2 and Diagram 3 illustrate the process work of an audit and its audit

reporting, e.g. RBIA. The other audit types work flow and reporting follow more or

less the same process.



Diagram 2 – Workflow of an audit (RBIA)

Diagram 3- RBIA Audit Report Structure

4.2 Overview of Risk Monitoring Universe

The Risk Monitoring Department (RMD) is entrusted with implementation of

Enterprise-wide Risk Management System in the Bank. RMD has two divisions

looking after operational risks and financial risks. For effective identification,

assessment and management of risks uniformly throughout the Bank, RMD:



• Prepares a broad risk management framework and also formulates and

periodically reviews Bank’s policies/ methodologies/ matrices by interaction

with functional units to ensure that all significant risks are identified.

• Aggregates, monitors and periodically reports the risks reported by functional

units to the Risk Monitoring Committee (RMC) and Audit and Risk

Management Sub-Committee (ARMS).

• Assess and reports the financial risks arising out of the Bank’s policy actions

to the RMC and ARMS.

• Creates institutional memory by building a database of ‘loss’ and ‘near loss’

events.

• Periodically reviews the adequacy and appropriateness of the Bank’s

Business Continuity Plans (BCPs) and systems.

• Helps to foster risk management culture in the organisation.



5. Existing Information Technology (IT) Set-up in the Bank

5.1 Existing Application and Interfaces

Various IT applications have been deployed in various functional areas to facilitate in

handling of various functions in the Bank. These are disparate systems built on

different hardware and software over a period of time. Current status of these

systems, the areas in which they are deployed, hardware and software details and

their interfaces with each other are summarized below.

Current IT infrastructures in various applications deployed in the Bank are provided

in the following tables:

Table 3 : Various Applications

Application I Application II Hardware Xeon server Xeon server O.S. Win 2000/2008 server and web

based clients Win 2000/2008 server and web based clients

Software Application software developed in Java and Oracle Database

PeopleSoft HCM version 8.9 customized to a large extent and Oracle Database

RDBMS Oracle 11g z 196 z Linux Oracle 11g z 196 z Linux

Application III Application IV

Hardware HP Superdome Flap barrier system , Readers, Controllers, EM LOCK, Power supply(12V), Emergency switch, Enrolment Kit and Cabling wire and smart card

O.S. HP Unix WINDOWS XP/WINDOWS 2000 Back end‐ Oracle data base

Software Intellect CBS Back end‐ Oracle data base. The front end application maintained by M/s BEL has various web browser based modules including Attendance Monitoring System

Application V Application VI Hardware Memory ‐ 16 GB

Vendor ‐ Genuine Intel Model Name ‐ Intel(R) Xeon(R) CPU X5260 @ 3.33GHz No of Processors –4 CPU Cores – 2

Memory ‐ 16 GB Vendor ‐ Genuine Intel Model Name ‐ Intel(R) Xeon(R) CPU X5260 @ 3.33GHz No of Processors –4 CPU Cores – 2



O.S. Windows XP Red Hat Enterprise Linux 4 (RHEL 4)

Software Front end –J2EE, Back end Oracle data base

Oracle Application Server 10.1.2.0.2

RDBMS Oracle 11g z 196 zLinux Windows 2003 (Web &App)

Table 4 :

Application VII Hardware Intel System

O.S. Hyper V, Windows 2012 Software SAP HCM Linkages with other systems

CBS, ESCAMS, DMIS

RDBMS Sybase

5.2 Existing Data Centre set-up Replication (2 Way) between PDC and DRDC:-

For Business Continuity Management the data from the Primary site is being

replicated asynchronously to the DR site. The replication is done by using the SAN

replication methodology. The replication is bi-directional.

5.3 Software Licenses with the Bank The Bank has the following Oracle PeopleSoft licenses:

a. PeopleSoft Enterprise Human Resources

b. PeopleSoft Enterprise Talent Acquisition Manager

c. PeopleSoft Enterprise eProfile

d. PeopleSoft Enterprise eDevelopment

e. PeopleSoft Enterprise Absence Management

f. PeopleSoft Enterprise Candidate Gateway

g. PeopleSoft Enterprise eProfile Manager Desktop

5.4 AMRMS Hardware Infrastructure AMRMS is expected to be hosted and implemented on the hardware, software and

other infrastructure facilities available in the Bank’s onsite and off-site Data Centers.

The bidders are expected to furnish information about the infrastructural

requirements of the proposed solution.



6 Requirement from AMRMS

6.1 Introduction AMRMS would cater to the requirements of primarily two Departments of the Bank

i.e. Inspection Department and Risk Monitoring Department. However, the AMRMS

will be used by the other CODs/ Offices of the Bank also for compliance submission,

incident reporting, Risk Registers, inspections conducted locally at the Auditee

Offices. The scope of the AMRMS would cover the areas as mentioned below;

however, the Bidder may get clarification, if required to get more insight into the

functioning of ID and RMD. Currently, the Auditee Offices under the purview of

Inspection Department consist of Central Office Departments (CODs), Regional

Offices (ROs) including Sub Offices attached to ROs, Training Establishments,

Subsidiaries of the Bank etc. The system would be an online web based application

with a centralized database and is browser independent (preferably). AMRMS will

have an off-line functioning capability and an automated work‐flow across all

processes covering the entire audit and risk universe of the Bank.

6.2 Detailed Scope of the Project:-

6.2.1 Planning: Audit Planning would cover the following:

1. Preparation of Audit Calendar – An audit calendar for the year should be

provided. Audit plan would depend on last audit conducted, size and risk ratings

of COs / ROs, available resources etc. Further, there should be a provision of

periodic (Monthly / Quarterly / Half Yearly/ Ongoing) tracking of status of the

Audit Plan. Audit planning feature need not be necessarily updated on a prior

date. It should have the facility to update for any type of audit on a post facto

basis also. For example, on completion of audit, when the audit reports are

uploaded onto AMRMS, allocation of work areas to the auditors can also be

updated. Application should have capability to perform Inspection of a Sub-Office

within Main Office.

2. Allocation of man-days - Calculation of man-days should be based on certain pre-

determined parameters which will be editable from the front end.

3. Allocation of resources - The module for allocation of resources should refer to

User master of Inspection Department to select the auditors. A provision to see /



upload training / experience details of auditors / PIOs would be required. There

should also be a provision to include users pertaining to other Department(s) in

case of special scrutinies / IS Audit or audit firms in case of technology audits etc.

The system should provide a list of probable auditors for the audit based on pre-

defined criteria.

4. Pre-audit data/information in respect of auditees – Functionality for preparation of

Pre-audit data/information for Auditor / Inspector from existing reports / Risk

Registers / Incident reports / Checklist etc., should be provided. Further, provision

to update and review the pre-audit facts on periodical basis and the updated

document with date should be available on AMRMS. There should be a provision

for uploading Inspection related instructions / circulars required by external /

internal auditors / inspectors. A field namely “scope of audit” should be a

mandatory field for each audit.

5. Checklist Modification/ Management - The system would have the complete

library of Checklists for different types of audits, with multi-tiered hierarchy,

identification for criticality, mapping to various controls and quantification of

risks/deviations/ scores and revenue leakages. Checklist Management should be

fully parameterisable to enable administrative users to add/ edit any new set of

checklists/controls. Provision of linking of the checklist to the Risk Registers and

vice versa should be there.

6. Audit Intimation - As and when a new inspection program is scheduled and a

team is formed, AMRMS should send an intimation mail / SMS to the Principal

Inspecting Officer (PIO) of the audit assignment and composition of the team

along with the list of chapters/areas to be covered by the audit team. The PIO

should have the option of sending intimation e-mails/ SMS to the team members

about the audit assignment and allocation of chapters.

7. Message Broadcasting - The system should have provision to transmit /

broadcast instructions / messages to all auditors / auditors of one team / all

PIO’s/ all nodal officers of the auditee locations for correspondence purposes etc.

8. Addition/ Deletion of audit entities/types of audit - . There should be provision for

addition/deletion of any new genre of audit. Also there should be provision to



add/merge/delete check lists/RRs as and when there is merging of Departments/

Offices, creation of new Departments / Offices would be necessary. In the event

of renaming of process / Department / Office etc. a proper tagging should be

there of the old / previous process/ name / department / office etc. with the

changed / new name / identity.

9. The Application should also have the similar functionality with regard to audit

planning at the auditee office for all the inspections / audits conducted locally.

6.2.2 Audit Input:-

1. Uploading of Audit Reports: Auditors / Inspecting Officer (IO) while inputting

data / uploading the audit reports, the same has to be linked with the audit

program created. This shall include mapping of the auditor(s) to respective

chapters/audit-areas in case of RBIA. The system should have facility to

upload various types of audit observations with necessary classifications /

parameters / grouping, marking to one or more auditees; e.g., Risk Based

Internal Audit (RBIA), Technology Audits, etc. There should be facility of use

of Digital Signature or by any other authentication mechanism as pre-

determined at the time of uploading of reports by IOs/ PIOs and other users.

The Application should have the capability to display / generate reports of

previous open pending inspection / audit observations to Inspector / Auditor

for cross reference.

2. Uploading of Attachments / Data: There should be provision to upload draft

reports by auditors in a structured format. The auditor should be able to attach

any work-papers /evidence /references in any format i.e. Word/ Excel/ Jpeg/

Pdf etc. There should be a field linking the work-papers / evidence to a

reference source. Provision to upload the entire audit report at once or

individual para wise should be there. Further, the system should enable to

upload and analyze data contained in reports from other packages like DMIS,

CBS, IES etc. running in the Bank (list of applications running in the Bank is

furnished in Chapter 5). While using data from other packages, original form

of data should be maintained. There should also be scope for customization

of data formats, if needed.



3. Evaluation by PIO: On submission of report by auditors, an alert (vide email /

SMS and also notification on screen) would be received by the PIO. Once

report is submitted to the PIO, auditor / IO should not be allowed to modify the

said report further. The PIO would have rights to modify any part of the report

by himself and also to send back the report / part of the report to the IO. The

PIO may also conduct an audit himself / herself and maker / checker concept

may not be applicable for submission of such reports. A provision for the PIO

to give suggestions / learning points / highlights/ confidential inputs to the Top

Management.

4. Calculation of Risk Score: The system would generate the Risk Rating of

Auditee Office/ Department automatically based on set parameters. It will also

generate a Heat-Map of the same in graphical form.

5. Final Submission: On Final submission of Report by PIO / relevant authority

message / SMS should be sent to Auditee Department, Planning Section and

Compliance Monitoring Team or any other authority as decided. The system

would have provision to generate letters in structured form in hard and soft

copy to the various stakeholders, like, Auditee office, respective COD, Top

Management, etc as per pre-defined template. There would also be provision

to change the template dynamically as per the need.

6. All Uploading / Downloading of reports should have a time-stamp.

7. Provision to indicate time frame for submission of compliance by the auditee

office to be provided in the audit report.

8. The Application should also have the similar functionality at the auditee office

for all the inspections / audits conducted locally.

6.2.3 Audit Output/Reports: 1. Report Generation: Facility to generate standard/ ad-hoc MIS reports on

various parameters/ status on/ across various audits, say, in terms of domains

/ classification of observations / areas of audit activities, auditee wise etc. with

drill down/ across feature over more than one variable - Exceptions observed/

closed/ pending/ criticality – COD wise, RO wise, exception-wise, pending

issue-wise, age-wise. Date wise, criticality wise and other parameters

dynamically. The report generation tool should be user-friendly with drag &

drop facility to add a new column or field.



2. Report Confidentiality: There would be access control for viewing and

downloading of the various reports, e.g., an auditee should not have access to

the report of another auditee. A report when is downloaded should contain

timestamp and User Id of the user at the footer. It may be noted that the

application should give an option to users at the time of downloading of

reports whether user wants the report in Word, Excel, PDF or any other

format.

6.2.4 Compliance Monitoring: 1. Submission of Compliance: The Application should enable the processing of

compliance by the local Business Unit at the Auditee Office and the final

compliance submission by the nodal officer at the Auditee Office through

AMRMS itself in a seamless, end to end, integrated fashion.

2. Nodal Officer at the Auditee Office would be responsible for all communication

/ compliance submission with ID.

3. The compliance module should have provision for uploading the response of

ID both para-wise or to multiple paras in a particular section / Office /

consolidated report. The auditee offices would be required to submit

compliance online duly signed digitally by the concerned authority or by any

other pre-determined authentication mechanism.

4. Compliance Processing: Compliance module would necessarily have

provision to keep track of previous compliances, if rejected earlier along with

the comments of ID as and when new compliance is submitted with complete

audit trail.

5. Compliance processing officer should have functionally to link / upload any file

/ annexure etc. as part of compliance processing.

6. For effective compliance processing of different types of audit in the Bank

there should be a provision for categorizing the compliance post scrutiny as

per business needs e.g. Chapter / Department / Functional area wise,

Functional / IS domain wise, Risk rating wise, etc.

7. During the course of compliance scrutiny provision to mark the para to

another auditee, if need be under any audit is required, e.g. Design gap paras

found in ROs may need to be marked to CODs. Further, the system should

allow to review the compliance received from more than one auditee (if



marked to them initially or during the course of compliance scrutiny) at single

place. Provision for comparison / cross referencing various audit reports over

a period of time should be available.

8. Maker / Checker Principle: Compliance processing at ID must follow the

maker / checker principle. Officers of Follow-Up Section may accept/ approve

the compliance submitted by auditee as well as compliance scrutinized at ID.

Top Management would have the privilege especially to access executive

summary, key observations etc. The system shall not allow same person to

both act as “maker” and “checker” for accepting any given compliance.

9. Closure of Compliance: Acceptance of exceptions and closure of the same

can be made in ID by Compliance Cell /other higher level. Any rejection of the

compliance submitted for various reasons would require the comments by the

Compliance Follow up Officer / other higher level. Resubmission of

compliance by CODs/ROs and rejection of the same would be allowed

multiple times and history as well as audit trail of same would be necessarily

maintained. Any acceptance/ rejection of compliance should be authorized by

the individuals Digital Signature or by any other authentication mechanism as

pre-determined.

10. Compliance status for the audit observations could be “Outstanding,

“Complied with”, “May Not be Pursued (MNP)”, “MNP – Risk Accepted by

Auditee”, etc. There may be a provision to add other types of compliance

status, if required.

11. Depending on nature of risk rating of the inspection paragraph the system

shall have customizable feature to define who can accept the compliance. For

example, a ‘Low’ risk para in RBIA, the compliance could be accepted at

Auditee Level itself with maker checker control while a ‘High’ risk para can be

accepted only by Head of ID (and above). Compliance in respect of CSAA,

CA, ISO/ISMS audits also shall be accepted at Auditee Level itself. For

compliances to be accepted at auditee level, ID shall have a view facility to

know what the compliance submitted and overall outstanding /compliance

position.

12. There shall be provision to track the time period requested by the auditee in

submission of compliance until which the paras may be treated as MNP. This

shall be useful in case of observations in nature of design gaps which need



not be repeated across all the ROs. If, compliance is not submitted before

expiry of time line, then the paragraphs would automatically be termed as

outstanding and it shall be commented upon in the very next Audit/Inspection.

There shall be a system to monitor the paras treated as MNP (MNP-RAA) for

which timelines are fixed to take necessary further action. This system can be

auditee wise along with summarized report sorted time wise as well.

13. Search & MIS Report Generation: A facility to search compliance / Reports /

findings in terms of Departments / Offices / Areas or any other relevant

parameters with required data protection and user access controls is required.

Generation of reports related to status of compliance submission on user

defined parameters. Further, there should be a provision for the auditees to

view status of the compliance submitted.

14. The application should have the functionality of generating reports providing

assurance in terms of quality management of the audit reports by cross-

comparison of the similar / identical audit findings and the risk scoring.

15. The application should have the functionality of graphical representation and

generation of reports of risk movement of the processes / audit units /

Business Units, etc.

16. Notifications: The system would alert various stakeholders through

SMSs/emails at different levels at the time of generation of reports; reminders

for non-compliance; escalation of pending items to various higher levels,

critical issues, periodical pending status etc. Additionally system should also

raise an alert as per the assigned parameters / crossing of deadline given by

the auditee office / BU in the audit report.

17. The Application should also have the similar functionality with regard to audit

compliance at the auditee office for all the inspections / audits conducted

locally.

6.2.4.2 Compliance Monitoring of ARMS / CB/ CCB/ EDC/ ITSC and other meetings.

1. Agenda Preparation: There may be a provision for providing an input for

Board / Committee meetings. The Agenda may be prepared from a set

template and downloaded in an editable Word format.



2. Minutes Preparation: The system may also provide functionality for capturing

the Minutes of the meeting and taking acknowledgment of the same through

email from the participants of the Meeting.

3. Follow-up of Action Points: The system may also provide way for tracking the

action points and compliance of the same from various Departments.

6.2.5 Risk Monitoring 1. There shall be a provision for populating / editing / deleting / updating /

aggregating / disaggregating the Risk Register (RR). The application should

facilitate risk rating based on pre-defined algorithm. The risk registers shall be

updated/ added by respective authorized users. Log of the changes along

with User-ID should be maintained.

2. There shall be facility to view the risk registers of each of the work unit

(Department/Section) of RO, risk registers of CODs and Training

Establishments. Individual Auditee Offices would be able to view their own

RR. Any updation of the RR by the individual Auditee Offices would have to

be authenticated by RMD.

3. Application should be capable of generating standard and Ad-hoc outputs,

including Heat Maps, to be generated based on contents of the RR. The

output including heat maps should be generated at any level of aggregation or

disaggregation based on selected parameters (Sections / Divisions/

Departments / Offices / Verticals or for the Bank as a whole). A dashboard

facility for report generation should be provided.

4. Facility for drill down of the Heat Maps should exist. There should be a

provision to cross compare RR and Checklists of ID. Facility to extract data

from the Risk Register and use it elsewhere the current RR data should be

migrated to the new database.

5. The system would provide discretionary Access Control for populating/

editing/ deleting/ updating etc of the Risk Registers. It would provide time

stamp and user id and similar actionable intelligence for security, compliance,

& operational issues. A provision for the ID Auditors to provide inputs for the

Risk Register should be provided. The inputs may either be incorporated or

rejected is to be decided by RMD.



6. As and when any update / modifications are made to RR, the system should

notify ID and the concerned Department to the changes.

7. System should have the capability to generate reports for the various types of

Risks like inherent risk, residual risk etc of the processes / Risk Register in

various scenarios like when controls are effective/ ineffective / failed.

6.2.6 Incident Reporting

1. There should be a facility for uploading of Incident Reports to the system by

using the Incident Reporting Template (IRT).

2. Provision to classify the incident, status of incident, incident description as

part of Incident Reporting System as per the incident reporting guidelines

shall be provided online as part of AMRMS.

3. The incident reporting system shall have reporting/escalation, acceptance,

closure facility. Only authorized users shall have provision to report an

incident, accept the incident and close an incident.

4. MIS report generation shall be available to view incidents, selected based on

one or more parameters of incidents. A facility to search through the database

of incidents based on type / location / keyword should be provided.

6.2.7 Concurrent Audit & Statutory Audit: 1. Concurrent Audit and Statutory audits are conducted by External Agencies in

coordination with individual Department / Offices. The System should contain

a separate module for Concurrent Auditors / Statutory Auditors to report their

audit findings and submit their audit report to CO. The Auditee Offices are

responsible for compliance with the audit findings and functionality for the

same is to be provided.

2. MIS Report & Notification: There should be a provision for generation of MIS

reports on concurrent audit / statutory audits for submission to Top

Management. Further, ID should be able to communicate instructions /

messages to Auditee offices and Auditors in connection with these audits.

3. External Auditors User Creation: The Nodal Officer at auditee locations would

request the ID to create user for concurrent / statutory / external auditors by

submission of an online application form. The Administrator in ID would be the

final authority for creation of user and assignment of rights to the external

auditors.



6.2.8 CSAA - Control Self-Assessment Audit : 1. Facility should be provided for COs/ ROs to

i. Update CSAA checklist

ii. Assign users from their Department for conduct of CSAA and uploading

of CSAA findings including exception reports, if any.

iii. Submission of Compliance of CSAA by respective sections of auditee

offices

2. MIS Report & Notification: ID should be able to oversee compliance status

and submit report of the conduct of CSAA to Top Management. Further, ID

should be able to communicate instructions / messages to Auditee offices and

Auditors in connection with these audits

6.2.9 External Auditors (IS/ IT / Other audits) 1. AMRMS should provide a facility for External Auditors to submit Final /

Intermediate audit report to auditee offices and ID.

2. There should be provision for ID to accept / reject audit reports / audit findings

and generation of MIS reports. The submission of reports by external auditors

shall be in a particular template. Further, provision to upload reports in PDF/

Word/ Excel format may also be provided.

3. MIS Report : Provision to Track the progress / efficiency / generation of MIS

reports of external audit in terms of status, like cost of the audit, start date /

completion date/ actual completion date, status of compliance, audit

personnel involved etc.

6.2.10 Other Requirements:

6.2.10.1 Risk Classification/ Parameterization of Audits 1. The audit observations in RBIA are classified as “High”, “Medium”, “Low”,

“High Design Gap”, “Medium Design Gap”, “Low Design Gap”, “Affirmation

Positive”. There should be provision to add any new type of risk classification.

2. There should be a provision to view the facts and relevant papers pertaining

to an audit observation by selecting the fact sheet number mentioned in the

audit report displayed on the web page.

3. The AMRMS shall have provision to accommodate more than one Auditee

Office for compliance. As it may happen that audit observations be marked to

one/more auditees (Multiple ROs, CO Department(s)) i.e., in addition to the



auditee, the observation could be marked to one/more CODs for compliance

purpose.

4. RBIA can have multiple chapters in its audit report. There shall be provision

available in AMRMS to update / add additional chapter corresponding to the

identified processes.

6.2.10.2 Document Management The AMRMS application would need to provide all necessary Document

Management functionalities such as version control, auditing, publishing, audit trail of

user activities for each change in the document. The Document Management

solution should provide storing of electronic documents in a central repository

accessible through the Bank’s network. The documents should be available in the

electronic form to the user when accessing their respective account. Necessary

documents should also be linked to different processes. The document management

should in sync with the Bank’s proposed EDMS application.

6.2.10.3 User Management 1. The system is envisaged to have a total user count upto 1000 users at

present.

2. The application should have standard ease of use features for user

management (Availability of features like: Creation/ amendment/ suspension/

deletion of users/rights, password rest/user unlocking etc. features for adding/

amending/ removing items in a menu, Availability of user type-wise menu e.g.

System Administrator, User administration, Central team user, Controllers,

users etc), log definition, review mechanism of logs, access controls on

functionalities based on user (auditor/auditee) on need to know and need to

have basis should be provided.

3. For accessing the application, every user will necessarily have to submit

online application form. This application form will be scrutinized by the

Administrator and based on Internal Policy and requirement, access will be

given. All the fields of the application form should necessarily be validated

before submission; provision to hand errors in efficient manner should be

provided.

4. The system will maintain its own set of users’ authentication database but the

vendor would need to provide functionality for the users to be authenticated



using the single sign-on feature of the Bank. The display of different modules

on the screen should be controlled by user access privilege rights and only

relevant required screen should be displayed.

5. An authorization matrix shall be put in place for providing privileges to the

users by mapping them to specific roles. Roles are broadly classified based

on the modules whereas privileges are what a user could do in each of the

role allotted to the user. Access controls and management, including user

creation with proper grouping and rights and all necessary services for user

management is to be undertaken in coordination with the ID’s officials at the

time of implementation.

6. There shall be provision for Audit Trails, Access Controls, Password controls

and Report Extraction Control etc. in line with IT policy of the Bank. Provision

to get a snapshot / report on the number of active / deactivated users, no of

Administrators / Super Administrators etc. should be provided.

Users: A snap shot of various categories of users in Audit system and their functions in brief

are furnished below.

a) Planning User - Planning functions related to various audit activities, viz;

calendar preparation, allocation of resources, allocation of work areas to

auditors, availability of pre-audit data / information with respect to auditee,

calculation of man-days based on certain pre-determined parameters etc.

b) Auditor – Input of reports / factsheets / observations

c) PIO – view of all reports / status of report of assigned audit team members.

Ability to submit final report. Creation and modification of checklist

d) Follow up - Acceptance and closure of compliances, specific responsibilities

for compliance recording, submission to DGM/PCGM for approval/closure.

Periodical reporting of status of compliances, submission of comments on

periodical status reports received and generation of other MIS. Creation of

reports for ARMS / EDC meetings.

e) Risk Officer – There will be a Risk officer in each department / office who will

be tasked with the monitoring of Risk Register and incident reporting.

f) Concurrent Auditors / Statutory auditors – Internal/ External or a group of

auditors with a team leader – tasks to be performed are import/entry of



records chosen for verification, recording of observations/deviations and other

comments.

g) ABCC Cell: Department / Office nodal centre for compliance, allocation for

compliance and approval return of compliance submitted. Periodical reporting

of status of compliances, submission of comments on periodical status reports

received and generation of other MIS.

h) Other functionaries, with activity specific responsibilities for compliance

recording, and submission to PCGM/ RD for approval/closure.

i) Controlling Office functionaries – MIS on statuses and trends and summaries,

comments/remarks on periodical status reports receipt for return to auditee.

j) RMD Officer – Would View / Update the Risk Registers of all Department /

Offices of the Bank. Further he would have view of all the Incident Reports

and MIS report creation functionality of the same.

6.2.10.4 Backup and Archiving 1. There shall be a provision for taking backups and archive the same of the

systems’ database and the application as well. There should be a provision of

adequate Business Continuity Management (BCM).

2. A methodology for the backing up of data and its archival may be indicated.

3. The Application should have a capability for easy retrieval of the Backed-up

Data (Both Application and the Database) with least amount of manual

intervention with no Data Loss events. The same should be amply

demonstrated.

6.2.10.5 Activity log management 1. There shall be provision for complete audit trail of all operations by the users.

There shall be provision / functionality to track down all backend modifications

as per assigned users roles and responsibilities if any by any user which can

be retrieved and analysed to get the complete history of the issue. The vendor

may take it as an input for redressal of the issue, if the same is application

related.

6.3 Technology Requirements 1. AMRMS shall be preferably based on Open Source Architecture; should be

highly Modular and Parameterisable. The scalability of the system is an

important criteria. Further, it would be advantageous if the proposed system is



platform independent. The bidder should propose the Minimum Bandwidth

required (at server / Client end) to run the application.

2. The BC and DR of the system should be compatible with the current BC & DR

of the Bank.

3. Ability to support and implement session timeout (Internet & Intranet). This

should be configurable and based on the Bank’s IT security requirements.

4. Application should adopt the Limited Data Transfer framework for Data

Transmission in the Web Scenario (Send only required information back and

forth rather than sending the entire webpage)

5. Oracle / Microsoft Enterprise licence is already available with the Bank, and

the same may be used as much as possible. Any other licenses to be

procured by the Bank will have to be specified by the Bidder.

6. The application should preferably be browser and operating system

independent. It should be able to run on any flavour of Windows and on any

browser (Chrome/ IE/ Firefox/ Opera etc.) The bidder should specify clearly if

the application would not run on any specific OS/ Browser.

7. Applications should be free from technology vulnerabilities as per OWASP

(Open Web Application Security Project)

6.4 Security Requirements 1. Effort may be made to make all queries parameterized to minimise error and

for ease of use. Provision should be provided that the entire data should be

encrypted when sending / receiving from the server.

2. A 2 step Identity and Authentication Controls authentication may be put in

place. i.e. application should be accessed via Password and Digital signature.

3. Exception handling should also be available and the system should log each

and every event along with timestamp/ IP address / user-id etc. which can be

used to identify the intruder.

4. The application should have regular security updates wherein data from

previous incidences can be recorded and used to improve the security of the

system.

5. The bidder should carry out a security related assessment and should also

provide a plan for improvement on a continuing basis to account for changes



in technology, the sensitivity of audit information, and internal or external

threats to information security.

6. The system should be capable of sanitizing all inputs before being uploaded

into the application.

7. The system should be in compliance with the IS Policy of the Bank with

respect to Logical Access Control Sub-Policy, Password Sub-Policy, Antivirus

Sub-Policy, Software Security Sub-Policy, Database Security Sub-Policy,

Network Security Sub-Policy, System Administration Sub-Policy, Incident

Reporting and Management Sub-Policy, Audit Sub-Policy etc.

6.5 Other expected requirements 1. Off-line Mode: The AMRMS system should have the functionality to work in

off-line mode with regards to the data entry / report preparation by the auditor

and compliance processing by the auditee office (on a locally downloaded

audit report) with reference to the ID and RMD activities. The bidder should

note that this would be a mandatory criteria at the time of evaluation of the

RFP Bid submission. It should also enable for report generation in an offline

mode based on the data stored locally. The off-line data may then

synchronised with the main server when connected online with due

authentication.

2. User Configurable Dashboard: There should be a Dashboard facility with user

friendly menus as per their roles and privileges. The system should have an

intuitive ‘Search’ functionality. 3. Integration with Existing Systems: AMRMS should be able to interface with

other applications currently running in the Bank like DMIS, CBS, IES etc. and

be able to analyze the exception reports generated by the internal

applications and to integrate the same with AMRMS on pre-defined

parameters.

4. Analytics: The system should also include intelligent and actionable cross

audit analytics by reading data from various audits (CSAA/ Concurrent Audit /

RBIA etc.)/ Incident Reports, exception reports from other applications and

throw up alerts / warning indicators to ID / RMD/ CODs/ ROs/ TEs etc.

5. There shall be provision for standardization of checklist / Risk Registers of

various Offices / Departments doing similar functionality. The system should



be able to analyze the checklist / incident reports / inspection reports / RR

over a period of time / data and be able to throw up areas where similar risks /

procedural errors are happening on an on-going manner.

6. Bi-Lingual: The application should be Bi-lingual (English / Hindi) as far as

possible. Effort should be made to give all headings of the application on the

screen and on the reports in a bi-lingual format (English / Hindi). The system

should also be able to take inputs (Checklists / Audit Findings / RR / Incident

Reports) and give Outputs (Reports/ MIS etc.) in both English and Hindi.

7. Maintenance of Legacy Data: There should be facility to Browse / View /

Download all legacy data prior to January 2013, which are stored in the

database.

8. Library: A Library should be created of all identified processes / reports/

findings / Risks etc, e.g. Audit Report, Checklist, RR, Audit Calendar,

international standards etc. All details regarding data dictionary and validation

tool should be readily made available in the system with due access controls.

System may also include a library of international best practices e.g. ISO

27001, COBIT, ITIL standards etc.

6.6 A few requirements which are not mentioned above, but are associated with the

same, may arise during the implementation period and should be considered within

the scope of the SRS at no extra cost.



7. Scope of Work 7.1 Introduction The ‘AMRMS Project’ means the Project to implement an Audit Management and

Risk Monitoring System along with the integration/ interfacing with Banks other

existing suite of application packages/ existing/ proposed other systems. The term

AMRMS project also includes ongoing administration and maintenance of the

solution by the means of 3 years warranty and 4 years of maintenance post go‐live

of the AMRMS application in the Bank.

AMRMS Project intends to provide a cross functional and seamless integration of

Audit Management and Risk Monitoring operations. AMRMS would be an online web

based application with a centralized database and browser independent (preferably).

AMRMS will have an off-line functioning capability and an automated work‐flow

across all processes covering the entire audit and risk universe of the Bank. The

system should be flexible & configurable to the user requirements dynamically. It

should also enable achieving the objective of paperless office environment.

The description of the envisaged scope is enumerated in a nutshell in the

subsequent sections. However, the Bank reserves its right to change the scope of

the RFP, if required even after the release of the RFP document to incorporate the

same. For broad reference of the expectations from the system, Chapter 6 of this

document may be referred, which explains in broad terms what is expected out of

this project and all major works essential to achieve the objectives.

Based on the contents of the RFP, the Bidder shall be required to propose a

solution, which is suitable for the Bank, after taking into consideration the effort

estimated for implementation of the same and the resource and the equipment

requirements. The Bank expressly stipulates the Bidder’s selection under this RFP is

on the express understanding that this RFP contains only the bold provisions for the

entire assignment and that delivery of the deliverables and the services in

connection therewith are only a part of the assignment. The Bidder shall be required

to undertake to perform all such tasks, render requisite services and make available

all such resources as may be required for the successful completion of the entire

assignment at no additional cost to the Bank notwithstanding what is stated here and

what is not stated but underlying intent.

http://rbidocs.rbi.org.in/rdocs/content/pdfs/TRFPCH130912_A.pdf

http://rbidocs.rbi.org.in/rdocs/content/pdfs/TRFPCH130912_A.pdf



Considering the nature of the assignment and the envisaged relationship with the

Bidder, any service, which forms a part of facilities management that is not explicitly

mentioned in this RFP but is relevant to the mentioned scope of the project, the

Bidder is expected to provide the same at no additional costs to the Bank. The

Bidder has to envisage all necessary services to be provided and ensure the same is

delivered to the Bank. The Bank will not accept any plea of the Bidder at a later date

for omission of critical services on the pretext that the same was not explicitly

mentioned in the RFP.

7.2 Process & System Study The Bidder is expected to study the RFP to gain an understanding of the current and

proposed business processes in the Bank. The Bidder is expected to identify

business process areas where the Bidder may need to obtain further understanding.

The Bidder is expected to identify further process improvement opportunities.

Additional documents required, if not already provided can be shared subject to

confidentiality requirements of the Bank. The details provided in the RFP are a fair

indicator of the requirements of the Bank; however the Bidder is expected to conduct

a comprehensive study of Bank’s operations for capturing the detailed user

requirements to define the System Requirements Specifications (SRS) and Control

Specifications of the proposed AMRMS.

The SRS preparation team of the successful bidder should be experienced, with full functional knowledge of the software. The Bank reserves the right to ask for replacement of any team member if the Bank feels he/ she is not adequately qualified for the same. The SRS Document shall be signed off by the Bank on acceptance of the same.

7.3 Preparation of Control Specification Document The Bidder is expected to create Control Specification documents for audit

management and risk monitoring function under the scope of the AMRMS

implementation including all proposed interfaces and customizations involved. The

Control Specification Document shall be signed off by the Bank on acceptance of the

same.

The Bidder may suggest amendments to the processes that would suit the product

solution offered for a seamless integration and document the same to suit the



proposed AMRMS application as envisaged in the Study Report. However, the

objective and output of the process should not change. On acceptance of the final

solution by the Bank, the Bidder cannot deviate from the agreed solution under any

circumstance unless agreed by the Bank. The agreed solution shall be binding on

the part of the Bidder and inability to deliver the solution may result in annulling the

contract and the same being awarded to another vendor as per the decision of the

Bank. The Bank shall impose financial penalties or / and invoke the performance

bank guarantee in such circumstances.

The Bidder is expected to prepare the Control Specification Document containing the

following details but not limited to:

1. Overview of the Process

2. Process flow diagrams including exceptional situations

3. Functional Description of each step

4. Database Schema for the Module

5. Document Management System and integration with database applications

6. Interaction logic of the modules with other Modules

7. Security features and how the existing Digital Signatures which are

currently being used for access to CHRS and existing Bank’s IT Security

Infrastructure be integrated with AMRMS

8. Configuration of each module / customization including field description

indicating data input format including details of all related parameterization

(standard available or customized)

9. Transaction flow between modules / customizations / interfaces

10. Restrictions to data entry

11. Mandatory fields

12. Optional fields

13. List of reports related directly/ indirectly to module(s)/ customization/

interface

14. Layout of each report and related customizations

15. Description and field description of each report

16. IT Security and Backup Architecture and parameterization with relevant

details

17. Abbreviations and Acronyms



18. Handling of Logs

19. User Manual and on-line tutorial

20. Performance Measurement Matrix

21. AMRMS offline capability

22. IT Hardware infrastructure Details

7.4 Proposed Hardware and Software procurement The Bank expects to host the application on the Banks’ existing hardware

infrastructure. The Bidder is expected to propose the hardware requirement for the

proposed solution. The Bank will scrutinize the same and if necessary will procure

any additional necessary hardware, or install/ implement the same on the existing

available hardware. The existing running applications and the IT software /

hardware infrastructure available in the Banks’ Data Center are mentioned in

Chapter 5.

Procurement of any other software for the purpose of implementation of AMRMS

application would be the sole responsibility of the Bidder and the same should be

factored in while submitting the commercial bid for the application.

7.5 Data Migration Strategy and Data Migration Activity Data migration from the existing system / process will be the responsibility of the

Bidder. The Bidder is expected to migrate the old data since January 2013 till the

time of go-live of the project, including the on-going inspections at that point of time.

However, the data prior to January 2013 are also to be ported on the database for

browsing, downloading the same for MIS purposes. The existing data is primarily in

the form of Excel / Word / PDF form.

Data Migration is broadly divided into following four major sub-components:

• Understanding of the data in the existing applications and development of

suitable tools for data migration.

• Extraction and migration of Data as part of the roll out from existing

solutions to the AMRMS application.

• Archiving of the existing data at the Data Centre, and

• Data migration audit and certification on the accuracy of data porting from

the existing systems to the AMRMS Application.



It is expected that the vendor understand the current system / process design,

database architecture of COMORS and excel / word documents and plan for data

migration into the new system. All necessary tools/ queries required for extraction/

transformation and migration should be provided by the Bidder. It is the Bidder’s

responsibility to ensure accuracy, integrity and completeness of the data migration

from legacy applications to new AMRMS application.

To facilitate understanding of the existing data, Bank shall make available necessary

support (man-power and knowledge of formats). The extraction of data from the

existing system in the required format would be carried out by the bidder. Based on

the study of the existing data, the Bidder has to develop necessary data extraction

tool and provide necessary services for migrating the data.

In case, the data has to be committed through data entry, then the Bidder shall be

fully responsible for data entry and data accuracy. If any outsourcing is resorted to,

previous written permission of the Bank should be obtained before handing over the

work to the outsourced agents. Confidentiality of data should be maintained and the

vendor shall be fully responsible for any act of omission or commission of the agents

who act on behalf of the Bidder.

The Bidder would migrate all necessary data from the existing system / process to

the new AMRMS Application at the time of data migration. The Bidder is expected to

provide an Archival Solution for the historical data. The necessary configuration and

implementation of the archival solution shall be the responsibility of the Bidder.

The Bidder may engage a separate team to decide on data migration strategy and

carry out actual data migration concurrently with other phases of the project. It is also

expected that the user acceptance test is conducted on live data and therefore, for

that purpose live data need to be migrated to the test environment and once

certification for user acceptance is granted, then again live data need to be ported on

to the live system. However, all data should be migrated and audited before the go-

live of the project.

The Bidder shall formulate the detailed Data Migration Strategy and methodology

and submit the same to Bank for its approval before commencement of Data



Migration task. The Bidder should draw a suitable strategy/plan to verify the

accuracy of the data before and after migration.

The Bidder shall provide the required upload formats as per the data structure/

format of the AMRMS application. The Bidder has to inform all the mandatory fields

required for migration and also provide the facility to upload the data with default

value for mandatory fields if the same are not readily available. There should also be

a facility to modify these mandatory fields subsequently by the Bank. In case default

value mapping for any field is to be done, such default values which shall be used

are to be approved by the Bank.

The Bidder shall assist the Bank during the data cleansing and validation exercise of

the data migrated from the legacy systems.

The Bank reserves the right to audit the data migration by external/internal auditors

and any gaps/discrepancies found during the audit are to be rectified by the Bidder.

The Bidder has to conduct mock data migration to confirm the accuracy of the data

migration tool developed.

The Bidder should provide facility for capturing the data through data entry

module/screen, which arises out of the gap between the data available in the legacy

process / system and that required by the proposed system. The data entered

through such screens is to be validated and it is to be uploaded by the Bidders.

The Bidder is required to certify completeness and accuracy of migrated data,

transaction history at each data migration instance.

It is clarified that the ownership of data shall at all times remain with the Bank and

the Bidder shall be responsible to maintain complete confidentiality of the same.

Bidder shall be responsible for all loss, inaccuracies, and discrepancies in data

arising out of data migration at any time during the currency of the project.

7.6 Implementation The Bidder shall suggest solution architecture and rollout sequence with a detailed

rationale for the same, the Bank shall suggest changes to the same to meet desired

milestones.



The Bidder shall give a detailed documentation on the gaps and customization

required – module-wise and how it would be integrated with AMRMS application.

The document should contain both the technical and the functional details along with

the timeline of the customization required.

The Bidder shall ensure that they have the necessary infrastructure and people in

place to resolve all the gaps within the timelines agreed for the implementation and

roll out.

All gaps identified should be resolved by customizing the proposed solution

by way of modifications/ enhancements, as necessary to the Bidder's products with

no extra commercial charge on the Bank.

The Bank may during the process of implementation, identify gaps that may not have

come to light during gap analysis and the Bidder should also undertake modification/

customization of such gaps that may be brought to the notice of Bidder during project

implementation. The Bidder should carry out all such modifications, customization at

no additional cost.

The Bidder should ensure that while applying software patches and in the version

migration, the customized software is also properly migrated to such higher

versions or extended versions. It is the Bidder’s responsibility to ensure that any

customization is compatible with upgraded applications / modules

The Bank will not entertain any change requests / cost escalation from the Bidder for

functionality which as per Bidders response is already present in a standard audit /

risk management application at the time of signing the contract or required by the

Bank as part of the RFP or is typically part of an AMRMS solution.

7.6.2 Interface with existing Applications AMRMS shall have the functionality and capability to process various MIS /

Exception Reports generated from the other existing applications running in the Bank

as per the user’s requirement. It should also generate new reports based on these

data and also enable population of the data input forms by the auditor, if required.

The Bidder shall be responsible for identifying and providing the interface

requirements for the existing as well as proposed software modules, including

present and proposed delivery channels. The Bidder has to assess the interface



requirements and add any further items required for interfaces as per Bank’s existing

IT environment and functional requirements. The bidder would be required to make

available the API (Application Programmable Interface) to interface with any other

applications running in the Bank and API should also be provided in AMRMS so that

other applications running in the Bank may be able to connect to AMRMS with due

authorizations. Primarily, the applications listed in Chapter 5 would need an interface

with the AMRMS Application at present.

While developing the interface, the Bidder should ensure and incorporate all

necessary security and control features within the application, OS, database,

network, etc. so as to maintain integrity and confidentiality of the data in all stages to

the extent applicable to AMRMS. All data communications should be in encrypted

form.

The test environment, which has to be set up within the scope of the project includes

the requirement of the interfaces, customization and data migration testing also and

the Bidder has to provide necessary test cases and tools for testing.

7.6.3 Execution After the successful Test run, the application would ‘Go-live’ from the Data Centers.

The Bidder should customize all the parameters in the application software as

accepted in the test environment. The Bidder shall be responsible for accuracy of the

parameters set according to business needs of the Bank.

Complete Roll-out of the project should be within 4 months from the date of signing

of the Contract.

The roll-out (go-live) shall consist of implementing the AMRMS Application,

including the customizations, interfaces, delivery channels and other solutions

covered within the scope of the project. It also includes relevant training to all users

of the proposed AMRMS, successful migration of data and submission of manuals.

The Bidder for this purpose shall set up the production Server at Data Centre (DC)

and also carry out the migration of data as explained in the document from ID/RMD

to the DC. The Bidder has to undertake all the necessary activities to go-live at ID/

RMD/ CODs / ROs and Data Centres.



The implementation phase shall be deemed as completed in all respects only after

• All the Applications and Services including Training, Documentation and

Interfaces are implemented as per the intent of this RFP;

• Enabling all the functionalities mentioned in Chapter 6 of this RFP, i.e. go live;

• All the related trainings are completed and post training assessment and

rectification of gaps, if any.

The Bidder is expected to state the implementation plan and methodology and

Bank’s team and the vendor shall jointly decide the roll out methodology including

parallel run.

7.6.4 Project Management Deliverables by Bidder The Bidder has to provide the details of the implementation plan, methodology,

process and periodic progress reports. The Bidder will have to provide the following

documents as a part of the Project Management Life Cycle. Each document needs

to be accepted and signed-off by the Bank.

• Project Management Plan

• Gap analysis and Process Improvement Plan

• Schedule Management Plan

• Defined Process Documentation including flowcharts for all processes

followed under

• Facilities Management

• Cost Management Plan

• Change Management Forms – Application & Technical Change Management

• Action Tracker - Problem and Issue Management Tracker

• Archival and Backup Plan

• Resource Calendar

• List of Milestones

• Release Management Plan

• Satisfaction Surveys of users at ID & RMD. These surveys will not be linked to

any penalty clause and shall be used objectively by the Bidder and Bank to

improve services to end users

• Software Development Lifecycle Documents including the following:

o Requirement Traceability Matrices



o Gap Analysis Document

o Business Process Definition Documents

o High and Low Level Design Documents of Customized Modules

o Unit, Integration, System and User Testing Documents with Sign-Offs

o Regression Testing and Action Planning

o User Manuals for standard modules

o Parameterization Manuals for Administrative modules

• Problem and issue redressal management

• Escalation charter

Bank will start its independent UAT only after the first round clearance from the

Bidder. The results thereafter will be jointly analyzed by all concerned parties. Only

after this clearance and acceptance should the Bidder move in for the rollout. The

Bidder should take note that the timelines for implementation should factor in these

as well.

The Bidder is expected to make changes to AMRMS application as required. The

Bidder is expected to make all necessary modifications to the AMRMS

application, customizations, interfaces, delivery channels etc., if there are

performance issues and errors identified during UAT by the Bank.

7.7 Training and Preparation of Training Material The Bidder should provide a minimum of 2 weeks hand holding (on-site) for the roll

out. The Bank expects the Bidder to train the end users till Bank’s personnel gain

sufficient expertise in the system and capable of taking over the training function.

Training should be imparted at various levels depending on the roles and

responsibilities of the users such as core team, inspecting officers, auditors, trainers

etc. The training should cover features, facilities, operations, implementation,

troubleshooting, system administration, database administration etc.

The Bidder would provide training,

a) To users of ID & RMD, and

b) To nodal officers of all CODs, MRO & Belapur

The project implementation team / trained core users of ID/RMD after getting trained

thoroughly would impart training to all the other users at other centers. The Bidder



would be required to provide support to the Banks’ Team for the above mentioned

training, if required.

The bidder would also be called to provide 2 days of training annually post-AMRMS

implementation to the core-users.

All travel related expenses incurred would be borne by the Vendor.

The software should also have a built-in help module along with on-line tutorial and

e-learning module with regards to all the functionalities of AMRMS.

7.8 System Integration Testing (SIT) and Users Acceptance Testing (UAT) The Bidder should carry out a thorough System Integration Testing (SIT). SIT will be

followed by User Acceptance Testing (UAT), plan for which has to be submitted by

the Bidder to the Bank. The UAT includes Functional tests, Resilience tests,

Benchmark Comparisons, Operational tests, Load tests etc. Banks staff/ third Party

Vendor designated by the Bank will carry out the UAT. The RBI UAT Team will need

necessary on-site training for the purpose and the same should be provided by the

Bidder. Bidder should submit result log of all tests to the Bank.

The Bidder shall fix the Bugs and carry out the necessary rectifications wherever

necessary and deliver patches/version towards changes effected within the agreed

time frame depending on the severity of the bug. On satisfactory completion of the

aforementioned tests, the User Acceptance Test (UAT) letter will be issued to the

vendor by the Bank.

The Bank shall accept the application software only after the critical or major bugs

are fixed. The Bank shall not be obliged to make partial acceptance or accept the

solution unless the solution meets the specifications and the team composition is as

per agreed service levels.

7.9 Post Implementation The post implementation period will start after 90 days of successful “Go-Live” of the

project, i.e. after issue of Completion Certificate by the Bank.

7.9.1 Warranty It would be mandatory on the Bidder to provide a Warranty for 3 years for the

product. The Warranty period of three (3) years would commence from the date of



issue of Completion Certificate by the Bank. During the Warranty period the Bidder

would be required to undertake all necessary modifications not falling under the

purview of ‘Change Management’ such as updates, bug fixes, changes in the

application or any other support as and when required at no extra cost.

During the first year of warranty, the Bidder will be required to provide on-site

support, extendable at the Bank’s discretion. It is envisaged at this stage that the

next two years of warranty would be on off-site support basis. Any major changes in

the application which will fall under the ‘Change Management’, the vendor will be

paid separately.

7.9.2 AMC

The Bank will enter an AMC agreement with the vendor for 4 years after the expiry of

3 years of warranty. The support extended during the Warranty Period as mentioned

in Chapter 7.9.1 would also be applicable during the AMC period on an off-site basis.

Any major changes in the application which will fall under the ‘Change Management’,

the vendor will be paid separately.

During each year of the AMC, the Bank reserves the right to use 30 man days’ worth

of effort for changes, development or customizations, any other support etc. The cost

of these additional 30 man days should be part of the commercial bid submitted to

the Bank, as a part of the AMC charges. No extra charge will be paid in this regard.

Till the end of the AMC period, if the total change request and onsite support for

Application maintenance requires work of less than 30 man days each year

respectively, no payment would be made in this regard. Any effort over and above

this would only be paid. Any part of the 30 man days effort left over in any year will

be carried over to the subsequent year and so on till the end of AMC period.

Any additional charges beyond the above prescribed period of 30 man days per

year, would be paid as per the rate mentioned by the bidder while submitting the

commercial bid / the negotiated price by the Bank in this regard. The change

management charges as mentioned by the vendor in the commercial bid annexure

will not be a part for commercial bid evaluation.



7.9.3 Change Management Post-Implementation, any request by the Bank that results in changes in the

structure of the application and / or a new module is added and which requires

considerable effort for customization would be considered as part of Change

Management. Any minor changes required in the application such as addition /

deletion / alteration of a row / column / field, additional report, menu items will not be

considered as part of Change Management. The vendor should maintain records of

all such changes made in the application with a proper audit trail and time-stamp.

There should be an appropriate roll back mechanism which is identified and tested if

changes are not successful.

Any standard functionality available in the proposed AMRMS would not form part of

the Change Request submitted by the Bidder. Bidder should provide and implement

any security patches/ upgrades/ updates for Software/ OS/ Middleware etc. as and

when release by the Vendor/ OEM or as per requirements of the Bank and the same

shall not be included as a part of change management. Bidder should bring to notice

of the Bank all release /version change. Bidder should obtain a written permission

from the Bank before applying any of the patches/ upgrades/ updates.

The Bidder is required to develop a change management methodology to

ensure all application changes and technical changes (after go-live, and in the case

of network changes, from the start of contract), are reviewed, tested, approved,

implemented, and verified post implementation.

All change requests should be documented and should have a numerically assigned

number in sequential order. A database of all change requests should be

maintained, and the Bidder should deploy an automated change management

application. All change requests should be classified, and approval and escalation

mechanisms should be defined as per classification.

The change request should include an appropriate roll back mechanism which is

identified and tested if changes are not successful. The Bank would initiate or invoke

penalty clause in case of repeated roll-back of change request (more than 2 roll

backs).



Changes should be implemented in a controlled manner, and should be tested in the

test (non-production) environment prior to implementation. The impact of technical

changes on application environment should also be performed. Dependencies of

changes should be documented.

All changes should be reviewed and the databases of changes should be reviewed

for any actions taken post implementation. Emergency change requests should

follow a defined and controlled process.

A release schedule should be maintained for all changes, so as to provide minimum

disruption to business services. The Bidder will be required to perform analysis of

change requests to review frequently occurring issues, trend analysis, and an

analysis report to be provided to the Bank along with a summary report.

The Bidder should quote the unit costs (man day charges) for affecting the Change

Management Requests as per Annex 14. During the second year onwards of the

support period, the changes in the quoted rate would be calculated as per the

indexation formula given in Chapter 9.3 and the same would be valid for the entire

period of support (3 years of Warranty and 4 years of AMC).

7.10 Phase-wise Deliverables It is expected that the entire implementation of AMRMS will be completed within 4

months of time from the signing of contract. The list of deliverables at various stages

of implementation is as mentioned below in table 5 Table 5: Milestone / Deliverable Time Schedule 1. Signing of Agreement Within 15 calendar days of

receiving the letter of offer from 2. Study of Processes/ Systems, Preparation of

SRS/ Control Specification Document, Process Re-engineering Report (BPR) and Finalization and signing off all the above.

Within 30 days from calendar date of Signing of the Agreement

Deployment 3. Customization / Development of AMRMS

Within 60 days from calendar date of Signing off of the SRS

4. - Setting up of Test Environment - Data Migration - SIT & UAT

Within 10 calendar days from Customization / Development of AMRMS



5. Other Deliverables - Training of all Users (i.e. ID, RMD, Auditee

Units) - On-line / e-learning training Modules - User Manuals & Operation Manuals - Any other Documentations

Within 10 calendar days from date of UAT

6. Complete implementation of the project i.e. Go-Live

Within 20 calendar days of UAT of all functionalities

Post Implementation

7. Receipt of Certificate of Completion from the Bank Within 90 calendar days after successful “Go-Live” of the project

8. – Warranty (3 Years) and AMC (4 Years) - Change Management on need basis, if required.

On-going for 7 Years

7.11 Security The Bank would reserve the right to conduct a Vulnerability Assessment and

Penetration Testing (VA-PT) of the application post implementation by hiring external

experts. Any security issues thrown up by the audit would need to be fixed by the

Bidder at his own cost.

The bidder would be required to provide a self-certification letter regarding source-

code audit of the Application by specific tool (prescribed by the Bank) to address

security concerns.



8 Responsibility of Bidder

The main responsibly of the bidder would be as under:

1. Receipt of Letter of Intent

2. Study of Business Requirements

3. Gap Analysis

4. Contract development and signing

5. Application specific Business Process Re‐engineering report, Blueprint/

Software Requirement Specification document, Segregation of Duties,

Authorization Matrix, Change document etc.

6. Data Migration tools development

7. Implementation at Data Centres

8. Installation of OS / RDBMS / Application software

9. Customisation

10. Interface development

11. Implementation of Security Policies

12. Testing

13. Core Team Training

14. End User Training

15. Roll out

16. Data Cleansing

17. Feedback / Simultaneous fine tuning

18. End User Manual / Online tutorial

The above list is not exhaustive and only indicative in nature.

Bidder’s deliverable should encompass the off-the-shelf product, any 3rd party

applications, interfaces, customizations required for the successful completion of the

project.

It is the Bidder’s responsibility to co-ordinate with all vendors including Bank’s

vendors for the successful completion of the implementation, i.e., Go-live, and

subsequently the maintenance period of the project.



8.1 Partnering with the OEM

It will be the sole responsibility of the Bidder to get the proposed technical solution

vetted by the OEM as part of the response, if he is not the OEM; and submit a copy

of the same to the Bank confirming their partnership regarding the implementation of

the AMRMS project. However, the Bidder only should collaborate with the OEM at all

stages of AMRMS implementation to the satisfaction of the Bank. The Bidder needs

to adhere to the project timelines at all costs irrespective of any constraint being

faced by the OEM. The bidder will only be responsible for any loss, damage, late-

payment, penalty arising out of non-fulfillment of obligations by OEM.



9. Payment Terms & Milestones

The commercial Bid will include all the costs related to the development,

implementation and maintenance of the application, excluding the hardware cost on

which the application will be hosted. Details of this are as under:

9.1 Application Cost

Bidder will provide the application cost as per the Annexure 14. The commercial

evaluation of the application cost shall be on the Total Cost of Ownership (TCO).

TCO will be split into two parts:-

a) Project Cost

Project cost would include all costs related to the implementation of AMRMS i.e.

initial cost/ onetime cost/ License fees/ development Cost/ installation cost/

commissioning cost/ integration cost with existing systems/ customization cost/

training cost/ technical assistance excluding Hardware infrastructure cost.

b) Application Support Cost

Bidder would be required to specify the cost of 3 years of Warranty period and 4

years of Annual Maintenance Contract (AMC) after the expiry of the Warranty.

The split up of the same would be required to be submitted.

The First year of Warranty would be on-site basis while the second and third

year would be on off-site basis. Cost of both on-site warranty and off-site

warranty on per year basis would need to be specified by the bidder.

The AMC will be on off-site support basis generally and the vendor is expected

to resolve the issue, if any on call basis urgently. Cost for 4 years of Annual

Maintenance Contract (AMC), inter alia would also have to be mentioned

separately on per year basis which includes among other support, 30 man-days

of (i) support for Application maintenance or (ii) Change Management requests

on a need basis.

For calculation of TCO, the cost Warranty support will be for 1 year onsite

support and 2 years of off-site support; and the cost of 4 years of AMC would be

calculated by multiplying the number of years (4) to the rate quoted by the bidder

as in Annex 14. However, it is informed that the actual payment to the bidder will



be calculated as during the Warranty and AMC period would be made as per the

indexation method as mentioned in Chapter 9.3.

The bidder should indicate the rate in INR charged for Change management

requests separately in the Annex 14, however the same would not be considered for

commercial bid evaluation.

9.2 Hardware Costs (DC & DRC for AMRMS & Other Third Party Applications)

The Bank expects to host the application on the Banks existing hardware

infrastructure. The Bidder is expected to propose the required hardware at the data

center, near site disaster recovery center and far site disaster recovery center, for

the deployment of the entire AMRMS application proposed including third party

applications. The Bank will scrutinize the same and if necessary will procure any

additional necessary hardware, or install/ implement the same on the existing

available hardware. The bidder is expected to study & examine the existing

hardware available at RBI as mentioned in Chapter 5 in this regard.

9.3 Payment terms

Payment will be made in 7 phases as specified below subject to completion of the

conditions and presentation of the bill:- Table 6: Sr. No

Milestone Payment

1. Finalization and signing off of SRS 15% of the Project Cost

2. Successful Data Migration, 15% of the Project Cost

3. Successful UAT and pilot implementation 10% of the Project Cost

4. Signing off of other deliverables like training, on-

line tutorials, documentations, manuals etc.

20% of the Project Cost

5. Complete Implementation and “Go-live” of the

project

15% of the Project Cost

6. Receipt of Certificate of Completion from the Bank 15% of the Project Cost

7. On submission of Performance Bank Guarantee 10% of the Project Cost

(to be paid only after

issue of successful

Completion Certificate



from the Bank)

The performance Bank Guarantee submitted shall be valid till the end of the

Contract.

The payment during the 3rd year of Warranty and 2nd year onwards of AMC period

would be made as per the indexation method as mentioned below:

A = B {15 + 45 x (WPIc / WPIp) + 40 (CPIc / CPIp)} * 1/100 Where

• A = The contract amount for the current year, • B = The contract amount for the previous year, • WPIc=Whole Sale price Index for the months generally based on index 6

months prior to the Commencement date of contact for the current year, • WPIp= Whole Sale price Index for the months generally based on index 6

months prior to the Commencement date of contact for the previous year, • CPIc= Consumer Price Index ( Urban – All groups, All India ) for the months

generally based on index 6 months prior to the Commencement date of contact for the current year and

• CPIp= Consumer Price Index ( Urban – All groups, All India ) for the months generally based on index 6 months prior to the Commencement date of contact for the current year.

9.4 Other Payment Terms

The Bidder recognizes that all payments to the Bidder under this RFP and

subsequent agreement are linked to and dependent on successful implementation

and acceptance of all milestones/ deliverables/ activities set out in the Project Plan

and therefore any delay in achievement of such milestones/ deliverables/ activities

shall automatically result in delay of payment.

Bidders have to provide a comprehensive price for the implementation of the

project. TCO will be calculated as the summation of the grand total of all the items

of the Price Bid as mentioned in the Annex 14.

All the payments becoming due during each year of the contract period (Warranty

/ AMC) will be paid within one (1) month of presentation of invoice for the completed

year.

Any objection/ dispute to the amounts invoiced in the bill shall be raised by the

Bank within reasonable time from the date of receipt of the invoice. Upon

settlement of disputes with respect to any disputed invoice(s), the Bank will make

payment within thirty (30) working days of the settlement of such disputes. All out

of pocket expenses, travelling, boarding and lodging expenses for the entire project



period and subsequent agreement should be included in the bid amount and the

Bidder shall not be entitled to charge any additional costs on account of any items

or services or by way of any out of pocket expenses, including travel, boarding and

lodging etc.

The prices quoted will also include transportation to respective sites. The price

payable to the Bidder shall be inclusive of carrying out any modifications/

changes/ upgrades to the AMRMS or other application software or equipment

that is required to be made in order to comply with any statutory or regulatory

requirements or any industry‐wide changes arising during the subsistence of the

implementation of the Project, and the Bank shall not pay any additional cost for the

same. Bidder needs to provide the details about all such items considered in the

RFP.

The prices quoted by the Bidder fees shall be inclusive of all costs such as

insurance, taxes (including service tax, as per the rates applicable), custom duties,

octroi, levies, cess, transportation, installation, (collectively referred to as “Taxes”)

that may be levied, imposed, charged or incurred and the Bank shall pay the fees

due under this RFP and subsequent agreement after deducting any tax deductible

at source (“TDS”) or any other cess/taxes, as applicable at the time of payment of

invoices. The Bidder will need to provide the details for the tax rates as considered

in the pricing. This will be used for subsequent tax changes. RBI shall pay each

undisputed invoice raised in accordance with this RFP and subsequent

agreement, within thirty (30) working days after its receipt unless otherwise

mutually agreed in writing, provided that such invoice is dated after such Fees have

become due and payable under this RFP and subsequent agreement, if any. Any

variation in Government levies/ taxes/ VAT/ cess/ excise/ custom duty /Octroi etc.

which has been included as part of the price will be borne by the Bidder. The

Bidder should not make any conditional or vague offers which are not in conformity

with the guidelines given in the RFP.

If any Tax authorities of any state, including, Local authorities like Corporation,

Municipality, Mandal Panchayat, etc. or any Central Government authority or

Statutory or autonomous or such other authority imposes any tax, penalty or levy or

any cess/ charge other than entry tax or octroi and if the Bank has to pay the same

for any of the items or supplies made in terms hereof by the Bidder, for any reason

including the delay or failure or inability of the Bidder to make payment for the same,



the Bank has to be reimbursed such amounts paid, on being intimated to the Bidder

along with the documentary evidence. If the Bidder fails to reimburse the amount

within a fortnight, the Bank shall adjust the amount out of the payments due to the

Bidder (Project Cost/ AMC/ BG) from the Bank along with the 12% (twelve per cent)

interest annually recoverable quarterly.

The penalty for delay / non-performance of service as mentioned in Chapter 10

during the Warranty / AMC period shall be deducted from the next payout.

Terms of payment indicated in the Contract that will be issued by the Bank to the

selected Bidder will be final and binding on the Bidder and no interest will be

payable by the Bank on outstanding amounts under any circumstances. If there are

any clauses in the Invoice contrary to the terms of the Contract, the Bidder should

give a declaration on the face of the Invoice or by a separate letter explicitly stating

as follows “Clauses, if any contained in the Invoice which are contrary to the terms

contained in the Contract will not hold good against the Bank and that the Invoice

would be governed by the terms contained in the Contract concluded between the

Bank and the Bidder”. Bidder should ensure that the project should not suffer for this

reason.

The Bidders should note that the contract entered with the successful Bidder

will be for implementation and post go‐live period of 7 years, extendable at the

Bank’s discretion. However, the Bank will have the right, in its sole discretion to

renegotiate the prices/ terms and conditions at the end of the contract period.



10. Service Level Agreement (SLA) & Contracting The Bidder shall be bound by the Service Levels described in this document for the

proposed AMRMS Application.

10.1 Terminologies Used

Service Levels are calculated based on the “Business Utility” of the solution, which

is described as the ratio of “System Available for Actual Business Hours” to the

“Scheduled System Availability for Business”

{Scheduled Business Operation Hours (SBOH) – Business Downtime (SBDT)}/

Scheduled Business Operation Hours (SBOH)

SBOH ‐ SBDT BU (%) = ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ * 100

SBOh The “Scheduled Business Operation Hours” for a given time frame are

calculated after deducting the planned downtime which can be taken on the

system only with prior notice to the Bank and with mutual consent of the Bank and

the Bidder.

“Business Downtime (BDT)” is the actual duration for which the system was not able

to service the Bank, due to System or Infrastructure failure as defined by the Bank

and agreed by the Bidder. The "Business Downtime" would be calculated on daily

basis and for all performance appraisals, the daily downtime would form part of

core measurement for assessment/escalation/penalty, etc.

The “Working Hours” for all the Offices are from 9:00 AM to 6:30 PM.

“Business Operation Hours” for Data Centre and Disaster Recovery Centre would be

24x7x365.

Bank requires that all operations at the Data Centre and the Disaster Recovery

Centre related to the proposed solution are supported 24 x 7 x 365 during the

warranty and AMC period.

10.2 Purpose and Objectives of SLA Bank intends to enter into a Service Levels Agreement (SLA) with the successful

Bidder in order to provide complete utility of the service that could be provided to



Bank once the “AMRMS Application” is live.

The SLA shall be included in the contract agreement which would cater to fullfilling

the expectations of Bank and defines the Scope and Boundaries for the

successful Bidder to provide maximum “Business Utility”.

Any application related issue could be classified under the following two categories:

• Level 1: The identified issue has a significant business impact.

• Level 2: The identified issue has minimal impact on the Business.

The Bank will have the sole right to decide on the level of classification of any

identified issue.

Any other software related issues like O/S, Server etc. may be attended

immediately. It is expected that the Bidder provides an immediate

solution/work around for Level 1 category issues so that Bank can continue to

function normally and then resolve the issue on priority by conducting a “Root

Cause Analysis”.

10.3 Scope of Services It is expected that after successful login all the respective modules of the application

should be made available to the users within a response time of 2-3 sec, assuming

the other related conditions being normal. The Bidder would be in total charge of the following:

• Complete Systems Software and Environments required for the AMRMS implementation

• Implementation Services for AMRMS (includes Integration, Interfaces) • AMC • Helpdesk Training and facilities management

The Bidder is expected to take care of the systems by covering them under the

Warranty, AMC contract. Table 6A:

Criticality Time to Recovery (TTR) Level 1 Full Functionality shall be restored

within 12 hours Level 2 Full Functionality shall be restored

within 24 hours Any failure in the primary DC should result in automatic switch over to the DR. The

time taken to switch over to DR sites due to complete failure of the DC shall not be

considered for TTR computation.



TTR shall be computed as total downtime per month. The TTR values given in the

above table therefore, define the maximum acceptable downtime in the specified

time and conditions.

A failure that does not result into a level 1 or level 2 incident, is still required to be

resolved by the Bidder in maximum 2 working days.

Service Degradation is a scenario where the service quality degrades for a

continual period by more than 20% of expectation at any point (measured in terms

of response time).

10.4 Performance Tracking and Reporting The Bank requires the Bidder to provide reports on “Business Downtime” and a

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

The frequency of the report would be Monthly, Quarterly and Yearly. If no issues, a

nil statement may be provided.

The solution related minimum service expectation as a percentage of

“Business Utility” is of 99.99% to be calculated on monthly basis.

10.5 Problem Management and Escalation Procedures The Bidder is expected to provide an interface for logging issues. It should have an

audit trail and updating functionalities and preferably have a role based access for

the users. Bank should be able to retrieve the details of any issue logged and get

the complete history of the issue including the enterer, date of entry, date and

details of the solution, re‐opened date with remarks, etc.

10.6 Penalties Business Utility and Business Downtime would be the key considerations for

determining the “Penalties” that would be levied on the Bidder for “Non‐Adherence” to

the SLA for the Services offered.

The inability of the Bidder to provide the requirements as per the scope or to meet

the deadlines as specified would be treated as breach of contract and invoke the

Penalty Clause.

The maximum limit on the penalties during the period of contract shall be 10% of the

total contract value.

The applicable “Penalties” would be the same irrespective of the root causes.



Table 7: Penalties Criticality Elapsed Time of unavailability for end users

Level 1 (INR)

Level 2 (INR)

Up to 12 hours 1.25 times man hour/day rate charged for change management by the bidder.

Up to 24 hours 1.5 times man hour/day rate charged for change management by the bidder.

1.25 times man hour/day rate charged for change management by the bidder.

Greater than 24 hours 1.75 times man hour/day rate charged for change management by the bidder.

1.5 times man hour/day rate charged for change management by the bidder.

The Payouts shall be on an annual basis and penalty shall be deducted from the

next payout (Warranty / AMC / BG).

10.7 Penalties for Delayed Implementation The successful Bidder is expected to complete the responsibilities that have been

assigned as per the specified time frame.

In case of the Rollout delays by the Bidder, the Bank can exercise its choice in

imposing financial penalty on the Bidder at 0.25% of the total contract value per

week of delay. The Bank may reserve the right to terminate the contract with/ without

any prior notice if there is a delay greater than 4 weeks as per the schedule given in

the milestones given in Chapter 7.10.



11 Overall Liability of the Bidder

11.1 Broad Terms and Conditions

The following are the general terms and conditions proposed to be included in the

Contract. The Bank reserves the right to add, delete, modify or alter all or any of

these terms and conditions in any manner, as deemed necessary before signing the

final agreement.

The Bidder, selected for the AMRMS project, will have to enter into a contract

agreement directly with the Bank. The contract agreement will contain various terms

and conditions relating to payment, delivery, installation & operationalisation,

training, commissioning & acceptance, support during periods of warranty &

maintenance, penalty due to delay in performance etc. All the diagrams, drawings,

specifications and other related literature & information, provided by the Bidder for

the solution and agreed to by the Bank, will also form a part of the agreement.

The successful Bidder should initiate work on the project within one week of signing

of the contract.

The successful Bidder at his own expense will register the contract agreement by

paying the appropriate amount of stamp duty. The first page of the contract

agreement shall be on a stamp paper of appropriate value. The stamp duty and

contract agreement will be based out of Mumbai jurisdiction only.

The bill for the services rendered should be furnished along with the prices thereof,

as per the terms and conditions contained in this document. The successful Bidder

will ensure that the prices quoted are reasonable and in the range of prices for

similar / same services available in the market.

Payment shall be made on the actual procurement and implementation of AMRMS

as per Payment terms and conditions as per Chapter 9.3

11.2 Application For the purpose of the Purchase Agreement as well as for the purpose of the Tender

Document, the Purchaser is:



Principal Chief General Manager Inspection Department Reserve Bank of India C-7, 8th Floor, BKC, Bandra (East) Mumbai –Maharashtra, India

11.3 Standards The services and other materials including all deliverables and reports under the

contract shall conform to the standards / best practices as mentioned in this RFP

document as well as the Technical Bid submitted by the Bidder and/or agreed

between the Bank and the Bidder, and when no applicable standard is mentioned,

the services/products/deliverables shall be supplied under the authoritative and

appropriate international standards of the such services/products/deliverables and

such standards shall be the latest issued by the concerned institution/s.

AMRMS Application should conform to the international best practices and

standards, e.g. ISO 27001, COBIT, ITIL standards etc.

11.4 Governing Language All correspondences and other documents pertaining to the contract shall be in

English and or Hindi.

11.5 Applicable Law The Contract shall be governed and interpreted in accordance with the Indian Laws.

11.6 Notices Any notice given by one party to the other pursuant to the contract shall be sent to

the other party (as per the address mentioned in the contract) in writing either by

hand delivery or by registered post or by courier and shall be deemed to be complete

only on obtaining acknowledgement thereof; or by facsimile or by other electronic

media and in which case, the notice will be complete only on confirmation of receipt

by the receiver.

A notice shall be effective when delivered or on the notice’s effective date,

whichever is later.



11.7 Right to alter the Requirements

The Bank reserves the right to alter the requirements specified in the RFP

Document. The Bank reserves the right to delete one or more items from the list of

items specified in the Tender. The Bank will inform all Bidders about changes, if any.

The Bidder agrees that the Bank has no limit on the additions or deletions on the

items for the period of the contract. Further, the Bidder agrees that the price quoted

by the Bidder would be proportionately adjusted with such additions or deletions of

requirements.

11.8 Contract Amendments Any change made in any clause of the contract which shall modify the purview of the

contract within the validity and currency of the contract shall be deemed as an

Amendment. Such an amendment can and will be made and be deemed legal only

when the parties to the contract provide their written consent about the amendment,

subsequent to which the amendment is duly signed by the parties and shall be

construed as a part of the contract. The details of the procedure for amendment shall

be as specified in the contract.

11.9 Use of Contract Documents and Information The successful Bidder shall not, without the Bank’s prior written consent, disclose

the Contract or any provision thereof, or any specification or information furnished by

or on behalf of the Bank in connection therewith, to any person other than a person

employed by the Successful Bidder in the performance of the Contract. Disclosure to

any such employed person shall be made in confidence against Non-disclosure

agreements completed prior to disclosure and disclosure shall extend only so far, as

may be necessary for the purposes of such performance.

Any document, other than the Contract itself, shall remain the property of the Bank

and all copies thereof shall be returned to the Bank on termination of the Contract.

The successful Bidder shall not, without the Bank’s prior written consent, make use

of any document or information above except for the purposes of performing the

Contract.



11.10 Escrow Intellectual property rights for all modules/ product developed especially for the Bank

and integrated in the Bank’s AMRMS will rest solely with the Bank. However, in the

case of the AMRMS being a customized product and difficult to concede the IP rights

by the bidder, Escrow arrangement should be made to deposit the source code of

the proposed solution. A certificate in the format as per Annex 11 should be

submitted along with the RFP documents.

The successful bidder shall, within 30 Business Days from the receipt of completion

certificate from the Bank, deposit the Software in human readable form and such

other material, instructions and documentation (including updates and upgrades

thereto and new versions thereof) as are necessary to compile or otherwise generate

the then current version of the Software supplied to the Bank in escrow with a

suitable escrow agent jointly appointed by the Bidder and the Bank. All costs

incurred in connection with the escrow shall be borne by the Bank, other than the

travelling and other expense of Bidders Personnel.

11.11 Indemnification

The successful Bidder shall, at its own cost and expenses, defend and indemnify the

Bank against all third-party claims including those of the infringement of Intellectual

Property Rights, including patent, trademark, copyright, trade secret or industrial

design rights, arising from use of the Products or any part thereof in India or outside

India.

The successful Bidder shall expeditiously meet any such claims and shall have full

rights to defend itself therefrom. If the Bank is required to pay compensation to a

third party resulting from such infringement, the Successful Bidder shall be fully

responsible therefor, including all expenses and court and legal fees.

The Bank will give notice to the successful Bidder of any such claim and shall

provide reasonable assistance to the Successful Bidder in disposing of the claim.

The successful Bidder shall also be liable to indemnify the Bank, at its own cost and

expenses, against all losses/damages, which the Bank may suffer on account of

violation by the Successful Bidder of any or all national/international trade laws,

norms, standards, procedures, etc.



11.12 Cancellation of Contract and Compensation The Bank reserves the right to cancel the contract of the selected Bidder and recover

expenditure incurred by the Bank on the following circumstances:

• The selected Bidder commits a breach of any of the terms and conditions

of the bid/contract.

• The Bidder goes into liquidation voluntarily or otherwise.

• An attachment is levied or continues to be levied for a period of 7 days

upon effects of the bid.

• The progress regarding execution of the contract, made by the selected

Bidder is found to be unsatisfactory.

• If deductions on account of liquidated Damages exceeds more than 10%

of the total contract price.

After the award of the contract, if the selected Bidder does not perform satisfactorily

or delays execution of the contract, the Bank reserves the right to get the balance

contract executed by another party of its choice by giving one months notice for the

same. In this event, the selected Bidder is bound to make good the additional

expenditure, which the Bank may have to incur to carry out bidding process for the

execution of the balance of the contract. This clause is applicable, if for any reason,

the contract is cancelled.

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/or invoking Bank Guarantee, if any, under this contract or any other

contract/order. Work, Study Reports, documents, etc. prepared under this contract

will become the property of the Bank.

11.13 Earnest Money Deposit Bidder will submit demand draft/banker’s cheque/pay order drawn in favour of

“Reserve Bank of India” payable at Mumbai towards Earnest Money Deposit (EMD) for Rs. 2,50,000/ (Rupees Two Lakh Fifty Thousand) along with the submission of

the RFP document.

The EMD of unsuccessful Bidders shall be returned within 30 days from the

declaration of the disqualification of the respective Bidder. The EMD of the



successful Bidder shall be returned after the successful Bidder furnishes the

Performance Bank Guarantee.

Offers made without the Earnest money deposit will be rejected.

The amount of Earnest money deposit would be forfeited in the following scenarios:

• In case the Bidder withdraws the bid prior to validity period of the bid for

any reason whatsoever;

• In case the successful Bidder fails to accept and sign the contract as

specified in this document for any reason whatsoever; or

• In case the successful Bidder fails to provide the performance bank

guarantee within 30 working days from the date of placing the order by the

Bank or signing of the contract, whichever is earlier, for any reason

whatsoever.

11.14 Performance Bank Guarantee The successful Bidder shall at his own expense deposit with the

Principal Chief General Manager

Inspection Department


C7, 8th Floor,

BKC, Bandra (East)

Mumbai Maharashtra, India

within thirty (30) working days of the date of notice of award of the tender, a

Performance Bank Guarantee from a scheduled commercial bank, payable on

demand in terms of Annex 2, for an amount equivalent to ten percent (10%) of the

contract price (TCO) for the due performance and fulfilment of the contract by the

Bidder.

Without prejudice to the other rights of the Purchaser under the Contract in the

matter, the proceeds of the performance bank 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 Bank shall notify the Bidder in writing of the

invocation of its right to receive such compensation, indicating the contractual

obligation(s) for which the Bidder is in default.



The Performance Bank Guarantee may be discharged upon being satisfied that

there has been due performance of the obligations of the Bidder under the contract.

The Performance Bank Guarantee shall be valid till the end of the contract.

Failure of the successful Bidder to comply with the above requirement, or failure of

the Bidder to enter into a contract within 15 working days from the formal intimation

of issuing the letter of intent or within such extended period, as may be specified by

the Principal Chief General Manager, Inspection Department, Reserve Bank of India,

shall constitute sufficient grounds, among others, if any, for the annulment of the

award of the tender.

11.15 Resolution of Disputes The bids and any contract resulting therefrom shall be governed by and construed

according to the Indian Laws.

All dispute or differences whatsoever arising between the selected Bidder and the

Bank out of or in relation to the construction, meaning and operation or effect of the

Contract, with the selected Bidder, or breach thereof shall be settled amicably. If,

however, the parties are not able to resolve any dispute or difference

aforementioned amicably, after issuance of 30 days’ notice in writing to the other,

clearly mentioning the nature of the dispute / differences, to a single arbitrator,

acceptable to both the parties, for initiation of arbitration proceedings and settlement

of the dispute/s and difference/ strictly under the terms and conditions of the

purchase contract, executed between THE BANK and the Bidder. In case, the

decision of the sole arbitrator is not acceptable to either party, the disputes /

differences shall be referred to joint arbitrators, one arbitrator to be nominated by

each party and the arbitrators shall also appoint a presiding arbitrator before the

commencement of the arbitration proceedings. The arbitration shall be governed by

the provisions of the Rules of Arbitration of the Indian Council of Arbitration under the

exclusive jurisdiction of the courts at Mumbai, India.

The award shall be final and binding on both the parties and shall apply to the

purchase contract.

Work under the Contract shall be continued by the selected Bidder during the

arbitration proceedings unless otherwise directed in writing by the Bank or unless the

matter is such that the work cannot possibly be continued until the decision of the



arbitrator, as the case may be, is obtained and save as those which are otherwise

explicitly provided in the Contract, 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 matters thereof.

The venue of the arbitration shall be at Mumbai, INDIA under the exclusive

jurisdiction of the courts at Mumbai, India.

11.16 Delays in the Bidder’s Performance The Bidder should strictly adhere to the implementation schedule, as specified in the

purchase contract, executed between the Parties for performance of the obligations,

arising out of the purchase contract and any delay in completion of the obligations by

the Bidder will enable the Bank to resort to any or both of the following:

• Claiming Liquidated Damages • Termination of the purchase agreement fully or partly and claim liquidated

damages.

11.17 Liquidated Damages The liquidated damages is an estimate of the loss or damage that the Bank may

have suffered due to delay in performance or non-performance of any or all the

obligations (under the terms and conditions of the purchase contract relating to

supply, delivery, installation, operationalisation, implementation, training,

support/services, acceptance, etc.), of the solution by the Bidder and the Bidder shall

be liable to pay the Bank a fixed amount for each day of delay / non-performance of

the obligations by way of liquidated damages, details of which will be specified in the

purchase contract. Without any prejudice to Bank’s other rights under the law, the

Bank shall recover the liquidated damages, if any, accruing to the Bank, as above,

from any amount payable to the Bidder either as per the purchase contract, executed

between the parties or under any other purchase agreement/ contract, the Bank may

have executed / shall be executing with the Bidder.

Liquidated Damages is not applicable for reasons attributable to the Bank and Force

Majeure. However, it is the responsibility/onus of the Bidder to prove that the delay is

attributed to the Bank and Force Majeure. The Bidder shall submit the proof

authenticated by the Bidder and bank’s official that the delay is attributed to the Bank

and Force Majeure along with the bills requesting payment.



11.18 Force Majeure

The Bidder or the Bank shall not be responsible for delays or non-performance of

any or all contractual obligations, caused by war, revolution, insurrection, civil

commotion, riots, mobilizations, strikes, blockade, acts of God, Plague or other

epidemics, fire, flood, obstructions of navigation by ice of Port of dispatch, acts of

government or public enemy or any other event beyond the control of either party,

which directly, materially and adversely affect the performance of any or all such

contractual obligations.

If a Force Majeure situation arises, the Bidder shall promptly notify the Bank in

writing of such conditions and any change thereof. Unless otherwise directed by the

Purchaser in writing, the Bidder shall continue to perform his obligations under the

contract as far as possible, and shall seek all means for performance of all other

obligations, not prevented by the Force Majeure event.

11.19 Ancillary Services The Bidder shall provide the necessary services for the supply, delivery at final

destination, installation and putting into satisfactory operation of the goods/products.

11.20 Audits The Bank can conduct any third party inspection/ audit for any phase. The Bidder

should make all necessary changes as mentioned by the results of these audits.

11.21 Prices The price charged by the Bidder for the services performed for the AMRMS Project

shall not vary from the contracted prices.

No adjustment of the contract price shall be made on account of variation of costs of

labour and materials or any other cost component affecting the total cost in fulfilling

the obligations under the contract. The Contract price shall be the only payment,

payable by the Purchaser to the Bidder for completion of the contractual obligations

by the Bidder under the Contract, subject to the terms of payment specified in the

Contract.

The price would be inclusive of all applicable taxes under the Indian law.

The prices, once offered, should remain firm and should not be subject to escalation

for any reason within the period of validity. The entire benefits/advantages, arising



out of fall in prices, taxes, duties or any other reason, should be passed on to the

Bank.

11.22 Taxes and Duties The Bidder shall be entirely responsible for all taxes, stamp duties, license fees, and

other such levies imposed within and outside India.

The Bidder is expected to submit the Commercial bid inclusive of the applicable

taxes for each line item as mentioned in Annex 14

11.23 Non Negotiability on RFP The Bank is not responsible for any assumptions or judgments made by the Bidders

for arriving at any type of sizing or costing. The Bank at all times will benchmark the

performance of the Bidder to the RFP documents circulated to the Bidders and the

expected service levels as mentioned in these documents. In the event of any

deviations from the requirements of these documents, the Bidder should make good

the same at no extra costs to the Bank, in order to achieve the desired service levels

as well as meeting the requirements of these documents.

All terms and conditions, payments schedules, time frame for implementation,

expected service levels as per this Tender will remain unchanged unless explicitly

communicated by the Bank in writing to the Bidder. The Bidder shall at no point be

entitled to excuse themselves from any claims by the Bank whatsoever for their

deviations in conforming to the terms and conditions, payments schedules, expected

service levels, time frame for implementation etc. as mentioned in this RFP.

The Bidders shall adhere to the terms of this RFP and shall not deviate from the

same.



12 Evaluation Process

12.1 Objective of Evaluation Process The objective of the evaluation process is to evaluate the bids received to select the

best fit solution at a competitive price based on technical and commercial

parameters. The evaluation will be undertaken by a Committee formed for the

purpose by the Bank which consists of senior Bank officials and external experts.

The decision of the Bank regarding the evaluation and selection of the Bidder would

be final.

For the purpose of the evaluation and selection of Bidder for the AMRMS project

implementation, a three-stage evaluation process will be followed. First of all, the

bidder has to comply with the pre-qualification criteria as per Annex 1 to qualify to

participate in the Technical Bid evaluation process. Those bidders who qualify the

pre-qualification criteria will only be eligible to participate in the ‘the Technical Bid’

and ‘the Commercial Bid’ process.

The bidders have to submit ‘the Technical’ and ‘the Commercial’ Bid simultaneously

in separate sealed covers; however final commercial bid decision will be taken on

the basis of ‘Reverse Auction’ Process. The ‘Technical Bid’ in a soft copy should

also be provided in a CD.

The Bidder has to submit ‘Technical Bid’ keeping in view the information / criteria

mentioned in Chapter 6, 7 and 8 of this document in a sealed envelope by the date

and time stipulated as in Table 1 of Chapter 1.

‘Technical Bid’ will contain the exhaustive and comprehensive technical details. The Technical Bid shall NOT contain any pricing or commercial information at all and if the Technical Bid contains any price related information, then that Technical Bid would be disqualified and would NOT be processed further.

The ‘Technical Bids’ will be opened on the date mentioned at Table 1 of Chapter

1and subsequently evaluated on certain pre-determined criteria and a technical

score would be arrived at. It is mandatory to score a minimum cut‐off marks, which

will be determined by the Committee, of the total 60 marks allocated for the

Technical evaluation. The Bidder scoring the highest technical score will be ranked

as T1 and so on. Bidders who do not achieve the cut‐off on any of the parameters as

determined by SC members will be disqualified from the bidding process further.



However, the Committee reserves the right to relax any of the parameters if the need

arises. Further details in this regard is furnished in Chapter 12.8.

In the third stage of evaluation, the commercial bid submitted by the bidders will be

opened and thereafter, all the Bidders who have qualified in the Technical evaluation

process shall be invited to participate in Reverse Auction Commercial bidding

process. After the Reverse Auction Commercial bidding process is complete, all bids

of the Bidders would be ranked as L1 (lowest bid), L2 and so on.

During the ‘Techno-Commercial’ evaluation, the ‘Technical Bid’ score carries a

weight of 60 percent, the ‘Commercial Bid’ score carries a weight of 40 percent. The

‘Techno‐Commercial’ scores (60:40) will be arrived at for each qualified Bidder and

the Bidder with the highest score as calculated by the formula mentioned in Chapter

12.10 will be declared as the successful Bidder as TC1. In case of non-acceptance

of the offer by TC1, the offer will be given to next successful bidder i.e. TC2, and so

on.

Post selection of the Bidder, the Bank shall return the Earnest Money Deposit (EMD)

to the unsuccessful Bidders within 30 days of formal declaration of results.

Bank may call for any clarifications / additional particulars required, if any, on the

Pre‐qualification / technical / commercial bids submitted. The Bidder has to submit

the clarifications / additional particulars in writing within 2 working days. 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. Based upon the final technical scoring, short listing would be

made of the eligible Bidders for final commercial bidding.

12.2 Technical Bid Evaluation Process The scoring methodology for technical bid components is explained in the following

paragraphs of this section.

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

parameters:

• Functional requirements (FR)



• Presentation which includes

• Product Structured Walkthrough in general.

• Approach, Methodology (AM) & Implementation Strategy for AMRMS

• Team Composition (TC)

• Past Experience of the Bidder in dealing in such project in the Banking Sector with special preference to India

• Proof of concept Each parameter would be assigned a score weight. The weighted scores shall be

summed up to determine the technical scores of the Bidders. The Bidder with the

highest technical score shall be ranked as T1 and shall be considered as THigh

for the

technical-commercial score.

12.3 Scoring Methodology for Functional Requirements

The functionalities expected from AMRMS are explained in Chapter 6 of the RFP.

The bidder would be required to submit their responses as how their product would

address the various functionalities as per Annex 12.

Response Options The Bidder should provide a response to each of the requirements of Annex 12,

which could be any one from the following categories:

1. Out of the Shelf / Configurable: The system that shall be delivered currently

supports this function either in native form without further enhancement or

the use of either programming or user tools, i.e. included in the base

package. This can also include assets/plug‐ins developed by the Bidder for

similar projects.

The system that shall be delivered currently supports this function but it

would need to be parameterized and modified according to needs of the

Bank. No additional coding or changes in code would be required.

2. Customization: The function is not available in the product but capability is

there and hence would require customisation by the Bidder’s programming

staff.

3. Not Possible – The requirement cannot be met by the proposed system.

4. Yes – The functionality / capability is present.

5. No - The functionality / capability is not present.



The committee would cross verify the information furnished by the respective bidders

in this regard and scoring for the functional requirements would be done accordingly.

The Bidder is expected to amply demonstrate all the Off the Shelf Features as indicated in Annex 12 in this regard.

The Bank reserves the right to reject the bid if the Bidder does not respond / leaves

the response field blank for any of the requirements.

Scoring for the responses in Annex 12 will be as follows: Table 8:

Out of the Shelf / Configurable 5

Customization 3

Not Possible 0

Yes 2

No 0

The total marks obtained would be converted to a score to be calculated out of 21.

(i.e. 35% of 60 which is the total marks for Technical Evaluation)

12.4 Scoring Methodology for Product Structured Walkthrough & Presentation based on PoC

12.4.1 Product Structured Walkthrough

The bidder should demonstrate all the functionalities of the product in the structured

walkthrough covering its salient features and the committee would evaluate and

assign marks accordingly.

During the structured walkthrough, the Bank may seek explanations on various

technical and other requirements.

The cost for set up for the structured walkthrough / PoC will be borne by the Bidder.

The Bank will not bear the expenses incidental to conducting the Structured

Walkthrough by the Bidder and his team.

12.4.2 Presentation based on Proof of Concept (PoC)

In addition to the structured walkthrough of the product the bidder would also have

to present and demonstrate the product capabilities based on the PoC so prepared



based on the data / input provided by the Bank as under. With regards to

presentation based on PoC, it would be advisable that the bidder shows the

complete workflow of the proposed system over one audit cycle with the following

minimum information:

1. Conduct of RBIA of a Regional Office which will involve the following activities: a. Preparation of Audit Calendar

b. Allocation of man-days

c. Allocation of resources

d. Pre-audit data/information in respect of auditees

e. Checklist Modification/Management

f. Audit Intimation

g. Message Broadcasting

h. Addition/ Deletion of audit entities/types of audit

2. Assignment of audit activities to team members of the following departments:

a. Issue Department – Cash Handling, Vault Maintenance, Vault Operation, Cash Handling (CCVS), Day-to-day vault operations, Coin vault, Resource, Remittance, Accounts, Records, CVPS etc.

b. DBS – Access control system (including password policy), Bank monitoring and follow up actions, complaint redressal analysis, monitoring of fraud cases, programming and conducting of inspection etc.

c. IT Cell – AMC (critical & non-critical IT assets, Facility Management & Warranty, Anti-virus control, BCP & DR drill, Incident Reporting, IT resource planning & purchase, maintenance of server room, network management, systems & project implementations, Access control in server room etc.

3. Input of data in the above mentioned areas and report submission to PIO and

vice versa till finalisation.

4. Facility of uploading work papers by auditors in the system

5. Generation of Fact Sheets and Audit Reports

6. Submission of report and acceptance by auditee.

Based on the technical response received and product walk-through the Bank

reserves the right to add items to the above list of items, a few specific functional

requirements need to evaluate that particular solution.



The responses provided by the Bidder in response to functional and technical

requirements of RFP will be verified and marked during the structured walkthrough

process. The Bank will not release any structured questionnaires for the product

walkthrough.

12.5 Scoring Methodology for Approach, Methodology & Implementation Strategy

Overview

The Bidder is expected to provide, as a part presentation to the Bank’s Steering

Committee (may consist of external as well as internal personnel) explain 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 SC and would cover the following:

1. Customisation for the defined requirements

2. Data Migration Methodology

3. Project Management

4. Roll‐Out Strategy & Training

Data Migration

The quality of the Bidder’s Data Migration procedure shall form an integral part of the

final evaluation and selection of the Bidder.

Data Migration solicits answers from the Bidder to questions on the Data Migration

techniques used. Bank shall rate each of the answers provided by the Bidder and

arrive at a total score for the entire module. The questions pertain to the Data

Migration training techniques, details of various steps to be carried out for successful

Data Migration by the Bidder and experience of the implementers.

Project Management

It is expected that the Bidder gives an elaborate Project Management template

covering each of the activities and the implementation schedule as per the

Implementation details provided in the Annex 3.



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 as per Annex 3.

Roll‐Out Strategy

The Bidder needs to prepare a roll‐out strategy and a plan on how efficiently and

optimally the AMRMS application can be rolled out.

12.6 Scoring Methodology for Team Composition The Bidder should propose a detailed team composition for the implementation of the

defined scope. The Bank envisages a structure headed by the project manager with

multiple team leaders managing various teams. The Bidder is, however, expected to

independently understand the scope and evaluate the resource requirements before

proposing the team structure. The resources assigned on the project are expected to

possess a minimum experience as listed in the table below:

Table 9:

Team Member

Scoring Criteria Marks Awarded

Project Manager

Should have 10 years of experience in Project Management with a minimum of one AMRMS like implementation as Project Manager

• 10 marks for experience in more than one AMRMS like implementations as Project Manager in a Bank in India • 5 marks for experience in one AMRMS like implementation as Project Manager in a Bank in India • 0 mark for not fulfilling the criteria

Team Leader(s)

Should have more than 5 years of experience in Project Management with a minimum of one AMRMS like implementation as Team Leader

• 5 marks for experience in more than one AMRMS like Implementations in a Bank in India

• 3 marks for experience in one AMRMS like implementation in a Bank in India

• 0 mark for not fulfilling the criteria

Team Members at least 2 in number

Should have at least 3 years’ experience in AMRMS like implementations as team members.

• 5 marks for experience in more than one AMRMS like Implementations in a Bank in India • 3 marks for experience in one AMRMS like Implementation in a Bank in India • 0 mark for not fulfilling the criteria



The total marks for Team Composition would be 20 which would be converted to

appropriate score as per the weightage.

At the time of bidding, the Bidder needs to have the required Project Manager, Team

Leader and Team Members with appropriate skills and experience on their payrolls

(excluding those employees on their notice period) to successfully commence and

complete the AMRMS project.

If any person has resigned from the Bidder’s company, then his name should not

feature in the proposed team structure.

The proposed team Profile information as per Annex 9 should be furnished along

with the other RFP documents keeping in view the requirements as mentioned

above in table 9.

12.7 Scoring Methodology for Past Experience(PE) in Banking Sector

The evaluation of the Past Experience will be done on the basis of the information

furnished by the bidder as per Annex 6.

12.8 Consolidated Score in Technical Bid Evaluation

The overall score for evaluating the Bidder would be 100 marks, out of which 60

marks is for the Technical evaluation and 40 marks is for Commercial bid.

Table 10: Score breakup for Bidder Evaluation

Technical Evaluation Commercial Bid Overall Score

60 40 100

The breakup for the 60 marks which is allocated for the Technical Evaluation is given

in the table below:

Table 11: Technical Score breakup for Bidder Evaluation

Scoring Parameters Weightage (%)

Total Marks out of 60

Functional Requirements (FR) as per Annex 12

35% 21



• Approach, Methodology & Implementation (10%)

• Product Walkthrough (7.5%) • Team Composition (TC) (7.5%) • Past Experience (PE) in Banking Sector

(10%)

35%

6

4.5

4.5

6

Demonstration of the Product based on Proof of Concept (PoC) as per criteria furnished in the RFP Document

30% 18

Total 100% 60

The Bidder will have to mandatorily score a minimum qualifying cut‐off marks

allocated for the Technical evaluation as decided by the Committee. The Bank may

disqualify any Bidder who does not achieve the cut‐off on any of above mentioned

bidding parameters from the bidding process. The decision of Committee in this

regard would be final.

The Bidder with the highest technical score shall be declared as T1.

12.9 Disqualification Parameters in Technical Bid Evaluation

Commercial Bids of only those Bidders who qualify the technical evaluation shall be

opened. Commercial Bids of the other Bidders shall not be opened and their Earnest

Money Deposit (EMD) shall be returned. If only one Bidder qualifies, the Bank at its

discretion may select more than one bidder for commercial evaluation.

The Bank at its discretion may reject the proposal of the Bidder without assigning

any reason whatsoever, if in the Bank’s opinion, the Solution Sizing was not made

appropriately to meet the performance criteria as stipulated by the Bank.

The Bank at its discretion may reject the proposal of the Bidder without giving any

reason whatsoever, if in the Bank’s opinion, the Bidder could not present or

demonstrate the proposed solution as described in the proposal.

12.10 Commercial Bidding by Reverse Auction Process The Bidders who qualify the technical bid evaluation will be invited to participate in

the Commercial bidding Process by ‘e-Reverse Auction’. The e-Reverse Auction

shall be conducted by the Bank through one of its service providers.

It may be noted that ‘Digital Signature’ is required for participation in the Reverse

Auction Commercial bidding process. The cost of Digital Signature will be borne by

the Bidder / Tenderer.



12.10.1 Auction

The qualified tenderer / bidder shall be given a unique user name and initial

password by the service provider. Each tenderer / bidder shall change the password

and edit the information in the registration page after receipt of initial password.

All the commercial bids made from the log-in ID given to bidder shall ipso-facto be

considered as the bid made by the bidder to whom log-in ID and password were

assigned by the service provider. Any bid once made through registered log-in ID /

password by the bidder shall be binding and final and cannot be cancelled.

Every successive commercial bid by the bidder being decremented, shall replace the

earlier bid automatically and the final bid as per the time and log-in ID shall prevail

over the earlier bids.

12.10.2 Transparency in Bids

All bidders will be able to view during the e-auction time the current lowest price in

the web - portal. Tenderers / Bidder shall be able to view not only the lowest bid but

also the last bid made by him at any point of time during the auction time.

12.10.3 Masking of Names

Names of tenderers / bidders shall be anonymously masked in the e-Reverse

Auction process and tenderers/ bidders will be given suitable dummy names by the

Service Provider.

12.10.4 Start Price

The Bank shall determine the start price either on its own or on the basis of the

lowest offer of the tenderer submitted.

12.10.5 Decremental Bid Value

The tenderers / bidders shall be able to bid only at a specified decrement value of Rs

1.0 lakh or any other values mutually agreed between the Bank and the bidders and

not at any other fractions.

For the sake of convenience of vendors, the web portal shall display the next

possible decremental value of bid. It is not, however, obligatory on the part of

vendors to bid at the next immediate lower level only. (That is, bids can be even at 2,

3 or more lower levels than the immediate lower level.)

12.10.6 e-Reverse Auction Process



In order to reduce the time involved in the procurement process, Bank shall be

entitled to complete the entire procurement process through a single e-Reverse

Auction.

The Bank shall however, be entitled to cancel the procurement of e-Reverse Auction

process, if in its view procurement or e-reverse auction process cannot be conducted

in a fair manner and/or in the interest of the Bank.

All the Bidders / Tenderers shall be required to provide a break-up of their individual

last bid price at the close of auction duly signed and stamped as per Annex 14 within

2 working days.

12.10.7 Don'ts Applicable to Tenderer / Bidder/ Vendor

No tenderer / bidder shall involve himself or any of his representatives in any price

manipulation directly or indirectly with other tenderers / bidders. If any such practice

comes to the notice, Bank shall disqualify the tenderer / bidder/s concerned from the

e-reverse auction process and may initiate any further disciplinary/ penal action as

deemed fit.

The tenderer / bidder shall not disclose details of his bids or any other details

concerning e-Reverse Auction process of the Bank to any other third party without

specific permission in writing from the Bank.

Neither the Bank nor the service provider shall be held responsible for any faults in

facilities such as power supply, system problem, inability to use the system, loss of

electronic information, power interruptions, UPS failure, etc. which may affect the

bidding process of any tenderer/ bidder/s.

12.10.8 Date / Time of Reverse Auction The Date and Time of commencement of Reverse Auction as also Duration of

'Reverse Auction Time' shall be communicated separately.

Any force-majeure or other condition leading to postponement of auction shall entitle

the Bank to postponement of auction even after communication, and the Bank shall

take all possible efforts to communicate to all participating bidders the

'postponement' prior to commencement of such 'e-Reverse Auction', to the extent it

is feasible under the circumstances resulting in such a force-majeure.



12.10.9 Compliance/Confirmation from Vendors

The Bidders participating in e-Reverse Auction shall submit the following documents

duly signed by the same Competent Authority who signs the offer documents in

response to the Tender;

a) Acceptance of Procedure for e-Reverse Auction and undertaking,

b) Agreement between service provider and vendor. (This format will be given

by the service provider during training for e - Reverse Auction.)

c) Letter of authority authorising the name/s of official/s to take part in e-

Reverse Auction.

12.10.10. Training

The Bank shall arrange training for participation in e-Reverse Auction through the

service provider. The service provider shall also enter into an agreement with each

bidder as per a format designed by him for this purpose.

Any bidder not participating in training shall do so at his own risk and responsibility

and such non-participation shall not be considered a valid reason for seeking any

special right / privilege and / or exemption.

Each tenderer / bidder shall participate in the training at his own cost, if any.

Training for e-Reverse Auction shall be arranged to only those tenderers who shall

be declared technically qualified after scrutiny of ‘Technical Bid’ by the Bank.

The date and time of the training will be intimated to the technically qualified

tenderers in due course. No request for postponement / re-scheduling of Training

Date / Time shall be entertained which in the sole view and discretion of the Bank

might result in any avoidable delay to either the e-Reverse Auction or the whole

process of selection of vendor or may act or cause to act in the detrimental interest

of the bidding process or for the Bank as whole.

12.11 Technical-Commercial Bid Evaluation All the Bidders / Tenderers shall be required to provide a break-up of their individual

last bid price at the close of auction duly signed and stamped as per Annex 14 within

2 working days. The Commercial Bid would be inclusive of all applicable taxes.



The payments shall be done as per the costs quoted by the Bidder when the

corresponding services are provided and such payments become due.

The Technically Qualified Bidder with the lowest Commercial Bid after ‘Reverse

Auction’ would be declared as CLOW

.

The technical‐commercial score shall be calculated as follows:

Total Score = (T / THIGH)*0.6 + (CLOW / C)*0.4

Here, T and C are the technical and commercial scores of the respective Bidders.

The bidder with the highest total score will be selected as the successful bidder. In

case of a tie of Total Score between two or more Bidders, the Bid with higher

technical score would be chosen as the successful Bidder.

The Bank will notify the name of the Successful Bidder.

Commercial bid valuation shall be considered as below in case of any kind of

discrepancy:

• If there is a discrepancy between words and figures, the amount in words

shall prevail,

• If there is discrepancy between unit price and total price, the unit price shall

prevail,

• If there is a discrepancy in the total, the correct total shall be arrived at by

Bank.

In case the Bidder does not accept the correction of the errors as stated above, the

bid shall be rejected.

The Bank reserves the right to renegotiate any terms (Price / Technical) further with

the successful Bidder.



13. Instructions for Tender submission 13.1 Instructions for Tender submission Reserve Bank of India (RBI) has prepared this document to give background information on participating in RFP process of AMRMS Project from the five (5) short-listed bidders only, i.e; (i) Auditime Information Systems Pvt. Ltd., Mumbai (ii) NCSSoft Solutions Pvt. Ltd., Chennai (iii) PWC Pvt. Ltd., Mumbai (iv) Quadrant 4 Software Solutions Pvt. Ltd., Chennai and (v) Thomson Reuters Pvt. Ltd., Mumbai; based on Expression of Interest (EOI) evaluation.

RFP Application received from any other bidder(s) will be summarily rejected.

The Bidder is expected to submit only one Technical Bid and relevant one

Commercial Bid. More than one Technical and Commercial Bid should not be

submitted and violation of the same may lead to disqualification of the bidder. The

Technical and Commercial bids should be put in separate covers and all such covers

shall be put in one single cover and delivered at the address mentioned in the Bid

Schedule.

The Bidder is expected to submit the Commercial bid inclusive of the applicable

taxes for each line item in the Annex 14. The Commercial Bid Compliance Certificate

should also be submitted as per format specified in Annex 13.

The cost of bidding and submission of the bids is entirely the responsibility of the

Bidders, regardless of the conduct or outcome of the tendering process.

Bids, in sealed covers, as per the Instructions to Bidders should be delivered as

mentioned in the Bid Schedule. Bids may be sent by registered post or by hand

delivery, so as to be received at the address mentioned in the Bid Schedule.

Receipt of the bids shall be closed as mentioned in the Bid Schedule. Bids received

after the scheduled closing time will not be accepted by the Bank under any

circumstances. Bank will not accept bids delivered late for any reason whatsoever

including any delay in the postal service, courier service or delayed bids sent by any

other means.

The technical bids will be opened as mentioned in Bid Schedule.



The Bidders or their authorized representatives may be present at the time of the

opening of the technical bid. Only two persons per Bidder will be allowed to be

present at the time of the opening the technical bids. No bid shall be rejected at bid

opening stage, except for bids received late.

13.2 General Guidelines The offers should be made strictly as per the formats specified. The bidders should

also mandatorily submit the certificate / letters among other things as per format

mentioned in all the Annexes and Non- Disclosure Certificate.

A declaration may be given by the Bidder stating that "No relative of the Bidders is

working in the Reserve Bank of India". If anyone working in the Bank is related to the

Bidders, the name, designation and the department where the person is posted may

be given.

The Bid should not contain any erasures, over‐writings or corrections using

whiteners. Any corrections to be made would be by striking through the content

being corrected and duly authenticating the corrections.

The Bidder is expected to examine all instructions, forms, terms and conditions and

technical specifications in the Bidding Documents. Failure to furnish all information

required by the Bidding Documents or submission of a bid not substantially

responsive to the Bidding Documents in every respect will be at the Bidder’s risk and

may result in rejection of the bid.

No rows or columns of the tender should be left blank. Offers with insufficient

information and Offers which do not strictly comply with the stipulations given above,

are liable for rejection.

The Bank may at its discretion abandon the process of the selection of Bidder any

time before notification of award.

All information (bid forms or any other information) to be submitted by the Bidders

may be submitted as a softcopy also in MS – Word in a CD and should be kept in the

respective sealed covers. The Bidders may note that no information is to be

furnished to the Bank through e‐mail except when specifically requested and such

queries are to be confirmed in writing.



The Bank reserves the right to pre‐pone or post‐pone the pre‐bid meeting date.

However, Bidders will be informed the date of pre‐bid meeting in advance to submit

their queries to the Bank seeking clarification.

The bids will be opened in the presence of competent authorized representatives of

the Bank and / or Bidders. In case of bidders’ presence during bid opening, the

representative of the Bidder has to produce an authorization letter from the Bidder to

represent them at the time of opening of Technical/Commercial bids. Only two

representatives will be allowed to represent any Bidder. In case the Bidder’s

representative is not present at the time of opening of bids, the quotations/bids will

still be opened at the scheduled time at the sole discretion of the Bank.

13.3 Clarification on the Tender Document For any clarification with respect to this RFP document, the Bidder may send an

email. The format to be used for seeking clarification is mentioned in Annex 8.

It may be noted that all queries, clarifications, questions, relating to this RFP,

technical or otherwise, should be in writing only and should be to the designated

email id as stated earlier.

Written requests for clarification may be submitted to the Bank at least 3 days prior

to Pre‐bid meeting and clarifications for such queries shall be provided by the Bank

or its representative in the pre‐bid meeting.

The Query Form should preferably be emailed to the Bank or provided by softcopy –

in either event hardcopy confirmations are to be submitted in the beginning of pre-

bid meeting.

Bidders should provide their email address in their queries without fail since replies

from Bank will be by emails only.

13.4 Amendments to Tender Documents Amendments to the Tender Document may be issued by the Bank for any reason,

whether at its own initiative or in response to a clarification requested by a

prospective Bidder, prior to the deadline for the submission of bids, which will be

mailed to all the bidders.

The amendments so made will be binding on all the Bidders. From the date of issue,

amendments to Terms and Conditions shall be deemed to form an integral part of

the RFP. Further, in order to provide prospective Bidders reasonable time to take the

mailto:[email protected]



amendment into account in preparing their bid, the Bank may at its discretion extend

the deadline for submission of bids.

13.5 Language of Bids All bids and supporting documentation shall be submitted in English.

13.6 Period of Bid Validity The Bids will be treated as valid for a period of 180 days from the closing date for

submission of the bid

13.7 Format and Signing of Bid The bid should be signed by the Bidder or any person duly authorized to bind the

Bidder to the contract. The signatory should give a declaration and through

authenticated documentary evidence establish that he/she is empowered to sign the

bid documents and bind the Bidder. All pages of the bid documents except

brochures if any are to be signed by the authorized signatory. All the pages of the bid

document should be serially numbered.

Forms with respective Power of Attorney should be submitted and signed by the

authorized signatory. Unsigned bids would entail rejection of the bid.

13.8 Correction of Errors

Arithmetic errors in bids will be treated as follows:

• Where there is a discrepancy between the amounts in figures and in words, the

amount in words shall govern; and

• The amount stated in the tender form, adjusted in accordance with the above

procedure, shall be considered as binding, unless it causes the overall tender

price to raise, in which case the bid price i.e. BID AMOUNT as Total Field in

Annex 14 shall govern.

13.9 Acceptance and Rejection of Bid

The Bank reserves the right not to accept any bid, or to accept or reject a particular

bid at its sole discretion without assigning any reason whatsoever.

13.10 Duration and Condition of Engagement Reserve Bank of India shall engage and appoint the successful Bidder to provide

services as detailed in Chapter 6 and Chapter 7 and other relevant documents



containing functional requirements of this document and in consideration of

remuneration payable by the Bank to the Bidder. The Bidder is expected to provide 3

years Warranty and 4 years of AMC for the application installed.

The Bank will reserve the right to terminate the services of the successful Bidder at

any point of the Project without assigning any reasons.

Information collected or provided to the Bidder would be confidential and shall not be

used by him for any other purpose. The work/study carried out by the Bidder would

be the sole property of the Bank.

At no point should the Bidder use the name of the Bank without prior written

permission to advertise itself.

13.11 General Terms and Conditions The bidder should cross check and submit the certificate as per format specified in

Annex 15 whether all the mandatory letters / certificates have been enclosed with the

RFP documents or not. In case of non-submission of any document may lead to

disqualification of the bidder from the RFP tendering process.

The term of this Bidder assignment is for a period of seven years from the date of

acceptance of appointment order or such extended period as may be mutually

agreed up on.

Adherence to terms and conditions: The Bidders who wish to submit responses to

this RFP should note that they should abide by all the terms and conditions

contained in the RFP. If the responses contain any extraneous conditions put in by

the respondents, such responses will be disqualified and will not be considered for

the selection process.

DISCLAIMER : The Bank and/or its officers, employees disclaim all liability from any

loss or damage, whether foreseeable or not, suffered by any Bidder/person acting on

or refraining from acting because of any information including statements,

information, forecasts, estimates or projections contained in this document or

conduct ancillary to it whether or not the loss or damage arises in connection with

any omission, negligence, default, lack of care or misrepresentation on the part of

Bank and/or any of its officers, employees.

Execution of SLA: The Bidder should execute



• A Service Level Agreement, which would include all the services and terms and

conditions of the services to be extended as detailed herein and as may be

prescribed by the Bank.

13.12 Other Terms and Conditions The Bank reserves the right to:

• Reject any and all responses received in response to the RFP without

assigning any reason whatsoever;

• Cancel the RFP/Tender at any stage, without assigning any reason

whatsoever;

• Waive or Change any formalities, irregularities, or inconsistencies in this

proposal (format and delivery). Such a change/waiver would be duly and

publicly notified in the Bank's website before the closure of the bid date;

• Extend the time for submission of all proposals and such an extension would

be duly and publicly notified to all the Bidders;

• Select the next eligible Bidder(L2) if the first successful Bidder(L1) evaluated

for selection fails to execute an agreement within a specified time frame;

• Share the information/ clarifications provided in response to any queries made

by any Bidder, with all other Bidder(s) /others, in the same form as clarified to

the Bidder raising the query.

The proposed team members should possess the knowledge and necessary

experience as specified under Chapter 12.6 and should be deployed as per the

requirements of the AMRMS Project. The key persons identified by the Bidder for the

project should carry out their activities from the premises of Reserve Bank of India,

Mumbai till the successful roll out of the project.

The clarifications, if any, required by the Bidder should be informed in writing, in

advance to the address given above. Such clarifications can be asked preferably up

to the date as schedule mentioned in Chapter 1. If the Bank in its absolute discretion

deems that the originator of the clarification will gain any advantage by a response to

a question, then the Bank reserves the right to communicate such query and

response to all respondents of the RFP.

The successful Bidder will be ineligible to bid for any audit/review and 3rd party user

acceptance testing tenders released under the AMRMS project.



Substitution of Project Team Members: During the assignment, the substitution of

key staff such as Project Manager, Team Leader or any key Team Members

identified for the assignment will not be allowed unless such substitution becomes

unavoidable to overcome the undue delay or that such changes are critical to meet

the obligation. In such circumstances, the Bidder can do so only with the

concurrence of the Bank by providing other staff of same level of qualifications and

expertise. If the Bank is not satisfied with the substitution, the Bank reserves the right

to terminate the contract and recover payments made by the Bank, if any to the

Bidder during the course of this assignment besides claiming an amount, equal to

the contract value as liquidated damages. However, the Bank reserves the right to

insist the Bidder to replace any team member with another (with the qualifications

and expertise as required by the Bank) during the course of assignment.

Professionalism: The Bidder should provide professional, objective and impartial

advice at all times and hold the Bank’s interests paramount and should observe the

highest standard of ethics while executing the assignment.

Adherence to Standards: The Bidder should adhere to laws of land and ‘rules,

regulations and guidelines’ prescribed by various regulatory, statutory and

Government authorities.

No legal binding relationship: It may be noted that no binding legal relationship will

exist between any of the Respondents of this RFP and the Bank, until execution of a

contractual agreement.

The Bank reserves the right to conduct an audit/ ongoing audit of the services

provided by the successful Bidder.

The Bank reserves the right to ascertain information from any of the Indian public

sector undertaking/ Indian public sector banks/large government departments in

India in which the Bidders have rendered their services for execution of similar

projects.

The Bank reserves the right to disqualify any bidder, who is involved in any form of

lobbying/ influencing/ canvassing etc., in the evaluation / selection process.



13.13 Expenses incurred by Successful Bidder on the Project It may be noted that the project office from where the project shall be managed and

implemented shall be established in Mumbai. The data centre where the application

would be hosted may be at a site outside Mumbai. The Bank will not pay any amount

/expenses /charges /fees /travelling expense /boarding expenses /lodging expenses

/conveyance expenses /out of pocket expenses other than the agreed Contract

amount.

13.14 Evaluation and Comparison of Bids Only bids from already five shortlisted Bidders meeting the defined requirements and

submitting complete and responsive bids will be processed to the stage of being fully

evaluated and compared. The evaluation criteria shall be based on the requirements,

stated in this document.

13.15 Notification of Awards The acceptance of a tender, subject to contract, will be communicated in writing at

the address supplied by the Bidder in the tender response. Any change of address of

the Bidder, should therefore be promptly notified to:

Principal Chief General Manager

Inspection Department


C7, 8thFloor,

Bandra Kurla Complex, Bandra (East)

Mumbai – 400 051, Maharashtra, India

13.16 Authorized Signatory for Signing the Contract The selected Bidder shall indicate the authorized signatories who can discuss and

correspond with the Bank, with regard to the obligations under the contract. The

selected Bidder shall submit at the time of signing the contract, a certified copy of the

resolution of their Board, authenticated by Company Secretary, authorizing an official

or officials of the company or a copy of the Power of Attorney to discuss, sign

agreements/contracts with the Bank. The Bidder shall furnish proof of signature

identification for above purposes as required by the Bank.



13.17 Signing of Contract The Bidder shall be required to enter into a contract with the Bank, within 15 days of

the award of the tender or within such extended period mutually agreed by both

parties.

13.18 Vicarious Liability The Bidder shall be the principal employer of the employees, agents, contractors,

subcontractors etc., engaged by the Bidder and shall be vicariously liable for all the

acts, deeds or things, whether the same is within the scope of power or outside the

scope of power, vested under the contract. No right of any employment shall accrue

or arise, by virtue of engagement of employees, agents, contractors, subcontractors

etc., by the Bidder, for any assignment under the contract. All remuneration, claims,

wages dues etc., of such employees, agents, contractors, subcontractors etc., of the

Bidder shall be paid by the Bidder alone and the Bank shall not have any direct or

indirect liability or obligation, to pay any charges, claims or wages of any of the

Bidder’s employees, agents, contractors, subcontractors etc. The Bidder shall agree

to hold the Bank, its successors, assigns and administrators fully indemnified, and

harmless against loss or liability, claims, actions or proceedings, if any, that may

arise from whatsoever nature caused to the Bank through the action of Bidder’s

employees, agents, contractors, subcontractors etc.

13.19 Assignment Neither the contract nor any rights granted under the contract may be sold, leased,

assigned, or otherwise transferred, in whole or in part, by the Bidder, and any such

attempted sale, lease, assignment or otherwise transfer shall be void and of no effect

without the advance written consent of the Bank.

13.20 Non-Solicitation The Bidder, during the term of the contract and for a period of one year thereafter

shall not without the express written consent of the Bank, directly or indirectly:

• Recruit, hire, appoint or engage or attempt to recruit, hire, appoint or engage or

discuss employment with or otherwise utilize the services of any person who has

been an employee or associate or engaged in any capacity by the Bank in

rendering services under the contract; or



• Induce any person who is / have been an employee or associate of RBI at any

time to terminate his/ her relationship with the Bank

13.21 No Employer– Employee Relationship The Bidder or any of its holding/subsidiary/joint‐venture/ affiliate / group / client

companies or any of their employees / officers / staff / personnel / representatives /

agents shall not, preferably have / deemed to have any employer‐employee

relationship with the Bank or any of its employees /officers / staff / representatives /

personnel / agents.

13.22 Subcontracting The Bidder shall not subcontract or permit anyone other than its personnel and the

parties enlisted in the response to perform any of the work, service or other

performance required of the Bidder under the contract without the prior written

consent of the Bank.

13.23 Design Ownership The ownership of the design for the AMRMS specific to the Bank and all related

application suites, interface designs, customizations design etc., and related

Intellectual Property Right (IPR) will rest with the Bank only.

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

RFP For Audit Management and Risk Monitoring System, RBI

Strictly Confidential Annex 1: Pre-Qualification Criteria

Annex 1: Pre-Qualification Criteria (On Bidders Letterhead)

The Bidder may note that the below criteria is of critical importance and non-adherence of the Bidders proposed solution to any would be lead to disqualification from further bidding process For detailed information, please refer Chapter 6 and 7 of the RFP.

Sr. NO

REQUIREMENTS YES / NO

1. Application is online, web-based with a Centralized Database

2. Application has an off-line functionality for critical modules

3. Application is based on a scalable architecture 4. Application has in-build capability for Data Analytics /

MIS report Generation

5. Application is capable of supporting input/output of data in bi-lingual format (English/ Hindi)

6. The Bidder is agreeable and capable for providing support for a minimum of 7 years after receipt of successful completion certificate of the project

7. The Bidder is capable of providing adequate training to the “core-users” of the Bank

8. The Bidder is agreeable and capable for data migration of all the legacy data

Authorized Signature


Strictly Confidential Annex 2: Performance Bank Guarantee 1

Annex 2: Performance Bank Guarantee


Principal Chief General Manager Reserve Bank of India Inspection Department, Central Office C-7, 8th Floor, Bandra Kurla Complex, Mumbai – 400 051,

Dear Sir,

PERFORMANCE BANK GUARANTEE – Services for the Implementation and Maintenance of Audit Management and Risk Monitoring System (AMRMS) for the Reserve Bank of India

WHEREAS

M/s. (name of Bidder), a company registered under the Companies Act, 1956, having its

registered and corporate office at (address of the Bidder), (hereinafter referred to as

“our constituent”, which expression, unless excluded or repugnant to the context or

meaning thereof, includes its successors and assigns), entered into an Agreement

dated …….. (Hereinafter, referred to as “the said Agreement”) with you (Reserve Bank

of India) for end to end implementation and maintenance services, as detailed in the

scope given in the RFP document, for the Implementation of Audit Management and

Risk Monitoring System (AMRMS) for the Reserve Bank of India, as detailed in the said

Agreement.

We are aware of the fact that in terms of sub-para (…), Section (…), Chapter (…) of the

said Agreement, our constituent is required to furnish a Bank Guarantee for an amount

Rs…….. (in words and figures), being 10% of the Contract Price (TCO) of Rs. … (in

words and figures), as per the said Agreement, as security against breach/default of the

said Agreement by our Constituent.



In consideration of the fact that our constituent is our valued customer and the fact that

he has entered into the said Agreement with you, we, (name and address of the bank),

have agreed to issue this Performance Bank Guarantee.

Therefore, we (name and address of the bank) hereby unconditionally and irrevocably

guarantee you as under:

1 In the event of our constituent committing any breach/default of the said Agreement,

which breach/default has not been rectified within a period of thirty (30) days after

receipt of written notice from you, we hereby agree to pay you forthwith on demand

such sum/s not exceeding the sum of Rs…… (in words and figures) without any

demur.

2 Notwithstanding anything to the contrary, as contained in the said Agreement, we

agree that your decision as to whether our constituent has made any such default/s /

breach/es, as afore-said and the amount or amounts to which you are entitled by

reasons thereof, subject to the terms and conditions of the said Agreement, will be

binding on us and we shall not be entitled to ask you to establish your claim or

claims under this Performance Bank Guarantee, but will pay the same forthwith on

your demand without any protest or demur.

3 This Performance Bank Guarantee shall continue and hold good till the completion of

the contract period for AMRMS i.e. (date), subject to the terms and conditions in the

said Agreement.

4 We bind ourselves to pay the above said amount at any point of time commencing

from the date of the said Purchase Agreement until the completion of the contract

period for the Total Solution as per said Agreement.

5 We further agree that the termination of the said Agreement, for reasons solely

attributable to our constituent, virtually empowers you to demand for the payment of

the above said amount under this guarantee and we have an obligation to honor the

same without demur.

6 In order to give full effect to the guarantee contained herein, we (name and address

of the bank), agree that you shall be entitled to act as if we were your principal



debtors in respect of your claims against our constituent. We hereby expressly waive

all our rights of suretyship and other rights, if any, which are in any way inconsistent

with any of the provisions of this Performance Bank Guarantee.

7 We confirm that this Performance Bank Guarantee will cover your claim/s against

our constituent made in accordance with this Guarantee from time to time, arising

out of or in relation to the said Agreement and in respect of which your claim is

lodged with us on or before the date of expiry of this Performance Guarantee,

irrespective of your entitlement to other claims, charges, rights and reliefs, as

provided in the said Agreement.

8 Any notice by way of demand or otherwise hereunder may be sent by special

courier, telex, fax, registered post or other electronic media to our address, as

aforesaid and if sent by post, it shall be deemed to have been given to us after the

expiry of 48 hours when the same has been posted.

9 If it is necessary to extend this guarantee on account of any reason whatsoever, we

undertake to extend the period of this guarantee on the request of our constituent

under intimation to you (Reserve Bank of India).

10 This Performance Bank Guarantee shall not be affected by any change in the

constitution of our constituent nor shall it be affected by any change in our

constitution or by any amalgamation or absorption thereof or therewith or

reconstruction or winding up, but will ensure to the benefit of you and be available to

and be enforceable by you.

11 Notwithstanding anything contained hereinabove, our liability under this Performance

Guarantee is restricted to Rs…… (in words and figures) and shall continue to exist,

subject to the terms and conditions contained herein, unless a written claim is lodged

on us on or before the afore-said date of expiry of this guarantee.

12 We hereby confirm that we have the power/s to issue this Guarantee in your favor

under the Memorandum and Articles of Association/ Constitution of our bank and the

undersigned is/are the recipient of authority by express delegation of power/s and



has/have full power/s to execute this guarantee under the Power of Attorney issued

by the bank in his/their favor.

We further agree that the exercise of any of your rights against our constituent to

enforce or forbear to enforce or any other indulgence or facility, extended to our

constituent to carry out the contractual obligations as per the said Agreement, would not

release our liability under this guarantee and that your right against us shall remain in

full force and effect, notwithstanding any arrangement that may be entered into between

you and our constituent, during the entire currency of this guarantee.

Notwithstanding anything contained herein:

• Our liability under this Performance Bank Guarantee shall not exceed Rs. …. (in

words and figure) ;

• This Performance Bank Guarantee shall be valid only up to …….. (date, i.e.,

completion of warranty period for the Total Solution) ; and

• We are liable to pay the guaranteed amount or part thereof under this Performance

Bank Guarantee only and only if we receive a written claim or demand on or before

…. (date i.e. completion of the warranty period for the Total Solution).

• This Performance Bank Guarantee must be returned to the bank upon its expiry. If

the Performance Bank Guarantee is not received by the bank within the above-

mentioned period, subject to the terms and conditions contained herein, it shall be

deemed to be automatically cancelled.

Dated ……………………. this ……….. day …………. 2016.

Yours faithfully,

For and on behalf of the …………… Bank,

(Signature)

Designation



(Address of the Bank)

Note:

• This guarantee will attract stamp duty as a security bond under Article 54(b) of the Mumbai Stamp Act, 1958.

• A duly certified copy of the requisite authority conferred on the official/s to execute the guarantee on behalf of the bank should be annexed to this guarantee for verification and retention thereof as documentary evidence in the matter.


Strictly Confidential Annex 3: Work Plan Format 1

Annex 3: Work Plan Format Detailed Work Plan (Project Plan) and Personnel Schedule Weeks

Serial No

Task 1 2 3 4 5 6 7 8 9 10 11 12 13 14 …..

The above plan should be provided for the entire duration of the implementation and should include all the areas in the scope that is: 1 Implementation of AMRMS 2 Customization 3 Training 4 Roll-out and Implementation plan The bidder is expected to provide the details mentioned in the table below apart from the details project plan. The details provided in this table should clearly match with the detailed project plan. Sr. No Task Calendar Months * 1

2

3

4 * The calendar months specified should indicate the actual calendar months taken to complete the task from issue of Purchase Order to the selected bidder NOTE: The bidder is expected to fill-up the above mentioned table and not change any of the tasks mentioned above.


Strictly Confidential Annex 4: Conformity Of Soft Copy 1

Annex 4: Conformity of Soft Copy (On letterhead of the bidder)


Principal Chief General Manager [Date]

Reserve Bank of India Inspection Department, Central Office C-7, 8th Floor, Bandra Kurla Complex, Mumbai – 400 051, [Salutation]

Sub: Request for Proposal for Implementation of Audit Management and Risk Monitoring System at Reserve Bank of India.

Further to our proposal dated, in response to the Request for Proposal for

Implementation of Audit Management and Risk Monitoring System (hereinafter referred

to as “RFP”) issued by Reserve Bank of India (hereinafter referred to as “RBI”) we

hereby covenant, warrant and confirm as follows:

The soft-copies of the proposal submitted by us in response to the RFP and the related

addendums and other documents including the changes made to the original tender

documents issued by RBI, conform to and are identical with the hard-copies of aforesaid

proposal submitted by us, in all respects.

In case of any discrepancies between the hard copy and the soft copy of the RFP

response, the hard copy shall supersede the soft copy.

Yours faithfully,

Authorized Signatory Designation Bidder’s corporate name


Strictly Confidential Annex 5: Bidder Undertaking Format 1

Annex 5: Bidder Undertaking Letter (On letterhead of the bidder)

Date:

From:

To Principal Chief General Manager Reserve Bank of India Inspection Department, Central Office C-7, 8th Floor, Bandra Kurla Complex, Mumbai – 400 051,

Dear Sir,

We, the undersigned, as bidder, having examined the complete RFP document (along

with its annexure), do hereby offer to produce, deliver, install, support and maintain

Audit Management and Risk Monitoring System (AMRMS) in full conformity of your

requirements as elaborated in above said RFP for the amounts mentioned by us in the

Commercial Bid or such other sums as may be agreed to between us.

We hereby agree to all the terms and conditions stipulated in the RFP.

We agree to abide by our Offer for a period of 6 months (180 Days) from the date of

last day of Bid submission and it shall remain binding on us for acceptance at any time

before the expiration of this period.

We understand that you are not bound to accept the lowest or any bid you may receive.

We undertake, if our Bid is accepted, to provide Contract Performance Guarantee, AMC

Performance Guarantee in the form and in the amounts and within the times stipulated

in the RFP.

We undertake as a part of this contract for successful operation of the AMRMS during

the warranty and AMC period (if contracted).

Yours faithfully,

(Authorised Signatory) In the capacity of ______________ Duly authorized to sign the Bid for and on behalf of _________________


Strictly Confidential Annex 6: Experience Details

Annex 6 – Experience Details (On letterhead of the bidder)

Part A

Experience of the Applicant of implementing an AMRMS like solution in a Bank in India

Sr.

No.

Name,

Address and Contact

details of

the clients

Name

/Description of

the Product

Month

and Year of

the order

Period of

Implementation Period of

Warranty /

AMC Remarks

From To

Part B

Experience of the Applicant of implementing an AMRMS like solution in any financial institution

Sr.

No.

Name,

Address and Contact

details of

the clients

Name

/Description of

the Product

Month

and Year of

the order

Period of

Implementation Period of

Warranty /

AMC Remarks

From To


Strictly Confidential Annex 7: Confirmation To Deliver 1

Annex 7: Confirmation to Deliver (On letterhead of the Bidder)

To,


Dear Sir, Re: Tender dated MMMM, DD, YYYY TECHNICAL BID for the Implementation of Audit Management and Risk Monitoring System (AMRMS) at the Reserve Bank of India 1 Having examined the Tender Documents including Annexure, the receipt of which is

hereby duly acknowledged, we, the undersigned, offer to supply, deliver, implement

and commission ALL the items mentioned in the ‘Request for Proposal’ and the other

schedules of requirements and services for your bank in conformity with the said

Tender Documents in accordance with the schedule of Prices indicated in the Price

Bid and made part of this Tender.

2 If our Bid is accepted, we undertake to comply with the delivery schedule as

mentioned in the Tender Document.

We attach hereto the Tender Response as required by the Tender document, which

constitutes my/our bid.

We undertake, if our Tender is accepted, to adhere to the implementation plan put

forward in our Tender Response or such adjusted plan as may subsequently be

mutually agreed between us and the Reserve Bank of India or its appointed

representatives.

If our Tender Response is accepted, we will obtain a performance bank guarantee in

the format given in the Tender Document issued by a scheduled commercial bank in

India for a sum equivalent to 10% of the contract sum for the due performance of the

contract.



3 We agree to abide by this Tender Offer for 180 days from the last day of bid

submission and our Offer shall remain binding on us and may be accepted by RBI

any time before expiry of the offer.

4 This Bid, together with your written acceptance thereof and your notification of

award, shall constitute a binding Contract between us.

We agree that you are not bound to accept the lowest or any Tender Response you

may receive. We also agree that you reserve the right in absolute sense to reject all

or any of the goods /products specified in the Tender Response without assigning

any reason whatsoever.

It is hereby confirmed that I/We are entitled to act on behalf of our

corporation/company /firm/organization and empowered to sign this document as

well as such other documents which may be required in this connection.

5 We undertake that in competing for and if the award is made to us, in executing the

subject Contract, we will strictly observe the laws against fraud and corruption in

force in India namely “Prevention of Corruption Act 1988”.

6 We certify that we have provided all the information requested by RBI in the format

requested for. We also understand that RBI has the exclusive right to reject this offer

in case RBI is of the opinion that the required information is not provided or is

provided in a different format.

Dated this …………………………. Day of …………………..2016

……………………………………………. …………………………………………….

(Signature) (In the capacity of)

Duly authorized to sign the Tender Response for and on behalf of:

……………………………………………………………………………………………………… ………………………………………………………………………………………………………

(Name and address of Bidding Company)

Seal/Stamp of Tenderer

Witness name:



………………………………………………………

Witness address:

………………………………………………………

……………………………………………………...

Witness signature:

…………………………………………………


Strictly Confidential Annex 8: Pre Bid Query Format 1

Annex 8: Pre Bid Query Format Bidder’s request for Clarification - to be submitted minimum of three working days before pre-bid meeting If, bidder, desiring to respond to RFP for Implementation of Audit Management and Risk

Monitoring System (AMRMS), require any clarifications on the points mentioned in the RFP

may communicate with Reserve Bank of India using the following format.

All questions received at least three working days before the pre-bid meeting will be

formally responded to and questions/points of clarification and the responses will be

circulated to all participating bidder if required. The source (identity) of the bidder seeking

points of clarification will not be revealed. Alternatively, RBI may at its discretion, answer all

such queries in the Pre-bid meeting.

Execution of AMRMS – RFP BIDDER’S REQUEST FOR CLARIFICATION

To be mailed, delivered, faxed or emailed to:

Chief General Manager -- address, email id and fax number given in the schedule

Name of Organization submitting request

Full formal address of the organization including phone, fax and email points of contact

Tel:

Fax:

Email:

Section Number: Page Number: Point Number:

Query description

Name and signature of authorized person issuing this request for clarification

Signature/Date

Official designation

1 In case of multiple queries, the contact details need not be repeated and only last two rows of the above format (table) are to be furnished for the subsequent queries.

2 Please indicate the preferred method and address for reply.

3 Please use email or softcopy as a preference but forward hard copy confirmations.


Strictly Confidential Annex 9: Proposed Team Profile 1

Annex 9: Proposed Team Profile

Sr No

Name of Proposed Project Manager/ Team leaders /Proposed Team members

Professional qualifications

Certifications / Accreditations

Banking Solutions expertise (Mention if he/she has worked in Banks earlier) In terms of years and areas of expertise

IT Expertise In terms of years and areas of expertise

Number of similar assignments involved In Public Sector Unit/ Public Sector Banks/ Large Government Department

Documentary proofs are to be enclosed to substantiate the claims made.

Place:

Date: Seal and signature of the bidder


Strictly Confidential Annex 10: Bidder Details 1

Annex 10 – Bidder Details BIDDER

1 The registered name of the bidding company

2 Business address for Location correspondence Street Locality City Pin Code Country Telephone Facsimile Email Other

3 CONTACT NAME OF THE BIDDER

4 CONTACT’S POSITION WITH BIDDER

5 Contact addresses if Location different from above Street Locality City Pin Code Country Telephone Facsimile Email Other 6 BUSINESS STRUCTURE

7 BID COMPANY’S REGISTERED

ADDRESS

8 Details of company registration

9 Names of Directors Chairman President/Managing Director

Directors

10 Include a structure chart reflecting the organization Structure


Annex 11: Undertaking Accepting Escrow Agreement Date

To,


Dear Sir,

Subject: Escrow Agreement for Implementation of Audit Management and Risk Monitoring System (AMRMS) to be implemented in the Reserve Bank of India

Having examined the Tender Document, we, the undersigned, accept the following:

(a) Within 30 Business Days from the Acceptance Date, XXX shall deposit the

Software in human readable form and such other material, instructions and

documentation (including updates and upgrades thereto and new versions

thereof) as are necessary to compile or otherwise generate the then current

version of the Software as supplied to the Bank (herein after referred to as

“Escrow Material”) in escrow with a suitable escrow agent jointly appointed

by the Parties (hereinafter referred to as “Escrow Agent”) under the terms of

a tripartite escrow agreement to be executed between the Bank, XXX and

Escrow Agent. The Parties hereby agree that all costs incurred in connection

with the escrow shall be borne by the Bank, other than the travelling and

other expense of XXX Personnel.

(b) Escrow Material shall further consist of all information in human readable form

necessary to enable a reasonably skilled programmer or analyst to maintain

and /or enhance the program(s) and that, without prejudice to the generally of

the foregoing, the source shall contain all listing of code, programmer’s

comments, logic manual and flowcharts.

(c) The Escrow Material shall be released to the Bank for its own use or that of

its Affiliates and become the property of the Bank in the event of : Strictly Confidential Annex 11: Undertaking Accepting Escrow Agreement 1


i. Termination of this Agreement for material breach of the terms of this

Agreement by XXX or in the event of the occurrence of an Insolvency

Event of XXX; or

ii. XXX ceasing, or giving notice of intention to cease to provide maintenance

or technical support service for the Software as required under this

Agreement or corresponding agreements for AMC and ATS.

The parties agree that they shall cause the Escrow Agent to release the

Escrow Material within 10 Business Days of receipt of written demand from

the Bank.

(d) XXX shall cause the Escrow Material to be kept current with the most recent

release of the Software for as long as the Bank contracts with XXX for

Software maintenance, within 10 Business Days of the installation of the said

release. The Escrow Material shall at all times include the last three versions

of the Software utilized in the Project.

(e) The Bank may require, with 30 Business Days written notice, that XXX

demonstrates the correctness of the Escrow Material by actually compiling

the contents thereof on a suitably configured system to be provided by the

Bank, and XXX shall remedy any deficiencies noted through such an exercise

within 10 Business Days.

(f) Excepting where Escrow Material or part thereof, is released to the Bank in

furtherance of Sub-Clause 10 (c) above, upon the expiry of this Agreement,

the Escrow Material shall be released in favour of XXX and the Bank shall

have no further claim thereto.

Dated this …………………………. Day of …………………..2016

……………………………………………. …………………………………………….


Duly authorised to sign the Tender Response for and on behalf of:

……………………………………………………………………………………………………… ………………………………………………………………………………………………………


Seal/Stamp of Tenderer

Strictly Confidential Annex 11: Undertaking Accepting Escrow Agreement 2


Witness name:

………………………………………………………

Witness address:

………………………………………………………

……………………………………………………...

Witness signature:

…………………………………………………

Strictly Confidential Annex 11: Undertaking Accepting Escrow Agreement 3


Annex 12: Functional Requirement The Bidder may respond to the below questionnaire keeping the following in mind

• Off the Shelf – If the proposed system meets the requirement completely or If the requirement can be fulfilled by changes from front end (without any additional codding) – without code changes in the proposed system

• Customisable – If the requirement can be fulfilled but some coding and changes are required in the proposed system

• Not Possible – If the requirement cannot be met by the proposed system

For detailed information of the system, please refer Section 6 of the RFP

REQUIREMENTS Off the Shelf (5 Marks) / Customisable (3 Marks)/ Not Possible (0 Mark)

1. Planning 1.1 Provision for preparation of Audit Calendar 1.2 Provision for tracking of status of the Audit Plan

(Continuous / Periodic)

1.3 Provision for populating / editing / deleting / updating / aggregating / disaggregating the checklist for audits

1.4 Provision of linking of the checklist to the Risk Registers 1.5 Provision for calculation of man-days, allocation of

suitable resources and allocation of work areas to auditors dynamically based on pre-inputed data.

1.6 Provision for preparation of pre audit data / information / pre inspection study

1.7 Provision for uploading Inspection related instructions / circulars

1.8 Provision to email / SMS PIOs / IO / Auditee depending on various input parameters

1.9 Ability of system to maintain old reports / checklist / RRs and updation and tagging of the same at the time of Mergers / Splits / Creation of New Offices / Departments / Renaming of Departments, New Audits / Audit Types

1.10 Provision for single or multiple assignments to auditors, mapping of audit areas, changes or swapping of audit areas, etc.

2. Audit Input 2.1 Provision to upload various types of audit observations

with necessary classifications / parameters / grouping, marking to one or more auditees.

2.2 Provision to upload work papers / draft reports by auditors

2.3 Ability in the system to upload the entire audit report at once or key in individual observations para-wise

Strictly Confidential Annex 12: Functional Requirement


2.4 Provision for Maker / Checker concept for audit Input 2.5 Provision to alert to the PIO on submission of report by

IO and final submission to be done by PIO only

2.6 Capability to use Digital Signature at the time of uploading of reports

2.7 Provision for automatic generation of Risk Rating of the Auditee based on pre-defined criteria

2.8 Provision to generate letters to the Head of Auditee Office / Top Management as per pre-defined template

2.9 Provision for Data Input at the auditee office level for conduct of any local inspections / audit

3. Audit Output/Reports 3.1 Provision to generate standard/ ad-hoc MIS reports on

various parameters across various audits

3.2 Facility of drag & drop facility to add a new column or field in a User-friendly manner

3.3 Facility of viewing and downloading of the various reports as per assigned roles and privileges.

3.4 Provision to download of report in Word, Excel, PDF or any other pre-determined format

4. Compliance Monitoring 4.1 Provision to submit compliance by Nodal Officer / Head

of Auditee Office through AMRMS with the functionality of authentication by Digital Signature as well

4.2 Provision for Nodal officer at auditee Office/ location to send / receive all the audit compliances through AMRMS itself.

4.3 Provision to track previous compliances, whether rejected / accepted, along with the comments of ID

4.4 Provision to simultaneously mark any auditee observation to more than one Auditee Office / BU

4.5 Provision for Maker / Checker principle for compliance monitoring at ID

4.6 Provision for specifying what type of compliance / para can be accepted / closed at what level.

4.7 Provision to track the time period requested by the auditee in submission of compliance.

4.8 Facility to search in compliance / reports / findings in terms of Departments / Offices / Areas or any other relevant parameters

4.9 Provision to view / generate compliance status by ID / Auditee Office

4.10 Provision to send alert to various stakeholders through SMSs/emails

4.11 Dashboard for list of observation and report generation thereof - Severity wise, Risk Category wise, Age wise, Open / Close status wise, BU/ Auditee Office wise etc. Create flexible Views user-wise to view Audit Information



5. Monitoring of ARMS / CB/ CCB/ EDC/ ITSC and other meetings at Inspection Dept, CO

5.1 Provision for agenda and report preparation for Board / Committee meetings

5.2 Provision for capturing the Minutes, acknowledgment , compliance of the meeting through AMRMS itself

5.3 Provision to track the compliance status of the action points

6. Risk Monitoring 6.1 Provision for populating / editing / deleting / updating /

aggregating / disaggregating the Risk Register (RR)

6.2 Calculation of risk rating / Heat-Maps on a pre-defined algorithm

6.3 Provision to cross compare RR and Checklists of ID 6.4 Provision for the ID Auditors to provide inputs for the

Risk Register.

6.5 Provision for sending Notification to ID and concerned Department / Office when update / modifications are made to RR

7. Incident Reporting 7.1 Provision to upload of Incident Reports by using the

Incident Reporting Template (IRT)

7.2 Provision to report, accept, close an incident by authorized users only

7.3 Provision to generate MIS / Ad-hoc reports of reported incidents, based on one or more selected parameters

8. External Audit (Concurrent Audit / Statutory Audit / IS/IT Audit )

8.1 Provision for external auditors to submit their Audit Report / Findings

8.2 Provision for respective Auditee offices / ID to submit / accept and process the compliance

8.3 Facility of generation of MIS reports 9. CSAA - Control Self-Assessment Audit 9.1 Provision for Auditee Department to upload / modify

their own checklists

9.2 Provision for Auditee Location to assign personnel to conduct CSAA

9.3 Provision for Submission of compliance by respective Sections / Departments in Auditee Office and the processing thereof

9.4 Provision for ID to oversee conduct of CSAA and generation of MIS reports

10. Document Management 10.1 Facility for Document Management functionalities such

as version control, auditing, publishing, audit trail of user activities for each change in the document

10.2 Provision to upload various types of files – Word / Excel / PDF/ JPEG / Emails etc



10.3 Provision for Virus / Malware/ Spyware Check before uploading of any file to the system

10.4 Capability to integrate the AMRMS application with the Bank’s proposed Electronic Data Management System (EDMS) application

11. User Management 11.1 Availability of Standard User Management features like:

Creation/ amendment/ suspension/ deletion of users/rights, password rest/user unlocking etc.

11.2 Authorization matrix for providing privileges to the users by mapping them to specific roles

11.3 Provision of Online Application form submission by users for user creation request for access to the system

11.4 Provision to have own users database 11.5 Functionality to integrate with the existing single sign-on

feature of the Bank

11.6 Capability of AMRMS to support around 1000 users concurrently for all modules within the response time of 2-3 secs

12. Backup and Archiving 12.1 Provision for taking backups of the systems database

and the application the same

12.2 Provision for easy retrieval of the Backed-up Data (Both Application and the Database) with least amount of manual intervention with no Data Loss events

13. Activity log management 13.1 Full audit trail of all operations by the users including

any changes from backend

14. Security Requirements 14.1 Provision for Two factor Authentication wherever

required

14.2 Capability of exception handling 14.3 Sanitization of all inputs into the system 15. Other Requirements 15.1 Offline Mode -

Provision to work in off-line mode with regards to the data entry / report preparation in the application itself with ability to sync data when online.

15.2 User Configurable Dashboard – Provision for configurable Dashboard facility with user friendly menus as per users access rights.

15.3 Analytics – Capability to integrate data from other applications running in the Bank like CBS, DMIS, ec. and throw up MIS / exception reports

15.4 Provision for standardization of checklist / Risk Registers of various Offices / Departments by cross comparison of audit observations across RBI Offices.



15.5 Provision to analyse checklist / incident reports / inspection reports / RR over a period of time / data and throw up areas where similar risks / procedural errors are happening.

15.6 Bi-Lingual Support Provision in the system to support input of data in bi-lingual nature (English / Hindi)

15.7 Workflow Management – Ability to change the workflow in any process in Auditee Office / ID/ RMD

15.8 Maintenance of Legacy Data Facility to Browse / View / Download / Upload all legacy data.

15.9 Library Provision for Library creation of all identified processes / reports/ findings / Risks etc, e.g. Audit Report, Checklist, RR, Audit Calendar etc.

15.10 Provision for a library of international best practices e.g. ISO 27001, COBIT, ITIL standards etc.

15.11 Provision for all details regarding data dictionary and validation tools to be readily made available

15.12 Help : Provision for On-line Help / Tutorial and e-learning training module to be available

16 Technical Support Yes (2 Marks) / No (0 Mark)

16.1 Hardware independence of the application Yes/No

16.2 Software (Web/App server, database, middleware) compatibility and portability with standard hardware infrastructure

Yes/No

16.3 Ability to support & implement session timeout Yes/No

16.4 Availability of Analytical Tools to monitor the Hardware / Server within the Application like usage details, CPU / Bandwidth usage etc.

Yes/No

16.5 Ability of application to adopt Limited Data Transfer framework

Yes/No

16.6 Applications to be free from tech vulnerabilities as per OWASP

Yes/No

16.7 Accessibility to the application is browser and OS independent (preferably).

Yes/No

16.8 Whether after successful login all modules will available to 1000 concurrent users within span of 2-3 secs in terms of response time

Yes/No

16.9 Ability to provide confidentiality, integrity and authentication using benchmark / standard tool / method

Yes/No

16.10 Ability to integrate with Active Directory/IPv6 Yes/No



16.11 Availability of plug-ins with other collaboration applications (MS-office, MS Project, e-mail etc)

Yes/No

16.12 Application to be scalable to add new modules Yes/No 16.13 Application to be scalable to support additional users

beyond the numbers indicated in the RFP document Yes/No

16.14 Bidder assurance for Change Management request, if required

Yes/No

16.15 Bidder assurance to share IPR / deposit the source code / enter into a escrow agreement depending on the case

Yes/No

16.16 Assurance to Migrate the Legacy Data before “Go-Live” Yes/No

16.17 Whether Bidder is capable and willing to provide assurance of Warranty and AMC for 3 and 4 years respectively

Yes/No

[Total Maximum score would be converted to an equivalent of 24 marks for Evaluation of Functional Requirements as mentioned in Chapter 12.3 of the RFP Document.]



Annex 12 A: Additional Details to be furnished by the Bidder

The Bidder should provide the following Additional Details about the proposed Application

A. Other Requirements 1 Technical Details required Details

1.1 Application Technical Architecture - Modular/ Parameterisable / Other - Please Specify

1.2 Bandwidth required (incl. at server end) to run the application smoothly –Bidder to specify

.. KBPS max., .. kbps normally

2 Scalability & Security 2.1 No. of Concurrent users application can scale to

– Bidder to specify number

3 Change Management 3.1 Cost Estimation: Methods of Efforts estimation 4 Resources required 4.1 Usage of Bank’s existing resources like

ORACLE Licence Yes/No

4.2 Limitations of the applications: like features that is not possible, dependence on proprietary H/W, S/W, particular settings in browser etc.

4.3 Assurance to comply with the IS Policy of the Bank

Yes/No

B. Bidder’s Requirement Sheet Sr. No Particulars Measure Remarks

1 Hosting Space Requirements (DC)

2 Hosting Space Requirements (DR)

3 Hosting Power Requirements (DC)

4 Hosting Power Requirements (DR)

5 No. of LAN ports required at DC

6 No. of LAN ports required at DR

7 (Any other requirements Hardware / Software ) – Please specify



C. General Information General Information to be

furnished by the Bidder

1 Based on requirements listed in the overall RFP, what is the percentage of requirements already available in the application and what would need to be customize/developed as part of deliverables

1) __% age available 2) __ % age would be

developed. 3) __ % Not possible

2 Capability to provide the Auditee Office module for the identified functionalities.

Yes/No

3 Training Requirement a) Administrator User b) Auditors c) Compliance Users d) RMD Users e) Auditee Offices Users

_______ Hrs _______ Hrs _______ Hrs _______ Hrs _______ Hrs

D. Any additional Technical Details the Bidder would like to provide may be appended.



Strictly Confidential Annex 13: Compliance Certificate Commercial Bid 1

Annex 13: Compliance Certificate Commercial Bid

Date To,


Dear Sir,

Subject: Tender dated DD, MM, YYYY COMMERCIAL BID for the Implementation of Audit Management and Risk Monitoring System at the Reserve Bank of India

Having examined the Tender Document, we, the undersigned, offer to supply, deliver,

implement and commission ALL the items mentioned in the ‘Request for Proposal’ and

the other schedules of requirements and services for the Bank in conformity with the

said Tender Documents for a total bid price of:

Indian Rupees in words and figures.

We attach hereto the Tender Commercial Response as required by the Tender

document, which constitutes our bid.

We undertake, if our Tender is accepted, to adhere to the implementation plan put

forward in our Tender Response or such adjusted plan as may subsequently be

mutually agreed between us and the Reserve Bank of India or its appointed

representatives.

If our Tender Response is accepted, we will obtain a performance bank guarantee in

the format given in the Tender Document, issued by a scheduled commercial bank in

India, for a sum equivalent to 10% of the contract sum for the due performance of the

contract.

We agree to abide by this Tender Response for a period of 180 days from the last day

of bid submission and it shall remain binding upon us, until within this period a formal

contract is prepared and executed, this Tender Response, together with your written



acceptance thereof in your notification of award, shall constitute a binding contract

between us and will initiate the formation of a separate contract in respect of

maintenance and support services after expiry of the warranty period.

We agree that you are not bound to accept the lowest or any Tender Response you

may receive. We also agree that you reserve the right in absolute sense to reject all or

any of the goods/products specified in the Tender Response without assigning any

reason whatsoever. We also understand that commercial bid decision will be taken on

the basis of ‘Reverse Auction’ as described in the RFP document, and in case if the

award is made to us, the final commercial bid as per Annex 14 will be submitted to the

Bank within 2 working days.

It is hereby confirmed that I/We are entitled to act on behalf of our corporation/ company

/ firm/ organization and empowered to sign this document as well as such other

documents which may be required in this connection.

We undertake that in competing for and if the award is made to us, in executing the

subject Contract, we will strictly observe the laws against fraud and corruption in force in

India namely “Prevention of Corruption Act 1988”.

Dated this …………………………. Day of …………………..2016

……………………………………………. …………………………………………….


Duly authorised to sign the Tender Response for and on behalf of:

………………………………………………………………………………………………………

………………………………………………………………………………………………………


Seal/Stamp of Tenderor

Witness name: ……………………………………………………… Witness address: ………………………………………………………



……………………………………………………... Witness signature: …………………………………………………


Strictly Confidential Annex 14: Commercial Bid Format

Annex 14: Commercial Bid Format (On letterhead of the bidder)

Sr No

Details Amount in INR

1

Project Cost (A) Includes all cost related to the implementation of AMRMS excluding Hardware infrastructure cost

1. Perpetual License Cost 1.

2. Customization / Development/ Implementation cost

2.

3. Data Migration Cost

3.

4. Training Cost 4.

5. Any other Software cost 5.

6. Any other cost not included above 6.

Sub Total (A)

______________

2 Application Support Cost (B) (1) On-Site Facility support in the first year during 3

years Warranty period.

(2) Off-Site Facility support in the 2nd and 3rd year

during 3 years Warranty period. @

(3) Off-Site Facility support during AMC period for 4

years post Warranty period. @

(1) ………. (2) ………….x 2 (3) ………….x 4

Sub Total (B)

______________

3 Total Cost of Ownership (TCO) (A + B)

{Charges for Change Management (Man-hour per day) ______________________

(Will be Applicable for all 7 years of the Contract. However for commercial bid

evaluation purpose this will not be considered). }


Strictly Confidential Annex 14: Commercial Bid Format

Total Cost of Ownership in Figures & Words

___________________________________________________________________

The fees payable by RBI to Bidder shall be inclusive of all costs such as

insurance, taxes (including service tax, as per the rates applicable), custom duties,

octroi, levies, cess, transportation, installation, (collectively referred to as “Taxes”)

that may be levied, imposed, charged or incurred and RBI shall pay the fees due

under this RFP and subsequent agreement after deducting any tax deductible at

source (“TDS”), as applicable. Any variation in Government levies/ taxes/ VAT/ cess/

excise/ custom duty / octroi etc. which has been included as part of the price will be

borne by the Bidder.

Authorized Signature


Strictly Confidential Annex 15: Submission Check List 1

Annex 15: Submission Check List The bidder has to ensure that the following have been submitted as a part of the RFP

submission process.

Failure to provide any of the documents as detailed below could lead to the

disqualification of the bidder from the bid.

Functional RFP Annexure Name

Content / Details Submitted (Y/N)

NDA Non-Disclosure Agreement

Demand Draft for Bid Security (Ernest Money Deposit)

Annex 1 Pre- Qualification Criteria

Annex 3 Work Plan Format

Annex 4 Conformity of Soft Copy

Annex 5 Bidder Undertaking

Annex 6 Experience Details

Annex 7 Confirmation to Deliver

Annex 8 Pre-Bid Query Format

Annex 9 Proposed Team Profile

Annex 10 Bidder Details

Annex 11 Undertaking Accepting Escrow Agreement

Annex 12 Functional Requirements

Commercial Bid Documents The following documents need to be provided by the Bidder for the Commercial Bid in a

separately sealed cover.

Annexure Name

Content / Details Submitted (Y/N)

Annex 13 Compliance Certificate Commercial Bid

Annex 14 Commercial Bid Format


Strictly Confidential Annex 16: Abbreviation List 1

Annex 16 – Abbreviation List AMRMS Audit Management and Risk Monitoring System AMC Annual Maintenance Contract API Application Programming Interface ARMS Audit & Risk Management Sub-Committee BCP Business Continuity Plan BO Banking Ombudsman Offices BOM Bill of Material BU Business Unit CBS Core Banking Solution CA Concurrent Audit CB Central Board CCB Committee of the Central Board CHRS Comprehensive Human Resources Management System CO Central Office COBIT Control Objectives for Information and Related Technology COD Central Office Department COMORS Compliance Monitoring and Reporting System CSAA Control Self Assessment Audit DMIS Document Management and Information System DC Data Center DRC Disaster Recovery Center EDC Executive Directors’ Committee EDMS Electronic Data Management System EKP Enterprise Knowledge Portal ESCAMS Enterprise wide Smart Card Based Access System EOI Expression of Interest ERM Enterprise-wide Risk Management HOD Head of Department HRMS Human Resources Management System ICCOMS Integrated Computerized Currency Operations and Management System ID Inspection Department IES Integrated Establishment System IRT Incident Reporting Template ISA Information Systems Audit ISMS Information Security Management System ISO International Organization for Standardization ITIL Information Technology Infrastructure Library ITSC Information Technology Sub- Committee MIS Management Information System NDA Non-Disclosure Agreement OEM Original Equipment Manufacturer OWASP Open Web Application Security Project PIO Principal Inspecting Officer


Strictly Confidential Annex 16: Abbreviation List 2

POC Proof of Concept RBI Reserve Bank of India RBIA Risk Based Internal Audit RFP Request for Proposal RIF Resource Interchange Format RMC Risk Monitoring Committee RMD Risk Monitoring Department RO Regional Office ROC Registrar of Companies RR Risk Registers RTGS Real Time Gross Settlement SIT System Integration Testing SLA Service Level Agreement SMS Short Messaging Service SRS System Requirements Specifications TE Training Establishment TA Technical Audit TTR Time to Recovery UAT Users Acceptance Testing VA-PT Vulnerability Assessment and Penetration Testing