RFP No. - 1-CMT/BMB/2013-14 · performance of all obligations under the RFP irrespective of the failure or inability of the subcontractor chosen by the ... The Bank‘s decision with

1

RFP No. - 1-CMT/BMB/2013-14

Date – 17th July 2013

Request for Proposal

For selection of IT Vendor for implementing Core Banking Solution based on the Application Service Provider

(ASP) model in the women focused public sector bank – proposed to be set up by the Government of India

2

Important Information

1. The management team appointed by the Government of India (the ―Core Management Team‖ or ―CMT‖) for

coordinating the processes of establishment of the proposed women focused public sector bank (herein referred to

as the ―Bank‖), invites Request for Proposal (―RFP‖) from OEMs of CBS Solutions for implementing Core

Banking Solution (―CBS‖) on an Application Service Provider (ASP) model including procurement,

customization, installation and maintenance of CBS in the Bank. The OEM may include a system integrator as a

sub-contractor with the prior approval of the Bank. However, the IT Vendor shall be solely responsible for

performance of all obligations under the RFP irrespective of the failure or inability of the subcontractor

chosen by the IT Vendor to perform its obligations.

2. This document should not be reissued or copied or used either partially or in full without explicit permission of

the Bank.

3. The Bank also reserves the right to accept or reject any or all the responses to this RFP without assigning any

reasons whatsoever.

4. The Bank will not be responsible for any delay on the part of the OEMs in obtaining the terms and conditions of

the proposal or submission of the proposal.

5. The last date for submission of proposal is Tuesday, August 6, 2013 by 4:00 p.m. (IST). The proposals should be

submitted in prescribed format (wherever provided) at the prescribed place within the prescribed scheduled

date and time otherwise the same shall not be accepted. No extensions to the timelines will be considered.

6. The information provided by the Bidders in response to this RFP will become property of the Bank, and will not be

returned.

7. The Bank reserves the right to amend, repeal or reissue this RFP at any time.

8. Amendments, if any, will be mailed to each of the shortlisted IT Vendors should the occasion arise. Such

amendments will be binding on all Bidders.

9. The Bank‘s decision with regard to technical bid evaluation and opening of commercial bid will be final.

3

Important Dates

Sr. No Particulars

Dates and Timelines

1 Issuance of RFP document by the Bank Wednesday, July 17, 2013

2 Last date for submission of queries

notifying the Bank of any error, fault,

omission or discrepancy in the RFP

document

Wednesday, July 24, 2013 by 5:00 p.m.

3 Pre- bid meeting Saturday, July 27, 2013, at 11:00 a.m.

Venue:

Punjab National Bank

PNB Pragati Tower,

C-9, G Block, 5th floor,

Bandra Kurla Complex,

Bandra (E), Mumbai - 400 051

4 Last Date of submission of RFP response Tuesday, August 6, 2013 by 4:00 p.m.

5 Technical Bid opening date Tuesday, August 6, 2013, at 5:00 p.m.

4

Definitions

Following terms are used in the RFP to mean:

1. Bank means the women focused public sector bank – proposed to be set up by the Government of India. The

Bank also refers to the Core Management Team, acting on behalf of the Bank, as the case may be.

2. Core Management Team or CMT means the management team appointed by the Government of India for

coordinating the process of establishment of the Bank. The Core Management Team is authorized to enforce the

terms and conditions of delivery including, but not limited to, service level terms as will be agreed between the

Bank and the IT Vendor.

3. SBI Capital Markets or SBICAPS means the Advisor appointed by the Government of India for setting up the

Bank. Any communication addressed to/received by SBI Capital Markets would be deemed to be addressed to

the Bank. SBI Capital Markets would also be deemed to be acting in the capacity of the adviser to the Bank as the

case may be.

4. Site(s) means branch/es, offices or other locations of the Bank, including but not limited to data centers, disaster

recovery (―DR‖) sites etc.

5. IT Vendor or Bidder means the respondent to the RFP document, which shall be an OEM of CBS Solutions, and

shall be a Government Organization/PSU/ PSE/ Public or Private Limited Company

6. RFP or Tender means this Request for Proposal document including all annexures.

7. DC means Data centre, DR / DRC/ DRS means Disaster Recovery Site.

8. CBS means Core Banking Solution including all the peripheral applications (such as internet banking,

mobile banking, financial inclusion module, treasury module, risk management module, forex module, trade

finance module, HRMS module, ALM module, ATM, payment gateway etc.) that will eventually be bundled

with the offerings. The list of peripheral applications is not an exhaustive list and would be based on the Bank‘s

requirements.

9. IT Vendor, Bank shall be individually referred to as ―Party‖ and collectively as ―Parties‖.

This document is meant for the specific use by the IT Vendor interested to participate in the current tendering

process. This document in its entirety is subject to Copyright Laws. The Bank expects the Bidders or any person

acting on behalf of the Bidders to strictly adhere to the instructions given in the document and maintain

confidentiality of information. The Bidders will be held responsible for any misuse of information contained in

the document, and liable to be prosecuted by the Bank in the event that such a circumstance is brought to the

notice of the Bank. By receiving the document, the interested party is subject to confidentiality clauses.

5

Contents

1. Introduction ............................................................................................................................................................................. 7

1.1. Information Provided .............................................................................................................................................................. 7

1.2. For Bidder only ....................................................................................................................................................................... 7

1.3. Disclaimer ............................................................................................................................................................................... 7

1.4. Costs Borne by Bidders ........................................................................................................................................................... 7

1.5. No legal relationship ............................................................................................................................................................... 8

1.6. Bidder‘s obligation to inform itself ......................................................................................................................................... 8

1.7. Evaluation of offers ................................................................................................................................................................. 8

1.8. Errors and Omissions .............................................................................................................................................................. 8

1.9. Acceptance of terms ................................................................................................................................................................ 8

1.10. Confidentiality ........................................................................................................................................................................ 8

2. RFP Response terms ............................................................................................................................................................... 8

2.1. Application Money .................................................................................................................................................................. 8

2.2. RFP closing date ..................................................................................................................................................................... 9

2.3. Submission of RFP response ................................................................................................................................................... 9

2.4. Late RFP policy....................................................................................................................................................................... 9

2.5. RFP Validity period ................................................................................................................................................................ 9

2.6. Requests for information ......................................................................................................................................................... 9

2.7. Notification ........................................................................................................................................................................... 10

2.8. Disqualification ..................................................................................................................................................................... 10

2.9. Eligibility criteria .................................................................................................................................................................. 10

2.10. Tender Process ...................................................................................................................................................................... 10

2.11. Timeframe ............................................................................................................................................................................. 11

3. Project Background ............................................................................................................................................................... 11

3.1. Introduction to the Bank ........................................................................................................................................................ 11

3.2. Business Strategy .................................................................................................................................................................. 12

3.3. IT Strategy ............................................................................................................................................................................. 12

3.4. Volume of transactions, users and accounts- Expected* ....................................................................................................... 14

4. Project Scope ......................................................................................................................................................................... 14

4.1. Project Objective ................................................................................................................................................................... 14

4.2. Project Scope ......................................................................................................................................................................... 14

5. Service Levels overview ....................................................................................................................................................... 28

5.1. Minimum Technical requirements ........................................................................................................................................ 28

5.2. Service Levels ....................................................................................................................................................................... 30

6. Terms and Conditions ........................................................................................................................................................... 32

6.1. General .................................................................................................................................................................................. 32

6.2. Rules for responding to this RFP .......................................................................................................................................... 32

6.3. Commercial Bids ................................................................................................................................................................... 34

6.4. Price Comparisons ................................................................................................................................................................ 35

6.5. Bid Security and Performance Guarantee ............................................................................................................................. 36

6.6. Performance Guarantee ......................................................................................................................................................... 36

6.7. Others .................................................................................................................................................................................... 37

6.8. Terms of Reference ............................................................................................................................................................... 43

6.9. Payment terms ....................................................................................................................................................................... 44

6

7. Responses to RFP .................................................................................................................................................................. 60

7.1. Bid Submission ..................................................................................................................................................................... 60

7.2. Contact details for responding to RFP .................................................................................................................................. 61

7.3. Proposal format ..................................................................................................................................................................... 61

8. Evaluation methodology ....................................................................................................................................................... 64

8.1. Two Bid Process ................................................................................................................................................................... 64

8.2. Technical Bid evaluation ....................................................................................................................................................... 64

8.3. Bid Evaluation ....................................................................................................................................................................... 66

ANNEXURE – 1: CHECKLIST ........................................................................................................................................................ 68

ANNEXURE – 2: COVER LETTER................................................................................................................................................. 69

ANNEXURE – 3: BID SECURITY LETTER (if Bid is submitted in draft/ pay order mode) .......................................................... 70

ANNEXURE – 4: BID SECURITY LETTER (If submitted as a Bank Guarantee) .......................................................................... 71

ANNEXURE – 5: BIDDER‘S PROFILE .......................................................................................................................................... 73

ANNEXURE – 6: FUNCTIONAL REQUIREMENT SPECIFICATION ......................................................................................... 76

ANNEXURE – 7: TECHNICAL PROPOSAL ................................................................................................................................ 151

ANNEXURE – 8: IMPLEMENTATION WORK PLAN (PROJECT PLAN) ................................................................................ 153

ANNEXURE – 9: PROFORMA OF LETTER TO BE GIVEN BY THE IT VENDOR ON ITS OFFICIAL LETTER-HEAD .... 154

ANNEXURE – 10: COMMENTS ON THE TERMS & CONDITIONS, SERVICES AND FACILITIES PROVIDED ............... 155

ANNEXURE – 11: MANUFACTURER AUTHORIZATION ....................................................................................................... 156

ANNEXURE – 12: MANUFACTURER DETAILS ....................................................................................................................... 157

ANNEXURE – 13: PERFORMANCE BANK GUARANTEE FORMAT ..................................................................................... 158

ANNEXURE – 14: FORMAT OF REQUEST FOR CLARIFICATIONS ...................................................................................... 161

ANNEXURE – 15: ELIGIBILITY CRITERIA ............................................................................................................................... 162

ANNEXURE – 16: COMMERCIAL PRICE BID TEMPLATE ................................................................................................... 163

7

1. Introduction

This RFP has been prepared solely for the purpose of selection of an IT Vendor for implementation of Core

Banking Solution under Application Service Provider (ASP) model in the Bank and other applications and maintenance

of the same throughout the period of the contract.

Through this RFP, the Bank invites responses from OEMs of CBS Solutions to propose a contractual arrangement for

the Supply, Installation, Implementation and support of technology solutions (CBS with all associated and

peripheral applications) on an ASP model for the Bank as described in this document.

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

arrangement, in respect of the equipment, tools, services and solutions. The provision of the services is subject to

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

successful bidder as identified by the Bank, after completion of the selection process as detailed in this

document.

1.1. Information Provided

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

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

intending contracting party to determine whether or not to enter into a contract or arrangement with the Bank in

relation to the provision of services. Neither the Bank nor any of its directors, officers, employees, agents,

representative, contractors, or advisers gives any representation or warranty (whether oral or written), express or

implied as to the accuracy, updating or completeness of any writings, information or statement given or made in this RFP

document. Neither the Bank nor any of its directors, officers, employees, agents, representative, contractors, or advisers

has carried out or will carry out an independent audit or verification or investigation or due diligence exercise in

relation to the contents of any part of the RFP document.

1.2. For Bidder only

The RFP document is intended solely for the information of the IT Vendor/Bidder and no other person or organization.

1.3. Disclaimer

Subject to any law to the contrary, and to the maximum extent permitted by law, the Bank and its directors,

officers, employees, contractors, representatives, agents, and advisers disclaim all liability from any loss, claim, expense

(including, without limitation, any legal fees, costs, charges, demands, actions, liabilities, expenses or disbursements

incurred therein or incidental thereto) or damage, (whether foreseeable or not) (―Losses‖) suffered by any person

acting on or refraining from acting because of any presumptions or information (whether oral or written and whether

express or implied), including forecasts, statements, estimates, or projections contained in this RFP document or

conduct ancillary to it whether or not the Losses arise in connection with any ignorance, negligence, inattention,

casualness, disregard, omission, default, lack of care, immature information, on the part of the Bank or any of its directors,

officers, employees, contractors, representatives, agents, or advisers.

1.4. Costs Borne by Bidders

All costs and expenses (whether in terms of time or money) incurred by the Bidder in any way associated with the

development, preparation and submission of responses, including but not limited to attendance at meetings,

8

discussions, demonstrations, etc. and providing any additional information required by the Bank, will be borne entirely

and exclusively by the Bidder.

1.5. No legal relationship

No binding legal relationship will exist between any of the bidders and the Bank until execution of a

contractual agreement between them.

1.6. Bidder’s obligation to inform itself

Bidder must apply its mind, take due care and conduct its own investigation and analysis regarding any information

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

1.7. Evaluation of offers

Each bidder acknowledges and accepts that the Bank may, in its sole and absolute discretion, apply whatever

criteria it deems appropriate in the selection of IT Vendor, not limited to those selection criteria set out in

this RFP document.

The issuance of RFP document is merely an invitation to offer and must not be construed as any agreement or

contract or arrangement nor would it be construed as any investigation or review carried out by a Bidder. The Bidder

unconditionally acknowledges that it is submitting its bid after due and independent verification of the information

provided in the RFP.

1.8. Errors and Omissions

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

Wednesday, July 24, 2013.

1.9. Acceptance of terms

A Bidder will, by responding to the RFP document, be deemed to have accepted the terms as stated in this RFP

document.

1.10. Confidentiality

The information contained in the RFP document is confidential and is not to be reproduced, transmitted, or made

available by the Bidder to any other party without the Bank's express written permission. The RFP document is provided

to the Bidder on the basis of the undertaking of confidentiality given by the Bidder to the Bank. The Bank may

update or revise the RFP document or any part of it. The Bidder acknowledges that any such revised or amended

document is received subject to the same terms and conditions as this original and subject to the same confidentiality

undertaking.

2. RFP Response terms

2.1. Application Money

Application money of Rs. 1,00,000/- (Rupees One Lakh only) is required to be paid in the form of Demand Draft from a

9

Nationalized Bank in favour of ―SBI Capital Markets Limited‖, payable at Mumbai. This application fees is non-

refundable, and must be submitted separately along with RFP response. The Bank may at its discretion, reject any bidder

where the application money has not been furnished with the RFP response.

2.2. RFP closing date

RFP Response should be received by the officials indicated, on or before Tuesday, August 6, 2013 by 4:00 p.m. IST

unless and until extended by the Bank with due information to all concerned at following address:

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Procedure for submission of RFP response is given in Section 7. If the last date of submission of RFP response is declared

as a holiday for any reason, then the last date for submission of RFP response will fall on the next working day.

2.3. Submission of RFP response

The submission should be in the format outlined in this RFP and to be submitted only through hand delivery or courier at

the stipulated place and on or before the stipulated date and time. If the submission to this RFP does not include all

the documents and information required or is incomplete or submission is through Fax mode, the RFP is liable to

be summarily rejected. All submissions, including any accompanying documents, will become the property of Bank.

The Bidder shall be deemed to have licensed, and granted all rights to, the Bank to reproduce the whole or any portion

of their submission for the purpose of evaluation, to disclose the contents of the submission to other Bidders who have

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

process, notwithstanding any copyright or other intellectual property right of the Bidder that may subsist in the

submission or accompanying documents.

2.4. Late RFP policy

RFP responses received after the date and time for lodgment of RFPs will be rejected by the Bank. No extensions to the

timelines for any reason whatsoever will be considered.

2.5. RFP Validity period

2.5.1. The process of bid evaluation, approval and the subsequent activities may be assumed to take a reasonable

amount of time. Therefore, the bids shall remain valid for 6 months after the date of opening of Technical Bid

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

2.5.2. In exceptional circumstances, the Bank may solicit the Bidders‘ consent for an extension of the period of

validity. The request and the responses thereto shall be made in writing by email. The bid security provided

shall also be suitably extended. A Bidder may refuse the Bank‗s request without forfeiting its bid security. A

Bidder granting the request made by the Bank will not be required nor permitted to modify its bid.

2.6. Requests for information

Bidders are required to direct all communications for any clarification related to this RFP, to the officials specified in this

RFP and must communicate the same in writing before Wednesday, July 24, 2013. All queries relating to the RFP,

technical or otherwise, must be in writing only. The Bank will try to reply, without any obligation in respect thereof,

every reasonable query raised by the Bidders in the manner specified. However, the Bank will not answer any

communication initiated by bidders later than 5pm IST on Wednesday, July 24, 2013. However, the Bank may in its

absolute discretion seek, but under no obligation to seek, additional information or material from any bidders after the

RFP closes and all such information and material provided must be taken to form part of that bidder‗s response.

10

Bidders should invariably provide details of their email address as responses to queries will only be provided to the

Bidder via email. If the Bank in its sole and absolute discretion deems that the originator of the query will gain an

advantage by a response to a question, then Bank reserves the right to communicate such response to all Bidders. The

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

more than one Bidder) after the RFP closes to improve or clarify any response. The IT Vendors are expected to

mention all the required queries in the format as specified in Annexure 14. All queries should be sent to:

Deepak Kaushik,

Vice President, Capital Markets Group

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Ph: 022-22178300

2.7. Notification

The Bank will notify the selected Bidder in writing. The bid security of the unsuccessful Bidders will be returned within

a period of one month from the date of completion of the evaluation process. The Bank is not obliged to provide any

reasons for any such acceptance or rejection.

2.8. Disqualification

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

2.9. Eligibility criteria

Eligibility criteria for the IT Vendor are as mentioned in Annexure 15.

The IT Vendor should confirm compliance to these eligibility criteria. The supporting documents required for each of the

criteria is also mentioned in Annexure 15.

Only those bidders who qualify the eligibility criteria as per Annexure 15 will be considered for technical evaluation.

Bids are liable to be disqualified if, at any stage of evaluation, it is found that the bidder‗s declaration with regard to any

of the set eligibility criteria as indicated and the other data, if any, in the RFP is incorrect.

2.10. Tender Process

Selection of a successful implementation partner involves the following approach

Evaluation of RFP Response

As per the CVC guidelines, the Bidder's functional and technical capabilities must be evaluated first. This will be

undertaken by evaluating responses against pre-determined scoping and weighting criteria. Broadly, the evaluation

criteria to be used by the Bank to initially evaluate the complying responses will include without limitation:

Content and Quality of the Bidder‘s submission.

Bidder‘s Ability to Implement Solution.

Bidder‘s Ability to Build, Operate and Manage Solution eco -system.

Bidder‘s past experience of providing such solutions including ‗under ASP model‘

Technical fitness

Functional fitness

11

Service Level Agreement Terms

Project Implementation Plan & Approach

The above details of evaluation criteria are only indicative and, hence, subject to addition, modification and deletion.

The response submitted to the Bank by the Bidder will be taken to be a legally binding offer from the Bidder, and as such

may be accepted or rejected (with or without conditions) by the Bank in its sole discretion.

Bidders will be evaluated on the basis of Evaluation Criteria mentioned in Section 8.

The Commercial Bids from the Bidder will then be evaluated and the Bank may, if deemed necessary, enter into

discussions with the identified bidder/s based on a techno-commercial ranking arrived at by combining technical

weightage with commercial weightage. The Bank will not bear any costs associated with this bid exercise. The CVC

guidelines regulate any pricing discussion with Bidders at any stage during the evaluation process.

2.11. Timeframe

The following is an indicative timeframe for the overall selection process. The Bank reserves the right to vary this

timeframe 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 Bidder/s during the process.

The time schedule will be strictly followed. Interested parties are expected to adhere to these timelines. However, the

Bank reserves the right to change the aforementioned timelines.

3. Project Background

3.1. Introduction to the Bank

The Bank is a new public sector Bank proposed to be headquartered in Delhi and proposed to be operational by

November 2013. It has received in-principle approval from RBI on June 27, 2013 and the banking company is being

set-up.

Sr. No. Particulars

Dates and Timelines

1 Issuance of RFP document by the Bank Wednesday, July 17, 2013

2 Last date for submission of queries notifying

the Bank of any error, fault, omission or

discrepancy in the RFP document

Wednesday, July 24, 2013 by 5:00 p.m.

3 Pre- bid meeting Saturday, July 27, 2013, at 11:00 a.m.

Venue: Pragati Towers,

Punjab National Bank,

Bandra Kurla Complex

4 Last Date of submission of RFP response Tuesday, August 6, 2013 by 4:00 p.m.

5 Technical Bid opening date Tuesday, August 6, 2013, at 5:00 p.m.

6 Opening of Commercial bids Will be communicated to the qualified Bidders

7 Issuance of Confirmed Order Will be communicated

8 Contract signed Will be communicated

12

A key objective of the Bank is focus on the banking needs of Women and promote economic empowerment.

3.2. Business Strategy

It is important that Bidders understand the business context of the RFP. The critical theme of the Business Strategy is to

establish a bank which focuses on the needs of women as also to become the principal vehicle for propagation of

financial inclusion in the hitherto unbanked areas of the country.

Further, the IT solutions offered to the Bank must be scalable allowing for a relatively low transactional volume in the

initial stages and catering for significant increases in transactional volumes because of system roll -out and greater

participation.

The Bank aims to become a customer-centric organization. Broadly, the technology platform to be offered by the

bidders should facilitate:

To establish a customer, rather than account focused business.

To establish new channels for the distribution of products and services to customers.

To have high operational efficiency and better resource and performance management.

3.3. IT Strategy

The overall IT Strategy is focused on:

(A) Implementing and operating an IT infrastructure involving a production and a disaster recovery in data centers of

minimum Tier III standard with state of the art scalable hardware, software, network and security equipment/tools.

The data centre can be a hosted one (Shared) with separated caged enclosure with special security for controlling

entry and exit. All hardware hosting the core and surround applications (Mentioned in B and C) shall be dedicated

for the Bank (Not shared).

(B) Implementing and operating a robust and flexible universal banking software (Core Banking Solution) ideally

suited for supporting its business and accounting rules, products and processes for the Indian Banking industry

(Not shared).

(C) Implementing and operating supporting banking applications for channels (Internet and Mobile Banking and

ATM), payment systems, billing and pricing systems, work flow systems (To enable various internal processes of

the Bank like automation of account opening, back office operation for transaction processing, etc.), MIS and

analytics to handle standard reports (ALM, ADF) plus various risk management models (AML, BASEL, etc)

prescribed by regulators from time to time (Not shared).

(D) Implementing and operating surround IT systems for HRMS, email, customer service management (Call

Centre/Help Desk for internal users and customers), etc (May be shared, like on public cloud).

(E) Implementing and operationalizing an IT policy and IT security policy framework aimed at IT risk management

around customer data protection, disaster recovery and business continuity, safeguard customers' transactions on

digital channels, safeguard against external intrusions, etc. conforming to various domestic and international

standards.

In order to achieve these objectives in a shorter timeframe without making initial capital investment, the Bank is

looking at partnering with an OEM of the Core Banking platform in an ASP model of medium to long term

13

duration (7 years). The IT Vendor shall have the overall responsibility to help the Bank achieve these objectives.

The selected vendor is expected to become the extended arm of the bank's IT division and work in close

collaboration with its various business units.

This RFP specifically seeks:

Provision of the required applications, hardware, licenses, all other supporting infrastructure capable of fully

meeting and delivering the complete functional requirements.

An implementation programme for the applications and the necessary infrastructure across the Bank including the

education and training of its staff in the operation of the applications.

Provision of ongoing support to maintain the applications and to operate and maintain the all IT infrastructure

(including future IT infrastructure) until the end date of the agreement.

Provision to ensure that upgradation, new versions, levels of support and scalability, as per the Bank‘s requirement,

are provided, to ensure uninterrupted operations.

14

3.4. Volume of transactions, users and accounts- Expected*

(All estimates are provided as at the end of the year)

Particulars Year 1 Year 2 Year 3 Year 4 Year 5 Year 6 Year 7

Number of Branches** 39 134 256 387 517 648 778

Number of ATMs 127 432 715 1,067 1,392 1,740 2,088

Number of Users in CBS 200 900 1,626 2,379 3,139 3,931 4,724

Number of Customer Accounts 33,299 524,914 1,214,427 2,076,583 3,129,012 4,255,267 5,532,912

Number of Financial

Transactions (per day)

3,330 78,737 242,885 519,146 938,704 1,702,107 2,766,456

*The estimates provided are indicative in nature and are subject to change. The Bidder is expected to make his own assumptions

and the Bank is not liable for any estimates provided above.

**Includes mobile and satellite branches also

4. Project Scope

4.1. Project Objective

The Bank intends to have the core banking solution implementation before the start of operations of the Bank. The

present Request for Proposal (―RFP‖) is to enable the IT vendor to provide a structured proposal for the products

and services as envisaged in the scope of the project.

The Bank invites bids from the from OEMs of CBS Solutions for implementing Core Banking Solution (―CBS‖) and its

surrounding IT systems to start the operations of the proposed Bank. The bidder should be a well-qualified total

solution provider to implement the initiative successfully. The bidder should be capable of providing a total integrated

solution for implementing CBS, including but not limited to providing of required hardware, database, middleware,

network, facility management, third party utilities, testing, providing interfaces required for Core Banking Solution

and other associated applications.

The Core Banking system would be deployed for networking at the sites covering branches, head offices, training

centers, other back offices and any new branches opened during the contract period as part of the current IT

outsourcing initiative. Since the Bank wants to implement CBS in any new branches opened during the next seven

years, the proposed CBS should be scalable to handle approximately 500 branches and service units.

4.2. Project Scope

The project for the implementation of entire package including Core banking solution (CBS) will be on the

application service provider (ASP) model under which the vendor will be completely responsible for providing the

necessary application services for running CBS, train, customize, implement, rollout and maintaining the infrastructure

and network connectivity for all the branches and offices of the Bank, including but not limited to Data Centre(s) and

DR site(s) for the entire period of the contract.

Description of the envisaged scope is enumerated as under. However, the Bank reserves its right to change the

scope of the RFP considering the size and variety of the requirements and the changing business conditions.

The Bank expressly stipulates the IT Vendor‘s selection under this RFP is on the express understanding that this

RFP contains only the principal 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 IT Vendor shall be required to undertake to

perform all such tasks, render requisite services and make available such resources as may be required for the

15

successful completion of the entire assignment at no additional cost to the Bank.

Considering the highly complex nature of the assignment and the envisaged long-term relationship with the IT

Vendor, any service, which forms a part of facilities management or any component that is not specifically

indicated in this document but is essential for rendering the service should not be treated as excluded and would

form part of this RFP, and the IT Vendor is expected to provide the same at no additional costs to the

Bank. The IT Vendor 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 IT Vendor at a later date for omission of critical services on the pretext

that the same was not explicitly mentioned in the RFP.

The IT Vendor is completely responsible for the proposed solution to meet the scope and objectives as stated

in the RFP and in all addendums, if any, issued thereafter. The Bank assumes no responsibility for the

assumptions made by the IT Vendor. In the event the proposed solution fails to meet the Service Level

Agreement (SLA) service levels and the scope and objectives of the RFP (and addendums), the IT Vendor will

have to upgrade, modify or replace the solution at no additional cost to the bank.

All the IT systems including application, infrastructure and software shall always remain in the latest versions and

never behind the latest version by more than eighteen months.

The IT Vendor has to ensure the arithmetical accuracy of the bid. The Bank will not be responsible for any errors

in the bid submitted by the IT Vendor.

Any assumptions, changes, deviations other than what is specified and accepted by the Bank will not be

considered for the purpose of this RFP.

4.2.1. Summary of Scope of work (services)

1) All software & hardware at DC, DRC, branches and offices to run CBS and other peripheral application for the

period of contract

2) Peripheral applications to include internet and mobile banking and other modules like financial inclusion, risk

management, HRMS, ATM, treasury, ALM etc.

3) All necessary networks required at DC and DRC and branches including HO.

4) End-to-end ATM management including procurement of ATM hardware and software, including, but not

limited to, managing the switch, card management, reconciliation and fraud monitoring.

5) All security infrastructures required at DC and DRC and branches including HO.

6) The IT Vendor is required to size, supply, install, and maintain WAN network for the period of contract,

bandwidth required at branches and HO including last mile connectivity over terrestrial

links/CDMA/RF, VSAT, VSAT Hub Station to DC and DRC and between DC and DRC for replication.

7) The IT Vendor is required to procure branch peripherals and provide minimum specifications for the

peripherals (thin clients).

8) The IT Vendor is required to supply install and maintain for the period of contract, the Antivirus for PCs,

Laptops & Servers at DC, DRC and at branches and offices.

9) The IT Vendor is required to do the Patch Management for the period of contract (OS, applications, DB and

AV & other network security devices at DC DRC and branches and HO)

10) In case of disaster at DC, the Bank should be able to access all the applications at DRC (same applications

of DC) within 2 hours of the disaster at DC. The RPO should be 15 minutes. IT Vendor should adhere to

the RPO and RTO timelines

16

11) The Bank data should not be accessible to the other clients and vice versa

12) The routers and switches provided at branches by the IT Vendor should meet the security and data

encryption requirements.

13) Training for the core team and end user will be the responsibility of the IT Vendor.

14) Helpdesk will need to be provided by the IT Vendor

15) Maintenance of SLAs & Reporting of Performance at monthly intervals

16) Application Management Customization

17) The implementation, testing and day-to-day operation of the IT systems needs to be documented. The audit

of the IT systems by the Bank or an independent third-party will be held on a periodic basis (annual, semi-

annual, quarterly or ad-hoc).

4.2.2. Ownership

Sl. No. Component Responsibility

1.

DC servers IT Vendor to provide these components

2.

DR servers IT Vendor to provide these components

3.

DC routers and switches IT Vendor to provide these components

4.

DR routers and switches IT Vendor to provide these components

5.

IPS (NIPS & HIPS), Firewalls, Active Directory,

Antivirus for PCs and Servers at all locations

including DC, DRC, Branches and at HO

IT Vendor to provide these components

6.

EMS / NMS or equivalent IT Vendor to provide these components

7.

Helpdesk (L1 and L2) IT Vendor - L2 based out of project

office of the vendor and L1 based out

of the Bank HO

8.

Network Operation Centre To be located at the IT Vendor service

providers premises or DC or DRC as

the case may be

9.

Branch Network components Each branch to have separate routers,

switches, VSATs etc. IT Vendor to

provide these components

10.

Branch peripherals including Local area network

(structured cabling), Gensets, UPS

The IT Vendor will procure branch

peripheral requirements and provide

minimum specifications for the

peripherals.

11.

Bandwidth IT Vendor to provide network

connectivity and liaison with network

service providers. Bandwidth sizing

and availability planning will have to

be done by the IT Vendor.

12.

Data Centre and Disaster Recovery site hosting To be hosted by the IT Vendor. The

DR site should be in a seismic zone

17

different from that of the DC.

4.2.3. Hardware and Software Requirements

The IT Vendor will have the overall responsibility to procure, install and implement all the hardware, software and

licenses needed to start the Bank's business. The cost of all items of hardware, software, licenses and the various

operating costs shall be provided to the Bank by the IT Vendor. The indicative broad requirements of the IT

infrastructure needed to operate the Bank are as outlined below:

Hardware:

Servers for all applications

Enterprise Storage for OLTP systems plus storage for other non-OLTP applications

Cabling of data centre, DR centre and branch/offices

Network components to virtualise the server and storage in data centre and DR centre

Core switch and router for data centre and DR centre

Terminals and telephones at help-desk centre/contact centre

Routers for branches and offices

Firewalls and other security devices for data centre and DR centre

Thin clients for end users

Peripheral devices like printers, scanners, CTS scanners etc. at branches and offices

ATMs with all attendant and security devices like CCTV etc.

Laptops and hand-held devices (for ultra-small branches and for financial inclusion) – connected

to Data Centre

Software:

Operating systems for servers

Licenses for database

Licenses for core banking

Licenses for surround applications like payment systems, channels, HRMS, email, etc

Licenses for the virtual desktops

Licenses for office suite of products for desktop

Operating Expenditure:

Rent and infrastructure cost (Power and cooling) of the data centres (Production and DR)

Network/connectivity cost of branches/offices to the two data centres

Annual maintenance contract (AMC) on hardware, software and licenses

4.2.4. Deployment of Core Banking Solution (―CBS‖)/ third-party applications/ identified delivery channels

4.2.4.1. Supply, install, train, customize, implement, rollout and maintain the following applications as per

functionalities provided in Annexure 6.

4.2.4.2. Considering the changes in requirements of business, the functional requirements of the CBS branches

selected for future roll out may undergo a change. The applications would include the following

solutions. The IT Vendor should ensure that they have appropriate legal rights for all the proposed

applications / solutions to be provided in the project to accord license to use for the users of the

Bank for the period of the contract. The IT Vendor should use and deploy only authorized / licensed

software and hardware for providing the services to the Bank and would be solely responsible and liable

for any unauthorized use or deployment of any hardware or software in the Bank by the IT Vendor or his

agents or vendors. The Bank will take the final call in respect of all licensing models for

software/products of multiple vendors. In the event of any claim asserted by a third party of infringement

of copyright, patent, trademark, industrial design rights, etc., arising from the use of the Goods or any part

18

thereof in India or abroad the IT Vendor shall act expeditiously to extinguish such claim. If the IT Vendor

fails to comply and the Bank is required to pay compensation to a third party resulting from such

infringement, the IT Vendor shall be responsible for the compensation to claimant including all expenses,

court costs and lawyer fees. The Bank will give notice to the IT Vendor of such claim, if it is made,

without delay. The IT Vendor shall indemnify the Bank against all third party claims.

Broadly, following are the application functionalities or functional components expected to be delivered

by the selected IT Vendor:

Core Modules

General Ledger, Trial balance, Profit and Loss account, Balance Sheet

Share capital accounting

Asset Liability Management

Agency banking transactions and reconciliation

Any branch banking

Clearing house operations

HO Accounting

Investments / Treasury Module

Borrowings

Customer Information Module

AML / KYC Module

Signature & Photo Capture

Financial Inclusion Module

AADHAR (UIDAI) /NPR capture & validation

HRMS

Corporate E-mail system

Trade Finance Module

Forex Module

Loan Origination System

Reconciliation and Settlement System

Retail Banking

Savings Bank accounts

Current accounts

Term deposits

Recurring deposits

Tax deduction at source

Cheque book request

Standing instructions

All Government business – collection and remittance

Cash

Clearing (through Service Branch module & other banks)

19

Locker

Mobile & Internet Banking

ATM facility including Card Management Services, Reconciliation and Fraud Monitoring solutions to

be included.

Bancassurance (Corporate, Agent & Referral Mode)

Utility Bill payment

Depository Services

On-line Trading

Audit Module (for the use of the Bank‘s own internal examiners as well as statutory auditors)

Loans and Advances

Cash credit and overdraft

Short term, medium term and long term loans, including loans with interest subvention and interest

calculation without/with compounding of different periodicities. Capability to handle subsidy in loan

accounts. Ability to handle write-off accounts.

Kisan credit card operations

Agricultural & Non-agricultural lending - Direct & on-lending under refinance scheme

Asset classification (NPAs) for Agricultural & Non-agricultural loans

Re-scheduling/ restructuring of loans

Resetting of interest (back dated calculation of interest)

Remittances and Other Services

Demand draft, pay order

Electronic Clearing Services (ECS)

Safe deposit lockers

Card products

Government securities

Other Marketable Securities

Stock Market Investments

NEFT / RTGS / SWIFT service (for inter-bank transfers / remittance)

Bills

Reporting and MIS, regulatory and other requirements

All regulatory returns including facility for Automated Data Flow (ADF) prescribed by RBI

Regular reports required by the Bank for MIS/control purposes

Anti money laundering and KYC reporting

All reports pertaining to Government business

Service tax

Detailed audit trail

SLR/CRR maintenance and reporting

Priority Sector Statements and Tax Collection reports

Credit Information Bureau Reporting

20

Analytics and Risk Management System compliant with Basel III standards

Customer Information

Store customer details

Link collaterals, limits and accounts to customers

Personal and business customer profiles

Name search facility

Customer and account enquiries with single view of customer

Compliance with regulatory requirement of customer profile

User defined relationships

Customer passwords and data security

Channels

To enable the Bank to provide comprehensive and competitive services through Alternate Delivery

Channels, the IT Vendor should provide either itself or through tie up with other service providers the

following services:

o Automated Teller Machines (ATM)

o Internet Banking (INB)

o Mobile Banking (MB)

o Social Media (if required by the Bank)

The above services should be an end to end service from origination to completion with appropriate

interfaces and safety features like encryption, fraud detection etc. built in, where warranted or

mandatory. The solution should also have automated reconciliation, reports / MIS generation

capabilities.

The ATM facility should be available to the Bank‘s customers from the start of operations.

The ATM and Switch should conform to industry standard (VISA/MasterCard) security specifications

and PCIDSS standard from the start of operations.

For detailed functional requirement specification as well as response, kindly refer to Annexure 6.

4.2.4.3. The CBS would need to technologically enable all Banking functionalities / products like Deposits,

Advances (including agricultural loans), Loans & advances, Credit Monitoring / NPA management,

Clearing functions at branches, Term Lending, Customer Information System, General Ledger, MIS and

reports, etc. as mentioned in Annexure 6. Specifically, the CBS includes but not limited to, the

functionalities listed in the sheets of Annexure 6. The Core Banking system should support a 24x7-

processing environment.

4.2.4.4. The proposed Core Banking Solution should be on a standardized RDBMS database.

4.2.4.5. IT Vendor is required to provide for 10 years of data retention. The production system should carry data

of an optimal period for operational convenience (any period not more than 3 years). Accordingly the

storage and servers should be sized to maintain and accommodate 10 years data. The data archival /

purging solution should be part of CBS and be provided by the IT Vendor.

4.2.4.6. The Bank expects the Core Banking solution to provide for Management and Executive information

reporting as required by the management and departments of the Bank as well as the statutory and

regulatory bodies from time to time. The system should be capable of generating individual branch,

21

village, panchayat, block, district, region, zone wise and head office reports as well as hierarchical and

consolidated reporting at each level. The system should be capable of generating all reports as on date

and also back dated reports between two dates. The IT Vendor has to ensure that the requisite

infrastructure is provided to support the reporting requirements. The Bank at a later date will not

make any additional payments and accept any plea of the IT Vendor in this regard.

4.2.5. Interfaces

4.2.5.1. Following interfaces are required to be built in the proposed solution:

1. Payment Gateway

2. Internet Banking

3. Web Server

4. RTGS /NEFT /SWIFT /IMPS /SFMS

5. Mobile / SMS Banking

6. ATM Switch (NPCI / Any other)

7. AML Check List Data Feed

8. Depository System (NSDL / CDSL)

9. Any Statutory / Regulatory systems

4.2.5.2. The IT Vendor will be responsible for identifying the detailed interface requirements for integrating the

proposed packages to the systems.

4.2.5.3. The IT Vendor will present to the Bank the interface requirements for review. During the business

process definition and system specification requirement stage, the IT Vendor should freeze on the list of

interfaces that needs to be implemented and obtain the sign off from the Bank, failing which

the IT Vendor would be forced to implement all the interfaces as listed above. The IT Vendor will give

the Bank adequate time to review the interface requirements. Any suggestions from the Bank will have to

be included by the IT Vendor to the extent possible. The IT Vendor will be responsible for developing,

testing and maintaining the interfaces. The IT Vendor must ensure that all interfaces are automated with

minimal manual intervention. All 3rd

party applications proposed by the IT Vendors to meet the

functional requirements of the Bank should provide an interface with the Core Banking Solution. The IT

Vendor will ensure and incorporate all necessary security and control features within the application,

operating system, data base, network etc. so as to maintain integrity, availability and confidentiality of

data at all times. The IT Vendor will be responsible for setting up the test environment for interface

testing.

4.2.5.4. The IT Vendor is expected to maintain, modify and customize the interfaces throughout the period of the

contract depending on any changes that may take place during the period of the contract.

4.2.5.5. Implement the required software at the desktops to run the proposed core Banking solution and interfaces.

The IT Vendor will ensure that Bank functions continue to operate through upgrades and new releases of

automation software. The IT Vendor will further ensure minimum interruption during upgrades to office

automation software.

4.2.6. Customization

4.2.6.1. The IT Vendor will be expected to carry out the customization during the course of implementation as

well as the period of support within the agreed monthly fees payable.

4.2.6.2. The IT Vendor needs to provide all statutory and regulatory reports as required by the regulatory

institutions. The Bank will not pay any additional customization costs either for gaps observed for the

22

above and/or statutory or regulatory reports as required by the banks.

4.2.6.3. The IT Vendor is expected to customize all gaps observed during Functional RFP, Product Demo,

Training, UAT, Business Process Definition (―BPD‖), and roll out for all the proposed solutions. There

will not be any additional cost of customization over and above what is quoted in the price bid. The IT

Vendor also needs to provide all statutory reports as required by the regulatory institutions. The Bank will

not pay any additional customization costs either for gaps observed for the above and/or statutory reports

as required by the Bank.

4.2.7. Testing

4.2.7.1. The Bank will be conducting a ―User Acceptance Test‖ (―UAT‖) testing for the purpose of ensuring that

all the functionality requested for by them are available and functioning accurately. The UAT would be

carried out for the CBS solution and other third-party software proposed.

4.2.7.2. The IT Vendor will convey to the Bank that all the customizations that are required to ―Go Live‖, as

agreed upon and signed off by the Bank are completed and the solution is ready for testing.

4.2.7.3. The IT Vendor will set up a test environment, to accommodate a minimum of 20 concurrent users, which

shall support simultaneous testing and installation of applications including the customizations as per

Bank‘s requirement and uploading of live data of a sample branch in the test server. The Bank expects the

test environment to be available to the Bank at all times, for the purpose of testing. The IT Vendor is

expected to provide for the requisite test and development infrastructure including hardware,

software, operating system and database for all applications being offered by the IT Vendor. The Bank

expects the IT Vendor to set up the required solutions (including the client peripherals) and provide

connectivity to test server at DC for the purpose of testing. The Bank shall not pay any additional

amounts to the IT Vendor for the purpose of creating the test environment. The IT Vendor has to ensure

that all requirements for the test environment like storage, compute environment etc. for the applications

are taken into account.

4.2.7.4. The IT Vendor will install client version of the solution on the peripherals. It will be the IT Vendor‘s

responsibility to establish connectivity of the test peripherals to the Test server.

4.2.7.5. The IT Vendor needs to provide separate test environments for CBS and other software being a part of

the solution to be provided by the IT Vendor. Consolidation of the test environment is acceptable

however; the IT Vendor has to ensure that there are no performance bottlenecks in the testing

environment.

4.2.7.6. The IT Vendor will be responsible for preparing detailed test cases including test data.

4.2.7.7. The IT Vendor will assist the Bank in conducting all the tests and analyzing /comparing the results. The

IT Vendor shall provide full-time resources conversant in all business areas, for trouble-shooting during

the entire UAT process.

4.2.7.8. Any deviations / discrepancies / errors observed during the testing phase will be formally reported to the

IT Vendor and the IT Vendor will have to resolve them immediately or within 7 working days.

4.2.7.9. The IT Vendor will be responsible for maintaining appropriate program change control and version

control for all the modifications / enhancements carried out during the implementation /testing phase.

4.2.7.10. The IT Vendor will be responsible for providing and updating system and user documentation as per the

modifications.

23

4.2.8. Wide Area Network (WAN)

4.2.8.1. Design, supply and install, commission the WAN Links at DC, DRC and all service locations of

the Bank will be the sole responsibility of the IT Vendor. The IT Vendor shall be

responsible for designing, liaisoning with the WAN link Service Provider and deploying the WAN

across all the locations as per the rollout plans. The IT Vendor is expected to liaison with WAN

service providers for the period of the contract to meet the service levels defined in the SLA.

4.2.8.2. The IT Vendor is required to liaise with the WAN Service Provider for procurement, commissioning,

installation, management and monitoring of such links through the period of the contract. The IT Vendor

is required to size the link bandwidth of all the network links part of the WAN.

4.2.8.3. The IT Vendor needs to provide the device and link level redundancy at DC / DRC as also at the branch

/ office locations between these locations.

4.2.8.4. The IT Vendor would be responsible for end-to-end procurement, installation, maintenance, monitoring

and adherence to service levels for all network related components and other terrestrial links.

4.2.8.5. The link should be terminated to the Router port installed at branches. All necessary equipment hardware

/ software (if any) etc., required to connect the link in Router port shall be provided by the selected

Vendor.

4.2.8.6. For VSAT equipment installations at the Bank‘s premises, the Bank would obtain the necessary

permission from the premises landlord for the installation of the VSAT. In case such permission is not

available or for any other reason where VSAT cannot be installed, then the IT Vendor will have to

procure last mile connectivity using Leased Line/RF or any other available solution.

4.2.8.7. The IT Vendor is expected to provide an Account Manager/ single point of contact at Bank‘s agreed

location during business hour of the Bank for the entire contract period.

4.2.8.8. Except for VSAT links, in any location, the link will be deemed to be commissioned only when both

primary and secondary links are commissioned, tested and accepted by the Bank.

4.2.8.9. The IT Vendor will be expected to inform the Bank of the link readiness and provide all the necessary

documents indicating the full details of the commissioned Network links.

4.2.8.10. The IT Vendor will be responsible to capture actual down time as per the agreed Service Levels.

4.2.8.11. The IT Vendor should provide infrastructure / tool (web portal etc.) to enable the Bank‘s team to monitor

the links from the designated locations. Web portal should be made available at the Bank‗s head office.

The tool should be able to provide:

Single screen view of the links availability status

Real time link usage report of individual links

Alerts for the links, wherein the link utilizations breaches the 80% utilization

Monthly SLA Reports i.e., availability and performance report including link usage report.

4.2.8.12. The IT Vendor needs to submit the monthly SLA reports to the Bank within 5 days from the last date of

the previous month. The report should also contain the full details of the SLA breaches and other SLA

deviations along with the necessary root causes, and appropriate measure should be taken in order to

avoid link failures.

24

4.2.8.13. The SLA report needs to be jointly reviewed by the Bank and Vendor within next 5 working days, and

agree upon the service levels deviation defined in the SLA.

4.2.8.14. Bandwidth Sizing

4.2.8.14.1. The IT Vendor is required to size the bandwidth based on the requirements as specified in the RFP

4.2.8.14.2. The IT Vendor is required to size the last mile connectivity bandwidth for each location such as

branches and HO.

4.2.8.14.3. The IT Vendor needs to ensure that there is no single point of failure with regards to the network and

security components at the DC and DRC as also the entire WAN.

4.2.8.15. Network Security

The proposed solution should consider and address at least the following security requirements:

4.2.8.15.1. An authentication, authorization and accounting (AAA) server must be placed at the DC & DRC. At

the Network layer (Layer 3 of OSI), there should be 256 bit AES (VSAT Network)/AES 256 bit (for

MPLS VPN Network) IPSec for all the routers of all networked branches, DC, DRC and proposed as a

part of RFP. The data must be encrypted using IPSec

4.2.8.15.2. At the Application layer (Layers 5 - 7 of OSI), the CBS must ensure appropriate methods to maintain

confidentiality & integrity of data at the application level.

4.2.8.15.3. The network must have at least the following security solutions deployed at the enterprise levels:

4.2.8.15.4. Firewalls The IT Vendor should design a security solution which has different make / model of

firewalls at the DC & DRC.

4.2.8.15.5. Intrusion Prevention System - Host-based and Network-based. The IT Vendor should design a security

solution which has different make / model of firewalls at the DC & DRC.

4.2.8.15.6. Data Encryption including IPSec using AES (256 bit);

4.2.8.15.7. Policy Management Solutions for access control and network security;

4.2.8.15.8. Highest level of security features supported by different network components; VLANs; Access

Controls (physical and logical) at the DC and DRC

4.2.8.15.9. Two layers of security (firewalls from different service providers) between the Internet & centralized

applications, between the 3rd party networks & centralized applications.

4.2.8.15.10. The servers housed at the data Center & disaster recovery site should not be accessed directly from any

network. It should be designed in such a way that the data being accessed from any location at the DC

and DRC should pass through the firewall & IPS systems.

4.2.9. Security Management

4.2.9.1. The software for policy management must be installed on the network to ensure well -defined policy and

monitoring any deviation from the Bank‘s policies which would be in line with global standards like RBI

and IBA guidelines, the Bank‘s policies etc.

4.2.9.2. The IT Vendor is responsible for defining and regularly updating the baseline security standards in line

25

with the above-mentioned security standards.

4.2.9.3. The IT Vendor will be responsible for update and refresh of anti-virus packages throughout the

technology eco-system including the client desktops.

4.2.9.4. At the Data Center, a central Policy server should be made available to define policies which will be

considered for network access for CBS branches. At branches, admission controls should be

configured at switch level which will limit access to those desktops that follow policies defined in

server.

4.2.9.5. The IT Vendor would be responsible for formulating detailed procedures for each and every service

component offered by the Bank.

4.2.9.6. The IT Vendor would be responsible for implementing the model IT & Security policy drafted by them

and approved by the Bank. Any deviations to such model policies should be informed to the Bank and

approval should be sought from the joint forum. The IT Vendor has to make best efforts to provide a

workaround for the deviation.

4.2.9.7. The IT Vendor would be responsible for complete log monitoring for servers, databases, networks and

security. The IT Vendor should ensure expert security specialists are given the task to monitor such logs.

The IT Vendor needs to provide tools for monitoring such logs. Any suspicious or concerned activities

should be immediately informed to the Bank. The IT Vendor personnel will also be responsible for

providing proactive solutions and taking immediate corrective actions to rectify any concerns, security

threats or suspicious activities.

4.2.9.8. The IT Vendor is expected to report and analyze security and other incidence and take corrective

proactive measures to rectify the same immediately. The IT Vendor also expected to proactively inform

the Bank of the occurrence of such incidences and breaches.

4.2.10. Project Implementation - Coverage

4.2.10.1. Business Process Design and System Requirement Specification Document

4.2.10.2. Gap Analysis

4.2.10.3. Parameterization

4.2.10.4. Impact analysis

4.2.10.5. Auditing techniques

4.2.10.6. Techniques of generating various MIS / EIS reports from the solution provided

4.2.10.7. Developing new audit reports / tools using the proposed solution

4.2.10.8. Training for report writer facility to create new reports and modify existing reports

4.2.10.9. Log analysis and monitoring

4.2.10.10. Incidence analysis and reporting

4.2.10.11. The Bank will be responsible for identifying the appropriate personnel for all the training

requirements.

26

4.2.10.12. The IT Vendor will be responsible to install the required applications / systems, training server at DC and

also ensure connectivity including bandwidth to the training server, for the purpose of training at the

training Centers. There will be no cost payable by the Bank for the application, database and operating

system software installation at such training sites. The training hardware at the data Center should at a

minimum support 50 concurrent users.

4.2.10.13. Project Timelines

It is expected that implementation at the first 6 branches of the Bank shall be completed by the end of

October 2013. Bidder has to submit a detailed project plan for implementation, which will be monitored

during the period of implementation.

4.2.11. Training & Handholding

4.2.11.1. The IT Vendor will be responsible to train all users in all branches as identified by the Bank. Trainings

will be at three levels viz. train the trainers (1 batch of identified persons), training of the Core

Team (consisting of 20 identified persons) and user training (a 1 week training of all the users at

branch before the branch operations start to CBS platform and to include all identified users to

participate in the 2-week handholding programmes at branches after going live). The class room and

lab environment will be arranged by the IT Vendor and all infrastructure including the PCs,

Bandwidth, connectivity to the training servers, desk, chairs, tables etc will be the responsibility of the

IT Vendor.

4.2.11.2. The IT Vendor must ensure that proficient personnel conduct the training at the respective

training Centers identified for the same. The IT Vendor should ensure that the end user training is

scheduled and completed at least a week prior to the branch going live.

4.2.11.3. The IT Vendor will be responsible for providing the users with the requisite training material in

both hard and soft copies for the core team as well as for the end users. The onus of preparing the

training material will be on the IT Vendor.

4.2.11.4. The IT Vendor will be expected to deliver to the Bank for each user, one (1) physical copy and one (1)

electronic copy of documentation for each of the deliverables and online context-sensitive help

module included in the software to enable the Bank‘s personnel to use and understand the operations of

the deliverables. The Bank may make additional copies of the Bank- specific Documentation for their

internal use.

4.2.11.5. The IT Vendor will be responsible for preparing, circulating and collecting training feedback forms

from the participants.

4.2.11.6. The feedback forms will be prepared by the IT Vendors, reviewed and given to the banks.

4.2.11.7. The Bank further expects its personnel to be trained for performing Helpdesk operation. The training

should be a combination of classroom and hands-on training along with web-based trainings. The

trainings should be equipped with effective feedback mechanism which will help the Bank to keep a

track of the effectiveness of trainings and evaluate the employees after the training.

4.2.12. Roll out

4.2.12.1. The roll out will consist of implementing the proposed Core Banking Solution along with all peripheral

applications as per the project implementation plan provided to the Bank and agreed before the

implementation exercise commences

27

4.2.12.2. The IT Vendor shall ensure setting up the live server at the DC and DRC. The DRC should be deployed

at a 100% capacity of the DC for the hardware, processing and security.

4.2.12.3. The IT Vendor will be responsible for installing the customizations and testing.

4.2.12.4. The IT Vendor will carry out parameter setting for the applications to support the Bank‘s business

rules which eventually will be transferred to the Core Team of the Bank. The Vendor shall be

responsible for accuracy of the parameters set according to business needs of the Bank.

4.2.12.5. The IT Vendor will be responsible for ensuring that the branches are connected to the DC and DRC

using the proposed network.

4.2.12.6. The IT Vendor will be responsible for ensuring that all the client software is installed at the branch

computers.

4.2.12.7. The IT Vendor will be responsible for imparting the required training to the branch personnel prior to

implementation.

4.2.12.8. The IT Vendor is expected to provide for hand-holding support.

4.2.13. Facilities Management

4.2.13.1. The IT Vendor will be the single point of contact and responsible for AMC, ATS, guarantees

& warrantees for all components, hardware, software, bandwidth, etc.

4.2.13.2. While bidding for providing facilities management services, the products and solutions proposed by the

IT Vendor by way of this RFP should come with warranty as provided by the respective OEM vendors.

Thereafter, the IT Vendor should provide AMC/ATS for these products and solutions as the case may

be, for the remainder of the contract period. Vendor should list out the warranty period provided for

each proposed product / solution in his RFP response.

4.2.13.3. Establish, operate and maintain a Help desk from 8 AM to 8 PM on all days of the week for branch

users. Such Help Desk should be available at the Bank HO and the central Help Desk at the DC

level. Help Desk support for the delivery channels such as internet banking, ATM etc. should be

24x7, 365 days a year.

4.2.13.4. Provide training to the information technology users on supervising the facilities management

function and train the Bank‗s employees on operating in the helpdesk

4.2.14. Services to be covered

4.2.14.1. This section describes, but does not limit, the services to be provided by the IT Vendor during the

currency of the contract. The Bank intends that the contract which is contemplated herein with the IT

Vendor shall be for a period of five years, and shall cover all deliverables and services required to be

procured or provided by the IT Vendor during such period of contract. The IT Vendor needs to consider

and envisage all services that would be required in the maintenance of the facilities. FM for all purposes

means all AMC, warranties, annual technical support and all other costs necessary and incidental for

the maintenance and support of the infrastructure and equipment.

4.2.14.2. The services would include but not be limited to:

1) Hardware Management (Servers)

2) System Administration

28

3) Integrated customer support and Helpdesk management

4) IT services

5) Hardware and software

6) Management services

7) Problem coordination services

8) Recovery services

9) Software related services

10) Software distribution

11) Software maintenance

12) Software maintenance and support services during warranty and AMC

13) Updates, upgrades, new releases and new versions

14) Enhancement

15) Software support

16) Security Management

17) Log analysis and monitoring

18) Antivirus Management

19) DC /DR LAN and Server Administration

20) Bank wide Corporate Network Management

21) Data Centre and Disaster Recovery Site management

22) Data Space management

23) Data Backup and Recovery of shared management

24) Perform Database Administration activities for Database

25) Operations Management

26) Application management including EOD, BOD, day-begin, month- end, year - end, periodic and

daily backups.

27) Software updates, patch management, security updates, data updates from one application to

another application in the centralized-Banking environment.

28) Application and database performance tuning at periodic interval (at least every 6 months).

29) Perform quarterly BCP, DC - DR drills, send the report to the bank.

30) Any other services required for maintenance and support of the entire proposed solution over the

contract period.

5. Service Levels overview

5.1. Minimum Technical requirements

5.1.1. IT Vendor should ensure the availability of 99.9% of the core system of the Bank to be computed on

monthly basis through the entire IT infrastructure provided by IT Vendor to the Bank. Not a single outage to

exceed more than 4 hours at a time and not repeated more than once in a month.

Components Availability*

Network within DC/ within DR 99.99%

Between DC and DR 99.9%

Branch Office to DC/ DR 99.5%

*If the network uptime is less than the requirements specified above, penalties will be charged as per the

Service Level Agreement

5.1.2. IT Vendor should ensure the performance of the IT infrastructure provided by the IT Vendor to the Bank,

29

that is resource utilization of the Server, Storage, Network and security devices should not be more than 80%

at any given point of time

5.1.3. CBS Application response time within the data center should be less than 10 ms.

5.1.4. CBS Application response time at branches, HO (client desktop) should be less than 2 seconds.

5.1.5. The Data Centre (DC) and the Disaster Recovery Centre (DRC) should be Level 3 or above standard as per

Uptime Institute and certification thereof would be preferred.

5.1.6. Data Center (DC) and Disaster Recovery Center (DRC) implementation and hosting the service will be at

Vendor‘s DC and DRC. The IT Vendor will be responsible for setting up the live server at the DC and DRC.

The DRC should be deployed at a 100% capacity of the DC for the hardware, processing and security.

5.1.7. The IT Vendor is expected to provide appropriate data replication strategy and technology to replicate data

between DC - DRC.

5.1.8. The IT Vendor must have a suitable strategy for recovery of data and application in case of a disaster with

necessary procedures for the same in the solution with RTO of 2 hours and RPO of 15 minutes.

5.1.9. The IT Vendor should exercise the periodical DR drill in order to test the readiness and effectiveness of the

business continuity plan as proposed by them.

5.1.10. The DRC should be deployed at a 100% capacity of the DC for the hardware and processing while the

security and environmental controls will be similar to the DC. The DRC should be operational in case of a

disaster at the DC.

5.1.11. The application deployment architecture should follow best-fit technology and preferably be based on SOA

architecture principles with deployment an advanced middleware application.

5.1.12. The logical architecture of DC & DRC at a minimum should be divided into different sub-networks. These

networks must be separated from other networks through switches and firewalls. The logical separation of

these sub-networks must be done using VLANs and sub-netting. The major classification of sub-network

must be at least:

Demilitarized Zone - 1 (for application, antivirus and DB servers);

Demilitarized Zone - 2 (for Active Directory servers, test & development servers, training

servers, etc.);

Management Network - (for Reports);

Private Network - (should consist of the separate logical networks to enhance the security of (a)

CBS, (b) intranet and/or mail server, (c) DNS/DHCP and other applications like HRMS, AML,

ALM, etc).

Network Level: The network at DC must be divided into various sub -networks. These networks

must be separated through switches, firewalls, IPS, sub-netting, etc.

Access Level: Access controls mechanisms, as defined in the security policy of the

Bank, must be implemented at network, operating system, database and

application system levels.

5.1.13. The IT Vendor is responsible for sizing the storage for the period of the contract; the Bank is not

responsible or liable for the sizing. Sufficient storage space should be allocated to the Bank, so that any

30

given point of time, 40% additional space should be available.

5.1.14. The IT Vendor is required to size for adequate hardware based on the volumes for the Core Banking

5.1.15. Application & Database and other Applications. The Core Banking Application and database should be

sized for active - active or active - passive cluster based on the proposed CBS application. The IT Vendor

needs to size, design, procure, commission and maintain the hardware and related software for all the

applications for the period of contract required as per the RFP.

5.1.16. The hardware sized for all the applications should be redundant & scalable. All the components within the

server should be hot swappable or pluggable and should incur no downtime due to component failure.

5.1.17. It will be the IT Vendor‘s sole responsibility to build the Testing and Development as well as Training

environments at the IT Vendor‗s facility for conducting UAT, application development and user Separate

adequately sized hardware should be kept for test & development and training servers.

5.1.18. The IT Vendor is expected to size the hardware to achieve 10 transactions per second (TPS). Detailed

transactions, users and accounts volumes data is given in an earlier section.

5.1.19. The IT Vendor is responsible to arrive at the sizing independently. The Bank is not responsible for any

assumption made by the IT Vendor with respect to the sizing. In the event the sizing quoted by the IT

Vendor does not meet the performance / service levels of the Bank the IT Vendor will at their cost carry

out the necessary upgrades / replacements. The Bank will not pay any additional amount during the period

of the contract.

5.2. Service Levels

Part A – Availability

5.2.1. IT Vendor should ensure the availability of 99.9% of the core system of the Bank to be computed on

monthly basis through the entire IT infrastructure provided by IT Vendor to the Bank.

5.2.2. The IT Vendor should provide the Availability Report on monthly basis and a review shall be conducted

based on this report. A monthly report should be provided to the Bank at the end of every month

containing the summary of all incidents reported and associated vendor performance measurement for that

period. All Availability Measurements will be on a monthly basis for the purpose of Service Level

reporting.

Penalty Calculation

5.2.3. Monthly Service Level Default = Expected Service Level - Monthly Actual Service Level

5.2.4. *Monthly service level default cannot be less than zero. (If for a particular month the actual service level is

above the minimum service level then the Monthly service level default will be zero and not less than zero)

5.2.5. Quarterly Service level default = Total of Monthly service level default for all the 3 months of the quarter.

5.2.6. Quarterly Penalty = (Quarterly Service level default) X (Quarterly Cost of Product & Services) X

(Performance Category Allocation)

5.2.7. Quarterly Availability Penalty shall be deducted from Quarterly payment before quarterly payments.

5.2.8. In case Actual Service Level for any quarter is below 95%, then up to 50% of the quarterly payment shall

be deducted as Penalty.

31

Part B - Helpdesk Response

5.2.9. All mails/calls received at Helpdesk will need to be classified as Incident, Problem, Service Request,

Change Request or Query. All Incidents and Problems will be further classified as Severity 1 to Severity 4

as depicted in the following table:

Severity Criteria Indicative list of issues Resolution/

Mitigation

L 1 Single user of a Branch/Office affected

Queries, Service

Requests

Within 60 minutes

L 2 Multiple users but less than 10% of the

Baseline Bank Users affected or entire

Branch is impacted due to local issues

This level would typically correspond to

issues which result into disruption of one or

more services to one or more offices

The identified issue has normal impact on

the business and needs to be addressed at the

earliest

Application support

from the data centre.

Within 30 minutes

L 3 More than 10% to 20% of the Baseline Bank

Users Affected or entire Branch is impacted

due to Application or network issues.

The identified issue has significant business

impact and needs to be taken up on top

priority

This level would typically correspond to

issues that result into disruption of one or

more critical services to all offices

Critical production

issues such as incorrect

interest application in

majority of the

accounts, frauds done

using the system,

inconstant accounting

or system behaviour.

Within 30 minutes

L 4 More than 20% of the Baseline Bank Users

affected

The identified issue has material business

impact and needs to be resolved

immediately.

This level would typically correspond to

issues that result into disruption of most or

all critical services to Branches.

Issues pertaining to

core application and

related databases,

system software,

hardware which make

the application

inaccessible.

Within 15 minutes

Expected Service Level – 95% calls should be resolved in given resolution time. Every call which remains

unresolved within the specified time shall be considered as default.

Penalty Calculation

Monthly Helpdesk Default = Expected Helpdesk Service Level - Monthly Actual Helpdesk Service Level

*Monthly Helpdesk service level cannot be less than zero. (If for a particular month the actual service level is

above the minimum service level then the Monthly service level default will be zero and not less than zero)

Quarterly Helpdesk Service level default = Total of Monthly service level default for all the 3 months of the

quarter.

32

Quarterly helpdesk Penalty = (Quarterly Service level default) X (Quarterly Cost of Product &

Services) X (Performance Category Allocation %)

5.2.10. Quarterly helpdesk Penalty shall be deducted from Quarterly payments.

6. Terms and Conditions

6.1. General

6.1.1. The IT Vendor shall adhere to the terms of this RFP and shall not deviate from the same. If the IT Vendor

has absolutely genuine issues only then should it provide its nature of non-compliance to the same in

writing.The Bank reserves its right to accept or not to accept such deviations to the tender terms.

6.1.2. The Bank intends the IT Vendor appointed under the RFP shall have the single point responsibility for

fulfilling all obligations and providing all deliverables and services required for successful

implementation of the project, notwithstanding the fact that the IT Vendor may appoint / procure services

of third party suppliers (including software Vendors) to perform all or part of the obligations contained

under this RFP and that the Bank may for convenience enter into arrangements, including tripartite

agreements, with such third party Vendors if required.

6.1.3. Unless agreed to specifically by the Bank in writing for any changes to the RFP issued, the IT Vendor

responses would not be incorporated automatically in the RFP document.

6.2. Rules for responding to this RFP

6.2.1. Last date for submission of bids is Tuesday, August 6, 2013 by 4:00 p.m. Bid will be submitted to:

Deepak Kaushik,

Vice President, Capital Markets Group

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Ph: 022-22178300

6.2.2. As per Bid Submission process, Bidders are required to submit technical and commercial bids in separate

envelopes superscribed as ―Technical Bid for 1-CMT/BMB/2013-14 Dated 17th July 2013 issued by the

Bank for Implementation of CBS at the Bank on ASP Model‖ & ―Commercial Bid for 1-

CMT/BMB/2013-14 Dated 17th July 2013 issued by the Bank for Implementation of CBS at the Bank

on ASP Model‖.

6.2.3. All responses received after the due date / time would be considered late and would be rejected.

6.2.4. All responses should be in English language. All responses by the IT Vendors to this RFP document shall

be binding on such Vendors for a period of 6 months after the opening of the technical bids.

6.2.5. All responses including commercial and technical bids would be deemed to be irrevocable

offers/proposals from the IT Vendors and may, if accepted by the Bank, form part of the final contract

between the Bank and the selected Vendor. Vendors are requested to attach a letter from an authorized

signatory attesting the veracity of information provided in the responses. Unsigned responses would be

treated as incomplete and are liable to be rejected.

6.2.6. Any technical or commercial bid, submitted cannot be withdrawn/modified after the last date for

33

submission of the bids unless specifically permitted in writing by the Bank. In case, due to unavoidable

circumstances, the Bank does not award the contract within 6 months from the last date of the

submission of the bids, and there is a possibility to award the same within a short duration, the IT

Vendor would have the choice to maintain the bid security with the Bank or to withdraw the bid and

obtain the security provided.

6.2.7. The IT Vendor may modify or withdraw its offer after submission, provided that, the Bank, prior to

the closing date and time, and receives a written notice of the modification or withdrawal

prescribed for submission of offers. No offer can be modified or withdrawn by the IT Vendor

subsequent to the closing date and time for submission of the offers.

6.2.8. The IT Vendors are required to quote for all the services mentioned in Section 4 – Project Scope of this

document. In case any Vendor does not quote for any of the services, the response would be deemed to

include the quote for such unquoted components.

6.2.9. Based on the Bank‗s requirements as listed in this document, the IT Vendor should identify the best-suited

solution that would meet the Bank‗s requirements and quote for the same. In case the IT Vendor quotes for

more than one solution (for example one quote for software x and y and another quote for software x and

z) then the response would be considered as improper and liable to be rejected. The IT Vendor is

expected to select the best option and quote for the same in his offer. (For example the IT Vendor should

not quote for two database servers, one xyz and other abc,)

6.2.10. Similarly, the commercial quotes should also be clear and straightforward and dependent upon

any conditions, events or choice. Any such response may run the risk of disqualification and

consequent rejection.

6.2.11. Each offer should specify only a single solution, which is cost-effective and meeting the entire tender

specifications. It is the responsibility of the IT Vendor to decide the best suitable solution.

6.2.12. The IT Vendor must furnish requirements as per the formats provided in the RFP document.

6.2.13. The Bank is not responsible for any assumptions or judgments made by the IT Vendors for arriving at

any type of sizing or costing. The Bank at all times will benchmark the performance of the IT Vendor to

the RFP documents circulated to the IT Vendors and the expected service levels as mentioned in these

documents. In the event of any deviations from the requirements of these documents, the IT Vendor

must make good the same at no extra costs to the Bank within two weeks of detection of the deviation, in

order to achieve the desired service levels as well as meeting the requirements of these documents.

The Bank shall not be responsible for any assumptions made by the IT Vendor.

6.2.14. The Bank ascertains and concludes that everything as mentioned in the RFP documents circulated to the

Vendors and responded by the IT Vendors have been quoted for by the IT Vendors, and there will be no

extra cost associated with the same other than the cost quoted by the IT Vendor.

6.2.15. In the event mandatory or optional prices are not quoted by the IT Vendor, for items where such prices are

a must and required to be quoted for, the highest price quoted by any of the participating IT Vendors

will be taken as the costs, for such for arriving at the Total Cost of Ownership for the purpose of

evaluation of the defaulting / deviating Vendor.

6.2.16. All out of pocket expenses, traveling, boarding and lodging expenses for the entire life of the contract

should be a part of the commercial bid submitted by the IT Vendor to the Bank. No extra costs on

account of any items or services or by way of any out of pocket expenses, including travel, boarding and

lodging etc. will be payable by the Bank. The IT Vendor cannot take the plea of omitting any charges or

34

costs and later lodge a claim on the Bank for the same.

6.2.17. The IT Vendor at no point in time can excuse themselves from any claims by the Bank whatsoever for

their deviations in confirming to the terms and conditions, payments schedules, time frame for

implementation etc. as mentioned in the RFP documents circulated by the Bank. The IT Vendor shall

be fully responsible for deviations to the terms & conditions, project schedule etc. as proposed in the

RFP.

6.2.18. The Bank would like to expressly state that any assumptions, terms, conditions, deviations etc which the

Vendor includes in any part of the IT Vendor‘s response to this RFP, will not be taken into account either

for the purpose of evaluation or at a later stage, unless such assumptions, terms, conditions, deviations

etc have been accepted by the Bank and communicated to the IT Vendor in writing. The IT Vendor at a

later date cannot make any plea of having specified any assumptions, terms, conditions, deviations

etc in the IT Vendor‗s response to this RFP.

6.2.19. The IT Vendor, from time to time during the period of the contract, should provide price benefits to

the Bank, in the event that the prices of any proposed items or services have reduced. The Bank and the

IT Vendor would discuss such price benefits mutually. In the event the IT Vendor does not offer the

price benefit to the will have the right to independently procure the same from the market and the IT

Vendor will have no objection to the same.

6.3. Commercial Bids

6.3.1. As per Bid Submission process, Bidders are required to submit commercial quote in a separate

envelope super scribed as ―Commercial Bid for 1-CMT/BMB/2013-14 Dated 17th July 2013 issued

by the Bank for Implementation of CBS at the Bank on ASP Model‖.

6.3.2. The IT Vendor is requested to quote in Indian Rupees (‗INR‘). Bids in currencies other than INR would

not be considered.

6.3.3. The IT Vendor shall only be reimbursed service tax as applicable besides the monthly charges. All other

taxes, direct or indirect, will have to be borne by the IT Vendor. However, service tax, as applicable, will

be reimbursed by the banks.

6.3.4. Bidders in their commercial bid shall indicate ―monthly charge per month per branch‖ for a period of [7

years]. There will be a fixed and a variable component of the charges as indicated in the proforma of the

price bid given in Annexure 16. Total Cost of Operation (TCO) will be calculated by summation of monthly

charges for [7 years] for 500 branches, for the number of months they are operational during the [7 year]

period.

6.3.5. The Bank will not pay any other charges / fees other than the monthly charges payable by the branch only

from the month of going live. For the first month, the charges will on pro-rata basis.

6.3.6. The monthly charges for the branches with CBS will be payable quarterly in arrear for those branches

which have successfully running / or implemented (Signed off) on CBS during that quarter.

6.3.7. The prices quoted by the IT Vendor shall include all costs such as, taxes, VAT, levies, cess, excise

and custom duties, installation, insurance etc. but excluding service tax that need to be incurred. The

prices quoted will also include transportation to respective sites, and insurance in perpetuity final

acceptance by the Bank. The price payable to the IT Vendor shall be inclusive of carrying out any

modifications changes / upgrades to the CBS or other software or equipment that is required to be

made in order to comply with any statutory or regulatory requirements or any industry-wide changes

35

arising during the subsistence of the agreement, and the Bank shall not pay any additional cost for the

same. The IT Vendor needs to provide with the details about all such items considered in the RFP.

6.3.8. In case of any variation (upward or down ward) in excise, custom duty or Government levies pertaining to

the above which is deemed to have been included as part of the price will be borne by the IT Vendor.

The benefit of other taxes mentioned as part of the commercial bid like VAT or Service Tax and levies

thereof due to downward revision shall be passed on or adjusted to the Bank. The Bank would not bear

any additional burden of changes in the taxes apart from what has been specified and mentioned by the IT

Vendor in the commercial bid. If the IT Vendor makes any conditional or vague offers, without

conforming to these guidelines, the Bank will treat the prices quoted as in conformity with these

guidelines and proceed accordingly.

6.3.9. 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 here under by the IT Vendor, for any reason including the

delay or failure or inability of the IT Vendor to make payment for the same, the Bank has to be

reimbursed such amounts paid, on being intimated to the IT Vendor along with the documentary

evidence. If the IT Vendor does not reimburse the amount within a fortnight, Bank shall adjust the

amount out of the payments due to the IT Vendor from the Bank along with the interest calculated at

commercial rate of interest.

6.3.10. Terms of payment indicated in the Purchase Contract that will be issued by the Bank on the selected

Vendor will be final and binding on the IT Vendor and no interest will be payable by the Bank on

outstanding amounts under any circumstances.

6.3.11. The IT Vendors should note that the contract entered with the successful Vendor will be for a period of

[7 years] from the effective date of the Master Agreement to be executed between the IT Vendor and the

bank. The IT Vendor shall continue to support the Bank if the Bank renews the contract thereafter.

However, the Bank will have the right to renegotiate these prices at the end of the contract period.

6.3.12. There will be no advance payments to be made by the Bank.

6.3.13. The IT Vendor must accept the payment terms proposed by the Bank. The commercial bid submitted by

the Bidders must be in conformity with the payment terms proposed by the Bank. Any deviation from the

proposed payment terms would not be accepted. The Bank shall have the right to withhold any payment

due to the IT Vendor, in case of delays or defaults on the part of the IT Vendor. Such withholding of

payment shall not amount to a default on the part of the Bank.

6.3.14. The Bank shall be under no obligation to accept the lowest or any other bid received in response to this

bid notice and shall be entitled to reject any or all bids including those received late or incomplete bids

without assigning any reason whatsoever. The Bank reserves the right to make any changes in the terms

and conditions of purchase.

6.3.15. For commercial evaluation methodologies please refer to Chapter 8 below.

6.4. Price Comparisons

6.4.1. The Bank will consider the Total Cost payable (―TCO‖) over a [7 year] period.

6.4.2. The IT Vendors are expected to maintain the solution and equipment supplied and to commence from the

36

date of acceptance of such solution and equipment by the Bank.

6.4.3. To administer price comparison, the Bank shall compute and compare the total cost of all items or services

for all branches/offices/locations involved for entire [7 year] period, as quoted by the IT Vendors who have

qualified on the technical specifications and hence shortlisted by the Bank. For Price Comparison

methodology, please refer to Section 8 – Evaluation Methodology.

6.4.4. The Price offer shall be on a fixed price basis. Bid submitted with an adjustable price quotation will be

treated as non-responsive and will be liable to be rejected.

6.4.5. The IT Vendor must provide and quote for all normal banking products and services as desired by the

Bank. The list of indicative products would be provided by the Bank before signing the contract.

6.5. Bid Security and Performance Guarantee

6.5.1. Bid Security

The IT Vendor is required to give an interest-free refundable Bid Security amount for INR 50,00,000/-

(INR fifty lakh only) by way of Demand Draft/Pay Order drawn in favour of SBI Capital Markets

Limited (as per Annexure 3) or Bank Guarantee valid for 6 months (as per Annexure 4) along with

Offer. The Bank Guarantee should be of a Scheduled Public Sector/Commercial Bank only and will be

accepted subject to the discretion of the Bank.

Offers made without the Bid Security will be summarily rejected.

6.5.1.1. The amount of bid security would be forfeited in the following scenarios:

6.5.1.2. In case the IT Vendor withdraws the bid prior to validity period of the bid for any reason whatsoever;

6.5.1.3. In case the IT Vendor refuses to accept and sign the contract as specified in this document for any reason

whatsoever; or

6.5.1.4. In case the IT Vendor fails to provide the performance guarantee within 15 days from the date of award

of contract by the Bank for any reason whatsoever.

6.6. Performance Guarantee

6.6.1. The IT Vendor shall provide a performance guarantee in favour of the Bank in the form and manner

provided in Annexure 13 - Proforma for Performance Guarantee equivalent to the extent of 10% of

the TCO for the period of the contract and 90 days thereafter. In the event of non - performance of

obligation or failure to meet terms of this tender, the Bank shall be entitled to invoke the performance

guarantee without notice or right of demur to the IT Vendor. Any amount pending for payment due to

non achieving of milestone/s set under the Agreement or any other reason solely attributable to the IT

Vendor should be included in the remaining amount of the contract value. The guarantee should be of that

of a nationalized bank only.

6.6.2. The project will be deemed complete only when all the solutions and items contracted by the Bank are

delivered in good condition, installed, implemented, tested and accepted along with the associated

documentation and training provided to the Bank employees and on completion of other

obligations as per the contract executed between the Bank and the IT Vendor.

6.6.3. If the performance guarantee is not submitted, the Bank reserves the right to cancel the contract. The

Performance Guarantee would be returned to the IT Vendor after the expiry or termination of the

37

contract.

6.7. Others

6.7.1. Responses to this RFP should not be construed as an obligation on the part of the Bank to award a

purchase contract for any services or combination of services. Failure of the Bank to select a Vendor shall

not result in any claim whatsoever against the Bank and the Bank reserves the right to reject any or all

bids in part or in full, without assigning any reason whatsoever.

6.7.2. By submitting a proposal, the IT Vendor agrees to promptly contract with the Bank for any work

awarded to the IT Vendor. Failure on the part of the awarded IT Vendor to execute a valid contract with

the Bank will relieve the Bank of any obligation to the IT Vendor, and a different IT Vendor may be

selected based on the selection process.

6.7.3. The terms and conditions as specified in the RFP and addendums if any thereafter are final and binding

on the IT Vendors. In the event the IT Vendor is not willing to accept the terms and conditions of the

Bank the IT Vendor may be disqualified.

6.7.4. The IT Vendor must strictly adhere to the delivery dates or lead times identified in their proposal.

Failure to meet these delivery dates, unless it is due to reasons entirely attributable to the Bank,

may constitute a material breach of the IT Vendor‘s performance. In the event that the Bank is forced

to cancel an awarded contract (relative to this RFP) due to the IT Vendor‗s inability to meet the

established delivery dates, that Vendor will be responsible for any re-procurement costs suffered by

the Bank. The liability in such an event would be limited to the amount actually spent by the Bank for

procuring similar deliverables and services. This is after repaying the original amount paid.

6.7.5. The IT Vendor represents and acknowledges to the Bank that it possesses necessary experience, expertise

and ability to undertake and fulfill its obligations, under all phases involved in the performance of the

provisions of this RFP. The IT Vendor represents that all software and hardware to be supplied in

response to this RFP shall meet the proposed IT Vendor solution requirements. The IT Vendor shall

be required to independently arrive at a solution, which is suitable for the Bank, after taking into

consideration the effort estimated for implementation of the same. If any services, functions or

responsibilities not specifically described in this RFP are an inherent, necessary or customary part of

the deliverables or services and are required for proper performance or provision of the

deliverables or services in accordance with this RFP, they shall be deemed to be included within the

scope of the deliverables or services, as if such services, functions or responsibilities were specifically

required and described in this RFP and shall be provided by the IT Vendor at no additional cost to the

Bank. The IT Vendor also acknowledges that the Bank relies on this statement of fact, therefore neither

accepting responsibility for, nor relieving the IT Vendor of responsibility for the performance of all

provisions and terms and conditions of this RFP, the Bank expects the IT Vendor to fulfill all the terms

and conditions of this RFP. The modifications, which are accepted by the Bank, shall form a part of the

final contract.

6.7.6. The IT Vendor represents that the proposed software solution and its documentation and/or use of the

same by the Bank shall not violate or infringe the rights of any third party or the laws or regulations under

any governmental or judicial authority. The IT Vendor further represents that the documentation to be

provided to the Bank shall contain a complete and accurate description of the software, hardware and

other materials and services (as applicable), and shall be prepared and maintained in accordance with

the highest industry standards. The IT Vendor represents and agrees to obtain and maintain validity

throughout the project, of all appropriate registrations permissions and approvals, which are statutorily

required to be obtained by the IT Vendor for performance of the obligations of the IT Vendor. The IT

38

Vendor further agrees to inform and assist the Bank for procuring any registrations, permissions or

approvals, which may at any time during the Contract Period be statutorily required to be obtained by

the Bank for availing services from the IT Vendor.

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

IT Vendor. The Bank shall not be responsible for any judgments made by the IT Vendor with respect to

any aspect of the Assignment. The IT Vendor shall at no point be entitled to excuse themselves from any

claims by the Bank whatsoever for their deviations in confirming to the terms and conditions, payments

schedules, expected service levels, time frame for implementation etc. as mentioned in this RFP.

6.7.7.1. The Bank and the IT Vendor covenants and represents to the other Party the following:

6.7.7.1.1. It is duly incorporated, validly existing and in good standing under as per the laws of the state in which

such Party is incorporated.

6.7.7.1.2. It has the right and authority to enter into Agreements and perform its obligations there under. The

execution, delivery and performance of terms and conditions under Agreements by such Party and the

performance of its obligations there under are duly authorized and approved by all necessary action

and no other action on the part of such Party is necessary to authorize the execution, delivery and

performance under an Agreement.

6.7.7.1.3. The execution, delivery and performance under an Agreement by such Party:

6.7.7.1.4. Will not violate or contravene any provision of its documents of incorporation;

6.7.7.1.5. Will not violate or contravene any law, statute, rule, regulation, licensing requirement, order, writ,

injunction or decree of any court, governmental instrumentality or other regulatory, governmental or

public body, agency or authority by which it is bound or by which any of its properties or assets are

bound;

6.7.7.1.5.1. Except to the extent that the same have been duly and properly completed or obtained, will not

require any filing with, or permit, consent or approval of or license from, or the giving of any

notice to, any court, governmental instrumentality or other regulatory, governmental or public body,

agency or authority, joint venture party, or any other entity or person whatsoever;

6.7.7.1.5.2. To the best of its knowledge, after reasonable investigation, no representation or warranty by such Party

in this tender and subsequent Agreement, and no document furnished or to be furnished to the other

Party to this tender and subsequent Agreement, or in connection herewith or with the transactions

contemplated hereby, contains or will contain any untrue or misleading statement or omits or will omit

any fact necessary to make the statements contained herein or therein, in light of the circumstances

under which made, not misleading. There have been no events or transactions, or facts or information

which has come to, or upon reasonable diligence, should have come to the attention of such Party and

which have not been disclosed herein or in a schedule hereto, having a direct impact on the

transactions contemplated hereunder.

6.7.7.1.6. The IT Vendor undertakes to provide appropriate human as well as other resources required, to

execute the various tasks assigned as part of the project, from time to time. The Bidder has to submit

the details of key project personnel as part of the Bid Document. In case the key management

personnel or key project personnel leaves the IT Vendor‘s organization or is unavailable to work on

the project for any reason, the IT Vendor will have to ensure provision of suitable replacement of

manpower of similar qualification of experience to continue the project. The complete detail of the

39

human resources will be arrived at as part of the contract and SLA.

6.7.7.1.7. The Bank would not assume any expenses incurred by the IT Vendor in preparation of the response to

this RFP and also would not return the bid documents to the IT Vendor.

6.7.7.1.8. The Bank will not bear any costs incurred by the IT Vendor for any discussion, presentation,

demonstrations etc. on proposals or proposed contract or for any work performed in connection

therewith.

6.7.8. Other RFP Requirements

6.7.8.1. The Bank reserves the right to change any terms and conditions of the RFP and its subsequent addendums,

as it deems necessary at its sole discretion. The Bank will inform all Vendors of the changes, if any.

6.7.8.2. The Bank may revise any part of the RFP, by providing a written addendum to all the short –listed

Vendors at stage till the award of the contract. The Bank reserves the right to issue revisions to this RFP

at any time before the award date.

6.7.8.3. The Bank reserves the right to extend the dates for submission of responses to this document.

6.7.8.4. The IT Vendor shall have the opportunity to clarify doubts pertaining to the RFP in order to clarify

any issues they may have, prior to finalizing their responses. All questions are to be submitted to the

RFP coordinator at the address mentioned in Section 2.6, and should be received by the point of contact

no later than the timeline specified. Responses to inquiries and any other corrections and

amendments will be distributed to all Vendors by fax or in electronic mail format.

6.7.8.5. Secured product report - It is essential for the IT Vendor to certify that all security requirements of the

proposed application & database for the purpose of this project, are meeting the Bank's security

requirements. The IT Vendor should provide the report stating the proposed solution is secured. This

would include denying access to unauthorized users, denying access to functions that have not been

given access to etc. This assessment should have been done by an independent and reputed agency.

Preliminary Scrutiny - the Bank will scrutinize the offers to determine whether they are complete,

whether any errors have been made in the offer, whether required technical documentation has been

furnished, whether the documents have been properly signed, and whether items are quoted as per the

schedule. The Bank may, at its discretion, waive any minor non-conformity or any minor deficiency in

an offer. This shall be binding on all Vendors and the Bank reserves the right for such waivers and the

Bank's decision in the matter will be final.

6.7.8.6. Clarification of Offers - To assist in the scrutiny, evaluation and comparison of offers, the Bank

may, at its discretion, ask some or all Vendors for clarification of their respective offers. The Bank

has the right to disqualify the IT Vendor whose clarification is found not suitable to the proposed

project.

6.7.8.7. No Commitment to Accept Lowest bid or Any Tender - The Bank shall be under no obligation to

accept the lowest price bid or any other offer received in response to this tender notice and shall be

entitled to reject any or all offers including those received late or incomplete offers without assigning

any reason whatsoever. The Bank reserves the right to make any changes in the terms and conditions of

purchase. The Bank will not be obliged to meet and have discussions with any IT Vendor, and / or to

listen to any representations.

6.7.8.8. Erasures or Alterations - The offers containing erasures or alterations will not be considered. There

should be no hand-written material, corrections or alterations in the offer. Filling up of the information using

40

terms such as ―OK”, ―accepted”, ―noted”, ―as given in brochure / manual” is not acceptable. The Bank may

treat the offers not adhering to these guidelines as unacceptable. The proposals should be in the template

that is recommended and provided in this RFP.

6.7.8.9. It is absolutely essential for the IT Vendors to quote the lowest price at the time of making the offer in

their own interest.

6.7.8.10. Vendor presentation – The IT Vendors are requested to be prepared to demonstrate the proposed

solution and make presentations and arrange for site visits if required as part of the final evaluation in

accordance with the responses given for the identified requirements, any time after the last date for

submissions of bids. The Bank will communicate a date and time to all qualified Vendors any time after

the last date for submission of bids.

6.7.8.11. Details of Sub-contracts, as applicable - If required by the Bank, Vendors should provide complete

details of any sub-contractor/s used for the purpose of this engagement. It is clarified that

notwithstanding the use of sub contractors by the IT Vendor, the IT Vendor shall be solely responsible

for performance of all obligations under the RFP irrespective of the failure or inability of the

subcontractor chosen by the IT Vendor to perform its obligations. The IT Vendor shall also have the

responsibility for payment of all dues and contributions, as applicable, towards statutory benefits for its

employees and sub-contractors.

6.7.8.12. The IT Vendor shall submit solution architecture document including server, storage, network and

security components. All reasonable facilities, tools and assistance including access to drawings

and production data should be provided to the Bank‘s officials and the consultants during review. There

shall not be any additional charges for such review. It is expected that the equipment should be ready for

review before end of October, 2013 from the date of awarding the contract by the Bank. If the IT Vendor

fails to do so, the Bank reserves the right to levy penalty, as specified in the SLA.

6.7.8.13. No site will be accepted as complete if any part of hardware, software, network components etc. are not

delivered, and if delivered not installed, and operationalized free of any additional cost to the Bank. In

such an event, the supply and installation will be termed incomplete and will not be

accepted and warranty period will not commence besides the Bank‘s right to invoke the penalties,

which will be prescribed in the contract. Every site will be accepted after complete commissioning of

equipment, functioning of equipment & the network link for a minimum period of 30 days.

6.7.8.14. The IT Vendor is responsible for managing the activities of its personnel or the personnel of its

subcontractors/franchisees and will be accountable for both. The IT Vendor shall be vicariously liable for

any acts, deeds or things done by their employees, agents, contractors, subcontractors etc. which is

outside the scope of power vested or instructions issued by the Bank/. Vendor shall be

the principal employer of the employees, agents, contractors, subcontractors etc. engaged by Vendor

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 purchase contract to be issued for this tender.

6.7.8.15. No right of any employment shall accrue or arise, by virtue of engagement of employees, agents,

contractors, subcontractors etc. by the IT Vendor, for any assignment under the purchase contract to be

issued for this tender. All remuneration, claims, wages, dues etc of such employees, agents,

contractors, subcontractors etc. of Vendor shall be paid by Vendor alone and the Bank

shall not have any direct or indirect liability or obligation, to pay any charges, claims or wages of any of

IT Vendor‗s employee, agents, contractors, and subcontractors. The IT Vendor shall hold the

Bank, its successors, Assignees and Administrators fully indemnified and harmless

against loss or liability, claims actions or proceedings, if any, that may arise from whatsoever nature

41

caused to the Bank through the action of its employees, agents, contractors,

subcontractors etc. However, the IT Vendor would be given an opportunity to be heard by

the Bank prior to making of a decision in respect of such loss or damage.

6.7.8.16. The Bank shall inform the IT Vendor of all known breaches and claims of indemnification and shall grant

the IT Vendor sole authority to defend, manage, negotiate or settle such claims; and make available all

reasonable assistance in defending the claims (at the expense of the IT Vendor). The written demand by the

Bank as to the loss / damages mentioned above shall be final, conclusive and binding on the IT Vendor and

Vendor shall be liable to pay on demand the actual amount of such loss / damages caused to the Bank.

6.7.8.17. In respect of demands levied by the Bank on the IT Vendor towards breaches, claims, etc. the Bank shall

provide the IT Vendor with details of such demand levied by the Bank.

6.7.8.18. For the purposes of this Clause, the indemnity may be restricted to the areas mentioned, i.e., ―claims arising

out of employment, non-payment of remuneration and non-provision of statutory benefits by the IT

Vendor to its employees, its agents, contractors and sub contractors.‖ However, there are other

indemnities such as indemnity for IPR (Intellectual Property Rights) violation, confidentiality breach,

etc, that the IT Vendor is expected to provide as per the RFP.

6.7.8.19. Indemnity would be limited to court or arbitration awarded damages and shall exclude indirect,

consequential and incidental damages. However indemnity would cover damages, loss or liabilities

suffered by the Bank arising out of claims made by its customers and/or regulatory authorities.

6.7.8.20. The Vendor‗s designated representative and local office will be the contact point for the

Bank.

6.7.8.21. Vendor should ensure that the hardware installed in the Bank including all components and attachments

are brand new. In case of software supplied with the system, the IT Vendor should ensure that the

same is licensed and legally obtained with valid documentation made available to the Bank.

6.7.8.22. The IT Vendor shall procure all user specific software licenses for the Bank, its offices and its

branches based users at the branches and offices as the case may be. The IT Vendor shall provide the

licenses for all software being a part of its proposed solution to the Bank. The IT Vendor shall

indemnify, protect and save the Bank against all claims, losses, costs, damages, expenses, action, suits

and other proceedings, resulting from infringement of any patent, trademarks, copyrights etc or such

other statutory infringements under any laws including the Copyright Act, 1957 or Information

Technology Act 2000 in respect of all the hardware, software and network equipments or other systems

supplied under ASP model by them to the Bank from whatsoever source, provided the Bank/ notifies the

IT Vendor in writing as soon as practicable when the Bank becomes aware of the claim however, (i) the

IT Vendor has sole control of the defense and all related settlement negotiations (ii) the Bank provides

the IT Vendor with the assistance, information and authority reasonably necessary to perform the above

and (iii) the Bank does not make any statements or comments or representations about

the claim without the prior written consent of the IT Vendor, except where the Bank is

required by any authority/regulator to make a comment/statement/representation. Indemnity would be

limited to court or arbitration awarded damages and shall exclude indirect, consequential and

incidental damages. However indemnity would cover damages, loss or liabilities suffered by

the Bank arising out of claims made by its customers, third party and/or regulatory

authorities due to the failure of the IT Vendor to perform its obligations or breach/infringement of any

rights thereof .

6.7.8.23. The final selected IT Vendor will have to demonstrate and report that the proposed solution provides the

required service levels in terms of number of the necessary Transactions per Second and concurrent

42

users, where all the debit and credit legs of the transaction would be considered as a single transaction,

along with the necessary number of concurrent transactions, total number of transactions, number

of accounts, time taken for End of Day, batch processing and meet the required response time as

expected by the Bank. This report should be carried out on the proposed hardware with the proposed

version of the operating system, proposed version of the database system and the proposed version of

the application system.

6.7.8.24. The IT Vendor shall ensure that the solution provided and sized by the IT Vendors is capable of

meeting the Bank‘s current and future transaction and business volumes.

6.7.8.25. The IT Vendors and/or its authorized service providers should have their own employees for

execution of projects. However, the IT Vendor will be fully responsible for the service of the

service providers. The Bank will not make any reference to them. In case of any deficiency in service,

penalties will be to Vendor‗s account.

6.7.8.26. The IT Vendor shall perform its obligations under this tender as an independent contractor, and may

engage subcontractors to perform any of the Deliverables or Services. Neither this tender nor the

IT Vendor‗s performance of obligations under this tender shall create an association, partnership, joint

venture, or relationship of principal and agent, master and servant, or employer and employee,

between the Bank and the IT Vendor or its employees, subcontractor; and neither Party

shall have the right, power or authority (whether expressed or implied) to enter into or assume any

duty or obligation on behalf of the other Party. The Bank will only approve any change

in sub-contractors proposed by the IT Vendor during the contract period of the project of [7 years].

6.7.8.27. The IT Vendor shall solely be responsible for all payments (including any statutory payments) to its

employees and / or sub contractors and shall ensure that at no time shall its employees, personnel or

agents hold themselves out as employees or agents of the Bank, nor seek to be treated as employees of

the Bank for any purpose, including claims of entitlement to fringe benefits provided by the Bank, or for

any kind of income or benefits. The IT Vendor alone shall file all applicable tax returns for all of its

personnel assigned hereunder in a manner consistent with its status as an independent contractor of

services; and the IT Vendor will make all required payments and deposits of taxes in a timely manner.

6.7.9. Confidentiality

6.7.9.1. The Parties acknowledge that in the course of performing the obligations under this Tender and

subsequent Agreement, each party shall be exposed to or acquire information of the other party, which

such party shall treat as confidential. Neither party shall disclose the Confidential Information to a

third party.

6.7.9.2. The Parties will, at all times, maintain confidentiality regarding the contents of this Tender and

subsequent Agreement and proprietary information including any business, technical or financial

information that is, at the time of disclosure, designated in writing as confidential, or would be understood

by the Parties, exercising reasonable business judgment, to be confidential.

6.7.9.3. The Parties agree to keep in confidence and not disclose to any third party any and all Confidential

Information available to the Parties, whether such information is given in writing or, is oral or visual,

and whether such writing is marked to indicate the claims of ownership and/or secrecy or otherwise.

Except as otherwise provided in this tender, the Parties agree that it shall not use, nor reproduce for

use in any way, any Confidential Information. The Parties agrees to protect the Confidential

Information of the other with at least the same standard of care and procedures used by to protect its

own Confidential Information of similar importance but at all times using at least a reasonable degree

of care.

43

6.7.9.4. If the IT Vendor hires another person to assist it in the performance of its obligations under this RFP, or

assigns any portion of its rights or delegates any portion of its responsibilities or obligations under this

tender and subsequent Agreement to another person, it shall cause its assignee or delegate to be bound to

retain the confidentiality of the Confidential Information in the same manner as the IT Vendor is

bound to maintain the confidentiality.

6.7.9.5. This shall not be applicable and shall impose no obligation on the receiving party with respect to any

portion of Confidential Information which:

6.7.9.5.1. Was at the time received or which thereafter becomes, through no act or failure on the part of the

receiving party, generally known or available to the public;

6.7.9.5.2. Is known to the receiving party at the time of receiving such information as evidenced by

documentation then rightfully in the possession of the receiving party;

6.7.9.5.3. Is furnished by others to the receiving party without restriction of disclosure;

6.7.9.5.4. Is thereafter rightfully furnished to the receiving party by a third party without restriction by that third

party on disclosure;

6.7.9.5.5. Has been disclosed pursuant to the requirements of law or court order without restrictions or other

protection against public disclosure; or

6.7.9.5.6. Independently developed by the receiving party without the help of the Confidential Information.

6.7.9.5.7. On termination of the tender and subsequent Agreement, each party must immediately return to the

other party or delete or destroy all Confidential Information of the other party and all notes and

memoranda (including copies of them) containing Confidential Information of the other party in its

possession or control save for that training materials and Documentation that has been provided to

the Bank which is contemplated for continued realization of the benefit of the Services.

Notwithstanding the foregoing, Vendor may retain a copy of such information (but which shall not

include customer data and Confidential Information) as may be necessary for archival purpose.

6.7.9.5.8. The IT Vendor recognizes and agrees that breach of the confidentiality Article by the Bank shall not be

construed as material breach for the purposes of this tender.

6.8. Terms of Reference

6.8.1. Contract Commitment

The Bank intends that the contract, which is contemplated herein with the IT Vendor, shall be for a

period of [7 years] starting from the effective date of the Master Agreement to be executed between the

Bank and the selected IT Vendor.

6.8.2. Customization process

The IT Vendor shall ensure that the software provided as a part of the Core Banking Project meets all the

requirements described in detail in this RFP and to carry out all such customization or development

work as may be required by the Bank at no additional License Charge or Fees or

Expenses. The IT Vendor shall provide all the MIS reports as per the requirements of the

the Bank. The precise scope of the customization and development work to be

undertaken by the IT Vendor shall be as per the requirements of the Bank/ as described in

the above mentioned Annexures. The IT Vendor shall carry out all the customization related work at the

44

Project Office of the Bank or offsite in case the customization cannot be carried out at the Bank

premises. The Bank shall be a party to the Functional Specifications requirement sign-off, User

acceptance test, User acceptance test sign-off, Installation sign-off and Implementation sign-off. The

IT Vendor shall install and commission the software for customization and User Acceptance Test as per

Project Plan to be agreed with the Bank failing which the IT Vendor shall be liable to pay

the Bank penalty to be defined as per this RFP. The IT Vendor shall provide all tools, testing

instruments, drivers, consumables, etc. required to install and customize and test the software free of

any fees or charges or any expenses. The IT Vendor shall document and submit to

the Bank all the testing activities, procedures and results. The IT Vendor shall be required

to ensure that the software provides interfaces to the other application systems at

the Bank as specified in Annexure 6 at no additional cost or fees or charges or

expenses. The IT Vendor shall provide the Bank weekly progress report on the

bugs/problems reported/points taken up with schedule of date of reporting, date of resolving, and

status for all kind of bugs and problems whether reported by branch/ Head Office or Vendor staff. In

case of disputes relating to resolution of problem relating to any site, the IT Vendor is required to send

the copy of call report pertaining to each visit of each of the engineer to the said site indicating the

purpose of call, when called, when visited, when problem was resolved, how resolved, etc.

6.8.3. Installation and Implementation

The IT Vendor needs to ensure that the scope of work for implementation of the software includes

creating master data at the Data Center, functional requirements specifications study, data conversion,

live cut-over, customization, configuration, installation, implementation and integration of the software.

The precise nature and scope of the activities and functions to be undertaken for installation and

implementation of the licensed software have been detailed and set out in Section 4 of this tender

document.

6.9. Payment terms

6.9.1. The IT Vendor must accept the payment terms proposed by the Bank. The commercial bid submitted by

the Bidders must be in conformity with the payment terms proposed by the Bank. Any deviation from the

proposed payment terms would not be accepted. The Bank shall have the right to withhold any payment

due to the IT Vendor, in case of delays or defaults on the part of the IT Vendor. Such withholding of

payment shall not amount to a default on the part of the Bank.

6.9.2. The monthly charges for the branches with CBS will be payable quarterly on pro-rata basis for only those

branches which have successfully running / or implemented (Signed off) on CBS during that quarter.

6.9.3. Penalties as per breach of Service Levels shall be calculated as per SLA.

6.9.4. The IT Vendor recognizes that all payments to the IT Vendor under this RFP and subsequent agreement

are linked to and dependant on successful achievement and acceptance of 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 such corresponding payment.

6.9.5. The fees payable by the Bank to the IT Vendor shall be inclusive of all costs such as insurance, taxes

(including service tax, as per the rates applicable), custom duties, 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”), as applicable. The IT Vendor will need to provide the details for the tax rates as considered

in the pricing. This will be used for subsequent tax changes.

45

6.9.6. The Bank shall pay each undisputed invoice raised in accordance with this RFP and subsequent agreement,

within 30 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.

6.9.7. Any objection / dispute to the amounts invoiced in the bill shall be raised by the Bank within reasonable

time as may be decided mutually 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 30 days of the settlement of such

disputes.

6.9.8. All out of pocket expenses, traveling, boarding and lodging expenses for the entire Term of this RFP and

subsequent agreement is included in the amounts and the IT Vendor 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.

6.9.9. All the payments becoming due during each of the quarters of the contract period will be paid at the end of

the respective quarter.

6.9.10. Delivery, implementation and Roll out

The IT Vendor shall be responsible for delivery; implementation and rollout of all the solutions required

under this RFP and also must agree to the time duration specified in Section ―Project Timelines”

of this document.

In the event of Vendor‗s failure to deliver and / or implement all required components of a fully functional

system (pertaining to the scope of the project) within the stipulated time schedule or by the date extended

by the Bank, unless such failure is due to reasons entirely attributable to the Bank, it will be

a breach of contract. In such case, the Bank would be entitled to charge a penalty, as specified in this

RFP.

6.9.11. Completeness of the project

The project will be deemed incomplete when the mutually agreed acceptance and completion criteria are

incomplete or not met or not fulfilled. The Bank reserves the sole right to accept or reject the acceptance of

any product / service in the event the agreed acceptance and completion criteria are not met by the IT

Vendors.

6.9.12. Compliance with Laws

Compliance with all applicable laws: The IT Vendor shall undertake to observe, adhere to, abide by,

comply with and notify the Bank about all laws in force or as are or as made applicable in future,

pertaining to or applicable to them, their business, their employees or their obligations towards them and all

purposes of this tender and shall indemnify, keep indemnified, hold harmless, defend and protect

the Bank and its employees/officers/staff/ personnel/representatives/agents from any failure or omission on

its part to do so and against all claims or demands of liability and all consequences that may occur or arise

for any default or failure on its part to conform or comply with the above and all other statutory

obligations arising there from.

Compliance in obtaining approvals/permissions/licenses: The IT Vendor shall promptly and timely obtain

all such consents, permissions, approvals, licenses, etc, as may be necessary or required for any of

the purposes of this project or for the conduct of their own business under any applicable Law,

Government Regulation/Guidelines and shall keep the same valid and in force during the term of the

project, and in the event of any failure or omission to do so, shall indemnify, keep indemnified, hold

46

harmless, defend, protect and fully compensate the Bank and its employees/ officers/ staff/

personnel/ representatives/agents from and against all claims or demands of liability and all

consequences that may occur or arise for any default or failure on its part to conform or comply with

the above and all other statutory obligations arising there from and the Bank will give notice of any such

claim or demand of liability within reasonable time to the IT Vendor.

This indemnification is only a remedy for the Bank/. The IT Vendor is not absolved from its

responsibility of complying with the statutory obligations as specified above. Indemnity would be

limited to court and arbitration awarded damages and shall exclude indirect, consequential and incidental

damages. However indemnity would cover damages, loss or liabilities suffered by the Bank arising out of

claims made by its customers and/or regulatory authorities.

6.9.13. Assignment

The IT Vendor agrees that the IT Vendor shall not be entitled to assign any or all of its rights and or

obligations under this tender and subsequent Agreement to any entity including IT Vendor‗s affiliate

without the prior written consent of the Bank.

If the Bank undergoes a merger, amalgamation, takeover, consolidation, reconstruction, change of

ownership, etc., this RFP shall be considered to be assigned to the new entity and such an act shall not

affect the rights of the IT Vendor under this RFP.

6.9.14. Insurance

The IT Vendor shall procure insurance coverage to include comprehensive general liability insurance, third

party accident insurance and all risk property insurance in respect of the Services provided by the IT

Vendor under this tender and subsequent Agreement to insure the Deliverables and the Bank against losses

arising out of this tender and subsequent Agreement and such insurance shall be valid until the point of

finally accepted by the Bank.

The IT Vendor shall cause its insurers to issue certificates of insurance evidencing that the coverage

and policy endorsements required under this RFP are maintained in force and that not less than 30 days

written notice shall be given to the Bank prior to any modification, cancellation, or nonrenewal of the

policies. The IT Vendor shall provide copies of the insurance to the Bank. The insurers selected by the IT

Vendor shall be of good standing and authorized to conduct business in all jurisdictions in which this

tender and subsequent Agreement is to be performed.

In the case of loss or damage or other event that requires notice or other action under the terms of any

insurance coverage, the IT Vendor shall be solely responsible to take such action. The IT Vendor shall

provide the Bank with contemporaneous notice and with any other information that the

the Bank may request regarding such event. The Bank shall provide to the IT Vendor reasonable

assistance and cooperation, at the IT Vendors expense, with respect to any insurance claim. The IT

Vendor shall not hold the Bank responsible for rejection of the insurance claims of the IT Vendor by the

insurer.

The IT Vendor‘s obligation to maintain insurance coverage hereunder shall be in addition to, and not in

lieu of, the IT Vendor‘s other obligations hereunder, and the IT Vendor‗s liability to the Bank shall not be

limited to the amount of coverage required hereunder.

6.9.15. Order Cancellation

The Bank will provide the IT Vendor a remedy period of 7 days to rectify a default or given

47

situation. The Bank will provide in writing the nature of the default to the IT Vendor through a

letter or mail correspondence. The 7 day time period will commence from the day the Bank

has sent such correspondence to the IT Vendor.

The Bank reserve its right to cancel the order in the event of one or more of the following

situations that are not occasioned due to reasons solely and directly attributable to the Bank

alone:

6.9.15.1. Failure of the successful bidder to accept the contract and furnish the Performance Guarantee within 15

days of receipt of purchase contract;

6.9.15.2. Delay in customization / implementation / installation beyond the specified period that is agreed in the

contract that will be signed with the successful Vendor; and

6.9.15.3. Serious discrepancy in the quality of service / hardware/ software expected during implementation

and rollout.

6.9.15.4. In the event of such cancellation of orders, the Bank will be entitled to any specific penalty charts without

any prejudice to the rights and remedies available under indemnity clause and performance bank

guarantee.

6.9.15.5. After cancellation the vendor will continue to provide services up to the transitory period up to which a

new vendor is signed as decided by the Bank.

6.9.16. Indemnity

The IT Vendor hereby indemnifies the Bank, and shall always keep indemnified and hold the Bank, its

employees, personnel, officers, directors, (hereinafter collectively referred to as ―Personnel”) harmless from

and against any and all losses, liabilities, claims, actions, costs and expenses (including attorneys' fees)

relating to, resulting directly or indirectly from or in any way arising out of any claim, suit or proceeding

brought against the Bank as a result of:

The Bank‘s authorized / bona fide use of the Deliverables and /or the Services provided by IT Vendor

under this RFP; and/or

An act or omission of the IT Vendor, employees, agents, sub contractors in the performance of the

obligations of the IT Vendor under this RFP; and/or

Claims made by employees or subcontractors or subcontractors‗ employees, who are deployed by the

Vendor, against the ; and/or

Breach of any of the term of this RFP or breach of any representation or false representation or

inaccurate statement or assurance or covenant or warranty of the IT Vendor under this RFP; and/or

Any or all Deliverables or Services infringing any patent, trademarks, copyrights or such other

Intellectual Property Rights; and/or

Breach of confidentiality obligations of the IT Vendor contained in this RFP; and/or

Negligence or gross misconduct attributable to the IT Vendor or its employees or sub-contractors.

The IT Vendor shall at its own cost and expenses defend or settle any claim against the

the Bank that the Deliverables and Services delivered or provided under this RFP infringe a

patent, utility model, industrial design, copyright, trade secret, mask work or trade mark in the country

48

where the Deliverables and Services are used, sold or received, provided the Bank:

(i) Notifies the IT Vendor in writing; and

(ii) Cooperates with the IT Vendor in the defense and settlement of the claims.

The IT Vendor shall compensate the Bank for such financial loss, direct and remote,

suffered by the Bank if the IT Vendor fails to fix bugs, provide the modifications / enhancements /

customization as required by the Bank as per the terms and conditions of this tender and subsequent

Agreement and to meet the service levels.

The Bank would ensure that Bank does hereby indemnify the IT Vendor, and shall always keep

indemnified and hold the IT Vendor harmless from and against any and all losses, liabilities, claims, actions,

costs and expenses (including reasonable attorneys' fees) relating to, resulting directly or indirectly from or

in any way arising out of any claim, suit or proceeding brought by third-parties against the IT Vendor as a

result of:

Third party infringement claims resulting from unauthorized equipment modification by the

Bank or equipment use prohibited by specifications for hardware and Software;

Third-party infringement claims resulting from a breach of Software license terms in respect of

software directly supplied by the IT Vendor.

The IT Vendor shall not be liable for defects or non-conformance resulting from: Unauthorized

modification, use or operation of the Core Banking Suite of Software

Or any individual product supplied under this RFP

6.9.17. Inspection of Records

All IT Vendor records with respect to any matters covered by this tender shall be made available to

the Bank or its designees at any time during normal business hours, as often as

the Bank deems necessary, to audit, examine, and make excerpts or transcripts of all relevant

data. Said records are subject to examination. The Bank/ auditors would execute

confidentiality agreement with the IT Vendor, provided that the auditors would be permitted to submit their

findings to the Bank, which would be used by the Bank. The cost of the

audit will be borne by the Bank. The scope of such audit would be limited to Service Levels

being covered under the contract, and financial information would be excluded from such inspection, which

will be subject to the requirements of statutory and regulatory authorities. The IT Vendor‗s records and sites

managed for the Bank shall also be subject to RBI / the Bank/ inspection or any other regulatory

authorities.

6.9.18. Publicity

Any publicity by the IT Vendor in which the name of the Bank‘s to be used should be done only with the

explicit written permission of the Bank

6.9.19. Solicitation of Employees

Both the parties (The IT Vendor and the Bank) agree not to hire, solicit, or accept solicitation

(either directly, indirectly, or through a third party) for their employees directly involved in this contract

during the period of the contract and one year thereafter, except as the parties may agree on a case -by-case

49

basis. The parties agree that for the period of the contract and one year thereafter, neither party will cause

or permit any of its directors or employees who have knowledge of the agreement to directly or indirectly

solicit for employment the key personnel working on the project contemplated in this proposal except with

the written consent of the other party. The above restriction would not apply to either party for hiring such key

personnel who (i) initiate discussions regarding such employment without any direct or indirect

solicitation by the other party (ii) respond to any public advertisement placed by either party or its affiliates in

a publication of general circulation or (iii) has been terminated by a party prior to the commencement of

employment discussions with the other party.

6.9.20. Penalty

6.9.20.1. The Bank expects the IT Vendor to complete the scope of the project as mentioned in Section 4 within

the timeframe specified in this RFP. Inability of the IT Vendor to either provide the requirements as per

the scope or to meet the timelines as specified would be treated as breach of contract and would

invoke the penalty clause. The proposed rate of penalty would be as mentioned in the SLA. Overall cap

for penalties will be 10% of the contract value. In the event the project timeframes are impacted due to

delays caused solely by the Bank, the IT Vendor will be given additional time (proportionate to the time

lost due to the delay) to complete the activity and further the IT Vendor will not be responsible for any

penalties for such delay or resultant extension.

6.9.20.2. Inability of the IT Vendor to provide services at the service levels defined as per service levels defined in

the SLA would result in breach of contract and would invoke the penalty clause. The proposed

penalty has been specified in the SLA. Overall cap for penalties will be 10% of the contract value

6.9.20.3. Notwithstanding anything contained above, no such penalty will be chargeable on the IT Vendor for the

inability occasioned, if such inability is due to reasons entirely attributable to the Bank.

6.9.20.4. Notwithstanding what is mentioned hereinabove or anywhere else in the RFP, the maximum amount that

may be levied by way of penalty shall on no account exceed 10 % of the Total Contract value and the

contract value will be determined at the time of contract finalization.

6.9.20.5. The right to invoke the penalty clause is in addition to and without prejudice to other right available to

the Bank such as termination of contract, invocation of indemnity and recovery of amount paid etc.

6.9.20.6. After cancellation the vendor will continue to provide services up to the transitory period up to which a

new vendor is signed as decided by the Bank.

6.9.21. Information ownership

All information and data processed, stored, or transmitted by the IT Vendor belongs to the Bank. By

having the responsibility to host infrastructure under ASP model, the IT Vendor does not acquire

implicit access rights to the information or rights to redistribute the information. The IT Vendor

understands that civil, criminal, or administrative penalties may apply for failure to protect information

appropriately.

6.9.22. Sensitive Information

Any information considered sensitive must be protected by the IT Vendor from unauthorized disclosure,

modification or access. Types of sensitive information that will be found on the Bank‘s system the IT

Vendor may support or have access to include, but are not limited to: Information subject to special

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

criminal investigations, etc.

50

6.9.23. Privacy and security safeguards

The IT Vendor shall not publish or disclose in any manner, without the Bank‘s prior written

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

under this contract. The IT Vendor shall develop procedures and

implementation plans to ensure that IT resources leaving the control of the assigned user (such as being

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

application software. The IT Vendor shall also ensure that all subcontractors who are involved in

providing such security safeguards or part of it shall not publish or disclose in any manner, without the

Bank‘s prior written consent, the details of any security safeguards designed, developed, or

implemented by the IT Vendor under this contract.

6.9.24. Confidentiality

―Confidential Information” means any and all information that is or has been received by the IT Vendor

(―Receiving Party”) from the Bank (―Disclosing Party”) and that: relates to the Disclosing Party; and is

designated by the Disclosing Party as being confidential or is disclosed in circumstances where the

Receiving Party would reasonably understand that the disclosed information would be confidential or is

prepared or performed by or on behalf of the Disclosing Party by its employees, officers, directors,

agents, representatives or consultants.

Without limiting the generality of the foregoing, Confidential Information shall mean and include any

information, data, analysis, compilations, notes, extracts, materials, reports, drawings, designs,

specifications, graphs, layouts, plans, charts, studies, memoranda or other documents, or materials

relating to the licensed software, the modules, the program documentation, the source codes, the

object codes and all enhancements and updates, services, systems processes, ideas, concepts,

formulas, methods, know how, trade secrets, designs, research, inventions , techniques, processes,

algorithms, schematics, testing procedures, software design and architecture, computer code, internal

documentation, design and function specifications, product requirements, problem reports, analysis and

performance information, business affairs, projects, technology, finances (including revenue

projections, cost summaries, pricing formula), clientele, markets, marketing and sales programs, client and

customer data, appraisal mechanisms, planning processes etc. or any existing or future plans, forecasts

or strategies in respect thereof.

―Confidential Materials” shall mean all tangible materials containing Confidential Information,

including, without limitation, written or printed documents and computer disks or tapes, whether

machine or user readable.

Information disclosed pursuant to this clause will be subject to confidentiality for the term of contract plus

two years.

Nothing contained in this clause shall limit the IT Vendor from providing similar services to any third

parties or reusing the skills, know-how and experience gained by the employees in providing the

services contemplated under this clause, provided further that the IT Vendor shall at no point

use the Bank‘s confidential information or Intellectual property.

6.9.24.1. The Receiving Party shall, at all times regard, preserve, maintain and keep as secret and confidential all

Confidential Information and Confidential Materials of the Disclosing Party howsoever obtained and

agrees that it shall not, without obtaining the written consent of the Disclosing Party:

6.9.24.2. Disclose, transmit, reproduce or make available any such Confidential Information and materials to

any person, firm, Company or any other entity other than its directors, partners, advisers, agents or

51

employees, sub contractors and contractors who need to know the same for the purposes of

maintaining and supporting the Software provided as a part of centralized Banking Project. The

Receiving Party shall be responsible for ensuring that the usage and confidentiality by its directors,

partners, advisers, agents or employees, sub contractors and contractors is in accordance with the

terms and conditions and requirements of this tender; or

6.9.24.3. Unless otherwise agreed herein, use of any such Confidential Information and materials for its own

benefit or the benefit of others or do anything prejudicial to the interests of the Disclosing Party or its

customers or their projects.

6.9.24.4. In maintaining confidentiality hereunder the Receiving Party on receiving the confidential information

and materials agrees and warrants that it shall:

6.9.24.4.1. Take at least the same degree of care in safeguarding such Confidential Information and materials as it

takes for its own confidential information of like importance and such degree of care shall be at least,

that which is reasonably calculated to prevent such inadvertent disclosure

6.9.24.4.2. Keep the Confidential Information and Confidential Materials and any copies thereof secure and in

such a way so as to prevent unauthorized access by any third party

6.9.24.4.3. Limit access to such Confidential Information and materials to those of its directors, partners, advisers,

agents or employees, sub contractors and contractors who are directly involved in the

consideration/evaluation of the Confidential Information and bind each of its directors, partners,

advisers, agents or employees, sub contractors and contractors so involved to protect the Confidential

Information and materials in the manner prescribed in this document

6.9.24.4.4. Upon discovery of any unauthorized disclosure or suspected unauthorized disclosure of Confidential

Information, promptly inform the Disclosing Party of such disclosure in writing and immediately

return to the Disclosing Party all such Information and materials, in whatsoever form, including any

and all copies thereof

6.9.24.4.5. The Receiving Party who receives the confidential information and materials agrees that on receipt of a

written demand from the Disclosing Party:

6.9.24.4.5.1. Immediately return all written Confidential Information, Confidential materials and all copies

thereof provided to, or produced by it or its advisers, as the case may be, which is in Receiving

Party‘s possession or under its custody and control

6.9.24.4.5.2. To the extent practicable, immediately destroy all analyses, compilations, notes,

studies, memoranda or other documents prepared by it or its advisers to the extent that the same

contain, reflect or derive from Confidential Information relating to the Disclosing Party

6.9.24.4.5.3. So far as it is practicable to do so immediately expunge any Confidential Information relating to

the Disclosing Party or its projects from any computer, word processor or other device in its

possession or under its custody and control

6.9.24.4.5.4. To the extent practicable, immediately furnish a certificate signed by its director or other

responsible representative confirming that to the best of his/her knowledge, information and belief,

having made all proper enquiries the requirements of this paragraph have been fully complied with

6.9.24.4.5.5. The rights in and to the data / information residing at the Bank's premises, including at the

DC/DRC even in the event of disputes shall at all times solely vest with the Bank.

52

6.9.24.4.5.6. The IT Vendor represents and agrees that during the Term of this RFP or until the takes over

the Deliverables from the IT Vendor, whichever is earlier, the Bank shall not be responsible for any

loss/damage (including malfunctioning or non-functioning of Deliverables) caused to the

Deliverables for any reason, unless such loss/damage (including malfunctioning or non-

functioning of Deliverables) is caused due to the willful act or gross misconduct of the Bank or any

of its personnel as certified jointly by the Project Directors of the Parties. In such an event, the IT

Vendor shall promptly repair and/or replace the non- performing Deliverable with a suitable

replacement, if required, without affecting the service level standards in this RFP. The reasonable

cost for such repair or replacement shall be borne by the Bank.

6.9.24.4.6. The restrictions in the preceding clause shall not apply to:

6.9.24.4.6.1. Any information that is publicly available at the time of its disclosure or becomes publicly

available following disclosure (other than as a result of disclosure by the Disclosing Party contrary

to the terms of this document); or any information which is independently developed by the

Receiving Party or acquired from a third party to the extent it is acquired with the valid right to

disclose the same.

6.9.24.4.6.2. Any disclosure required by law or by any court of competent jurisdiction, the rules and regulations of

any recognized stock exchange or any enquiry or investigation by any governmental, statutory or

regulatory body which is lawfully entitled to require any such disclosure provided that, so far as it is

lawful and practical to do so prior to such disclosure, the Receiving Party shall promptly notify

the Disclosing Party of such requirement with a view to providing the Disclosing Party an

opportunity to obtain a protective order or to contest the disclosure or otherwise agree to the

timing and content of such disclosure

6.9.24.4.6.3. The Confidential Information and materials and all copies thereof, in whatsoever form shall at all

times remain the property of the Disclosing Party and its disclosure hereunder shall not confer on

the Receiving Party any rights whatsoever beyond those contained in this document

6.9.24.4.6.4. The confidentiality obligations shall survive the expiry or termination of the agreement between

the IT Vendor and the Bank.

6.9.25. Hardware Utilization

6.9.25.1. The IT Vendor is expected to size Hardware based on the information provided in this RFP for

implementing the solution for the number of branches as per the implementation schedule mentioned in

Section 3 Clause 3.5. At any point in time during the contract period, for these locations, during business

hours, the average CPU and Memory utilization should not exceed 80% threshold. In case the above

requirement is not met, additional hardware would have to be provided by the IT Vendor to meet

performance level, within 4 weeks of crossing the threshold(s).

The vendor at all times has to ensure that the sizing done confirms to the service level requirements of

the Project. In the event, these requirements of the Bank are not met at any point during the

contract period, the IT Vendor would need to deploy additional resources to meet the

performance levels, failing which penalty would be levied as per this RFP.

The vendor also has to perform pro-active monitoring of the solution to ensure that before any breach

happens they have sufficient time in procuring and installing the additional components. At no point in

time should the Bank be made to suffer on account of the vendors delay to procure the additional

resources.

53

6.9.26. Technological advancements

The IT Vendor shall take reasonable and suitable action, taking into account economic

circumstances, at mutually agreed increase / decrease in charges, and the Service Levels, to

provide the Services to

The Bank at a technological level that will enable the Bank to take advantage of

technological advancement in the industry from time to time.

6.9.27. Intellectual property rights – IPR

The IT Vendor shall be liable to obtain appropriate rights to provide the Deliverables upon the terms

and conditions contained in this RFP. The Bank agrees and acknowledges that save as expressly

provided in this RFP, all Intellectual Property Rights in relation to the Software and Documentation and

any adaptations, translations and derivative works thereof whether protectable as a copyright, trade mark,

patent, trade secret design or otherwise, provided by the IT Vendor during the course of the contract, in

connection with or in relation to fulfilling its obligations under this RFP, belong to and shall remain a

property of the IT Vendor or its licensor.

The IT Vendor shall be responsible for obtaining all necessary authorizations and consents from third

party licensors of Software used by Vendor in performing its obligations under this Project.

If a third party's claim endangers or disrupts the Bank‗s use of the Software, the IT Vendor shall at no

further expense, charge, fees or costs to the Bank, (i) obtain a license so that the Bank may continue use of

the Software in accordance with the terms of this tender and subsequent Agreement and the license

agreement; or (ii) modify the Software without affecting the functionality of the Software in any manner

so as to avoid the infringement; or (iii) replace the Software with a compatible, functionally

equivalent and non- infringing product

6.9.28. Vendor‘s liability

The IT Vendors aggregate liability in connection with obligations undertaken as a part of the Centralized

Banking Project regardless of the form or nature of the action giving rise to such liability (whether in

contract, tort or otherwise), shall be at actuals and limited to the value of the contract. The IT Vendors

liability in case of claims against the Bank resulting from misconduct or gross negligence of the IT Vendor,

its employees and subcontractors or from infringement of patents, trademarks, copyrights or such

other Intellectual Property Rights or breach of confidentiality obligations shall be unlimited.

The Bank shall not be held liable for and are absolved of any responsibility or claim/litigation arising out of

the use of any third party software or modules supplied by the IT Vendor as part of this RFP. In no event

shall the Bank be liable for any indirect, incidental or consequential damages or liability, under or in

connection with or arising out of this tender and subsequent agreement or the hardware or the software

delivered hereunder, howsoever such liability may arise, provided that the claims against customers,

users and service providers of the Bank would be considered as a direct claim.

6.9.29. Monitoring and audit

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

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

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

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

Vendor shall afford the Bank‘s representatives access to the IT Vendor's facilities, installations, technical

54

resources, operations, documentation, records, databases and personnel. The IT Vendor must provide the

Bank access to various monitoring and performance measurement systems (both manual and

automated). The Bank has the right to get the monitoring and performance measurement systems (both

manual and automated) audited without prior approval / notice to the IT Vendor.

6.9.30. Guarantees

The IT Vendor shall guarantee that the software and allied components used to service the Bank are

licensed and legal. All hardware and software must be supplied with their original and complete printed

documentation.

6.9.31. Force Majeure

6.9.31.1. The parties shall not be liable for default or non-performance of the obligations under the contract, if such

default or non-performance of the obligations under this contract is caused by Force Majeure.

6.9.31.2. For the purpose of this clause, ―Force Majeure‖ shall mean an event beyond the control of the parties, due

to or as a result of or caused by acts of God, wars, insurrections, riots, earth quake and fire, events not

foreseeable but does not include any fault or negligence or carelessness on the part of the parties,

resulting in such a situation.

6.9.31.3. In the event of any such intervening Force Majeure, each party shall notify the other party in writing of

such circumstances and the cause thereof immediately within 2 calendar days. Unless otherwise directed

by the other party, the party pleading Force Majeure shall continue to perform/render/discharge other

obligations as far as they can reasonably be attended/fulfilled and shall seek all reasonable alternative

means for performance affected by the Event of Force Majeure.

6.9.31.4. In such a case, the time for performance shall be extended by a period(s) not less than the duration of

such delay. If the duration of delay continues beyond a period 3 months, the parties shall hold

consultations with each other in an endeavor to find a solution to the problem.

6.9.31.5. Notwithstanding above, the decision of the Bank shall be final and binding on the Bidder.

6.9.32. Resolution of disputes

6.9.32.1. The bid and any contract resulting there from shall be governed by and construed according to the Indian

Laws.

6.9.32.2. All settlement of disputes or differences whatsoever, arising between the Bank and the IT Vendor out of

or in connection to the construction, meaning and operation or effect of this bid or in the discharge of any

obligation arising under this bid (whether during the course of execution of the order or after completion

and whether before or after termination, abandonment or breach of the Agreement) shall be resolved

amicably between the Bank‗s representative and the IT Vendor‗s representative.

6.9.32.3. In case of failure to resolve the disputes and differences amicably within 30 days of the receipt of

notice by the other party, then such unsettled dispute or difference shall be referred to arbitration by

sole arbitrator mutually agreed in accordance with the Arbitration and Conciliation Act, 1996. If no

agreement is arrived at within 30 days from the date of notice as to who shall be the sole arbitrator, the

Bank shall send to the IT Vendor a panel of 5 names of persons who shall be presently unconnected

with the Bank or the IT Vendor. The IT Vendor shall on receipt of the names as aforesaid, select any one

of persons so named to be appointed as sole arbitrator and communicate his name to the Bank within 30

days of receipt of the names. The Bank shall thereupon without delay appoint the said person as the

sole arbitrator. If the IT Vendor fails to select the person as sole arbitrator within 30 days of receipt of the

55

panel and inform the Bank accordingly, Bank shall be entitled to appoint one of the person from the

panel as sole arbitrator and communicate his name to the IT Vendor. If the person so appointed is unable

or unwilling to act or refuses his appointment or vacates his office due to any reason whatsoever,

another person shall be appointed by the Bank from the above list of persons.

6.9.32.4. The venue of the arbitration shall be at the capital of the State where the Bank is situated.

6.9.32.5. Work under the contract shall be continued by the IT Vendor during the arbitration proceedings unless

otherwise directed in writing by the Bank, unless the matter is such that the work cannot possibly be

continued until the decision of the arbitrator is obtained. Save as those which are otherwise explicitly

provided in the contract, no payment due, or payable by the Bank to the IT Vendor 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.

6.9.32.6. Any notice, for the purpose of this clause, has to be sent in writing to either of the parties by facsimile

transmission, by registered post with acknowledgement due or by a reputed courier service, All

notices shall be deemed to have been validly given on (i) the business day immediately following the

date of transmission with confirmed answer back, if transmitted by facsimile transmission, or (ii) the

expiry of 5 days after posting, if sent by post, or (iii) the business date of receipt, if sent by courier.

6.9.33. Exit option

6.9.33.1. Each Party shall have the option to exit the contract at the end of the 3 year or 5 year period by giving the

other Party a 90 days prior notice in writing.

6.9.33.2. This would include a well-defined reverse transition mechanism, which would normally require 4 to 6

months and will contain

a. Procedures for transition and migrating to the new Vendor

b. Time frame for parallel run

c. Skill transfer mechanism and in specific cases the human resources requirement

6.9.33.3. Notwithstanding the exit option, the IT Vendor will be expected to continue to provide all services as part

of the scope mentioned in Clause 4.2. The Bank shall have the sole and absolute discretion to decide

whether proper reverse transition mechanism over a period of 4 to 6 months, has been complied with.

6.9.33.4. The Bank and the IT Vendor shall together prepare the Reverse Transition Plan as detailed in the SLA.

However, the Bank shall have the sole decision to ascertain whether such Plan has been complied with.

6.9.33.5. Reverse Transition mechanism would typically include service and tasks that are required to be

performed / rendered by the IT Vendor to the Bank or its designee to ensure smooth handover and

transitioning of Bank‘s deliverables, maintenance and facility management.

6.9.33.6. In case of exit, the Bank will have the right to acquire the hardware in operation at book value.

6.9.34. Corrupt and fraudulent practice

6.9.34.1. As per Central Vigilance Commission (CVC) directives, it is required that Bidders / Suppliers /

Contractors observe the highest standard of ethics during the procurement and execution of such

contracts in pursuance of this policy:

6.9.34.2. ―Corrupt Practice” means the offering, giving, receiving or soliciting of anything of values to

56

influence the action of an official in the procurement process or in contract execution

6.9.34.3. ―Fraudulent Practice” means a misrepresentation of facts in order to influence a procurement process or

the execution of contract to the detriment of the Bank and includes collusive practice

among bidders (prior to or after bid submission) designed to establish bid prices at artificial non -

competitive levels and to deprive the Bank of the benefits of free and open competition

6.9.34.4. The Bank reserves the right to reject a proposal for award if it determines that the bidder recommended

for award has engaged in corrupt or fraudulent practices in competing for the contract in question.

6.9.34.5. The Bank reserves the right to declare a bidder ineligible, either indefinitely or for a stated period of

time, to be awarded a contract if at any time it determines that the firm has engaged in corrupt or

fraudulent practices in competing for or in executing the contract.

6.9.35. Waiver

No failure or delay on the part of either party relating to the exercise of any right power privilege or

remedy provided under this RFP or subsequent agreement with the other party shall operate as a waiver

of such right power privilege or remedy or as a waiver of any preceding or succeeding breach by the other

party nor shall any single or partial exercise of any right power privilege or remedy preclude any other or

further exercise of such or any other right power privilege or remedy provided in this RFP all of which

are several and cumulative and are not exclusive of each other or of any other rights or remedies

otherwise available to either party at law or in equity.

6.9.35.1. Violation of terms

The Bank clarifies that the Bank shall be entitled to an injunction, restraining order, right for

recovery, specific performance or such other equitable relief as a court of competent jurisdiction may

deem necessary or appropriate to restrain the IT Vendor from committing any violation or enforce the

performance of the covenants, obligations and representations contained in this RFP. These injunctive

remedies are cumulative and are in addition to any other rights and remedies the Bank may have at law or

in equity, including without limitation a right for recovery of any amounts and related costs and a right

for damages.

6.9.35.2. Visitorial Rights

The Bank and its authorized representatives reserve the right to visit any of the IT Vendor‗s premises

without prior notice to ensure that data provided by the Bank is not misused. The IT Vendor shall

cooperate with the authorized representative/s of the Bank and shall provide all information/ documents

required by the Bank.

6.9.35.3. Addition / Deletion of qualified offerings

6.9.35.4. Both parties agree that the intent of this tender is to establish an initial set of service offerings.

The Bank recognizes that, as the use of these services expands, it is possible that additional services and /

or service categories will be needed. For this purpose, a Change Order Procedure will be followed. The

Bank may request a change order in the event of actual or anticipated change(s) to the agreed scope of

work, services, deliverables and schedules. The IT Vendor shall prepare a change order reflecting the

actual or anticipated change(s) including the impact on deliverables schedule. The IT Vendor shall carry

out such services as required by the Bank at mutually agreed terms and conditions.

6.9.35.5. The IT Vendor shall agree that the price for incremental offering cannot exceed the original proposed cost

and the Bank reserves the right to re-negotiate the price. The IT Vendor shall agree to submit the request

57

to add new services or service categories on its letterhead signed by a representative authorized to bind

the organization.

6.9.35.6. The Bank is under no obligation to honor such requests to add service categories or amend this contract.

6.9.35.7. As a method for reviewing Vendor services and the Bank‘s requirements, the

the Bank will sponsor regular reviews to allow an exchange of requirements and opportunities.

This also includes the right to modify the number of branches, service units, offices, training

centers etc.

6.9.36. Termination

6.9.36.1. The Bank shall have the option to terminate the contract in whole or in part by giving the IT Vendor

atleast 90 days prior notice in writing provided always that Bank agrees not to terminate the contract

during which period the IT Vendor shall complete the implementation at all the identified Sites.

Notwithstanding what has been stated, the Bank will be entitled to terminate the contract if the IT Vendor

breaches any of its obligations set forth in this RFP; and

Such breach is not cured within 30 days after the Bank gives written notice; or

If such breach is not of the type that could be cured within 30 days, failure by IT Vendor to provide the

Bank, within 7 days, with a reasonable plan to cure such breach, which is acceptable to the Bank.

The following conditions will be considered as a breach of contract by the IT Vendor:

Delay in completing installation / implementation beyond the specified periods;

Serious discrepancy in functionality to be provided or the performance levels agreed upon,

which have an impact on the functioning of the Bank.

Serious deficiency in service levels agreed upon as a part of the SLA.

6.9.36.2. In addition to the termination of purchase contract, the Bank reserves the right to appropriate the damages

through encashment of Bid Security / Performance Guarantee given by the IT Vendor.

6.9.36.3. Notwithstanding the existence of a dispute, and/or the commencement of arbitration proceedings, the IT

Vendor will be expected to continue to provide all services as part of the scope mentioned above. The

Bank shall have the sole and absolute discretion to decide whether proper reverse transition mechanism

over a period of 4 to 6 months, has been complied with.

6.9.36.4. The Bank and the IT Vendor shall together prepare the Reverse Transition Plan. However, the Bank shall

have the sole decision to ascertain whether such Plan has been complied with.

6.9.36.5. Reverse Transition mechanism would typically include service and tasks that are required to be

performed / rendered by the IT Vendor to the Bank or its designee to ensure smooth handover and

transitioning of Bank‘s deliverables, maintenance and facility management.

6.9.36.6. Without prejudice to the rights of the Parties, upon termination or expiry of this tender and subsequent

Agreement, the Bank shall pay to Vendor, within 30 days of such termination or expiry of the following,

whichever is later:

All the undisputed fees outstanding till the date of termination;

Provided the Payment is made only after Reverse Transition Services are provided.

Upon the termination or expiry of this tender and subsequent Agreement:

58

6.9.36.7. The rights granted to Vendor shall immediately terminate,

Upon the Bank‘s request, with respect to (i) any agreements for maintenance, disaster recovery

services or other third-party services, and any Deliverables not owned by the IT Vendor, being

used by the IT Vendor to provide the Services and (ii) the assignable agreements, the IT

Vendor shall, use its reasonable commercial endeavors to transfer or assign such agreements

and Vendor Equipment to the Bank and its designee(s) on commercially reasonable terms

mutually acceptable to both Parties.

Upon the Bank‘s request in writing, the IT Vendor shall be under an obligation to transfer

to the Bank or its designee(s) the Deliverables being used by the IT Vendor to perform the

Services free and clear of all liens, security interests, or other encumbrances at a value

calculated as stated.

As part of Reverse Transition Services, the Bank shall have the right, and the IT Vendor shall

not object to or interfere with such right, to contract directly with any IT Vendor‗s

subcontractor.

6.9.36.8. In case of termination the Bank will have the right to acquire the hardware in operation at book

value.

6.9.37. Effect of Termination

The Bank desires to appoint the IT Vendor for a total period of [7 years], considering the effort and

investments required in the arrangement. However, understanding the complexities of the entire

arrangement, the Bank would like to safe guard the interests of all the entities involved in the

arrangement. Therefore, the Bank would like to have options to revisit the arrangements and terms of

contract as well as to re -price the same after the contract term on mutually agreed terms if necessary.

The Bank expects the benefits from any un-anticipated decrease in technology infrastructure costs,

over the term of the contract due to reduction of prices, efficient use of IT infrastructure / reduction of

statutory charges, etc. and operations management methods that yield more efficient operations, to be

passed on through re-negotiation.

6.9.38. Reverse Transition Services

Reverse Transition Services are the services provided by the IT Vendor to the Bank during the reverse

transition period which will start after completion of the notice period to facilitate an orderly transfer of

the Services to the Bank or to an alternative third partly service provider nominated by the Bank.

The Reverse Transition Services, to be provided by the IT Vendor to the Bank shall include the following

6.9.38.1. Hardware

The IT Vendor shall provide a list of sub-contractors used by the IT Vendor for maintaining the hardware

(including inter alia, servers, PC‗s, networking, switches, routers etc.) under this RFP and shall ensure

that all such sub- contractors shall enter into separate annual maintenance agreements for maintenance

of the hardware maintained under this RFP, upon commercially reasonable terms and conditions as

available currently to the vender or better than the same.

In case of termination the Bank will have the right to acquire the hardware in operation at book value.

6.9.38.2. Software

The IT Vendor shall provide appropriate training to the Bank‘s personnel or its designee to enable them

59

to maintain the Software provided under this Agreement. If there is a change-over in the IT Vendor after

the contract period, the IT Vendor must ensure continued operations of the existing system till such

change-over is completed. The IT Vendor shall ensure that if any data migration is required, the same

shall be carried by the IT Vendor and a handover to be provided for the smooth transition of the

operations. The IT Vendor shall provide the Bank‘s data, current CBS data structures and all other

material with respect to this contract in a prescribed format given by the Bank / new Vendor appointed by

Bank.

6.9.38.3. Network Management

The IT Vendor shall provide a list of network service providers used by the IT Vendor for providing

corporate network connectivity under this Tender and subsequent Agreement and shall ensure that all

such network service providers shall enter into separate agreements for use and management of the

network.

6.9.38.4. Knowledge transfer

The IT Vendor shall provide such necessary information, documentation to Bank or their assignee,

for the effective management and maintenance of the Deliverables under this RFP. Vendor shall provide

documentation (in English) in electronic form where available or otherwise a single hardcopy of all

existing procedures, policies and programs required supporting the Services. Such documentation will be

subject to the limitations imposed by Vendor‗s Intellectual Property Rights of this RFP.

Listing of all third (3rd) party Vendors that have been directly relevant to the provision of the Services

and that may be the subject of a request by Bank or the replacement service provider for assignment,

cancellation or renovation.

All trainings that the Bank feels are necessary to be imparted to the Bank‘s designated personnel.

6.9.38.5. Warranties

All the warranties held by or in the name of the IT Vendor shall be assigned or transferred ―As Is‖ in the

name of the Bank. The IT Vendor shall execute any and all such documents as may be necessary in this

regard.

The Parties shall return confidential information and will sign-off and acknowledge the return of such

confidential information.

Vendor shall provide all other Services as may be agreed by the Parties in connection with the Reverse

Transition Services.

The IT Vendor recognizes that considering the enormity of the Assignment, the Transition Services listed

herein are only indicative in nature and the IT Vendor agrees to provide all assistance and services

required for fully and effectively transitioning the Services provided by the IT Vendor under this tender

and subsequent Agreement, upon termination or expiration thereof, for any reason whatsoever.

6.9.39. Escrow Mechanism

The Bank and the Bidder shall agree to appoint an escrow agent to provide escrow mechanism for the

deposit of the source code for the software product supplied/ procured/customized by the Bidder for the

Bank in order to protect their interests in an eventual situation. The Bank and the Bidder shall enter into a

tripartite escrow agreement with the designated escrow agent, which will set out, inter alia, the events of

the release of the source code and the obligations of the escrow agent. Costs for the Escrow arrangement

60

so agreed upon will be borne by the bidder/s. Vendor/s must deliver all current versions of the software

and all modifications and enhancements to the escrow agent. As a part of the escrow arrangement, the

final selected bidder /s is/are also expected to provide a detailed code documentation of the solution,

which has been duly reviewed by an external independent organization for its validity. The escrow

agreement also requires the software supplier to keep the escrowed software updated.

7. Responses to RFP

7.1. Bid Submission

The IT Vendor bid submissions need to be as per the schedule under Section 6.2.

All bids should be submitted in a two-bid process i.e. the Technical Bid and the Commercial Bid. The technical

Bid should be submitted in a separate envelope superscribed in bold letters ―Technical Bid for 1-CMT/BMB/2013-14

Dated 17th July 2013 issued by the Bank for Implementation of CBS at the Bank on ASP Model‖ while the

Commercial Bid, also to be submitted in separate enveloped superscribed in bold letters ―COMMERCIAL Bid for

1-CMT/BMB/2013-14 Dated 17th July 2013 issued by the Bank for Implementation of CBS at the Bank on ASP

Model‖ Both the above envelopes should be securely sealed and stamped and then along with Tender Fee, Bid Security

& other documents as required be put into a single envelope which will again be stamped and sealed and

superscribed as ―BID DOCUMENTS FOR 1-CMT/BMB/2013-14 Dated 17th July 2013 issued by the Bank for

Implementation of CBS at the Bank on ASP Model‖. The authorized signatories of the IT Vendor should initial on all

pages of the entire proposal.

The IT Vendor has to submit the response in hard copy and soft copy (in CD). Soft copies should be in MS Word

2007/2010 and/or MS Excel 2007/2010 version so as to facilitate easy compilation wherever warranted. All CDs

submitted should be neatly labeled and should also include the name of the IT Vendor.

The IT Vendor needs to submit one master envelope duly sealed. This master envelope should contain 2 sub-envelopes

each duly sealed.

First sub envelope “Technical Envelope” should have the hard copy and CD for Technical Bid.

Original Hard copy of the technical bid with pages properly numbered, each page signed and stamped. A

separator should mark each section. The technical proposal should be bound in such a way that the sections of

the proposal could be removed and separated easily. The cover page should be clearly superscribed in bold

letters as "ORIGINAL COPY OF Technical Bid for 1-CMT/BMB/2013-14 Dated 17th July

2013issued by the Bank for Implementation of CBS at the Bank on ASP Model‖

Duplicate Copy of Technical Bid Document clearly superscribed in bold letters as "DUPLICATE COPY OF

Technical Bid for 1-CMT/BMB/2013-14 Dated 17th July 2013 issued by the Bank for Implementation of

CBS at the Bank on ASP Model "

Compact Disk (CD) containing the soft copy of technical proposal should be provided

In case of any discrepancy between Original/Duplicate and Soft Copy, Original Copy shall prevail.

Second sub envelope “Commercial Envelope” should have the hard copy and CD for Commercial Bid.

One Original hard copy of the commercial proposal with each page signed and stamped;

Duplicate hard copy of the commercial proposal with each page signed and stamped;

61

Compact Disk (CD) containing the soft copy of the commercial proposal.

In case of any discrepancy between Original/Duplicate and Soft Copy, Original Copy shall prevail.

All envelopes must be super-scribed with the following information:

RFP reference number

Type (Technical/ Commercial)

Date

Name of Vendor

The IT Vendor should certify that the contents of the CDs are the same as that provided by way of hard copy as per letter

format. In the event of a discrepancy the hard copy will prevail and be considered.

7.2. Contact details for responding to RFP

The bidder can deliver the bids by hand or couriered to following personnel from the Bank. All the queries and

communication must be addressed to the officer mentioned below:

Deepak Kaushik,

Vice President, Capital Markets Group

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Ph: 022-22178300

7.3. Proposal format

The IT Vendor‘s proposal must effectively communicate their solution and be formatted in the specified formats in order

for the Bank to assess the alternatives.

7.3.1. Technical Bid Format

The technical bid should be submitted in the following order:

Sr.

No.

Subject Document As per Annexure Remarks

1 Check List Annexure 1

2 Cover Letter Annexure 2

3 Application Fee of Rs. 1 Lakh Bank DD Favouring SBI Capital

Markets Limited

4 Bid Security of Rs. 50 Lakh Bank DD / Bank

Guarantee

Favouring SBI Capital

Markets Limited

5 Bidder‘s Experience & Capability No fixed formats. Contents

as per Clause 8.2 below.

Refer to Clause 8.2

6 Functional Requirements Specifications Contents as per Clause 8.2

below & Annexure 6.

Refer to Clause 8.2

7 Technical requirements Specifications Contents as per Clause 8.2

below & Annexure 7.

Refer to Clause 8.2

8 Approach & Methodology Contents as per Clause 8.2

below & Annexure 8.

Refer to Clause 8.2

9 SLA (expected to be in conformity with the No fixed formats. Contents Refer to Section 5 &

62

Section 5.0 above) as per Clause 8.2 below. Clause 8.2

10 Conformity Letter Annexure 9

11 Comments on the Terms & Conditions,

Services and Facilities Provided

Annexure 10

12 Manufacturer Authorisation Annexure 11

13 Manufacturer Details Annexure 12

14 Soft Copy of all documents in a CD All proposals to be in

MS Word (2007/2010)

format except Balance

Sheet, Certificates,

Client Letters etc.

The technical bid should have documents should only have Company related details & all information and data,

which are purely about the solution and offer and strictly non-commercial in nature.

Pages of the Hard copy of the technical proposal should be properly numbered, with each page signed and

stamped.

A separator should mark each section.

The technical proposal should be bound in such a way that the sections of the proposal could be removed and

separated easily.

Technical proposal should be submitted in two copies clearly marked as "TECHNICAL BID - ORIGINAL" and

"TECHNICAL BID - COPY"

7.3.1.1. Compliance to each of the items in Annexure 1 (Checklist) should be filled by the vendor.

7.3.1.2. Cover letter to be submitted as per format specified in Annexure 2.

7.3.1.3. Application money of Rs. 1,00,000/- (Rupees One Lakh only) is required to be paid in the form of

Demand Draft from a Nationalized Bank in favour of SBI Capital Markets Limited, payable at

Mumbai.

7.3.1.4. Bid Security of INR 50,00,000/- (INR fifty lakh only) by way of Demand Draft or Pay Order (as per

Annexure 3) or Bank Guarantee (as per Annexure 4) valid for 6 months should be submitted along

with the Offer. The Bank Guarantee should be of a Scheduled Public Sector/Commercial Bank only and

will be accepted subject to the discretion of the Bank.

7.3.1.5. Information to evaluate Bidder's experience and Capability should be submitted as per format

specified in Annexure 5, with supporting documents attached for each item.

7.3.1.6. Response to Functional Requirement Specification should be filled as per Annexure 6 in excel format.

The Bidders should respond to the requirements which should be under one of the following categories.

Scale Description

R (R) Standard Feature: The system that will be delivered already supports this

functionality without further augmentation or the use of either programming or user

tools, i.e. included in the base package at no additional cost.

S (S) Substitutable: If the proposed system offers an alternative to the desired

functionality, please provide a written explanation. Please clearly specify the reference

number where appropriate.

63

C (C) Customizable: This functionality would require custom alterations to the system, by

Bidders‘ programming staff, as part of the base price. The customization items mean a

change/modification/alteration to the base software, to be undertaken by the Prime

Bidder.(Prime Bidders should not expect the Bank‘s users to modify or add on to the

base software using toolkits etc. for functionality not available as ‗Regular‘ in the

proposed base version of the software).

A (A) Augmentable: This functionality is scheduled/ expected to be released in a future

update or release of the software, and Prime Bidders will provide these features at no

additional cost as part of the proposed comprehensive solution.

U (U) Unavailable: The functionality does not exist in the current system and is not

scheduled for release in an update within the next calendar year and not feasible for

customization also.

Each line item in the functional requirement mentioned in Annexure 6 carries marks. Marks will be

allotted against the responses to each of the point mentioned as per the following marking pattern:

4 R- Standard feature

3 S-Substitute available

2 C - Customization required.

1 A - Augmentation

0 U- Unavailable

7.3.1.7. Response to Technical Requirements and Proposed Solution Architecture should be filled as per

Annexure 7.

In Part - A, Vendor should just express its compliance to each of the Technical Requirement.

For Part - B , Vendors are requested to provide a document describing the solution offered as per the

categories mentioned in Annexure 8 as briefly as possible.

7.3.1.8. Vendor should provide detailed Approach and Methodology in its own format to cover following

details:

Implementation approach & rationale

Project Plan

Break-down of tasks / Activities

Resources allocation

Responsibility Matrix

They should also attach Annexure 8 covering details of Manpower Deployment and Implementation

Deadlines.

7.3.1.9. Compliance letter to be provided as per Annexure 9. Vendors should provide their

comments/suggestions as per Annexure 10.

64

7.3.1.10. Manufacturer Authorization Form and details of Manufacturers as per Annexure 11 and Annexure 12.

Soft Copy of all above Documents should be provided separately in a CD clearly labeled.

7.3.2. Commercial Bid Format

The commercial bid should be submitted strictly in the following order:

i) Commercial Bid as per format specified in Annexure 16

ii) Soft Copy of Commercial bid

Commercial bid should be submitted in two copies clearly marked as "COMMERCIAL BID -

ORIGINAL" and "COMMERCIAL BID - COPY"

8. Evaluation methodology

8.1. Two Bid Process

The evaluation of Bid will be a two-stage process. The stages are:

Technical bid evaluation

Commercial bid evaluation

8.2. Technical Bid evaluation

Technical Evaluation will be based on 6 major parameters - Scoring of Functional Requirements, Approach and

Implementation Roadmap, Scoring of Technical Requirements, Bidder‘s Capability and Experience,

Presentations and Reference Site Visits. Technical Scores shall be calculated out of total of 100 marks. Broad

evaluation parameters are given below:

S. No. Criteria Description Adequate support documents required Weightage

1. Bidder’s Capability and Experience

1.1 Implementation

Experience

No. of CBS implementations in banks

Letters from customers

Project descriptions with data sheet in terms of

project scope, time of delivery agreed, actual

completion date, project outlay, number of people

deployed for implementation, number of persons for

maintenance & service delivery, brief technology

architecture etc.

15%

1.2 Vendor's Resources Details of the Proposed :

Total manpower strength in BFSI vertical

Core Technical Team

Core Infra Team (DC/DR/NW)

Core Project Team

Field / Branch Team

Help / Support Team

5%

2. Functional Requirements Solution architecture (Functional) Doc and

Response as per the given format

20%

3. Technical Proposal Solution architecture (Technical) Doc and 20%

65

Response as per given format

4. Approach and

Implementation

Roadmap

Implementation approach & rationale

Project Plan

Break-down of tasks / activities

Resources allocation

Responsibility Matrix

20%

5. Proposal Response and Presentations

5.1 Technical Presentation Proposed date & time required 10%

5.2 Product Demonstration Proposed date & time required 5%

5.3 Reference Site Visits Names of the client and details of the site. Response

may indicate all the live sites for the Bank to choose

from.

5%

Total 100%

8.2.1. Scoring of Bidder's Capability and Experience

Bidder's Capability shall be evaluated based on response submitted by the Bidder in Annexure 5

8.2.2. Scoring of functional requirements

The responses received in Annexure 6 will be used for evaluating the bidder on the functional

requirements fulfillment. The bidder is expected to provide ‗Vendor Response‘ in the respective column

for each functional specification. The response format and scoring criteria are specified in Annexure 6.

Functional Requirement Score = Score Obtained

X Weightage for FRS Maximum Possible Score

8.2.3. Scoring of technical requirements

8.2.4. The responses received in Annexure 7 will be used for evaluating the solution on technical specifications.

The bidder is expected to provide ‗Vendor Response‘ in the respective column for each technical

specification. Proposed Technical Solution should be described briefly as per the list of Topics in Part

Annexure 7.

8.2.5. Approach and Implementation Roadmap

Evaluation of Approach and Implementation Roadmap shall be on the basis of response submitted by the

Bidder. This section should clearly express.

a) Approach

b) Implementation Strategy

c) Time Lines

d) Manpower Deployment

e) Monitoring

8.2.6. Reference Site Visits

IT Vendors should provide the list of all live sites. The Bank may choose the site/s to visit.

66

Vendors should arrange for the site visit by liaising with the clients.

The Bank requires the bidders to provide at least one reference site in a similar environment, where the

proposed solution has been installed.

The Bank may contact the users directly to gain information about the solution. Bidders will need to

arrange for visits to the reference sites and DC/DR sites on the Bank‗s request.

8.2.7. Presentations

The presentations will have two components:

8.2.7.1. Technical Presentation (~1 hour)

During the technical presentation, the bidders will be asked to present the solution information submitted by

them in response to this RFP. This will include (but shall not be limited to):

Overall functional architecture

Technical architecture

Project Plan and Timelines

Implementation Methodology

Training Methodology

Testing Methodology

Post Implementation Support to be provided by the bidder

The quality of clarifications given by the IT Vendor during the technical presentation will be factored in the

evaluation score under the respective headings.

8.2.7.2. Product Demonstration (~3 hours)

The Bidders are required to make demonstrations of the software at the Bank‗s desired location. The

demonstration will allow the evaluation team to see the software system modules in terms of functionality

and technical fitment. It will also allow the Bank to evaluate the solution in terms of look and feel,

screen navigation, user friendliness, confirmation of Bidder‗s response to this tender, etc. The bidders will

be asked to demonstrate specific scenarios during demonstrations, the details of which shall be made

available to bidders.

The demonstrations will also give the Bank an opportunity to clarify issues arising out of the review of the

Bidder‗s response to this tender. The Bank shall not be under any obligation to bear any part of the

expenses incurred by the Bidders for the demonstrations.

8.3. Bid Evaluation

8.3.1. The commercial bid would be appraised based on the scores of the Functional, Technical and Support

features appraisal stage and absolute prices quoted by the qualifying vendors.

8.3.2. Based on the aggregate weighted technical score arrived at in the Technical Bid Evaluation, vendors will be

ranked according to their scores with Technical 1 (‗T1‘) as the IT Vendor having the highest score being

T1 followed by the respective Vendors in descending order. The Bank reserves the right of opening

commercial bid/s of up to top 4 bidders who have technical scores of minimum 70% of the total score, and

minimum 60% under each individual major head.

67

8.3.3. The Bank reserves the right to not open commercial bid of bidders that are found to be technically

deficient.

8.3.4. The marks scored by the Bidders in the technical evaluation will be given a weightage of 70. Similarly, the

commercial bids of the Bidders will be given a weightage of 30. The combined score of technical and

commercial bids will determine the H1, H2, H3 and so on.

8.3.5. The commercial bid would be evaluated based on a ―Total Cost of Ownership (TCO)‖ basis.

8.3.6. In case of a tie in the commercial evaluation stage, the Bank's decision will be final and will be based on

marks scored in the technical bid evaluation only.

8.3.7. The Bank reserves the right to select one or more vendors for implementation of the project.

68

ANNEXURE – 1: CHECKLIST

SECTION SECTION HEADING PROFORMA Vendor's Compliance

Remarks

Section I : Technical Bid envelope to contain the following

1.

Checklist Annexure 1

2.

Cover letter Annexure 2

3. Application Fees (by way of a Bank

Draft drawn in favour of SBI Capital

Markets Limited)

To be provided by the Bidder

4. Bid Security (In case of Demand

Draft/Pay Order)

Annexure 3

5. Bid Security (In case of Performance

Bank Guarantee )

Annexure 4

6.

Bidder's experience and Capability Annexure 5

7. Functional Requirement Specification Annexure 6

8. Technical Requirements and

Proposed Solution Architecture

Annexure 7

9. Approach and methodology To be provided by the Bidder

10. Detailed Work Plan & Timeline Annexure 8

11. Conformity Letter Annexure 9

12. Comments on Terms and Conditions Annexure 10

13.

Manufacturer Details and

Manufacturer Authorization

Annexure 11 and 12

14. Eligibility criteria Annexure 15

15.

Soft Copy of all above Documents in

a CD

In .doc format (MS Word 2007 and

above)

Section II : Commercial bid envelope to contain the following

1. Commercial Bid Annexure 16

2. Soft Copy of Commercial bid

69

ANNEXURE – 2: COVER LETTER

Date:

To,

Deepak Kaushik,

Vice President, Capital Markets Group

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Dear Sir/Madam,

1. Having examined the Tender Documents including all Annexures, 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‖ for implementing CBS under ASP model and the other schedules of

requirements and services 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.

3. We agree to abide by this Tender Offer for 6 months from date of Tender (Commercial Bid) opening or

extended period as per clause 2.5.1 of the RFP and our Offer shall remain binding on us and may be

accepted by the Bank 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.

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 agree that the Bank is not bound to accept the lowest or any Bid which the Bank may receive.

7. We have never been barred/black-listed by any regulatory/statutory authority.

8. No legal case of any default/blacklisting should have ever been filed by any regulator on the firm.

9. We certify that we have provided all the information requested by the Bank in the format requested for.

We also understand that the Bank has the exclusive right to reject this offer in case the Bank is of the

opinion that the required information is not provided or is provided in a different format.

Dated this…………………………………..by ……………………….20

Authorized Signatory

(Name: Contact Person, Phone No., Fax, E-mail)

(This letter should be on the letterhead of the IT Vendor duly signed by an authorized signatory)

70

ANNEXURE – 3: BID SECURITY LETTER (if Bid is submitted in draft/ pay order mode)

BID SECURITY LETTER

(if Bid is submitted in draft/ pay order mode)

Bond No.:

Dated:

1. WHEREAS,………………………………………… (hereinafter referred to as ―IT Vendor‖) has

submitted its proposal and response dated…………………………(hereinafter referred to as

―Bid‖) for the supply of all the requirements described in the Request for Proposal along with its

amendments / annexures and other ancillary documents (hereinafter referred to as ―RFP‖) as

issued by the Bank.

2. We ……………………………………………….having our registered office at

………………………………………. (hereinafter called the ―IT Vendor‖) are offering bid security deposit of Rs

………………………………………………. (Rupees …………………………... ..) Vide [demand draft / pay

order / issued by a scheduled/Commercial bank] bearing No. dated [drawn on/ issued by] (hereinafter referred to

as ―Bid Security‖) favouring the Bank for consideration of the Bid of the above mentioned IT Vendor.

3. The IT Vendor specifically acknowledges and agrees that the IT Vendor has furnished his Bid on the

understanding and condition that, if the IT Vendor:

a. Withdraws its Bid during the period of Bid validity specified by the IT Vendor on the

Tender Documents or

b. Having been notified of the acceptance of its Bid by the Bank during the period of validity:

i. Fails or refuses to execute the contract form if required; or

ii. Fails or refuses to furnish the Performance Security, in accordance with the

instruction to IT Vendors.

The Bank has the right to forfeit the entire Bid Security amount merely on the occurrence of one

or more of the foregoing events without demur or a written demand or notice to the IT Vendor.

4. The Bid Security shall be returned to unsuccessful Vendors within one month from the date of the award of

contract to a successful Vendor. The Bid Security shall be returned to the successful Vendor upon furnishing

of Performance Security in accordance with the instructions of the IT Vendor.

5. The IT Vendor undertakes that it will not cancel the Bid Security referred to above till the IT Vendor is

returned the Bid Security from the Bank in accordance with the foregoing conditions.

6. The IT Vendor represents and warrants that the IT Vendor has obtained all necessary approvals,

permissions and consents and has full power and authority to issue this Bid Security and perform its

obligations hereunder, and the IT Vendor has taken all corporate, legal and other actions

necessary or advisable to authorize the execution, delivery and performance of this Bid Security. The

absence or deficiency of authority or power on the part of the IT Vendor to issue this Bid Security

or any irregularity in exercise of such powers shall not affect the liability of the IT Vendor under this

Bid Security.

Dated this... ............... ..day of...

Place:

Date: Seal and signature of the IT Vendor

71

ANNEXURE – 4: BID SECURITY LETTER (If submitted as a Bank Guarantee)

BID SECURITY LETTER

(If submitted as a Bank Guarantee)

(On non-judicial stamp paper of appropriate value)

To,

Deepak Kaushik,

Vice President, Capital Markets Group

SBI Capital Markets Limited

20th Floor, Cuffe Parade, Mumbai-400005

Dear Sir/Madam,

WHEREAS the Bharatiya Mahila Bank, a public sector bank established under the

the Companies Act, 1956, as amended, (hereinafter referred to as the Bank, which expression shall,

include its successors and assigns) has invited tenders for ―Implementation of Core Banking

Solutions on ASP Model in the Bank‖ (hereinafter referred to as ―said work‖)

(2) WHEREAS M/s___________________________________ who are our constituent (hereinafter

referred to as "the Tenderer", which expression shall include the successors and assigns) has submitted a

tender for the said work.

(3) AND WHEREAS it is one of the condition of the said tender that the Tenderer shall deposit with the

the Bank at the time of submitting the tender a sum of Rs.-------- /- (Rupees ------------------------------------

--------------------------only) as and by way of Bid Security (BS), which Bid Security (BS) shall not bear

any interest and which shall be liable for forfeiture: -

1. If the Tenderer withdraws its Bid during the period of bid validity specified by the Tenderer on the Bid

form; or 2. If the Tenderer, having been notified of the acceptance of its bid by the Bank during the

period of bid validity:

(a) fails or refuses to execute the Contract; or

(b) fails or refuses to furnish the Performance Guarantee, in accordance with the Terms and Conditions

of the Contract;

(4) AND WHEREAS at the request of the Tenderer, the Bank has agreed not to insist for payment of the

said Bid Security (BS) in cash and accept the guarantee from a Scheduled Commercial Bank in lieu

thereof and have agreed to accept the same from us, the Bank, as hereinafter contained.

In the premises aforesaid and in consideration of the Bank having agreed at our request to exempt the

tenderer from depositing the said Bid Security (BS) in cash. WE,_________________________Bank

having our Head Office at ___________________and one of our Branches at __________________ _ Do

hereby unconditionally and irrevocably guarantee unto the Bank that the Tenderer will not withdraw its

Bid during the period of bid validity specified by the Tendorer on the Bid Form and also execute the

Contract and furnish the Performance Guarantee, in accordance with the Terms and Conditions

of the Contract failing which WE the__________________________Bank shall, on demand and

without demur, pay unto the Bank the sum of Rs. --------------/- (Rupees-----------------------------------------

-------- ---- only) at its office at Mumbai.

72

We _____________________________________________Bank further covenant that:

(a) We shall pay the aforesaid sum on demand made in writing by the Bank without reference to the

Tenderers and notwithstanding any dispute or difference that may exist or arise between the Bank and the

tenderers;

(b) that this guarantee shall be a continuing guarantee and shall not be revoked by us without prior

consent in writing of the Bank.

(c) that the decision of the Bank on the breach of any of the terms and conditions of the said contract /

tender by the Tenderers or their failure to perform their obligations or discharge their duties under the said

tender / contract shall be final and binding on us and shall not be disputed by us inside or outside the

court, tribunal, arbitration or other authority;

(d) that the notice of demand in writing issued by the Bank shall be conclusive proof as regards the

amount due and payable to the Bank under this guarantee and it shall not be disputed by us either inside

or outside the court, tribunal or arbitration or other authority;

(e) that any neglect or forbearance on the part of the Bank in enforcing any of the terms and conditions of

the said tender / contract or any indulgence shown by the Bank to the Tenderer or any variation in the said

tender / contract terms made by mutual agreement between the Bank and the Tenderer or any other act or

deed on the part of the Bank which but for this clause may have the effect of discharging us under the law

relating to guarantee / sureties shall not discharge us from our obligations herein and we shall be

discharged only by compliance by the Tenderers with all their obligations / duties under the said tender /

contract or by payment of the sum.

(f) that this guarantee shall not be affected by any infirmity or absence or irregularity in the exercise of

the powers by or on behalf of the tenderers to submit the said tender and enter into the said contract or

any change in the constitution or dissolution of the Tenderers or change in its name;

(g) that it shall not be necessary for the Bank to exhaust its remedies against the Tenderers before

invoking this guarantee and the guarantee therein contained shall be enforceable against us

notwithstanding any other security which the Bank may have obtained or may hereafter be

obtained from the Tenderers at the time when this guarantee is invoked is outstanding and unrealized;

(h) that we hereby agree that this guarantee shall be valid and be in force for a period of 6 months, i.e.

upto ___________ and we hereby agree to renew this guarantee for such further period or periods at the

request of the Bank in the event of withdrawal of Bid, non execution of contract or furnishing of

performance bank guarantee and such renewal shall be entirely at the cost and expense of the Tenderer.

(i) Any claim arising under this guarantee shall be preferred by the Bank within a period of [● months]

from the aforesaid date of expiry i.e.____________ or, in the event of any renewal, within a period of [●

months] from the date of expiry of such renewed period extended by such renewal, and unless the claim is

so preferred against us, we shall stand discharged of all our liabilities hereunder.

Yours faithfully

For and on behalf of

_______________Bank

(Authorized Official)

73

ANNEXURE – 5: BIDDER’S PROFILE

Bidder's Profile

Supporting Document for each Parameter should be attached with the annexure.

* Please refer to the Section on Technical Evaluation parameters for broad basing the response.

1. Basic Details

Company Name

Date of Incorporation

Holding Company or Parent

Corporate Address

Contact Name

Phone

Fax

Email

Supporting: Self certification by the IT Vendor that it has not been blacklisted by any public sector bank

in India.

2. Commercial Strength and Viability

Parameter Vendor's Response

2.1 Turnover

Turnover for the last financial year ending 31

March'13 (amount in Rs. Crore)

Growth rate (%) of turnover (CAGR over last 3

years, i.e., 3/10 to 3/13)

2.2 Profit

Profit for the last financial year ending 31 March'13

(amount in Rs. Crore)

Growth rate (%) of profit (CAGR over last 3 years,

i.e., 3/10 to 3/13)

2.3 Balance Sheet

Balance Sheet for last 3 financial years ending 31

March'13 i.e., 3/10 to 3/13

Capital Structure (including share-holding patterns)

Debt Structure

3 Strength and Resources

3.1 Presence in India

Number of years in business in India

Number of offices or branches

74

Number of R&D centres

3.2 Availability of Resources

Number of employees engaged in

1. Implementation,

2. Technical support and

3. Research and Development

3.3 Accreditations

ISO 9001/27001

BS 7799

SEI CMM Level 5

3.4 IT Infrastructure Resources

Data Center ( Level / Model of ownership)

4 Implementation experience

4.1 Number and Scale of Implementations

No. of Implementations of CBS in India

(Name of client/ No. of Banks/ No. of Branches/

Duration of the project )

No. of Implementations of CBS in ASP Model

(Name of client/ No. of end users/ Duration of the

project )

No. of Implementations of ASP Model

(Name of client/ No. of Banks/ No. of Branches/

Duration of the project )

4.2 Experience in end to end implementation

DC / DR Setup (No. of Banks/No. of Branches)

Helpdesk Support for applications (No. of

Banks/No. of Branches)

Helpdesk Support for hardware and infrastructure

support (No. of Banks/No. of Branches)

Experience in integrating the solution with other

surrounding systems (No. of Banks/No. of

Branches)

Financial Inclusion

5 Reference Site Details

(Prime Bidder should furnish the reference site details in the following format for two references)

5.1 Basic Details

a) Client Name

b) Client Address

c) Telephone Number

d) Fax Number

e) Contact Name

f) Client email ID

75

5.2 Project Details

a) Scope of Project

b) Prime Bidder‗s role in the project

c) Duration of the implementation and time taken

for different stages.

d) Modules and version of the software currently

being used at HO and branches

e) Version of operating system, database in use

f) Details of any other system used in conjunction

the application software like front end systems

g) Interfaces to external systems being used

h) Number of branches using the solution

i) Total number of users and maximum number of

users in any branch

j) Total number of customer accounts and

transactions per day on average handled

k) Number of transactions processed per second

76

ANNEXURE – 6: FUNCTIONAL REQUIREMENT SPECIFICATION

The Bidders should respond to the requirements which should be under one of the following categories in an excel

format. The software is being evaluated based on presence of these functionalities but not all features might be used

ultimately.

(R) Standard Feature: The system that will be delivered already supports this functionality without further

augmentation or the use of either programming or user tools, i.e. included in the base package at no additional cost.

(S) Substitutable: If the proposed system offers an alternative to the desired functionality, please provide a written

explanation. Please clearly specify the reference number where appropriate.

(C) Customizable: This functionality would require custom alterations to the system, by Bidders‘ programming staff, as

part of the base price. The customization items mean a change/modification/alteration to the base software, to be

undertaken by the Prime Bidder.(Prime Bidders should not expect the Bank‘s users to modify or add on to the base

software using toolkits etc. for functionality not available as ‗Regular‘ in the proposed base version of the software).

(A) Augmentable: This functionality is scheduled/ expected to be released in a future update or release of the software,

and Prime Bidders will provide these features at no additional cost as part of the proposed comprehensive solution.

(U) Unavailable: The functionality does not exist in the current system and is not scheduled for release in an update

within the next calendar year and not feasible for customization also. 1 COMMON REQUIREMENTS FOR ALL MODULES Response Remarks

The requirements mentioned below are the functions / features, which are expected

from all the modules covered in this document.

1.1 Access Control Requirements: -

Provide:

1.1.1 Maker Checker Concept:

1.1.1.1 Multiple level of makers (based on a pre-defined number)

1.1.1.2 Multiple level of checkers (based on a pre-defined number)

1.1.1.3 Maker cannot be checker and vice versa.

1.1.1.4 Allow Maker checker concept to be mandatory for all transactions including to

master and parameter files.

1.1.2 Provide for maker and checker concept allowing, for entry, verification, and

authorization and post commit verification and audit by different users based on:

1.1.2.1 Product type

1.1.2.2 Account Type

1.1.2.3 Transaction type

1.1.2.4 Transaction amount

1.1.2.5 Authorization levels

1.1.2.6 USER WISE

1.1.3 Mandatory log for:

1.1.3.1 User creation , grant of user rights, modification of user rights, deletion of user

1.1.3.2 It should not be possible to delete this log without first printing it

1.1.3.3 This log should be automatically archived at the end of the day.

1.1.3.4 This Mandatory log should have a serial no.

1.1.4 Enabling user-id of new employee with dummy password which the user should be

77

FORCED to change on first log-on.

1.1.5 Disabling user-id of employees on leave / not on computer duty

1.1.6 Intruder detection (repeated unsuccessful attempts (THREE ATTEMPTS) to gain

access to the system) should be logged with date and time stamp and the terminal

should get locked after a number of pre-defined unsuccessful attempts.

1.1.7 1.1.7.1 Generation of mandatory log for all the activities carried out by highly powerful

users like System Administrator / DBA

1.1.7.2 Generation of access logs with date and time stamp on processes run user-id wise.

1.1.8 Once user logs on to the System from the client workstation, he should be taken

straight to the banking application menu (possibly using a login script) and once he

logs out of the application session, he should get disconnected from the database

with no command line access / any other means of connecting to the database (say

through SQL prompt).

1.1.9 User will be limited to a single session on the network i.e. user cannot log-in

concurrently from more than one terminal.

1.1.10 Appropriate Password Management features:

1.1.10.1 Minimum password length 8 for normal users and 10 for privileged users.

1.1.10.2 Password should be alpha numeric.

1.1.10.3 Provide for mandatory change of password for users at the end of preset time

intervals. Password expiration period should not be more than 30 days for normal

users and 15 days for privileged users.

1.1.10.4 Passwords such as user name, commonly used words etc. should not be allowed to

be used

1.1.10.5 System not to show Password while entering

1.1.10.6 In case of reset of password by another authority e.g. by DBA where the user has

forgotten his password etc.

1.1.10.6.1 Details should be captured in an exception report.

1.1.10.6.2 New users (or users whose password has been reset by administrator) should be

forced to change the password at first login.

1.1.10.6.3 In case the Bank wants to enforce stricter controls of password like not allowing use

of old passwords, use of special characters in password, longer length of password,

etc. then such capability should be available to be enforced through parameter(s) in

CBS.

1.1.11

1.1.11.1 All secret and confidential information should be stored in encrypted form.

1.1.11.2 All access to secret and confidential information should be logged.

1.1.12 Appropriate User right management features, like no user other than the System

administrator should have command line / any other means of accessing the

Operating System or Standard RDBMS database directly.

1.1.12.1 Critical data in the database should be encrypted

1.1.13 If any logged in session is inactive for more than predefined period of time

password protected screen savers should be activated and the screen saver should be

uniform throughout the organisation.

1.1.14 At the time of log in, date / time of previous log in and unsuccessful attempt to log

in, if any, should be displayed on the screen

1.1.15 CBS should have the capability to configure roles to define the user level access,

function and financial powers. Users will gain system access based on assignment

of respective roles to their ID.

1.1.15.1 Availability of menu should be restricted on the basis of user access level.

1.1.15.2 It should be possible to restrict access to menu and sub-menu to a particular user in

the group i.e. it should be possible to restrict every user in the system to specific

functions ( menu option)

1.1.16 Facility for operational security and ability to restrict access through passwords at:

1.1.16.1 System Level

1.1.16.2 User Authority Level

1.1.17 Access level (in the system) to be defined at System Level, Database Level etc.

78

1.1.18 Support for controlling access to the system by the user based on but not limited to:

1.1.18.1 Time, Date, Functionality

1.1.18.2 System Activity (BOD, Online, EOD etc.)

1.1.18.3 IP Address, Net work ports, User Activities (Input authorization etc.).

1.1.18.4 System access log should record the IP address from which a user has logged in to

CBS.

1.1.19 Support ability to assign privileges to users for functions like Display Screens,

Menus, Fields, Reports etc.

1.1.20 Support defining user activity (on transactions) access to be based on the following

and not limited to Input, Hold, Modify, Delete, Authorize, Reverse, View / Display,

Print etc.

1.1.21 Provide for a facility to have a category of accounts which cannot be viewed on

enquiry except with proper authorization.

1.1.22 Provide defining the external access levels to the database / tables based on:

1.1.22.1 View

1.1.22.2 Insert

1.1.22.3 Update

1.1.22.4 Delete.

1.1.23 While creating user-ids of employees, it should be possible to capture:

1.1.23.1 Employee number (Provident Fund Membership Number).

1.1.23.2 Identification Number of the branch where they are posted.

1.2 General Requirements: -

1.2.1 Provide ability to redesign / paint the screens to bank‗s requirement to enable data

entry operators to enter data with ease from the input forms.

1.2.2 Support custom defining of pop-up messages related to events, validations etc.

(Provision for special remarks which should pop-up while authorizing transactions

for that account or at the time of enquiry on that account)

1.2.3 Provide support or the ability to support

1.2.3.1 Branch code up to 4 digits.

1.2.4 Support definition and classification of products under a multi-level hierarchy for

the purpose of:

1.2.4.1 Definition of business rules

1.2.4.2 Definition of accounting rules

1.2.4.3 Authorization control

1.2.4.4 Defining workflows

1.2.4.5 Product channel mapping

1.2.5 Provide for configuring product templates with following parameters, but not

limited to

1.2.5.1 Product definition

1.2.5.2 Business rules

1.2.5.3 Payment / Repayment schedules

1.2.5.4 Accounting rules

1.2.5.5 Interest, commission, charges modules

1.2.5.6 Collateral requirements

1.2.5.7 Applicable customer types

1.2.6 Provide for defining product variants based on product template and assigning

standard / user-definable transaction types.

1.2.7 At the time of authorisation, details of the transactions being authorised should be

available on the screen.

1.2.8 Allow defining and setting up of authorizations as a combination of following

organizational and functional levels, but not limited to:

79

1.2.8.1 User groups

1.2.8.2 Nature of transaction

1.2.8.3 Amount of transaction

1.2.8.4 Nature of operation (transaction entry, change, deletion, clearing, blocking,

printing, batch update, end-of-day processing, query etc)

1.2.8.5 Nature of function (maker, checker, auditor etc.)

1.2.8.6 Nature of Product (e.g. Bank wise user should have access to own bank products

only)

1.2.9 Support:

1.2.9.1 Multiple Companies (‗Legal Entities‘)

1.2.9.2 Multiple Business units (‗Strategic units‘)

1.2.9.3 Multiple Locations

1.2.9.4 Multiple Products

1.2.9.5 English and Hindi Languages

1.2.9.6 Multiple Currencies

1.2.10 Support rounding up / rounding down of the amount to the nearest user-defined

unit.

1.2.11 Support defining rounding off rules for specific transactions e.g. Income Tax, TDS,

Interest etc.

1.2.12 Provide for configuring master / transaction fields for entry, default value update or

display based on nature of operation (add, modify or delete).

1.2.13 Provide for configuration of mandatory fields for master and transaction within

each module, ensuring their entry before the transaction / master entry is

‗committed‗.

1.2.14 Provide for on-line validation of all ‗codes‘ (such as product codes, classification

codes, transaction types, etc.) in any transaction / master and their on-line display of

description for visual verification.

1.2.15 Support calendar definition (and modification) for each location / branch capturing

Weekly Holidays, Public Holidays, Non-business working day, Unscheduled

holidays for each front office separately.

1.2.16 Provide for capturing and reporting of the transaction history for input as well as

changes at field level for all transactions as well as master entries, reporting:

1.2.16.1 The User(s) who made the entry

1.2.16.2 The date / time on which the entry was made

1.2.16.3 The User(s) who authorized the entry

1.2.16.4 The date / time on which authorized

1.2.16.5 The User(s) who made the changes

1.2.16.6 The date / time on which the change was made

1.2.16.7 The User(s) who authorized the change

1.2.16.8 The date / time on which the change was authorized

1.2.16.9 The NEW value of the field

1.2.16.10 Date of reference document

1.2.16.11 Date when the document was acted upon

1.2.16.12 Date of Exchange rate and the actual exchange rate used in case of foreign currency

transaction.

1.2.17 Provide capability to enquire in real time the status of the transaction and track its

progress throughout its life history, e.g. entered but not yet submitted for approval,

waiting for approval, waiting for limit checking etc.

1.2.18 Provide for a business open interface that allows business rules specific to the Bank

to be inserted into the validation and processing functions of the software.

1.2.19 Provide for automatic generation of entries / transactions based on duly

authenticated / authorised structured messages between CBS and external interfaces

/ delivery channels (ATM Switch, debit card, payment gateway, RTGS/NEFT

gateway at member bank branch, SFMS,DEMAT, ASBA internet etc).

80

1.2.20 Provide for tracking delivery channel foot-prints like user, channel type, date, time,

reference number, etc on data impacted.

1.2.21 Provide for straight through processing of transactions originating at a branch /

location and through other delivery channels across all supported products at all

stages of processing.

1.2.22 Provide for defining and processing of activities / tasks for say:

1.2.22.1 Start of Day

1.2.22.2 Start of week

1.2.22.3 Start of month

1.2.22.4 Start of quarter

1.2.22.5 Start of year

1.2.22.6 End of day

1.2.22.7 End of week

1.2.22.8 End of month

1.2.22.9 End of quarter

1.2.22.10 End of year

1.2.23 Support storage and retrieval of images of

1.2.23.1 Signature

1.2.23.2 Photographs

1.2.23.3 Thumb Impressions & Retina through biometric media

1.2.23.4 Physical documents and linking them to customer id and / or account number for

retrieval

1.2.24 Provide for automatic / manual classification / flagging of specific borrowal

accounts as Special Watch accounts / NPA (non performing assets) accounts etc.

based on user-defined rules.

1.2.25 1.2.25.1 Income accrued on NPA accounts also needs to be recognized differently for the

purpose of accounting of income, without application / accounting in interest

receivable.

1.2.25.2 System driven Asset Classification in terms of RBI guidelines (including changes

during the currency of the contract) for agriculture and non-agriculture advances /

loans

1.2.26 Provide for value dated transactions, which result in a change in the end-of-day

account balance and / or targeted to an account linked to a tiered interest rate

structure. These should be flagged as ‗exceptions‘ and processed via the end-of-day

interest recalculation program.

1.2.27 Provide for capture and automatic processing of account operating instructions

(Standing Instructions) of different types including but not limited to

1.2.27.1 For fixed amount fixed period

1.2.27.2 For variable amount

1.2.27.3 For variable amount with limit

1.2.27.4 For variable frequency

1.2.27.5 Event driven

1.2.28 Provide for retrieval of customer information required by the product (for asset as

well as liability products) e.g. all deposit products or all credit products subscribed

to by a customer.

1.2.29 Provide facility to :

1.2.29.1 Generate exception report for accounts with balances below a threshold (to be

defined as a parameter in the system).

1.2.29.2 Generate customer notices (as per formats predefined in the system) for the above.

1.2.29.3 Exclude specific customer categories such as staff / VIP etc. from the above

1.2.30 Provide for alerts based on pre-defined frequency for monitoring of due dates and

maturity lists for time deposits, payments, repayments, sanctions, collaterals,

insurance, loan instalments, loan documents etc.

1.2.31 Provide for basic calculator functionality (as a standalone facility or as an integral

81

part of input transaction) which can assist in tasks such as but not limited to:

1.2.31.1 Summing a set of numbers.

1.2.31.2 Calculating interest

1.2.31.3 Converting currencies

1.2.31.4 Calculating percentages

1.2.31.5 Calculating averages

1.2.31.6 Basic functions (add, subtract, multiply, divide, etc)

1.2.32 Support word processing features for text fields, reports, notices e.g. back delete,

forward delete, word wrap, split and join lines, format paragraphs, etc.

1.2.33 Allow for user defined backups for the following:

1.2.33.1 Online, Automated, Manual etc.

1.2.33.2 Database, Programs, Systems etc.

1.2.34 Provide For:

1.2.34.1 Audit trail of additions / deletion / modifications to parameter file / master file etc.

should be available.

1.2.34.2 Report should be available for record / audit purposes along with values before and

after entries / modifications.

1.2.35 System should automatically generate an indent for supply of security printing

items SB / CA / CC account cheque books, demand draft leaves etc when the stock

falls below the minimum prescribed level which should be parameterised

1.2.36 Wherever there is override of a given rule / parameter it should be captured in an

exception report and printed automatically as part of EOD.

1.2.37 It should be possible to generate exception reports for a given period for a given

account.

1.2.38 Provide for Alerts in case of certain exceptions to specified persons.

1.2.39 Ability to define both Error messages and Override messages (in case of error

messages system should not allow to proceed EOD and in case of over rides should

allow to continue EOD with over ride).

1.2.40 System should permit EOD processing only after ensuring that

1.2.40.1 All transactions are authorized.

1.2.40.2 Entries / modifications in masters / parameters etc are authorized.

1.2.40.3 In case of any unauthorized transaction / entry / untallied batch etc. appropriate

error message should be displayed and proceed as per 1.2.39 above.

1.2.40.4 Account balances are made available in one of servers / PC at each of the branches

to cope with communication failure with data center.

1.3 Interest Calculation:

1.3.1 Allow interest calculation based on but not limited to:

1.3.1.1 Daily product

1.3.1.2 Month end balance (staff housing loans)

1.3.1.3 Minimum balance between two predefined dates (Savings a/c)

1.3.1.4 Average balance maintained in the account between pre-defined dates / periods.

1.3.2 Support stepped interest rate calculation based on stepped interest rate

1.3.2.1 Based on amounts (e.g. 0-500: 5%, 501-1000: 5.5%)

1.3.2.2 Based on period (e.g. 1st yr 5%, 2nd yr 5.5% etc.)

1.3.3 Provide for maintaining multiple fixed and floating interest rates applicable to

different products.

1.3.4 Enable floating rate to be held as Base rate + Spread (both of which are variable,

independent of each other). The spread could be positive or negative.

1.3.5 Support interest calculation based on but not limited to

1.3.5.1 360 days

1.3.5.2 365 days

1.3.5.3 Leap year adjustment

82

1.3.5.4 12 months and balance days / 30

1.3.6 Support interest rate changes with retrospective effect and consequential

recalculation of interest automatically on all interest bearing assets and liabilities.

1.3.7 Provide for back value dated interest rate calculations for 'X' months where 'X' is a

parameter

1.4 Product Accounting

1.4.1 Provide for configuring / defining accounting rules for individual product and

generating accounting entries that will be passed to the General Ledger module.

1.4.2 Ensure automatic generation of accounting entries, on-line at the time of data entry

or batch update itself, based on the pre-defined rules above.

1.4.3 Provide for interfacing with the General Ledger Module at individual transaction

entry level (individual entry routed to General Ledger) or as consolidated entries

(consolidated for a period, transaction type etc.) based on pre-defined parameters

(say, for pension payments).

1.4.4 Support accounting for

1.4.4.1 Amortization of fee and interest

1.4.4.2 Multiple business units

1.4.4.3 Multiple products

1.4.4.4 Multiple cost-centers

1.4.4.5 Multiple profit-centers

1.4.4.6 Multiple delivery channels

1.4.4.7 Multiple currency

1.4.4.8 For asset and liability accounts of customers in FCY, system should support interest

accounting in home currency (INR).

1.4.5 Provide for single transaction of value as large as ‗9,999,999,999,999.99‘ (i.e. 13.2

where the decimal separator is ―.‖). Decimal should be definable for each currency.

1.4.6 Provide for storage of totals as large as ‗999,999,999,999,999.99‘ (i.e. 15.2 where

the decimal separator is ―.‖)

1.4.7 Allow data entry as well as printing of transactions as well as total amounts with

following formats (both in figures and words) for all screens, reports, documents

(including cheque printing) with ―.‖ as decimal separator and ―,‖ as thousand /

lakh / million / crores separator.

1.4.7.1 Millions, Billions and Trillions

1.4.7.2 Lakhs and Crores

1.4.8 Provide for printing of all documents either on blank sheets or pre-printed

stationery, as per Bank's own format, individually or in bulk based on user

selectable filter parameters.

1.4.9 Provide for capture of all financial transactions concurrently for Accounting unit

Currency (‗Local Currency‘)

1.5 Batch Updates: All modules in the proposed solution should have batch update

capability, as per requirements specified hereunder

1.5.1 Provide for ‗Batch Update‘ or ‗Job Stream‘ update for all data entry screens.

1.5.2 Ensure that validations and authorization for batch processing necessarily follows

the settings defined for corresponding on-line data entry transactions.

1.5.3 Provide for identification and alerts for ‗missing batches‘ based on batch numbers.

1.5.4 Provide control and monitoring support for batch-processing updates with support

for review of batch values before committing the postings.

1.5.5 Provide for complete rollback of the entire batch in the event of failure of batch

processing.

1.6 Income tax, Service Tax etc.

Income tax/TDS, Service tax calculation needs to be supported by all modules,

which have incidence of income tax, service tax etc e.g. deposits, advances,

treasury, general ledger etc. The system has to adequately support all requirements,

statutory or otherwise, of all types of tax. The requirements have been listed in

detail in the following section. The system should provide for multiple tax

83

deduction structure at the customer / account type level and linking of tax

calculation structure and account type.

1.6.1 Support automatic calculation of income tax, service tax etc for both product

accounts as well as general ledger accounts (such as vendor payable accounts,

receivable accounts etc.)

1.6.2 Support classification of taxes as income tax, service tax, any other type of tax for

statutory reporting.

1.6.3 Support configuring of income tax, services tax etc.– statutory codes and rules,

specifying but not limited to

1.6.3.1 Basis and method of calculation

1.6.3.2 Default percentage rates

1.6.3.3 General accounts to which tax effects may be posted

1.6.3.4 Statutory codes

1.6.3.5 Application State, location

1.6.3.6 Reasons for exemptions, concession

1.6.3.7 Model rules / templates

1.6.4 Support defining of Income tax, service tax specifying but not limited to

1.6.4.1 Concessional Percentages rates with reasons

1.6.4.2 Effective dates

1.6.4.3 Numbering rules for the certificates as and when desired (based on model rules /

templates)

1.6.5 Support automatic calculation and deduction of specific type of Income tax, service

tax at the time of:

1.6.5.1 Accounting / Provision / Recognition of payable / receivable transaction

1.6.5.2 Down Payment.

1.6.6 Support calculation and deduction of specific type of Income tax, service tax only at

the time of payment.

1.6.7 Support calculation and deduction of specific type of Income tax, service tax only at

the time of accounting or recognizing of the payable or receivable transaction.

1.6.8 Ensure integration of the Income tax, service tax functionality with general ledger,

accounts receivable and accounts payable functionality.

1.6.9 Ensure integration of the Income tax, service tax functionality with automatic

payments functionality if any.

1.6.10 Ensure support for all statutory reports / tax returns based on, but not limited to

1.6.10.1 Classification of Tax

1.6.10.2 Tax Codes

1.6.10.3 Accounting Entity

1.6.10.4 Branch ID

1.6.10.5 Nature of Transaction

1.6.11 Ensure capture and reporting of additional information required for statutory tax

returns which include

1.6.11.1 Parties to the Transaction

1.6.11.2 Tax deduction Certificate number ( branch & fiscal year specific) and date

1.6.11.3 Statutory Tax Code

1.6.11.4 Reason for Exemption

1.6.11.5 Concessional rate and reason

1.6.11.6 Reference to document seeking exemption / concession e.g. Form 15H.

1.6.12 System should be capable of marking whether tax is applicable or not and specify

reasons why it is not applicable. (This should be done at transaction level)

1.6.13 Support grouping of accounts for calculation of tax, where the first account holder

is common in single / Joint accounts.

1.6.14 Allow verifying as well as setting up of the tax liability of an account transferred

from another branch.

84

1.6.15 There should be facility for printing all details of Income tax either in the form of

certificates, reports etc in user-definable formats.

1.7 Reporting and Enquiries: -

1.7.1 Generate all prescribed reports product-wise / functional area-wise / customer-wise

/ branch-wise etc

1.7.2 Enable user to customize reports as per requirements.

1.7.3 Enable sorting of the user-defined reports based on any of the fields in the report.

1.7.4 Enable users to define filters, selection criteria on any field or group of fields for

generation of such report.

1.7.5 Enable users to define grouping, totalling on any field in the user defined reports.

1.7.6 Enable user to select results of formulae (addition, subtraction, multiplication,

division of value in field(s) with a constant or with value of another field) for

incorporation in the report.

1.7.7 Support user-defined page and column headers, footers, paper size, etc. in such

report.

1.7.8 Support generation of reports in electronic form for storage and transmission and

text form for printing.

1.7.9 Some reports should be outside the ambit of report write facility for security and

internal control reasons. Such reports must be produced only using specific

programs in the system, either as part of EOD / BOD or using specific menu

options.

1.8 General Interface / Integration Requirements: -

1.8.1 All modules within the application should be completely integrated.

1.8.2 All modules should support (on-line and / or batch) interface with other front-end

and back-end applications but not limited to:

1.8.2.1 Core banking transaction applications (including Demand and Time Deposits,

Credit Products, Trade Finance, Funds Payment / Transfer, Cash Management,

Government Business, Custodial Services etc)

1.8.2.1.1 Clearing

1.8.2.1.2 General Ledger

1.8.2.1.3 Head Office

1.8.2.1.4 Specific interface with other delivery channels (including ATMs, DEMAT/CTS

Kiosks, Call Centre, Mobile banking, Tele-banking etc)

1.8.2.1.5 Internet Banking Applications

1.8.2.1.6 Payment Gateway including RTGS/NEFT /SWIFT/IMPS

1.8.2.2 Enable opening of account with retrospective effect to facilitate taking in such

accounts.

1.8.3 Support and ensure full interface with external solutions / mechanism for

1.8.3.1 Payment

1.8.3.2 Settlement (including RTGS/NEFT/DEMAT)

1.8.3.3 Clearing

1.8.4 Support processing of structured messages from but not limited to

1.8.4.1 Electronic media (e.g. INFINET, SFMS)

1.8.4.2 RBI Interface – Electronic Funds Transfer, Electronic Clearing Services, CTS etc.

1.8.5 Support generation and transmission of all messages by various products and

accounting systems through INFINET, SFMS, Fax, e-mail or Mail or their

combination as desired by the user. Similarly system should support taking

messages from these and process in CBS)

1.8.6 Provide for interfacing with other systems at detailed transaction level as well as

rolled-up summary level.

1.8.7 Provide for user-friendly support for synchronization of data with interfacing

systems / applications.

1.8.8 Provide for user-friendly support for reconciling of data with interfacing systems /

85

applications.

1.8.9 Support facility for uploading data files from customers such as but not limited to:

1.8.9.1 Payroll data from Institutions

1.8.9.2 Stock Statements

1.8.9.3 QIS data etc.

1.8.10 Ensure interface with external data feeds for but not limited to

1.8.10.1 Stock Rates

1.8.10.2 Customer Rating Information etc.

1.8.11 Support interfacing all types of printers

1.8.12 Support defining printer types on

1.8.12.1 Central Server

1.8.12.2 Branch Server

1.8.12.3 Client Workstation

1.8.13 Support parameterization of the following and not limited to (for the printer)

1.8.13.1 Font selection

1.8.13.2 Page Length Selection

1.8.13.3 Page Width Selection

1.8.13.4 PRINTING MUST BE DONE ONLY WITH WINDOWS SETUP, NOT through

DOS

1.8.14 Ability to define keypad (num pad ) for data entry operators

1.8.14.1 Support setting up of hotkeys for certain predefined functions (e.g. help, commit

etc.)

1.9 Branch Information

1.9.1 Support capturing of details of the Branch including but not limited to:

1.9.1.1 Branch Name

1.9.1.2 Bank Code

1.9.1.3 Branch ID

1.9.1.4 Branch Code (for clearing)

1.9.1.5 Address

1.9.1.6 Phone Number

1.9.1.7 Branch Category

1.9.1.8 Branch Size

1.9.1.9 MICR Code

1.9.1.10 Area Code

1.9.1.11 State Code

1.9.1.12 Weekly Holiday

1.9.1.13 Whether ATM attached, how many and also whether on site / off site

1.9.1.14 IFSC Code

2. SIGNATURE VERIFICATION

2.1 General Requirements:

System should permit online signature verification. In case of accounts of illiterates,

photos should be displayed along with thumb impression.

2.1.1 System should work with a common database for all modules in the branch

2.1.2 Signature is associated with:

2.1.3 Customer

2.1.4 Staff

2.1.5 Signatures may be retrieved and viewed for any Customer / staff etc. from any

client PC. If customer has multiple authorised signatories, signatures of all

86

authorised signatories should be retrieved at transaction time along with mode of

operation

2.1.6 Signature scanning and authentication should be possible at any client PC. Facility

for modification of signatures should be available along with history of changes.

Changes made should be captured in the exception report.

2.1.7 Provide for uploading of scanned signatures to common database (after due

authentication) in:

2.1.8 Batch mode

2.1.9 Online mode

2.1.10 Only authenticated signatures can be used for verification purpose.

2.1.11 Scanned signatures should be stored in compressed format.

2.1.12 The compressed signatures should be encrypted and stored.

2.1.13 System should be able to seamlessly integrate with other modules for transaction

processing.

2.1.14 Zooming of signatures (with various levels of zooming) should be possible.

2.1.15 It should be possible to group signatures together.

2.1.16 User should be able to assign particular Signatures to groups.

2.1.17 It should be possible to search and display signatures based on :

2.1.18 Account number

2.1.19 Customer id

2.1.20 Location

2.1.21 Others

2.1.22 Sorting facility for a given display

2.1.23 System should be able to link and show key data like account number, name, limits

period of validity etc. along with signature.

3 CUSTOMER INFORMATION

Customer Information module will hold customer information / profile for all the

customers of the branch across various products of the bank. The module will

ensure standard customer information across various product solutions with the

specific object of providing a single view of customers across products. The module

should have the capability to integrate with all other modules which support

individual products like loans, deposits, trade finance, treasury products etc.

The module should have in-built design to show single view of all relations of a

customer with the bank. During creation of every new customer, the module should

check existence of earlier record of the same customer based on key

parameterisable fields (Like PAN/Passport/DL number) and duplicate ID should

not be created under the circumstance.

3.1 Customer Profile

Ability to record structured profiles of each Customer of the branch including

Retail, Corporate, Government etc. which would include the following information

but not limited to:

Unique Customer Identification Number

3.1.1 3.1.1.1 INDIVIDUALS

Following details regarding individuals as single / joint account holder, proprietor,

partner, director etc. as well as borrower, guarantor etc. are required to be captured:

3.1.1.2 Name (s) and Mother‘s/Father's Name of Joint account holder with mandatory

detail

3.1.1.3 Individual field length for capturing each component of customer details mentioned

below should be parameterised:

3.1.1.4 Salutation

3.1.1.5 First name

3.1.1.6 Middle name

3.1.1.7 Last name

3.1.1.8 Title

3.1.1.9 Name of mother/father / spouse

3.1.1.10 Nationality

87

3.1.1.11 Date of birth

3.1.1.12 Name of guardian in case of minor

3.1.1.13 Marital status (Married, single, widower etc.)

3.1.1.14 Residential status

3.1.1.15 Passport details such as date of issue, valid till, issued by, passport number

3.1.1.16 Current address with pin code (minimum six fields)

3.1.1.17 Permanent residential address with pin code (minimum six fields)

3.1.1.18 Voter ID card number, date of issue and issuing authority

3.1.1.19 PAN card number

3.1.1.20 UID (Aadhaar) Card number/NPR (National Population Registry) number, Date of

Issue and Place of Issue - electronic capture and validation

3.1.1.21 Telephone number

3.1.1.22 Fax number

3.1.1.23 Mobile number

3.1.1.24 E-mail address (additional five fields may be provided)

3.1.1.25 Other Details

3.1.1.26 Date of Commencement of Customer relation

3.1.1.27 Number of dependents

3.1.1.28 Name of each dependent

3.1.1.29 Relationship

3.1.1.30 Occupation

3.1.1.31 Designation

3.1.1.32 Office address (provide for minimum 6 fields)

3.1.1.33 Phone number (provide for minimum 5 fields)

3.1.1.34 Annual Income

3.1.1.35 PAN Number and issuing authority

3.1.1.36 Details of contact persons (with relationship ),

3.1.1.37 Manager, Power of Attorney Holder, etc

3.1.1.38 Group Code for definition of Customer Hierarchy (used to flag individual within a

group OR Family Code for grouping all members within a family) should provide

for at least two levels of Hierarchy.

3.1.1.39 Whether the Individual is an agriculturist-Y / N

3.1.2 3.1.2.1 Non-Individuals

3.1.2.2 In case of accounts of other than individuals the following details would have to be

captured

3.1.2.3 Name of Organisation

3.1.2.4 Constitution (e.g. Proprietorship, Partnership, Private Ltd. Company, Public Ltd.

Company, Club, Trusts, HUF, Government, Autonomous body etc.)

3.1.2.5 Provide for particulars of proprietors / partners / directors / promoters etc. as given

for individuals herein above.

3.1.2.6 Phone numbers - Provide for five fields

3.1.2.7 E-mail id

3.1.2.8 Fax Number - Provide for five fields

3.1.2.9 Activity Code as per Basic Statistical Return (BSR)

3.1.2.10 Date of incorporation

3.1.2.11 Date of commencement of business

3.1.2.12 Whether enjoying credit facility from any other bank- Y / N

3.1.2.13 If Yes, then name of bank, branch and address.

3.1.2.14 Whether no objection certificate from that bank has been obtained – Y / N

88

3.1.2.15 PAN Number

3.1.2.16 Introduction Details

3.1.2.17 Details of Introducer (could be another existing customer and in such case customer

id of that customer will do) such as name (three fields), address(six fields), etc.

3.1.2.18 Provide for maintaining a list of individuals / banned organisations / entities etc. as

per Anti Money Laundering measures for validation purposes so that accounts in

such names are not allowed to be opened in the system.

3.1.3 Provide For Specific Details

3.1.3.1 Specific details are required to be captured with respect to following but not limited

to:

3.1.3.2 Credit Ratings from External Agencies

3.1.3.3 Credit Risk Indicators

3.1.3.4 Litigation Status

3.1.3.5 Consortium bank / multiple banking arrangement details

3.1.3.6 Any other (user definable – at least another 10 fields)

3.1.4 Credit Ratings from External Agencies. An illustrative list of status will include:

3.1.4.1 Credit Rating Agency

3.1.4.2 Rating

3.1.4.3 Rating definition

3.1.4.4 Rating date

3.1.5 Credit Risk Indicators. An illustrative list will include:

3.1.5.1 Wilful Defaulter

3.1.5.2 Missing person

3.1.5.3 On watch list of the Bank

3.1.5.4 RBI defaulters list

3.1.5.5 RBI Exporter‗s caution list / SAL of ECGC / DGFT caution list

3.1.5.6 Dormant Customer

3.1.5.7 Inoperative Customer

3.1.5.8 NPA / Special Watch account flag

3.1.6 Litigation Status. List should include, but not limited to:

3.1.6.1 Court case proceedings as ‗defendant‘

3.1.6.2 Official seizure and sale by public auction

3.1.6.3 Official liquidation

3.1.6.4 BIFR reference Date

3.1.6.5 BIFR Registration Date

3.1.6.6 BIFR Reference Number

3.1.6.7 BIFR status Code

3.1.6.8 BIFR status date

3.1.7 Consortium bank / Multiple banking arrangement details for credit customers

3.1.7.1 Bank Name

3.1.7.2 Bank Code

3.1.7.3 Consortium Leader

3.1.7.4 Income Recognition Classification for the consortium Bank

3.1.7.5 Asset Classification for the Consortium Bank

3.1.8 Provide for maintaining more than one value per Customer Profile with ‗Effective

Dates‘ for Specific fields like, but not limited to:

3.1.8.1 Credit Ratings

3.1.8.2 Litigation Status

3.1.8.3 Consortium Bank Details

89

3.1.8.4 Operation Status

3.1.9 Support creation and maintenance of drop down list for individual fields based on

standard / User-defined classifications during creation of Customer Profiles and all

related Masters (for example when system comes to religion field a drop down list

should come with options of religion like Hindu, Christian etc.)

3.1.10 Product Utilization Information

3.1.11 Provide for identifying various Products being Used by the Customer across the

Bank including Retail Products, Corporate Products, Cash Management etc. as well

as to enquire balance outstanding under each head / product

3.1.12 Provide for identifying Products not yet taken up by the Customer

3.1.13 Provide for targeting of specific products to the Customer based on the Customer

Profile.

3.1.14 In case of change of constitution of the customer, support linking of accounts to the

new customer Profile

3.1.15 Controls and User Support

3.1.16 Allow staged completion of the customer profiles creation process (e.g. create a

customer with just a customer-id and name with the ability to add / modify

additional details at a subsequent stage) (COMPLETION OF REMAINING

DETAILS BE MADE MANDATORY BEFORE EOD)

3.1.17 Allow combination of two or more customer ids to be linked to a joint account.

3.1.18 Ability to accept customer information details in electronic form (e.g. account

opening request from web-interface where the customer will enter part of the

customer information).

3.1.19 Provide for on-line verification of introducer‗s signatures, in case the introducers

are customers of the Bank / branch.

3.1.20 Provide for classification of accounts as per customer type / subtype: e.g.

Individual>Male>Pensioner>Defence-personnel>Physicallyhandicapped

3.1.21 Reports and Inquiries

3.1.22 Provide ad hoc and standard reporting capabilities based on individual customers,

customer type for both user defined and system default periods and locations

including, but not limited to the following report components:

3.1.23 Enable creation of reports based on individual / combination of fields in the

customer master.

3.1.24 Generate audit report of additions, amendments and deletions to customer master.

3.1.25 Provide support to query on the customer limits as well as MIS information based

on user-defined parameters.

3.1.26 Interface / Integration

3.1.27 The customer information records are expected to be accessible by all other product

/ transaction systems. The customer information system should allow for on-line

access / querying of its database by external systems by standard database query

drivers / utilities.

3.1.28 Accept information from the web site for request for account opening.

3.1.29 Enable straight through processing for information received from the web interface,

to set up customer profile and open an account.

4. CASH DEPARTMENT

4.1 General Requirements

4.1.1 Provide facility to define functions / operations, which can be performed by each

teller / cashier:

4.1.1.1 Support limits for tellers based on:

4.1.1.2 Type of accounts

4.1.1.4 Type of transactions

4.1.1.5 Amount of transactions

4.1.1.6 Ability to handle cash limits for receipt/payments in respect of products (Like

SB/CA/CC), instruments (DD/PO).

4.2 Teller / Cashier Operation

4.2.1 Provide facility for the teller to view customer‗s signature on screen for verification

90

and account operating instructions.

4.2.2 Provide teller functions in local currency (INR) as well as foreign currencies.

4.2.3 Support exchange of currency, denomination-wise, between two or more tellers /

cashiers and head cashier.

4.2.4 Support tendering of change to customer, denomination-wise.

4.2.5 Support payment of cash for demand drafts, pay orders, bank orders, traveller‘s

cheques etc.

4.2.6 Provide for issue / printing of drafts, pay orders, bank orders etc. by the teller.

4.3 Cashier Operations

4.3.1 Cashier to be able to query / call on terminal-only cash transactions already

authorized for payment, pay cash, enter denominations and flag transaction as ‗cash

paid‘.

4.3.2 Provide for enquiry on cash on hand and denominations to monitor cash. All cash

receipts and payments and creation of opening and closing of cash should be linked

to recording denomination of cash for the transaction. Facility of denomination-

wise cash reconciliation should be available.

4.3.3 Provide for enquiring on status of transactions, whether entered, already authorized

etc based on amount, account number and type etc.

4.3.4 Generation of cash scrolls, payment and receipt for end-of-day handing over of cash

to Chief / Head cashier / Cashier in Charge.

4.4 Chief / Head Cashier Operations

4.4.1 Support facility to record open / close status of vault

4.4.2 Support automatic verification of Cash-on-Hand position (as per General Ledger) at

end-of-day (EOD) with EOD cash inventory position and pop-up message in case

of discrepancy. (EOD to be allowed to go ahead only if there is no difference).

4.4.3 Should allow for a teller function and a cashier function optionally.

4.4.4 Cashier should be able to receive / pay amounts with authorizations. At least two

levels of authorizations must be provided for.

4.4.5 There should be a provision for storing a token number and scroll number for each

cash payment / cash receipt.

4.5 Cash Deposits

4.5.1 Provide a facility for cash deposit to all permitted account types for credit of

accounts across all CBS branches. (SUBJECT TO USER DEFINED CHARGES

OVER AND ABOVE REDFINED LIMIT OF CASH DEPOSIT)

4.5.2 Provide for Cash handling charges on User defined parameters

4.6 Cheque Deposits

4.6.1 Support cheque deposit (and their classification for the purpose of printing of

statements and monitoring) of the following types:

4.6.1.1 Cheque drawn on another customer of same branch.

4.6.1.2 Cheque drawn on another customer of same bank but different branch.

4.6.1.3 Cheque drawn on another customer of another bank in the same city.

4.6.1.4 Cheque drawn on another customer of another bank in different cities.

4.7 Cash Payments

4.7.1 Enable cash withdrawal from specified account type using withdrawal slips /

vouchers.

4.7.2 Allow withdrawal of cash using cheques as well as payment of DDs, POs, and BOs.

(IN CASE OF DDs, PO and BOs and TERM DEPOSIT ACCOUNTS A

PREDFINED LIMIT SHOULD BE FIXED FOR CASH PAYMENT; say Rs.

20,000/-)

4.7.3 Allow cash withdrawal across branches and validate for cheque number, cheque

date, stop payments in case cheques are used for withdrawals.

4.8 Data Input for teller operations

4.8.1 Provide facility to enter transaction (e.g. Cheques) in batch mode or single

transaction mode.

4.8.2 Support input of transactions affecting internal accounts like Cash-Remittance-in-

Transit, Working Expenses, Sundry Debtors, Rent Payable etc

91

4.8.3 Allow authorization of inputs, when done for a batch, ONLY WHEN the batch is

balanced. Support for unbalanced batches based on entry /partial updation etc. in

case of problems during entry / updation.

4.8.4 Allow marking of transactions as reversed (rather than passing contra entry to

cancel the erroneous entry) which should be captured in exception report.

4.8.5 Support functionality to allow access to the above-mentioned facility only to

predefined users.

4.8.6 Support facility to authorize multiple transactions using a single function with

overrides if any for transactions. Any overrides should be captured in exception

report.

4.9 Printing of Pass-Book, Statement ,Demand Draft and Pay Order at teller

counter

4.9.1 Passbook layouts and transactions should be user-definable

4.9.2 Allow printing of a statement on demand, e.g. the remaining transactions after the

issue of a periodic statement. The statement layouts and transactions should also be

user-definable.

4.10 Handling of Foreign Currency

Support recording currency-wise deposits and withdrawals of foreign currency,

denomination-wise.

Should be able to reflect position of foreign currency held, currency-wise and

denomination-wise.

4.11 Report Inquiries

4.11.1 Enable teller to scan at any time his journal on the terminal to view transaction log,

amount, account number, code, etc. or to trace errors.

4.11.2 Provide a facility to view cash position for each teller at any point of time.

Similarly, facility to view consolidated cash position for the branch at any point of

time (without closing cash position).

4.11.3 Allow generating of list of all transactions, function wise, (cash deposit, cash

withdrawal, cheque deposit, etc.). Rectification of incorrect entries to be allowed in

each function.

4.11.4 Provide for generation of report on transactions of pre-defined amounts for a given

period as per Anti Money Laundering (AML) measures.

4.11.5 Provide for a report on branch totals to be produced when all the tellers in the

branch have completed the ‗Final sign off‗.

4.11.6 Provide for a cash analysis report, for each Teller and consolidated at branch level.

4.11.7 Enable facility that allows the teller to inquire on all clients / transactions using

various search methods. The search criteria to be user definable. (e.g. alphabetical

order, matching name, transaction type / AMOUNT WISE AND CHEQUE WISE

etc.)

4.12 Interface / Integration

4.12.1 Provide support for connecting other devices such as swiped card reader and accept

data as input bar-coded pass-books for automatic updation.

4.12.2 Provide support for interfacing with smart card and pre-paid card solution.

5. CLEARING

5.1 General Requirements

Provide for following categories of clearing:

5.1.1 MICR clearing

5.1.2 Non MICR clearing

5.1.3 Inter Bank clearing ( Magnetic media based clearing system)

5.1.4 High value clearing

5.1.5 National clearing

5.1.6 Cheque truncation-Image Based Clearing.

5.1.7 Electronic Clearing Service

5.1.8 Outstation clearing or any other clearing as per RBI norms

5.1.9 System should support various types of clearing under each of the above category :

92

5.1.9.1 Inward clearing

5.1.9.2 Outward clearing -- as well as provide for data entry for next working day

5.1.9.3 Clearing returns – Provide for generation of outward debit note and processing of

inward debit note

5.1.10 To provide for more than one clearing per day in each of the above categories.

5.1.11 There may be more than one Clearing zone in most of the Centers:

5.1.11.1 Customers may be credited on a pre-defined working day, (mostly on next day from

the date of deposit).

5.1.11.2 Customer may be allowed to utilize the funds after a pre-defined number of days as

per the clearing norms at the center.

5.1.12 Provide for on line posting, as well as batch posting. System to suggest measures

for double-checking of batches posted to ensure correctness.

5.1.13 Provide for handling of multiple cheques deposited under one Pay-in slip.

5.1.14 Provide for credit to multiple accounts from one cheque.

5.1.15 To generate unique reference number for every deposit of Cheques.

5.1.16 Provide for automatic transfer of net balance to RBI clearing account /local-clearing

account.

5.1.17 Give daily status of net amount ‗due to‘ or ‗due by‘ RBI / SBI / clearing house

including re-conciliation of account.

5.1.18 To provide for handling of electronic funds transfers (Electronic debits and credits

not internal to the bank)

5.1.19 Provide for recording and handling payments of dividend warrants separately

including through electronic clearing service.

5.1.20 Provide for beginning and end of clearing cycle so that no instruments can be

included after the end of the clearing cycle.

5.2 Outward clearing

5.2.1 Provide for following functionality for all categories of clearing:

5.2.2 Provide for capturing of the following information but not limited to:

5.2.2.1 Customer ID

5.2.2.2 Customer's account type and number

5.2.2.3 Cheque number / Cheque date

5.2.2.4 City code

5.2.2.5 Branch code

5.2.2.6 Bank code

5.2.2.7 Type of instrument

5.2.2.8 Amount

5.2.2.9 Account number of issuing party

5.2.2.10 MICR code

5.2.3 Provide for capture of cheque image for enabling capacity for cheque truncation.

5.2.4 Provide for capability to interface with the cheque truncation software as may be

provided by RBI / external agency.

5.2.5 Support upload of the above details pertaining to the instruments from the file

generated by the reader and sorter machine.

5.2.6 Support identification and sorting of the intra bank and inter bank cheques and

support clearing of cheques locally without being sent to RBI, if required.

5.2.7 Support generation of list of instruments bank wise (for inter-bank) and branch wise

(for intra-bank) for each clearing (formats of the lists to be defined by the user).

5.2.8 Allow defining the following dates:

5.2.8.1 Clearing data entry date, credit date and clearing clear date:

5.2.8.2 Posted date: date on which RBI gives credit to the concerned Bank. Customer

account begins to earn interest from this date.

5.2.8.3 Cleared date: funds are cleared and available to the customer provided for crediting

the entries in the account based on these dates and mark the balances as cleared etc.

93

5.2.9 Provide for marking for returned cheques and posting them automatically to the

customer‗s accounts along with charges.

5.2.10 Provide for postponement of uncleared funds and not advancement in relation to

pre-defined days / period.

5.2.11 Provide for two fields - one for voucher details and other for cheque details.

5.2.12 System should flash message in case of undetailed batch or un-tallied batch.

5.2.13 To provide for charges in respect of outward clearing return instruments and

generate vouchers.

5.2.14 To provide for authorization of all entries.

5.2.15 To generate responding entries in respect of outward clearing

5.2.16 PROVIDE FOR VIEW OF ACCOUNT STATUS (e.g. Inoperative / Minor / Blind

/ILLITERATE /KYC norms complied / FREEZED etc.) ON DEPOSIT OF

CHEQUE

5.3 Generation of reports

5.3.1 Provide for generation of Debit Note Issued.

5.3.2 Provide for generation of clearing register based on clearing type and batch number

5.3.3 Provide for generation of advices and vouchers

5.3.4 Provide ASCII file listings of instruments presented in a particular clearing on a

particular day to enable power encoding through Reader -encoder using MICR

technology.

5.4 Inward clearing

5.4.1 Support following functionality for all categories of clearing:

5.4.1.1 Provide for validation of cheque number / date and stop payment instructions before

the cheque is cleared for payment.

5.4.1.2 A cheque number once paid should not be allowed to be presented again for

payment

5.4.1.3 When a cheque is presented again, a warning should be flashed to the user and

should be committed only by the user and NOT AUTOMATICALLY.

5.4.1.4 In case of a batch posting, system should reduce the available balance dynamically

from the Customer's account after every cheque.

5.4.1.5 Provide a facility to automatically store and make available on enquiry, information

such as when and where the cheque is presented and cleared and whether cleared or

stopped, payment to which bank etc.

5.4.1.6 Support generation of auto referral to the authorized persons in case of insufficient

funds.

5.4.1.7 The INSTRUCTION OF OPERATION & signature of the customer should be

shown on screen before posting of the cheque and the following validations must be

carried out:

5.4.1.7.1 Validity of the account.

5.4.1.7.2 Account is not blocked or closed.

5.4.1.7.3 Cheque is not stopped for payment

5.4.2 To generate voucher and Cheque Return Advice in respect of returned cheques

containing the following details:

5.4.2.1 Service charges to be automatically debited to the customer's account.

5.4.2.2 Reason for return.

5.4.2.3 Cheque details.

5.4.2.4 NAME OF DRAWEE / PRESENTING BANKER SHOULD BE MENTIONED

ON THE RETURN MEMO

5.4.3 To generate responding entries in respect of inward clearing.

5.4.4 To provide for all posting of cheques, account wise individually.

5.4.5 To provide for scrutiny of list and confirmation of cheques to be returned.

5.4.6 Provide for authorization of remaining entries excluding the deletion entries in

respect of returned instruments.

5.4.7 Provide for Debit Note Receivable Account (pointing account).

94

5.5 Service Branches

5.5.1 5.5.1.1 Support receipt of clearing data by the Clearing (Service) branch from all the

designated branches in the format as prescribed by the user. This may be based on:

5.5.1.2 Drawee bank, drawee branch, presenting bank, presenting branch.

5.5.2 Support creation of summarized clearing data branch-wise, instrument type wise,

account wise etc., with printed and soft copy.

5.5.3 Enable consolidation of the soft copy of the clearing data received from different

branches in user defined formats.

5.5.4 Allow the user to define the period by which credit has to be passed on to the

branches for different types of clearing.

5.5.5 Allow for marking of returned cheques. Allow for sorting the unpaid or returned

cheques bank-wise and branch-wise with reasons thereof.

5.5.6 Generate the clearing data to be sent back to the originating branches giving the

details of cleared cheques and returned cheques. The format of these statements

may be defined by the user.

5.5.7 Support automatic credit to customer‗s accounts for cheques that have been cleared.

5.5.8 Ability to automatically reverse the entries in customer accounts for cheques that

have been returned unpaid.

5.5.9 Ability to debit the customer's account for recovery of the charges for unpaid

cheques automatically.

5.5.10 Provide for automatic transfer of net balance to Reserve Bank of India clearing

account / local clearing (Outward).

5.5.11 Support re-present option for those cheques, which have been returned unpaid.

5.5.12 Support sorting of the data on user-defined parameters for all cheques received

5.5.13 Enable data upload of inward items to inward clearing based on the data received in

soft copy from Reserve Bank of India / Clearing house or Input the data generated

by the MICR reader at the service branch and also to modify cheque date and

payee's name.

5.5.14 Ability to match the instrument details received from the clearing house with the

details of instruments sent to the clearing house and identifies and reconciles any

differences.

5.5.15 Should be able to support cheques / DDs drawn on branches maintained in another

DATA CENTRE of the bank to be uploaded and paid.

6. Deposits Requirements:

Accounts of Resident Indians:

6.1 Opening of Account:

6.1.1 Existence of customer record to be mandatory for opening a new account

6.1.2 Records must be created and authorised by the supervisor as per maker-checker

concept except system generated accounting entries. Necessary accounting entries

must be passed in respective GL head. Provide option for Single / Dual

authorization as per user requirement for any record / transaction level entry.

6.1.3 Provide for Trigger/Alert on Transaction in Minor accounts on Minor Turning

Major

6.1.4 Support various liability products, including but not restricted to:

6.1.4.1 Savings Bank - General, Staff, Salary, No-Frill, Pension, NRE / NRO

6.1.4.2 SB Society/Institutional

6.1.4.3 Current Deposit - General, Society, Banks, NRE/NRO

6.1.4.4 Fixed deposit (General) where interest is paid out to the depositor periodically

6.1.4.5 Cumulative Fixed deposit

6.1.4.6 MIS

6.1.4.7 RD

6.1.4.8 Savings related insurance

6.1.4.9 Term Deposit (Senior Citizen)

6.1.4.10 Term Deposit (Staff)

95

6.1.4.11 Recurring Deposit (Predefined number and amount of monthly deposits)

6.1.4.12 Two Way Deposit Scheme [Sweep option].

6.1.4.13 Flexi Fixed Deposit

6.1.4.14 No Minimum Balance charge scheme (SB & Current)

6.1.4.15 ESCROW Accounts

6.1.4.16 Provide facility to stop opening a particular type of account/product type from a

specified date. Existing account to continue unless & until closed or matured

6.1.4.17 DAILY DEPOSIT SCHEME

6.1.4.18 Support defining eligibility criteria for different account / customer type.

6.1.5 6.1.5.1 Provide for capturing details including but not limited to:

6.1.5.1.1 Title of a / c

6.1.5.1.2 Name (First, Middle, Last name) with salutation e.g. Mr. / Ms key in field

6.1.5.1.3 Mother/Father‗s / Spouse‗s Name

6.1.5.1.4 Postal Address

6.1.5.1.5 Telephone No / Fax /

6.1.5.1.5A Mobile No.

6.1.5.1.6 E-Mail

6.1.5.1.7 Date of Birth

6.1.5.1.8 Sex of each a / c holder & PA holder, if any

6.1.5.1.9 PAN No

6.1.5.1.10 Passport No. etc.

6.1.5.1.11 UID (Aadhaar) Card No. /NPR(National Population Registry)

6.1.5.1.12 Details of introducer.

6.1.5.2 In case of illiterate account-holder, particulars of the person explaining the rules.

6.1.5.3 Provide for customer-use of aliases in Internet Banking / Other channels.

6.1.5.4 Provide menu for flagging of accounts of deceased depositors and accounts where

operations have been stopped / restricted under Court-Order / I.T Order etc.

6.1.5.5 In case of substitution, original name should be retained with date of change and

exception report to be generated.

6.1.5.6 Support flagging of matured but unpaid term deposits as overdue and include the

balances as demand deposits in General Ledger.

6.1.5.7 DATE AND AUTHORITY ISSUING ID PROOF

6.1.6 Support capturing particulars of documents attached, including but not limited to:

6.1.6.1 Memorandum and Article of Association

6.1.6.2 Certificate of incorporation and commencement of business

6.1.6.3 Proprietorship letter

6.1.6.4 Partnership Deed / Letter, Trust Deed, HUF declaration, Resolution of Board /

Trust / Clubs / / Association / Society, Order of appointment of Executor or

Administrator

6.1.6.5 Details of A / C with any other bank(s) / or our other branch(es)

6.1.6.6 Power of Attorney

6.1.6.7 Copy of PAN Card, Form 60 / 61

6.1.6.8 Passport, Driving License, Voter Identity Card, Electricity Bill / Telephone Bill /

Defence Identity Card.

6.1.6.9 Undertaking to notify the bank of any change in the partnership/Board of

Directors/Memorandum and Articles of Association etc. Hang down list with yes /

no tick off.

6.1.6.10 DATE AND AUTHORITY ISSUING / REGISTERING DEED ETC.

6.1.7 Provide for capturing mode of operation including but not limited to:

6.1.7.1 For individuals: Singly, severally, jointly, either or survivor, former or

survivor.(JOINTLY OR SURVIVOR / S)

96

6.1.7.2 For other than individuals e.g. companies / Trusts / HUFs / Clubs/Society etc.: Any

one, joint, an authorized operator and any one / more of the rest of the authorized

signatories. Also provide for capture of modification with history. (PANCHAYATS

/ PANCHAYAT SAMITI ETC.)

6.1.8 Capture deposit-scheme specific parameters e.g. minimum / maximum period and

period and amount of deposit, rate / mode of payment of interest, maturity value

etc.

6.1.9 6.1.9.1 Provide for storing for specific number of years old account numbers(from earlier

legacy system) with corresponding new account numbers

6.1.9.2 Support enquiry based on old account numbers

6.1.10 Nominations:

6.1.10.1 Provide facility to specify nomination eligibility based on customer types

6.1.10.2 Provide for the capture of following details including but not limited to:

6.1.10.3 Name of the nominee

6.1.10.4 Address of the nominee

6.1.10.5 Relationship with the account holder

6.1.10.6 Date birth of the nominee (if minor).

6.1.10.7 Date birth of the nominee / age of nominee (ALL CASES)

6.1.10.8 Name of the person authorized to receive money in case of minor nomination

6.1.10.9 Signature of the Nominee

6.1.10.10 Particulars of Witness

6.1.10.11 Nominations to continue on renewal of deposit unless changed an alert should

appear to this effect at the time of renewal

6.1.10.12 Support generation of report for nomination

6.1.10.13 Allow for modifications and cancellations of nominations with authorization.

6.1.10.14 Provide for restricted access to data relating to specific customer.

6.1.11 Provide for minimum amount with which account can be opened:

6.1.11.1 For SB and CA, as given in item 6.4 hereunder.

6.1.11.2 For FDR, RD, etc. Rs. ‖x‖ where x is a parameter.

6.1.12 Support recording of mode of deposit of the initial amount: Cash / Transfer /

clearing.

6.1.13 Support allotment of A / c No., Nomination Registration No., PA holder

Registration No., if any, etc. upon authorization of account opening.

6.1.14 Provide for flagging the account as a ―New A / C‖ for a period of first ―x‖

months, 'x' to be defined as a parameter.

6.1.15 Provide capability to group the various accounts of a corporate / individuals based

on predefined parameters, e.g. common first accountholder for tax deduction at

source.

6.1.16 Support printing of pass book / deposit receipt etc after authorization of initial

credit.

6.1.17 Allow recovery of Rs. ‖x‖ per issuance of Call Deposit Receipt (x to be defined as a

parameter in the system)

6.1.18 6.1.18.1 Cheque Book facility:

6.1.18.2 (Y / N), if YES accept cheque from and to numbers.

6.1.18.3 Support recording details of the cheque series including alphabetical part of the

series and numbers of cheque leaves issued to customer for each account separately.

6.1.18.4 Posting of cheques to be validated. Cheque Number to be within the range of

cheques already issued and not paid.

6.1.18.5 Provide for on-line checking of the amount of each cheque against the actual

balance in the account at the time of data-entry, including during batch entry of

multiple cheques.

6.1.18.6 Provide for rejection / override message in case the cheque amount exceeds the

available balance in the account.

6.1.18.7 Provide for maintenance of chequebook inventory at branch and alert when stock

goes below a predetermined level.

97

6.1.18.8 Support recovery of charges for issuing of cheque books with an exception for staff

accounts

6.1.18.9 Support maintenance of stock of cheque books for all account types

6.1.18.10 Support 'ALPHA' number validation of Cheque

6.1.18.11 Support Expection of charges as defined by user

6.2 Day-to-day operations:

6.2.1 Allow setting of Account Parameter: Account cannot go negative. Necessary alert

must be displayed and the authorized official must approve the debit-transaction.

6.2.2 Allow generation of a unique reference number for each transaction.

6.2.3 6.2.3.1 While posting debit transaction with cheque, the system must verify for the

following but not limited to:

6.2.3.2 STOP PAYMENT instructions

6.2.3.3 Ear Marking flag, if any, on the balance, if there is any

6.2.3.4 Already-paid cheques (same cheque cannot be paid once again).

6.2.4 Provide Alert for special authorization for Credit / Debit posting in a ―New A / C‖

if:

6.2.5 In case of a savings account, while posting debit transactions which could result

account being overdrawn, necessary alert must be displayed by the system and must

be approved by an authorized official. All such cases must be listed in the exception

report.

6.2.6 In all such above cases, interest must be recovered automatically when sufficient

credit balance becomes available in the a / c

6.2.7 Restricted operations:

6.2.7.1 Allow for setting of account parameter including but not limited to:

6.2.7.2 Debits not allowed

6.2.7.3 Credits not allowed

6.2.7.4 Debit / credit not allowed

6.2.7.5 Debit with ceiling

6.2.7.6 Credit with ceiling

6.2.7.7 Provide for Pop-up message displaying the restriction giving reason thereof,

requiring approval by authorized official. Such transactions must be listed in the

exception report

6.2.7.8 Provide for revocation of such restriction under authorization.

6.2.8 Provide facility to post BULK CREDIT entries from the electronic format for e.g.

STAFF / Corporate clients, ECS Credit / Debit etc. A format of ASCII File may be

described in the parameter.

6.2.9 STOP PAYMENT instruction: -

6.2.9.1 Provide for Add / Display / Delete / Print.

6.2.9.2 Provide for rejection of Stop Payment instruction if corresponding cheque number

is already marked as paid.

6.2.9.3 Provide for flagging of the relevant cheque when a Stop Payment instruction is

entered.

6.2.9.4 Provide for recovery of charge @ Rs. ‖x‖ per instruction and printing of debit

advice.

6.2.10 Provide for revocation of Stop Payment instruction under authorisation.

6.2.11 Dishonoured Cheques:

6.2.11.1 Provide for: (also refer 5.4.2)

6.2.11.2 1. Tracking dishonoured cheques in any account

6.2.12 6.2.12.1 Provide for:

6.2.12.2 Tracking number of withdrawals per half-year in a SB account.

6.2.12.3 Recovery of charge @ Rs. ‖x‖ per additional withdrawal over permissible number

―n‖ per half-year. x & n are parameters (x is to be specified as part of service

charge module).

98

6.2.12.4 3. Printing of debit advice.

6.2.13 Provide for:

6.2.13.1 Tracking number of withdrawals per half-year in a SB account.

6.2.13.2 Recovery of charge @ Rs 'x' per additional withdrawal

6.2.13.3 Printing of debit advice.

6.2.14 Provide for:

6.2.14.1 Tracking balance falling below the minimum balance

6.2.14.2 Recovery of charge @ Rs.‖x‖ per such occasion. X to be definable as a parameter

6.2.14.3 Capability to charge@ Rs 'w' per day between the two specific days. W to be

definable as a parameter

6.2.15 For SB inoperative a/c if incidental charge/service charge less than minimum

balance, issue notice to depositor

6.2.16 For CA inoperative a/c if incidental charge/service charge less than minimum

balance, issue notice to depositor

6.2.17 For SB and CA accounts, allow marking the account as ‗Inoperative‘ if not operated

upon (no customer initiated ‗debit‘ or ‗credit‘) for ‗x‘ period. Any subsequent debit

/ credit in such account will require authorization.

6.2.18 6.2.18.1 Provide facility for issuing duplicate Statement / Passbook etc. by authorized

official with recovery of charge @ Rs.‖x‖ per occasion, ―x‖ determined on the basis

of number of past entries required by the customer.

6.2.18.2 Provide for override of the recovery of charge under authorization to be captured in

exception report.

6.2.19 Support for enquiry of transactions based on amount (less than, in, more than a

range), customer ID, type of account, Account Number, transaction type, cheque

no., date etc.

6.2.20 Support maintenance of notional balances in certain types of accounts such as

P.P.F.

6.2.21 Support parameterisation of permissible credits for product-types e.g., the variable

monthly instalment to be deposited by the customer should not exceed Rs.‖x‖.

Provide for pop-up message and authorization for exception.

6.2.22 Support flagging of Recurring Deposit (RD) accounts where monthly installment is

not received in any month.

6.2.22.1 Display number of arrear installment

6.2.22.2 Calculate and display applicable penalty as applicable;

6.2.22.3 Provide for generation of notices to be sent to customers in case of over due

instalments for more than parameterized period

6.2.22.4 Provide for conversion of full or part of one type of deposit into another with

facility of waiver of penal interest on premature payment of a term deposit

converted into another term deposit.

6.2.23 Provide for applying concessions in charges to specific account / group of accounts.

6.3 Standing Instructions:

6.3.1 Periodical Standing Instructions to be executed at the time of DAY BEGIN / Mid

day / End of day, with provision to execute during working hours also at higher

authorization level.

6.3.2 Provide flexibility for setting up and processing any type of standing instructions as

and when required with different parameters including but not limited to:

6.3.3 Fixed Amount Fixed Period / Variable amount / Variable amount with limit /

Variable frequency / Event driven / Maintenance of balance (eg. keeping a balance

of Rs.5,000 / -, remaining amount to be transferred to another account) .

6.3.4 6.3.4.1 Provide for generation of Report on:

6.3.4.2 Standing Instructions executed, and

6.3.5 Standing Instructions failed in execution.

6.3.6 Provide a facility to allow carry forward of the standing instructions, for some user-

definable period, till the condition for processing the standing instruction is met or

number of attempts made (should be flagged off as exceptions).

6.3.7 Provide for recovery of charge Rs.‖x‖ per failed attempt.

99

6.3.8 Provide capability to automatically cancel the standing instruction for the current

cycle if it has been carried forward for more than the predefined number of attempts

(to be defined as a parameter) with generation of a report for advising the customer.

6.3.9 Provide facility to add / modify / delete / display / print a standing instruction.

6.3.10 Allow for sweep option to transfer amounts from SB / CA accounts when the

balance exceeds the Limit set and create Fixed Deposits with such amounts and

credit back to relative SB / CA account, on FIFO or LIFO basis, one or more of

such Fixed Deposits executing premature payment whenever required(sweep

facility).

6.4 Minimum Balance requirements:

6.4.1 Allow defining of minimum balance based on the following but not limited to:

6.4.1.1 Customer type e.g. Staff, Pensioner, Individual, Firms and Companies etc.

6.4.1.2 Account type e.g. SB, CA.

6.4.1.3 Cheque facility available (SB account)

6.4.1.4 Cheque facility not available (SB account)

6.4.1.5 ATM Facility available

6.4.1.6 Sweep facility available (please refer to item 6.3.10 above)

6.4.1.7 Population category of the branch like Metropolitan, Urban, Semi-Urban and Rural

, and / or location such as District Head Quarter, State Capital, etc

6.4.2 Allow defining of minimum balance to be maintained on each type of account, on a

daily, monthly, quarterly, half-yearly, yearly basis

6.4.3 Allow defining of minimum average balance to be maintained on each type of

account, on a daily, monthly, quarterly, half-yearly, yearly basis

6.4.4 Enable system to levy charges in case of default on instance-basis / period-basis.

6.4.5 Minimum Balance Charges must be levied before END OF DAY is executed. If the

balance in the account is not sufficient to charge Minimum Balance charges, a

record must be kept and charges are to be recovered automatically whenever

sufficient balance becomes available in the account.

6.5 Payment of Interest on SB &CA:

6.5.1 Savings Bank Account:

6.5.2 Interest is to be accrued at user-defined interval and applied to all savings accounts

on

the monthly products, based on the minimum clear balance between two specified

dates of each month, on or before interest application date that may be defined on

the

system and at the rate given in the interest table.

6.5.3 Rate of interest for different types of customers should be parameterized.

6.5.4 Provide for capability to accrue interest on SB account but not applying.

6.5.5 Provide for interest to be calculated up to the last completed month and credited to

particular SB account at the time of its closure.

6.5.6 Current Account:

6.5.7 Provide for payment of interest at parameterized rate on Sole Proprietorship

account at the time of settlement of deceased-claim.

6.6 Payment of Interest on Term Deposits:

6.6.1 Allow for creation / maintenance of various modes of interest payment on Term

Deposits including but not restricted to:

6.6.2 Fixed Deposit where interest is paid out to the depositor at monthly (discounted)

/Quarterly / other predetermined interval by cash / P.O / credit to designated

account (liquidation type).

6.6.3 Cash Certificate Deposits where interest is compounded at quarterly intervals and

credited to Cash Certificate Deposit A / C at the end of the financial year / pre-set

interval.

6.6.4 RD interest on the basis of monthly product

6.6.5 Provide for executing Tax Deduction at Source at the time of interest payment or

accrual at predetermined intervals (including quarterly) and as per parameters

required

for calculation of applicable tax, with facility for clubbing all taxable interest

income of a particular customer.

6.6.6 Provide for facility to capture and apply / revoke tax exemptions either on the basis

100

of depositor‗s declaration or by virtue of exemption as a customer-type.

6.6.7 Support remittance of amount of TDS within user-defined period and generation of

interest and TDS certificate at predefined periods.

6.6.8 Support generation of yearly ticklers to the customer within a user defined period

say for TDS declaration.

6.6.9 Others type of Term Deposit

6.6.10 Support maintenance of:

6.6.10.1 Cash Certificate Deposits Interest Accrual Account for holding CC quarterly

accruals.

6.6.10.2 Interest Paid Cash Certificate Deposits Account for making payments of interest on

Cash Certificate Deposits for current quarter.

6.6.10.3 Interest Accrued and Payable-Non- Cash Certificate Deposits for holding quarterly

accruals in respect of other term deposits. The balance to be credited to Interest

Paid-Non Cash Certificate Deposits on the first working day of the new quarter.

6.6.10.4 Interest Paid-Non- Cash Certificate Deposits for making payments of interest on

Non-CC Term Deposits for current quarter.

6.6.10.5 In case of premature payment provide for reversal of recoverable interest from Cash

Certificate Deposits account to Cash Certificate Deposits interest account.

6.6.11 System to support parameterized interest payments for different types of accounts

in

respect of period and rate of interest and recovery of excess interest already paid in

case the deposit does not run for a minimum period. System to support accrual of

interest with or without application at parameterized intervals on authorization.

6.6.12 Support parameterised payment of interest in case of deceased account

6.6.13 Support mode of payment of interest like cash / electronic clearing / transfer / other

remittance mode etc.

6.6.14 Support crediting of interest to loan account in case of lien marking on deposit

account to loan account and interest is liquidated periodically

6.7 Loan against deposit:

6.7.1 Support marking of lien on deposits (including Cash Certificate Deposits) against

which loan / overdraft have been sanctioned and then only the loan can be

disbursed.

6.7.2 Denial of closure of such deposit accounts by the system if corresponding loan is

not fully adjusted. PROVISON FOR AUTOMATIC CLOSURE OF LOAN

AGAINST DEPOIST ACCOUNT/S ON MATURITY PAYMENT OF FIXED

DEPOSIT ACCOUNT

6.7.3 Support tagging of interest and principal in loan account to such deposit account

with alert if the former exceeds y% of the interest and principal amount of deposit

6.7.4 Support automatic lifting of lien when loan / overdraft is adjusted

6.7.5 Auto Linking of renewed interest, lien to be marked accordingly and administer the

effective rate accordingly

6.7.6 Support opening of a single loan account against many deposits

6.8 Closure of account: Provide facilities including but not restricted to:

6.8.1 Provide for validation with respect to lien / earmarking, pending debit / credit,

recovery of any outstanding charges, instructions like no operation / no withdrawal,

unused cheques, stop payment instructions, instruments out standing in clearing,

outward bills for collection and bills purchased, standing instructions, instruction

for

credit of interest and / or principal of term deposit, outstanding ATM / Debit /

Credit Card or any other restriction to closure

6.8.2 VALIDATION FOR LOST POSTAL RECIEPTS(NSC/KVP) & DEMAND

DRAFTS

6.8.2 Bank initiated closure will need validation in terms of prior notice

6.8.3 Support payment of proceeds by Pay Order / credit to designated account /

conversion

fully or partly to a fresh Term Deposit / Demand Draft etc. Payment by cash

restricted to parameterized amount at product-level.

6.8.4 Closed accounts should be allowed only for enquiry and not for transactions.

6.8.5 Closure of SB and CA: (in addition to 6.8.1 to 6.8.4)

Unused cheque must be surrender or deleted before closure of any account in CA &

SB

101

6.8.6 Recover charge of Rs.‖x‖ if SB / CA account closed within y months from date of

opening (other than due to death of the depositor). Where y is a parameter.

6.8.7 Closure / renewal of Term Deposits:

6.8.8 Provide facility for renewal of full or part of the proceeds e.g. Principal and interest,

Principal, interest and overdue interest, Principal only, Interest only (i.e without

addition of amount), of matured Fixed Deposit for further period, including

retrospective renewal from date of maturity for overdue Fixed Deposit.

6.8.9 Support parameterisation of rate of interest applicable to overdue period of a Fixed

deposit on prospective renewal after ―x‖ days from maturity-date.

6.8.10 Support parameterisation of rate of interest applicable to overdue period of a Fixed

deposit on settlement of deceased account

6.8.11 In case of premature closure interest rate for run-period of the deposit is to be

selected from the interest table effective on date of opening and x% penalty to be

charged, 'x' to be set as a parameter.

6.8.12 Premature only from the date of extension

6.8.13 Account to be termed as closed only when balance is zero and there is nothing

further left to process either in the account in question.

7. Non Agriculture Loan (Direct Lending)

7.1 General Requirements

7.1.1 Provide capability to segregate advances into various types like but not limited to

7.1.1.1 Overdraft

7.1.1.2 Cash Credit

7.1.1.3 Clean Advances

7.1.1.4 Term loans

7.1.1.5 Working capital loans

7.1.1.6 Hire Purchase

7.1.1.7 Bills Purchased (a) Inland (b) Foreign

7.1.1.8 Advance Bills Purchased Account ( Bills under devolved LCs )

7.1.1.9 Letter of Credit

7.1.1.10 Bank Guarantee

7.1.1.11 Deferred Payment Guarantee

7.1.1.12 Discounting of Bills under LC (Inland)

7.1.1.13 Advances to Infrastructure Projects (Eligible for tax exceptions under Section

10(23) G of IT Act

7.1.2 Provide capability to segregate advances into:

7.1.2.1 ‗Standard‘ - with provision for age wise sub classification

7.1.2.2 ‗Sub-standard‘ -- with provision for age wise sub classification

7.1.2.3 ‗Doubtful‘ -- with provision for age wise sub classification

7.1.2.4 ‗Loss‘

7.1.2.5 PROVIDE TRIGGER FOR SPECIAL WATCH ACCOUNTS(PROBABLE NPA

A/Cs OR OVERDUE A/Cs FOR USER DEFINED PERIOD

7.1.3 Provide capability to segregate advances into various Schemes / Categories like but

not limited to the following with a facility to add each product to the corresponding

BSR code

7.1.3.1 Small Scale Industries

7.1.3.2 Retail Trade and Small Business

7.1.3.3 Composite Loan (Bank credit for Artisans Village & Cottage industries)

7.1.3.4 Loans to Professional & Self-employed

7.1.3.5 Direct Loan to Small Road & Water Transport Operators

7.1.3.6 DRI Scheme

7.1.3.7 Loans to Farmers & Agriculturists (all schemes)

7.1.3.8 Kisan Credit Card (PROVIDE FOR CAPTURING OF INFORMATION ON

FRESH KCC AND IN ADWDR ACCOUNTS)

7.1.3.9 State / Central Sponsored Schemes (SGSY REVOLVING FUND & SGSY

PROJECT FINANCE) POP SCHEME FRONT END SUBSIDY SCHEME FOR

SC

7.1.3.10 Education

7.1.3.11 Rural Housing

7.1.3.12 Consumption Loans

7.1.3.13 Self-help Groups

102

7.1.3.14 National Equity Fund scheme

7.1.3.15 SRMS

7.1.3.16 KVIC

7.1.3.17 SLRS

7.1.3.18 General Credit Card, Swarojgar credit card, LUCC

7.1.3.19 Wind Mill

7.1.3.20 Solar Power

7.1.3.21 Others, if any

7.1.3.22 Personal Loan

7.1.3.23 Vehicle Loan

7.1.3.24 Demand Loan (Staff)

7.1.3.25 Demand Loan (Others)

7.1.3.26 Salary linked personal loan

7.1.3.27 Gold Loan

7.1.3.28 Mahila Shakti

7.1.3.29 Mortgage Scheme

7.1.3.30 Rain Water Harvesting

7.1.3.31 Joint Liability Group Loan

7.1.3.32 On-farm Water Management/ MSTP (Million Shallow Tube-well Programme)

7.1.3.33 Land Development Scheme

7.1.3.34 Agri Clinic & Agri Business

7.1.3.35 Dairy / Poultry Venture Capital Scheme

7.1.3.36 Commercial Horticulture(Agro Export)

7.1.3.37 Pensioner Loan

7.1.3.38 Dairy / Poultry / Piggery / Fishery / Goatery / Duckery /Shipery

7.1.3.39 Rural Godown

7.1.3.40 PMEGP

7.1.3.41 Loan Against Banks Deposit / NSC / KVP / LIC Shares / Other Banks Deposit

7.1.3.42 Functional Requirements of Core Banking Solution

7.1.3.43 Car Loan

7.1.3.44 Loan Against Flexi RD- (age wise credit limit e.g. Big Samridhi Loan Scheme)

7.1.3.45 Cash Loan

7.1.3.46 Staff Loans (not limited to) House Loan, Additional House Loan, Overdraft

Scheme, Vehicle Loan, Festival Loan, Consumer Loan

7.1.3.47 Bee Keeping

7.1.3.48 Fish Farmer Development Agency

7.1.3.49 Integrated Tribal Development Program

7.1.3.50 Tribal Sub Plan

7.1.3.51 RSBY(Rastriya Shrambikas Yojna)

7.1.3.52 BSKP(Bangla Swanirbhar Karmosansthan Prakalpo)

7.1.3.53 SSEP

7.1.3.54 Real Estate Loan

7.1.3.55 Debt Swap Scheme

7.1.3.56 Gramin Tatkal Yojna

7.1.3.57 Anytime Money For Salaried Persons/ Comm. Agents

7.1.3.58 Biogas

7.1.4 Provide capability for configuring templates for lending products with, but not

limited to, following Parameters:

7.1.4.1 Name of the lending product

7.1.4.2 Target Group for the lending product

7.1.4.3 Eligibility criteria for the product

7.1.4.4 Quantum of loan -

7.1.4.4.1 Minimum

7.1.4.4.2 Maximum

7.1.4.5 Rate of interest -

7.1.4.5.1 Minimum

7.1.4.5.2 Maximum

7.1.4.6 Method of charging interest - simple / periodic compounding (With option not to

charge / to charge interest during moratorium)

103

7.1.4.7 Security - Primary and Collateral (Provision for modification for security subject to

authorisation.)

7.1.4.7.1 Owner of the collateral

7.1.4.7.2 If owner of collateral is a third party , then there should be a mandatory field for his

guarantee, (IN CASE OF FDR AS COLLATERAL SECURITY, THE

GUARANTEE SHOULD BE LIMITED TO THE EXTENT OF PRINCIPAL AND

INTEREST OF FDR)

7.1.4.8 Repayment Schedule with options to show daily, monthly, quarterly, half yearly,

annual etc. with or without moratorium - Suitable option for running accounts and

loan accounts

7.1.4.9 Pre-payment Charges

7.1.4.10 Commitment charges

7.1.4.11 Insurance requirements with provision indicating different clauses and extent of

coverage with reference to value of goods

7.1.4.12 Processing Charges / Up-front fees

7.1.4.13 PREPAYMENT INCENTIVE (e.g. EDUCATION LOAN ETC.)

7.1.4.14 PROVIDE FOR MARGIN SENSITIVE INTEREST RATES

7.1.5 Support creating composite loan products using the generic loan products / facilities

under each of the lending classifications at item number 7.1.1

7.1.6 Support definition of main-limit, outer-limit , inner-limit, interchangeable limit,

earmarking for other facilities, month-wise operating limit for seasonal activities (

e.g. Tea, sugar etc.) etc.

7.1.7 Support maintenance of more than one limit per customer for a type of facility

7.1.8 Support maintenance of main limit in one product with sub-limits / inner-limits in

other loan products / in other branches

7.1.9 Allow creating of notes, which have to be attached to the loan details. These could

be in the form of but not limited to:

7.1.9.1 Additional text fields in the loans

7.1.9.2 Separate form attached to the original detailed form

7.1.9.3 Separate note linked to the loan details form and security documents

7.1.10 Support for marking lien on deposits within the branch or with another branch,

offered as security for any loan with option to generate report / certificate of lien

7.1.11 Support marking lien on limit / drawing power of loan accounts (for issuing

Commercial Paper, Letters of Comfort, Letters of Credit, Bank Guarantees, Short

Term Loan etc.)

7.1.12 Support auto reduction of limit to the extent of excess drawals in other specified

loan account(s) selected i.e. defining the overall group exposure

7.1.13 Support seeking on-line confirmation for lifting of lien, on closure of loan account

7.1.14 Support reflection of liens details for a Loan account, marked against any deposit /

liability Products

7.1.15 Support reflection of liens marked on a loan limit

7.1.16 Allow and support different due dates for principal interest and other charge types

with both structured or irregular periodicity

7.1.17 Provide for transfer of loan accounts from one branch (location) to another. This

should not be treated as pre-mature closure of account with option to transfer such

accounts within core banking branches and other branches and necessary inter-

branch transfers

7.1.18 Provide for validation of the time / demand deposit in case it is offered in lien for

the loan.

7.1.19 Support loan application where the collateral is held with another branch / bank

7.1.20 Support selecting mode of sending notices to borrowers / guarantors both

individually for each type of notice and collectively for borrower and group of

borrowers / guarantors (BILINGUAL)

7.1.21 Support blocking either credits or debits or both in any account with reasons and

reports along with option for generating notice advising the account holder

7.1.22 Provision to maintain records of securities for loans against shares with options for

temporary in / out :

7.1.22.1 Physical

7.1.22.2 Demat

7.1.22.3 With option for validating acceptability of shares against set of predetermined list

104

of shares and option.

7.1.23 Provision to maintain loans against own bank deposits and / or Government

certificates / bonds (LIC policy)

7.1.24 Provision to generate reports of Shares company wise, category wise, with number

and face value, market Value with annual high and low

7.1.25 Provision to update share value with provision for interface with external source

7.1.25.1 Offline

7.1.25.2 Online

7.1.25A Provide for surrender value of LIC

7.1.26 Provision to calculate drawing power as per the definition and generation of advice

letters to party in case of excess / overdrawing for regularisation

7.2 Limit Monitoring

7.2.1 Support capture of records based on the following parameters and validate the

exposure limit , but not limited to:

7.2.1.1 Customer

7.2.1.2 Customer Groups

7.2.1.3 Sanction / application reference

7.2.1.4 Scheme wise

7.2.1.5 Industry wise

7.2.1.6 Sanctioning authority

7.2.1.7 Facility / Product

7.2.1.8 Limit wise (amount)

7.2.1.9 PROVIDE FOR CAPTURING DETAIL OF REFERENCE PERSON

7.2.2 Limit maintenance Support capture of following information

7.2.2.1 Name & address of borrower

7.2.2.2 Nature of activity

7.2.2.3 Category of borrower (Priority / Non- Priority / Export / Special Schemes, etc.)

7.2.2.4 Restructured account (CDR or otherwise), accounts under compromise, sick unit

etc.

7.2.2.5 Date of sanction / Renewal / Review

7.2.2.6 Due date for Limit Renewal

7.2.2.7 Age in Number of days from date of renewal and review

7.2.2.8 Sanctioning Authority with validation for sanctioning powers as per delegated

Authority

7.2.2.9 Nature of limits(Division wise limit If any)

7.2.2.10 Limit with progressive reductions

7.2.2.11 Sub Limits for charging differential rate of interest

7.2.2.12 Amount of limit (Peak and Non-Peak Level)

7.2.2.13 RATING OF THE BORROWER

7.2.3 Support setting up limits in stages for a Customer account i.e., support setting of

limits for each product / facility separately

7.2.4 Provision to override the exceptions for partial disbursements up to a particular

amount / nos. of transactions only with proper authorisation.

7.2.5 Provision to maintain partial / full disbursements

7.2.6 Provide capability to set overdraft limits for the current accounts

7.2.7 Enable setting of limits and exposures for loans to be sanctioned to a Customer /

Group

7.2.8 Support usage of a single overall limit by all disbursement products (WITH LEVEL

/ BREAK-UP OF DISBURSEMENT)

7.2.9 Allow for setting up of lines / provisional limit in case the customer has used up the

limit defined.

7.2.10 Provide capability to automatically reduce the overdraft limit based on a predefined

Frequency

7.2.11 Support design (template) to check compliance, of related terms and conditions of

Sanction

7.2.12 Support modification of check List to make account specific modification

requirements of terms of sanction

7.2.13 Support capture of data in stages, for details of compliance for each application /

sanction reference

7.2.14 Support capturing details of Registration of charge with Registrar of Companies,

105

Registrar of assurances , Depository etc. for each limit separately with provision for

recording the modifications there to with maintenance of the history

7.2.15 Support tracking and give alerts for primary securities and collaterals pending

registration of charge with ROC Registrar of assurances etc, at pre-defined

frequencies

7.2.16 Support for flagging of limit for non-Compliance of terms and conditions

7.2.17 Support definition of mandatory compliance (in the standard list of compliance) for

lifting the flag, to make the limit operational

7.2.18 Support capturing dates of execution of each document stipulated in the Sanction

7.2.19 Support seeking on-line confirmation(s) for making a limit operational / for

overdrawing etc.

7.2.20 Ensure that no limit is set up unless sanction details are recorded

7.2.21 Capability to ensure that there is no duplication in the limit set up for any

Sanctioned Limit

7.2.22 Support obtaining of special approval for sanctioning of advance, where the

advance is linked to the line of credit and not the limit itself

7.2.23 Enable conversion of the line into limit in case payment of any other advance

releases the limit with approval of the delegated authority

7.2.24 In the case of a change of constitution of the customer, support linking accounts to

the new customer profile with past history

7.2.25 Support alerts / messages in case the collateral amount goes below the pre

determines level, where the limit is linked to the collateral

7.2.26 Allow for setting up of limits as a percentage of the collateral held.

7.2.28 Support updating of the limits on enhancement, reductions or ad-hoc sanctions and

maintain history of changes

7.2.29 Ability to update the sanction details for completion of the legal formalities and

execution of documents , registration of charges etc

7.3 Collateral management

7.3.1 Support capturing history of creation / addition / modification in the collateral

security.

7.3.2 Support blocking / freeze (manual) and de-freeze link to relevant authority.

7.3.3 Provide for maintaining value of Collateral security with relevant date and history

of valuations

7.3.4 Support tracking of date of valuation of Collateral, vis-à-vis predefined validity

periods and prompt the user to update valuations. User to be able to define validity

period for each category of Collateral

7.3.5 Provide a reminder facility, based on a predefined frequency, for revaluation of

collateral

7.3.6 Provide alerts where the collateral value drops below the predefined limit

7.3.7 Support interface with deposits module for recording liens on deposits

7.3.8 Provide a facility to monitor collateral where the collateral(mainly time / demand

deposits) is held with another Branch

7.3.9 Support seeking on-line confirmation for de-linking of time / demand deposit to the

loan limit, in case the loan is paid up

7.3.10 Support seeking on-line confirmation for lifting lien in case the relative Letters of

Credit, Bank Guarantee is retired

7.3.11 Allow for management of collateral even in case the loan is paid up

7.3.12 Allow for linking of

7.3.12.1 Single loan to multiple collateral

7.3.12.2 Multiple loans to single collateral

7.3.12.3 Single collateral to multiple Customers

7.3.13 Support validation of the collateral against the existing database, to find if it is

being currently used for any other loan / advance

7.3.14 Allow for capturing the following, but not limited to

7.3.14.1 Insurance details

7.3.14.2 Legal / Solicitor details

7.3.14.3 Valuation details (external consultant etc)

7.3.14.4 Details of loans for which the security is held as collateral

7.3.15 7.3.15.1 Provision to maintain details of suit filed details borrower / account wise

Advocate details

106

7.3.15.2 Suit Number

7.3.15.3 Date of filing

7.3.15.4 Date of hearing

7.3.15.5 Amount of suit

7.3.15.6 Accounts under the suit

7.3.15.7 Court(s)

7.3.15.8 Nature of suit( money / mortgage etc)

7.3.15.9 Charges paid

7.3.15.10 Stages of suit

7.3.15.11 Date of decree

7.3.15.12 Date of:

7.3.15.12.1 Preliminary decree

7.3.15.12.2 Final decree

7.3.15.13 Date of execution of decree

7.3.15.14 Details of appeals if any

7.3.15.15 Notice issued under securitization act.

7.3.15.16 Status of action under securitization act

7.3.16 Facility to automatically restrict operation on the collateral with provision to over-

ride by authorized users

7.3.17 Provide for closing / marking the Collateral in case the collateral is disposed off in

the market

7.3.18 Maintenance of Primary and collateral securities separately should include

7.3.18.1 Recording of value

7.3.18.2 Recording of revaluation

7.3.18.3 Acknowledgement of securities

7.3.18.4 Addition / or release of securities

7.3.18.5 Registered mortgage or equitable mortgage

7.3.18.6 If registered mortgage, amount and date of registration

7.3.18.6.1 Description of security

7.3.18.6.2 Legal opinion date

7.3.18.6.3 Search Report

7.3.18.6.4 Valuation Report

7.3.18.6.5 Name of valuer

7.4 Disbursals

7.4.1 Enable a phased draw-down schedule for the disbursal of the loan amount

7.4.2 Support checking of balance and drawing power and ability to display record of

past disbursement before the disbursal of the loan

7.4.3 Ability to check authority limit of disbursing officer / approving authority

7.4.4 Ability to check company / industry exposure prior to disbursement

7.4.5 Ability to generate disbursement memo with disbursement request and overall

exposure details

7.4.6 Provision to track disbursement, full / partial. Provision for blocking further debits

except interest, after completion of final disbursements.

7.4.7 Ability to modify disbursement Schedule during the tenure of a facility

7.4.8 Ability to keep track of future disbursement schedule

7.4.10 Support cheque operated loan accounts (cash credit accounts on lines of current

account)

7.4.11 Provision to remit / draw disbursements related to scheme parameters through DD

/PO / Cash / Cheques etc.

7.4.12 Provision to enter the proof of end use of funds like

7.4.12.3 Bills / Money Receipts

7.4.12.4 RC book etc

7.4.13 Support Bulk credits / Recoveries in retail loans e.g. (salary Etc.)

7.5 Fee based disbursals

7.5.1 Ability to account for fee based income with characteristics similar to interest rates

7.5.2 Ability to handle transactions with only Fee based income

7.6 Prepayment / closure of Loans

7.6.1 Allow pre-payment of loans on user-defined rules / charges model

7.6.2 Support checks to ensure non-closure of Loans till all outstanding and interest

accrued against it has been repaid

107

7.6.3 Ensure release of lien in case of prepayments

7.6.4 Provision to generate pre-defined lists before closure of accounts to check for:

7.6.4.1 Charges to be recovered

7.6.4.2 Interest to be recovered

7.6.4.3 Interest in dummy ledger

7.6.4.4 Cheque books to be surrendered

7.6.4.5 ATM / credit card / debit card or any other card transactions

7.6.4.6 Cheques deposited - but not cleared

7.6.4.7 Lien on deposits

7.6.4.8 Subsidy details

7.6.4.9 Margin details

7.6.4.10 List of securities

7.6.4.11 Operations in related accounts

7.6.5 Provision for authorization of account Closure After all the exceptions / cautions

are attended.

7.6.6 On authorization of account closure the related security documents have to be

marked accordingly.

7.7 Drawing Power

7.7.1 Support automatic(rule based) / manual setting up of ‗drawing powers‗ and

restricting disbursals / drawings based on the same

7.7.2 Allow defining rules for calculating drawing power based on

7.7.2.1 Security(percentage / absolute value)

7.7.2.2 Installments not yet due

7.7.3 Support limiting drawing in a loan account to drawing power (like a running

account)

7.7.4 Support allowing drawings in excess of ―Drawing Power‖ with on-line approval of

authorized users with exception reporting

7.7.5 System to prompt for period of validity each time drawing power is updated with

default date as system date while updating.

7.7.6 Support selecting method / methods of Computation of ―drawing power‖ for each

limit set up on the system

7.7.7 Support selecting items of security for calculation of drawing power.

7.7.8 System should enable capture of margins, caps (sub-limits), periodicity of

valuation, etc. specified for securities

7.7.9 System to maintain these values for period specified by the user(minimum of

12months)

7.7.10 Support tracking of periodicity of valuation vis-à-vis the stipulated periodicity

7.7.11 Support design of standard templates for capturing details like

7.7.11.1 Date of valuation(date of stock statement),

7.7.11.2 Value of each item of security(market value)

7.7.11.3 Drawing power available

7.7.11.4 for Cash Credit / Working Capital Demand Loan

7.7.11.5 For Deposit receipts system should arrive DP after reducing margin on present

value of deposit. Lien should be marked on the deposits

7.7.11.6 For all other securities like NSC, Shares etc. security type, value of Security,

margin and description should be accepted and DP arrived accordingly by the

system

7.8 Monitoring of loans

7.8.1 Ability to record tracking of key events / milestones during the project analysis

Stage like financial closure, implementation, implementation status, clearance

(statutory and others) etc.

7.8.2 Facilitate identifying / monitoring defaulting loans based on

7.8.2.1 Interest default

7.8.2.2 Principal default

7.8.2.3 Charges / fees default

7.8.3 Ability to generate standard notice / Legal notice / suit / plaint documents / letters

of invocation of guarantee etc.

7.9 Re-payments

108

7.9.1 Provision unique repayment schedule for each of the disbursements

7.9.2 Support fixing repayment schedule for a Limit. The methods of Repayment could

be:

7.9.2.1 Periodical (monthly, quarterly, half-yearly, Yearly, seasonal (harvest) etc.)

7.9.2.2 Irregular and progressive

7.9.2.3 On demand

7.9.2.4 With or without initial moratorium

7.9.2.5 Separate repayment schedules for Interest and principal

7.9.2.6 Equated instalments, with or without Moratorium

7.9.2.7 Equated monthly instalments (EMI)

7.9.2.8 Equal or un-equal instalments Provide for accepting repayments by:

7.9.3 Provide for accepting repayments by:

7.9.3.1 Cheque / ECS

7.9.3.2 Post-dated cheque (with due date maintenance for presentation)

7.9.3.3 Transfer from other account

7.9.3.4 Cash

7.9.3.5 Automatic debiting of any other account

7.9.4 Support ‗clearing‘ repayments against loan Amount

7.10 Insurance Details

7.10.1 Support capturing insurance details for each item of primary security as also each

interim Collateral security (for which insurance cover is stipulated in the sanction).

7.10.1.1 The details should include: Insurance company

7.10.1.2 Policy date

7.10.1.3 Policy number

7.10.1.4 Asset covered

7.10.1.5 Risks covered

7.10.1.6 Insurance cover

7.10.1.7 Premium

7.10.1.8 Beneficiary

7.10.1.9 Due date for renewal

7.10.2 Provision to note Insurance cover / guarantee cover -

7.11 Inspection

7.11.1 Support capturing dates of inspection customer-wise for both primary and collateral

7.11.2 Support inputting of remarks / report of Inspecting officials / agencies (memo

field).

7.11.3 Provision to enter / upload remarks and Replies of audits like external, statutory,

Concurrent, RBI, External

7.11.4 Support capturing names of the officials / Agencies who conducted the inspections

7.11.5 Provide for tracking the periodicity of Inspections with the periodicity of

inspections specified in the Sanction Customer-wise for both primary and Collateral

security

7.11.6 Recording of inspection of assets

7.11.6.1 Post sanction

7.11.7 Generation of letters / reports to Customers / higher authorities about the

Inspections of assets

7.11.7.1 Date of last inspection

7.11.7.2 Inspection Schedule

7.12 Asset Classification and Provisioning

Support definition of norms for asset Classification and income recognition

differently for each sector with provision to deal with restructured accounts as per

terms of:

7.12.1 Restructure

7.12.2 Support auto classification of all loans into performing (including special watch

accounts) and non-performing assets, based on user defined criteria

7.12.3 Support manual over-ride facility for asset classification by authorized users with

exception report

7.12.4 Ability to identify and categorize assets into various categories such as standard,

sub-Standard, doubtful and loss assets based on Multiple criteria

7.12.5 Ability to trigger when there is a possibility of one or more criteria being met

7.12.6 Store date on which the asset classification Changes from performing asset to non-

109

Performing asset

7.12.7 Support automatic change of asset status (standard, sub-standard, etc.) based on

user defined criteria after obtaining on screen confirmation from user

7.12.8 Provision to classify accounts as per Income recognition norms with calculation of

interest and charges to be reversed and account accordingly with report generation

7.12.8.1 Automatic upgrading

7.12.8.2 Automatic downgrading

7.12.8.3 Support separate calculation of interest Accruals for non-performing assets (NPAs)

on an on-going basis

7.12.9 Provision to maintain dummy account Ledger for NPA accounts / written off

accounts. (A dummy ledger is one where notional entries are made without

affecting any of the accounting heads)

7.12.10 Provision to accrue interest on dummy ledger accounts / written off accounts (off-

balance sheet item) without applying the same.

7.12.11 Provision to close dummy ledger on automatic upgrading of advance account.

7.12.12 Support compounding of interest at the user specified frequency for NPAs while

computing Interest accrued

7.12.13 Support maintenance of income Suspense / interest not collected account

7.12.14 Provision to maintain details of suit filed details borrower / account wise

7.12.14.1 Advocate details

7.12.14.2 Suit Number

7.12.14.3 Date of filing

7.12.14.4 Date of hearing (ALL DATES)

7.12.14.5 Amount of suit

7.12.14.6 Accounts under the suit

7.12.14.7 Court(s)

7.12.14.8 Nature of suit( money / mortgage etc)

7.12.14.9 Charges paid

7.12.14.10 Stages of suit

7.12.14.11 Date of decree

7.12.14.12 Date of a. Preliminary decree b. final decree

7.12.14.13 Date of execution of decree

7.12.14.14 Details of appeals if any

7.12.15 Automatically calculate write-off / write back amount outstanding in specified NPA

accounts based on user defined criteria

7.12.16 Automatically calculate specific provisions based on user defined criteria and

formulae

7.12.17 Support creation of interest provisions and Receivables, based on accrued interest

calculated

7.12.18 Support maintenance of provision / receivable accounts separately for each account

type separately

7.12.19 Support application of interest by debit / credit to Provisions / receivable accounts

7.12.20 Support user defining calendar for reversal of outstanding in provision / receivable

accounts

7.12.21 Provision to reversal of interest out of Recoveries, in the dummy ledger

7.12.22 The asset classification data should be available for future reference

7.12.23 Provision to maintain income recognition norms for asset classification

7.12.23.1 Product wise

7.12.23.2 Scheme wise

7.12.23.3 INTERST RATE WISE

7.12.24 Provision to appropriate recoveries to

7.12.24.1 Principal

7.12.24.2 Interest

7.12.24.3 Charges

7.12.25 Provision to record receipt of guarantee claims like ECGC / CGFSI and

proportionate refund from recoveries / claim accounts.

7.12.26

7.12.26.1 Provision to generate reports of asset Classification for any given date / back date

7.12.26.3 Generate NPA-1 and RBI 5, 6 7 report as per enclosed format

7.12.27 Generate potential NPA (special watch) statements as per pre defined norms /

110

formats

7.12.28 Provision to calculate un-recovered interest on newly identified NPA accounts.

7.12.29 Provision to define accounting entries for un-recovered interest amounts

7.12.30 Provision to generate report / query of NPA a/c as per asset classification

7.12.30.1 Branch wise / size wise

7.12.30.2 Scheme wise

7.12.30.3 Sector wise

7.12.30.4 INTEREST RATE WISE

7.12.31 Age-wise classification of over dues and generation of report

7.12.32 Ability to generate outstanding / arrear status / reminder letter

7.13 Reports and Inquiries

7.13.1 7.13.1.1 System should reflect position of accounts of a customer at any point of time, in a

columnar form which include

7.13.1.2 Limit

7.13.1.3 Date of valuation (stock statement)

7.13.1.4 Market value

7.13.1.5 Advance value

7.13.1.6 Drawing power

7.13.1.7 Outstanding balance

7.13.1.8 Irregularity

7.13.2 Ability to generate reports based on

7.13.2.1 Sanction / availed amount

7.13.2.2 Due dates of repayment

7.13.2.3 LAST RECOVERY AMOUNT & DATE

7.13.3 Ability to generate reports with / without provision and write-off figures

7.13.4 System to furnish at the end of each month and on ad-hoc request list of all limits

overdue for inspection along with dates of last inspection

7.13.4.1 Details of security

7.13.4.2 Historical data of valuation of primary and collateral security

7.13.4.3 Limit history covering drawing power, peak-outstanding, peak irregularity,

minimum outstanding during a month, for the months specified

7.13.4.4 Details of credits and debits into the account beyond a stipulated amount- to be user

definable at account level and will be different for credits and debits.

7.13.5 Query on the status of the customer to issue no-due / no-objection certificate.

7.13.6 Certificates of outstanding balances, Recoveries, interest, etc to customers

7.13.7 PROVISON FOR GENERATION OF INTEREST CERTIFICATE ON FUTURE

DATE

7.13.8 Generate Limits register at user defined intervals

7.13.9

7.13.9.1 Provide a full set of operational, audit trail and MIS reports which include

7.13.9.1.1 Daily Activities Report

7.13.9.1.2 Outstanding Report

7.13.9.1.3 Due Date Analysis Report

7.13.9.1.4 Overdue Report

7.13.9.1.5 Classification of Assets

7.13.9.1.6 Assets written off

7.13.9.1.7 Closed accounts

7.13.9.2 Reports

7.13.9.2.1 Advice of transactions to customers

7.13.9.2.2 List of NPA Account IRAC status wise / with provisioning

7.13.9.2.3 Document Register

7.13.9.2.4 List of Inoperative Accounts - For a given period

7.13.9.2.5 List of account which is overdrawn - for a given period

7.13.9.2.6 Limit Register

7.13.9.2.7 Balance Report

7.13.9.2.8 Statement of Account

7.13.9.2.9 Ledger - Regular / Dummy

7.13.9.2.10 Interest Calculation Product Report

7.13.9.2.11 TDS calculation report

111

7.13.9.2.11A TDS PROJECTION REPORT

7.13.9.2.11B TDS DEDUCTION REPORT

7.13.9.2.12 Report on processing charges recovered

7.13.9.2.13 List of Accounts opened / closed

7.13.9.2.14 Cheque Issue Register

7.13.9.2.15 Stop Payment Register

7.13.9.2.16 Cheque book register

7.13.9.2.17 Pass Book Printing

7.13.9.2.18 Report on Folio Charges

7.13.9.2.19 Statement of Account is ASCII format

7.13.9.2.20 Balance Certificate

7.13.9.3 QUERY

7.13.9.3.1 Account details for a given customer

7.13.9.3.2 Assessing Value of account. Information for the following to be provided between

two dates.

7.13.9.3.2.1 Interest Income

7.13.9.3.2.2 Other Income

7.13.9.3.2.3 Deposits maintained

7.13.9.3.2.4 Length of Association with bank

7.13.9.3.3 Account closure query

7.13.9.3.4 Exception Transactions

7.13.9.3.5 Statement of Account Query (for Current day)

7.13.9.3.6 Statement of Account Query (for any given period)

7.13.9.3.7 Stop cheque issued

7.13.9.3.8 Cheque issued

7.13.9.3.9 List of Overdrawn Accounts

7.13.9.3.10 A / C wise debit / credit balances

7.13.9.3.11 Query on effect of a transaction on available limit

7.13.9.3.12 Clearing cheques returned for a given period Inward Clearing / Outward Clearing

7.13.9.3.13 Query on Asset classification

7.13.10 7.13.10.1 Audit trail of transactions / jobs done for all accounts / masters should be available

7.13.11 Provide on-line enquiry capabilities for each loan record to include

7.13.11.1 Transaction pending for further processing

7.13.11.2 Currently active outstanding records

7.13.11.3 Currently inactive records but still being kept in the system

7.13.11.4

All the transaction movement history as long as they are kept in the system. The

period for which the history transactions are maintained in the system must be user-

definable and can vary for each product

7.13.12 Provision to view / print the details of a loan account for the entire period of Loan.

7.13.13 Provision to generate Demand, Collection and Balance register

7.13.14 All reports under MIS on monthly / quarterly (FORTNIGHTLY / H.YEARLY

/YEARLY)

7.13.15 Statement of irregular accounts M

7.14 Interface / Integration

7.14.1 Integration with collateral management facilities for verification / entry of details of

collateral

7.14.2 Interface with customer information module for linking customer details to limit set

up and vice-versa

7.14.3 Provide for interfaces from Reserve Bank of India, other banks, Credit Information

Bureau, for credit risk information / default status

8. Non Agricultural Loan (Indirect lending)

8.1 House Building, Transport etc. loan to Employee's Credit Co operative Society

(ECCS)/SHG/Other societies.

8.2 Interest calculation methods.

8.3 Interest and Principal Repayment/Recovery process definition.

8.4 Reports for Statement of Accounts ,Closure report, Interest calculation for Income

Tax, Monthly statements for loan demand etc.

9. Agriculture Loan (Indirect Lending)

9.1 Loan Given to SHG/JLG

9.1.1 Interest calculation methods for Indirect lending products, seasonal products and

112

existing practice of interest calculation should be maintained.

9.1.2 Insurance calculation method for various Crop insurance.

9.1.3 Interest and Principal Repayment/Recovery process definition.

10. Cash Credit & Over Draft:

10.1 Appraisal for CC/OD. Recording date/Date of membership/Validity date

10.2 Sanctioning of Limits.

10.3 Opening of new account.

10.4 Fixation/Calculation of limits, margin, drawing power.

10.5 Monitoring of the CC/OD account. Max. outgoing/Min out going/Credit Balances

number recording with Ref. date

10.6 Documentation.

10.7 Closing of an existing account.

10.8 Recording and posting of debit entries.

10.9 Recording and posting of credit entries.

10.10 Calculation and Debiting of Interest.

10.11 Issue of Cheque books.

10.12 Debiting cheque return charges.

10.13 Purchase of cheques.

10.14 Generation of Statement of Account & Passbook Printing

10.15 Answering queries related to accounts.

10.16 Stop Payment instructions.

10.17 Dormant and Non Operational accounts.

10.18 Freezing of accounts.

10.19 Accepts the relevant information of CC/OD application form.

10.20 List of documents to be submitted - Checks.

10.21 Records appraisal reports.

10.22 Records sanctioned limits with terms & conditions with ref. to LR meeting date.

10.23 Account opening checks for category of account.

10.24 Checks for list of documents submitted.

10.25 Records all the details of the Application form.

10.26 Cash deposit with scroll number.

10.27 Provides input for RBI specifications viz. margin applicable industry wise.

10.28 Records information from the monthly stock statement.

10.29 Details regarding the security furnished.

10.30 Provides input for RBI specified penal interest for late submission of stock

statements etc.

10.31 MPBF, limit and drawing power.

10.32 Details of the securities provided with reference to the valuation and date.

10.33 Modification to value of security, if any.

10.34 Allows modifications to an account and only with the authority.

10.35 Application for modification with relevant details.

10.36 Application for closing.

10.37 Allows withdrawal by cheque, Standing Instructions and Internal Voucher signed

by an Officer.

10.38 Records date and scroll of the transaction.

10.39 Allows deposit to the account through cheque, cash, remittance, standing

instruction and internal transfer signed by an officer.

10.40 Records interest rate applicable and end of the day balance for calculating interest.

10.41 Allows modification of interest rates for past quarter.

10.42 Accepts the application for issue of Cheque books.

10.43 Calculates rate per cheque leaf to be charged against issue of cheque Book.

10.44 Accepts parameter details for charging the cheque return.

10.45 Parameter available for calculating commission for cheque purchases facility and

113

minimum number of days the bank should hold the Cheque.

10.46 Provision to generate statement of account and printing of passbook with date range

and account range.

10.47 Accepts and activates and de-activates the Stop Payment instruction for an account.

10.48 Provides transaction history of an account to monitor health of the Account.

10.49 Provides facility for classifying assets, provisioning and up-gradation.

10.50 Allows freezing and de-freezing of accounts with earmarking.

11 Term Loan

11.1 Parameter Setting.

11.2 Opening of a new account/Authorization.

11.3 Modification of an existing account depending on Status.

11.4 Closing of an existing account.

11.5 Loan Disbursement.

11.6 Calculation of Interest and Installment Amount based on Installment Calculation

Method. Check list for release of subsequent instalment

11.7 Calculation of Due Dates for Installment.

11.8 Diary creation for every Account.

11.9 Deposit Entry/Authorization.

11.10 Provision of giving Grace Period and Grace Policy for every Installment or only in

first Installment.

11.11 Provision of giving Grace Period and Grace Policy for every Installment or only in

first Installment.

11.12 Interest Application policies. (On, When)

11.13 Calculation of Installment Amounts on Different Amounts (Ledger Balance,

Disburse Amount, Loan Sanction).

11.14 Different Methods for calculating Installment Amount.

11.15 System will calculate Exact Installment Amount Depending on Installment

Calculation Method.

11.16 System Provides facility of giving Moratorium Period to Loan Account.

11.17 Diary will get created taking in to consideration Due Date, Installment Amount,

Moratorium Etc.

11.18 Different Repayment Modes are provided in system Like Quarterly, daily, Monthly,

Bimonthly, Half Yearly, Yearly, Lump sum.

11.19 In Deposition, facility is given to account holder what he want to adjust first, Any

Interest/Which Interest or Principal.

11.20 Depending on Interest charge Frequency Interest will get automatically posted to

his Account.

11.21 Security of Term Loan Detail recording. Prepayment/EMI Guarantor for loan -

Detail Recording.

11.22 Guarantor for loan - Detail Recording.

11.23 System will keep track of Account Holder and his Guarantors.

11.24 Partial Disbursement is allowed.

11.25 Facility of transferring Term Loan Account from One Branch to Another. Re-

Schedulement / Compromise settlement

12 Non Performing Assets & Interest Reversal:

12.1

Balance Sheet reflects the financial position, proper recognition of income,

classification of assets and provisions for bad debts of a Bank. Therefore the

classification of assets and provisions for bad debts should be made properly. The

most important thing to be remembered is that the income recognition should be

based on records of recovery rather than on subjective considerations, what is

today‗s position should be taken in consideration.

12.2 In simple words we can define NPA as ―An asset/account becomes Non performing

Asset when it ceases to generate income for a bank‖.

12.3 The basis/business rules for declaring NPA is different for different types of

advances like - Term loan,/Agricultural loan, Cash credit, Overdraft, Bills Payable,

114

Bills Discounted, etc

12.4 In respect of Term loans, if Installment remains past due for a period of 90

(parameterised) days then it is treated as NPA. An amount is considered "Past due‖

when it remains outstanding for a period of said days.

12.5 In respect of cash-credit and overdraft accounts, if the account is overdrawn for a

period of more than 90 days i.e. one Quarter then it is treated as NPA, provided

those two Quarters are consecutive.

12.6 In respect of bills purchased and discounted, if the bills remain overdue and unpaid

for a period of more than 180(parameterised) days then it is considered as NPA.

13 BILLS

13.1 General requirements

13.1.1 Provide for:

13.1.1.1 Defining work flow requirements for authorizations based on hierarchy levels and

amounts for different types of transactions.

13.1.1.2 Unique reference number generated for each transaction should be a combination

based on branch ID, type of transaction, currency and Serial Number.

13.1.1.3 User should be able to define the order of this combination.

13.1.1.4 To enable users to hold the captured data as an incomplete transaction and the same

may be accepted or committed after all the fields are captured.

13.1.1.5 To provide for creation of multi level authorisation for the purpose of committing

the transactions

13.1.1.6 To prompt the user before any transaction is committed.

13.1.1.7 To provide for any entries in the accounts and the GL, only when the final

authorities has approved the transaction.

13.1.1.8 To support blocking either credits or debits or both in any account.

13.1.1.9 To process all types of transactions and to provide for all types of facilities to draw

up the list of documents missing when the user is processing the transaction.

13.1.1.10 In case of any discrepancies during the validation of documents against the check

list, the same should be forwarded to the next approving authority as per the work

flow defined by the user.

13.1.1.11 To enable creation of new transaction by copying an existing transaction with the

facility to change all fields

13.1.2 Provide for linking of all transactions to day book, subsidiary and General Ledger.

13.1.3 To enable picking up of customer information for all transaction from the data base

13.1.4 To provide capability to search a transaction based on various fields or a

combination of fields such as

13.1.4.1 Customer ID

13.1.4.2 Date of transaction / range of dates

13.1.4.3 Due date

13.1.4.4 Reference number

13.1.4.5 Type of transaction

13.1.4.6 Amounts

13.1.4.7 Selection criteria defined by the user

13.1.5 To enable customisation of new products as and when introduced by the Bank

13.1.6 Masters

13.1.7 Allow the user to define the desired fields as mandatory fields for all types of

products. Interface with customer master module to capture customer details

13.1.8 Provide for keeping a record of directory of Bank Branches giving details like

13.1.8.1 Bank name

13.1.8.2 Branch name

13.1.8.3 Branch address

13.1.8.4 Fax / telephone number

13.1.8.5 E mail address

13.1.8.6 Swift address

13.1.8.7 Contact person

13.1.8.8 BSR CODE

13.1.8.9 PIN CODE

13.1.8.10 CBS BRANCH CODE

13.1.8.11 MICR CODE

13.1.8.12 IFSC CODE

115

13.1.9 Outward bills-cheque for collection

13.1.10 Provide for

13.1.10.1 Our reference number

13.1.10.2 Date of lodgement

13.1.10.3 Name of party / account number

13.1.10.4 Cheque / DD number with date

13.1.10.5 Drawn on bank / branch with city

13.1.10.6 Amount of cheque / instrument

13.1.10.7 Drawee account no. and name

13.1.10.8 Sent for collection to whom like service branch, our branch, other bank with

address

13.1.10.9 Commission, postage

13.1.10.10 Returned instruments with reasons thereof

13.1.10.11 Provide for a separate head in P&L subsidiary ― Interest paid account on delayed

collection‖

13.1.10.12 WAIVER OF COMM. FOR STAFF & QUASI GOVT. BODIES

13.1.11 Provide for printing

13.1.11.1 Different schedules for each type of destination along with instructions for despatch

e.g. courier, speed post etc.

13.1.11.2 Passing of contra voucher

13.1.11.3 Reminders for unrealised instruments beyond specified number of days

13.1.12 Realisation of cheque sent for Collection

13.1.13 Provide for payment of interest for delayed collection of cheques beyond specified

period in respect of state capitals and other places as per Goiporia Committee

Recommendations - specified period to be parameterized separately for state capital

and other places.

13.1.14 Provide for realisation register with the following details

13.1.14.1 Date

13.1.14.2 Our number

13.1.14.3 Amount realized and amount credited

13.1.14.4 Our commission

13.1.14.5 Other bank‗s charges

13.1.14.6 Postages

13.1.14.7 Number of days taken for realization

13.1.14.8 Interest for delayed period if any

13.1.14.9 Returned Instruments

13.1.15 Transfer from Collection to purchase

13.1.15.1 To provide for authorisation -

13.1.15.2 Details of credit to be given

13.1.16 To provide for

13.1.16.1 Separate schedule/code numbers

13.1.16.2 National clearing realization

13.1.16.3 Outward Bills for Collection Register

13.1.17 To provide for collection register with the following details

13.1.17.1 Date of lodgement

13.1.17.2 Our bill number

13.1.17.3 Name of party / account number

13.1.17.4 Amount

13.1.17.5 Drawee details

13.1.17.6 Details of usance / due date

13.1.17.7 Our commission and collecting Bank‗s charges if any

13.1.17.8 Postage

13.1.17.9 Interest charges / recovered as per drawers instructions

13.1.17.10 Details of documents enclosed like Invoice, Lorry / Railway Receipt /Airway Bill

etc. with date / number / amount

13.1.17.11 Instruction to party (regarding commission, C form, overdue interest and disposal

instructions)

13.1.17.12 To whom sent for collection

13.1.17.13 Details of bill returned

13.1.18 To generate-

116

13.1.18.1 Register for a given period

13.1.18.2 Covering schedule along with necessary instructions.

13.1.18.3 Control vouchers

13.1.19 To provide reminders for unrealized bills after due date or parameterized period

13.1.20 Realisation of bills

To provide for register with following details

13.1.20.1 Bill number

13.1.20.2 Name of party / account number

13.1.20.3 Date of realization

13.1.20.4 Amount realized and amount credited

13.1.20.5 Other Bank‗s charges, our commission / postages

13.1.21 To sense the bill from the bill number, date of lodgement and original bill amount

13.1.22 Cheque / Draft purchase

13.1.23 To provide for register with the following details for cheque purchase:

13.1.23.1 Date

13.1.23.2 Our number

13.1.23.3 Name of party / account number

13.1.23.4 Staff / non-staff

13.1.23.5 Amount of Cheque and amount credited

13.1.23.6 Cheque number and date ( date to be validated)

13.1.23.7 Drawee bank / branch

13.1.23.8 To whom sent for collection

13.1.23.9 Interest / commission / postage / other bank‗s charges if any

13.1.23.10 Date of realization

13.1.24 To generate covering schedule for despatch including remittance and dispatch

instructions on realisation (e.g. TT / Courier ) as also necessary vouchers and

provide for charging of commission upfront

13.1.25 To generate reminders for unrealized cheques and maintenance of ledgers party

wise

13.1.26 Realisation of cheques purchased

13.1.26.1 Date of realisation

13.1.26.2 Our number

13.1.26.3 Amount realized / credited

13.1.26.4 Rate of interest

13.1.26.5 Amount of interest

13.1.26.6 Other bank‗s charges

13.1.26.7 Column for returned instrument ( to be debited to Past due and dishonoured bills

account in case of insufficient funds in the party‗s account) with reasons thereof

13.1.27 To provide for entries for converting from

13.1.27.1 Cheque Purchase to Cheque Collection

13.1.27.2 Returning of cheques with reasons thereof

13.1.27.3 Charging of interest from day one with penal interest

13.1.27.4 Our bill number

13.1.27.5 Name of party / account number

13.1.27.6 Bill amount / Amount credited

13.1.27.7 Margin held

13.1.27.8 Drawee details

13.1.27.9 Whether documentary or clean bill

13.1.27.10 Details of demand bills(Demand bills purchased are to be shown separately in

general ledger (GL) under Inland Bills Purchased (Demand) account head)

13.1.27.11 Details of documents enclosed like Invoice, Lorry / Railway Receipt, Airway Bill

etc. with date / number / amount / Transport Operator (validation of date of LR /

RR with provision to override with exception report)

13.1.27.12 Our commission and collecting Bank‗s charges if any

13.1.27.13 Postage

13.1.27.14 Interest charges / recovered

13.1.27.15 Instruction to party (regarding commission, C form, overdue interest and disposal

instructions)

13.1.27.16 To whom sent for collection

13.1.27.17 Date of realization

117

13.1.27.18 Details of returned Instrument ( to be debited to Past due and dishonoured bills

account in case of insufficient funds in the party‗s account) with reasons

13.3.28 Provide for generating-

13.3.28.1 Register

13.3.28.2 Covering schedules for despatch along with instructions of the drawers of the bill

13.3.28.3 Vouchers

13.3.29 To generate reminders based on instructions of the drawer in the schedule or after

parameterised period to drawer and drawee / bank

13.3.30

13.3.30.1 Maintenance of Bills Purchase Register and Bills Purchase Ledger party wise

13.3.30.2 Maintenance of pointed account for margin held

13.3.31 Realisation

13.3.32 To provide for register with the following details

13.3.32.1 Bill number

13.3.32.2 Amount purchased / realized

13.3.32.3 Date of realization

13.3.32.4 Overdue interest

13.3.32.5 Amount

13.3.32.6 Number of days

13.3.32.7 Interest rate and Penal rate

13.3.33 Provide for realisation register and vouchers along with advice for party

13.3.34 To provide for two fields for interest calculation

13.3.35 Upfront

13.3.36 At the time of realisation

13.3.37 To provide for penal interest at the time of overdue bills realization

13.3.38 Bills for discounting

13.3.38.1 Date of Purchase

13.3.38.2 Bill number and Bill Date

13.3.38.3 Name of party / account number

13.3.38.4 Amount

13.3.38.5 Drawee

13.3.38.6 Details of B / E, number of days of usance period and due date

13.3.38.7 Details of documents enclosed like Invoice, Lorry / Railway Receipt, Airway Bill

etc. with date / number / amount / Transport Operator (validation of date of LR /

RR with provision to override with exception report)

13.3.38.8 Discount, amount of discount

13.3.38.9 Commission / postage

13.3.38.10 Date of realization

13.3.38.11 Margin Deducted

13.3.38.12 Details of returned Instrument ( to be debited to Past due and dishonoured bills

account in case of insufficient funds in the party‗s account) with reasons thereof

13.3.39 To generate schedule for despatch along with instructions

13.3.40 Maintenance of Bills Discounted Register and Bills Discounted Ledger party wise

13.3.41 Maintenance of pointed account for margin held

13.3.42 Maintenance of list of IBA approved Transport Operators and validation thereof

while purchasing Bills

13.3.43 To generate reminders one week before due date to drawer & drawee /bank

13.3.44 Realisation of discounted bills

To provide for register with the following details

13.3.44.1 Date of realization

13.3.44.2 Name of party / Account number

13.3.44.3 Amount of bill and amount realized

13.3.44.4 Number of days

13.3.44.5 Rate of interest

13.3.44.6 Overdue interest

13.3.44.7 Penal Interest

13.3.44.8 Margin Deducted

13.3.44.9 Details of returned Instrument ( to be debited to Past due and dishonoured bills

account in case of insufficient funds in the party‗s account) with reasons thereof

13.3.45 To generate realisation register

118

13.3.46 Inward cheques and bills received for collection

13.3.47 To provide for register with the following details:

13.3.47.1 Our number

13.3.47.2 Date

13.3.47.3 Their number

13.3.47.4 Name of our customer / drawee

13.3.47.5 Bill number / cheque number & date ( date to be validated in case of cheque)

13.3.47.6 Amount

13.3.47.7 From whom received with address- (a) From Branches (b) From others - the contra

From whom received with address- (a) From Branches (b) From others - the contra

entries in respect of these two categories are to be shown separately in GL

13.3.47.8 Their commission and interest

13.3.47.9 Our commission and postage

13.3.47.10 Details of documents enclosed like Invoice, Lorry / Railway Receipt, Airway Bill

etc. with date / number / amount / Transport Operator ( validation of date of LR /

RR with provision to override with exception report)

13.3.47.11 Due date

13.3.47.12

13.3.47.13 Instruments returned with reasons thereof. Drawee -in- need is to be referred before

return of instrument. Details of drawee-in-need to be captured while registering bill

13.3.48 Provide for register, schedule, presentation memo incorporating instruction from

the drawer including commission, interest details, mode of remitting realisation

proceeds etc.

13.3.49 To generate contra vouchers

13.3.50 To generate reminders on overdue bills to both drawer / collecting bank and drawee

13.3.51 Realisation of Inward bills

13.3.52 To generate register with following details

13.3.52.1 Date

13.3.52.2 Name of customer / drawer / drawee

13.3.52.3 Branch

13.3.52.4 Amount of bill

13.3.52.5 Amount remitted

13.3.52.6 Our commission including charges on post parcels if any and postage /their charges

13.3.52.7 Interest details including number of days and rate of interest.

13.3.53 To generate realisation register and contra voucher and remittance of proceeds as

per instructions of drawer / bank. System should prepare DD in case of cheques /

bills received other than from our own branches. In case of our own branches

system should prepare IBCN. The amount to be remitted should be based on the

instructions of the Drawer

13.3.54 Immediate credit of outstation cheques

13.3.55 Provide for register with the following details

13.3.55.1 Date of lodgement

13.3.55.2 Our number

13.3.55.3 Name of party, acc type and account number

13.3.55.4 Cheque number, date

13.3.55.5 Amount

13.3.55.6 To whom sent for collection

13.3.55.7 Date of realization / return

13.3.55.8 Commission and other bank charges if any

13.3.55.9 Postages

13.3.56 Provide for validation only for individual accounts and account should have been

operative at least for preceding six months

13.3.57 Reporting

13.3.58 To provide for periodicals reference code wise

13.3.58.1 Statement of overdue inward and outward bills / cheques separately. Generation of

statement of overdue bills purchased / discounted to be submitted to controlling

office

13.3.59 Advance against Bills in Course of Collection

13.3.60 Name of the customer / party

13.3.61 Limit

119

13.3.62 Sanctioning authority

13.3.63 Date of sanction

13.3.64 Renewal date

13.3.65 To generate register with the following details

13.3.66 Date of lodgement

13.3.67 Bill No.

13.3.68 Name of the customer / drawer

13.3.69 Branch of Bank / branch / agency on whom it is drawn

13.3.70 Amount of bill

13.3.71 Drawee details

13.3.72 No. of days grace

13.3.73 Due Date / Details of usance

13.3.74 Our commission and collecting Bank‗s charges

13.3.75 Postage

13.3.76 Interest charges / recovered as per drawers instructions

13.3.77 Whether documentary / clean bill

13.3.78 Details of documents enclosed like invoice, lorry / railway receipts /airway bill etc.

with date / number / amount / Transport Operator(validation of date of LR / RR

with provision to override with exception report)

13.3.79 Details of usance / due date

13.3.80 Our commission and collecting Bank‗s charges if any

13.3.81 Postage

13.3.82 Interest charges / recovered as per drawers instructions

13.3.83 Instruction to party (regarding commission, C form, overdue interest and disposal

instructions)

13.3.84 To whom sent for collection and city

13.3.85 Amount realized and amount credited

13.3.86 Margin held

13.3.87 Date of realization

13.3.88 Details of returned Bills / Instruments (to be debited to Past Due and Dishonored

Bills Account in case of insufficient funds in the party‗s account) with reasons

13.3.89 Provide for generating—(a) register (b) covering schedules for dispatch along with

instructions of the drawers of the bill (c) vouchers and (d) party wise ledger (e)

Control vouchers

13.3.90 To generate reminders based on instructions of the drawer in the schedule or after

parameterized period to drawer and drawee / bank

13.3.91 Maintenance of pointed account for margin held

13.3.92 To generate realization register

13.3.93 To generate reminders one week before due date to drawer and drawee/ bank

13.3.94 To generate de-control vouchers

13.3.95 Supply Bills Purchased

13.3.96 System to provide validation for acceptance of the bill after verifying limits

sanctioned (parameterized) documentation, creation of charge over the assets of the

limited company and other documents.

13.3.97 System to provide for acceptance of the bill after Manager‗s approval

13.3.98 System to provide for register with the following details for supply bills purchased

13.3.99 Date of lodgement

13.3.100 Our bill number

13.3.101 Name of the Govt. Department on whom the bill is drawn

13.3.102 Bill amount

13.3.103 Amount credited

13.3.104 Margin held

13.3.105 Drawee details

13.3.106 Details of the supply bills (Supply bills purchased are to be shown separately in

general ledger (GL) under Inland Bills purchased (Supply bills) account head)

13.3.107 Details of documents enclosed like bill of exchange for the good supplied,

inspection certificate, a contract acceptance note, a receipted Challan evidencing

receipt of goods by the Department concerned.

13.3.108 Our commission

13.3.109 Postage

120

13.3.110 Interest charges / recovered (System to provide for debit from the date of purchase

to the date of receipt of proceeds by the bank)

13.3.111 No. of days

13.3.112 Interest rate and Penal rate

13.3.113 Amount realized

13.3.114 Date of realization

13.3.115 System to generate for realization register and vouchers along with advice for party

13.3.116 Details of returned Instrument (to be debited to past due and dishonored bills

account in case of insufficient funds in the part‗s account) with reasons

13.3.117 Maintenance of supply bills purchased register ledger party wise

13.3.118 Maintenance of pointed account for margin held

14 Remittance

14.1 Remittance transactions involves funds transfer which will include and is not

restricted to Demand draft, Pay Order, Bank Order, Electronic Fund Transfer, Mail

Transfer, Telegraphic Transfer (in local and foreign Currency), RTGS, NEFT. This

includes inward and outward remittance.

14.1.1 Allow remittance for customers and non customers

14.1.2 Provide creation of transaction type which include specific multi-purpose products

like:

14.1.3 Demand Draft

14.1.4 Pay Order

14.1.5 Bank Order (Denominations to be parameterized)

14.1.6 Direct transfer of funds

14.1.7 Telegraphic Transfers

14.1.8 Mail Transfers

14.1.9 Electronic fund transfers (NEFT)

14.1.10 RTGS

14.1.11 SWIFT

14.1.12 IMPS

14.1.13 Bulk payment of products

14.2 Enable setting up and maintenance of bank lists, branch lists, branch id ,alpha code

and drawing limits for paying branches

14.3 Enable creation of a daily rate master for definition of foreign currency conversion

rates to be applied for retail transactions.

14.4 Provide maintenance of currency master history for user defined periods

14.5 Allow overriding default currency rates. Such overriding should be captured in

exception report

14.6 Enable waiver / reduction of charges on specific transactions for any account with

appropriate approval and inclusion in exception report

14.7 Enable definition of amendments possible in the transaction details without

cancelling Transaction

14.8 Enable online approval of transaction by auto referral to appropriate authority

14.9 Enable processing of transactions in both on line and batch mode. Transaction entry

should be possible in singe input mode and bulk import of data.

14.10 Provide automatic generation of instrument number. The information will include

but is not restricted to:

14.11 Issuing branch code and ID no

14.12 Paying branch wise yearly running serial number ( to be reset to 0 at the beginning

of each Financial year)

14.13 Type of transaction

14.14 Type of instrument (the structure of the number is to user definable)

14.15 Provide for issuance of DD / PO / EFT / TT / MT against the following mode of

payments-cash ,debiting account of the customer at the same branch, debiting

account of the customer at another branch (should support multi branch

transactions). Internal debit note / voucher, bill negotiated / discounted and debiting

third party account with proper authorisation.

14.16 Provide for issuance of DD on another Data Centre of the Bank.

14.17 Provide printing of instruments in pre printed Continuous Stationery

14.18 Provide user definition of criteria for generation of issuance advice (B-12) to the

paying bank / branch which will be used based on Paying bank / branch.

121

Correspondent bank (in case of Foreign Currency Drafts) Advice for DD in a given

amount range.

14.19 Provide maintenance of stock of instruments with alpha series and issue of books

/running stationery there against.

14.20 System should have facility to automatically pick up the next DD / PO / BO / MT

instrument number from the stock

14.21 Provide for issuance of DD / Fund Transfer / Pay Order / Bank Order

14.22 Provide input for name of the payee, amount and date.

14.23 Provide branch code and branch name in a drop down list box

14.24 Provide Drawee branch Name and Code in a drop down list box

14.25 Provide for IBCN Number, Branch ID for drawer and Drawee branch, Branch

ALPHA and branch Name for drawer and drawee branch, appropriate IBCN

Transaction Code for Inter-branch(IBT) and Direct Head Office(DHO)

Transactions, Daily Reporting Statement (in hard as well as soft copies), IBCN paid

register, auto allotment of IBCN number and generation of IBCN number allotment

register.

14.26 Provide for account status at the time of posting of Voucher

14.27 Provide instant printing of DD / Pay Order / Bank Order / Mail Transfer

14.28 Enable control over Security items

14.29 Enable Running Number and Missing Number

14.30 Enable defining Service charges (parameters)

14.31 Enable passing of Accounting entries / advice as per bank‗s requirements

14.32 Provide updation of master

14.33 Provide charging of out of pocket expenses and Actual Postage / Telegram Charges

14.34 Provide Transmission of messages by SWIFT

14.35 Provide for bulk remittances

14.36 PROVIDE FOR MULTIPLE DEBITS AND SINGLE / MULTIPLE

REMITTANCES

14.37 Enable DD issued on Service Branch at centers where such service branches exist -

separate field for reversal

14.38 Provide for Bank orders (fixed amount)

14.39 Facility for receipt and authorizing payment which will include but not restricted to:

14.39.1 Batch receipt of messages

14.39.2 Validation of instruments noted for caution instruments reported lost (stop

payments )

14.39.3 Validation for date of instrument (period to be parameterised)

14.39.4 Validation for duplicate issued

14.39.5 Validation for instruments already paid

14.39.6 Validation of ALPHA number of the instrument

14.39.7 Provision to redirect to other accounts

14.40 Provide for payment on Instrument / instructions in the modes which include but

not restricted to

14.40.1 Cash (ceiling for cash payment should be parameterised)

14.40.2 Crediting account of customer at the same branch or another Branch i.e. (it should

provide for IBCN generations in such cases)

14.40.3 Issue of another instrument / remittance instructions like Bankers cheque

14.40.4 Crediting third party accounts and Internal accounts

14.41 Provide for cancellation of instruments against user determined conditions for

Cancellation. Facility to cancel an instrument and pay cash / credit customers

accounts with proceeds with recovery of charges for cancellation.

14.42 Provide for recording of caution for instruments reported lost (stop payment). These

instructions can be originated by the user or internally generated

14.43 Provide for validation of instrument numbers against stop payment instruction

before actual pay out of the amount

14.44 Provide for validation of instrument numbers against stop payment instruction

before actual pay out of the amount

14.45 Support validation of instruments before payment that will ensure that instrument /

remittance are not paid twice or instruments cancelled / reported as lost are not

honoured. The validation will include (a) Instruments / remittances issued by the

issuing branch exceeding Rs.10,000 / . (b) Instruments noted for caution. (c)

122

Instruments report as lost. (d) Instrument remittances paid. (e) Intra office suspense

account.

14.46 Provide for recording of reason for dishonour of instruments with minimum of 99

types of reasons for dishonor

14.47 Provide for overriding facility with user defined authorization for issue of

instruments with direct debits when an account exceeds the authorised account limit

and provision for exception report.

14.48 Support issuance of duplicate / revalidation by the issuing branch. Period for

allowing revalidation to be user definable with recovery of charges for the same.

14.49 Provide for transfer of outstanding instruments beyond the cut off date / period to

Head Office with related IBCN entries and user specific details

14.50 Allow facility to record pre-requisite conditions for duplicate issue. Validation

against these conditions will include but is not restricted to:

14.50.1 Original issue reference

14.50.2 Reported lost

14.50.3 Stop instructions

14.50.4 Duplicate already issued

14.50.5 Receipt of non payment advice

14.50.6 Receipt of indemnity bond

14.50.7 Prior permission from head office for issue of drafts above Rs. x / -amount (x to be

parameterized)

14.50.8 Provide for referencing the original instrument / remittance while issuing a

duplicate instruments / remittance

14.51 Provide for cancellation of DD(including cash DD) / Remittance on the date of

issue after authorization.

14.52 Provide for cancellation of DD (including cash DD) / Remittance on subsequent

dates

14.53 Provide for generation of accounting entries

14.54 Ability to automatically issue instructions for cancelling the validity of the original

instruments on issuance of duplicate

14.55 Provide for generation of duplicate DD with marking DUPLICATE ISSUED IN

LIEU OF ORIGINAL DD BEARING NUMBER ………REPORTED LOST

14.56 Provide for generation of revalidated DD and remittance

14.57 Provide for generating the advice for duplicate and revalidation of DD / remittance

14.58 Provide issue and payment of MT on non-computerised branches -define

parameters

14.59 Provide for capture of DD payment details

14.60 Provide identification by:

14.61 Cash voucher no. for customer

14.62 Passport / Identification card

14.63 Voter ID, Driving license / Electric Bill / Telephone Bill / Defence ID Card / PAN

Card

14.64 Clearing

14.65 Transfer

14.66 Revalidation

14.67 To be done by the system and fresh revalidated DD / PO / BO to be issued

14.68 No advice to be generated in above cases.

14.69 List of outstanding DD Payable in case of instrument in excess Rs.10,000 / - for

which advices have been received from issuing branch to be generated

14.70 It should generate reminders for issuing branches on O / S in DD payable accounts

after 3 months from date of issue.

14.71 Service charges

14.72 Provide for creation of differential charge structure which should consider

parameters like:

14.72.1 Customer (Branch Customers etc.)

14.72.2 Product (DD / TT Discounted etc.)

14.72.3 Cancellation charges

14.72.4 Amount

14.72.5 Slab or tier charges

14.72.6 Postal / Telegraph / Telecom charges

123

14.72.7 Combination of one or more above parameters

14.73 Provide for creation of differential charge for issuance to noncustomer against cash

etc.

14.74 Support for marking of certain accounts / class of accounts for automatic waiver of

commission / Charge

14.75 Provide generation of reports and queries for daily activity at branch product wise

to include but not restricted to:

14.75.1 DDs / TTs / MTs issued register

14.75.2 Pay order issued register

14.75.3 Draft Account issued and paid details

14.75.4 Bank Order issued register with additional column for date of issue of IBCN

14.75.5 DD / PO issued on a particular day

14.75.6 DD / PO paid on a particular day

14.75.7 Transaction volumes for specified period

14.75.8 Generation of balancing report of IBCN paid and reminders for outstanding entries

14.76 Provide for status for specific instrument / remittance which may include but is not

restricted to:

14.76.1 Unique reference number

14.76.2 Transaction type

14.76.3 Date

14.76.4 Customer

14.76.5 Branch

14.76.6 Customer identification number

14.76.7 Combination of any two or more of the above

14.77 Provide for MIS report generation for computing flow for the branch at the

following levels:

14.77.1 Customer

14.77.2 Branch

14.77.3 Product

14.77.4 Period

14.77.5 Combination of the above

14.78 Provide for generation of control Reports for reconciliation which includes but is

not restricted to:

14.78.1 Unpaid instruments listing

14.78.2 Aging of unpaid of instruments

14.78.3 Note : this report will be with respect to a branch, product and customer.

14.79 Generate reports as per the user requirements for enabling inter branch

reconciliation

14.80 Do not allow modification of DD / Remittance once it is printed

14.81 Allow entries to be authorized by the officials

14.82 Allow printing of DD / PO only on authorisation

14.83 Loading of stationery - to be done manually on every day by the Officer

14.84 Draft Account should be a pointing account (drop down list). It must have the

facility to mark individual Demand Drafts as paid based on which corresponding

accounting entries should be passed.

14.85 Draft Accounts entries will point to the Issuing / paying branch for generation of

DD Issued and DD Paid report in branch-wise seriatim manner with the facility of

dropdown list for report selection. Provide for accounting entries at all stages of

instrument which will include but not be restricted to:

14.85.1 Issue

14.85.2 Payment including certain inter-branch entries as per user definition for

reconciliation

14.85.3 Reversal of entries in the inter-branch account for payments

14.85.4 Parking entries in inter-office suspense accounts

14.85.5 Suspense accounts reversal / reconciliation in no.

14.85.6 Inter office suspense accounts

14.85.7 Cancellation

14.85.8 Charges

14.85.9 Issuance of duplicate

14.85.10 Instruments / instructions

124

15. FEES, INTEREST AND CHARGES

15.1 General Requirements

15.1.1 Provide ability to define fees and charges to be applied to all products based on, but

not limited to:

15.1.1.1 Flat charges

15.1.1.2 Tiered

15.1.1.3 Variable

15.1.1.4 Transaction type

15.1.1.5 Account type

15.1.1.6 Customer type

15.1.1.7 Product

15.1.1.8 Register Type

15.1.1.9 Segment / sector

15.1.1.10 Area type

15.1.1.11 Combination of the above

15.1.1.12 Service Tax on the fees charged on specified categories for each transaction at

predetermined rates.

15.1.1.13 PERIOD WISE

15.1.2 Provide a facility for defining a minimum or maximum amount to be charged based

on period, amount, transaction etc.

15.1.3 Allow the user to override the predefined charges or waive them with a facility for

automatic reversion after a predefined period.

15.1.4 Provide a facility to charge customer for statement sent by other than by ordinary

post, duplicate statements, and ad-hoc statements etc.

15.1.5 Enable creation of an interest rate master for various types of deposit and borrowal

accounts. The application should maintain a history of interest rate changes.

15.1.6 Support defining interest rates for credit and debit balances separately for each

account.

15.1.7 Support creation of penal interest rate masters for various types of deposit and

borrowal accounts and maintain history of changes in the penal interest rates

15.1.8 Support defining penal interest for each type of advance product / facility, for more

than one factor which includes, but is not limited to:

15.1.8.1 Excess Drawings

15.1.8.2 Limit Overdue

15.1.8.3 Non-compliances e.g. non-submission of Stock Statement etc.

15.1.9 Support defining cap for penal interest rate for each product / facility separately

with facility for waiver.

15.1.10 Support defining cap for aggregate interest rate (applicable interest rate+ penal

rate),for each product / facility separately

15.1.11 Allow user to choose method for charging penal interest from time to time, at

account level

15.1.12 Support charging of penal interest for past periods.

15.1.13 Support capturing the factors in respect of which penal interest rate is to be charged.

15.1.14 Support linking interest rate on advance to interest rate on deposit held as security

(loan against deposit)

15.1.15 Support defining spread / differential over deposit interest rate for arriving at

interest rate on the corresponding loan account. Support defining the spread

differently for

15.1.15.1 Customer type

15.1.15.2 Segment type

15.1.15.3 Location type

15.1.16 Allow user to choose options for calculation of accrued interest, differently for

different products. The options should include but not be limited to:

15.1.16.1 Daily on EOD balances.

15.1.16.2 At pre-defined frequencies on average balance in the preceding period

15.1.16.3 Minimum balance during a period in the preceding period

15.1.16.4 Maximum balance during a period in the preceding period

15.1.16.5 End of the period balance

15.1.16.6 The frequencies should include: weekly, fortnightly, monthly, quarterly, half-yearly

and yearly.

125

15.1.17 Support calculation of interest by treating the year as consisting of 360 / 365 / 366

days, taking the actual no. of days in a month, and arriving at accrual / application

on quarterly basis as per financial year / calendar quarter from date of opening of

Term Deposit and keeping record of monthly payment of interest at a discounted

rate.

15.1.18 Support display of interest rate charts applicable from effective dates, historical

upto ten years

16. Interest Calculation

16.1 General Requirements

16.1.1 Provide capability for user-definable Interest rate for debit and credit interest

16.1.2 Provide for interest rates to be linked to keys change in interest rate in master file

should be applied to all accounts through the keys.

16.1.3 Provide for fixed as well floating interest rates

16.1.4 Enable floating rate to be further divided into but not limited to:

16.1.5 Support for interest rate calculation based on but not limited to

16.1.5.1 360 days

16.1.5.2 365 days

16.1.5.3 Leap Year Support

16.1.6 Support interest rate changes with retrospective effect

16.1.7 Support changing rates of interests both in the master and at the account level - with

future effect

16.1.8 Provide capability to handle automatic calculation of local taxes on interest

earnings and deduct withholding tax / TDS on it with alerts for tax deducted in the

previous month but not remitted.

16.1.9 Provide a capability to define different tax rates for different customer types and

Exemptions

16.1.10 Enable users to define the interest accounting in case of holiday:

16.1.10.1 In advance to a holiday

16.1.10.2 Subsequent to holiday

16.1.11 Provide facility to set the new interest rate with an effective date and to generate

customer advice viz. letter / e-mail.

16.1.12 Provide for re-calculation of interest based on value date

16.1.13 Provide support for changes in interest rates during the tenure of the products with:

16.1.13.1 Retrospective effect

16.1.13.2 Current effect

16.1.13.3 Future effect

16.1.14 Provide support for charging penal interest at different rates on all kinds of

products, for reasons defined by the user e.g. Non submission of stock statement,

excess over limit, QIS non-submission.

16.1.15 For deposits maturing on holidays, calculation of interest should be through to the

morning of the next working day.

16.1.16 Provide a facility to define frequency of compounding differently for different

products.

16.1.17 Support choosing method of interest calculation simple, compounding at the

product facility level with past and future effect

16.1.18 Support multiple compounding frequencies for each product, with option to choose

the frequency at account level.

16.1.19 Support compounding of interest, whether the accrued interest is applied (debited /

credited) to the account or not.

16.1.20 Provide a facility to segregate the interest / compounded interest and the original

principal for business reporting purpose.

16.1.21 Provide for recalculation of interest for time deposits - in case the time deposit is

broken before the specified term and the interest to be given is lesser than the

original interest rate.

16.1.22 In case of premature closure of deposit accounts, system to automatically pick up

the interest rate applicable for the actual period the deposit is held and penal rate

(from penal rate master item) and arrive at the rate at which interest is to be charged

with waiver in case of deceased claim settlement, premature extension and

conversion into another term deposit scheme with maturity period covering

remaining period of original deposit.

126

16.1.23 The applicable rate of interest will be the rate for the actual period as applicable at

the start date of the deposit.

16.1.24 System to reflect the above details at the time of subsequent to closure of deposit

when required.

16.1.25 Provide capability to define interest rates for above kind of time deposit products.

16.1.26 System should automatically make adjustments in interest provisions, where

recalculation is required.

16.1.27 Provide facility to calculate the penalty interest in case time deposit is partly / fully

broken.

16.1.28 Support feature of maintaining the history record of the interest rate changes.

16.1.29 Support for defining of differential interest rates for time deposit based on but not

limited to:

16.1.29.1 Carried till maturity

16.1.29.2 Partly broken at predefined frequency

16.1.29.3 Fully withdrawn before maturity

16.1.30 Interest accrual / application

16.1.30.1 Support defining frequency of application of accrued interest for each product /

facility separately.

16.1.30.2 Allow defining of interest application frequency based on a parameterized value,

for any type of account or transaction.

16.1.30.3 Support creation of interest provisions and receivables, based on accrued interest

calculated.

16.1.30.4 Support maintenance of provision / receivable accounts separately for each account

type, product, General Ledger Head separately.

16.1.30.5 Support application of interest by debit / credit to provisions / receivable accounts.

16.1.30.6 Allow interest on debit balance to be applied either as per the parameterized

frequency or on the balance becoming credit.

16.1.30.7 Support generation of certificates at user defined periodicity for the customers

regarding interest applied on the account.

17 Financial Inclusion

17.1 The system should support the following as part of financial inclusion:

17.1.1 Authentication of customers

17.1.2 Secured communication

17.1.3 Transaction processing through fingerprint matching (BIOMETRIC)

17.1.4 Customer enrollment system

17.1.5 Uploading / downloading of transactions / customer enrolment data through online

or offline mode

17.1.6 Generation of printed acknowledgement for completed transactions

17.1.7 Generation of Audit trail including failed transaction. The rejected transaction data

should also reside in the database and should be retrievable for any analysis.

17.1.8 Generation of Audit trail for transaction originations and changes. These should

record the change history in terms of the user, date, nature of change etc. All

changes should be stored within a history table which should record the change

information for each record.

17.2 The system should provide for as part of financial inclusion:

17.2.1 Opening of deposit a/c ( deduplication process is to be done by the system before

any account is opened)

17.2.2 Opening of loan a/c

17.2.3 Cash deposit

17.2.4 Cash withdrawal

17.2.5 Transfer transaction ( both deposit & withdrawal ) between two cards

17.2.6 Uploading transactions Offline and Online

17.2.7 Downloading Interest paid / loan repaid transactions

17.2.8 Pension disbursement through centralized job stream posting

17.2.9 A report generation module for generation of various MIS reports

17.2.10 Enquiry module for on line query and help line related activities

17.3 The following reports should be generated:

17.3.1 Customers enrolled during a day, given period

17.3.2 Audit Trail for a given period

17.3.3 Report of transactions done during the day, given period

127

17.3.4 Generates atleast 10 nos. of MIS reports for the purpose of monitoring and control

of the project by the bank.

18 General Ledger

18.1 General Requirements:

18.1.1 Support online update to GL accounts for all types of transactions.

18.1.2 Provide for generation of daily Trial Balance in Bank‗s General Ledger Balance

Format and Section 42 Return -ACT-1 Format. Copies maybe obtained on request.

18.1.3 Provide for reflecting in the General Ledger Balance the total of credit balances in

current accounts on the liabilities side and total of debit balances in Cash Credit

Accounts on the asset sides respectively by taking into account the total of debit

balances in current accounts on the assets side and total of credit balances in Cash

Credit accounts on the liabilities side every day.

18.1.4 Provide ability to produce General Ledger

18.1.4.1 By Branch

18.1.4.3 By Centre

18.1.4.4 By Zone (as defined by bank) / REGIONAL OFFICE

18.1.4.5 BY DISTRICT WISE

18.1.4.6 Bank as a whole

18.1.5 Support application of alternate methods for generation of reports required for

statutory purposes and for internal Management Accounting.

18.1.6 Provide for capture of all financial transactions concurrently for

18.1.6.1 Transaction currency

18.1.6.2 Accounting unit currency (‗local currency‗)

18.1.7 Allow data entry as well as printing of transaction as well as total amounts with

following formats (both in figures and words) for all screens, reports, documents

(including cheque printing)

18.1.7.1 Millions, Billions and Trillions

18.1.7.2 Lakhs and Crores (HUNDREDS / THOUSANDS)

18.1.8. Provide for fiscal year (April to March) accounting.

18.1.9 Allow splitting of fiscal year as defined by user.

18.1.10 Support user-defined financial reporting periods other than fiscal year, e.g. 15

months or 9 months.

18.1.11 Support monthly / quarterly / half-yearly accounting periods within each fiscal year

with facility for aggregation of monthly figures into quarterly / half-yearly figures.

18.1.12 Provide for automatic maintenance and carry forward of period-end account

balances to subsequent periods for

18.1.12.1 Each accounting period within a fiscal year

18.1.12.2 Across fiscal years / financial reporting periods

18.1.13 Allow reporting of figures as at end of monthly accounting periods over a quarter /

half year / year(s).

18.1.14 Allow sorting of figures as at end of monthly accounting periods as per user-

defined parameters.

18.1.15 Allow postings pertaining to prior dates after authorization (restricted to current

accounting period).

18.1.16 Provide for continuing operations into the new fiscal year with authorization even if

due to some contingency, closing of accounts for the prior fiscal year remains

incomplete.

18.1.17 Provide for detailed logging of all events related to ‗opening‘ and ‗closing‘ of

accounting periods.

18.1.18 Allow user-defined closing cycles for any fiscal year with authorization.

18.1.19 Provide for different accounting entities to ‗close‗ independently.

18.1.20 Provide for acceptance and posting of only balanced journal entry transactions.

18.1.21 Support automatic calculation of ‗Retained Earnings‗ for each fiscal year and its

automatic carry forward to the next fiscal year.

18.1.22 Support defining organization hierarchy allowing multiple levels reporting of

‗Financials‘ (trial balance, balance sheet and profit and loss accounts). The

hierarchy definition to support reporting at

18.1.22.1 Bank / Accounting Entity Level

18.1.22.2 BLOCK LEVEL WISE

18.1.22.3 Zonal Level.

128

18.1.22.4 Branch Level.

18.1.22.5 DISTRICT LEVEL.

18.1.23 Provide for reporting of ―Financials‖ at user-defined levels e.g. State Level, District

Level, City Level and Block Level)

18.1.24 Provide for defining chart of accounts allowing reporting of accounted transactions

for, but not limited to:

18.1.24.1 Statutory financials and cash-flows

18.1.24.2 Management reporting

18.1.24.3 Financials for group consolidation

18.1.25 Provide for defining individual general ledger accounts with following parameters,

including but not limited to:

18.1.25.1 Effective dates of the account

18.1.25.2 Overall blocking of account

18.1.25.3 Blocking of an account for specific accounting period / entity / location / branch

18.1.25.4 Mapping of each general ledger account to any node (subsidiary heads) of the chart

of account(s)

18.1.25.5 Mapping of each general ledger account to one or more interfacing chart of

accounts (since multiple systems would be interfacing with the general ledger)

18.1.26 Support each general ledger account to be maintained in different currencies.

18.1.27 Provide facility to identify certain General Ledger accounts as bank /cash accounts.

18.1.28 Provide for specifically recording of following additional definitions to general

ledger accounts representing Bank accounts, including but not limited to

18.1.28.1 Bank Name / Internal code

18.1.28.2 Standard Bank Code (as understood across the banking sector for the country /

world)

18.1.28.3 Branch (Name / Code)

18.1.28.4 Funded limits

18.1.28.5 Cheque inventory

18.1.28.6 Authorized signatories (multiple) and their limits

18.1.28.7 Validity dates for authorized signatories

18.1.28.8 MICR code of the Branch

18.1.28.9 Account Identification Number

18.1.28.10 Account Description

18.1.28.11 Account Location, State, Country

18.1.28.12 PIN number

18.1.28.13 Telephone and Fax numbers, Contact person, etc. (multiple)

18.1.28.14 Nature of Account

18.1.28.15 Date of opening / closing of account

18.1.28.16 Method(s) of on-line communication with the bank

18.1.29 Support recognizing, accounting and reporting of transactions with respect to

various heads including, but not limited to:

18.1.29.1 Asset

12.1.29.2 Liability

12.1.29.3 Income

12.1.29.4 Expense

12.1.29.5 Contingent

18.1.30 Support multi-level GL hierarchy definition supporting at least 5 levels.

18.1.31 Provide for recognizing, accounting and reporting of transactions, which are not

directly initiated by customer, such as interest recoverable, matured principle,

provision for interest, etc

18.2 Transaction Posting:

18.2.1 Provide for assigning and usage of specific accounting vouchers (documents) for

specific types of transactions.

18.2.2 Automatically generate and assign sequential numbers to accounting documents for

each document type independently for:

18.2.2.1 Bank / Accounting entity

18.2.2.2 Location / Branch

18.2.2.3 Fiscal year

18.2.3 Support changes to only selective fields of posted documents while allowing for

changes to all fields of documents put ‗on-hold‗.

129

18.2.4 Provide for automatic reversal of accounting document:

18.2.4.1 Individually

18.2.4.2 Collectively based on, but not limited to, parameters like document type,

accounting entity, document reference number, location, user, etc.

18.2.5 Support capture of reason for every reversal.

18.2.6 Ensure that reversal transactions do not affect the analysis of accounts for the

purpose of MIS (e.g. a debit into an account and its reversal by a credit entry should

not be considered while reporting movements i.e. ‗additions‘ and ‗reductions‘ to the

account during the period) but reversals should be included in audit trail.

18.2.7 Provide for faster creation of new documents using

18.2.8 Provide for creating recurring entries that allocates one amount to multiple accounts

based on user-definable ratios.

18.2.9 Provide for setting of starting and ending date, period / year for recurring entries.

18.2.10 Provide for automatic / scheduled processing of recurring / repetitive documents for

user definable dates and period e.g. monthly, bi-monthly, quarterly etc.

18.2.11 Provide for automatic recasting of balance in the main account whenever a

transaction is posted in the sub-ledger account.

18.2.12 Support restriction of direct postings to main accounts where sub-ledger account is

maintained.

18.2.13 Allow selecting desired general ledger accounts (such as employee loan accounts,

travel advance, etc.) to provide similar functionality for clearing of open debit and

credit transactions within the general ledger account.

18.2.14 Provide for defining for each account (which is chosen to offer the clearing

functionality) what should be the nature of the originating transaction (debit or

credit) and what should be the nature of clearing transaction (corresponding credit

or debit). The system should enforce the definition.

18.2.15 Allow for defining account level rules to automatically charge-off tolerable

differences (user-definable and based on definable authorizations) to specific

accounts while clearing open unbalanced debit and credit transactions

18.2.16 Allow definition of rules for automatic processing (‗clearing‘) of open transactions

in batches . The definition of rules should allow combination of various selection

parameters like, but not limited to:

18.2.16.1 Accounting entity

18.2.16.2 Specific GL account

18.2.16.3 Definable set of GL accounts

18.2.16.4 Branch / Location

18.2.16.5 Group of Branches

18.2.16.6 Nature of transaction

18.2.16.7 Definable set of Document types

18.2.16.8 Any of the reference number fields

18.2.16.9 Amount

18.2.17 Provide for alerts for duplicate vouchers based on a combination of the following:

18.2.17.1 Dates

18.2.17.2 Reference number

18.2.17.3 Amounts

18.2.18 Provide standard fields for recording of narration at the following levels:

18.2.19 Provide for capture of following dates per transaction (with automatic update by

system wherever possible), but not limited to:

18.3.19.1 Date (and time) of preparing the document

18.3.19.2 Value date

18.3.19.3 Date (and time) of authorizing the document

18.3.19.4 Date (and time) when document was changed

18.3.19.5 Date of reference document if any

18.3.19.6 Date when document was reversed

18.3.19.7 Date of exchange rate used for foreign currency translation

18.2.20 Support concurrent recording of transaction across accounting entity /branch /

location through one accounting document.

18.2.21 Support defining rules for automatically calculating and accounting for, but not

limited to:

18.2.21.1 Difference on clearing unbalanced open items

130

18.2.21.2 Exchange rate difference postings (at time of clearing of open transactions)

18.2.21.3 Income Tax (payable as well as recoverable)

18.2.21.4 Service Tax

18.2.21.5 Sales Tax

18.2.21.6 Purchase Tax

18.2.21.7 Cash Discounts

18.2.21.8 Interest on over-due amounts

18.2.21.9 Service Charges

18.2.22 Ensure correct on-line generation of automatic entries based on defined rules at the

time of data-entry or batch update itself.

18.2.23 Accounts Receivable / Accounts Payable:

18.2.24 Provide definition of sub-ledgers for desired main ledger accounts.

18.2.25 Allow linking of multiple sub-ledger accounts (receivables as well as payables)

within the accounting entity to behave as one account.

18.2.26 Support definition of following codes and their assigning to specific sub-ledger

accounts (valid across receivable as well as payable accounts)

18.2.26.1 Income tax codes

18.2.26.2 Service tax codes

18.2.26.3 Payment terms

18.2.26.4 Service charge codes

18.2.27 Provide Alert for remitting / payment of taxes to concerned authorities at pre-

defined periods.

18.2.28 Provide ability to post miscellaneous receivable and payable transactions such as:

18.2.28.1 A. Receivables:

18.2.28.2 Service Charges / Commission / Rent e.g. from Fund Transfer, Agency, Lockers.

18.2.28.3 Sale of assets

18.2.28.4 Down payments / Advance payments

18.2.28.5 Security Deposits (e.g. rent, telephone, electricity etc.)

18.2.28.6 Adjustment journals (e.g. exchange rate difference etc.)

18.2.28.7 Inter unit reconciliation entries

18.2.28.8 Receipts (manual as well as through electronic mode)

18.2.28.9 Payments (refunds)

18.2.28.10 Income Tax

18.2.28.11 Service Tax / Any other Tax

18.2.28.12 Bills Payables:

18.2.28.13 Vendor invoice

18.2.28.14 Debit / Credit notes to Vendor

18.2.28.15 Down payments / Advance payments

18.2.28.16 Adjustment journals (e.g. rebate on bills, amortized discounts, provisions, exchange

rate difference etc.)

18.2.28.17 Payments (manual as well as automatic, including electronic mode)

18.2.28.18 Receipts (refunds)

18.2.28.19 Employee related payments

18.2.28.20 Withholding Tax (including automatic printing of tax certificates)

18.2.28.21 Service Tax (including automatic printing of tax certificates)

18.2.28.22 Inter-Unit reconciliation of accounts

18.2.28.23 Specific / Part reversal of entries

18.2.29 Provide for generation / printing of, including but not limited to:

18.2.29.1 Accounts balances

18.2.29.2 Accounts statements

18.2.29.3 Payment Advice / Receipt Advice

18.2.29.4 Correspondence based on account balance, un-cleared transactions, payment made,

amount received, etc.

18.2.29.5 Accounts analysis (based on due dates, etc.)

18.2.30 Managing receivables and payables:

18.2.31 Provide support for complete tracking of receivables, through one visual / printable

interface, with regard to:

18.2.31.1 Due date

18.2.31.2 Date of receipt of payment

18.2.31.3 Date when deposited with bank

131

18.2.31.4 Date when realized

18.2.32 Provide support for complete tracking of payables, through one visual / printable

interface, with regard to:

18.2.32.1 Receipt of Invoice

18.2.32.2 Accounting of the Invoice

18.2.32.3 Approval of Invoice for payment

18.2.32.4 Due date and other terms of payment

18.2.32.5 Date of printing of payment instrument / instruction

18.2.32.6 Authorization of payment

18.2.32.7 Date of release of payment

18.2.32.8 Date of realization of payment

18.2.33 Facilitate automatic payments based on user definable payment terms

18.2.33.1 using following parameters, but not limited to

18.2.33.2 Payment method (e.g. cheque, transfer, etc.) preferred for the payee /vendor

18.2.33.3 Bank account from which payment may be made (based on definable authorizations

specific to a branch / location)

18.2.34 Facilities for ―copy‖ of the last transaction

18.2.35 Single Debit with multiple credits & Multiple debits with single credit

18.2.36 Support generation of single payment for multiple transaction, cutting across one or

more receivable, payable or general ledger accounts for, but not limited to

18.2.37

18.2.37.1 Provide support for recording of Cancelled cheques / other instruments

18.2.37.2 Bounced cheques

18.2.38 For payments made, provide support for automatic recording and accounting for:

18.2.38.1 Collection charges

18.2.38.2 Service charges

18.2.38.3 Any other charges

18.2.39 Ensure automatic reversal of accounting documents in the event of, but not limited

to:

18.2.39.1 Cancelled cheques / other instruments

18.2.39.2 Bounced cheques

18.2.40 Allow user to update cheque inventory only for select bank accounts based on

definable authorizations.

18.2.41 Provide for querying / printing of cheque register for individual bank accounts

based on definable authorizations.

18.2.42 Provision of automatically printing of correspondence for payment made / amount

received to any one or combination of the following

18.2.42.1 Payee

18.2.42.2 Payee bank

18.2.43 Provide fully functional interface for affecting inter-branch / location, inter-bank

accounts funds transfer with complete integration with general ledger functionality.

18.2.44 Bank Reconciliation:

18.2.45 Support reconciliation of bank accounts using bank statements inputs either as:

18.2.45.1 On-line manual entry, or

18.2.45.2 Upload of standard structure soft file (say SWIFT format, etc)

18.2.45.3 Upload of flexible structure soft file (different for each bank or bank account)

18.2.46 Support automation of bank reconciliation based on combination of following filter

parameters, but not limited to:

18.2.46.1 Transaction code (e.g. Inward clearing, Outward clearing, Service charges, Interest,

etc.)

18.2.46.2 Bank / Branch code / MICR code

18.2.46.3 Cheque / Instrument number

18.2.46.4 Date of transaction

18.2.46.5 Amount

18.2.47 Ensure that bank reconciliation process does not interfere with the regular

accounting process or maintaining books of accounts.

18.2.48 Ensure that bank reconciliation process does not adversely affect the analysis of

account for the purpose of MIS (e.g. reporting account movements during the

period, or fund flow analysis).

18.2.49 Budgeting:

132

18.2.50 Support general ledger accounts level budgeting at each of the following levels:

18.2.51 Provide for generation of ‗Original‗ budget as well as revised versions and

forecasting from past period / year actual or budget figures using:

18.2.52 Reports and Inquires:

18.2.53 Provide for reporting of Financials at:

18.2.53.1 Bank / Accounting Entity level

18.2.53.2 REGIONAL OFFICE LEVEL / Zonal level

18.2.53.3 Branch / Location level

18.2.53.4 Business Unit level / BLOCK LEVEL

18.2.54. Provide reporting of the following financial reports, but not limited to at each of the

above reporting levels:

18.2.54.1 Trial balance (with debit and credit values listed in separate columns)

18.2.54.2 Balance sheet

18.2.54.3 Profit and Loss account

18.2.54.4 Net movement by account (or set of accounts) showing opening balance, additions

during the period, reductions during the period, and closing balance

18.2.54.5 Incremental movements by account (or set of accounts) showing only the

incremental additions and reductions during the period

18.2.54.6 Average balance sheet

18.2.54.7 Cash flows

18.2.55 Provide for automatic rolling up of transaction level data to summary values

18.2.56 Provide for generation of analysis of outstanding amounts based on user defined

parameters which include:

18.2.56.1 Currency

18.2.56.2 Branch / Location

18.2.57 Interface / Integration:

18.2.58 Support full (on-line as well as off-line) interface with following front end

applications / functionality, but not limited to:

18.2.58.1 Payroll / Personal Management system

18.2.58.2 Treasury application (Front Office, Middle Office and Back Office modules)

18.2.58.3 Asset Liability Management System

18.2.58.4 Cash Management System

18.2.59 Provide for user-friendly support for synchronization of data with interfacing

systems / applications.

18.2.60 Provide for user-friendly support for reconciling of data with interfacing systems

/applications.

19. Specific MIS Requirements

This is addition to compliance list as per the Annexure-3

19.1. General Requirements

19.1.1 Provide for a report generation facility that would generate reports specific to user

requirements. System should also generate all statutory and regulatory reports. The

data for these reports to be captured at the branch.

19.1.2 Facilitate generation of report on screen, print, file, optical disk etc.

19.1.3 Provide user friendly interface for viewing, extraction, printing of all reports

19.1.4 Enable generation of historical transaction reports for a specific period (within a

fiscal year, across years etc.)

19.1.5 Enable users to apply Boolean selection parameters (e.g. >, <, =, AND, OR) as

selection / exception criteria for report generation.

19.1.6 Provide for generating reports across multiple financial periods for any entity

within the hierarchy in list or columnar form.

19.1.7 Provide for generating reports across multiple versions of financials for any entity

in list or columnar form

19.1.8 Provide for automatic rolling up of transaction level data to Summary values

19.1.9 Enable users to define report formats (columnar or in list form) based on the

following but not limited to:

19.1.9.1 Report parameters

19.1.9.2 Logical database structures

19.1.10 Provide for flexible designing of reports including formats for totals, sub-totals,

running totals, etc.

19.1.11 Enable user to insert comments in the structure of all user-defined reports

133

19.1.12 Enable users to prepare new reports by using existing reports as models.

19.1.13 Enable generation of reports on multiple pages if necessary.

19.1.14 Enable report writer to link up to ('call up') other reports

19.1.15 Allow selecting user selectable reporting formats for dates (DDMMYY or

MMMYY, etc.) amounts (Millions / Billions / Trillions or Lakhs / Crores), etc.

19.1.16 Provide for rule based rounding of values and / or totals.

19.1.17 Computational capabilities

19.1.18 Enable calculation of the following account balances for Transaction reports

19.1.18.1 Opening balances

19.1.18.2 Closing balances

19.1.19 Run Time Option

19.1.20 Enable scheduling of processing / printing of Reports (including statements /

memos /notes) at desired frequencies, including

19.1.20.1 Daily

19.1.20.2 Weekly

19.1.20.3 Monthly

19.1.20.4 Quarterly

19.1.20.5 Half-yearly, yearly

19.1.20.6 Ad hoc

19.1.21 Provide for the option to direct specific reports to certain terminals

19.1.22 IMPORTANT RETURNS REQUIRED

19.1.23 General Ledger Balance (ACT-1)

19.1.24 Statement of limits sanctioned by Branch Managers within their delegated powers

and beyond their delegated powers (CMR-7 & CMR-7A)

19.1.25 Certificate of Balancing of Books (IT-4)

19.1.26 Statement of irregular accounts (for CC,OD,BP,LC,BG) - RCR-1

19.1.27 Statement of Sundry Debtors - BS-8

19.1.28 Statement of Sundry Creditors - BS-9

19.1.29 REGISTER FOR BANKERS CHEQUE, CHEQUE ON OTHER BANKS,

DEMAND DRAFT

19.1.30 IMPORTANT MONITORING RETURNS (IMRS)

19.1.31 Position of Currency Chest Balance (RES-7)

19.1.32 Monthly Credit Information (RB-C)

19.1.33 Funds Remittance in Transit Account (REM-I)

19.1.34 Monthly reconciliation of accounts with RBI

19.1.35 IBR

19.1.36 Statement of other bank‗s DD / TT paid

19.1.37 Statement of Review / Renewal of borrowal Accounts (CR-HC-2)

19.1.38 Statement of suit-filed / Decreed accounts

19.1.39 Statement of Irregular Loan Accounts - Loan and DPGs (RCR-2 A & B)

19.1.40 Daily Maturity Statement

19.1.41 Fortnightly balance statement

19.1.42 Statement of maturity pattern of deposits with residual maturity

19.1.43 Statement of maturity pattern of advances

19.1.44 Interest band wise term deposits report

19.1.45 Interest band wise advances report

19.1.46 Term deposit BAND-WISE for bank as a whole

19.1.47 Statement of TDS recovered from accounts

19.1.48 Overdue advances and NPA position

19.1.49 ACTIVITY AND SCHEME-WISE Progress report

19.1.50 ACTIVITY AND SCHEME-WISE Recovery performance

19.1.51 ACTIVITY AND SCHEME-WISE Subsidy utilization / requirement statement

19.1.52 NHB Rural Housing Finance

19.1.53 Flow of credit to SSI

19.1.54 BSR

19.1.55 GCC / SCC / FINANCIAL INCLUSION

19.1.56 QUATERLY PROGRESS REPORT

19.1.57 LOAN TO ADWDR FARMERS

19.1.58 ACTION TAKEN REPORT

134

19.1.59 TIME-BARRED LOAN DOCUMENT REPORT

19.1.60 UNCLAIMED DEPOSIT STATEMENT

19.1.61 INNOPERATIVE ACCOUNT

19.1.62 Institutional Deposit Account/ Govt. Deposit Account

19.1.63 Interest Accrued and Payable Report

19.1.64 KCC Disbursement upto 7 %, (Monthly, Quarterly, Half-yearly & Yearly)

19.1.65 Premature Closure Report for Time Deposits

19.1.66 Compromise Settlement of Loan

19.1.67 Customer specific reports

19.1.68 Amount of business generated from a customer / group for product wise / branch

wise / etc.

20. SAFE CUSTODY AND LOCKERS

20.1 Safe Custody Facility

20.1.1 Support capturing of customers details for customer master which may include but

not be restricted to

20.1.1.1 Name

20.1.1.2 Address

20.1.1.3 Board Resolution Number and date

20.1.1.4 Authorised signatories

20.1.1.5 Nature of operation (singly, jointly two, jointly by any two of the three, etc.)

20.1.2 Provide for automatic capture of customer details from existing database (CIF) in

case of the existing customer

20.1.3 Provide for capturing and retrieval of signature/s of authorized person/s

20.1.4 Provide for definition of 'different types of items' under safe deposit articles which

includes but not limited to:

20.1.5 Provide for user definable 'fee table' for capturing

20.1.5.1 Application fee

20.1.5.2 Handling charges

20.1.5.3 Any other charges

20.1.5.4 Periodicity of levy of charges

20.1.6 Support capturing of nomination details which includes but not limited to:

20.1.6.1 Name

20.1.6.2 Address of the nominees

20.1.6.3 Relationship

20.1.6.4 Date of Birth

20.1.6.5 Age

20.1.6.6 Maximum no. of nominee to be parameterized

20.1.6.7 Witness's name

20.1.6.8 Witness's address

20.1.6.9 Support generation of reports, at user definable periodicity, which may include but

not limited to:

20.1.6.10 Reminder for payment of fees

20.1.6.11 Acknowledgement of payment of fees

20.1.6.12 List of accounts where fees have not been recovered /paid

20.1.7 Provide validation of the Time Deposits / Demand Deposits offered as lien Lockers

20.2 Support capturing of customer details for Customer master which may include but

not be limited to:

20.2.1 Name

20.2.2 Address

20.2.3 Board Resolution Number and date

20.2.4 Authorised signatories

20.2.5 SB/Current Account no/ Reference account number

20.2.6 Nature of operation (singly, Jointly by any two of the three, etc.)

20.3 Provide for automatic capture of customer details from his existing database in case

of existing customer

20.4 Provide for maintenance of locker inventory with size-wise break-up which

includes but not limited to

20.4.1 Total Number in use

20.4.2 Total Number not in use / free

20.4.3 Total Number under servicing.

135

20.4.4 Provide for capturing and retrieval of signature/s of Authorised person/s

20.4.5 Provide for capturing and retrieval of signature/s of Authorised person/s

20.4.6 Support capturing of nomination details which includes but not limited to

20.4.6.1 Name of the nominees (Maximum no. to be parameterized)

20.4.6.2 Address of the nominees

20.4.6.3 Relationship

20.4.6.4 Date of Birth

20.4.6.5 Age

20.4.6.6 Witness's name

20.4.6.7 Witness's address

20.4.6.8 Provide for user definable 'different locker sizes' and rent applicable for each size

20.4.6.9 Provide for user definable 'fee table' for capturing

20.4.6.10 Application fee

20.4.6.11 Handling charges

20.4.6.12 Any other charges

20.4.6.13 Periodicity of levy of rent

20.4.6.15 Penal charges for delayed payment of rent.

20.4.7 Provide for acceptance of standing instruction for recovery of charges

20.4.8 Support generation of list and voucher for fees recoverable from depositors as and

when due and automatic postings thereof

20.4.9 Provide for generation of user definable 'Locker receipt' to be issued to the

depositor

20.4.10 Provide for recording the date, time, name of the person for every operation by the

locker holder/s

20.4.11 Provide for authorisation of locker operations by authorized signatory before the

holder is allowed to operate on the locker

20.4.12 Provide for recording of name of the operating holder for every operation on the

locker

20.4.13 Provide for recording of locker number and the corresponding key number with

ability to alter the same

20.4.14 Provide for STOP of operation against Attachment Order issued by competent court

of law.

20.4.15 Provide for capturing corresponding key number for every locker

20.4.15 Provide for allotting token number and key number to locker holder

20.4.16 Support generation of reports, at user definable periodicity, which may include but

not limited to:

20.4.16.1 Statement of lockers in use, serial number wise, size-wise, customer-wise, age-wise

20.4.16.2 Reminders for payment of rent

20.4.16.3 Acknowledgement of payment of rent

20.4.16.4 List of lockers where rent have not been recovered/paid

20.4.16.5 List of vacant lockers, size-wise

20.4.16.6 Change of KEY for the lockers surrendered and keeping of history

20.4.17 Enable creation of Party Master providing for but not limited to:

20.4.17.1 Standing instructions

20.4.17.2 Updating the party master

20.4.17.3 Enable operation of locker by using

20.4.17.4 Name

20.4.17.5 Locker number

20.4.17.6 Signature scanning

20.4.17.7 Generation of reports

20.4.17.8 Operation of lockers on daily basis

20.4.17.9 Register of overdue rent

20.4.17.10 Register of lockers sealed

20.4.17.11 Rent register

20.4.17.12 Reminders for due dates for rent arrears

20.4.17.13 Register for attachment order received up to date

21 Bancassurance (Corporate Agent/Referral Mode)

21.1 21.1.1 Name of the Policy Holder

21.1.2 Address

21.1.3 Mobile No

136

21.1.4 Name of the Nominee

21.1.5 Sum Assured

21.1.6 Date of Commencement of the Policy

21.1.7 Table - Term

21.1.8 Amount of Premium

21.1.9 Mode of Payment

21.2 Micro Insurance

21.2.1 Name of the Policy Holder

21.2.2 Address

21.2.3 Mobile No

21.2.4 Name of the Nominee

21.2.5 Sum Assured

21.2.6 Date of Commencement of the Policy

21.2.7 Table - Term

21.2.8 Amount of Premium

21.2.9 Mode of Payment

21.3 Group Mortgage Redemption Assurance

21.3.1 Name of the Policy Holder

21.3.2 Address

21.3.3 Mobile No

21.3.4 Loan Amount

21.3.5 Date of Birth

22 Trade Finance (Domestic and Foreign Currency)

22.1 Imports Letter of Credit ('LC')

22.1.1 For opening of LC for bank‘s customers where the customer master details are

already prevailing in the system, there should be a facility to search for the

customer record using various search criteria and map the customer details from the

customer master.

22.1.2 For non-customers, the system should not require creating of a customer record in

the customer master file. Instead, the system should allow the opening of the LC by

recording a minimum number of essential information such as name, address and

margin information.

22.1.3 There should be a facility to map the relevant bank details (advising bank,

negotiating bank, advising through bank etc) from the bank details centrally

maintained in the system.

22.1.4 The system should facilitate recording of key information such as LC amount,

currency, tolerance, tenor, issue date, expiry date, expiry place, shipment details,

whether LC is revocable or not, back to back LCs, revolving LC, confirmation

required, negotiation restrictions etc.

22.1.5 The system should generate the LC reference number with minimum processing

such as collection of margin, collection of charges and liability generation of

accounting entries and the details to be entered subsequently under same LC

reference number.

22.1.6 Separate field to record Special instructions to be available. Any variation to set

standard should be sanctioned.

22.1.7 There should be a facility to maintain predefined LC clauses in the system, which is

global, so that these can be linked to any LC of any customer.

22.1.8 The system should cater to maintain LC clauses, which are specific to the customer

so that, whenever an LC is opened for that customer, the user can easily, map the

predefined customer specific clause to his LC.

22.1.9 The system should allow for amending the clauses at LC transaction level

depending on specific requirements of the LC.

22.1.10 The system should provide check boxes for standard terms, documents required and

facility to type any additional documents required.

22.1.11 Ability to record License details, special reports of beneficiary from rating

agencies.

22.1.12 Upon opening of the LC, the respective import LC limit should get updated. System

should be flexible of earmarking the deposit / EEFC to prevent withdrawal

137

22.1.13 If opening of the LC exceeds the granted limit, warning messages should be

displayed, higher authority requested and reports generated.

22.1.14 The system should automatically generate predefined accounting entries, vouchers

and update the branch GL.

22.1.15 The system should automatically pickup the appropriate exchange rate to convert

the LC amount to the base currency amount. In case of enhancement, rate should be

standardized for all account.

22.1.16 There should be a sub-module for all charges related to import transaction. The

system should automatically compute the necessary charges such as LC

commission, SWIFT & Telex

22.1.17 For special customers, the system should compute the commission at the special

rate defined centrally for the customer. Whereas for normal customers, the

commission is charged at the bank‘s normal rate.

22.1.18 When margin is collected from the customer for opening of the LC, the system

should provide for various means by which margin can be collected such as cash

margin, cheque and direct debiting of customer‘s account, which is at any branch of

the Bank.

22.1.19 The system should provide the option to hold funds online in a foreign currency

account of the customer, which is in another branch as security for opening an LC.

22.1.20 The system should maintain margin details per customer per LC.

22.1.21 The system should generate serial numbers on validation of the LC which depicts

the following:

22.1.21.1 The branch which originated the transaction

22.1.21.2 The customer category (Private LC, Government LC, LC under license, LC under

grant, LC for non customers, LC for branch customer, Term credit, Different type

of LC)

22.1.21.3 The LC tenor (sight, usance)

22.1.21.4 The year of the transaction

22.1.21.5 The serial number

22.1.22 There should be an interface from the system to SWIFT, Telex, Fax (without

diskette transfer) so that the opened LCs can be transmitted to the correspondent

banks. Should facilitate generation of specific SWIFT messages e.g. MT 700

22.1.23 After a predefined period from the expiry of an LC (parameterisable), the system

should automatically close the LC, reverse the liabilities, refund balance LC margin

and generate reports automatically.

22.1.24 On a selective basis, there should be a facility to hold above mentioned auto expiry.

22.1.25 Facility to make amendments and only the amendment details to be extracted by the

system for correspondence.

22.1.26 Prior to a parameterised number of days from the date of auto closure / expiry, the

system to generate statements for such LCs.

22.1.27 There should be a facility for reinstating any closed LC.

22.1.28 When there are amendments to LC to increase the LC value, the system should

provide the facility to collect additional margin from the customer accordingly. The

collection of this additional margin can be by way of cash, cheque, direct debiting

customer‘s a/c etc.

22.1.29 Before utilisation of an LC, facility to transfer it from one branch to another with

history.

22.1.30 Facility to record hedges against transactions and utilisation details.

22.1.31 System should have facility of segregating mandatory data, fixed data and variable

data

22.1.32 Application form to be compatible with SWIFT format. Facility to generate

standardized advices to customer. E.g. on discrepancy

22.1.33 System should have the facility to accommodate different or additional information

against specified fields e.g. addresses of SBUs

22.1.34 Mandatory reporting requirements should be supported e.g. HO reports, RBI reports

22.1.35 Integration with SWIFT, Treasury Back office,

138

22.1.36 Check on margin amount / commitment charges / usance charges to be recovered at

LC opening stage

22.1.37 Liability monitoring should be party-wise and LC wise

22.1.38 System should provide check on obtaining Research reports from agencies like Dun

& Bradstreet etc.

22.1.39 Follow up letters, payment messages/advises should be facilitated.

22.2 Inland Letter of Credit

22.2.1 System should support basic entry and voucher support

22.2.2 Liability monitoring and utilisation should be facilitated

22.2.3 System should provide provision to enter acceptance details, special remarks,

enhancements, categorisation of clean or regular LCs

22.2.4 Flexibility to accommodate special instructions, Purchase Orders details, Performa

invoice, insurance, Lorry Receipts, margin details, acceptance details

22.2.5 MIS supporting LC outstanding, unpaid bills, date of sanction, name of authority,

22.2.6 Facility to generate 'as on date' reports

22.2.7 System should facilitate generation of standard documentation for presentation, due

date confirmation, voucher generation and MIS/ledger updation

22.3 Guarantees

22.3.1 The system to have the facility to handle guarantees viz. performance, financial etc.

The system should identify the above mentioned as different transaction types.

22.3.2 Upon entering the shipping/parcel guarantee amount, the system should

automatically capture the customer selling exchange rate and convert the foreign

currency amount into the base currency and compute the margin to be collected

automatically.

22.3.3 If the base currency amount of the guarantee is less than X, the margin to be

collected is P% of guarantee amount in base currency and this should be computed

automatically.

22.3.4 If the base currency amount of the guarantee is more than X, the margin to be

collected is Q% of guarantee amount in base currency.

22.3.5 There should be a facility to override these system-generated figures at transaction

level and exception reports should be generated on such instances.

22.3.6 There should be a facility to define special customers in the system to define the

logic of margin computation for that client.

22.3.7 There should be a facility for collecting margin by way of cash, loan, cheque, direct

debiting from customers account at the same branch or any branch in the Bank

online or in the case where the customer has foreign currency accounts.

22.3.8 In the case of reservation of funds in the foreign currency account, the hold should

automatically be released online on settlement of the bill, retaining any excesses,

which will be refunded on cancellation of the guarantee.

22.3.9 There should be a facility to collect margin partially by way of a loan and the

balance by debiting his account.

22.3.10 On receipt of the original documents, the system should provide for utilisation of

shipping guarantee margin directly (without the intervention of any intermediary

accounts) for the settlement of the bill.

22.3.11 If there is a margin balance, this should be refunded upon the cancellation of the

Bill of Lading by the shipping line. There should be a facility to refund this margin

by way of directly crediting the customer‘s account at any of the Bank‘s branches.

22.3.12 If the customer is not account holder of the bank, there should be a facility to print

Pay Orders from the system for the refund of margin

22.3.13 The number of levels required for authorisation should be parameterisable.

22.3.14 Interest payment to margin balances should be parameterised.

22.3.15 If there is a delayed settlement of the bill by the customer (the guarantee / LC

margin is not sufficient to settle the bill), on settlement of the bill, the system

should calculate interest having adjusted the bill amount for customer‘s margin

balance.

22.3.16 The system should maintain margin (parameterisable) for all guarantees issued

22.3.17 The system should generate liability in base currency for guarantees.

139

22.3.18 System should have field for purpose of BG and onerous clauses

22.3.19 System should have facility to incorporate comfort letters from corporates and other

comfort documents

22.3.20 System should have a special calculator for margin calculation in case of BGs. Such

margins can be kept in cash/FD/EM

22.3.21 System should have the facility of marking lien on collaterals of other branches

22.3.22 System should have the facility to segregate and share commission with other

banks.

22.3.23 Amendments with required authorisation should be permissible

22.3.24 Log of amendments should be available

22.3.25 MIS support of generating BG ledger details

22.3.26 Standardised letters I.e. intimating honor of claim, notice to opener, reminders,

cancellation, etc

22.3.27 Voucher support for accounting adjustments and entries

22.3.28 Opening form with std text and office details

22.3.29 Facility to classify margin wise, counter guarantee wise, type, branch, etc

22.4 Import Bills

22.4.1 There should be a facility to handle bills under LC, collection bills and local bills

(under LC and collection) as different categories of bills with separate reference

numbers.

22.4.2 Facility to handle a number of bills under one LC. LC available amount to be

updated with processing each bill under the LC.

22.4.3 Ability to handle bills of non customers with the input of minimum amount of data

in the system as opposed to customers which necessitate input of comprehensive

details.

22.4.4 All these types of bills should be accommodated and ability to define as sight or

usance (term)

22.4.5 The system should provide the facility to parameterise the mandatory documents

required.

22.4.6 The system should have the ability to record / lodge discrepancies. Auto-generation

of messages to negotiating bank/collecting bank/customer

22.4.7 Upon authorisation of lodgment of bills under LC, the system should automatically

generate and post predefined accounting entries.

22.4.8 Upon authorisation of such bills, the LC available limit should be updated by the

reversing LC liability amount.

22.4.9 Upon lodgment of collection bills, the system should generate and post the

predefined accounting entries.

22.4.10 The system should have the ability to distinguish between the contingent and real

liability of bills. For example there may be a usance limit of 100M and the customer

has accepted bills for 70M.

22.4.11 On processing of the bill, the system should automatically pickup the day‘s

exchange rate, any bill commissions, interest and other charges.

22.4.12 There should be a facility to utilise any LC or guarantee margin for the settlement

of the bill.

22.4.13 If there is any shortfall (the margin balance is insufficient to settle the bill), there

should be a facility to debit the shortfall straight from the customer‘s account

maintained at any branch of the Bank

22.4.14 For sight bills under LC, if not settled within x days, the system should generate a

report on the xth day detailing the payments due on that day. On the EOD of the (x-

y)th day also (y is a day before x), a report should be generated automatically

detailing the payments due on that day.

22.4.15 With each part payment, the liability should get reduced automatically.

22.4.16 There should be a facility to account for charges levied (which will be charged from

the customer) and charges waived (which will be deducted from the total amount

the customer has to settle) separately. These charges should not have any impact on

the LC

140

22.4.17 For clean bills under LC where the correspondent bank has already claimed funds,

the customer should compute the interest from the negotiation date to the settlement

date.

22.4.18 For bills under LC where the correspondent bank has not already claimed the funds,

the interest will be computed from the correspondent bank payment date to the

customer settlement date.

22.4.19 For sight bills this rate will be the normal rate. However, for heavily delayed

payments there should be a provision to apply a penal rate at the discretion of the

management from a date the management decides.

22.4.20 Global parameterisation of interest rates with the ability to override at transaction

level with higher authority.

22.4.21 There should be provision to define special interest rates to special customers which

are automatically applied by the system when the bills for that customer are

processed.

22.4.22 There should be provision to close collection bills which have been accepted by the

customer but not settled for a prolonged period. There should be provision in the

system for auto closure of such bills after a parameterised number of days, if not

settled by the customer.

22.4.23 The system should automatically reverse the entries and generate reports on such

automatic closures.

22.4.24 The system should compute exchange profit per transaction automatically

22.4.25 Authorisation of bills to be done by parameterised level/s of users.

22.4.26 On settlement of a bill where margin has been collected (LC or guarantee), if there

is an exchange profit or loss, the system should provide the option to either directly

charge that from or refund that to the customer‘s account.

22.4.27 For other charges also, there should be a facility to charge them either by debiting

the customer‘s account (which may be at any branch of the Bank) or from margin

collected from him.

22.4.28 For settlement of bills under partial shipment, the system should provide the option

to either make the full settlement from the margin or to proportionately utilise

margin for bill value which is a management decision.

22.4.29 The system should automatically categories unsettled bills and interest as overdue,

substandard, doubtful and loss upon elapse of predefined time periods from the due

date.

22.4.30 The system should have the facility to define different penal rates centrally and

these to be automatically applied by the system.

22.4.31 There should be a facility to override the centrally defined penal rates at transaction

level with higher authority.

22.4.32 System to generate customer advices for all outstanding bills in a predefined

frequency or on elapse of a predefined number of days from a defined day / event

22.4.33 Facility for the settlement of term bills in part prior to the due date of the bill and

the liability to get reduced accordingly upon each part payment.

22.4.34 Ability to crystallise unsettled bills (conversion of the foreign currency liability to

base currency) under LC after a defined period from the due date.

22.4.35 The system should generate a report to capture the bills which have not been

accepted by the customer, after a predefined period from the day of the first

reminder.

22.4.36 Ability to close DP bills in the system, which have been accepted but not settled by

the customers upon elapsing of a defined number of days.

22.4.37 Whenever a currency conversion is involved in the settlement of a bill, the system

should online report the positions generated to the Treasury dealers

22.4.38 Register maintenance of remittances executed with mandatory details

22.4.39 Facility to support updation of vouchers i.e. Debit Orders and Credit orders

22.4.40 Facility to support Foreign Inward Remittance Certificate.

22.4.41 SWIFT compatibility and account fungibility e.g. EEFC

22.4.42 Support to process and report DD and TT remittances

141

22.4.43 Facility to generate follow up letters for collection to drawee, collecting bank,

further instructions

22.4.44 Advice and voucher generation should be facilitated.

22.4.45 System to provide facility to accommodate multiple bills with document support

and entry e.g. Bill of Lading, Bill of Entry, vessel, etc

22.4.46 Ability to generate A1 form and R-Returns

22.4.47 Check to mark bills as 'overdue import bills'

22.4.48 Interest computation to be provided over and above the L/C value with facility of

charging interest separately

22.4.49 Check for segregating and recording suppliers credit and buyers credit transactions

22.4.50 Clean payments to be supported for all misc purposes with R-Return and A2

compliance and mode of remittance

22.4.51 Ability to effect payment of Import bills direct / import bills under L/C's through

market purchase or through EEFC accounts at decided selling rate. Voucher

generation at notional rate or actual rate as decided by the Bank. Transactions to

appropriately

22.4.52 Generation of BEF statement to be submitted to Statutory authorities at prescribed

interval, presently half yearly for a branch / AD

22.5 Export Letter of Credit

22.5.1 There should be a facility to directly download export LCs and amendments from

SWIFT to the Trade Finance system.

22.5.2 There should be a facility in the system to identify the mode by which the LC was

received by the bank (i.e. whether by SWIFT, telex or post).

22.5.3 There should be a facility to advise LCs to the key customers online.

22.5.4 For LCs received by the bank via telex and post, on a selective basis (for non

customers) the system should provide the facility to enter only the following

minimum essential information and advice the LC without having to enter all the

information in the fields.

22.5.4.1 The beneficiary details

22.5.4.2 The LC number

22.5.4.3 The LC amount

22.5.4.4 LC issuing bank

22.5.5 The system should generate a different reference number type for the above

mentioned LCs.

22.5.6 When LC details are entered manually (which are not downloaded straight from

SWIFT) there should be a facility to map the relevant bank details (advising bank,

negotiating bank, advising through bank etc) from the bank details centrally

maintained in the system.

22.5.7 The system should facilitate recording of key information such as LC amount,

currency, tolerance, tenor, issue date, expiry date, expiry place, shipment details,

whether LC is revocable or not, revolving LC, confirmation required, negotiation

restrictions

22.5.8 Ability to record confirmation of a LC and liability to be generated and accounting

entries to be posted on confirmation of a LC. Correspondence also to be generated

accordingly

22.5.9 Facility to record 3rd party bank details

22.5.10 Ability to handle any number of LC transfers to any number of beneficiaries

through the system and advice the other second beneficiaries online if they are also

key customers of the Bank.

22.5.11 The system should maintain the full history of LC transfer details from the original

details though all the transfers to all beneficiaries.

22.5.12 For export LCs of customers of the bank , the system should provide the facility to

directly debit his account for LC advising charges.

22.5.13 The system should automatically pick respective LC advising charges for the

customers and non-customers.

22.5.14 The system should provide the facility to amend the LC when requested by the

opening bank. Facility to record the amendment.

142

22.5.15 When bills are lodged for negotiation under the LC, if there are any discrepancies

such as the bill value exceeding the LC available amount (with any tolerance), LC

expired, last shipment date lapsed etc, the system should provide warning messages

required.

22.5.16 Upon elapsing of a predefined period from the date of expiry of an LC, the system

should automatically close the LC and generate reports accordingly on closure.

22.5.17 Before a predefined period from the expiry date of the LC, the system should

automatically generate reminders to be sent to the beneficiary at the discretion of

the user.

22.5.18 There should be a facility to close LC upon the confirmation from the opening

bank.

22.5.19 There should be a facility to reinstate the closed LCs.

22.5.20 System should facilitate data base updation with specific LC advising details

22.5.21 Support to generate covering schedule and vouchers

22.5.22 SWIFT compatibility for upload of data received and generating of messages in the

format required.

22.5.23 Computation of Advising charges with care to specific charges to key clients

22.5.24 Report on LC confirmation and due date

22.6 Negotiation / Purchase of Export Bill

22.6.1 The system should be able to handle Negotiation of bills / discounting, purchase,

collection of bills and advance against bills/remittances.

22.6.2 The system should generate different reference number types for these types of bills

22.6.3 The reference number generated should be the same throughout different stages of

the bill (e.g. the number generated on negotiation should be the same on the

acceptance and realisation of the same bill)

22.6.4 It should be possible to browse the LCs advised to the customer and negotiate the

bill under the respective LC.

22.6.5 Upon the negotiation of bill under a LC, the LC available amount should get

adjusted automatically with the bill value.

22.6.6 For purchasing of bills, the system should automatically validate the export bill

purchase limit granted to the customer and the limit should be updated upon

purchasing.

22.6.7 Ability to negotiate / purchase a portion of the bill value while the balance to be

credited only on realisation (the balance to be considered as a collection)

22.6.8 Facility should be available to record the bill details including the details of goods,

shipment details, transportation details, insurance details, draft details, tenor,

discounting number of days etc.

22.6.9 When bills are lodged for negotiation under the LC, if there are any discrepancies

such as the bill value exceeding the LC available amount (with any tolerance), LC

expired, last shipment date lapsed etc, the system should provide warning messages

required.

22.6.10 The exchange rate of Treasury should be mapped for transactions without the

requirement for any manual intervention.

22.6.11 Upon negotiation / purchasing of a bill, the system should have the facility to

directly apportion the proceeds online to any number of customer accounts which

are in different currencies in different branches of the bank.

22.6.12 When the currency of the customer‘s foreign currency account is different from the

bill currency, the system to provide the following two options to the user for the

conversion:

22.6.13 Ability to receive currency rates (including cross currency rates) from the treasury

package

22.6.14 Ability to verify whether the appropriate rate of interest / commission is charged,

(based on the parameter set).

22.6.15 Accounting of commission as profit from Trade Finance.

22.6.16 Ability of the system to apportion the interest component between the trade finance

branch and the treasury(parameterisable)

22.6.17 Ability to archive and pool scanned important documents related to transaction.

143

22.6.18 The system should possess the facility to record the availability or non-availability

of buyer‘s report.

22.6.19 If currency conversions are involved, the system should report the positions

generated online to Treasury dealers.

22.6.20 The system should be designed to automatically apply a defined

charge(parameterisable) upon transfer of funds to a foreign currency account.

22.6.21 Option should be available to settle any Domestic/Foreign Currency Loans taken by

the customer directly upon purchase / negotiation of bills.

22.6.22 The system should automatically generate advices and messages on negotiation /

purchasing of bills.

22.6.23 Facility should be available to convert a collection bill to Negotiation or Purchase

with auto reversal of collection entries and generation and posting of new entries

for the negotiation / purchase. A change of exchange rate is required to facilitate thi

22.6.24 There should be a facility to change the tenor of a purchased, discounted /

negotiated bill subsequently with the facility to change the exchange rates

accordingly for the new tenor.

22.6.25 The system should cater to recording of acceptance from the importer.

22.6.26 When the buyer confirms the maturity date, there should be a buyer/facility to

record it in the system.

22.6.27 Ability to impose duty rebates to defined products so that on realisation they are

automatically computed and accounted for by the system.

22.6.28 There should be a facility to record and remit agency commission.

22.6.29 Links to key courier companies to identify the location of bills so that this

information can be provided to the customers when they inquire.

22.6.30 If there is a shortfall on realisation, the system should provide the facility to recover

this shortfall in the following ways:

22.6.30.1 Ø By utilising margin collected (either in bill currency or in base currency) on

negotiation / purchase

22.6.30.2 Ø From any account of the customer in any branch of the Bank (in any currency)

22.6.30.3 Ø A combination of above two methods

22.6.30.4 Ø Debiting a designated GL account

22.6.31 If there is an excess in realisation, the system should provide the option to credit the

excess to any account of the customer which is in any currency in any branch of the

Bank at the realisation day‘s exchange rate.

22.6.32 If there is any balance margin left after the realisation of the bill, the system should

provide the facility to refund this margin to any account of the customer.

22.6.33 If there is any currency conversion involved in recovering the shortfall, refunding

margin or crediting the excess, the positions generated should be reported online to

Treasury dealers.

22.6.34 The system should automatically utilise the realisation days exchange rates for any

currency conversion involved in the shortfall, excess or refund of margin.

22.6.35 The exchange profits or losses arising due to shortfalls, excesses or refund of

margin should be transferred to Treasury.

22.6.36 The system should automatically categories unrealised bills and interest as overdue,

substandard, doubtful and loss upon elapse of predefined time periods from the due

date.

22.6.37 The system should automatically apply penal rate of interest which is X% in excess

of the normal rate or which can be parameterised as per bank rules from time to

time, immediately after the due date.

22.6.38 Should the bank require a penal rate to be applied on a bill which is either an

overdue, substandard, doubtful or loss, the system should have the ability to do so.

22.6.39 The system should provide amounts for provisioning for bad debts based on the Bill

amounts in each of the above categories.

22.6.40 System to generate customer reminders and correspondent bank reminders for all

outstanding unrealised bills in a predefined frequency or on elapse of a predefined

number of days from a defined day / event (for example after 1 day 7 days 21 days

and after

144

22.6.41 Flexibility to incorporate and maintain special rates for each key account

22.6.42 Voucher support and documentation for inter-branch transactions

22.6.43 Facility to generate due date diary for each FBC/FBN with log of amendments

22.6.44 Swift compatibility and facility to generate follow up / reimbursement claims

22.6.45 Reports on due date extension, amendments with authorisation, account turnover,

interest earned.

22.6.46 System should have facility to incorporate ECGC processing

22.6.47 Ledger and voucher support for this function with GR/PP/Softex/ENC form

22.6.48 XOS and Crystallisation facility to realise the bills

22.6.49 Voucher generation and collection of foreign bank charges during realisation

22.6.50 System to have facility to appropriate proceeds to multiple accounts

22.6.51 Inter-branch remittances vouchers to be generated and also viewed in the system

22.6.52 System to have facility to adjust and calculate amounts transferred in case of

application of multiple rates

22.6.53 Facility to view and print MIS/ ledger showing movement of bills for each account

for FBP, FBC and FBN

22.6.54 System to provide calculation of interest and generate advice showing interest rate,

days with checks and authorisation.

22.6.55 System to facilitate recording, apportionment and realisation of bills partly

purchased/ negotiated/collection/adjusted against EPC. Report viewing and printing

facility for each account.

22.6.56 System to facilitate ECGC premium calculation with relevant checks.

22.6.57 System to provide appropriate interest calculation after considering confirmed due

date.

22.6.58 Reporting of FBN/FBP/FBC

22.6.59 MIS on overdue export bills with reminder notes

22.6.60 Margin money provision and reversal on realisation

22.6.61 Ability to record permission by RBI / AD to export goods in Trade fairs /

Exhibitions and re- import of full or part of unsold goods. Treatment of

GR/PP/SOFTEX and Bill of entry in requisite manner (follow - up and reporting of

the above as required by RB

22.6.62 Ability to record and treat existing export document, for which permission for

extension in date of realization has been granted by RBI / Branch. Necessary

treatment in XOS. Facility for follow - up in case of extension given by the branch

22.6.63 Ability to record and treat export bills / import bills as per the social provisions

applicable to SEZ / EPZ's

22.6.64 Ability to record write - off of realisation of export, as per permission granted by

RBI / AD. Treatment of export declarations accordingly

22.7 Export Bills on Collection

22.7.1 The system should generate different reference number type for collection bills.

22.7.2 The reference number generated should be the same throughout different stages of

the bill (e.g. the number generated on submission of documents from the customer

should be the same on the acceptance and realisation of the same bill)

22.7.3 If it is bill under LC, it should be possible to browse the LCs advised to the

customer and link the bill to the respective LC. If the bill is not advised through the

Bank, the system should recognise that the LC has been advised by another bank.

22.7.4 Facility should be available to record the bill details including the details of goods,

shipment details, transportation details, insurance details, draft details, tenor,

discounting number of days etc.

22.7.5 If there are any discrepancies such as the bill value exceeding the LC available

amount (with any tolerance), LC expired, last shipment date lapsed etc, the system

should provide warning messages, require further validations ( parameterisable )

and gener

22.7.6 Ability to scan important documents and attaching them to the transaction should be

possible in the system.

22.7.7 The system should possess the facility to record the availability or non availability

of buyer‘s report.

145

22.7.8 The system should cater to recording of acceptance from the importer.

22.7.9 When the maturity date is confirmed by the buyer, there should be a facility to

record it in the system.

22.7.10 For realisation of collection bills, the system should have a facility to handle cross

currency rates and ideally the exchange rate should be fed by the treasury without

any intervention at the Branch level.

22.7.11 The system should automatically utilise the realisation days exchange rates for any

currency conversion involved.

22.7.12 Upon realisation of a bill, the system should have the facility to directly apportion

the proceeds online to any number of customer accounts which are in different

currencies in different branches of the bank.

22.7.13 Option should be available to settle any Domestic Foreign Currency Loans taken by

the customer directly upon realisation of bills.

22.7.14 The commission should be accounted as the profit of the Trade Finance branch

22.7.15 The system should automatically generate advices and messages on realisation of

bills.

22.7.16 Facility should be available to convert a collection bill to Negotiation or Purchase

with auto reversal of collection entries and generation and posting of new entries

for the negotiation / purchase. A change of exchange rate is required to facilitate thi

22.7.17 Ability to impose duty rebates to defined products so that on realisation they are

automatically computed and accounted for by the system.

22.7.18 There should be a facility to remit agency commission.

22.7.19 Links to key courier companies to identify the location of bills so that this

information can be provided to the customers when they inquire.

22.7.20 If there is any currency conversion involved in the realisation of the bill, the

positions generated should be reported online to Treasury front office system.

22.7.21 System to generate customer reminders and importer‘s bank reminders for all

outstanding unrealised bills in a predefined frequency or on elapse of a predefined

number of days from a defined day / event (for example after 1 day 7 days 21 days

and after eve

22.7.22 Facility to record primary details and generate covering schedule and collection

advice with charges

22.7.23 Ability to generate Liability voucher, and follow-up advices (in the customizable

format) at a pre defined (as per parameter set) frequency

22.7.24 Periodic reports on outstanding and overdue

22.7.25 Supporting XOS charges, recording, processing, reporting

22.7.26 Partywise reporting of bills with overall liability

22.8 Forward Exchange Contract

22.8.1 Facility should be available to enter into forward exchange contracts for the

following types of transactions

22.8.1.1 Import bills under LC

22.8.1.2 Import collection bill

22.8.1.3 Export Negotiation Bills

22.8.1.4 Export Purchase Bills

22.8.1.5 Export Collection Bills

22.8.2 The system should generate different reference number types for each of the above

mentioned types of forward contracts so that upon utilisation of the contract, the

users are able to identify clearly for what transaction the forward exchange contract

has

22.8.3 Exchange contract limit to get updated on entering into, modification, utilisation

and cancellation of forward exchange contracts.

22.8.4 The system should online pass the forward exchange information to Treasury

dealers upon entering into the contract.

22.8.5 The forward exchange contract to be linked to the transaction on its processing for

the utilisation of the contract with check on RBI regulation.b

146

22.8.6 On processing any type of transaction, if the customer has entered into a forward

exchange contract for the same type of transaction, the system should prompt the

user so that the user can check whether the contract is to be utilised for the

transaction b

22.8.7 On utilisation of the contract also the system should pass the information online to

Treasury.

22.8.8 Facility to make amendments to the contract (rollovers) such as extending the

period, change of amount etc. This information to be passed online to Treasury.

22.8.9 Upon the date of expiry of unutilised forward exchange contracts, the booked

contract to be automatically cancelled and information to be passed to treasury

online.

22.8.10 The system should automatically generate reminders before a predefined period

from the date of expiry to be sent to the customer.

22.8.11 Reports to be generated automatically capturing such automatically cancelled

forward exchange contracts.

22.9 Foreign Currency Loan

22.9.1 The system should be able to handle the following types of Trade Finance Loans

separately

22.9.1.1 Packing Credit i.e. Order to order or Running a/c, Post shipment Loans

22.9.1.2 Other Forex Loans e.g. FCNR (B)

22.9.2 Ability of the system to generate separate reference numbers for the above

mentioned loan

22.9.3 Facility to define loan products , incorporate relevant details and block appropriate

limits

22.9.4 System should be flexible to facilitate multiple disbursements

22.9.5 Basic parameters i.e. 75-100% of FOB value or L/c or confirmed order to be

structured

22.9.6 Upon releasing the loan, the system should provide the option either to credit the

customer‘s account online or to issue and print Pay Orders/bankers cheque, or

crediting branch advice, margin or a designated GL account.

22.9.7 The release of the loan should be authorised by levels of authorisation, which

should be parameterisable.

22.9.8 Availability of the limits to be updated on line upon release of loan

22.9.9 There should be a facility to define centrally the interest rates for each type of loan

above which with the facility to override them at transaction level with higher

authority.

22.9.10 Facility to define interest in terms of addition to a base rate e.g.. PLR +/-, LIBOR

22.9.11 Flexibility of updating master for interest rates on changes in regulatory

announcements

22.9.12 There should be a facility to centrally define a minimum interest rate, so that the

highest of the customer interest rate and the minimum rate is applied automatically

by the system.

22.9.13 Ability of the system to define the interest-collecting period for each loan whether it

is on regular intervals (e.g. weekly, monthly, quarterly from the date of loan release

or on a defined date by the bank such as the last working day of the month) or t

22.9.14 For packing credit loans, interest should be computed for the principal amount the

customer is settling, from the day it was released till the settlement date and should

be applied on the settlement day.

22.9.15 Ability to set reminders prior to a predefined number of days from the due date.

22.9.16 On the due date for recovery of interest / principal, ability of the system to

automatically debit customer‘s account or any other designated account for

recovery of interest / principal.

22.9.17 Interest calculation should be supported by detailed ageing of each account

22.9.18 Generation of advices on such auto recovery of the loans / interest.

22.9.19 On settlement of the loan by the customer, the relevant loan limit of the customer

should get updated.

147

22.9.20 If sufficient funds are not available to recover the interest / principal on the due

date, ability of the system to automatically generate customer reminders and a

report capturing all such loans for senior management review.

22.9.21 Facility to recover interest by overdrawing the customer account with parameterised

level of authority.

22.9.22 For interest / loans not recovered due to insufficient balance in the customer

account, the system should automatically generate a report which shows all the

account balances of the customer at the Bank (in all branches) through an account

summary option

22.9.23 Ability to correlate the concerned document against the PO/LC/Performa.

Settlement can only be out of proceeds from export sales. Basis for running account

should be parameterized for example FIFO, LIFO, etc. with a facility to over ride at

transaction le

22.9.24 The system should automatically categorise unsettled loans and interest as overdue,

substandard and loss upon elapse of predefined time periods from the due date.

22.9.25 Accounting entries on category transfer to be parameterisable such as crediting the

un-recovered amounts to a suspense account for subsequent recovery. Notional

entries for revaluation purposes to be supported

22.9.26 The system should automatically apply penal rate of interest which is X%

(parameterisable )in excess of the normal rate, from a defined date.

22.9.27 The system should have the facility to define different penal rates for different loan

categories to be automatically applied by the system.

22.9.28 ECGC details and processing should be facilitated

22.9.29 EEFC provisioning and adjustment should be facilitated

22.9.30 System should facilitate crystallisation of bills

22.9.31 The system should provide amounts for provisioning for bad debts (based on the

criteria defined in the parameters).

22.9.32 Facility to transfer Loans from one branch to another with the transaction history

22.9.33 Facility to transfer a PC into Post shipment on presentation of bill

22.9.34 Facility to monitor the overall exposure to the customer or group

22.9.35 Updating regulatory and mandatory documents e.g. ENC statement, XOS, R -

Returns and

22.10 Domestic Foreign Currency Loans ('DFC')

22.10.1 The system should provide the option to grant foreign currency loans for Packing

credit and Bill Discounting, can be Term or working capital finance (FCNR – B),

can be against FCNR (B) deposit

22.10.2 The system should identify these as different types of loans with the generation of

different reference number categories for each of the different loan types.

22.10.3 Accommodate spreads to be charged on forex loans w.r.t. RBI guidelines and credit

parameters

22.10.4 Upon granting of any of the above-mentioned loans, the accounting entries, which

show the loan liability and the asset, should be accounted in the branch GL in base

currency.

22.10.5 The loan granted should be reflected in the Treasury GL as receivable from the

Trade Finance branch while funding a given Nostro.

22.10.6 For pre-shipment loans, there should be a facility to directly credit the customer‘s

account in base currency in the Branch.

22.10.7 For this there should be a facility to obtain foreign currency funds from a given

nostro in the Treasury and convert to base currency and transfer to the Trade

Finance branch.

22.10.8 Upon the conversion of the currencies, the respective positions generated should be

reported online to Treasury dealers

22.10.9 For all types of forex loans, there should be a facility to transfer funds from a given

nostro of the bank to a selected reimbursing bank in the Treasury.

22.10.10 Upon granting the loan, the system should automatically generate advices

containing the loan details to be sent to the branch where customer maintains his FC

account

148

22.10.11 The system should provide for calculating interest, taxes and other charges.

22.10.12 The system should have the facility to define the interest collecting period for each

loan whether it is on regular intervals (e.g. weekly, monthly, quarterly from the date

of loan release or on a defined date by the bank such as the last working day of t

22.10.13 The system should possess the facility to define different interest and other charges

computational logics (for example, interest may be on the outstanding balance for

the given period or for the settling amount from the day granted).

22.10.14 The system should provide for the following options of loans recovery:

22.10.14.1 Ø Recovery from exports proceeds

22.10.14.2 Ø Recovery from the foreign currency accounts of the customer which may be in

a different branch of the Bank

22.10.15 Upon recovery of the loan, the asset and liability originally generated at the branch

GL should get reversed automatically.

22.10.16 The loan receivable balance of the Treasury should get automatically reversed with

the charging the nostro which was funded on granting the loan.

22.10.17 When the loan is recovered from the exports proceeds of the customer, the system

should provide the facility to transfer funds from the nostro in which the realisation

proceeds have arrived to the nostro which was originally used to finance the loan.

Faci

22.10.18 When the loan is recovered from the customer‘s foreign currency account in

another branch, the system should provide the facility to charge the customer and

transfer the funds to a given Nostro.

22.10.19 The system should provide the facility to apportion the interest between a number

of business units based on computational logic defined by the bank with a part of

this interest to be accounted in foreign currency and the other part in base currency.

22.10.20 For the amount converted into base currency, the system should online report

position to Treasury dealers on the positions generated.

22.10.21 The system should automatically categorise unsettled loans and interest as overdue,

substandard, doubtful and loss upon elapse of predefined time periods from the due

date..

22.10.22 The system should automatically apply penal rate of interest which is X% in excess

of the normal rate, immediately after the due date.

22.10.23 The system should have the facility to define different penal rates for different loan

categories which will be automatically applied by the system.

22.10.24 The system should provide amounts for provisioning for bad debts based on the

loan amounts in each of the above four categories. The provisioning amount is a

percentage of the un-recovered amount, which is defined for each category.

22.10.25 Due date calcluation with parameters of earliest date and latest date

22.10.26 MIS showing various disbursements under one account

22.10.27 Ageing of account showing whether a/c is running or order based

22.10.28 Details of hedges to be co-related with loan transaction & Treasury

22.10.29 Ability to record ODA submitted by the customer for investment in WOS / JV

abroad by Indian company. Record approval from RBI for soecific amount of FC.

Effect remittance in FC, in one go or instalments and maintain records and

reconciliation. Club the re

22.10.30 Payment of bullion imports in FC through market purchase or disbursement of

PCFC / PSFC

22.10.31 Ability to record external commercial borrowing arranged by the bank / directly

arranged by the customer. Recording of approval by RBI, arrange for adjustment of

Inward remittance. Repayment on due dates as per terms of sanction. Record pre-

payments, rem

22.10.32 Submission of ECB returns to Statutory authorities

22.10.33 Ability to disburse PCFC and adjust repayment from remittances received in

Nostro, Disbursement to be credited in INR after conversion by exchange rate,

ability to retire Import bill, Import bill under LC, effect clean remittances,

nremittances towards a