Amrms250116 A

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 E mail.
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.
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]

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. 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 February 01, 2016
clarification from bidders
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 / Inspection Department, Central Office

Presentations
Conference Room,
C-7, 7th Floor,
Bandra Kurla Complex, Bandra East
Mumbai – 400 051
II Any Queries to be mailed to isaudit@rbi.org.in
1
Confidential and for Restricted Use
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
2
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.
3
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.
4
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
5
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
6
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.
7
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
8
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.
9
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.
10
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.
11
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:
12
• 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.
13
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 Win 2000/2008 server and web
based clients based clients
Software Application software developed in PeopleSoft HCM version 8.9
Java and Oracle Database 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 Memory ‐ 16 GB
Vendor ‐ Genuine Intel Vendor ‐ Genuine Intel
Model Name ‐ Intel(R) Xeon(R) Model Name ‐ Intel(R) Xeon(R)
CPU X5260 @ 3.33GHz CPU X5260 @ 3.33GHz
No of Processors –4 No of Processors –4
CPU Cores – 2 CPU Cores – 2
14
O.S. Windows XP Red Hat Enterprise Linux 4 (RHEL

4)
Software Front end –J2EE, Back end Oracle Oracle Application Server
data base 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 CBS, ESCAMS, DMIS
with other
systems
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.
15
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 /
16
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
17
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.
18
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.
19
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
20
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
21
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.
22
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.
23
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.
24
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
25
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
26
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
27
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
28
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
29
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
30
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.
31
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.
32
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
33
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
34
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.
35
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
36
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.
37
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
38
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.
39
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
40
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
41
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
42
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.
43
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).
44
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 Within 30 days from calendar date
SRS/ Control Specification Document, Process of Signing of the Agreement
Re-engineering Report (BPR) and Finalization
and signing off all the above.
Deployment
3. Customization / Development of AMRMS Within 60 days from calendar
date of Signing off of the SRS
4. - Setting up of Test Environment Within 10 calendar days from

- Data Migration Customization / Development of
- SIT & UAT AMRMS
45
5. Other Deliverables Within 10 calendar days from

- Training of all Users (i.e. ID, RMD, Auditee date of UAT
Units)
- On-line / e-learning training Modules
- User Manuals & Operation Manuals
- Any other Documentations
6. Complete implementation of the project i.e. Go- Within 20 calendar days of
Live 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) On-going for 7 Years
- Change Management on need basis, if required.
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.
46
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.
47
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.
48
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
49
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. Milestone Payment
No
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- 20% of the Project Cost
line tutorials, documentations, manuals etc.
5. Complete Implementation and “Go-live” of the 15% of the Project Cost
project
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
50
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
51
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,
52
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.
53
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
54
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.
55
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.
56
Table 7: Penalties
Criticality 
Elapsed Time of
unavailability for end Level 1 (INR) Level 2 (INR)
users
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 1.25 times man hour/day rate
charged for change management charged for change management
by the bidder. by the bidder.
Greater than 24 hours 1.75 times man hour/day rate 1.5 times man hour/day rate
charged for change management charged for change management
by the bidder. 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.
57
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:
58
Principal Chief General Manager

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.
59
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.
60
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.
61
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
62
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

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.
63
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
64
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.
65
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
66
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.
67
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.
68
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)
69
• 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.
70
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
71
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.
72
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.
73
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 Scoring Criteria Marks Awarded

Member
Project Should have 10 • 10 marks for experience in more than one AMRMS like
Manager years of experience implementations as Project Manager in a Bank in India
in Project • 5 marks for experience in one AMRMS like
Management with a implementation as Project Manager in a Bank in India
minimum of one • 0 mark for not fulfilling the criteria
AMRMS like
implementation as
Project Manager
Team Should have more • 5 marks for experience in more than one AMRMS like
Leader(s) than 5 years of Implementations in a Bank in India
experience in • 3 marks for experience in one AMRMS like
Project Management implementation in a Bank in India
with a minimum of • 0 mark for not fulfilling the criteria
one AMRMS like
implementation as
Team Leader
Team Should have at least • 5 marks for experience in more than one AMRMS like
Members 3 years’ experience Implementations in a Bank in India
at least 2 in AMRMS like • 3 marks for experience in one AMRMS like
in number implementations as Implementation in a Bank in India
team members. • 0 mark for not fulfilling the criteria
74
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 35% 21
Annex 12
75
• Approach, Methodology & 6

Implementation (10%) 4.5
• Product Walkthrough (7.5%)
35%
• Team Composition (TC) (7.5%) 4.5
• Past Experience (PE) in Banking Sector 6
(10%)
Demonstration of the Product based on 30% 18
Proof of Concept (PoC) as per criteria
furnished in the RFP Document
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.
76
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
77
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.
78
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.
79
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.
80
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.
81
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.
82
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
83
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
84
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
85
• 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.
86
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.
87
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:
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.
88
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
89
• 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.
-----------------------------------------------------------------------------------------------------
90
RFP For Audit Management and Risk Monitoring System, RBI
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. REQUIREMENTS YES / NO

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 1: Pre-Qualification Criteria

Annex 2: Performance Bank Guarantee

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
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.
Strictly Confidential Annex 2: Performance Bank Guarantee 1

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.

Annex 3: Work Plan Format

Detailed Work Plan (Project Plan) and Personnel Schedule
Weeks
Serial Task 1 2 3 4 5 6 7 8 9 10 11 12 13 14 …..
No
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
* 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 3: Work Plan Format 1

Annex 4: Conformity of Soft Copy

(On letterhead of the bidder)

Principal Chief General Manager [Date]
C-7, 8th Floor,
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 4: Conformity Of Soft Copy 1

Annex 5: Bidder Undertaking Letter

Date:
From:
To
C-7, 8th Floor,
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 5: Bidder Undertaking Format 1

Annex 6 – Experience Details

Part A
Experience of the Applicant of implementing an AMRMS like solution in a Bank in India
Name,
Name Month Period of Period of
Sr. Address and Contact
/Description of and Year of Implementation Warranty / Remarks
No. details of
the Product the order AMC
the clients From To
Part B
Experience of the Applicant of implementing an AMRMS like solution in any financial institution
Name,
Name Month Period of Period of
Sr. Address and Contact
/Description of and Year of Implementation Warranty / Remarks
No. details of
the Product the order AMC
the clients From To
Strictly Confidential Annex 6: Experience Details

Annex 7: Confirmation to Deliver

(On letterhead of the Bidder)
To,
C-7, 8th Floor,
Mumbai – 400 051,
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.
Strictly Confidential Annex 7: Confirmation To Deliver 1

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:
…………………………………………………

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, Chief General Manager

faxed or emailed to:
-- address, email id and fax
number given in the
schedule
Name of Organization Full formal address of the Tel:

submitting request organization including
phone, fax and email points Fax:
of contact
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 8: Pre Bid Query Format 1
Annex 9: Proposed Team Profile
Sr Name of Professional Certifications Banking Solutions expertise IT Expertise In terms of Number of similar
No Proposed qualifications / (Mention if he/she has years and areas of assignments involved In
Project Accreditations worked in Banks earlier) In expertise Public Sector Unit/ Public
Manager/ terms of years and areas of Sector Banks/ Large
Team leaders expertise Government Department
/Proposed
Team
members
Documentary proofs are to be enclosed to substantiate the claims made.
Place:
Date: Seal and signature of the bidder
Strictly Confidential Annex 9: Proposed Team Profile 1

Annex 10 – Bidder Details

BIDDER
The registered name of
1
the bidding company
2 Business address for Location
correspondence Street
Locality
City
Pin Code
Country
Telephone
Facsimile
Email
Other
CONTACT NAME OF THE
3
BIDDER
CONTACT’S POSITION
4
WITH BIDDER
5 Contact addresses if Location
different from above Street
Locality
City
Pin Code
Country
Telephone
Facsimile
Email
Other
6 BUSINESS STRUCTURE
BID COMPANY’S
7
REGISTERED
ADDRESS
Details of company
8
registration
Names of Directors Chairman President/Managing Director
9 Directors
Include a structure chart

10 reflecting the organization
Structure
Strictly Confidential Annex 10: Bidder Details 1

Annex 11: Undertaking Accepting Escrow Agreement

Date
To,
C-7, 8th Floor,
Mumbai – 400 051,
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

Witness name:
………………………………………………………
Witness address:
………………………………………………………
……………………………………………………...
Witness signature:
…………………………………………………

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) Yes/No

compatibility and portability with standard hardware
infrastructure
16.3 Ability to support & implement session timeout Yes/No
16.4 Availability of Analytical Tools to monitor the Hardware / Yes/No

Server within the Application like usage details, CPU /
Bandwidth usage etc.
16.5 Ability of application to adopt Limited Data Transfer Yes/No
framework
16.6 Applications to be free from tech vulnerabilities as per Yes/No
OWASP
16.7 Accessibility to the application is browser and OS Yes/No
independent (preferably).
16.8 Whether after successful login all modules will available Yes/No
to 1000 concurrent users within span of 2-3 secs in
terms of response time
16.9 Ability to provide confidentiality, integrity and Yes/No
authentication using benchmark / standard tool / method
16.10 Ability to integrate with Active Directory/IPv6 Yes/No

16.11 Availability of plug-ins with other collaboration Yes/No

applications (MS-office, MS Project, e-mail etc)
16.12 Application to be scalable to add new modules Yes/No
16.13 Application to be scalable to support additional users Yes/No
beyond the numbers indicated in the RFP document
16.14 Bidder assurance for Change Management request, if Yes/No
required
16.15 Bidder assurance to share IPR / deposit the source code Yes/No
/ enter into a escrow agreement depending on the case
16.16 Assurance to Migrate the Legacy Data before “Go-Live” Yes/No
16.17 Whether Bidder is capable and willing to provide Yes/No
assurance of Warranty and AMC for 3 and 4 years
respectively
[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 .. KBPS max., .. kbps
the application smoothly –Bidder to specify 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 Yes/No
ORACLE Licence
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 Yes/No
Bank
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, 1) __% age available
what is the percentage of requirements already 2) __ % age would be
available in the application and what would need developed.
to be customize/developed as part of 3) __ % Not possible
deliverables
2 Capability to provide the Auditee Office module Yes/No
for the identified functionalities.
3 Training Requirement
a) Administrator User _______ Hrs
b) Auditors _______ Hrs
c) Compliance Users _______ Hrs
d) RMD Users _______ Hrs
e) Auditee Offices Users _______ Hrs
D. Any additional Technical Details the Bidder would like to provide may be
appended.

Annex 13: Compliance Certificate Commercial Bid

Date
To,
C-7, 8th Floor,
Mumbai – 400 051,
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
Strictly Confidential Annex 13: Compliance Certificate Commercial Bid 1

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:
…………………………………………………

Annex 14: Commercial Bid Format

Sr Details Amount in INR

No
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 2.
cost
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 (1) ……….
years Warranty period.

(2) Off-Site Facility support in the 2nd and 3rd year (2) ………….x 2
during 3 years Warranty period. @
(3) Off-Site Facility support during AMC period for 4
(3) ………….x 4
years post Warranty period. @
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 14: Commercial Bid Format

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 Content / Details Submitted
Name (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 Content / Details Submitted
Name (Y/N)
Annex 13 Compliance Certificate Commercial Bid
Annex 14 Commercial Bid Format
Strictly Confidential Annex 15: Submission Check 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 1

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
Strictly Confidential Annex 16: Abbreviation List 2

Amrms250116 A

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Amrms250116 A

Загружено:

Авторское право:

Доступные форматы

RFP for Audit Management and Risk Monitoring System, RBI

Reserve Bank of India

Request for Proposal

Audit Management and Risk Monitoring System

(January 25, 2016)

Disclaimer & Disclosures

Draft of the NDA is as under.

(Letter head of the bidder)

Strictly Private and Confidential

Principal Chief General Manager [Date]

o To our partners/directors and employees who have a bona fide need

Training, Testing, Commissioning, Warranty and Maintenance of

Authorized Signatory and Stamp of Company

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

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

Table1: Time frame for the Overall Process

I Place of opening of Bids/ Meetings / Inspection Department, Central Office

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

Diagram 1 – Audit and Risk Management Structure

2.2 Purpose of the Document

3.1 Annexure Seeking Response for Evaluation

Annex 14 Commercial Bid Format

3.2 Definition of terms

A detailed list of abbreviations is provided in Annex 16.

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

4.1 Overview of Audit Universe

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

Streams of Inspection in the Reserve Bank

Risk Based Internal Audit (RBIA)

Information System Audit (ISA) / Technology Audit

Vulnerability Assessment and Penetration Testing (VA-PT) Audit

Concurrent Audit (CA)

Control Self-Assessment Audit (CSAA)

Statutory Audit (Limited Role)

Compliance, Follow-up and Reporting

ARMS / EDC/ ITSC/ CB/ CCB Meetings

Current Audit Infrastructure

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

• Prepares a broad risk management framework and also formulates and

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

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

Application III Application IV

Hardware HP Superdome Flap barrier system , Readers,

Software Intellect CBS Back end‐ Oracle data base. The

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

5.2 Existing Data Centre set-up

5.3 Software Licenses with the Bank

5.4 AMRMS Hardware Infrastructure

6 Requirement from AMRMS

6.2 Detailed Scope of the Project:-

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

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

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

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

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

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

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

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

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

6.2.2 Audit Input:-