Annexure 2 - Functional and Technical Requirements

Request for Proposal (RFP) for Core Business Solution

Index
S. No. Particulars
Functional
1 LOS
2 LMS including Collections Management
3 Deposits
4 Finance and Accounts including Fixed Assets

5 HRMS

6 Document Management System

7 Company Borrowing & Investments

8 Risk Management & ALM
9 Third Party Insurance Tool
10 Procurement management including Vendor Management

11 Lead Management / CRM Implementation

12 Legal
13
API Manager
14

Aadhaar Data Vault (ADV)

15 Reports
Non-Functional
1
VM Storage & Platform
2
Database
3
Virtual NW and Load Balancer
4
Infrastructure & Network Security
5
NOC
6
Mailing and Collaboration
7
Backup Solution
8
Backup as a service
9
SOC
10

SD-WAN
11 ITSM
12 Disaster Recovery Drill
13
Data and Analytics
14
Hardware Security module (HSM)
 15
DNS (Domain Name System)
16 General Requirement

Note: The list of requirements and functionalities defined in this document are indicative only

Instructions for responding to the functional and technical requirements:

1) Id
2) System Requirement
3) Importance

4) Bidder Response
or Proposal (RFP) for Core Business Solution

Brief Description
Functional
Loan Origination System to map the lead to disbursal phase of lending lifecycle
Loan Management System to track the loans and related details across the lending lifecycle and beyond
Deposits offering to existing and new customers
To cater to the accounting needs of CFHL which must be integrated with various other business applications
to avoid manual entries in the system and provide real time, error free data to different departments and
accurate financial statement analysis report, at any point of time, as per the business needs.

To track and manage the HR processes such as recruitment, leave management, payroll processing etc and its
integration across the CBS touchpoints
To manage the document storage, maintenance and its movement between branches and the document
center.
To assess and manage the flow of funds to and from the CFHL
To assess and manage the flow of funds to and from the CFHL
To ensure and assess propoerties that are secured by Insurance
To ensure that the streamlined vendor acquisition process, maintenace of vendor contracts and transactions

Sales, servicing, marketing and communication engine for lead generation and customer acquisition.
To track and manage the integration of company secretariat across the CBS touchpoints
API manager solution is required for the purpose of managing different API components like API Gateway,
API Dashboard, API Creation, API Publication, Securing API and monitoring API.
To incorporate and integrate Aadhaar Data Vault (ADV) to store Aadhaar Numbers and any connected
Aadhaar data (e.g. eKYC XML containing Aadhaar number and data) in a centralized storage accordance with
the regulatory requirements.
To incorporate standard reports within respective modules
Non-Functional
Virtual machine and storage to be part of Cloud & Computing. This is a platform to provide cloud computing
& storage services to organizations.
To provide database solutions which will be easy to deploy, operate & scale up/down based on the target state
application's requirement. 
Solution designed to securely transfer data from one network access point to other or more network access
points via routing & switching, virtual network and load balancer service.
To provide infra & network security through solutions such as (not limited to) firewall/NGFW, WAF, IPS,
endpoint security & DDOS
To monitor network, servers, and applications for health and performance. Analyze bandwidth and
proactively identify bottlenecks.
Mailing and collaboration services to provide a highly reliable, scalable, and feature-rich mailing environment
including AD, DLP, DMS, Encryption for data at rest
To create a copy of the data on the system that we use for recovery in case the original data is lost or
corrupted.
In addition to the cloud native Back up solution, bidder must provide the backup as a service to ensure next
layer of redundancy.
To protect the organization by monitoring, detecting, analyzing, and investigating cyber threats with the help
of SIEM tools
A virtual WAN architecture to allow enterprises to leverage any combination of transport services—including
MPLS, LTE and broadband internet services—to securely connect users to applications.

Processes & practices for the IT teams to manage the end-to-end delivery of IT services to customers.
To perform Business Impact Analysis (BIA) & provide IT DR plan & perform DR drills.
A platform to perform analysis on complex and dynamic data that allows to retrieve, combine, explore, and
visualize data from the various sources an organization might have.
HSM solution to manage digital keys & provision cryptographic operations for critical functions such as
signing, encryption, decryption and authentication of applications, identities and databases
 To translate the domain names into a specific IP address so that the initiating client can load the requested
Internet resources.
General Requirement for Application Development & Cloud Enabling Functions

ment are indicative only

requirements:

The requirements are categorized as :

a) Critical – These are Mandatory Requirements which are to be met in their entirety
b) Important – These are the requirements which are essential for the smooth functioning of business
operations
c) Desirable – These are the requirements that are desired by CFHL, but are ready to accept even if they are
provided with lesser priority by the Bidder
The Bidder is required to provide appropriate response to each requirement requested as per the below
options:
a) Standard (S) - The system that shall be delivered currently supports this function either natively or
through existing parameterization without further enhancement or the use of either programming or user
tools, i.e. included in the base package.
b) Alternate Available (A) – If the proposed system offers an alternative to this function, the Bidder is
required to provide a written explanation when using this response as a workaround solution.
c) Customization (C) - The function would require customization by the Bidder’s programming staff, and
the Bidder shall provide these features at no additional cost by the agreed timelines but before go live date.
The bidder should also mention the customization required in % terms to meet the requested functionality
and customization efforts in man-days.
d) Unavailable (U) - The function does not exist in the current system and is not scheduled for release in an
update within the next calendar year and is not feasible for customization.
Finance & Accounts Index
Sheet 4: Finance and Accounts

Response Status as per RFP

S Standard
A Alternate available Please populate only these colum
C Customization
U Unavailable

Id System Requirement ImportanceBidder Response (S/A/C/U)

1 Master Data Critical
1.1 Index
1.2 Business Unit Critical S-Standard
1.3 Journal Type Critical S-Standard
1.4 Operator Code Critical S-Standard
1.5 Transaction Reference Critical S-Standard
1.6 Accounting Period Critical S-Standard
1.7 Account Code Critical S-Standard
1.8 Currency Code Critical S-Standard
1.9 Transaction Date Critical S-Standard
1.1 Base Currency and Transaction Currency Critical S-Standard
1.11 Debit Amount Critical S-Standard
1.12 Credit Amount Critical S-Standard
1.13 Main branch Critical S-Standard
1.14 Sub branch Critical S-Standard
1.15 Authorizer Critical S-Standard
1.16 Scheme Critical S-Standard
1.17 Chart of Accounts Critical S-Standard
1.18 GST Tax Code - CGST/SGST/IGST Critical S-Standard
1.19 Start Period Critical S-Standard
1.2 End Period Critical S-Standard
System should have capability to create vendor (an entity that has purchasing and financial transactions) with the company code. This includes vendors/
1.21 suppliers. Critical S-Standard
Each System should assign an account group to vendor when creating vendor master in application. The vendor account group is a classifying term in
1.22 application and is used to group vendors of the same characteristics. Critical S-Standard
1.23 Vendor Name Critical S-Standard
1.24 Vendors entity nature Critical S-Standard
1.25 Vendor number (alpha or numeric) and address Critical S-Standard
1.26 Vendor remit-from-address/ ship from address Critical S-Standard
1.27 Vendor Multiple ship from addresses Critical S-Standard
1.28 Vendor Telephone Critical S-Standard
1.29 Vendor facsimile Critical S-Standard
1.3 Vendor contact person Critical S-Standard
1.31 Vendor email address Critical S-Standard
1.32 Vendor type (e.g., merchandise, non - merchandise, temporary) Critical S-Standard
1.33 Vendor bank account number for electronic funds transfers Critical S-Standard
1.34 Vendor bank terms/contract information Critical S-Standard
1.35 Internal customer number (e.g. number by which we are referenced in the vendor’s customer file) Critical S-Standard
1.36 Vendor TIN information, GSTR Information Critical S-Standard
1.37 Vendor PAN details Critical S-Standard
1.38 Last payment date Critical S-Standard
1.39 Accounting Data - Accounting information like type of account, interest calculation, payment data Critical S-Standard
1.4 Bank Account Number, IFSC Code, Bank Name, branch details Critical S-Standard
1.41 Credit Period field Critical S-Standard
1.42 Nature of Vendor (One Time/ Permanent Vendor) Critical S-Standard
1.43 Applicability of TDS Critical S-Standard
1.44 TDS Rate Critical S-Standard
1.45 Income Tax Act section on TDS applicable to vendor Critical S-Standard
1.46 Threshold limit after which TDS should be deducted Critical S-Standard
1.47 TDS to be deducted if PAN details not available Critical S-Standard
1.48 Currency Code Critical S-Standard
1.49 System should have capability to maintain customer data containing below mentioned Fields
1.5 System should have capability to identify customers by a customer code across the company Critical S-Standard
1.51 System should have capability to maintain details of a customer that are common across divisions at one place in the system at the company level. Critical S-Standard
Each System should assign an account group to customer when creating customer master in application. The customer account group is a classifying term in
1.52 application and is used to group customers of the same characteristics. Critical S-Standard
1.53 The list of items to be included in customer master date is as follows: Critical S-Standard
1.54 Customer Name Critical S-Standard
1.55 Customer Address Critical S-Standard
1.56 Accounting Data - Accounting information like type of account, interest calculation and receipt data Critical S-Standard
1.57 Bank Account Number, IFSC Code, Bank Name, Branch Details Critical S-Standard
1.58 Credit Period field Critical S-Standard
1.59 General Ledger account distributions Critical S-Standard
1.6 Cheque Number Critical S-Standard
1.61 Cheque Amount Critical S-Standard
1.62 Apply-to document /invoice numbers Critical S-Standard
1.63 Apply-to document/invoice Amount Critical S-Standard
1.64 Date of Payment Critical S-Standard
1.65 Account Numbers Critical S-Standard
1.66 Invoice details Critical S-Standard
1.67 Credit memo field Critical S-Standard
1.68 Debit memo field Critical S-Standard
1.69 Cheque details field. Critical S-Standard
1.7 System should have capability to maintain Asset Master Data containing below mentioned Fields
Asset accounting should be a dedicated module in system, it should incorporate several master data components which defines the structure and design for
fixed asset management and accounting in the system. This system design and structure in turn should control and determine the business process regarding
1.71 fixed assets lifecycle right from acquisition to disposal. Critical S-Standard
System should have capability to maintain chart of depreciation.
(The chart of depreciation is the highest level component in asset accounting. It defines the relationship of various underlying components (asset class, asset
code, depreciation area) and design for accounting asset in the system. It exists at the client level and is assigned to a company code to enable that company
1.72 code to use the same. All the other components in asset accounting resides under a COD only.) Critical S-Standard
System should have capability to maintain Depreciation Area
(Depreciation Area is used in order to manage various legal requirements for the depreciation and valuation of assets. It contains terms for management and
computation of Depreciation under various statutes viz. Companies Act, Income Tax Act and other regulatory requirement applicable to organization. One
1.73 entity can have multiple depreciation areas.) Critical S-Standard
System should have capability to define asset class
(Asset class classifies and groups various assets according to their basic nature and common characteristics. For Ex. All plant and machinery shall form part of
1.74 one asset class.) Critical S-Standard
1.75 Asset Master should have following fields
1.76 Asset Name Critical S-Standard
1.77 Type of Asset Critical S-Standard
1.78 Life of Asset Critical S-Standard
1.79 Rate of Depreciation Critical S-Standard
1.8 Estimated Salvage value Critical S-Standard
1.81 Method of Depreciation Critical S-Standard
1.82 Addition/ modification to existing assets Critical S-Standard
1.83 System should have capability of assigning each asset master record to an asset class. Critical S-Standard
System should have the capability to control the assignment of asset numbers by the asset class. i.e. whether the number range has to be internal or external
1.84 depends on the configuration of asset class. Critical S-Standard
System should have the capability to define the control parameters for each asset class and default values should be defined for depreciation calculation and
1.85 other master data e.g. Depreciation Key, Depreciation Area and other relevant fields. Critical S-Standard

1.86 Asset class should establish the integration between the asset master records and the corresponding accounts in the general ledger in financial accounting. Critical S-Standard
1.87 System should have the capability to develop the depreciation key for controlling the calculation of Depreciation for the asset in a depreciation area. Critical S-Standard
Depreciation key should determine the rate of depreciation, the base value on which depreciation is to be calculated and the period for which calculation needs
1.88 to be made. Critical S-Standard
In cases where additional depreciation has to be charged to the asset then it is controlled through the depreciation key and after the required configuration
1.89 settings the same depreciation key should be capable to charge additional depreciation. Critical S-Standard
1.9 System should have capability to maintain Bank Master Data containing below mentioned Fields
1.91 System should be capable of developing appropriate bank master and housing bank account. Critical S-Standard
1.92 List of details to be entered in the bank account are as follows Critical S-Standard
1.93 Bank Name Critical S-Standard
1.94 Account Number Critical S-Standard
1.95 IFSC Code Critical S-Standard
1.96 MICR Number Critical S-Standard
1.97 Branch Name Critical S-Standard
1.98 Branch Point of Contact Critical S-Standard
1.1 Type of Account Critical S-Standard
1.101 Minimum balance Critical S-Standard
1.102 Bank Ledger Code Critical S-Standard
1.103 System should be able to create the investment master data containing below mentioned fields
1.104 Name of security Critical S-Standard
1.105 Nature/type of security Critical S-Standard
1.106 Purchase price of security Critical S-Standard
1.107 Rate of interest in case of fixed income securities. Critical S-Standard
1.108 Tenure of securities. Critical S-Standard
1.109 Frequency of accrual of income. Critical S-Standard
1.11 Maturity date and amount of security (If applicable) Critical S-Standard
1.111 Person responsible for Investment.(Custodian) Critical S-Standard
1.112 Open ended or close ended schemes Critical S-Standard
1.113 System should be able to create the TDS master data containing below mentioned fields
1.114 Type of TDS( For Eg: Salary, Contractor, Professional Fees) Critical S-Standard
1.115 Section of TDS under income Tax Act Critical S-Standard
1.116 Rate of TDS, modifiability according to exception scenarios Critical S-Standard
1.117 Applicability of TDS ( For Eg: Individual, HUF), Threshold limit to be defined basis which TDS should be deducted Critical S-Standard
1.118 Analysis Code
1.119 System should be able to create scheme master containing below mentioned fields
1.12 Scheme Name Critical S-Standard
1.121 Scheme Code Critical S-Standard
1.122 Branch or Sub branch of the scheme Critical S-Standard
1.123 Duration of the scheme Critical S-Standard
1.124 Other Specifications
1.125 Apart from the above mentioned masters system should be capable of creating masters as per the requirement of users. Critical S-Standard
1.126 System should allow only authorized users to change the master. Critical S-Standard
1.127 Any update to the master data should be supported by audit trail. Critical S-Standard
1.128 System should be capable to generate the reports based on parameters defined in master. Critical S-Standard
2 Interface Entries Critical
2.1 System should have capability to post the journal entries once the vendor invoice is approved by the authorized personnel as per the authorization matrix. Critical S-Standard

System should have the capability to capture the figures from payroll system after the payroll for the particular month is processed and pass the expense accrual
2.2 entry in the accounting module of the system automatically. Once the expense accrual entry is passed system should pass the payment entry on dual approval. Critical S-Standard
System should have the capability to capture leave encashment details from payroll module of the system and pass the expense accrual entry automatically once
2.3 the leave encashment process is completed in payroll module. Critical S-Standard
System should have the capability to pass the expense accrual entry automatically for all the claims and expense reimbursements of the employees which are in
2.4 the "approved" stage in Expense reimbursement module of the system. Critical S-Standard
System should have the capability to pass the payment entry for claims and expense reimbursements of the employees for all the applications which are in the
2.5 "Paid status" in expense reimbursement module of the system Critical S-Standard
System should have the capability to pass the expense accrual entry automatically for all the retirement benefit expenses (For Eg: Provident Fund, pension, like
retirement benefit expenses) once the process for Retirement benefit expense is completed in Payroll module of the system. Once the expense accrual entry is
2.6 passed system should automatically pass the payment entry after a defined time by organization. Critical S-Standard
System should have the capability to define the frequency for passing automatic entries (Automatic entries will only be applicable for internal postings but for
2.7 external, wherever Bank and Cash is involved manual intervention for authorization is mandated. Critical S-Standard
2.8 System should have a capability to define the account heads which will be debited and credited for passing above mentioned accounting entries. Critical S-Standard
2.9 System should have the capability to raise an alert if the accounting entries are not passed automatically as per the scheduled time. Critical S-Standard
3 Budgeting Critical
3.1 System should be capable of defining hierarchical structures that allow for reporting of individual as well as aggregate revenues and expenditures. Critical S-Standard
3.2 System should be capable of maintaining an audit trail (including time and user identification)automatically reflecting all budget entries. Critical S-Standard
System should have capability to compute “what if” scenarios using actual budget data or adjusted budget data compared to actual expenditure data or adjusted
3.3 expenditure data in any combination. Critical S-Standard
3.4 System should be capable of allowing users to develop budget forecasts using base-year budgets. Critical S-Standard
System should be capable of accommodating various budget recording methods such as increasing, decreasing, or replacing existing budgets (e.g., versions,
3.5 revisions, or changes in a Budget). Critical S-Standard
3.6 System should have a capability to perform a variety of revenue, expenditure and fund balance forecasting including the ability to perform fee analysis. Critical S-Standard
3.7 System should allow budget request data to be entered easily and/or copy from a user defined period. Critical S-Standard
3.8 System should be capable to create, modify, and establish a budget for a specific scheme and component of a scheme. Critical S-Standard
3.9 System should be capable to develop budget for expense with different fiscal years Critical S-Standard
3.1 System should be capable of allowing forecasts to be expressed in terms of percentage increases or decreases. Critical S-Standard
3.11 System should be able to perform budget modifications and maintain an audit trail of modifications. Critical S-Standard
3.12 System should be capable of providing a process to apply inflation factors to a budget model. Critical S-Standard
3.13 System should have the capability to enter budget requests on-line. Critical S-Standard
3.14 System should provide online worksheet to facilitate preparation of budgets. Information from a user defined period should flow into this worksheet. Critical S-Standard

3.15 Allows budgets or budget items to be frozen at a certain level of approval to prevent further change by the projection percentage during the revision process. Critical S-Standard
3.16 System should provide the ability to make mass adjustments to budget line items throughout the comprehensive budget. Critical S-Standard

3.17 System should be able to Prepare the budget at ledger account, sub account, income, expense, branch, sub branch, scheme, department and employee level. Critical S-Standard
3.18 System should be able to approve budgets through on-line approval. Critical S-Standard
Ability to specify the basis for computing the budget based on user defined criteria (e.g. Salary, total scheme cost, billing rates, total general overheads, Fixed
3.19 Asset Acquisition budget, Branch cost, Sub Branch Cost etc.) Critical S-Standard
3.2 System should be able to allocate budgets across departments, Schemes, Branch, Sub Branch for the same line item as well as roll up to one total cost. Critical S-Standard
3.21 System should be able to perform reallocation and tracking of budgets by individual schemes, branch, sub branch, employees and departments. Critical S-Standard
3.22 System should have capability to track actual project costs and compare with budgeted project costs (adjust if reallocations are made). Critical S-Standard
3.23 System should have capability to track expenses by categories and allocate cost to project cost accounts as required. Critical S-Standard
3.24 System should be able to accommodate project contingency line items in budgets. Critical S-Standard

3.25 System should have capability to provide currency and percentage change techniques by budget line item or line item group to simplify budget preparation. Critical S-Standard
Each cost center should have a contact person or “responsible person” assigned to it in the system. All users should be able to view this field on any cost center.
3.26 This functionality would allow for better communication and assist with compiling group/departmental reports Critical S-Standard
3.27 System must support the entire budget process such as preparation, approval, amendments, monitoring and variance analysis. Critical S-Standard
3.28 System should be capable of analyzing subsequent proposals and changes to budgets without affecting current budgets. Critical S-Standard
3.29 Allow authorized users to see which budgets have been approved. Critical S-Standard
3.3 Users must be able to assign temporary cost center numbers and be able to delete them if not approved. Critical S-Standard
3.31 System should have ability to support activity based costing budget preparation Critical S-Standard
3.32 System should have ability to close budgetary amounts from the current file at the end of the fiscal year. Critical S-Standard
System should be able to allow the rollover of selected budget lines, or all budget lines into the new fiscal year and adjustment of appropriate spending
3.33 allocations and encumbrance balances. Critical S-Standard
3.34 System should allow comparison of different budget versions Critical S-Standard
3.35 System should have ability to allocate overhead and administration costs to departments, cost centers, branch and sub branch levels automatically. Critical S-Standard
3.36 System must provide a high level of security that would only allow specific users to access, create, modify and/or approve specific budgets. Critical S-Standard
3.37 System should have ability to establish a tolerance level for budget warning. Critical S-Standard
3.38 System should have ability to display a warning notice when transactions are proposed for accounts whose budgets have been exceeded. Critical S-Standard
3.39 System should have ability to set spending controls at various levels relating to funds available for expenditures. Critical S-Standard
3.4 System should have ability to check for unauthorized charges against budgeted line items on a timely basis. Critical S-Standard
3.41 System should have ability to provide on-line approval of proposed budgetary transactions. Critical S-Standard
3.42 System should have capability to determine sufficiency of funds prior to processing change orders. Critical S-Standard
3.43 System should be able to identify accounts with budgetary balances that meet criteria for being carried forward to the next fiscal period. Critical S-Standard

3.44 System should have ability to permit the modification of encumbrances (e.g., increase, decrease, or cancel) and produce an audit trail of the transaction. Critical S-Standard
3.45 System should have ability to track the original amount, current amount, payments made, and remaining balance for an encumbrance. Critical S-Standard
3.46 System should have ability to allow for pre-encumbrance and/or encumbrance before a contract or purchase order is awarded. Critical S-Standard

3.47 System should have the ability to provide liquidation of encumbrance when final payment is made against an account when specified by project manager. Critical S-Standard
3.48 System should have ability to automatically close encumbrances with appropriate journal entries for year-end financial reporting. Critical S-Standard
3.49 System should have ability to encumber on-line against available appropriation balance to reduce the corresponding spending allocation. Critical S-Standard
3.5 System should have ability to flag a warning for Non-Sufficient Funds (NSF) condition when vouchers exceed encumbered funds. Critical S-Standard
3.51 System should have ability to perform standard encumbrance accounting activities. Critical S-Standard
3.52 System should have ability to track current year and inception-to- date allocation and authorization amounts in the budgetary accounts. Critical S-Standard
3.53 System should have ability to establish and maintain budget data on-line for any number of past, present, and future years. Critical S-Standard
3.54 System should have ability to store and retrieve actual revenue and expenditure data on-line for any number of past years. Critical S-Standard
3.55 Budget module must recognize account attributes (groupings) that are built into the account structure in the general ledger Critical S-Standard

3.56 System should be able to have all prior history for actual spending and budgets available on-line for multiple years as per the requirement of the organization. Critical S-Standard
3.57 Approved budget is automatically recorded for use by general ledger in new fiscal year. Critical S-Standard
3.58 System should have ability to use workflow for budget approval and calendaring Critical S-Standard
3.59 System should have ability to roll up department or ledger head budgets to the organizational level. Critical S-Standard
3.6 System should have ability to view the detail charges of actual spending or encumbrance amounts on-line. Critical S-Standard
3.61 System should be able to deny financial transaction if budgetary amount is not adequate to cover the transaction being posted. Critical S-Standard
3.62 System should have ability to generate Intermediate and final budget reports. Critical S-Standard
System should have ability to identify budgets by original budget, first revised budget, second revised budget, third revised budget and details of further revised
3.63 budgets. System should maintain history of revision in budgets. Critical S-Standard
3.64 System should have ability to create and maintain multiple budget versions Critical S-Standard

3.65 Ability to create an on-line long-term capital budget that is integrated with direct and indirect expense, accounts payable, budgeting, and project management. Critical S-Standard
3.66 System should have ability to put budget processing for certain line items on hold. (flag budgets on hold) Critical S-Standard
Ability to create cost centers in the budget module before they are created in the GL to accommodate non-approved budgets that should not carry forward to the
3.67 GL. Critical S-Standard
3.68 System should have capability to allow monthly, quarterly, half yearly, yearly budget figures to be established, if desired. Critical S-Standard
3.69 System should have ability to provide centralized monitoring of spending, budget preparation process and available balances. Critical S-Standard
3.7 System should have ability to maintain as many sub-budgets and scheme budgets for certain line items and schemes as needed. Critical S-Standard
3.71 System has capability to produce comprehensive management and budget reporting. Critical S-Standard
System has capability to produce both standard and ad hoc reports as well as allow for the use of standard statistical and logically functional packages so that
3.72 research and analysis can take place. Critical S-Standard
3.73 System has capability to produce internal reports of an organization unit as well as government-wide reporting Critical S-Standard
3.74 Ability to allow the comparison of budget (spending plan) to actual obligations and expenditures, including a variance and percentage variance. Critical S-Standard
3.75 System should have ability to keep multiple budget years open at one time. Critical S-Standard

3.76 System should have ability to provide variance reports illustrating budgets versus appropriations versus actual encumbered amounts to the respective budgets. Critical S-Standard
3.77 Reports should have a ʺto and from dateʺ, with the default being our fiscal year. Critical S-Standard
3.78 System should be able to generate exception reports or criteria-driven reports (e.g. accounts that are 75% expensed at mid-year) Critical S-Standard
3.79 The system should allow users to run reports at a high level and drill down to lower levels Critical S-Standard
3.8 System should be able to create the final budget document on-line in its finished form. Critical S-Standard
3.81 Cost allocation rates can be assigned to specific range of dates for individual cost centers and/or other user-defined criteria. Critical S-Standard
3.82 System should have cut, copy and paste features or easy export to Excel, Access, or other software programs. Critical S-Standard
3.83 System should have ability to produce budget to actual reports on-line. Critical S-Standard
3.84 System should have ability to define budget projections that can be made for multiple years according to user-defined parameters. Critical S-Standard
3.85 System should have ability to accommodate the transfer of funds between budgeted line items. Critical S-Standard
System should be able to do organizational level, department level, branch level, sub branch level, scheme level, project level and Accounting head level
3.86 budgeting. Critical S-Standard
4 General Ledger Functionality Critical
4.1 System should allow sufficient dimensions to allow grouping or rollup levels for GL reporting or on-line inquiry to meet all usersʹ needs. Critical S-Standard
4.2 System should have capability to provide for automated monthly and year end closing entries. Critical S-Standard
4.3 System should have capability to provide automated journal entries for the allocation of indirect cost, fringe and space costs. Critical S-Standard
4.4 Provide real time on-line inquiry to GL detail transaction information. Critical S-Standard
4.5 System should provide for the differentiation between a ʺsoft- closeʺ and a ʺhard closeʺ based on cost center Critical S-Standard
4.6 System should allow data exchange with other subsystems and automatic posting to the GL from other subsystems Critical S-Standard
Provide user friendly drop-down menus for all codes currently available in the system, such as Cost Center, Department Codes, Account Codes, Scheme codes,
4.7 branch codes, sub branch codes and other applicable codes as per organizations requirement. Critical S-Standard
System should provide reconciliation capabilities for Accounts Payable, Accounts Receivable, TDS Accounts, Service tax accounts and other organizational
4.8 created ledgers. Critical S-Standard
System should have ability to set up logic in the system so it will provide a warning if the user has entered an account that may be wrong. For example, if
4.9 someone enters a cash account on a purchase order. Critical S-Standard
4.1 System should allow Coping standard reports over to user libraries and make specified changes to them without altering the original report. Critical S-Standard
4.11 System should allow easy correction of data entry errors within a batch job before posting Critical S-Standard

4.12 System should provide multiple-user operations down to the program level so that many people may access the same files and programs at the same time. Critical S-Standard
4.13 System should have ability to run other applications alongside the GL system software. Critical S-Standard
4.14 System should allow the capability to associate new cost center numbers with historic cost center numbers. Critical S-Standard
4.15 System should have the ability to assign a responsible person to each cost center. Critical S-Standard
4.16 System should process complex selection criteria utilizing operators, Boolean connectors and/or multiple data files across system boundaries Critical S-Standard
4.17 System should provide user-defined on-line HELP screen for field description, policies or procedures related to specific screens Critical S-Standard
System should allow the user to move from screen to screen without moving through menu hierarchies and/or without signing off one application to sign on to
4.18 another. Critical S-Standard
4.19 System should maintain a history of all changes made to accounts and cost centers (not only the latest change) Critical S-Standard
System should have built-in software safeguards to ensure general ledger accounts are always in balance and sub-ledgers totals to main ledger accounts, even
4.2 during computer crashes. Critical S-Standard

4.21 System should allow Creating and posting transactions for subsequent accounting periods (i.e. Month or year) before the current account period is closed. Critical S-Standard
4.22 System should provide access to any data elements and files (permanent or temporary) within the system to authorized users Critical S-Standard
System should Automatically identify and warn the user of errors on-line before posting (For eg: error in account code, budget allowance, duplicate entry, dr/cr
4.23 balance.) Critical S-Standard
4.24 System should allow users to print a proof report to verify entries before posting . Critical S-Standard

4.25 System should provide on-line access to audit trail information including terminal operator ID, time, date, revised amount, and before and after update results. Critical S-Standard
4.26 System should allow automatic reversing entries. Critical S-Standard

4.27 System should Provide the ability to selectively assign access rights to accounts. (activate cost centers for Accounting while they are deactivated for operations) Critical S-Standard
4.28 System should allow the association of each transaction with a user name/user number, job number, entry date and time. Critical S-Standard
4.29 System should restrict the user from duplicate entry using real-time mechanism. Critical S-Standard
4.3 System should provide procedures queue for ʺafter-hoursʺ tasks, including daily backup procedures. Critical S-Standard
4.31 System should allow easy creation and deletion of cost centers Critical S-Standard
4.32 System should allow the correction of errors before the authorization process has been completed Critical S-Standard
4.33 System should have ability to activate or inactivate accounts for specified date range periods Critical S-Standard
4.34 Common GL master should be created for all the units. Critical S-Standard
System should provide stand alone and consolidated trial balance and financial statements for the organization. Along with Extraction of GL reports at
4.35 Company level. Critical S-Standard
System should provide for posting monthly/weekly/daily (depending on the organizations requirement) provisions with respect to expenses and goods in
4.36 transit. Critical S-Standard
4.37 System should provide for document approval process. Critical S-Standard
4.38 System should provide for reversal of document. Reversed document must be linked with original document. Critical S-Standard
Entries once made in the system should not be deleted instead it should be reversed if wrong accounting entry is passed. The reversal should be supported by
4.39 proper audit trail. Critical S-Standard
4.4 System should have standard functionality to simulate and park the accounting entry before it is posted in books of accounts. Critical S-Standard
4.41 Post Simulation system should provide the GL accounts that will be posted in the books of accounts. Critical S-Standard

4.42 Organization should have process of getting parked entries approved and then do the posting in the system. This will help to keep maker and checker control. Critical S-Standard
A document should be created by one person (parked document) and posted by another person after verification. System should provide for segregation of
4.43 duties. Critical S-Standard
4.44 System should restrict the parked document from getting updated in the books of accounts unless and until they are verified by authorized personnel. Critical S-Standard
Recurring entry master can be created in the application for all the recurring entries to be posted at the end of defined period by organization. System should
4.45 automatically pass the journal entries based on details mentioned in master. Critical S-Standard
4.46 The recurring entry master should not update the books of accounts. Critical S-Standard
4.47 The recurring entry should be allowed to change as per the requirement of the organization with the proper audit trail. Critical S-Standard
4.48 System should be able to define the time frame for which recurring entry can be passed. Critical S-Standard
4.49 The month end closing process is as follows: Critical S-Standard
4.5 Running depreciation report to provide for depreciation Critical S-Standard
4.51 Posting accruals and deferrals – Provisions for expenses Critical S-Standard
4.52 Posting recurring entries Critical S-Standard
4.53 Making statutory payments Critical S-Standard
4.54 Closing earlier month and opening new month Critical S-Standard
4.55 Preparing trial balance and financial statements Critical S-Standard
4.56 Interest income on investment should be booked at the end of every month or defined period by organization. Critical S-Standard
4.57 The solution should also cover all the financial entries passed which should give the output as per Ind AS and IGAAP. Critical S-Standard

5 Accounts Payable Critical

5.1 System should have capability to allow new vendor set up during invoice posting. Critical S-Standard
5.2 System should allow entering invoices into batches on-line with control totaling. Critical S-Standard
5.3 System should automatically generate unique invoice posting accounts payable batch numbers. Critical S-Standard
5.4 System should allow processing debit and credit memos when it’s received from vendors. Critical S-Standard
5.5 System should allow correction to the distribution of an invoice without reentering the invoice prior to general ledger distribution. Critical S-Standard
5.6 System should allow posting debit/credit memos to the general ledger automatically. Critical S-Standard
5.7 System should allow to reference a debit/credit memo to multiple invoices of Vendor. Critical S-Standard
5.8 System should allow generating payment through one cheque for multiple invoices issued by same vendor. Critical S-Standard
5.9 System should support multiple payment types (e.g., system cheque, wire transfer and other suitable payment methods) Critical S-Standard
5.1 System should provide on-line warning if total payment amounts exceed invoice amount. Critical S-Standard
5.11 System should flag duplicate vendor invoices to prevent double payment. Critical S-Standard
5.12 System should provide automatic balancing control of the data entry. Critical S-Standard
System should have capability to support on-line inquiries for invoice-by-invoice number, invoices by cheque number, TDS & GST number and invoices by
5.13 vendor code. Critical S-Standard
5.14 System should allow processing stop payments and void transactions. Critical S-Standard
5.15 System should allow for processing over shipments of goods. Critical S-Standard
5.16 System should provide on-line accounts payable data entry validation as well as error correction and reentry of information. Critical S-Standard
5.17 System should allow creation of fixed or variable recurring payments with option of end date and separate payment cycle Critical S-Standard
5.18 System should allow processing inter-fund payables entries. Critical S-Standard
System should allow comparing the purchase price variance. When an item is received should be matched to subsequent vendor invoices entered for calculating
5.19 purchase price variance and compare it with user defined tolerance. Critical S-Standard
5.2 System should allow tracking of all changes to invoice adjustments/cancellations. Critical S-Standard
5.21 System should allow for Automatic calculation of an estimated payment date as part of the Accounts Payable process. Critical S-Standard
5.22 System should provide user-defined aging categories. Critical S-Standard
5.23 System should have capability to generate aging report for payable invoices based on the invoice date. Critical S-Standard
5.24 System should apply prepayments to specific invoice line items with balance reflecting the total net amounts to be paid Critical S-Standard
5.25 System should allow cheques drawn on multiple bank accounts or on a single bank account Critical S-Standard
5.26 System should prevent payment to vendors with debit balances Critical S-Standard
5.27 System should allow multiple partial payments against an invoice up to the total payment value of the invoice. Critical S-Standard
5.28 System should allow processing installment and lease payments Critical S-Standard
5.29 System should allow users to override the invoice amount in the case of discrepancies, and identify the invoice as paid in full. Critical S-Standard
System should allow only authorized users to accept invoice prices that differ from vendor contract price. Also, allow only authorized users to override contract
5.3 pricing and provide contract Critical S-Standard
5.31 System should allow accounts payable users to select invoices for payment based on invoice due date within specified date range on approvals. Critical S-Standard
System should allow Accounts payable users to select bank accounts for disbursements, including reviewing multiple bank accounts to determine the proper
5.32 account from which to issue cheques Critical S-Standard
5.33 System should allow Scheduling of payments and printing cheques Critical S-Standard
System should allow the Accounts Payable module to post to the general ledger in summary the entire accounts payable distribution, manual cheque
5.34 distribution and cash disbursements distribution. Critical S-Standard
System should have ability to electronically transmit user-defined purchase order information from purchasing department and receiving location to accounts
5.35 payable department. Critical S-Standard
5.36 System should allow users to perform electronic matching of purchase order and user-defined invoice information. Critical S-Standard
5.37 System should provide ability to sort cheques by vendor number, by user-defined sequence within bank account number or by vendor name Critical S-Standard
5.38 System should allow for voiding cheques on-line and reverse the payment from the master File Critical S-Standard
5.39 System should allow printing of the cheques after due validation of all the parameters. Critical S-Standard
System should have ability to print cheque stubs with user-defined information such as invoice number(s), invoice line item(s), invoice amount(s), discount
5.4 taken, vendor name, number, purchase order number or any other accounts payable data field. Critical S-Standard
5.41 System should have ability to print cheque stub detail on successive cheque stubs if necessary and void successive cheques Critical S-Standard
Ability to generate a “Cheque Register” – The Cheque register should be printed after each Cheque run and should be sequenced by Cheque number. This report
should provide information on paid invoices such as: invoice gross amount, discount amount, TDS & gst amounts, net amount, vendor name/ID number,
5.42 showing totals for each Cheque number. Critical S-Standard
5.43 System should provide ability to withhold cheques to vendors even though the invoice is due Critical S-Standard

5.44 Ability to generate Cheque Reconciliation Report. This report is printed upon demand in cheque number sequence, showing detail on all outstanding cheques. Critical S-Standard
5.45 Ability to generate paperless wire transfers and ACH transactions. Critical S-Standard
5.46 Ability to flag checks such as negative checks and zero checks. Critical S-Standard
5.47 Ability to prevent printing blank cheques, negative cheques and zero cheques. Critical S-Standard
5.48 System should maintain vendor payment records on-line for current, year-to-date and prior years. Critical S-Standard
5.49 System should accumulate year-to-date vendor wise purchases. Critical S-Standard
System should have ability to print the list of vendors upon request based on user specified format such as: vendor ID number, alphabetical or year-to- date
5.5 purchase amount (amount or quantity) sequenced by product line. Critical S-Standard
System should have ability to generate Vendor Analysis report. This report is printed upon request and should show various breakdowns of activity by vendor
5.51 (quantity, product line, type) for the current period and year-to-date and provide a comparison to the previous year’s figures. Critical S-Standard
System should have ability to generate purchase analysis report. This report is generated by vendor (Names or ID numbers) showing budgeted items, quantities
and amount of purchased item, actual items, budget-to actual purchasing variances, dates purchased, delivery performance, comparisons to prior
5.52 periods/years. Critical S-Standard
System should have ability to generate Vendor Shipping Performance report. The report lists by vendor, due dates for delivery, actual dates of delivery, item
5.53 short shipments, incorrect items shipped and other required information as per the needs of the organization. Critical S-Standard
The vendor master file should be shared between purchasing and accounts Payable only at the inquiry level. An authorized person in the accounts payable
5.54 department must do any updates or changes to the vendor master file. Critical S-Standard
 System should automatically purge vendors after a user- specified period of inactivity, only if the vendor balance and purchase commitments are both equal to
5.55 zero Critical S-Standard
5.56 System should have ability to run reports on inactive vendors. It should list vendors with no activity for a user specified period of time Critical S-Standard
5.57 System should track all changes to vendor master and maintain audit trail for all changes. Critical S-Standard
5.58 System should be able to Identify selected vendors as “critical” for review and analysis Critical S-Standard
5.59 System should be able to deactivate discounts for specific vendors Critical S-Standard
5.6 Create system-controlled limits on vendor transactions, total purchases and other defined parameters as per the requirement of the organization. Critical S-Standard
5.61 System should be able to search by seller number and name. Critical S-Standard
5.62 Definition and description of each stage in the purchasing process should be available within the system. Critical S-Standard
5.63 System should have ability to maintain accounts payable voided cheque log Critical S-Standard
5.64 System should have ability to maintain accounts payable stop payment cheque log Critical S-Standard
5.65 System should allow multiple people to view the same vendor simultaneously, but restrict maintenance of vendor to authorized personnel. Critical S-Standard
5.66 System should have ability to run vendor payment Listing by given parameters as per the requirement of the organization. Critical S-Standard
5.67 Allow multiple users to post entries in the system without locking it up. Critical S-Standard
5.68 System should have ability to run various vendor reports Critical S-Standard
5.69 Systems should have ability to run cash requirement report Critical S-Standard
5.7 System should have ability to run vendor payment history report. Critical S-Standard
5.71 System should have ability to allow inquiry on status of payment Critical S-Standard
5.72 System should have ability to schedule invoices for payment based on defined parameters as per the requirement of the organizations. Critical S-Standard
5.73 System should have ability to accommodate “one-time” vendors and identify them as such. Critical S-Standard
System should have ability to process invoice information, basis all the defined parameters, if applicable. System should have ability to process invoice
5.74 information, including invoice number, amount, payment date and transaction number, if applicable. Critical S-Standard
5.75 System should have ability to generate cheques on a daily, weekly, monthly or user defined basis. Critical S-Standard
5.76 System should have ability to produce a reconciliation activity report showing all the daily on-line update activity in the system. Critical S-Standard
5.77 System should have ability to provide invoice tracking for pending department/agency approvals. Critical S-Standard
5.78 System should have ability to produce a daily report of all cleared cheques by cheque type and by fund. Critical S-Standard
5.79 System should differentiate between payments that are due immediate and payments that are on hold. Critical S-Standard
5.8 System should allow split of several invoices on an obligation Critical S-Standard
5.81 System must allow generating outstanding accounts payable report containing opening balance, transactions during the year and closing balance. Critical S-Standard
5.82 The invoice date must be a required field so that it can be used as a search criteria for reporting Critical S-Standard
5.83 The system must allow the invoice number to be used for inquiry purposes on imported transactions. Critical S-Standard
5.84 Ability to make changes to the vendor file once the payment has occurred. Example: flag inactive, delete Critical S-Standard

5.85 Accounts Payable system should allow running reports by cheque date, fiscal year or any user-defined period. Regardless of when payments were processed. Critical S-Standard
System should have ability to verify existence of key documents to support the voucher prior to submittal – insurance certificates, performance bonds, invoices,
5.86 travel tickets and other required documents required for preparation of documents. Critical S-Standard
5.87 Provide status of any submitted voucher or fund or project to review payments to date and committed funds. Critical S-Standard
5.88 System should have ability to place vouchers on hold and record reasons for hold. Critical S-Standard
Retain history of voucher numbers after payment and/or period end to avoid duplicate voucher numbers. Ideally, system generates voucher numbers and does
5.89 not allow duplicate numbers to be used for A/P vouchering. Critical S-Standard
5.9 System should have ability to reverse flow through the lifecycle till the payment is done. Critical S-Standard
5.91 System should have ability to consolidate multiple invoices from one vendor and pay with one voucher. Critical S-Standard
5.92 System should have ability to maintain open invoice records until paid in full (for unpaid and partially paid vouchers). Critical S-Standard
5.93 System should have ability to develop vouchers for partial payment of invoices. Critical S-Standard
5.94 System should have ability to warn possible duplicate vendor entries even if entry is not an exact match (e.g. ABC Plumbing vs. ABC Plumbing Inc). Critical S-Standard
5.95 System should have ability to delete vendors as required with option of retaining or deleting history. Critical S-Standard
5.96 System should retain vendor history including current period, year to date and all prior history. Critical S-Standard

5.97 System should have ability to suspend and restart payment for specified vendors, parent vendor groups, contracts or work orders for user defined duration. Critical S-Standard
5.98 System should have ability to track invoices to vouchers and vice versa and flag if amount paid is different than original voucher submitted. Critical S-Standard
5.99 System should have ability to process one-time vouchers for non- contract and non-project invoices. Critical S-Standard
System should have ability to accumulate multiple invoices on a single voucher and/or group payments for remittance based on selected criteria (i.e., payment
5.1 due date). Critical S-Standard
5.101 The ability to automatically calculate payment due date from receipt of goods/services or invoice and allow for user override. Critical S-Standard
5.102 The ability to identify the organizational unit, department, branch or sub branch originating a voucher. Critical S-Standard
5.103 The ability to flag and report duplicate purchase orders and invoices. Critical S-Standard
5.104 The ability to generate multiple vouchers or multiple request for payment from a single invoice. Critical S-Standard
The system must include provisions to allow multiple invoices processing on a single contract or purchase order without the potential for overpayment (paying
5.105 twice for the same item). Critical S-Standard
System should have ability to generate voucher for progress payment indicating: item number, description of material or services, quantities, unit price, line
5.106 item total for the voucher and total-to-date for the given contractor, Vendor, project or assignment. Critical S-Standard
5.107 System should have ability to verify existence of all required documents for preparing a progress payment voucher. Critical S-Standard
System should have ability to inhibit (restrain) specified users from modifying invoice data once the invoice has reached approval status through project
5.108 manager release. Critical S-Standard
5.109 System should have ability to record an invoice for partially received material or for over shipments of material. Critical S-Standard
5.11 Ability to enable user to view pending bills, bills in progress and bills being paid. Critical S-Standard
5.111 System should have the ability to pay a vendor automatically on one warrant for multiple invoices with different pay dates. Critical S-Standard
5.112 System should have the ability to select or not to select vendors for payment by due date. Critical S-Standard
System should have the ability to input an invoice in the system with two steps validation. System should have the ability to input an invoice in the system
5.113 without a receiver in the system. Critical S-Standard
5.114 System should have ability to sort report by vendor, by amount or provide year-to-date vendor information. Critical S-Standard
5.115 System should have ability to perform electronic matching of purchase orders, goods receipt reports and vendor invoices i.e. three way reconciliation. Critical S-Standard
5.116 System should have ability of taking decision to keep purchase order open or close purchase order. Critical S-Standard
5.117 System should have ability to process travel vouchers automatically with electronic approval. Critical S-Standard
5.118 System should have ability to allow for inputting multiple addresses for each vendor. Critical S-Standard
5.119 System should have ability to provide for the establishment of discount and payment terms for each vendor. Critical S-Standard
5.12 System should have ability to allow for invoice data to be processed on-line. Critical S-Standard
System should have ability to automatically retrieve vendor name, vendor address, goods ordered, goods received and unit prices based on purchase order
5.121 number. Critical S-Standard
5.122 System should have ability to automatically calculate applicable discounts and payment date. Critical S-Standard
5.123 System should have ability to allow for the addition of freight and bulk charges. Critical S-Standard
5.124 System should have ability to calculate multiple taxes as appropriate by item. Critical S-Standard
5.125 System should have ability to calculate tax rebates at the time of invoice entry. Critical S-Standard
5.126 System should have ability to provide automatic on-line budget account validation as well as funds availability. Critical S-Standard
5.127 System should have ability to automatically liquidate associated encumbrances as invoices are processed. Critical S-Standard
5.128 System should have ability to automatically calculate payment due date to take advantage of available discounts. Critical S-Standard
System should have ability to provide for the issuance of “on demand” checks that automatically update the General Ledger and liquidate associated
5.129 encumbrances. Critical S-Standard
5.13 System should have ability to automatically handle recurring payments. Critical S-Standard
System should have ability to provide document history retrieval on-line, linking requisitions, bids, purchase orders, stores issues, invoices, cheques, returned
5.131 goods and received goods. Critical S-Standard

5.132 System should have ability to prevent the entry of an invoice that would cause the cumulative invoiced amount to exceed the contract or purchase order value. Critical S-Standard
System should have ability to generate a report of open and closed vouchers basis all the defined parameters. System should have ability to generate a report of
5.133 open and closed vouchers based on user-criteria, such as daily or weekly time period, fund number or project code. Critical S-Standard
5.134 System should have ability to generate a complete on-line reports and hard copy reporting of accounts payable activity. Critical S-Standard
5.135 System should have ability to allow for on-line inquiry of all Accounts Payable based on vendor, branch, sub branch, schemes and department. Critical S-Standard
5.136 Ability to make adjustments to posted transactions in the system so that the transaction is affected in both accounts payable and general ledger. Critical S-Standard
6 Accounts Receivable Critical
6.1 System should have ability to maintain a master customer file. Critical S-Standard
6.2 System should have ability to access all customer and billing data on-line. Critical S-Standard
6.3 System should have ability to purge all paid invoices on file for a user-defined period. Critical S-Standard
6.4 System should have ability to activate/deactivate customers on request. Critical S-Standard
6.5 System should have ability to display the open item/balance forward status and aging for customer invoices. Critical S-Standard
6.6 System should have ability to enter invoices, credit/debit memo and payments individually Critical S-Standard
6.7 System should Automatically assign unique invoice numbers Critical S-Standard
6.8 System should allow user defined aging categories (e.g., current, 30,60,90 days) Critical S-Standard
6.9 System should have ability to generate delinquency letters for customers. Critical S-Standard
6.1 System should have ability to enter credit memos to update accounts receivable. Critical S-Standard
6.11 System should have ability to enter debit/credit memos on-line Individually Critical S-Standard
System should provide ability to produce refund cheques from accounts receivable which should be transferred to accounts payable automatically. This should
6.12 be done using the maker checker control. Critical S-Standard
6.13 System should allow the entry of negative credit memos (to act as internal adjustments). Critical S-Standard
6.14 System should automatically assign unique credit memo number. Critical S-Standard
6.15 System should have ability to print debit and credit memos on request. Critical S-Standard
6.16 System should allow partial billing of an invoice amount. Critical S-Standard
6.17 System should allow separate open receivables by customer, department, branch, sub branch and scheme for collections purposes. Critical S-Standard
6.18 System should maintain daily accounts receivable billing control total with supporting detail Critical S-Standard
System should generate an accounts receivable report containing opening balance, debit transactions, credit transactions and closing balance as on particular
6.19 date. Critical S-Standard
6.2 System should have ability to post cash receipts on-line. Critical S-Standard
6.21 System should have ability to apply a single cheque for multiple open items Critical S-Standard
6.22 Allow partial payments to be applied to specific invoice line items in a predetermined order, or designated at posting or to the invoice as a whole Critical S-Standard
6.23 System should have ability to receive cash for items other than invoices such as miscellaneous cash Critical S-Standard
6.24 System should process miscellaneous cash receipts through the cash receipts application Critical S-Standard
6.25 System should have ability to review on-line all customer accounts past due. Critical S-Standard
6.26 System should have capability to review activity for specified account on-line. Critical S-Standard
6.27 System should have capability to review customer aging and other statistics such as last payment date on-line. Critical S-Standard
System should have capability to maintain billing and payment history containing details of all invoices, adjustments and payments by customer for a user-
6.28 specified period of time. Critical S-Standard
6.29 System should have capability to record cash payments received and adjustments made by customer and related general ledger accounts. Critical S-Standard
System should have ability to generate general ledger distribution report Summarizing the distribution of accounts receivable general ledger transactions by
6.3 account and date. Critical S-Standard
6.31 System should have capability to generate all A/R reports containing account users wise entries. Critical S-Standard
The A/R report should be sorted numerically by receipt number (column 1), User number/ID number (Column. 2), description (Column 3), and amount
6.32 (Column 4) Critical S-Standard
Users should have ability to drill down on specific items when they display invoices for a specific customer, including:
• Invoices
• Credit Memos
• Debit Memos
6.33 • Outstanding Amount Critical S-Standard
System should have ability to post General Ledger/cash receipts, invoices and credit memos automatically. This should be done using the maker checker
6.34 control. Critical S-Standard
6.35 System should have ability to perform billing and posting to the accounts receivable account. Critical S-Standard
6.36 System should have ability to maintain customer billing and payment history. Critical S-Standard
6.37 System should have ability to maintain date and amount of last billing. Critical S-Standard
6.38 System should have ability to maintain date and amount of last payment. Critical S-Standard
6.39 System should have ability to mention year to date billing and payment amount. Critical S-Standard
System should have ability to generate Invoice containing invoice number, invoice date, invoice line items, customer name, contact details, organizations
service tax number, registered address, amount of invoice, payment due date, rate of interest if invoice not paid within due date, authorized personnel from
6.4 organization signing invoice and total amount of invoice. Critical S-Standard
6.41 System should track all maintenance activity in the master customer files. Critical S-Standard
6.42 System should support extended payment terms and automatically adjust aging analysis. Critical S-Standard
6.43 System should automatically generate tear-off remittance advice to be returned with the payment receipt acknowledgement. Critical S-Standard
6.44 System should Initiate cash posting by entering a customer number, customer name, partial customer, partial name or ledger code. Critical S-Standard
6.45 System should display all open customer invoices during receipt posting. Critical S-Standard
6.46 System should be able to generate active customer master list containing list of all active customers including name, address and telephone number. Critical S-Standard
6.47 System should allow cashier to enter easy user defined codes in place of full account codes. Critical S-Standard
6.48 System should allow processing of miscellaneous cash receipts. Critical S-Standard
6.49 System should allow printing of cash receipts. Critical S-Standard
6.5 System should allow automatic posting to appropriate subsidiary and general ledger accounts with maker checker control. Critical S-Standard
6.51 System should maintain GST information to facilitate automatic calculation of Service tax on each invoice Critical S-Standard
System should have ability to print invoices and/or statements in any desired order (i.e. Customer, alphabetical, zip code, payment due date and other terms as
6.52 per the need of the organization) Critical S-Standard
6.53 System should have ability to print accounts receivable statements by user defined criteria Critical S-Standard
6.54 System should have capability to print informational messages on invoices/statements. Critical S-Standard
6.55 System should suppress statements with zero and credit Balance. Critical S-Standard
6.56 Systems should have capability to maintain quantity details. Critical S-Standard
6.57 System should have capability to maintain customer wise TDS account. Critical S-Standard
6.58 System should have capability of running reports for user specified time. Critical S-Standard
6.59 System should have ability to restrict duplicate Invoice numbers or cash receipt numbers. Critical S-Standard
If payment is received in advance then system should accept payment in absence of invoice. However, on issuance of invoice the payment should be allocated to
6.6 that invoice. Critical S-Standard
6.61 System should have ability to set up multiple Accounts Receivable accounts. Each A/R account tracks one type of customer Critical S-Standard
6.62 System should have ability to generate aging reports which query for payments 30, 60, 90 days or as per user defined period. Critical S-Standard
6.63 System should have ability to provide complete on-line and hard copy reporting of accounts receivable activity and aging. Critical S-Standard
System should have ability to allow for on-line inquiry and hard copy reporting of all accounts receivable by branches, sub Branches, department, schemes and
6.64 Customers. Critical S-Standard
6.65 System should allow for setting different types of currency formats as per the needs of the users. Critical S-Standard
6.66 During cash receipt active cost center accounts should be displayed via a drop down menu. Critical S-Standard
6.67 System should not allow duplicate receipt numbers to be generated. Critical S-Standard
When A/R is posted there should be security associated with the user ID and capability of specifying business date. The user ID determines whether the person
6.68 has privileges to access Account receivable account for current year and prior years. Critical S-Standard
6.69 Ability to segregate the type of receivables- set up different rules to accommodate the different types of operations Critical S-Standard
6.7 System should have the ability to view the detail transaction of the A/R in General Ledger. Critical S-Standard
System should have ability to generate the following management & collection reports for tracking of loan activities:
• Account Summary
• Payment Summary
• Escrow Transaction
• Aging Report
6.71 • Past Due Notices Critical S-Standard
System should have ability to generate loan reminder notices for interest rate change or other change in terms and conditions of the loan at the time of updating
6.72 loan master. Critical S-Standard
6.73 System should have ability to process different invoice formats from the system to accommodate different program needs. Critical S-Standard

7 Cash and Bank Accounts Critical

7.1 System should have capability to integrate all cash, cheque and online transactions. Critical S-Standard
7.2 System should allow sorting of transactions by either type, date, amount, debit entries, credit entries and contra entries. Critical S-Standard
System should allow quick marking of transactions that have cleared the bank by allowing the selection of either single transactions or entire ranges of
7.3 transactions Critical S-Standard
7.4 System should have ability to receive an electronic data on cleared cheques from the bank to perform bank reconciliation. Critical S-Standard
7.5 System should receive automatic updates for each deposit made from the cash receipts subsystem. Critical S-Standard
System should provide on-screen reconciliation summary information, such as unreconciled bank balance, unreconciled book balance, difference, number of
7.6 cleared payments, cleared payments total, number of cleared deposits and cleared deposits total. Critical S-Standard
7.7 System should allow the reconciliation of multiple bank accounts at the same time. Critical S-Standard
7.8 System should allow to distinguish between the different types of cheques issued Critical S-Standard
7.9 System should allow the users to selectively view transactions by status, cheque date or other field data. Critical S-Standard
System should allow the posting of interest income and service charges to the General ledger account during reconciliation with appropriate maker checker
7.1 control. Critical S-Standard

7.11 System should allow Automatic matching of cancelled cheques from the bank statement to the system by cheque, amounts, cheque number and bank ID. Critical S-Standard
7.12 System should provide a report of unclaimed funds. Critical S-Standard

7.13 System should allow the users to query a group of records from the system and update them all simultaneously with a chosen event date (cancelled date). Critical S-Standard
System should have the ability to recognize cheques as stale cheques automatically based upon the difference in the amount of days between cheque issuance
7.14 and the current date. Critical S-Standard
7.15 System should have the ability to automatically reverse the payment or receipt entry for stalled cheques with appropriate maker checker control. Critical S-Standard

7.16 System should receive automatic updates for each cheque printed, reprinted, handwritten, void or reversed from the payroll or accounts Payable subsystems. Critical S-Standard
7.17 System should allow automatic upload of bank statements into the system Critical S-Standard
System should log all transactions related to any given document, such as Issue Date, Review Date, Stop Date, Cancel Date, Reverse Date and other relevant
7.18 information's. Critical S-Standard
7.19 System should raise an alarm when the cash balance goes beyond a minimum cash limit. Critical S-Standard
7.2 System should provide a cheque history by Vendor. Critical S-Standard
7.21 System must offer password secured access Critical S-Standard
7.22 System should have capability to provide audit trails for cash and bank transactions recorded. Critical S-Standard
7.23 System should provide a cheque listing by bank ID and cheque number Critical S-Standard
7.24 System should Provide a listing of deposits with details of information Critical S-Standard
7.25 System should provide a summary listing of withdraw and deposit information Critical S-Standard
7.26 System should provide a list of cancelled cheques Critical S-Standard
7.27 System should provide a history report on any given Document Critical S-Standard
7.28 System should provide a list of outstanding cheques Critical S-Standard
7.29 System should have ability to manually void or reconcile a series of cheques Critical S-Standard
System should raise a popup on the cash expense increasing the limit specified by Income Tax Act, 1961 and as per appropriate limit defined according to the
7.3 delegation power. Critical S-Standard
7.31 System should have the capability to raise an alarm on crossing an OD amount beyond a particular limit. Critical S-Standard
7.32 System should allow controlled direct update of cheque or deposit information. Critical S-Standard
Any employee from Finance team required to withdraw the cash from bank should raise a request on system and should be approved by authorized personnel
7.33 as per approval matrix. Once the request is approved then only cash should be withdrawn from bank. Critical S-Standard
7.34 System should allow for creation of an unlimited number of bank accounts and cash accounts Critical S-Standard
7.35 System should allow comparison of current years cash expenditure with previous years cash expenditure for similar period. Critical S-Standard
7.36 System should be capable of generating cash flow and fund flow statement. Critical S-Standard
7.37 System should print a report to Identify all gaps in the cheque sequence Critical S-Standard
7.38 Ability to perform reconciliation of voided, canceled and returned cheques on-line or in batch Critical S-Standard
7.39 System should automatically print a listing of printed cheques after each cheque printing cycle. This is a control list of cheques printed. Critical S-Standard
7.4 System should have ability to print a report showing the outstanding cheques Critical S-Standard
7.41 System should allow automatic posting of reconciliation adjustments to the general ledger with appropriate checker validation. Critical S-Standard
7.42 Ability to provide a completely automated bank reconciliation process including the matching of outstanding and cleared cheques with issued cheques. Critical S-Standard
7.43 System should allow automatically tracking of cash entries, cash on hand and provide cash receipt register and deposit reports for cash reconciliations Critical S-Standard
7.44 System should have the ability to track petty cash Critical S-Standard
7.45 System should have a capability to link bank ledger with the corresponding general ledger in accounting module for recording the bank transaction. Critical S-Standard
System should have the capability to reverse the accounting entries which are outstanding in bank reconciliation statement for more than organization specified
7.46 duration with the appropriate checker validation. Critical S-Standard

8 Fixed Asset Critical

8.1 The system should have the ability to provide for automatic calculation of depreciation and posting of entries to the General Ledger. Critical S-Standard
8.2 The system should have the ability to selectively post depreciation based on asset category, account, status or other field. Critical S-Standard
System should have the ability to allow depreciation to be calculated on either a monthly, quarterly, annual or defined periodic basis as per the requirement of
8.3 organization. Critical S-Standard
 System should have the option to depreciate asset on a variety of methods (straight line, Reducing Balance and other suitable method as per the requirement of
8.4 the organization.) Critical S-Standard
8.5 System should be capable of Computing depreciation expense for financial statement purposes and Income-Tax Purpose separately. Critical S-Standard
System should have option to do comparisons for different years depreciation such as comparing last year's depreciation with this year's depreciation for same
period, allow comparison on monthly/ quarterly/ Semi-Annually or defined time basis as per the requirement of organization and allow comparison on Year to
8.6 date basis) Critical S-Standard

8.7 Have the ability to provide the option of having depreciation data updating the general ledger or being stored in fixed assets for information purposes only. Critical S-Standard
8.8 Allow the assignment of primary classes to assets. (for reporting and inquiry) Critical S-Standard
8.9 Allow the assignment of secondary or tertiary classes to assets. (for sorting and inquiry) Critical S-Standard
8.1 System should allow both automatic and manual entry creation of an asset into the system Critical S-Standard
8.11 System should allow for maintenance/improvement adjustments to an asset for increasing the value and/or extend the useful life. Critical S-Standard
8.12 System should track the history of maintenance/improvement on an asset. Critical S-Standard

System should automatically recognize accounts that are related to capital expenditures. The purchases related to capital expenditure should automatically roll
8.13 over purchasing/accounts payable information into the fixed asset system. (Interface from Accounts Payable and Purchase order to Fixed Assets) Critical S-Standard
System should allow the creation of detailed retirement records in relation to an asset including sales price, disposal date, method of sale, vendor, address,
8.14 profit/loss on sale of Assets and other required information as per the needs of organization. Critical S-Standard
8.15 System should allow for tracking multiple funding sources related to one asset Critical S-Standard
8.16 System should allow for tracking multiple/split expense accounts related to the purchase of one asset Critical S-Standard
System should have ability to allow for the definition of user-defined categories/codes of fixed assets based on the branch, sub branch, products and
8.17 department. Critical S-Standard
8.18 System should have the ability to track the transfer of assets from one branch to other branch and all associated history related to transfer of assets. Critical S-Standard
8.19 System should have the ability to maintain detailed property or vehicle records for insurance purposes. Critical S-Standard
8.2 System should have the ability to maintain cost, insurance and replacement values. Critical S-Standard
8.21 System should have the ability to maintain detailed warranty records Critical S-Standard
8.22 System should allow the interface/integration of the system with other, independent asset management systems. Critical S-Standard
System should have the ability to automatically post the appropriate entries for all capital expenditure purchases to fixed asset accounts (with appropriate
8.23 entries based on whether they are a governmental or proprietary purchase) Critical S-Standard
System should have the ability to perform ad-hoc reporting on any field or feature within the fixed asset screens to produce depreciation reports, inventory
8.24 reports, Asset Purchase report, Asset Sale report, Profit/ Loss on sale of Assets. Critical S-Standard
System should allow for construction in progress (CIP) classification to accrue costs while the asset is still under construction, but exclude it from depreciation.
8.25 System should allow for capitalization of interest and other expenses up to the date of construction. Critical S-Standard
8.26 System should allow the association of an asset with an old asset number (in relation to a trade-in, retirement, theft, etc) Critical S-Standard
8.27 System should have the capability to link related assets together. Critical S-Standard
8.28 System should provide miscellaneous fields for user defined information. Critical S-Standard
System should provide sufficient location information fields such as building, department, room, room description, address, phone number and Asset Code
8.29 tagged to Asset. Critical S-Standard
System should allow tracking of information related to the purchase, such as contract number, purchase order number, bid number, cheque number, invoice
8.3 information, vendor and related general ledger account. Critical S-Standard
8.31 System should allow the association of an asset with a responsible person, such as a custodian Critical S-Standard
8.32 System should provide a notes section to allow free form text entry. Critical S-Standard
8.33 System should allow the attachment of an image to each asset. Critical S-Standard
8.34 System should allow the user to copy asset information from another, pre-existing asset. Critical S-Standard
System should have a capability to Interface the Fixed Asset account with receiving department so that property management will know when an asset has been
8.35 received and is ready for tagging. Critical S-Standard
8.36 System should have the ability to compare actual fixed asset expenditures versus budgeted amount comparisons and also support the variance analysis. Critical S-Standard
System should generate physical inventory reports by branch, sub branch, cost center, employee name or number, custodian name or number, asset type, asset
8.37 class and asset category. Critical S-Standard
System should have the capability to generate Inventory reports containing opening balance, additions, deletions, depreciation and closing balance during the
8.38 year. Critical S-Standard
8.39 System should provide history of assets by custodian or location. Critical S-Standard
8.4 System should have a barcode capability with Physical Inventory input. Critical S-Standard
8.41 System should have an adequate asset description along with purpose of acquisition of asset. Critical S-Standard
8.42 Separate field for Serial Number, Manufacturer and other identifiable marks Critical S-Standard
8.43 System should have ability to export information to Excel, PDF and other desired format as per the needs of the organization. Critical S-Standard
8.44 System should have the capability to generate Fixed Asset schedule as per revised schedule VI of Companies Act, 2013. Critical S-Standard
8.45 System should have the capability to amortize the cost incurred for Fixed asset as per the requirement of the users. Critical S-Standard
8.46 System should have the capability to label the asset as per the Asset code generated from the system. Critical S-Standard
8.47 Asset code should be generated from the system and manual entry should be avoided to prevent duplication and errors. Critical S-Standard
Fixed Asset module should consider the effect of applicable accounting standards requirement as per Institute of chartered Accountants of India, requirements
8.48 of companies Act 2013 and Income Tax Act, 1961. Critical S-Standard

9 Financial Reporting Critical

9.1 System should have ability to provide real time reporting and inquiry. Critical S-Standard
System should provide Standard Financial Statements, Financial statements as per revised schedule III of the companies Act, 2013, cost center expense reports,
9.2 revenue reports, Account Detail/ Ledger Account Report, trial balance, cash expense report, Budget reports. Critical S-Standard
The solution should also cover all the financial entries passed which should give the output as per Ind AS and IGAAP and should have capability to provide
Financial statements as per Indian Accounting standards(Ind AS) and IGAAP. System should also be capable of IFRS requirements and any other requirements
9.3 that may come out during adoption of IFRS standards in India in future or any other standards presented by Government of India. Critical S-Standard

9.4 System should have ability to generate report for any selected time period (monthly, quarterly, multi-year, prior year or as per the defined time frame of user) Critical S-Standard
9.5 System should have capability to set-up the format of the report Critical S-Standard
9.6 System should have capability to specify subtotal and total lines Critical S-Standard
9.7 System should have capability to Customize headings, columns and rows Critical S-Standard
9.8 System should have capability to Set-up prompts for request report parameters from user Critical S-Standard
9.9 System should have capability to roll up the report by cost center, division, group, branch, sub branch and Schemes. Critical S-Standard
9.1 System should have capability to set-up analysis/variance reporting Critical S-Standard
9.11 System should have capability to provide statistical reports in diagram form like, Bars, graphs, charts pie diagram and other available formats. Critical S-Standard
9.12 System should have capability to generate comparative balance sheets, extract balances for multiple years Critical S-Standard
9.13 System should have capability to perform calculations on columns such as adding or subtracting columns and print account descriptions. Critical S-Standard
9.14 System should modify standard reports easily through drag and drop down window Critical S-Standard
9.15 System should Capture detailed statistical data Critical S-Standard
System should have Automated interfaces between General ledger accounts, Profit Loss Account, Balance sheet, budget module, Cash Flow and Fund Flow
9.16 Statement with report module and Borrowings and Investments modules. Critical S-Standard
9.17 System should have flexible reporting capabilities as per the requirement of the organization. Critical S-Standard
9.18 System should have capabilities to generate report in user-defined output formats like Lotus, Excel, PDF, Word, dbase, text or print image. Critical S-Standard
9.19 System should have comprehensive Ad-Hoc Report Writer Critical S-Standard
System should have ability to queue/schedule multiple reports in a queue for automatic printing with user-defined folders to help organize reports by typical
9.2 generation time (weekly, monthly, yearly) Critical S-Standard
System should have capability to provide for interactive file interface for downloading and uploading of data while maintaining security controls and data
9.21 integrity. Download information and reports to standard personal computer formats. Critical S-Standard
9.22 System should have capability to sort data in user-specified orders. Critical S-Standard
9.23 System should Process complex selection criteria utilizing operators, Boolean connectors and/or multiple data files across system boundaries. Critical S-Standard
9.24 System should have ability to move reports to a standard word format, PDF Format and/or Excel format. Critical S-Standard
9.25 System should copy standard reports over to user libraries and make specified changes to them without altering the original report. Critical S-Standard

9.26 Design a report based on user-defined criteria (For Eg: sort sequenced data elements, calculations, print formats and other specified requirement by user) Critical S-Standard
9.27 System should provide for user determined reports and processing of batch update jobs as part of an automatic job schedule. Critical S-Standard
9.28 System should provide report accuracy such that all reports provide summary totals and cross-foot regardless of rounding factors. Critical S-Standard
9.29 Define data extraction routines that create separate data files that can later be used by other report writer programs to create reports Critical S-Standard
9.3 Keep detailed transaction history for at least 5 years or more depending on organizations requirement. Critical S-Standard
9.31 System should have ability to monitor cost centers and accounts that are overspent (Frequency – Daily alert) Critical S-Standard
9.32 System should have a customized report writer that incorporates logic/statistical functions within the application, such as “if” and “then” functions. Critical S-Standard
9.33 System should not allow to change any elements of data at the report generation screen. Critical S-Standard
 9.34 System should be able to generate the reports based on parameters defined in Master data. Critical S-Standard
9.35 System should be able to generate the report as per the parameter defined by user. Critical S-Standard
9.36 System should be able to create Daily Funds Statement with information on cash inflows and cash outflows. Critical S-Standard

10 Profitability Workflow Critical

Branch Wise Profitability
10.1 System should have capability to define zone, region, branch or sub branch as separate profit center. Critical S-Standard
10.2 System should have capability to allocate total management fees among the branches, cluster and RO. Critical S-Standard
10.3 System should have capability to automatically incorporate the details received from branch and cluster for the profitability report Critical S-Standard
10.4 System should have capability of allocating directly identifiable expense to respective branches and department of RO Critical S-Standard
10.5 System should have capability of allocating direct employee cost to respective branches and departments of RO based on actual cost. Critical S-Standard

System should have capability of allocating Indirect expenses such as staff welfare expenses, gratuity, provision for leave encashment and other indirect expense
10.6 to various branches and departments on the basis of their direct staff cost/Number of employees as per the requirement of organization. Critical S-Standard
System should have capability of allocating incentive expense for current year to respective branches in proportion of previous years branch wise and RO wise
10.7 incentive expenses. Critical S-Standard
10.8 System should have capability to allocate actual branch expenses to respective branches and sub branches. Critical S-Standard
10.9 System should have capability to allocate rent expense to respective branches and sub branches on actual basis. Critical S-Standard
10.1 System should have capability to allocate rent and electricity expense at RO based on number of employees in each department. Critical S-Standard
10.11 System should have capability to define cost centers based on departments. Critical S-Standard
10.12 System should have capability to define sub cost centers based on services within the department. Critical S-Standard
System should have capability of allocating customer service department cost including call center expenses to respective branches and sub branches on the
10.13 basis of number of folios at each branches. Critical S-Standard
System should have capability of allocating Services Department (Such as Accounts & Admin, IT, HRD & MD / CEO's Secretariat) cost is allocated to various
10.14 branches/other departments on the basis of number of employees. Critical S-Standard
System should have capability of allocating expenses related to risk management, compliance and Internal Audit to Debt Investment Expense, Equity
10.15 Investment Expense, operations expense and PMS Retail expense in the desired ratio. Critical S-Standard
10.16 System should have capability of allocating operations department expense to different branches and sub branches. Critical S-Standard
10.17 System should have capability of allocating marketing expense to various branches based on actual funds mobilized. Critical S-Standard
10.18 Expense specific to a particular scheme should be directly allocated to branch or sub branch to which it belongs. Critical S-Standard
10.19 Based on above calculations system should be able to generate region wise, branch wise and Sub Branch wise profitability report. Critical S-Standard
10.2 System should have capability to generate region wise management fee and other respective expense report. Critical S-Standard
10.21 System should have capability to generate zone wise, region wise, branch wise and sub branch wise share. Critical S-Standard
10.22 System should have capability to generate region wise total Income and Expense report. Critical S-Standard
10.23 System should have capability to consider only management fees while doing profitability analysis. Critical S-Standard
10.24 System should have capability of allocating brokerage expense to the branch based on gross inflow of particular scheme in that branch. Critical S-Standard

Scheme Wise Profitability

10.3 System should have capability to allocate product related expenses directly to the product. Critical S-Standard
10.31 System should have capability to allocate management fees to particular product based on details received from Fund Accountants. Critical S-Standard

System should have the capability to allocate cost of customer services department including call center expenses and cost of operation department to various
10.32 product on the basis of live folios of each schemes. For redeemed schemes the cost should be allocated base on folios as at the date of maturity of schemes. Critical S-Standard

10.33 System should have the capability to allocate part of the direct expenses to schemes. Remaining of the expenses on the basis of number of folios in each scheme. Critical S-Standard
HO expenses allocated to branches and sub branches above in branch wise profitability are further allocated to schemes on the basis of management fees
10.34 received from particular schemes in that branch. Critical S-Standard
Channel-wise Profitability
System should have the capability of allocating expenses Sales channel-wise. The system should differentiate between direct business and business routed
10.37 through various types of distributors, if CFHL adopts different channels. Desirable S-Standard

11 Fixed Asset Management Critical

The system should be able to record the details of the fixed asset purchased.
The system should have the capability to create a Fixed Asset Master to determine the parameters related to Fixed Asset. This included:
- Asset Category - Machinery/Equipment/Furniture/Electronics etc
- Asset Type - Under each asset category, there is a corresponding asset type. (For eg: Cupboard under Furniture, Laptop under Electronics etc.)
- Depreciation - Depreciation rates to be defined as per the depreciation master file.
- GST/TDS - Tax category and tax code applicable on the Fixed asset should be defined in the system.
- Capitalization Rate - System to parameterize capitalization for each asset type and category.
The details of the Fixed asset shall include:
-Fixed Asset ID
-Fixed Asset Category
-Fixed Asset purchase date
-Fixed Asset Amount
-GST bifurcation - CGST/IGST and SGST/UTGST
-Fixed Assed Vendor ID
-Invoice number Critical
- Invoice Date
-Fixed Asset depreciation
-Fixed Asset Capitalization
-Fixed asset impairment
- The system should have the capability to record and calculate the capitalization of the asset.
- The system should have the capability to record and calculate the depreciation on the fixed asset.
- If CGST is given, IGST field should be disabled, and only input in SGST field or UTGST field should be allowed. If case SGST is given, UGST field should be
disabled and if UTGST is given, SGST field should be disabled. And in case, IGST is given, rest all fields should be disabled.
- Facility for the transfer of asset from one branch to another and accounting entries with respect to the same must be captured.
- Facility to upload and manage the invoice as attachments.

11.1 S-Standard
Asset Discovery:
Solution should be able to have Information for the Assets (IT & Non-IT) and their removable/replaceable components.
The solution should have the abilities to assign unique "Asset Code" like identity to all the assets identified by the CFHL in the target
11.2 state. S-Standard
Asset Onboarding:
The solution should be able to provide a framework to on-board the asset.
On-boarding criteria like (but not limited to) availability of proper PO, scanned invoice, availability of AMC/warranty documentation
11.3 must be defined in agreement with CFHL wherever it is applicable S-Standard
Asset Tagging:
-Solution should be able to generate "Asset Codes" for the Assets (IT & Non-IT). All the assets before handing over to the department/an individual should be
assigned with a unique asset code. Same should be pasted on the asset.
11.4 -Assets can be mapped to an office/branch location for better traceability S-Standard
Asset Inventory:
-Solution should be capable of generating inventory details for all the Assets (IT & Non-IT) inside the CFHL’s environment.
-All the removable components/parts under warranty should be tagged in the system
-Asset Tracking: Solution should be capable to identify and track change in the location of assets, increase or decrease the number of assets, track assignment
status and user information. Asset management to be managed and maintained by CFHL Admin team
11.5 -Solution should have reporting functionalities in the formats like Excel/pdf (but not limited to) as and when required by the CFHL Team S-Standard
 Contract Management

CFHL may purchase Assets (IT & Non-IT) by entering into contracts with multiple service providers. The solution should be able to manage such contracts by
providing the following facilities :

-Contract Creation for all onboarded Assets (IT & Non-IT). Contract Creation maybe at the time of onboarding or at a later date
-Contract Creation may include upload of details & documents of Service Level Agreement & CFHL Guarantees.
-Contract tracking by providing alerts and triggers regarding completion of contracts/ renewals due.
-Online maintenance of Contract Documents

11.6 Contract management of assets is to be with CFHL admin department S-Standard

Asset Life Cycle Management:
The solution shall provide for life cycle management for the Assets (IT & Non-IT). The solution shall track the life cycle through Purchase, End of Life and
Disposal stages of the Assets (IT & Non-IT). Solution shall provide alerts for each stage of any such non-IT Asset Capitalization and depreciation to be
considered for all the assets by CFHL admin team
Capitalization/depreciation/Impairment/Purchase/Sale of the asset calculation and entries to be maintained in the solution and integrated with the F&A
11.7 solution S-Standard

12 Annual Maintenance Contract Critical

AMC to be captured and warranty details to be captured
Details captured
- Fixed Asset ID
- AMC Vendor details - In case the AMC vendor is same as the purchase vendor - Vendor ID is sufficient to capture the details
- AMC start date
- AMC end date
- AMC amount
The AMC and warranty related details to be accessed by both RO and branch
12.1 Critical S-Standard

13 Fixed Asset Accounting Critical

- The Accounting module should be integrated with the Fixed Asset Module to pass automatic entries with respect to fixed asset.
- The system should be able to post entries with respect to purchase of fixed asset and sale of fixed asset.
- the system should be able automatically post entries with respect to capitalization of the asset and impairment of the asset.
The system should be able to post entries with respect to the depreciation of the asset.
13.1 Critical S-Standard

14 Rent Module Critical

 - Facility to maintain a module for the purpose of premise rent. The module will look into the following:
Branch ID
Branch Address
Lease Rent Amount
Rent Payment Date
Lease Start Date
Lease End Date
Lease Rent Agreement
Owner Details
Owner's ID proof
Rent Increment
Rent Increment Date
GST component and bifurcation
14.1 Bank details of the owner
- The system should have the capability to attach lease contract.
- Facility to trigger alerts/ notification when the lease is about to expire - 3 months
- Facility to trigger alert for rent increment - 1 month
- Integration with the account module for the payment of lease premise rent.
- The system should be able to automatically post entries when rent is paid.
- Facility for the GST component - If CGST is given, IGST field should be disabled, and only input in SGST field or UTGST field should be allowed. If case SGST
is given, UGST field should be disabled and if UTGST is given, SGST field should be disabled. And in case, IGST is given, rest all fields should be disabled.
- The system should be able to generate reports for the rent amount.

Critical S-Standard
Facility to maintain staff quarters rent details in the rent module and its integration with the HRMS module. The staff quarters rent information should
include:
- Employee ID - The employee opted for staff quarters rent
- Employee Name
- Rent Amount
- Location
- Payment Date
- Employee Salary
14.2 Facility to maintain the details of the rent reimbursement in case of employee is relocated and its integration with the HRMS system.
- In case of owned premises, the following details should be checked:
Employee ID
Employee Name and Designation
Employee Branch/RO
Tax Payable
Address details of the owned premise

Critical
S-Standard
15 Phone Bills Critical
Landline and SIM card is provided to each branch and the bill is paid by CanFIn
Details of the mobile number and landline number should be linked to each branch along with the user ID
15.1 The bill amount along with the billing days to be captured in the system.
The system should be able to calculate the amount in case of transfer of the branch incharge in between of the month. Critical S-Standard

16 Vehicle Insurance Critical

- The system should be able to record vehicle insurance detail of the branches. The branches should record the vehicle insurance details.
- The system should allow RO to approve these expenses.
- Integration with the accounting module for the payment of vehicle insurance.
16.1 - Facility to automatically generate vouchers for insurance expense and send it to the accounting module for approval and automatic posting of such entries.
- Facility to trigger alerts/notification to the branches when the vehicle insurance premium date is approaching.
- Facility to generate report of the branches yet to pay the vehicle insurance.
- Facility to generate reports for the vehicle insurance paid.
Critical S-Standard
nly these columns with your responses

Bidder Clarifications / Comments

What if?
SAC

Check

bpc
No of entity

GST filing
Bank integ
Cash management
Vendor master

Check, HCM module

Check
Borrowings & Investment
Sheet 7: Borrowing and Investment

Response
S
A
C
U

Id

11
11.1
11.2
11.3

11.4
11.5

11.6
11.7
11.8

11.9
11.10

11.11

11.12

11.13

11.14

11.15
11.16

11.17
11.18
11.19
11.20
11.21
11.22
11.23

11.24

11.25

11.26
11.27

11.28
11.29
11.30
11.31

11.32

11.33

11.34

11.35

11.36

11.37
11.38

11.39
11.40
11.41
11.42
11.43
11.44

11.45
ings & Investment
Borrowing and Investment

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Investment & Borrowings

Master Data
System should be able to create the borrowings and investment master data containing below mentioned fi
Institute Name - The institute name shall be maintained in the master since some of the institute like NHB.
Nature/type of investment or borrowing - The types of loans borrowed by CanFin and the investments made by CanFin shall
system.
Borrowing - Loan/NCD/CP. Type of loan - NHB loan, bank loan, NBFC loan etc
Tenure of securities - Monthly/Quarterly/Yearly etc shall be maintained in the master
Person responsible for Investments & Borrowings.(Custodian).
ALCO committee will be the custodian for the Investments and borrowings.
Applicable GL codes against borrowings and investments shall be maintained in the system
Borrowings

The system should have the ability to store and configure the following information with respect to the Borrowing applicatio
- Borrowing Instrument - The details of the asset borrowed which includes - Commercial Papers , NCD and Term Loans. Und
are three types of loans- 1. NHB Loans, 2. Banks loans 3. Loans from NBFC
- Institute name
- Interest rate
- Date of Sanction
- Sanctioned Amount
- Interest to be paid
- Disbursement Amount 1 - To be a multi value field in case the sanctioned amount is disbursed in tranches.
- Date of disbursement 1
- RoI of disbursement 1
- Date of Maturity disbursement 1
- Interest Reset Rate 1
- Interest Reset Date 1
- Interest to be paid 1
- Principal to be paid 1
- Interest Payment date 1
- Interest Payment frequency 1 - Monthly/quarterly/half yearly/yearly
- Interest payment due date 1
- Repayment schedule 1 - Monthly/quarterly/half yearly/yearly
- Monthly provision expense 1 - provision expense related to current month which is due in the next month.
- Prepayment
- Adverse Balance Payment - ONLY IN CASE OF NHB
- Secured/Unsecured - Facility to provide an option if the given loan is secured or unsecured,
For CPs, the following information should be recorded:
Amount
Date of issue
Interest Rate
Date of Issue
Maturity date
Total Period for CP
Interest Payment frequency - Monthly/quarterly/half yearly/yearly
Interest payment due date
Repayment schedule 1 - Monthly/quarterly/half yearly/yearly
Monthly provision expense 1 - provision expense related to current month which is due in the next month.
Prepayment
Commercial papers are unsecured, so it should be noted that no security must be attached to the same. The system shall rais
the same.
System should be able to capture initial subscribers for each CP issue.
System should have the capability to capture CP issued amount and maturity amount.
The system should be able to calculate interest on the issued value till the maturity.

For NCDs, the following information should be recorded:

Amount Decided to raise
Amount Received
Interest
Date of Issue
Date of Maturity
Security Attached
Interest Payment frequency - Monthly/quarterly/half yearly/yearly
Interest payment due date
Repayment schedule 1 - Monthly/quarterly/half yearly/yearly
Monthly provision expense 1 - provision expense related to current month which is due in the next month.
Prepayment
System should have the capability to raise appropriate warnings in case NPA has been attached as a security.
System should be able to secure NCDs using the security(loans) plus the accrued interest.
System should be able to capture initial subscribers for each NCD issue

The system should be able to attach the securities. The system should allow standard security(Canfin loans) to be attached to
Facility to define the securities(Canfin loans) on the basis of the borrowing category - Bank Loan/ NHB/NCD.
The system should be able to mark the securities, that is, each loan given by Can Fin homes to be assigned/marked to partic
loan/NCD/NHB

Facility for maker checker control for the borrowing process to ensure stringent control and reducing chances of collusion/ f
incorrect data entry.
The system should be able to highlight in case an NPA/SMA3(Canfin loan) is attached as a security and an option should be
user to remove the NPA or not.
- The system should be able to configure the 9-digit loan account number provided by NHB for the purpose of security(Canfi
- Adverse Balance = Loan O/S- Security amount - NPA = ONLY IN CASE OF NHB
- The system should also include Adverse margin in case of NHB.

Facility to change/replace the securities(Canfin loans) in case the status of such security(Canfin loan) becomes NPA/SMA3.
-The system should be able to calculate Interest Spread = Yield - Weighted Cost of Funds

- The system should be able calculate TDS on the Interest and deduct the same while paying.
- The system should be able to filter out the priority sector lendings - to be attached as a security.'
- Facility to add filtering mechanism basis which securities(Canfin loans) with certain conditions can be linked as a security t
In case of NCD, securities(Canfin loans) should include O/S loan amount + accrued interest.
Trigger alert for cases where the securities amount is less than the O/S amount.
Alerts/notifications/ reminders to be triggered by the system to intimate the business user regarding the interest to be paid b

1. Reports to be generated for the borrowings.

The system should have the capability to generate reports as per the user requirements, The user should be able to filter out
generate the report as per their needs. For eg: If only the Institute and the amount of borrowing is required, appropriate rep
2. Repayment schedule for each borrowing.
3. Reports for the security linked to these borrowings along with the security details.

Entries to be posted from the system once the borrowing takes place and interest payment has been done. These entries shou
expense, Principal Payment, Bank charges entry(SMS, RTGS etc.), prepayment.
Appropriate maker checker concept shall be applicable on posting of these entries.
The facility to define the interest rate type:
- Fixed Interest Rate
- Floating Interest Rate
- Fixed for first "X" months and Floating for remaining tenor
Interest calculation method shall be configurable as per the business rules prevailing in CanFin. Eg: Actual/360 or 30/365 e
System should have Automated interfaces between General ledger accounts, Profit Loss Account, Balance sheet, Cash Flow a
with report module.
System should have the capability to upload all types of supporting document for Commercial Papers, bank loans, NHB, NCD
System should be integrated with Document management system to safeguard all the borrowing documents
Investments

The system should have the ability to store and configure the information regarding the investment:
- Instrument - The details of the investment instrument - 1. Govt Bonds - State & Central 2. Bank Deposit. Under Bank depo
Fixed deposit and KD(Kamadhenu deposit)
- Institute name
- Interest rate
- Renewal of deposit & Change in Interest rate - only in case of bank deposit
- Date of approval
- Date of investment
- Date of Maturity
- Investment Amount
- Interest to be received
- Interest Received date -
- Interest received frequency - Monthly/quarterly/half yearly/yearly
- Monthly provision income - provision income related to current month which is due in the next month.
Facility to maintain the investment documents in the system.

Facility for maker checker control for the investment process to ensure stringent control and reducing chances of collusion/
incorrect data entry.

Alerts/notifications/ reminders to be triggered by the system to intimate the business user regarding the interest to be receiv

1. Reports to be generated for the investments

The system should have the capability to generate reports as per the user requirements, The user should be able to filter out
generate the report as per their needs.

Entries to be posted automatically from the system once the investment takes place and interest received. These entries shou
income.
The facility to define the interest rate type:
- Fixed Interest Rate
- Floating Interest Rate
- Fixed for first "X" months and Floating for remaining tenor
Interest calculation method shall be configurable as per the business rules prevailing in CanFin. Eg: Actual/360 or 30/365 e
System should have Automated interfaces between General ledger accounts, Profit Loss Account, Balance sheet, Cash Flow a
with report module.
System should provide investment and FD yield on year to date basis.
System should be integrated with Document management system to safeguard all the investment documents
Interest Spread
The system should have the capability to calculate the interest spread - Yield on Investment+Yield on Funds - Cost of Funds
Interest Spread to be calculated on monthly basis
The system shall generate Interest spread report for each borrowing, investment and loans and advances. This report shall b
borrowing with the institute name, interest rate, outstanding amount, number of days, weighted rate.
Index

Bidder Bidder
Importa
Response Clarifications /
nce
(S/A/C/U) Comments
Critical
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical
S-Standard
Critical S-Standard

Critical
S-Standard
Critical S-Standard
Critical S-Standard

Critical

S-Standard
Critical

S-Standard

Critical

S-Standard

Critical

S-Standard
Critical
S-Standard
Critical
S-Standard

Critical
S-Standard
Critical S-Standard
Critical
S-Standard Check
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical
S-Standard

Critical

S-Standard

Critical
S-Standard

Critical
S-Standard
Critical S-Standard
Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical

S-Standard
Critical
S-Standard
Critical
S-Standard

Critical
S-Standard
Critical
S-Standard

Critical
S-Standard
Critical S-Standard

Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard Portfolio analyzer
Critical S-Standard
Critical S-Standard
Critical
S-Standard
Risk & ALM
Sheet 8: Risk and ALM

Response
S
A
C
U

Id

1.1

1.2
1.3

1.4
1.5
1.6

1.7

1.8

1.9
1.1

1.11
1.12
1.13
1.14
1.15

1.16
1.17
1.18
1.19

1.2

1.21
1.22
 1.23
1.24
1.25
1.26
1.27
1.28
1.29
1.3
1.31
1.32

1.33
 
2
2.1
2.2

2.3
2.4

2.5
 2.6
2.7
2.8
2.9
2.1
2.11
2.12

2.13
2.14
 
3
3.1
3.2
3.3
3.4

3.5

3.6

3.7
 
4

4.1
4.2

4.3
 4.4
4.5

4.6

4.7
4.8
 
5
5.1
5.2
5.3
5.4
5.5
5.6
5.7

6.1
 6.2
6.3

6.4
6.5

6.6
6.7

6.8
6.9
6.1

7.1

7.2
 
8
8.1
8.2

9
9.1
9.2

9.3

10
10.1
10.2
10.3

10.4
10.5
10.6
10.7
10.8

10.9

10.11

11
11.1
11.2
eet 8: Risk and ALM

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

ALM
- The system should be able to prepare ALM statements which include:
1. Structural Liquidity Statement - 8 times, quarter end and a month before quarter
2. Interest Rate Risk Statement
3. Short Term Dynamic Liability Statement
- The system should be able to generate IRS and SLS on end of every quarter and a month before quarter end.
IRS
The system should be able to calculate the IRS automatically. The Interest Rate Risk statement consist of the total inflow and ou
for which the interest rate will be reset on a given date and the outstanding amount of such inflows and outflows are classified u
different date buckets.
The system should be able fetch the outstanding amount of the borrowing - outflows and loans and advances - inflows.
- The system should be able to fetch the reset date for borrowings - outflows and loans and advances - inflows.
- The system should be able to define the bucket under which the outstanding amount (borrowings) outflows and investments -
inflows will be put.
- The bucket will include the futuristic dates in the following manner:
*O/S amount from 1st to 7th of the month
*O/S amount from 14th to 21st of the month
*O/S amount from 21st to 28th of the month and so on.

- The system should be able to filter the outstanding amount (borrowings and investments ) as per bucket according to the rese
- Tolerance Limit bucket wise to be defined by the user
- The system should be able to calculate the sum of bucketed outstanding loan amount as per each bucket- total inflow and total
outflow.
- Facility for IRS percentage - Interest rate sensitivity and Average Interest Rate
- The system should be able to report mismatch in the IRS - difference between inflow and outflow
- The system should also be able to calculate the mismatch percentage - mismatch amount divided by total outflow.
SLS
The system should be able to calculate the SLS automatically. The SLS is similar the IRS wherein the interest reset date is captu
and instead of outstanding amount for borrowings, the EMI(Principal + interest) is taken.
- Tolerance Limit bucket wise to be defined by the user
- The system should be able fetch the outflows and inflows.
- The system should be able to fetch the reset date for borrowings - outflows and loans and advances - inflows.
- The system should be able to define the bucket under which the borrowings and advances - outflows and investments - inflows
be put.
- The bucket will include the futuristic dates in the following manner:
*O/S amount from 1st to 7th of the month
*O/S amount from 14th to 21st of the month
*O/S amount from 21st to 28th of the month and so on.
- The system should be able to filter the EMI amount (borrowings ) as per bucket according to the reset date.
- The system should be able to calculate the sum of bucketed outstanding loan amount as per each bucket- total inflow and total
outflow.
- The system should be able to report mismatch in the SLS - difference between inflow and out
- The system should also be able to calculate the mismatch percentage - mismatch amount divided by total outflow.
STDL calculation
- The system should be able to calculate the STDL automatically.
- The System should only consider live loan account while calculating STDL.
- It should be able to fetch the increase in loans and advances for calculating the STDL.
- The system should be able filter the live accounts as per the bucket dates.
- The system should be able to calculate the total of inflows and outflows.
- The system should be able to calculate the mismatch and mismatch percentage using the inflows and outflows
The system shall have the capability to forecast other outflow expenses and Net Cash position(inflow)on the basis of past 2 years
using the Forecasting tool. This shall be forecasted for the next 6 months

Stress Testing
- The system should be able to prepare stress testing framework every quarter.
- - The system should be able to provide probable scenario for the purpose of stress testing.

- The following impacts need to be checked for the purpose of stress testing:
•Impact of Increase in NPA on profit and CAR
•Impact of Increase in NPA and simultaneous increase in Provisioning requirements
•Impact of Collateral Depletion
•Impact of Increase in total NPA downgraded to Loss category
•Impact of 10%, 15%, 20% downgrade shift in the Performing Assets to Sub-Standard Assets
-Impact of 10%, 20% and 30% downgrade shift in the Restructured asset to substandard asset.
Note: The system should have the provision to change the percentage as per the business user needs
•Impact of Increase in Defaults in different regions - to be provided by user.
1. Impact of increase Default in NCR 1 region
2. Impact of increase in default in NCR 2 region
3. Impact of increase in default in UP and MP region. The system should have the provision to change the region as per the busin
user needs.
•Impact of top 10 borrower (having highest exposure) defaulting on his/her loans.
•Impact of top 20 borrowers (having highest exposure) defaulting on his/her loans.
•Impact of top 30 borrowers (having highest exposure) defaulting on his/her loans.
•Impact of 10%, 20% and 30% shock on Collection Efficiency for the last month of the quarter - Collection Efficiency on the basi
Customer type(Salaried, SENP(Business and professional))
2. Risk Rating - S1, S2-S2+, S3+ S4(S4 was used earlier and some customers still fall under this category)
3. SMA0, SMA1, SMA2, SMA3
-- The system should be able to fetch information from different departments like Planning and Development, Collections, Finan
and Accounts for the purpose of stress testing.
- The system should be able to apply the following scenarios - 1) Baseline 2) Medium 3) Severe based on the impact assessed.
- The system should be able to do a comparative analysis between different quarters based on CAR and Profit (in absolute terms
Percentage terms) (Input can be the different Scenarios each quarter) can be provided.
Liquidity Stress Testing

The system should be able to calculate the position of LCR based on various factor.
This includes:
1. Decrease in Inflow weightage from 75% to 60%
2. Increase in Outflows weightage from 115% to 125%
3. Impact of 15%, 20% and 30% decrease in HQLA depletion
4. Impact of 20%, 30% and 40% runoff of Deposit
5. Impact of 20%, 30% and 40% of Un availed runoff.
The system should be capable of combining all the above
Simulation and Scenario Analysis - The system should be able to simulate possible scenarios to analyze the risk of a
decision/consequence/external factors.
Definition of external factors(Eg: Repo Rate changes) to be defined by the business user.
The system should be able to assess the impact of external factors, for eg; Repo Rate on the CanFin Assets.
IIR Stress Testing: The system should be able to check the impact of increase/decrease in interest rate.
Stress Test for Interest Rate Risk
Impact of 1%, 2% and 4% downward shift in Interest Rates across all time buckets for both Assets and Liabilities
Impact of 1%, 2% and 4% upward shift in Interest Rates across all time buckets for both Assets and Liabilities
Upward and Downward shift in Interest rates for specific time buckets across all assets and liabilities
Non parallel upward shift in Interest Rates for specific time buckets across all assets and liabilities. Different Percentage change
Assets and Liabilities, that is, X% change in Assets and Y % change in Liabilities and vice versa.
The system should be flexible to change the above values as per the requirement of the business user.

LCR Calculation
- The system should be able to calculate Liquidity Coverage Ratio(LCR) on a daily basis
The system should be able to fetch the required data from different modules for LCR calculation
Facility to calculate the HQLA(High Quality Liquid assets) and trigger alert in case of HQLA breach.
Provision for FIMMDA(Fixed Income Money Market and Derivatives Association of India) rates to be provided.
- The system should be able to generate the LCR reports as per the requirements of the Risk team.
- The system should be able to forecast monthly /daily disbursement targe
The system should be able to forecast monthly /daily disbursement target
- The system should be able to fetch the cash inflows and outflows for the purpose of LCR calculation.

Loans & advances- Filter data from past month’s dump - accounts-live, restructured data- Blank and No, cycle date- remove blan
status column- only EMI, SMA, restructured amount and NPA- blank for all
• Un availed Limit- Bank borrowings, NHB is included if there in DFS
• Net cash outflow= Stressed outflow-min(75% of stressed outflow, stressed inflow)
• Min HQLA = 50% of net cash outflow
• Actual LCR= HQLA/net cash outflow for next 30 days

Re Risk Rating
- The system should be able to reflect the re risk rating basis the CIBIL score and other scores depending on the arrears and cheq
bounces. The customer can submit their request to the branches for reduced RoI under the floating rate loan scheme.
- Facility to provide for the re risk rating request by the customer in the system and the branch.
- In case the customer physically visits the branch to request for re risk rating, the branch in charge can apply at their level and
proceed with the further request to the RO Risk team.
- The re risk rating score should be based on the following three parameters -
1. Return of PDC’s/ECS
- No Return of PDC’s/Cheque
- Return of PDC/ECS less than 2 occasions in year
- More than 2 occasions and less than 5 occasion in year.
- More than 5 occasions
2. Repayment History
- No Arrears and prompt repayment
- SMA0: Arrears<=30
- SMA1: Arrear> 30 days & <= 60 days
- SMA2: Arrear> 60 days
- NPA
3.Perfection of security
- Perfection of security in all respect
- Perfection of security pending> 3 months & <=12 months
- Perfection of security pending > 12 months
Facility to provide approval workflow in the system itself.

Scoring for Re Risk Rating

Total Score = Customer Profile score + Project Profile score + Re risk rating parameter scores

- The system should be able to check if MINIMUM Interest Adjustment charges(IAC) has been debited from the loan account, an
basis that it should proceed with the approval process in the system itself. - BALANCE WAIVED OFF IAC to be checked as well.
- The system should give an alert to the branch in case of rejection by the Risk team/Credit for Re Risk rating application.

ALCO Report
The daily Funds Statement to be calculated by the system after proper approvals from the Accounts team.
The system should be able to calculate the mismatch which will be added in the ALCO report
For the purpose of ALCO report, the system should be able extract the Data from the Daily Funds Statement - DFS.
The system should be able to fetch all the inflows and outflows from DFS for the purpose adding it in the ALCO report.
The system should be able to fetch all the inflows and outflows from DFS for the purpose adding it in the ALCO report.
The system should be able to fetch the balancing OD account amount from DFS
The system should be able to provide unveiled limit for the purpose of calculating inflows and outflows from DFS.
 
Risk Profiling

Risk Rating for all types of Risk in CanFin:

1. Credit Risk
2. Market Risk
3. Operational Risk
4. Liquidity Risk
5. Earning Risk
6. Compliance risk
7. Capital Risk
8. Management Risk
The system should be able to define the type of risk - Low/Medium/High as per the Risk Rating matrix.
The Risk Rating matrix is as follows: Low Risk - up to 40%, Medium Risk - 41% to 80%, High Risk ->80%
Each of 8 above Risks is assessed on a scale of 100 marks, then converted into % and reported above. In case of Credit Risk, mor
weightage has been given because our primary activity is lending.
Risks are assessed on the principle of “higher the risk, higher the marks; lower the risk, lower the marks.
Risk traits (Business Risk) & Risk Control Traits (Control Risk) are grouped under respective 8 ‘Risk’s and risk profile of the Com
is assessed.
The Risk traits/Risk Control traits are reviewed and revised as suggested by the Board in its 174th meeting held on 07/09/2016.
The system should be able to fetch information for the purpose of risk assessment using various sources like RBIA reports, balan
sheet, market information etc.
The risk assessment sheet is attached in the given Risk Management Policy attached in the Excel.
- The system should be able to provide a comparative analysis for the past quarters as a part of risk assessment.
 
OTMS

- The system be able to generate different OTMS reports as given in the file attached.
- The system should have The functionality to report The credit spurt

The system should be able to trigger Early Warning Signals(EWS) in order to alert about The exceptional transaction taking
in The branches in real time basis.

The system should be able to generate The OTMS report with EWS on a monthly basis.

The basis of OTMS report is information from other modules. The system should be able to fetch this information.

- The system should be able to report the Credit spurt.

- Facility to categorize the branches - Small/Medium/Large/Very large/Extra Large on the basis of their O/S amount, Number o
sanctions and disbursements
Top 6 branches of each category are taken for both sanctions and disbursement
Any anomaly in this data need to be reported.
Branch Category
- Small
- Medium
- Large
- Very Large
- Extra Large
Branch ID – This should be multi value field as it should be updated for 6 branches
Multi value field with the branch code/ID
Branch Name
Multi value field with the branch code/ID
Disbursement Amount
For each top 6 branch
This should be for a specific for a given branch under a given category.
Sanction Amount
For each top 6 branch
This should be for a specific for a given branch under a given category.
Number of sanction
For each top 6 branch
This should be for a specific for a given branch under a given category.

Cross Verification
Reports based on the enquiry made by the risk team.
Filter out various loan accounts for cross verification purpose:
Loan amount less than Rs50 lacs
o Site Loans
o Composite loans where construction cost is above Rs. 2500/- per sq ft
o Individual housing loans where LCT/LTV is above 75%
o Properties located within the Gramathana/ Panchayat limits
o Flats under construction
o Branches where newly recruited/ promoted Managers have been posted
 
Credit Review Monitoring
Define criteria basis which the Risk team can review the loans which are remarked by the cluster head
Facility to provide these remarks in the system only.

Filter out the remarked loans basis conditions:

1)LTV>60% in case of Mortgage Loan.
2)LTV>85% in case of Housing Loan.
3)NTH<=25%.
4)IIR>60%
5)Loans beyond Delegated Powers
6)Loans beyond 30km out of command area.
7)Loans under 44 AD SENP sanctioned by branch.
8)Loan sanctioned without LSR and Valuation Report.
 
Valuers Empanelment.
Empanelment of valuers with their details
Trigger alert in case the allocation is above 70%
Trigger alert for expiry of valuer – 15 days before the expiry

Branch code and Branch Name

Valuer Type - Individual/Company/Partnership
Valuer Name
Valuer Phone Number
Address of the Valuer
The system should have option to add multiple address such as: Current Address/Permanent Address
KYC Documents: PAN Details/Aadhar
Valuer’s Company Address
Qualification details: Institute of Valuers Fellow certificate/Other qualification (Graduate/undergraduate degree)/Wealth Tax 3
Registration certificate
Empanelment letters of other nationalized banks
Partnership deed, in case of Partnership firm
Constitution annexure
Valuer Empanelment Date
Valuer Expiry Date
Renewal option - Yes/No
*Renewal to be done from the date of expiry
Renewed Empanelment Date
Renewed Expiry Date
add new valuers in a given branch
Attachment provision - PAN, Aadhar, Valuation certificates, empanelment letter from other nationalized banks
add valuers expiry date and the renewal date.
• System should run de-dupe for Valuer. De-dupe is run based on following fields:
o Name
o Mobile number
o PAN

• System shall have capability to upload documents in following formats. “Upload” option to be made available next to the field
o Jpg
o Jpeg
o Png
o Pdf
o And any other format shall be configurable
A static field – Allocated Cases – should be added which will be updated as and when a case gets allocated to a given valuer.
The system should have the ability to configure any further type and format of document required.

Regression Analysis and Forecasting Tool

The system shall perform regression analysis based on the requirement of the business user.
The system shall have a predictive analysis tool

Please note that the Integrated Risk Management solution covering all aspects of Risk Management needs to b
implemented without any change request cost to CFHL.
Index

Bidder Bidder
Importance Response Clarifications /
(S/A/C/U) Comments
Critical S-Standard

Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard

Critical S-Standard

  S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical

 
Critical S-Standard
 
Critical S-Standard

Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard
 
Critical
Critical S-Standard
Critical S-Standard

Critical S-Standard

Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
 
Critical
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard

Critical S-Standard

Critical S-Standard

Critical

Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard

Critical S-Standard
Critical S-Standard
 
Critical
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
 
Critical

Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard

Critical S-Standard
Critical S-Standard
Critical S-Standard
 
Critical

Critical S-Standard

Critical S-Standard

Critical
Critical
Critical
 
Critical
Critical S-Standard
Critical S-Standard

Critical S-Standard
 
Critical S-Standard
Critical S-Standard
Critical S-Standard
 

Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical S-Standard

Critical S-Standard
 
Critical S-Standard
Critical S-Standard
Critical S-Standard
Procurement management
Sheet 10: Procurement Management including Vendor Management

Response
S
A
C
U

Id

1.1

1.2

1.3

1.4
1.5
1.6
1.7
1.8
1.9

1.10

1.11
1.12
1.13

2.1

2.2
2.3
2.4
2.5

2.6
2.7
2.8
2.9
2.10
2.11

2.12

2.13

2.14

2.15

2.16
2.17
2.18
2.19
2.20
2.21

3
3.1

3.2

3.3

3.4
3.5
3.6

3.7
3.8
3.9

4.1
4.2

5
5.1
5.2
5.3

5.4

5.5
5.6

5.7

5.8

5.9
5.10

5.11
5.12
5.13
5.14
5.15
5.16
5.17

5.18

5.19
5.20
5.21
5.22

5.23

5.24
5.25
5.26

5.27
5.28

5.29

5.30

5.31

5.2
5.2.1
5.2.2
5.2.3

5.2.4
5.2.5
5.2.6

5.2.7

5.2.8
5.2.9
5.2.10

5.2.11

5.2.12
5.2.13
ocurement management
eet 10: Procurement Management including Vendor Management

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Vendor Onboarding
System should have capability to create vendor (an entity that has purchasing and financial transactions) with the company code
includes vendors/ suppliers.
Each System should assign an account group to vendor when creating vendor master in application. The vendor account group i
classifying term in application and is used to group vendors of the same characteristics.
- The system should be able to onboard the vendor selected for onboarding.
- The system should configure the regular list of vendors if any.
- The system should be able to add new vendors that will be onboarded.
- Facility to provide broad category of product/service offered.
- The system should be able to categorize the vendors as per the product/service offered by them.
- The vendor must be mapped to the respective branches where they are hired.
- The system should have an internal workflow to provide approval for onboarding of the vendors.

The system should be able to input the details of the vendor in Vendor Master. The details should include the following:
- Vendor Name
- Vendors entity nature
- Nature of Vendor (One Time/ Permanent Vendor)
- Vendor Type (e.g., merchandise, non - merchandise, temporary)
- Vendor Address, phone number
- Vendor contact person
- Vendor email address
- Vendor Category - product / services offered
- Vendor TIN information, GSTR Information
- PAN number of vendors - KYC of vendors
- Branch ID
- Vendor Bank Details - for electronic funds transfer
- Vendor bank terms/contract information
- Internal customer number (e.g. number by which we are referenced in the vendor’s customer file), if any
- Last payment date
- Applicability of TDS
- TDS Rate
- Income Tax Act section on TDS applicable to vendor
- Threshold limit after which TDS should be deducted
The system shall be able to generate a unique vendor ID
The system should allow multiple single vendor to be to linked to multiple branches
- Empanelment certificates to be uploaded and last contract/recent work order to be uploaded.

System should be able to provide Maker checker facility.

System shall be able to classify the vendor as the 197(J) lower TDS certificate owner.
System should be able to deduct TDS if PAN details not available
- The system should be able to manage the vendor contracts and upload the same once a given vendor is finalized.

- The system should have the capability to manage the vendor bids, if the vendor is getting onboarded via bid system.
- Once the vendor has been onboarded, the status of such vendor should be onboarded.

- The system should be able to generate report once the vendor is onboarded with the list of vendors and the products/services o

Integration with the Document Management system to store the Vendor contracts
Integration with the fixed asset module if the vendor is onboarded for the purchase of Fixed Asset.

Vendor Transaction Processing

- The system shall be able to record the transaction that takes place through a given vendor.
- The system shall be able to record the invoice number and invoice date for the given vendor.
- the system should be able to capture the transaction detail. This includes-
Branch ID and name
Vendor Name and ID
Vendor GST/PAN number
Product/Service Category
Product/ Service
Contract details
Contract Validity
Contract Date
Contract Amount
GST details and amount - CGST, IGST or SGST etc.
- The system should be able to fetch the basic vendor details form the vendor onboarding application like vendor bank details, ve
name ID etc.

Facility to update the completion of the task, that is, the payment has been made.

Integration with the accounting module for posting of entries in the system
System should provide on-line warning if total payment amounts exceed invoice amount.
System should flag duplicate vendor invoices to prevent double payment.
System should have capability to support on-line inquiries for invoice-by-invoice number, invoices by cheque number, TDS & GS
number and invoices by vendor code.
System should allow processing stop payments and void transactions.
System should allow for processing over shipments of goods.
System should prevent payment to vendors with debit balances
System should have ability to provide invoice tracking for pending department/agency approvals.
System should accumulate year-to-date vendor wise purchases.
System should have ability to print the list of vendors upon request based on user specified format such as: vendor ID number,
alphabetical or year-to- date purchase amount (amount or quantity) sequenced by product line.

System should have ability to generate Vendor Shipping Performance report. The report lists by vendor, due dates for delivery, a
dates of delivery, item short shipments, incorrect items shipped and other required information as per the needs of the organiza
Create system-controlled limits on vendor transactions, total purchases and other defined parameters as per the requirement of
organization.
System should allow multiple people to view the same vendor simultaneously, but restrict maintenance of vendor to authorized
personnel as each department have different vendors to onboard.
System should provide ability to sort cheques by vendor number, by user-defined sequence within bank account number or by v
name
System should be able to search by Vendor number and name.
System should have ability to automatically calculate applicable discounts and payment date.
System should have ability to allow for the addition of freight and bulk charges.
System should have ability to calculate multiple taxes as appropriate by item.
System should have ability to calculate tax rebates at the time of invoice entry.

Vendor Payment
Integration with the Accounting module for payment to the vendor
- The system shall be able to record the transaction that takes place via given vendor.

- The system should have the capability to raise a voucher automatically as and when the vendor transaction is approved.

-The automatically raised voucher must be moved to the accounting module and once approved from there, the accounting entry
vendor payment will be made automatically.
-The system should be able to generate reports regarding the payment and transaction details that took place with the vendor.
Ability to make changes to the vendor file once the payment has occurred. Example: flag inactive, delete
System should support multiple payment types (e.g., system cheque, wire transfer, online payment methods like net banking, UP

System should maintain vendor payment records on-line for current, year-to-date and prior years.
Ability to reflect changes to the vendor file once the payment has occurred. Example: flag inactive, delete

Vendor Offboarding
- The system should have the capability to delete/offboard a given vendor.

- Facility to record the reason for offboarding or deletion of such vendor should be available in the system.

eBidding
Functional
The system shall be capable of e bidding process where in the bidder will apply and register online for the purpose of bidding.
The bidder can apply for the e bidding via CFHL website

Can Fin website shall furnish information for bids from time to time as per their requirement and shall provide a link for the ven
Using the link, the vendor can provide information. This link shall be integrated with the internal vendor management system.
eBidding to be integrated with Procurement management system. Any given vendor selected via the ebidding, the details will be
updated in Vendor Onboarding module to avoid rework.
The system shall support upload of tenders on CFHL website.
Provision to upload the bids on the website itself which will be linked to the internal system. It shall be ensured that no bidders c
what the other party has bid and complete confidentiality shall be maintained.
The system shall generate a unique Request ID of each Requirement RFP that is uploaded on the website. The system shall be
integrated with the website to pull in the bids that are received through the website.
The bidder will provide their information and all the necessary information which is requested.
The system shall also provide for updating the information by the bidder.
The system shall define basic qualification parameters which are same across all the departments.
Notification and trigger alerts for any change in date or change in requirement to the bidder through SMS and email submitted b
them.
The system should perform a comparative analysis between different bid and provide a report to CFHL
The system shall ensure that no bids are accepted post the final date and appropriate error message shall be shown.
The system should list down the bids received with the following information:
- Request ID - ID of the RFP
- Bidder Name
- Bidder Details - Phone number, Address, etc.
- Bid amount
- Bidding Start Date
- Bidding End Date
- Bid date (when the vendor had actually bid) etc.
The system shall be configurable by the business users to add/modify/delete fields.
The system shall also have pre configurable data fields.
The system shall also have pre configurable data fields.
The system should have the capability to handle the soft copies provided by the bidder. These copies will be uploaded by the ven
the bidding link provided on the website.
System should allow tracking of information related to the purchase, such as contract number, purchase order number, bid num
cheque number, invoice information, vendor and related general ledger account.
Technical
In the existing Website, the bidder is supposed to add the e-bidding feature.
The entire bidding process would be conducted through the e-tendering portal of CFHL
All respective technical and commercial bids need to be submitted through this portal only. Relevant documents need to be uplo
at appropriate places on the portal.
The cost of bidding and submission of the bids is entirely the responsibility of the Bidders, regardless of the conduct or outcome
bidding process
Receipt of the bids shall be closed as mentioned in the RFP Schedule.
The technical bids will be opened as mentioned in RFP Schedule
Bidders who do not achieve the cut‐off on any of the bidding parameters or the overall cut‐off score will be disqualified from the
bidding process and their commercial bids will not be opened. Commercial bids of only the technically qualified Bidders will be
opened
Commercial Bid opening schedule will be intimated to the Technical Qualified Bidders as mentioned in the RFP schedule

The Bidder is expected to examine all instructions, forms, terms and conditions and technical specifications in the Bidding Docu
The Bid should not contain any erasures, over‐writings or corrections using whiteners. Any corrections to be made would be by
striking through the content being corrected and duly authenticating the corrections
All information (bid forms or any other information) to be submitted by the Bidders must be submitted on the web portal. The B
may note that no information is to be furnished to CFHL through e‐mail except when specifically requested for.

Technical Requirements
The bidder is expected to add the e-bidding feature, in the existing website
The entire bidding process will be conducted through the e-tendering portal of CFHL
All respective technical and commercial bids need to be submitted through CFHL's e-tendering portal only. Relevant documents
should be uploaded at the appropriate places on the portal.
The cost of bidding and submission of the bids is entirely the responsibility of the Bidders, regardless of the conduct or outcome
bidding process
Receipt of the bids shall be closed as per the timelines mentioned in the RFP Schedule.
The technical bids will open as per the RFP Schedule
Bidders, who fail to achieve the cut‐off on any of the bidding parameters or the overall cut‐off score will be disqualified from the
bidding process and their commercial bids will not be opened. Commercial bids of only the technically qualified Bidders will be
opened
Commercial Bid opening schedule will be intimated to the Technical Qualified Bidders as per the RFP schedule

The Bidder is expected to examine all instructions, forms, terms and conditions and technical specifications in the Bidding Docu
The Bid should not contain any erasures, over‐writings or corrections using whiteners. Any corrections to be made would be by
striking through the content being corrected and duly authenticating the corrections
All information (bid forms or any other information) to be submitted by the Bidders must be submitted on the web portal. The B
may note that no information is to be furnished to CFHL through e‐mail except when specifically requested for.

The bidder should provide complete solution for e-procurement including the following functionalities

1. Indenting
2. Preparation and mapping of tender/auction documents
3. Publishing of the tender/auction on the portal
4. Invitation to all suppliers/Customers
5. Submission of bids by suppliers /Customers including e-payment for EMD etc.
6. Digital Signing of Bids and bid documents.
7. Bid submission
8. Prequalification evaluation of bids
9. Technical evaluation of bids
10. Reverse Auctions should support multiple auction types & format
11. Forward Auction should support multiple auction types & format
12. Commercial evaluation of bids
13. Award of the contract and Purchase Order/Work Order.
14. MIS Reports.
15. Integration with ERP operating.
16. Help Desk facility.
The bidder should provide the following functionalities for forward e-auction (forward & reverse): -

1. Auction EOI / Enquiry to be published in media other than e-auction platform.

2. Techno-commercial Scrutiny of bidder
3. Publishing / Mapping of auction in portal Bidder
4. Mock auction to bidders/MMTC officials Bidder
5. Sending contact details of techno-commercially approved Bidders to service provider
6. Framing Business rule containing auction format and other details Bidder
7. Approval of Business Rule
8. Sending Business rule document to all the Bidders Bidder
9. Collection of consent letter & compliance statement from Bidders Bidder
8. Commercial query handling
9. Auction related query handling & Bidder Training Bidder
10. Making user id & Password available to Bidders Bidder
11. Assisting Bidders participate in dummy auction Bidder
12. Event Date & Time finalization &
13. To provide Start Bid price/Estimate/minimum quantity/minimum incremental price & quantity for bidding
14. Conducting Auction & Providing Helpdesk service during auction
15. Auction report generation and submission (Detail and summary as required by CFHL immediately after completion of auctio
16. Price break up (if any) to be collected from the Winning bidder
17. Non-disclosure of identity of vendors/customers to CFHL and other participating vendors for maintaining sanctity of event
18. Multiple currency bidding, provision for bidding up to predefined decimal places, auto closing/extension of auction after
predefined time, auto refresh of vendors/customer screen at preset interval , support single as well as multiple lot auctions , disp
ranks/price only on the dashboard of vendors/customer , auto-bid facility & bid trail
19. In case of loss of connectivity of vendors/customer computer/laptop/mobile etc. due to any reason , the bidders should supp
secure alternate to allow such vendors/customers to place the bid
20. Voice and video logging of auction event and submission to CFHL as when asked for
21. SMS broadcasting to vendors/customers on auction notification, schedule, reschedule etc.
22. Devise suitable auction strategy
Index

Bidder
Bidder Clarificat
Importance Response ions /
(S/A/C/U) Comment
s
Critical S-Standard
Critical
S-Standard
Critical
S-Standard

Critical

S-Standard

Critical

S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical
S-Standard
Critical S-Standard int
Critical
S-Standard int

Critical
S-Standard
Critical S-Standard
Critical S-Standard

Critical

Critical

S-Standard
Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical
S-Standard

Critical
S-Standard
Critical
S-Standard
Critical
S-Standard
Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard
Critical S-Standard

Critical

Critical
S-Standard
Critical
S-Standard
Critical
S-Standard
Critical S-Standard
Critical S-Standard
Critical
S-Standard Interface with Bank
Critical S-Standard
Critical S-Standard

Critical
Critical
S-Standard
Critical S-Standard

Critical

Critical Ariba
Critical Ariba

Critical
Ariba
Critical
Ariba
Critical Ariba
Critical
Ariba
Critical
Ariba
Critical
Ariba
Critical Ariba

Critical
Ariba
Critical Ariba
Critical Ariba
Critical

Ariba
Critical Ariba
Critical Ariba
Critical Ariba
Critical
Ariba

Critical
Ariba
Critical
Critical Development
Critical Ariba
Critical
Ariba
Critical
Ariba
Critical Ariba
Critical Ariba

Critical
Ariba
Critical Ariba
Critical
Ariba
Critical
Ariba

Critical
Ariba

Critical Ariba int

Critical Ariba int
Critical
Ariba int
Critical
Ariba int
Critical Ariba int
Critical Ariba int

Critical
Ariba int
Critical Ariba int
Critical
Ariba int
Critical
Ariba int
Critical
Ariba int

Critical

Ariba
Critical

Ariba
Deposits
Sheet 3: Deposits

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement

Module Deposit Product Master

1 Product Definition

Application shall define different types of deposit products / offerings:

Public Deposits:
a) Cumulative Term Deposit
b) Fixed Term Deposit
Exempt Deposits:
a) Central Government
b) State Government
1.1 c) Deposits Guaranteed by Central or State Govt.
d) Local Authority
e) Banking Company
f) Co-operative Banks/Co-operative Group Housing Society
g) Security Deposit accepted from an employee of CFHL
h) Deposits accepted from Companies (both Pvt. and public Ltd.) incorporated in India, under
Companies
Act 1956 for a period of less than One year.

2 Product Features
Facility to fetch the unique customer identification number from the UCIC module for fetching
2.1
the details of the customer. (Refer to CRM Sheet)
2.2 Facility to define the minimum and maximum amount of the deposit account
2.3 Facility to define the minimum and maximum tenure of the deposit account
2.4 Facility to define the maximum interest till which the TDS is not applicable

Facility to capture the employee ID of the in the deposit application form and deposit module
2.5
Functionality to verify employment status from HRMS system based on employee ID provided

System to allow crediting the customer account on receipt of cash payments on completion of
2.6
the authorization by the defined user
2.7 Facility to configure TDS rates based on PAN availability
Facility to configure the additional interest rate applicability in case first applicant one of the
following:
1. Retired Employee
2.8
2. Existing Employee (exempt contract employee from existing employee category for interest
rate deviation)
3. Senior Citizens
 The following treatment shall be configurable for interest
1. Payout at periodic intervals / frequency (fixed term deposits only)
a. Monthly (Facility to define the minimum and maximum deposit amount for monthly payout
of interest)
b. Quarterly (Facility to define the minimum and maximum deposit amount for quarterly
payout of interest)
c. Half Yearly (Facility to define the minimum and maximum deposit amount for half yearly
2.9 payout of interest)
d. Yearly (Facility to define the minimum and maximum deposit amount for annual payout of
interest)
2. Cumulate and compound quarterly at March, June, September, December to the term deposit
account. Basis configuration:
a. Interest added to principal and compounded on quarterly basis
3. Computation of the payable amount during pre-closure (including exemption for customer
death).

System shall provide the facility to define the deposit code applicable for the chosen deposit
2.10
product
2.13 Facility to cancel the deposit if discrepancy is found at back-end
2.14 Facility to define business rule for interest rates basis slabs of deposit tenure
Functionality to replicate existing nominee details based on existing deposits for the new
2.15
deposits being created
System functionality to capture the exemption certificate for levying a reduced rate of Tax
2.14
Deducted at Source
System functionality to check if nominee has attained majority/independent operation in case of
depositor death
2.17
Facility to issue a pop-up to inform branch user where nominee is a minor: ID details of both
minor and guardian to be captured.
Treatment of the account at the maturity configured for following options:
1. Encashment and payout proceeds of deposit account
2.18
2. Renewal of deposit (upon request)
3. OD Deposit, in lieu of renewal
Mapping of the General Ledger for the automated posting of Journal Vouchers for different
2.19
deposit product codes shall be configurable
Penal Interest to be applied in case of pre mature closure of the account (except depositor
2.18
death).
2.19 System functionality to capture the death certificate of the depositor
2.20 Aadhaar Data Vault
System functionality to incorporate and integrate Aadhaar Data Vault (ADV) to store Aadhaar
2.20.1 Numbers and any connected Aadhaar data (e.g. eKYC XML containing Aadhaar number and
data) in a centralized storage accordance with the regulatory requirements.
2.20.2 System functionality to access ADV only on need to know basis.
System functionality to incorporate and integrate Aadhar Data Vault (ADV) with the CRM/Lead
2.20.3 Management, Lending, Deposit, TP Insurance Module or other modules as may be deemed
necessary by the management at CFHL
Module Deposit Application
3 Deposit Account Opening
Facility to open deposit online through website and CFHL mobile application (provision to be
3.1
made for future state but not activated)
3.2 Facility to open deposit offline through branch visit
Facility to ensure that majority of the details to be automatically filled up in deposit application
3.3 form and limited details be made available for customer to fill up: Tenure, Amount, Nominee,
Signature (ROI to be fetched as per pre-defined business rules)
 Facility to link the UCIC of the depositor to the deposit account thereby fetching existing
3.4
customer details based on UCIC Number to reduce manual data input

Facility to fetch and auto populate existing customer details based on UCIC of the customer.
System functionality to conduct the option of prefilling the name, age, demographics as per one
of:
3.5 PAN Card (editable/non-editable)
Aadhaar Card (editable/non-editable)
in the CRM/Lead Management, Deposit or other modules as may be deemed necessary by the
management at CFHL

Facility to verify the KYC details of the depositor through integration with NSDL/UIDAI portal.
e-KYC of PAN:
a. System functionality to conduct eKYC of PAN for the application in the CRM/Lead
Management, Deposit, Leding, Insurance Modules or other modules as may be deemed
necessary by the management at CFHL
b. System Functionality to record the Name, Validated PAN Number or other details as may be
deemed necessary by the management of CFHL based on details mentioned in NSDL database.
System Functionality to record the verified details in Lending, Deposit modules or other
3.6 modules as may be deemed necessary by the management at CFHL
e-KYC of Aadhaar:
a. System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the
CRM/Lead Management, Deposit, Lending, Insurance Modules or other modules as may be
deemed necessary by the management at CFHL
b. System Functionality to record the Name, DOB, Address, Gender or other details as may be
deemed necessary by the management of CFHL based on details mentioned in UIDAI database.
System Functionality to record the verified details in Lending, Deposit modules or other
modules as may be deemed necessary by the management at CFHL

Facility to auto-fill the reference number against the Aadhar Number of the customer, guardian
3.7 (minor) coupled with de-duplication check and corresponding Aadhaar details stored in
Aadhaar data vault (ADV).
3.8 Facility to link the PAN Card details of the customer, guardian (minor)
3.9 Facility to define the Nominee for the account

Facility to capture and link the UCIC and KYC details of the Nominee to the deposit account
Facility to enable option of printing/not printing of nominee details on the deposit receipt
System functionality for replication of existing nominee details for the new deposits being
3.10 created based on existing deposits
System functionality to alter the nominee in existing deposits (upon written request of
customer), map new nominee to new deposits, capture sequencing of nominees mapped to
deposit account (proportion of payout)

The system shall provide the option Mode of Operation of the account
1. Individual including NRI, minor, illiterate, blind, par Darshin (details of accompanying
person, POA to be captured) etc.
2. Joint Account: Either or Survivor, Anyone or Survivor, First Depositor or Survivor, All jointly
3.13 (minimum and maximum individual for joint account holders to be defined)
3. Proprietorship Account
4. Partnership Account
5. Trust Account
6. Organizations: Non corporate bodies
 3.14 Facility to open a deposit account on the date of realization of deposit account funding
3.15 Facility to print the Term Deposit Receipt with terms of deposit
3.14 Joint Account: Name of all the account holders shall be printed on the Deposit Receipt
3.17 Minor: Name of guardian shall be printed on the Term Deposit Receipt
Functionality to be incorporated but inactive for now:
Functionality to capture customer instructions for auto-renewal of deposits at the time of
3.18
deposit creation
Functionality enabling auto-execution of renewal instructions on maturity date of deposit
Storage of Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML
3.19
containing Aadhaar number and data)
System Functionality to Record the Aadhaar number in the Deposit or other modules as may be
3.19.1
deemed necessary by the management at CFHL
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the
3.19.2 CRM/Lead Management, Deposit, Lending, Insurance Modules or other modules as may be
deemed necessary by the management at CFHL

System Functionality to record the Name, DOB, Address, Gender or other details as may be
deemed necessary by the management of CFHL based on details mentioned in UIDAI database.
3.19.3
System Functionality to record the verified details in Lending, Deposit modules or other
modules as may be deemed necessary by the management at CFHL

System Functionality to generate associated unique reference key.

3.19.4 System functionality to replace the Aadhaar number with the reference key across the entire
ecosystem of CFHL.
System Functionality to ensure that post completion of any transaction where Aadhaar number
3.19.5
is exchanged, the reference key to replace the Aadhaar number, when needed.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to
ADV:
3.19.6 All the existing Aadhaar related information to be stored in the Aadhaar Data Vault.
Functionality to ensure that the scanned copy of the physical Aadhaar card be masked and
stored in an encrypted format within CFHL database.
3.19.7 System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the Aadhaar information based on reference number, if needed for
3.19.8 regulatory purposes/other mandated business engagements, but referenced through the key
post the transaction, via APIs to whitelisted IP addresses.
System functionality to conduct Re-KYC of the customer based on risk category and update the
3.19.9
same in ADV.
System functionality to conduct de-duplication checks based on unique reference keys mapped
3.19.10
against Aadhaar number.
Module De-Dupe Engine
4 De-duplication Engine

System functionality to define the parameters on which the de-duplication engine is to be

configured and triggered (tentative but not limited to):
Full Name
Customer Mobile Number
PAN Number
Aadhaar Number (against unique reference number as per ADV)
Passport number
Any Other KYC Number
Customer DOB
Address (Passive)
4.1
4.2 System functionality to trigger the de-duplication check automatically and manually
 Facility to run/re-run de-duplication checks at pre-defined stages and centrally across entire
customer and customer master database:
Customer Creation
Application Processing (Loans/Deposits)
Post Application (Disbursal/Deposit Creation) De-dupe Checks
Master database de-dupe at specified intervals basis management discretion: monthly,
quarterly, semi-annually, annually
4.3
System functionality to validate the de-duplication checks across customer categories:
4.4 individuals and non-individuals
System functionality to report the de-dupe checks to defined authority within CFHL for
4.5 processing, rectification and analysis and correction
Facility to report the cases on which multiple UCIC have been identified and suggest scenarios
accordingly, including but not limited to:
Contacting customer
Merging the UCIC
4.6 Suggesting and updating the customer details based on their verified KYC
System functionality to validate duplication checks against internal (across CFHL) and external
databases (regulatory and non-regulatory databases e.g. politically exposed persons, negative
4.7 list etc.)
Module Application De-duplication Check
5 Application De-duplication
5.1 System functionality for user to log in into de-duplication search engine
5.2 Facility to select product, and sub-product
5.3 Facility to select application/deposit number for running the systemic de-dupe checks
5.4 System functionality to create a de-duplication check ID

5.5 System functionality to display the deduplication ID, Matched Customer ID, Matched
Parameters, Current Input Value, Matched Score, Data Source and matched parameters validity
5.6 System functionality for the maker to accept and suggest matched parameter validity
System functionality to display the customer details post the de-duplication check upon
5.7
expanding UCIC number

Display details like (tentative but not limited to):

Customer Name
Customer Type
5.8 UCIC
Customer Name, Gender, DOB
PAN, Passport, Aadhaar (against unique reference number as per ADV), Voter ID, DL Number
Complete Address
Phone Number
Father/Mother/Spouse Name
5.9 System functionality to reflect the details filled in the application form versus available in databa
Facility to check, respond and correct the details in either the application form or the UCIC
5.10
module for the customer
Module Checker
6 Checker
System Functionality to include provision for checker in the de-duplication search engine
6.1
module
System functionality to ensure that dedupe verifier checks & verifies the Details of each & every
6.2 Parameter between the Request & Response and then decides to Approve or Reject the
Customer Code to avoid the duplicate detail[s] of the UCIC
 System Functionality to mark the case as checked & verified by the Approver ensuring the
6.3 details are appropriate while comparing the Request & Response details, then the Approver
selects the option ‘Valid’ from the list
For modifications in customer data post de-duplication checks, the user selects UCIC mapped
6.4 from data base.
Once the appropriate UCIC is selected, the checker clicks the Update Dedupe Status button for
updating the details of the Customer, thereby, updating the details
Rejection of de-duplication results/UCIC:
6.5 Post de-dupe, if the maker-checker are not satisfied with the details while comparing the
Request & Response details, then the checker selects the option ‘Invalid’ from the list
7 Deposit Account Funding
System functionality to accept following modes of payment towards funding of deposit:
Cheque deposit
7.1
NEFT/RTGS/IMPS
to continue as the funding method for deposit account creation
7.2 Facility to generate deposit code for various categories of deposit products
Configure automated posting of Journal Vouchers for LS deposit across deposit codes through
7.3
system to system integration for Realtime replication of journal entries
Configure system functionality for mapping of the General Ledger for the posting of Journal
7.4
Vouchers for different transactions
Module Interest Application & Accrual
8 Interest Accrual
8.1 Facility to compute interest accrual on the deposited account
Fixed Deposit: Feature to configure the interest accrual on the fixed deposit account as per pre-
8.2 defined frequency
Interest paid at periodic intervals: Monthly, Quarterly, Half Yearly, Yearly
Cumulative Deposit: Cumulate and compound quarterly interest at March, June, September,
8.3 December to the term deposit account. Basis configuration:
a. Interest added to principle and compounded on quarterly basis
9 Interest Application
The interest application at the account shall be as per the interest application frequency being
9.1
configured at the product level
System functionality for calculation and timely credit of interests linked to deposit accounts of
9.2
customer across all branches of CFHL.
The system shall perform the interest application as per the following methods:
Fixed Deposit: Interest Payout to the customer at pre-defined frequency as configured at
9.3
product level
Cumulative Deposit: Capitalize to the deposit account as net of TDS
The system shall provide the following options for interest payout:
System Functionality to prepare the interest payout worksheet to be posted to respective bank
9.4
branches.
Payout to the customer account at pre-defined frequency as configured at product level
Module TDS
10 Tax Deducted at Source
Facility to deduct the tax at source if interest for the customer across all deposit accounts is
10.1
more than the threshold amount defined at the product level
Facility to ensure that TDS is computed at the slabs defined at product level based on
10.2
availability of PAN number
10.3 Facility to generate the TDS certificate to be issued to the customer
10.4 Facility to map the deposits against the 15G / 15H form submitted by the customer
 Facility to ensure that if Form 15G / 15H is submitted by the customer, TDS shall not be
10.5 deducted even if the interest for the customer ID across all Term Deposit accounts is more than
the threshold amount defined at product level
10.6 Facility to ensure that TDS is reported to Income Tax department at defined intervals
10.7 System functionality to account different slabs of TDS based on exemption certificate
System functionality to allow modification of TDS slabs at RO level basis the exemption
10.8
certificate

11 Loan on Deposits
Facility to validate the deposit(s) that can be kept as collateral as per the terms decided at
11.1
product level
Facility to keep the deposit(s) as collateral as per the terms of loan (LTV, PF, ROI, Tenure)
11.2
decided at product level
System functionality to compute interest on LOD till the date of maturity of loan (against prior
11.3
month end)
Module Pre-Closure
12 Pre-Closure
12.1 Facility for the system to levy penal interest rates and charges
Facility for the system to re-compute and re-calculate interest to be applied on the revised
12.2
period of term deposit only
System functionality to capture the reason for pre-closure of deposits
12.3
Functionality to auto-compute interest based on reason for pre-closure (depositor death)
Facility to provide the following option for payment of deposit amount upon pre-mature deposit
closure:
12.4
Payment of A/C payee cheque
Transfer to bank account via NEFT / RTGS
12.5 Configure posting of Journal Vouchers for LS deposit for pre-mature closure of deposit
Facility to ensure that if deposit is used as a collateral then the system shall not allow premature
12.6
closure of the TD
System facility to allow TDS deduction on interest paid to customer at the time of pre mature
12.7
closure of term deposit
Module Closure and/or Renewal
13 Account Maturity
13.1 System functionality to provide closure of deposit account on the maturity date
System shall check for the maturity instructions - Auto-Renewal (provided but not activated),
13.2
Manual Renewal (complete/partial), Deposit OD account, Closure
System shall ensure the validation of deposit receipt for maturity instructions - Closure, Manual
13.3
Renewal
Facility to provide the following option for payment of deposit amount upon closure of matured
deposit:
13.4
Payment of A/C payee cheque
Transfer to bank account via NEFT / RTGS

13.5 Configure posting of Journal Vouchers for LS deposit for closure of deposit on date of maturity

Facility to ensure that if deposit is used as a collateral then the system shall not allow closure of
13.6
the TD
System facility to allow TDS deduction on interest paid to customer at the time of closure of
13.7
matured term deposit
14 Renewal
System shall facilitate automatic renewal of deposit accounts post closure on the maturity date
14.1
(functionality provided but not activated)
 System shall facilitate manual renewal of deposit accounts with deposit receipt post closure on
14.2
the maturity date

System shall facilitate following options post closure on the maturity date
- Renewal of Principal Only with payout of Interest
14.3 - Renewal of Principal + Interest
- Part withdrawal of Principal + Interest amount
- Part addition of Principal Amount (subject to realization of payment in CFHL bank account)

Facility to apply interest rate applicable on the renewal date for the declared tenure shall be
14.4
applied on the TD Account
System functionality to check if the deposit maturity date for renewal is more than "x" months
14.5 (configurable) than the period for which the deposit is kept in OD account, subject to maximum
tenure of deposit allowed by CFHL
Functionality for supporting renewal of deposits across CFHL branches for all depositors (policy
14.6
level decision: functionality provided but not activated)

14.7 If the depositor becomes Sr Citizen, existing employee, interest rate benefit shall be provided

System functionality to allow modification of joint account holder, nominee details, guardian
14.8
(minor)
System should support renewal of term deposit within “n” calendar days (configurable) of
maturity date. The renewal in such cases should be effective from the date of the maturity of
14.9
deposit. Revised interest rate on the deposit in such cases should be the interest rate on date of
maturity/or current interest rate whichever is lower
15 Closure on maturity
15.1 Facility to send reminder SMS to depositor for due closure of deposits
15.2 Reminder SMS to incorporate the change of slabs for senior citizens
15.3 The system computes maturity amount as: Principal + Interest adjusted for TDS
Facility to provide the following option for payment of deposit amount upon maturity of
deposit:
15.4
Payment of A/C payee cheque
Transfer to bank account via NEFT / RTGS
16 Migration of Deposits
Functionality for supporting closure at maturity, preclosure of deposits across CFHL branches
16.1
for all customers (policy level decision: functionality provided but not activated)
Module Exempt Deposits
17 Exempt Deposits
Functionality to capture deposit request of the exempt depositor against deposit amount,
17.1
tenure, requested ROI, exemption certificate (TDS)
Functionality by RO to configure final terms of exempt deposit (amount, tenure, requested ROI,
17.2
TDS rate) presented in non-editable mode to the branches for further processing
Module Customer Web Tools
18 Customer Information Tools
Facility to provide information at the handheld device for deposit customers for information
18.1
related to information purposes

Ability to suggest status of the deposit to the concerned depositor for the following parameters:
Depositor Name, Nominee Name
KYC Details
18.2
Address
Contact Details
Principal Amount, Maturity Amount, Exact Amount as on Date, ROI, Start Date and End Date
 System functionality to ensure provision for renewal of deposit (provided as a functionality for
18.3
future state but not activated)
System Functionality to track the periodic interest credited to depositor account along with the
18.4
date of payment.
18.5 System functionality to record the details of payment to the branches for processing of vouchers a
Module MIS and Dashboards
19 Reports
Facility to generate a report for minor to major depositor or customer becomes senior citizen at
19.1
least one month prior

19.2 System functionality to trigger/generate reports to collect exemption certificate from customers

Facility to generate monthly reports to collect 15G/15H forms from customers where cumulative
19.3 interest across all deposit accounts is more than the threshold amount defined at the product
level
19.4 All existing deposit reports to be prepared and mapped
20 De-Duplication Functionality
System functionality to incorporate, integrate and run de-duplication as per the management
20.1
discretion
Index

Please populate only these columns with your responses

Bidder
Importance Response Bidder Clarifications / Comments
(S/A/C/U)

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

 
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical
Critical
 
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
LOS Index
Sheet 1: LOS

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement Importance

Module Reference Master

1 Product Definition Critical
1.1 Functionality to map the existing products and schemes Critical
System functionality to configure, map and maintain the list of all product
1.1.1 Critical
masters for existing products in CFHL (Active/Inactive)
1.2 Aadhaar Data Vault
System functionality to incorporate and integrate Aadhaar Data Vault (ADV)
to store Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML
1.2.1 Critical
containing Aadhaar number and data) in a centralized storage accordance
with the regulatory requirements.
1.2.2 System functionality to access ADV only on need to know basis. Critical

System functionality to incorporate and integrate Aadhar Data Vault (ADV)

1.2.3 with the CRM/Lead Management, Lending, Deposit, TP Insurance Module Critical
or other modules as may be deemed necessary by the management at CFHL

Module Reference Master - New Product

2 New Product and Scheme Configuration Critical
2.1 New Product Configuration Critical
System functionality to utilize and derive product configuration from an
existing product along with all the master and rule definitions
2.1.1 Critical
Facility to define and create new products along with functionality to make
required changes in the parameters and related masters
2.2 New Scheme Configuration Critical
System functionality to utilize and derive scheme level configuration from
an existing product along with all the master and rule definitions (e.g.
promotional schemes)
2.2.1 Critical
Facility to define and create new schemes within existing product codes
along with functionality to make required changes in the parameters and
related masters
2.3 Flexibility in terms of loan parameters Critical
System functionality to ensure flexibility in defining the terms of loan
2.3.1 Critical
parameters of existing loan products
3 Channel Access Critical
3.1 Sourcing Channel Critical
Ability to provide access to LOS for sourcing channels (other external
3.1.1 Critical
sourcing channels)
3.2 Process Channel Critical
 Ability to provide access to LOS for different external agencies for lifecycle
3.2.1 stages FI(Field Investigation) Agencies, Insurance Partners, Empaneled Critical
lawyers and Technical Valuers, or other channel partners (configurable)

4 Integrations Critical
4.1 Internal Systemic Integration Critical
4.1.1 CIF Critical
4.1.2 LMS Critical
4.1.3 DMS Critical
4.1.4 Corporate website Critical
4.1.5 Mobile app Critical
4.1.6 HRMS Critical
4.1.7 Deposit Critical
4.1.8 Aadhaar Data Vault (ADV) Critical
Description: Builder Module, Layout Module, Builder Master Module
4.1.9 Critical
Employment Master Module, Any other module
4.2 External Systemic Integration Critical
4.2.1 Credit Bureau (CIBIL/Experian/Any other) Critical
4.2.2 eKYC (NSDL, UIDAI, GSTIN, any other) Critical
4.2.4 Financial/Bank Statement Analysis (Perfois, any other) Critical
4.2.5 Vahan Critical
4.2.6 FI agency system Critical
4.2.7 Third party aggregators (web portals) Critical
4.2.8 Servers Critical
4.2.9 Cloud Storage Critical
4.2.10 Enterprise Data Warehouse Critical
4.2.11 DSA Critical
4.2.12 Empaneled Advocate and Valuer Modules Critical
4.2.13 Insurance Partners Critical
4.2.14 eNACH Critical
Module New Application
5 UCIC(Unique Customer Identification Code) Fetch Critical
System functionality to fetch the UCIC from customer creation module
(Refer to CRM Sheet)
5.1 Critical
Functionality to auto-populate the details of the customer in respective LOS
fields
System functionality to autogenerate and assign a loan application number
5.2 Critical
for each application
System functionality to conduct the option of prefilling the name, age,
demographics as per one of:
PAN Card (editable/non-editable)
5.3 Critical
Aadhaar Card (editable/non-editable) in the CRM/Lead Management,
Lending or other modules as may be deemed necessary by the management
at CFHL
 e-KYC:
e-KYC of PAN:
a. System functionality to conduct eKYC of PAN for the application in the
CRM/Lead Management, Deposit, Lending, Insurance Modules or other
modules as may be deemed necessary by the management at CFHL
b. System Functionality to record the Name, Validated PAN Number or
other details as may be deemed necessary by the management of CFHL
based on details mentioned in NSDL database.
System Functionality to record the verified details in Lending, Deposit
modules or other modules as may be deemed necessary by the management
5.4 at CFHL e-KYC of Aadhaar: Critical
a. System Functionality to conduct eKYC verification of the Aadhaar
Number with UIDAI in the CRM/Lead Management, Deposit, Lending,
Insurance Modules or other modules as may be deemed necessary by the
management at CFHL
b. System Functionality to record the Name, DOB, Address, Gender or other
details as may be deemed necessary by the management of CFHL based on
details mentioned in UIDAI database.
System Functionality to record the verified details in Lending, Deposit
modules or other modules as may be deemed necessary by the management
at CFHL

6 Lead Mapping to Loan Application Critical

System functionality to define the number of channels and name of channels
6.1 Critical
for generating and maintaining leads

System functionality to maintain a list of repository of leads generated and

6.2 Critical
map the reference lead number to the loan application being generated

System functionality to ensure that branch manager has the right to discard
6.3 the balance leads that remain in the system against the customer and mark Critical
it as "hold", "reject", "converted"
7 Customer Segment Critical
7.1 Functionality to configure customer segment, constitution for the Products Critical
 The customer should be segmented into the following categories:
Constitution:
Individual
HUF
Proprietorship
Partnership
Pvt Ltd/Public Ltd
Trust
Govt
7.1.1 LLP Critical
1. Individuals - Housing loans to Individuals (including Salaried
&Professional and Self Employed Professionals and Non Professionals -
SENP).
2. Individuals/Firms/ Companies - Non-housing loans to
Individuals/Companies/Firms etc. No loans shall be permitted to
partnership firms in which a Trust is a partner.
3. Builder Loans to Builder/Contractors/Corporates
4. Line of Credit is given to Corporate Sector, Micro finance Institutions &
Govt Sector

System functionality configure minimal processing fee

8 System Functionality to collect and record minimum processing Critical
fee
9 Credit Information Report Critical
Credit Bureau Check: System Functionality to define the rules for fetching
9.1 Critical
and validating the credit information score
Facility to configure "Credit Bureau Check" activity in the workflow
9.1.1 (CIBIL/Experian/Any other) Critical
Functionality to be configured for manual or automated mode

System Functionality for integration of LOS for retrieving the CIBIL or

Experian scores.
Facility for branch user to initiate CIR based on ticket size of the loan:
9.1.2 Critical
< 30 L: CIBIL
> 30 L: CIBIL & Experian
Facility to re-initiate the service for any Credit Bureau or for any applicant

9.2 Credit Bureau Check Rules Critical

System functionality to ensure that upon "Credit Bureau Check" initiation,
the request should ensure:
1. Simultaneous multi bureau check (> 30 L)
2. Conditional multi bureau check (<30 L vs > 30L)
9.2.1 3. Credit Bureau Check for Co Applicant and/or Guarantor as well Critical
4. Credit Bureau specific integration calls (with CIBIL or Experian)
5. Credit Bureau result interpretation (CC etc.)
6. Revert "Credit Bureau" result in specific place holders for data capture
along with the credit information report
9.3 Capture and Populate CIR Score Critical
Capability to display the "Credit Bureau Results" in specific place holders for
9.3.1 data capture along with the credit information report Critical
Provision to view or download "Credit Bureau" report.
9.4 Aberrations Critical
 System functionality to ensure following based on result from "Credit
Bureau":
9.4.1 > 600: Capability to take Decisions at branch level. Critical
< 600: Obtain concise* permission with substantiating reasons from RO
(manual decisioning)

System functionality to define the validity of credit information report and

9.5 Critical
set functionalities to re-initiate the credit check as an option or compulsorily

9.6 Capability to manually re-initiate "Credit Bureau" check. Critical

Module Document
10 Document Collection Critical
System functionality to support document collection and tracking
10.1 System functionality to define the information and corresponding Critical
documents to be captured against categories of customer segment
System functionality to support document submission (collection and
10.2 tracking) by the borrowers through an online link generated and shared to Critical
customer through registered e-mail or phone number.
10.3 Display List of Documents Critical
Facility to display the list of "Documents to be collected" from the borrower
10.3.1 Critical
during application processing, as applicable
Provision to mark the non mandatory documents as mandatory if required
10.3.2 for a particular application/case. Mandatory documents can not be marked Critical
non mandatory.
10.3.3 Provision to display list of mandatory documents, to be collected Critical
System functionality to categorize the documents as mandatory and non-
Critical
10.3.4 mandatory
10.4 Document Search Critical
Provision to search documents based on reference type, stage,
Critical
10.4.1 applicant/business partner type and status.
10.5 Document Status Critical
Provision to capture the document status (as Received, Waived Off,
Critical
10.5.1 Deferred) and remarks(if required).
For "Received" document the date can be captured on which the document
was received along with document related details(if original submitted,
Verification status). Critical
Additional information w.r.t. the document (as configured) can also be
10.5.2 captured.
Provision to capture waiver reason/deviation permission for "Waived Off"
Critical
10.5.3 document, along with delegation status
Provision to capture "reason for deferment" and "deferred till date" for
Critical
10.5.4 "Deferred" document.
Provision to upload document image for "Received" Documents.
Document image upload can be configured to be "mandatory" or "non Critical
10.6 mandatory"
Facility to track and update status of documents that were marked deferred
Critical
10.7 or are pending from borrower
Facility to accept additional documents, other than configured, applicable to
Critical
10.8 an application.
System functionality to customize the workflow and number of screens for
Critical
10.9 collecting and recording the documents within the module
Functionality to check the clarity (legibility) of document uploaded by the
Critical
10.10 user
 For "Received" document the date and time to be captured on which the
document was received along with document related details (if original Critical
10.11 submitted, Verification status).
Critical
10.12 Provision to view the document status of an application and print the same.
Until all the mandatory documents are either "Received", "Waived" or
"Deferred". Critical
System functionality to pop the message upon the date of deferment/stage
10.13 of lending lifecycle of deferment

System functionality to collect the documents related to the details of

construction builder-vendor:
Name
Address Critical
KYC Details (validated against central database)
Communication Details (Address, Phone, E-mail Address)
10.14 Photo and Signature
Module De-Dupe Engine
11 De-duplication Engine Critical

System functionality to define the parameters on which the de-duplication

engine is to be configured and triggered (tentative but not limited to):
Full Name
Customer Mobile Number
PAN Number
Critical
Aadhaar Number (against unique reference number as per ADV)
Passport number
Any Other KYC Number
Customer DOB
Address (Passive)
11.1
System functionality to trigger the de-duplication check automatically and
Critical
11.2 manually
Facility to run/re-run de-duplication checks at pre-defined stages and
centrally across entire customer and customer master database:
Customer Creation
Application Processing (Loans/Deposits) Critical
Post Application (Disbursal/Deposit Creation) De-dupe Checks
Master database de-dupe at specified intervals basis management
11.3 discretion: monthly, quarterly, semi-annually, annually
System functionality to validate the de-duplication checks across customer
Critical
11.4 categories: individuals and non-individuals
System functionality to report the de-dupe checks to defined authority
Critical
11.5 within CFHL for processing, rectification and analysis and correction

Facility to report the cases on which multiple IDs have been identified and
suggest scenarios accordingly, including but not limited to:
Contacting customer Critical
Merging the IDs
Suggesting and updating the customer details based on their verified KYC
11.6
System functionality to validate duplication checks against internal (across
CFHL) and external databases (regulatory and non-regulatory databases e.g. Critical
11.7 politically exposed persons, negative list etc.)
Module Data Entry
 12 Data Capture Critical
12.1 Individual Critical
12.1.1 Provision to capture the occupational details of borrower Critical
12.1.2 Provision to capture the financial details on the basis of occupation. Critical
The details varies for different occupation types like "Salaried", "Self
12.1.3 Critical
Employed Professional", "Self Employed Non Professional" and "Other".
12.1.4 Facility to capture details of legal heirs Critical
12.1.5 Customer Profiling Critical
System functionality to define the system parameters to assess an individual
12.1.5.1 Critical
and assign rating scores against parameters
Facility to categorize the customer base based on risk:
Based on employment of applicant, co-applicant
Status of Employee
Age
12.1.5.2 Critical
Educational Qualifications
Tenure of Service completed vs remaining
Salary
CIBIL etc.
Provision to capture personal discussion details held by branch team
12.1.6 System functionality to capture and record the video personal discussion of Critical
the applicant and store securely within CFHL servers.
If the data entered is mismatched, between the actuals vs provided by
12.1.7 borrower, the system functionality to be able to modify the details and re- Critical
run the borrower assessment
12.1.8 Salaried Critical
Maintain list of masters for categorizing and recording various heads of
12.1.8.1 income, expenses, obligations Critical
Facility to capture details of existing and previous employers

Provision to capture salary income details for various salary heads such as
"Basic Salary", "HRA", "Allowances" etc.
Capability to capture the frequency of various components of income.
System functionality to specify %age of a particular income head is to be
12.1.8.2 Critical
considered for final computation of eligibility
For NRI: System functionality to capture income against various heads in
different currency and to convert all income in base currency
The "Net Annual Income" as a function of above mentioned parameters.

Provision to capture other income details for various income heads such as
"Rental Income", "Dividend Income", "Agricultural Income"
Provision to capture "Other Income" details for current year and previous
year.
12.1.8.3 Critical
For NRI: Capability to capture other income against various heads in
different currency and to convert all other income in base currency.
Facility to configure Income that will be considered under a particular head
will be based on a configurable logic.
 Provision to capture deduction details for various expense heads such as
"House Rent", "Education Expense", "Household Expense" etc.
Capability to capture the frequency of deduction such as weekly, monthly,
quarterly
12.1.8.4 Capability to specify what fraction of a particular deduction head is to be Critical
considered for final computation
NRI: Capability to capture deduction against various heads in different
currency and to convert all deduction in base currency
"Total Deduction" computed as a function of the above

Provision to capture asset details for various asset types such as "Fixed
Deposit", "Vehicle", "House", etc.
12.1.8.5 Critical
Capability to capture different asset value in different currency and to
convert these in base currency.

Provision to capture liability details such as "Outstanding Balance",

"Installment Amount", "Installment Frequency", etc. for various existing
loans.
12.1.8.6 NRI: Capability to capture different liability details in different currency and Critical
to convert these in base currency.
Provision to specify whether or not the particular liability is to be considered
for "Net Disposable Income" and "Debt Burden Ratio" calculation.

12.1.8.7 Provision to compute Net take home income (NTH) Critical

12.1.8.8 Provision to compute Net Disposable Income (NTH-Obligation) Critical
Provision to compute existing ratios for loan metrics: e.g. Installment to
12.1.8.9 Critical
Income Ratio (IIR)
Provision with third party for financial analysis of Individual or non
12.1.8.10 Critical
individual
12.2 SENP Critical
12.2.1 Customer Profiling-SENP Critical
System functionality to define the system parameters to assess an individual
12.2.2 Critical
and assign rating scores against parameters
Facility to categorize the customer base based on risk:
Based on employment of applicant, co-applicant
Status of Employee
Age
12.2.2.1 Critical
Educational Qualifications
Tenure of Service completed vs remaining
Salary
CIBIL etc.
12.2.2 Financial Details for SEP and SENP Critical
Provision to upload the Financial Details of defined number of years for
"Self Employed Professional" and "Self Employed Non Professional".
Financial Details includes:
- Income & Expense Statement
12.2.2.1 - Balance Sheet Critical
- Ratio Analysis
- Cash Flow Statement & Analysis
Provision to display uploaded data.
Capability to attach the uploaded file.

Capability to upload the financial details.

12.2.2.2 Capability to maintain upload history. Critical
Capability to download the attached file.
 System Functionality to ensure document collected should be available
12.2.2.3 Critical
across screens and modules as desired by the application
12.3 Non Individual Borrower Critical
Provision to capture the identification details such as TIN No., TAN No.,
12.3.3.1 Critical
CIN No. etc.
12.3.3.2 Provision to capture the office/ business address. Critical
Provision to capture the details of Partners/Directors (name, designation,
12.3.3.3 Critical
holding % etc.).
Provision to capture the composition of directors in the organization such as
maximum & minimum no., number of directors based on their type such as
12.3.3.4 independent, nominees, outside etc. Critical
Provision to capture the details of Partners/Directors (name, designation,
holding % etc.).
Provision to capture the business details like Business Activity, Business
12.3.3.5 Critical
Model, Business Process etc.
Provision to capture the contact persons' details such as name, designation,
Email ID, Phone Number and address.
12.3.3.6 Critical
Provision to specify any of the contact persons as Primary contact.

Provision to upload the Financial Details of last few defined number years
Financial Details includes:
- Income & Expense Statement
- Balance Sheet
12.3.3.7 Critical
- Ratio Analysis
- Cash Flow Statement & Analysis
Provision to display uploaded data.
Capability to attach the uploaded file.

Capability to upload the financial details.

12.3.3.8 Capability to maintain upload history. Critical
Capability to download the attached file.
Storage of Aadhaar Numbers and any connected Aadhaar data
12.4 Critical
(e.g. eKYC XML containing Aadhaar number and data)
System Functionality to Record the Aadhaar number in the CRM/Lead
12.4.1 Management, Deposit, Lending, Insurance Modules or other modules as Critical
may be deemed necessary by the management at CFHL
System Functionality to conduct eKYC verification of the Aadhaar Number
with UIDAI in the CRM/Lead Management, Deposit, Lending, Insurance
12.4.2 Critical
Modules or other modules as may be deemed necessary by the management
at CFHL
System Functionality to record the Name, DOB, Address, Gender or other
details as may be deemed necessary by the management of CFHL based on
details mentioned in UIDAI database.
12.4.3 Critical
System Functionality to record the verified details in Lending, Deposit
modules or other modules as may be deemed necessary by the management
at CFHL
System Functionality to generate associated unique reference key.
12.4.4 System functionality to replace the Aadhaar number with the reference key Critical
across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of any transaction
12.4.5 where Aadhaar number is exchanged, the reference key to replace the Critical
aadhaar number, when needed.
 System Functionality to ensure the legacy data of the CFHL ecosystem be
stored and migrated to ADV:
All the existing Aadhaar related information to be stored in the Aadhaar
12.4.6 Critical
Data Vault.
Functionality to ensure that the scanned copy of the physical aadhaar card
be masked and stored in an encrypted format within CFHL database.

System functionality to replace aadhaar number in log database with

12.4.7 Critical
reference keys.
System functionality to fetch the Aadhaar information based on reference
number, if needed for regulatory purposes/other mandated business
12.4.8 Critical
engagements, but referenced through the key post the transaction, via APIs
to whitelisted IP addresses.
System functionality to conduct Re-KYC of the customer based on risk
12.4.9 Critical
category and update the same in ADV.
System functionality to conduct de-duplication checks based on unique
12.4.10 Critical
reference keys mapped against Aadhaar number.
13 Bank Account Verification Critical
System functionality to record the bank account details of applicant and co-
13.1 Critical
applicant
13.2 Facility to conduct penny-drop validation for account confirmation Critical
13.3 Facility to conduct name validation for confirming bank account holder. Critical
14 Customer Requirement Critical
Facility to document the product that the customer intends to take loan
Critical
14.1 against
14.2 Facility to incorporate the loan amount requested by the borrower Critical
System functionality to define the workflow and assign delegation flexibility,
Critical
14.3 where needed

Facility to support Loan Approval method on the basis of the delegation

power of the branch. Functionality to support the following:
1. Approval by the branch in charge, if the loan amount is within the
authority of the branch in charge
2. Approval by the Cluster head, if the loan amount is beyond the authority
Critical
of branch in charge but within the authority of the cluster head
3. Approval by the CCPC, if the loan amount is beyond the authority of
cluster head but within the authority of CCPC
4. Approval by the Registered Office, if the loan amount is beyond the
authority of CCPC within the Registered Office(Head office) authority
14.4

Facility to analyze if customer is eligible for PMAY-CLSS option - Yes/No.

Yes: Facility to capture and incorporate details like product code,
Critical
construction Details regarding the same
No: Facility to incorporate and document remarks for the same
14.5
14.6 Facility to document balance transfer cases from other financers Critical
Provision to authenticate and capture details of existing collateral marked aa
a liability to be considered for Balance Transfer Critical
14.7 Facility to capture the NOC details during Balance Transfer
14.8 Stage Based Disbursals Critical
14.8.1 Capability to support single disbursal as well as multiple disbursal. Critical
Capability to support stage based disbursals for under construction projects Critical
14.8.2
 Capability to make loan disbursal payment either to customer or associated
Critical
14.9 business partner (Dealer, Builder, etc.).

System functionality to capture the account details and facilitate e-NACH

facility
Capability to capture Installment mode (Arrear or Advance), Installment
Plan (Equated), Frequency of Repayment (Monthly, Bi-Monthly, Quarterly,
Half Yearly, Annually), Number of Advance Installments, Interest Rate Type Critical
(Fixed, Floating), Interest Rate, Interest Start Date, Moratorium Details.
Facility to capture the installment due dates in a cyclical manner till the
tenure of the loan account

14.10
Capability to deduct customer receivables (Partially or Fully) from loan
Critical
14.11 disbursal payment.
Capability to capture Collateral Details for Secured Loans.
Critical
14.12 Supports capturing of multiple collateral.
Supports adding a new collateral or attaching an existing collateral to a
Critical
14.13 credit application.
14.14 Supports "Collateral Dedupe" for property and vehicle collateral types. Critical
14.15 Supports display of Consolidated Financial Details Summary. Critical
14.16 Fee and Charges: Refer Corresponding section Critical
Module Collateral Set Up
15 Collateral Critical
Facility to capture the details of the security provided to facilitate loan
15.1 Critical
approval and processing
Facility to capture and maintain if additional collaterals are required for the
respective product
15.2 Critical
Capability to map different collateral type(s) that can be available for the
product respectively
System functionality to capture and maintain multiple collaterals against a
loan account number
15.3 Critical
Capability to display and input collateral details basis collateral type
selected.
15.4 Property Details Critical
Facility to capture property details for mortgage loans at detail data entry
(DDE) stage.
15.4.1 System functionality to input property details basis the data captured. Critical
Facility to have a unique property id/collateral id on saving the details of a
property
Provision to capture Property Address for the underlying property with
15.4.2 Critical
address type as property address
Provision to copy already defined address in the application as property
15.4.3 Critical
address
15.4.4 Provision to capture seller details if the Type Of Purchase is Resale Critical
System functionality to include and incorporate de-dupe on collateral
15.4.5 Critical
pledged by the borrowers
System functionality to assign the collateral across multiple loan
15.4.6 Critical
applications, if needed
15.5 Sub-type of Collateral Critical
15.5.1 System functionality to configure the sub-type of collateral Critical
 Provision to capture collateral sub-type like:
- Ready Property,
- Plot + Self Construction,
15.5.2 Critical
- Construction on Land &
- Builder Property Under Construction.
Ability to input property details basis the data captured.
System functionality to record and create new collaterals including but not
15.5.3 Critical
limited to masters for pre-approved projects
15.6 Collateral-Builder Loans Critical
Provision to capture Builder Details if collateral sub type is builder
15.6.1 constructed property. Critical
Ability to define it in Builder Property Setup.
Provision to capture general fields like Market Value, Area, Classification
15.6.2 Critical
etc.
15.7 Collateral-Resale Critical
15.7.1 Provision to capture seller details if the Type Of Purchase is Resale Critical
15.7.2 Provision to capture Agreement Details of the Property Critical
Provision to capture Current Ownership as well as previous ownership of
15.7.3 Critical
the Property
15.8 Provision to display summary of the Property details. Critical
Capability to auto calculate the Loan to Market Value of property (LTV) and
15.9 Critical
Loan to cost Ratio (LCR).
15.10 Provision to capture CERSAI details for collateral type property. Critical
Provision to capture insurance details of collateral.
15.11 Critical
Ability to capture add multiple insurance details for each collateral.
15.12 Provision to capture the details of the asset. Critical
Capability to display the summary of collateral details entered like Asset
15.13 Critical
Cost, Down payment etc. .
15.14 Collateral Verification Critical
15.14.1 Provision to initiate verification of asset/property details captured. Critical
15.14.2 Provision to have a valuation check of Asset/Property details captured. Critical
15.14.3 Provision to re-initiate collateral verification. Critical
15.14.4 Provision to re-initiate collateral valuation. Critical
15.14.5 Provision to initiate multiple valuation and verification. Critical
Capability to initiate valuation and verification to different agencies
15.14.6 Critical
respectively.
15.15 Facility to finally select the collateral and hypothecate the same Critical
15.16 Collateral documents to be uploaded and maintained in the system Critical
Module Deviation/Approval Management
16 Deviation Management Critical
16.1 Deviation Policy Critical
16.1.1 System facility to define deviation policies for raising exceptions. Critical
System facility to raise deviation at different application processing stages
like
- Detail Data Entry
16.1.2 - Recommendation Critical
- Credit Approval
- Post Approval
- Disbursal Stage
16.1.3 Facility to specify the list of mitigants with every deviation. Critical
System functionality to define the minimum authority level required for
16.1.4 Critical
approval of that particular deviation.
 16.1.5 System to map different deviation policy associated with different products Critical

Deviation policy associated with product is inherited by all the schemes

16.1.6 under that product. Critical
Option of attaching specific deviation policy for the scheme is available
During application processing, the associated deviation policy is executed
Critical
16.2 and raises the appropriate deviations automatically.
16.3 Deviation Approval-System Critical
System functionality to ensure that authorized approver can either
Critical
16.3.1 "Approve" or "Reject" the deviations
System functionality to ensure that credit approver has to
Critical
16.3.2 "View/Approve/Reject" the deviations raised
System functionality to re-route the deviations to the appropriate approving
Critical
16.3.3 authority that cannot be approved by the approver
System functionality to facilitate approver to choose one or more mitigants
Critical
16.3.4 while approving the deviation
System functionality to ensure recording of approver to be tracked, along
Critical
16.4 with date and time stamp
Provision to raise Manual Deviation at "Recommendation" and "Credit
Critical
16.5 Approval Stage".
Critical
16.6 Credit Approver can re-execute the "Deviation Policy" if any data is updated.
Module Fee and Charges
17 Fee and Charge Definition Critical
System functionality to support both receivable and payable types of Fees
17.1 Critical
and Charges.
System functionality to pre-define the fee and charges to be maintained for
17.2 Critical
various stages and components of loan sanctions and disbursals
17.3 Processing Fee Charge Definition Critical
Facility to support definition of "Upfront Processing Fee and Charges" as per
following:
17.3.1 - Fixed Amount Critical
- Percentage based (e.g. x% of loan amount)
System functionality to support Slab based fee and charges calculation
Supports minimum and maximum amount definition (in case of percentage
17.3.2 Critical
based calculation).
Functionality to capture minimum processing fee at the time of Credit
Bureau check
17.4 Critical
Facility to collect the balance of processing fee at the time of sanction, prior
to creation of loan account number
Facility for the branch user to seek approval through concise report for
17.5 Critical
concession on fees and charges
System functionality to provide break-up of fee and charges including but
not limited to:
17.6 Critical
CIBIL/Experian CIR, CERSAI charges, Legal Fee, Printing Stationary Fee
etc.
Facility to collect the processing fee through defined modes of payment,
17.7 enable and disable certain modes of payment Critical
System functionality for automate generation of corresponding voucher
 System functionality to define GST Taxation Rules, other taxes (surcharges)
17.8 if any Critical
Facility to supports Tax Inclusive as well as Exclusive Fee and Charge
definition
System functionality to capture the offer rates on fee and charges; waiver
17.9 Critical
and deviations if any
Module Valuation
18 Legal and Technical verification of Underlying Asset Critical
Module Technical Valuation
18.1 Valuation Critical
System Functionality to assign the empaneled valuers for the valuation of
18.1.1 Critical
property basis availability
Facility to map the valuer code to the assigned cases
18.1.2 Facility to assign the file number of the proposed loan cases to empaneled Critical
valuers
Facility to map single or multiple valuers to the file number based on ticket
18.1.3 Critical
size of the loan
18.1.4 Facility to submit an independent observation of property valuation Critical
Facility to incorporate builder module, layout module, builder master
18.1.5 Critical
module, employment master module, any other module etc.
Facility to upload and download the report provided by the valuers for fair
18.1.6 Critical
valuation of property.
Facility to compute and maintain the charges to be paid to each valuer for
18.1.7 Critical
the file numbers valued
System functionality to capture and map the collaterals and underlying asset
18.1.8 Critical
to latitude and longitude against geo-tagging
RO to have complete overview over the valuers and valuation as pr business
18.1.9 Critical
rules, before and after sanction
Module Legal Scrutiny
18.2 LSR Critical
System Functionality to assign the empaneled lawyer for the scrutiny of
18.2.1 Critical
property basis availability

Facility to map the empanelment code of the lawyer to the assigned cases
18.2.2 Facility to assign the file number of the proposed loan cases to empaneled Critical
lawyer

System functionality to assign legal scrutiny against/for multiple properties

18.2.3 Critical
as appended by the applicant
Facility to submit an independent observation of title deed/legal scrutiny
report
18.2.4 Critical
Facility to share the approval/rejection of LSR to credit team for further
sanction/rejection of cases
Facility to upload and download the report provided by the empaneled
18.2.5 Critical
lawyer for preparation of LSR
Facility to compute and maintain the charges to be paid to each lawyer for
18.2.6 Critical
the file numbers against which LSR is submitted
RO-legal to have complete overview over the valuers and valuation as pr
18.2.7 Critical
business rules, before and after sanction
Module Pre-Sanction Verification
18.3 Pre Sanction Verification Critical
 Agency Filtration
18.3.1 Supports configuration for "Agency filtration" on the basis of maintained Critical
Verification Type, City/Pincode and Product respectively.
History
18.3.2 Provision to view FI history at Field Investigation Initiation and Critical
Completion.
Supports view of all the FI record's status once FI initiated.
18.3.3 Critical
Facility to document the staff/agency conducting pre-sanction verification
Facility to conduct PSVR on multiple collaterals assigned against the loan
18.3.4 Critical
account
18.3.5 Facility to document pre-sanction verification Critical
18.3.6 Facility to upload and download the pre sanction verification report Critical
18.3.7 System functionality to mark: "Positive", "Negative" on PSVR Critical
System functionality to capture and map latitude and longitude against geo-
18.3.8 Critical
tagging

18.4 Critical
Facility to flag file numbers with cases where LSR and/or PSVR is not clear
Module Credit Profiling and Terms of Loan
19 Credit Profiling Critical
19.1 Cumulative Credit Profile Critical
Facility to define the credit scoring of the borrower based on captured
19.1.1 Critical
details
Facility to define the score as a cumulative function of: customer profile and
19.1.2 Critical
project profile
Facility to auto fetch the loan account related details from loan application
19.1.3 Critical
input for customer profile and project profile
Facility to automate the computation of cumulative score of customer and
19.1.4 Critical
project profile
Facility to compute the risk weighted score of co-applicant and averaged
19.1.5 Critical
with the score of applicant
19.2 Facility to display the final risk weighted score to the underwriter Critical
Facility to provide/assign the Loan Pricing (RoI) and EMI calculation on the
19.3 basis of the credit score along with computation of loan ratios: IIR, LCR, Critical
EMI calculation
19.5 Facility to configure installment due dates of the loan Critical
Module Moratorium
20 Moratorium Critical
Provision to use moratorium feature for cases where multiple disbursal is
20.1 Critical
selected.
Capability to have following types of Moratorium:
1) Moratorium In Principal Payment
20.2 2) Adjust in First Installment Critical
3) Adjust in Schedule
4) Interest Capitalization (with or without Compounding)
Capability during subsequent disbursal to capture details like:
20.3 - Charge Details and Adjustment Critical
- Moratorium Details
- Principle Recovery Details
20.4 System functionality to capture define and assign holiday period, if any Critical
Module Application De-duplication Check  
21 Application De-duplication Critical
 21.1 System functionality for user to log in into de-duplication search engine Critical
21.2 Facility to select product, and sub-product Critical
Facility to select application/deposit number for running the systemic de-
21.3 Critical
dupe checks
21.4 System functionality to create a de-duplication check ID Critical
System functionality to display the deduplication ID, Matched Customer ID,
21.5 Matched Parameters, Current Input Value, Matched Score, Data Source and Critical
matched parameters validity
System functionality for the maker to accept and suggest matched
21.6 Critical
parameter validity
System functionality to display the customer details post the de-duplication
21.7 Critical
check upon expanding UCIC number

Display details like (tentative but not limited to):

Customer Name
Customer Type
UCIC
21.8 Customer Name, Gender, DOB Critical
PAN, Passport, Aadhaar (against unique reference number as per ADV),
Voter ID, DL Number
Complete Address
Phone Number
Father/Mother/Spouse Name
System functionality to reflect the details filled in the application form
21.9 Critical
versus available in database
Facility to check, respond and correct the details in either the application
21.10 Critical
form or the UCIC module for the customer
Module Credit Approval
22 Credit Approval Critical
Facility to allocate the credit application to respective credit approver using
22.1 Critical
Assignment Definition
22.2 Facility to define sanction limit matrix for the Credit Approver. Critical
22.3 Provision for Credit Approver to edit the credit application details. Critical
22.4 Provision for Credit Approver to view the complete Credit Application. Critical

Capability to view the status of the documents.

22.5 Capability to update the collection status of the documents. Critical
Provision to add new document to be collected as per approver's decision

Functionality to define and execute rules based loan specific "Approval

22.6 Critical
Checklist"
Provision to view the final result of the credit application based on existing
CFHL credit policy
22.7 Critical
Provision to analyze the details of applicable credit policy based on rule level
results

Provision that a Credit Approver can view or edit the applicant information
of:
22.8 - Primary Applicant Critical
- Co-applicant
- Guarantor
- Add on Applicant
 System functionality to view the credit policy related deviation summary
22.9 through concise (Deviations raised vs Approved). Critical
Provision to view the details of the deviations raised along with approval
remarks.
22.10 Provision to Re-Run the Credit Policy. Critical

Facility to view the summary of the "Credit Bureau Check" result for each
22.11 applicant and co-applicant: Critical
System functionality to view the credit score of applicant and co-applicant
Facility to view the credit bureau detailed report for each applicant and co-
applicant
Provision to re-initiate the "Credit Bureau Check" for an
22.12 applicant/application. Critical
Re-Initiation can be done for a specific Credit Bureau or all the credit
bureaus.
22.13 Provision to view the final status of the Field Investigation. Critical
Facility to view the summary and details of various Field Investigations
22.14 Critical
performed along with its result.
22.15 Provision to re-initiate Field Investigation for one or more applicants. Critical
22.16 Provision to view the result of "KYC Check" for all the applicants. Critical
Capability to view the KYC details.
22.17 Critical
22.18 System Functionality to rerun the dedupe. Critical
22.19 RMD-Check Critical
Provision to view the results of the document's "Screening" and/or
22.19.1 Critical
"Sampling" done by Risk Management Department (RMD)
Provision to re-initiate credit checks observed by the RMD against internal
22.19.2 Critical
checks
22.19.3 Critical
Provision to view the Credit Score and Credit Score Rating of application.
22.20 Collateral Critical
22.20.1 Provision to view the status and details of the Collateral Valuation. Critical
22.20.2 Provision to view the status and result of the Collateral Verification. Critical
Facility to review and comment on the LSR status submitted by the
22.20.3 Critical
empaneled lawyer
22.21 Collateral History Critical
22.21.1 Provision to view the history of Collateral Verifications. Critical
22.21.2 Facility to view the history of Collateral through CERSAI. Critical
22.21.3 Provision to view the history of collateral valuations by the valuers Critical
22.22 Ability to reinitiate the Collateral Verification. Critical
22.23 System Limits Critical
Capability to display the maximum eligible loan amount for the product and
22.23.1 Critical
scheme selected for the application.
Capability to check eligible amount for all the active schemes under the
22.23.2 Critical
product selected in the application.
Capability to calculate and display various ratios like EMI to Income Ratio
(IIR), Loan to Value (LTV)
22.24 Capability to configure the ratios to be displayed based on product types Critical
Functionality to display formula of ratios configurable in the system for
better comprehension and analysis by users
22.25 Deviations Critical
 System functionality to define Deviations for non compliance of "Approval
22.25.1 Critical
Checklist".
System functionality to raise Deviations for Non Compliance of "Approval
22.25.2 Critical
Checklist".
Capability for Credit Approver to "Forward" the application to other
22.25.3 approving authorities. Critical
Capability to notify via e-mail to the user to whom the application is
forwarded.
System functionality to view the credit policy related deviation summary
22.25.4 through concise (Deviations raised vs Approved). Critical
Provision to view the details of the deviations raised along with approval
remarks.
Facility to raise and define Deviations for non compliance of "Approval
22.25.5 Critical
Checklist".
Provision to view all the deviations raised for the application along with its
22.25.6 Critical
status.
22.25.7 Critical
Provision to Approve/Reject deviations (based on Role and Deviation level).
22.25.8 Provision to add mitigant(s) for every deviation. Critical
Provision to raise deviation(s) manually. The same can be assigned to a
22.25.9 Critical
specific user.
Provision to Rerun the deviation policy.
22.25.10 Critical
22.26 Post Deviation Credit Approval Critical
22.26.1 Critical
Facility to re-initiate and re-run the credit policy refreshed after deviations
Facility to edit the terms of the loan: "Sanctioned Amount", "Sanctioned
22.26.2 Processing Fee", "Underlying Collateral", "Sanctioned Tenure" and Critical
"Sanctioned Interest Rate" for the application.
22.26.3 Facility to specify the final credit decision with reason and comments. Critical
Facility to reject the loan basis the review of loan account during credit
22.26.4 approval stage Critical
Facility to cancel sanctioning of the loan account upon the request of
borrower
Facility to attach special condition(s) to a credit application leading to
22.26.5 Critical
conditional approval of credit, if any
Provision to input the decision justification.
22.26.6 Credit Approver can input the strengths and weaknesses for Character, Critical
Capability and Collateral.
Facility to capture the Executive Summary as well.
22.27 Approval History Critical
Capability to maintain the decision history of the credit application for all
22.27.1 Critical
the referral stages
22.27.2 Critical
Capability to maintain the forwarding history of the application on concise
Facility to raise deviation(s) in case ROI for the loan case is less than the
22.28 Critical
desired ROI
Provision to re-execute various policies and checks on edit of Credit
22.29 Critical
Application by Credit Approver
System functionality to review and sign off the credit approval checklist
22.30 Critical
prior to final approval of loan account
22.31 Facility to approve the credit by approver(s). Critical
 22.32 De-Duplication Checker Critical
System Functionality to include provision for checker in the de-duplication
22.32.1 Critical
search engine module
System functionality to ensure that dedupe verifier checks & verifies the
22.32.2 Details of each & every Parameter between the Request & Response and Critical
then decides to Approve or Reject the Customer Code to avoid the duplicate
detail[s] of the UCIC

22.32.3 System Functionality to mark the case as checked & verified by the Approver Critical
ensuring the details are appropriate while comparing the Request &
Response details, then the Approver selects the option ‘Valid’ from the list
For modifications in customer data post de-duplication checks, the user
selects UCIC mapped from data base.
22.32.4 Once the appropriate UCIC is selected, the checker clicks the Update Critical
Dedupe Status button for updating the details of the Customer, thereby,
updating the details
Rejection of de-duplication results/UCIC:
22.32.5 Post de-dupe, if the maker-checker are not satisfied with the details while Critical
comparing the Request & Response details, then the checker selects the
option ‘Invalid’ from the list
Module Loan Sanction
23 Sanction Critical
23.1 Sanction Letter Critical
System functionality to generate Sanction Letter for the applications post
23.1.1 Critical
credit approval.
System functionality to modify and update the sanction letter for
23.1.2 Critical
reconsiderations, if any
Sanction Letter will be generated in a predefined file format which can be
23.1.3 Critical
printed.
System functionality to configure the static and dynamic part of sanction
23.1.4 letter within the module: static being common and dynamic part Critical
configurable for product types.
System functionality to capture the details entered by the branch as input
23.1.5 Critical
for all the dynamic entries and print on the sanction letter

23.1.6 Facility to track the timeline for approval by the customer on sanction letter Critical

Facility to record configure and consider revalidation changes if sanction

23.1.7 Critical
letter is not accepted by the borrower within 30 days, 60 days
23.1.8 Facility to configure charges for re-validation at sanction stage Critical
Revalidation routing an deviation approval basis the business rules
23.1.9 Critical
configurable, if needed
System functionality to delegate loan sanctioning power to next in line
23.1.10 authority in case of deviation - eg: resignation or absence of a branch in Critical
charge. The necessary approval for The same from The different teams - HR
and Credit team should be within The system.
Capability to check the Sanction validity of an application
23.2 Critical
Provision to initiate disbursal only if Approval validation is not breached

Capability to capture 'Sanction Date' and 'Sanction Expiry' of the application

23.3 Critical
Provision to maintain 'Sanction Validity (Days)' in Scheme/Product

Facility to re-initiate application based on business rules; considering lapse

23.4 Critical
of timelines at the stage of sanction letter etc.
 Facility to re-initiate along with re-validation of loan account, basis new
23.5 Critical
terms
System functionality to define the number of times re-validation can be
23.6 Critical
done
System to define the establishment of sanction date (not changed), re-
23.7 Critical
validation date basis revised T&C
23.8 System functionality for registry creation for CERSAI Critical
Integration with CERSAI for the purpose of updating the asset details in
23.9 CERSAI and generating the CERSAI search report. Critical
The CERSAI charge creation in the system to be automated.: ASSET ID AND
SECURITY ID
System to not allow sanction until all the mandatory documents are either
23.10 Critical
"Received", "Waived" or "Deferred".
Module Loan Review Mechanism
24 Loan Review Mechanism - Before Disbursal Critical
System functionality to incorporate loan review mechanism basis business
24.1 Critical
rules and management discretion
System functionality to assign authority for loan review mechanism after
24.2 Critical
sanction but prior to disbursals
Facility to seek and resolve queries, mitigants, approve reject or hold loan
24.3 Critical
applications.
Module RO Bucket
25 Legal Vetting Critical
Facility for define the credit authorization limit (loan amount as sanctioned
25.1 after credit approval) above which the agreement shall be routed to RO legal Critical
team for review
25.2 Critical
System functionality to track and manage legal audit for stated loan amount

25.3 Facility for legal team to review agreement for loan application where Critical
sanctioned amount is more than the credit authorization limit stated above

25.4 Functionality for creation of sale deed draft approval, documentation and Critical
legal audit from empaneled lawyer before and after sanction (if needed)
26 Credit vetting Critical
Facility for define the credit authorization limit above which the agreement
26.1 Critical
shall be routed to RO credit team for review
Credit authorization for the loans above INR 75 lakh should be withing the
26.2 system and with RO credit team where sanctioned amount is more than the Critical
credit authorization limit stated above
Module Insurance
27 Insurance Critical
Integration with the Insurance module for the purpose of property
27.1 insurance. Property insurance is mandatory for housing loans and hence the Critical
system should be able to link the property insurance with the lending
module.
System functionality to allow the insurance partner to upload the insurance
27.2 Critical
policy against the loan application number for the stated loan
Facility to fetch and manage the insurance policy basis identifiers: Loan
27.3 Application Number, Customer Name, UCIC, Insurance Policy Number etc. Critical
and other customizable identification parameters
28 MODT Critical
 28.1 MODT to transfer the ownership of the asset from borrower to CFHL Critical
System functionality to capture/track/manage all the legal documents in the
28.2 Critical
system for creation of MODT
28.3 System to ensure flag the loan account as "perfection for security" Critical
Module Disbursal
29 Disbursals Critical
Provision to initiate disbursal request so that amount can be disbursed to
29.1 Critical
applicant
30 Masters Critical
System should have the provision to create / amend / delete master tables as
30.1 Critical
per the requirement of business.
31 Reports Critical
The system should be able to create customized reports as per the
requirement of the credit team.
31.1 Critical
The system should have a filtering mechanism for the business user to
generate only the required items of the report.
32 Geo-Tagging Functionality Critical
System functionality to capture latitude and longitude basis geo-tagging
32.1 functionality. Critical
Geo-tagging functionality as per the management discretion
33 De-Duplication Functionality Critical
System functionality to incorporate, integrate and run de-duplication as per
33.1 Critical
the management discretion
Please populate only these columns with your responses

Bidder
Bidder Clarifications /
Response
Comments
(S/A/C/U)
LMS
Sheet 2: LMS

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement

Module Disbursals
1 Disbursals
Provision to validate sanction request from LOS, and initiate disbursal request so that amount
1.1
can be disbursed to applicant
System functionality to configure the mode of disbursal payment basis the ask of applicant
- Cheque
- Demand Draft
1.2
- Transfer in the Operative Account
- NEFT
- RTGS

Provision to configure the information details related to disbursements to be made and future
disbursements required.
(e.g.
1.3
Sanctioned Amount, Sanction Date,
Disbursal Type, Disbursal Status, Disbursed Amount, First Disbursal Date
Future Disbursal Schedule/Date/Amount etc.)
System functionality to configure and manage a pre-disbursal checklist configured through
1.4
UCIC, LOS, Lead Modules
1.5 Capability to have one time disbursal, or in multiple traches as defined in LOS.
System functionality to automatically generate a loan account number immediately upon
1.6
processing first disbursal
Capability to disburse the loan amount to more than one entity/ business partners (e.g.
1.7
disbursal to be made to a customer & dealer)
1.8 System functionality to ensure and include limit restriction before each disbursal
System functionality to configure and re-validate technical valuation with assignment of
1.9
technical valuer to each loan account prior to subsequent disbursals, including geo tagging
Provision of handling subsequent disbursal(second and onwards disbursal cases) for the loans
1.10
that have been partially disbursed.
System functionality to create login details, along with reference code for the customer to service
1.11
the loan lifecycle, map referral code
Provision to view and generate PDF file of the Repayment Schedule based on the loan
1.12
parameters captured for disbursal type.
2 Loan Account Management - View only
System functionality to maintain and manage the loan account throughout ongoing loan
2.1
management cycle
Each loan account in system will be referenced with the UCIC and/or loan account number
and/or Loan application number
2.2
System functionality to display entire loan account details with all parameters from lead
generation through collections to closure
 System functionality to map the loan account numbers against the applicant/co-applicant,
2.3 functionality to fetch and map financial product history of all products of applicant/co-
applicant, followed by transaction history against their respective loan accounts
2.4 System functionality to post and pass voucher for corresponding accounting entries
Corresponding Accounting Entries of loan accounts:
During day/month/quarter/year end to accommodate all the transactions from the last day of
2.5
the month till the time/day the period closure activities are complete in the system
Transactions reversals and transaction schedule

System should allow End of Day, End of Month, End of Quarter, End of Half-Yearly, End of Year
2.6
closing processes and initiate relevant accounting entries to be posted in the accounting system

System functionality to update the borrower's account with opening/closing balance at defined
2.7
intervals as per secretion of management
3 CERSAI Integration
3.1 System functionality for registry creation for CERSAI
3.2 System functionality for registry modification for CERSAI
3.3 System functionality for registry satisfaction for CERSAI
Integration with CERSAI for the purpose of updating the asset details in CERSAI and generating
3.4 the CERSAI search report.
The CERSAI charge creation in the system to be automated.: ASSET ID AND SECURITY ID
System functionality to revise the CERSAI registry creation, modification, satisfaction upon
3.5
revision of underlying collateral
Module Collections and Recovery
4 Collection of EMI Payment
4.1 Modes of Collection Payment

Facility to configure following modes of EMI payment by customers:

1. Post Dated Cheques (PDC: for very old cases, discontinued for new disbursements)
2. ECS: Electronic Clearing Services (For old cases, discontinued for new disbursements)
3. e-NACH: For all new disbursements
4.1.1 4. Automated salary deduction based on agreement with corporations/institutions
5. Online Money Transfer: Payment by customer through the CFHL website (Online Money
Transfer)
6. Remit Cash payments at CFHL branch and Current Account of CFHL maintained with Canara
bank: <200,000 per day
7. Online Payments to CFHL Current Account of branches maintained with Canara Bank
4.2 Online Money Transfer
4.2.4 The system shall authenticate the User Id and Password
4.2.2 CFHL shall be able to parametrize the password policy
4.3 NACH (National Automated Clearing House) Presentment
4.3.4 System functionality to prepare worksheet for presentment of payment due form applicant
4.3.2 System functionality to perform bulk actions on a group of loan accounts and automatically post s
4.4 Post Dated Cheques (PDC)
4.4.4 PDC presentment, date, cheque number, collection of further PDC
4.5 Automated presentment of payment entries against successful collection to branches for automat
4.6 Automated presentment of payment entries for salary deduction against pre-approved PSU corpo
Facility to provide for handheld device for collection and recovery agents, collection staff for
4.7
recovery and collection purposes
 Ability to capture the loan account details of the accounts meant for recovery along with the
details of:
Customer Name, Co-Borrower Name
KYC Details (unique reference number mapped as per ADV)
4.8
Address
Contact Details
Collectible Amount (Asa sum of Principal Amount, Interest Amount, Penalty Charges, Misc.
Charges, as configurable by the management)
Integration of the collection and recovery of the handheld collection device with the core
4.9
banking solution system
System functionality to include the digital modes of collection including but not limited to QR
4.10
Code (Dynamic/Static), Debit Card, Net Banking, UPI etc.
4.11 System functionality to record the details of payment to the branches for processing of vouchers a

System functionality to provide alternate mechanism for payment of outstanding amount (in
addition to current process of OMT):
Customer ability to view the Loan Account details on Mobile Application
Customer ability to transact and complete the payment of the outstanding amount through the
4.12
handheld mobile application
Facility to view live and running loan accounts with the CFHL
Proposed new loan products which can be cross sold and up sold to the borrower along with the
facility to apply for the loan/associated products
Customer ability to download the Income Tax Certificate and other statutory documents
Module Loan Account Status
5 Loan Account Management Functionality
5.1 Over Due Categorization
5.1.1 System facility to record and manage trail of all follow up activities performed for recovery agains
5.1.2 System functionality to define various buckets/categories on which the loan with dues can be cla
5.1.3 System functionality to classify loan accounts into various delinquency buckets (SMA category) o
5.1.4 System functionality to store historical data on SMA categorization /buckets (basis days pas

System to classify an account as overdue when:

1. Amount due on a contracted date is not received, the account becomes overdue by 1 day on the
5.1.5 day following the EMI payment due date
2. The system should provide an option for accommodating grace days for receipt of EMIs which
would be user definable
3. An account would be classified as an NPA, when the account becomes overdue by 90 DPD

Systems should provide a workflow for allocation of default cases for analysis and next action to
be specified (role-based access as per the predefined work flow). At the time of re-allocation, the
5.1.6 system should provide the following details -
- The number of days the account was allocated to the previous user and the amount collected
by the user
- The number of users to whom the loan account was allocated to
 System should be able to define the classification of loans into various buckets on the basis of
the outstanding EMIs:
a. SMA 0:0-30 DPD
b. SMA 1: >30-60 DPD
5.1.7
c. SMA 2: >60-90 DPD
d. NPA: 90+ DPD
System facility to automatically allocate the buckets mentioned above based on condition if:
1. Amount due on a contracted date is received or if the due amount has bounced
2. Roll Forward/ Roll Backward/Stabilized based on number of EMI received
3. Loan account becomes overdue by 1 day on the day following unrealized EMI payment
4. An account would be classified as an NPA, when the account becomes overdue by 90 DPD
5. All loan accounts of the customer are deemed NPA, if even one of the loan accounts is NPA
6. The solution should provide for automatred NPA recognition through system.
5.2 Search/Review of Loan Accounts

System should provide a comprehensive search mechanism to identify the collections status of
loan accounts based on filtered fields
Loan Account Number
5.2.1 SMA
Customer Profile
Linked Accounts (Loans/Deposits)
Customer ID
5.2.2 System assignment of default accounts should be based on the segment/customer profile/Bucket
5.2.3 System should have a provision to manage and review defaulted accounts across all collection se
5.3 Change in Customer Master Data
5.3.1 System should allow the updating of master customer data (e.g. current address) through the rec
5.3.5 System should be able to capture the correspondence address preference including but not limite
Module Promise to Pay
6 Capturing Promise to Pay (PTP)
6.1 Preparation of Calling Reports
6.1.1 System functionality to define/customize tele calling reports based on filters to be fetched for ca
Functionality to capture information regarding interaction of call center team and borrowers
6.1.2 including:
Calling date and status of the activity such as whether contact was a visit/call or no Response are
also entered.
6.1.3 Functionality of module to display last payment information, and contact information. The commen
6.1.4 Facility to record the Promise to Pay date (PTP) and record the voice recordings in disposition sh
6.2 PTP Recording
System Functionality to set pre-defined limit post which PTP may not be accepted e.g. if the PTP
6.2.1 is more than the next EMI date
Functionality to ensure validation checks for data entry, e.g. if Promise to Pay date (PTP) agreed
is greater than pre-defined limit, system to record justification
6.3 Facility to prepare report for downloading to branches in a pre-defined format
6.4 System functionality to download the PTP mapped to the respective branches against the loan ac
6.5 System should record of all the accounts where the PTP is not adhered to
Module Branch Follow Up: Tracking and Management
7 Branch Follow Up
 Functionality to capture information regarding interaction of branch officers and borrowers
7.1 including:
Calling date and status of the activity such as whether contact was a visit/call or no Response are
also entered.
7.2 Functionality of module to display last payment information, and contact information. The comment
7.3 Subsequent Follow-up
7.3.1 The system should allow branch officers to keep information about the customer’s promises. Branch
7.3.2 System functionality to schedule follow-up appointment calendar, Workload indicator, bookmarks
8 Activity Schedule

The system should have the capability to define status for defaulted loan accounts. The status is
used to generate activity schedule for branch officers. These schedules can be prioritized based
on specific requirements. Status will enable the officers to manage the progress of accounts.
8.1 Examples of states are:
- Promise to Pay
- Waiting to be called
- Minimal balance and fees
- Broken promise
- Pending promise
8.2 System functionality to provide a monitoring screen/reports for branch manager, regional collect
8.3 Sort and Filter
8.3.1 System should provide a provision for future action and follow up prioritization/ Reminder upda
8.3.2 System should give a provision for sort/filter and view cases assigned to them according to their
9 Supervisory Review
9.1 Functionality to ensure that collection team hierarchy should monitor the collection activity at a
9.2 Functionality to route/re-route accounts to agencies/collection officers/agents etc.
9.3 System should provide monitoring assistance to the collection officers through reminders such a
The users should have a provision to Monitor their own daily performance with a real-time
9.4 dashboard of collections
All actions performed by the collection officer (no. of visits, no. of calls, no. of reminders issued
etc) are logged for the historical review
10 Expense Recording
10.1 System shall have the capability to record all expenses associated with recover of loan account
11 Re-classification
For accounts where any collection is accounted, the system should automatically reassign those
11.1
accounts to buckets predefined in the system
Facility to regularize the linked loan accounts with NPA accounts where the customer has paid
11.2
up the outstanding dues in totality
11.3 Facility to automatically roll-back the bucket for loan accounts (across SMA buckets) where cu
12 NPA
12.1 An account would be classified as an NPA, when the account becomes overdue by 90 DPD
12.2 For a customer, whose one loan is classified as NPA, the customer's linked loan accounts should a
Module Regulatory Notice Generation
13 Notices
13.1 System should have a provision for the reminder letter, collection notice should be generated bo
13.2 System functionality to define the static and dynamic part of notices in predefined format
13.3 Facility to auto incorporate the dynamic entries from the system for automated generation of noti
Module One Time Settlement
14 Settlement
14.1 Sources for One Time Settlement
 System functionality to record the customer request for settlement of loan account
14.1.1. 1. Through branch walk-in
2. Through alternate channels
3. Through telecall during collections, upon satisfaction of BM
14.2 One Time Settlement
System should provide the ability to capture settlement terms with a workflow for approval of
14.2.1
the case with assigned authority
Facility to record the details of one time settlement (OTS) and generate report by date of NPA,
14.2.2 value of property, ROI, unapplied interest, waiver of interest/principal based on delegated
powers
System should facilitate automated computation of final amount to be paid for a OTS performed
14.2.3 for a definite loan account -
Computation of Interest, Principal, penal interest and SARFESAI Expenses (legal charges,
prepayment charges etc)
System should facilitate to pull out a report of the number of OTS performed for a definite
14.2.4
period
14.3 Expiry of One Time Settlement request
System should block the One Time Settlement beyond the date committed in the system.
14.3.1
Exception to this to be based on approval as per the defined workflow
Module Case Management
15 Legal
15.1 Legal Cases
The system shall have the facility to track and record all the activities being performed for the
15.1.1
repossession and eventually sale / auction of the property
15.2 Sec 138
15.2.1 System functionality to define the notices to be sent to borrowers in case of default
System functionality to incorporate the standard template with static and dynamic part of the
15.2.2
notices
System functionality to record the dates of previous notices and communication being sent to
15.2.3
applicant and co-applicant
Facility to auto incorporate the dynamic entries from the system for automated generation of
15.2.4
notices
System functionality to record the notices being sent to applicant and co-applicant including
15.2.5
date and courier tracking number
Facility to auto incorporate the dynamic entries from the system for automated generation of
15.2.6
notices
Functionality to integrate the properties under Sec 268 to external agencies for physical
15.2.7
possession.
15.3 Auction

System should provide a module to track and manage inventory of repossessed properties and
15.3.1 sales process including entry of parameters like possession date, valuation details (market value,
distress sale value, realizable sale value), reserve price, sale price, auction date, no. of bidders,
no. of failed auctions, name of highest bidder, highest bid amount, date of sale confirmation,
date of registration, date of EMD received, date of full and final payment received etc.
Any receipt which is not in line to the payment schedule needs to be approved as per the defined
15.3.2
authority matrix

15.3.3 System will allow the generation of sales certificate release of documents when the account is
categorized as "Sold under auction" by the user and approved as per the authority matrix
15.4 Collection Post Auction
15.4.1 System Functionality to capture the loss or gain on properties sold under auction
15.4.2 Facility to make excess payment recovered under auction to the borrower
15.4.3 Facility to record and recover loss on auctioned property from the borrower
16 Provisioning

System functionality to automatically enable provisioning of underlying loan accounts based on

provisioning norms of RBI under the following categories (standard, sub-standard, doubtful 1,
doubtful 2, and loss assets)
16.1
The solution should enable provisioning on the above categories as per the Master Direction
issued by RBI as on 2022 - Master Direction - Non Banking Financial Company - Housing
Finance Company (Reserve Bank) Directions, 2021 - RBI/2020-21/73
DOR.FIN.HFC.CC.No.120/03.10.136/2020-21

17 Collections - View Only & Reports

System functionality to present all the modes of repayment (PDCs, ECS, Salary Mandates, Bank
17.1 transfer (NEFT, RTGS, OMT)) at pre-defined repayment frequency as recorded by the applicant
in LOS against loan account at sanction stage
System functionality to view status of repayment, including DPD/SMA, against loan account for
17.2 different modes of repayment (PDCs, ECS, Salary Mandates, Bank transfer (NEFT, RTGS, OMT
etc.)
System to allow crediting the customer account on receipt of cash payments on completion of
17.3
the authorization by the defined user
System shall have the feature to configure the generation of the Instalment Advice "X" days in
17.4
Advance

System functionality to configure alerts and send reminder SMS/e-mail to the applicant, co-
17.5
applicant and registered e-mail address XX (configurable) days before the installment due date

System to automatically categories an account to NPA when it moves to 90 (configurable) days

17.6
outstanding. The parameter needs to be user definable

System should have provision to classify all borrower a/cs as deemed NPA if any account of that
17.7
borrower turns NPA. Accounting entry for NPA provisioning and income reversal to be triggered

If an NPA account becomes regular at a later date, the other accounts classified as NPA by virtue
17.8 of being accounts of the same borrower, should automatically become regular accounts if
otherwise in order.
18 Penalty and Charges-View Only

System Functionality to display all the charges (configured at product definition stage) for
different activities during the lifecycle of loan such as:
- Stamp Duty
- Rescheduling Charges
- Moratorium Charges, if any
- Bulk Refund Charges
18.1
- Penal Interest
- Late Payment Penalty
- Fore Closure Charges
- Bounce Charges
- Ad-hoc Charges
Any other charges that may needs to be configured

System should track accounts where payment presentment has bounced and levy cheque bounce
18.2 charges. The charges and the penal interest are accounted on accrual basis and adjusted for cash
received basis
 The system shall allow the user to waive the charges. A partial waiver of the charge shall be
18.3
allowed

19 Unscheduled Payment
19.1 Facility to apply the charges for unscheduled payments (pre-defined in product masters)
19.2 Adjustments in loan accounts as per the unscheduled payment made by the applicant
19.2.1 The charges can be either adjusted from the payment amount or it can be recovered separately
19.2.2 Option to reduce the loan tenor or instalment amount as a result of Unscheduled payment
Capability to have broken period handling with Interest Charge method as:
1) Adjust in First Installment
19.2.3
2) Adjust in Schedule
3) Charge Separately
Module Automated System of Risk Rating
20 Reset of ROI
20.1 System functionality to configure and establish rules for upward revision of rate of interest
Facility to ensure that upward revision in the rate of interest for loans is effected to loans
20.2
including those sanctioned and outstanding on the date of change in ROI
20.3 Facility to ensure that downward revision is effected to loans granted prospectively
System functionality to conduct annual reset and auto-apply revised rate of interest for
20.4
customers

20.5 Auto-change of rate of Interest basis re-risk rating and apply revised interest rate to customer.
20.6 System functionality to record deviations needed
20.7 System functionality to record the maker-checker, approver along with date and time stamp

System functionality to suggest application of revised ROI based on re-risk rating as per
20.8
management discretion
20.9 System Functionality to suggest flagged loans, if any
21 Re-Risk rating-Credit Team
21.1 System functionality to conduct re-risk rating of customer basis discretion of credit team
Basis suggestion of credit team, facility to configure and establish rules for upward revision of
21.2
rate of interest at the discretion of management
21.3 Facility to ensure that downward revision is effected to loans granted
21.4 System functionality to record deviations needed
21.5 System functionality to record the maker-checker, approver along with date and time stamp

System functionality to suggest application of revised ROI based on re-risk rating as per review
21.6
of credit team and management discretion
21.7 System Functionality to suggest flagged loans, if any
Module Post Disbursement ROI Reduction Request
22 ROI Concession module:
22.1 System functionality to record the customer request (link letter) for seeking ROI concession
22.2 Facility to switch the account to annual reset mode
System functionality to establish deviation rules and record deviations needed to service ROI
concession to customers
22.3
Facility to record the maker-checker, approver for ROI deviation provide with date and time
stamp, along with comments and mitigants
System functionality to modify and apply the revised ROI automatically and adjust repayment
22.4
schedule payment
22.5 System functionality to levy ROI concession charges, where needed
 System functionality to define rules for flagging loan account for treatment of ROI as per
22.6
business / regulatory rules
Module Composite to Site Loan
23 Auto conversion of Loan Account
23.1 System functionality to record the construction status as per credit policy of CFHL
23.2 Facility to conduct and record the status of construction in PSIR
System functionality to auto convert composite loan to site loan in case the construction has not
23.3
taken place within the stipulated time as per CFHL Credit Policy
23.4 Facility to define/re-define rules for adjustment to be made as per the
System facility to auto calculate differential interest retrospective from the date of first
23.1
disbursement and debit the respective account with following changes
Facility to incorporate ROI as applicable to Site loan Interest as per the prevailing card rate on
23.6
the date of conversion
23.7 Facility to recompute and suggest revised EMI to be arrived on outstanding.
System functionality to keep checks and balances
E.g. ensure O/s. is not more than the loan disbursed amount after debiting the differential
23.8 interest retrospective from the date of first disbursement, if so, disbursed amount should be
taken as outstanding, showing balance amount as overdue) for balance left out tenure as
applicable to site loan keeping sanction date as base and redraw schedule.
23.9 Facility to restrict loan account where needed
Module Product Conversion
24 Change of product code during the tenure of the loan
System functionality to establish rules for conversion of loan account from one product code to
24.1
another product code
System functionality to incorporate deviation module and rules, as per product/business
24.2
discretion
Facility to record deviation being managed, and approve along with approver name,
24.3
designation, date and time stamp
24.4 GRHS / LUH / New GRHS / New LUH to IHL / Composite loan / CHL
24.4.1 Facility to restrict amount of loan quantum under product categories
Facility to auto-change product code, basis completion/starting of a specific lending product.
24.4.2 For eg: Product code for construction building should be changed to product code for flats as the
Construction is completed and the builder updated about the same.

System functionality to include scenarios for increase in sanction amount on account of

24.4.3
escalation in the cost, repair and renovation and/or extension or personal loan/mortgage loan

24.4.4 Functionality to include workflow for inadvertent sanctions

24.5 IHL to CHL/LCP
Facility to incorporate borrower request for additional loan on account of additional
24.5.1
construction
24.5.2 Construction of additional units without information of branch as identified in PDIR
24.5.3 NHB / RBIA inspections
24.6 Composite loan to Site loan: Covered Separately
Provision to attach additional documents, history to be maintained, deviations sought and
24.7
approved
25 Modification of Misc. Parameters
25.1 System functionality for Restructuring of EMI - including staggered EMI
25.2 System functionality to restructure repayment tenure, repayment schedule
System functionality to incorporate change in resident status: Resident loan to Non-resident
25.3
loan and vice versa
25.4 System functionality to incorporate change in mode of repayment
 25.5 System functionality to incorporate collection and recording of charges related to changes, if any

25.6 System Should facilitate marking of Loans as Restructured for Regulatory reporting purpose.

System functionality to incorporate calculators for modification of loan clauses before

25.7
facilitating the modification/re-structuring
25.8 All modification in the terms of the loan to be completed post maker and checker process
Facility to define the conditions or restriction to assign flags to loan accounts
System functionality to mark mitigant parameters for unflagging the loan account
25.9 Facility to mark the loan accounts as flagged
Facility to unflag the loan account
Audit trail for flagging and un-flagging to be maintained
Module User request
26 Branch User Request
26.1 System functionality to develop a master list for user request to be generated by branch
26.2 Facility to map the department to who the request is to be mapped/routed to
26.3 Facility to create masters for resolution of user request

Customer Change Request:

All KYC changes to be completed in UCIC module and mapped across all CFHL products and
customer masters
For Aadhaar KYC updating, mapped to reference key as per ADV
e-KYC:
e-KYC of PAN:
a. System functionality to conduct eKYC of PAN for the application in the CRM/Lead
Management, Deposit, Lending, Insurance Modules or other modules as may be deemed
necessary by the management at CFHL
b. System Functionality to record the Name, Validated PAN Number or other details as may be
26.4 deemed necessary by the management of CFHL based on details mentioned in NSDL database.
System Functionality to record the verified details in Lending, Deposit modules or other
modules as may be deemed necessary by the management at CFHL
e-KYC of Aadhaar:
a. System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the
CRM/Lead Management, Deposit, Lending, Insurance Modules or other modules as may be
deemed necessary by the management at CFHL
b. System Functionality to record the Name, DOB, Address, Gender or other details as may be
deemed necessary by the management of CFHL based on details mentioned in UIDAI database.
System Functionality to record the verified details in Lending, Deposit modules or other
modules as may be deemed necessary by the management at CFHL

26.4.1 Change Request for Aadhaar

System Functionality to Record the Aadhaar number in the CRM/Lead Management, Deposit,
26.4.1.1 Lending, Insurance Modules or other modules as may be deemed necessary by the management
at CFHL
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the
26.4.1.2 CRM/Lead Management, Deposit, Lending, Insurance Modules or other modules as may be
deemed necessary by the management at CFHL
 System Functionality to record the Name, DOB, Address, Gender or other details as may be
deemed necessary by the management of CFHL based on details mentioned in UIDAI database.
26.4.1.3
System Functionality to record the verified details in Lending, Deposit modules or other
modules as may be deemed necessary by the management at CFHL

System Functionality to generate associated unique reference key.

26.4.1.4 System functionality to replace the Aadhaar number with the reference key across the entire
ecosystem of CFHL.
System Functionality to ensure that post completion of any transaction where Aadhaar number
26.4.1.5
is exchanged, the reference key to replace the Aadhaar number, when needed.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to
ADV:
26.4.1.6 All the existing Aadhaar related information to be stored in the Aadhaar Data Vault.
Functionality to ensure that the scanned copy of the physical Aadhaar card be masked and
stored in an encrypted format within CFHL database.
26.4.1.7 System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the Aadhaar information based on reference number, if needed for
26.4.1.8 regulatory purposes/other mandated business engagements, but referenced through the key
post the transaction, via APIs to whitelisted IP addresses.
System functionality to conduct Re-KYC of the customer based on risk category and update the
26.4.1.9
same in ADV.
System functionality to conduct de-duplication checks based on unique reference keys mapped
26.4.1.10
against Aadhaar number.
Any change made to the customer master data, system should trigger an SMS/email to the
26.5
customer
User Escalation:
26.6 System to have a provision for escalation of customer complaints as per the predefined authority
level set in the system
26.7 Document Management Retrieval
System should reflect customer requests for retrieval of property or loan related documents or
26.7.1
any loan related requests
System functionality to ensure that all the documents related to the loan account are stored
26.7.2 against the loan account in a digitized format and can be fetched as per the needs of the user:
branch and RO, others
System functionality to track and report the documents stored at branches, at CDSC, including
26.7.3
submission and successful retrieval
Module Income Tax Certificate
27 Taxation
System should generate year wise interest and principal break up certificate for IT purposes
27.1
(provisional and final)
System should be restricted to certain type of products/schemes for which IT certificates can be
27.2
generated. However, the interest paid certificate shall be retrieved for all loan types
27.3 System should support IT Certificate generation for a user defined period.
27.4 System functionality to send the IT certificate directly to customer through registered e-mail ID
Module Cross-Sell
28 Cross-Sell Insurance
28.1 Facility to link the general insurance and/or life insurance policy of all the loan applicants
28.2 The system shall alert the "X" days in advance for the policies which are expiring
28.3 The system shall keep a track of all the past insurance policies
Module Loan Account Fore-Closure
29 Foreclosure of Loan Account
 All loan foreclosure requests to be routed through RO for approval.
29.1 Facility to manage the approval/reject response from RO, including date and time stamp with
record of approver
The system shall apply the foreclosure penalty (if configured in product scheme and masters
29.2
against penal interest and charges)
The system shall compute the total due - Principal Outstanding, Interest Accrued, Any other
29.3
charges and Fore Closure Charges
System to ensure, run de-supe and suggest that if collateral is marked as a lien for other loan
accounts, loan can be closed but documents not released.
29.4
System to ensure post de-supe within the system and report to CERSAI only if all liens have
been removed.
29.5 Once the transaction is processed the account status shall become closed
29.6 The lien applied on the collateral shall be released
29.7 The loan closure letter shall be generated by the system
Module Loan Account Closure
30 Loan Closure
The system shall have the feature to mark the account as closed on the Maturity Date of the loan
30.1
if the outstanding balance of the loan has become zero
System to ensure, run de-supe and suggest that if collateral is marked as a lien for other loan
30.2
accounts, loan can be closed but documents not released
System to ensure post de-supe within the system and report to CERSAI only if all liens have
30.3
been removed.
30.4 The lien applied on the collateral shall be released
30.5 The loan closure letter shall be generated by the system
Module PMAY-CLSS Classification
31 CLSS Classification
For PMAY-CLSS screen to capture data at later stage during LMS and loan should be flagged
31.1
and adjustment made upon receipt of subsidy
Module Post Disbursal Inspection Report
32 Post Disbursal Inspection
32.1 Post Sanction Inspection Reports to be generated, captured, uploaded managed and tracked
32.2 System functionality to track and report geo-tagging of PSIR
Module Post Disbursal De-Dupe Engine
33 De-duplication Engine

System functionality to define the parameters on which the de-duplication engine is to be

configured and triggered (tentative but not limited to):
Full Name
Customer Mobile Number
PAN Number
Aadhaar Number (against unique reference number as per ADV)
Passport number
Any Other KYC Number
Customer DOB
Address (Passive)
33.1
33.2 System functionality to trigger the de-duplication check automatically and manually
 Facility to run/re-run de-duplication checks at pre-defined stages and centrally across entire
customer and customer master database:
Customer Creation
Application Processing (Loans/Deposits)
Post Application (Disbursal/Deposit Creation) De-dupe Checks
Master database de-dupe at specified intervals basis management discretion: monthly,
33.3 quarterly, semi-annually, annually
System functionality to validate the de-duplication checks across customer categories:
33.4 individuals and non-individuals
System functionality to report the de-dupe checks to defined authority within CFHL for
33.5 processing, rectification and analysis and correction
Facility to report the cases on which multiple IDs have been identified and suggest scenarios
accordingly, including but not limited to:
Contacting customer
Merging the IDs
33.6 Suggesting and updating the customer details based on their verified KYC
System functionality to validate duplication checks against internal (across CFHL) and external
databases (regulatory and non-regulatory databases e.g. politically exposed persons, negative
33.7 list etc.)
Module Application De-duplication Check
34 Application De-duplication
34.1 System functionality for user to log in into de-duplication search engine
34.2 Facility to select product, and sub-product
34.3 Facility to select application/deposit number for running the systemic de-dupe checks
34.4 System functionality to create a de-duplication check ID

34.5 System functionality to display the deduplication ID, Matched Customer ID, Matched
Parameters, Current Input Value, Matched Score, Data Source and matched parameters validity
34.6 System functionality for the maker to accept and suggest matched parameter validity
System functionality to display the customer details post the de-duplication check upon
34.7
expanding UCIC number

Display details like (tentative but not limited to):

Customer Name
Customer Type
34.8 UCIC
Customer Name, Gender, DOB
PAN, Passport, Aadhaar (against unique reference number as per ADV), Voter ID, DL Number
Complete Address
Phone Number
Father/Mother/Spouse Name
System functionality to conduct Re-KYC of the customer based on risk category and update the
34.9
same in ADV.
System functionality to conduct de-duplication checks based on unique reference keys mapped
34.10
against Aadhaar number.
34.11 System functionality to reflect the details filled in the application form versus available in databa
Facility to check, respond and correct the details in either the application form or the UCIC
34.12
module for the customer
Module Checker
35 Checker
System Functionality to include provision for checker in the de-duplication search engine
35.1
module
 System functionality to ensure that dedupe verifier checks & verifies the Details of each & every
35.2 Parameter between the Request & Response and then decides to Approve or Reject the
Customer Code to avoid the duplicate detail[s] of the UCIC
System Functionality to mark the case as checked & verified by the Approver ensuring the
35.3 details are appropriate while comparing the Request & Response details, then the Approver
selects the option ‘Valid’ from the list
For modifications in customer data post de-duplication checks, the user selects UCIC mapped
35.4 from data base.
Once the appropriate UCIC is selected, the checker clicks the Update Dedupe Status button for
updating the details of the Customer, thereby, updating the details
Rejection of de-duplication results/UCIC:
35.5 Post de-dupe, if the maker-checker are not satisfied with the details while comparing the
Request & Response details, then the checker selects the option ‘Invalid’ from the list
Module Circulars
36 Management Control
36.1 System functionality to upload regulatory and management announcement to branches
Module MIS and Dashboards
37 Reports
The system should be able to create customized reports as per the requirement of the credit
team.
37.1
The system should have a filtering mechanism for the business user to generate only the
required items of the report.
System should enable classification of Account under litigation recovery:
37.2 - By default days range (segment collection by days)
- By bucket
- By Amount Range
System should enable Classifying collection accounts into geo-regional collection branches/
37.3
centers for better customer contact and turnaround
37.4 All MIS reports as under IBS module
This system should have an option to export collection data to use the MIS report or analytical
37.5
reports in any format.
Index

Please populate only these columns with your responses

Bidder
Importance Response Bidder Clarifications / Comments
(S/A/C/U)

Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

 
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
 
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical
 
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
 
Critical
Critical
Critical
Critical
 
Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
 
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

 
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
 
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical
HRMS
Sheet 5: HRMS

Response
S
A
C
U

Id

1.1
1.2
1.3

1.4

1.5
1.6

1.7

1.8
1.9
1.10
1.11
1.12
1.13
1.14

1.15
1.16

1.17
1.18
1.19

1.20

1.21

1.22

1.23
1.24

1.25
1.26

1.3
1.28

1.29

1.3
1.31
1.32

1.33

2.1

2.2
2.30
2.4

2.5

2.6

2.7

2.8

2.9

2.1
2.11

2.12
2.13
2.14
2.15
2.16

2.17
2.18
2.19

2.20

2.21
2.22

2.23

2.24

2.25

2.26
2.27
2.28
2.29
2.30

2.31
2.32

3.1
3.2

3.3

3.4

3.5
3.6

3.7
3.8
3.9
3.10

3.11

3.12
3.13

3.14
3.15

3.16
3.17

3.18
3.19

3.20
3.21

3.22
3.23
3.24

3.25
3.26

3.27

3.28

3.29

3.30
3.31
3.32

3.33
3.34

3.35

3.36
3.37

3.38
3.39
3.40
3.41
3.42

3.43
3.44
3.45
3.46
3.47
3.48

3.49

3.50

3.51

3.52
3.53
3.54
3.55

3.56
3.57
3.58
3.59

3.60

4
4.1

4.2

4.3

4.4
4.5
4.6
4.7
4.8
4.9

4.10
4.11
4.12
4.13
4.14
4.15

4.16
4.17
4.18

4.19

5
5.1
5.2
5.3

5.4

6
6.1
6.2
6.3

6.4
6.5
6.6
6.7

7
7.1
7.2
7.3

7.4

7.5
7.6
7.7

7.8

8
8.1
8.2

8.3

8.4
8.5

8.6
8.7

8.8
8.9

8.10

9.1

9.2

9.3
9.4

9.5
9.6
9.7
9.8

9.9
9.10
9.11

9.12

9.13
9.14

10
10.1
10.2
10.3

10.4
10.5
10.6
10.7
10.8

10.9
10.10

10.12

10.13

10.14

10.15
10.16
10.17
10.18

11

11.1
11.2
11.3

12

12.1
12.2

13

13.1

13.2
13.3
13.4

13.5

13.6
13.7
13.8
13.9

14
14.1
14.2

14.3
14.4
eet 5: HRMS

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Recruitment & Joining

Define the specifications of the vacancies in terms of Qualifications, work experience, location considerations, Skills/competenci
required, Additional certifications / professional qualifications etc.
facilitate to go for E - Recruitment of all category of staff through an appropriate module to be provided by the vendor
function of uploading scanned or original documents / credentials as a part of the application
The system should capture and store the detailed information of applicant/candidate.
The system should be able to maintain a master database & repository of the CVs received of the applicant /candidate.
The system should have a search mechanism to identify candidates in the master database & repository matching the required j
description criteria fulfilling an open position.

Facility to provide unique ID to the potential candidate for joining.

The system should include basic details like:
- Name
- Age
- Gender
- DoB
- Nationality
- Phone Number
- Address - both current and temporary
- Identity Proofs - Aadhar, PAN, DL, passport and UAN(In case of working professional - mandatory)
- Previous company information - in case of an experienced personnel.
- Educational background - this should include all the certificate information
Recruitment Link to be shared with potential candidate from the HR team.

The system should maintain a record of this information for the purpose of future use, especially in case of rejected employees.
- Facility to configure the recruitment marks as per the recruitment policy.
- Facility to provide the marking along with comments in the system itself and capture the assessment sheet and generation of r
of evaluation
Approvals in the system
Categorize the recruitment system into - 1. Full time employee Recruitment 2. Contractual employee Recruitment
Status of the recruitment. Eg: Application submitted, Application under process etc
Generate the offer letter for a selected candidate.
Facility to provide the joining date approval from higher authorities, in the system itself
Information flow from recruitment system - extract basic details about the employee from the recruitment database.
Generate the mail ID and temporary password for the newly joined employee. The HR team should be the point of approval for t
same.
Automated approval mechanism for the employees on probation and soon to be confirmed.
Alerts and notifications when an employee's probation period is about to get over. The HR team can make changes accordingly,
if the probation will continue or the employee leaves etc.
Confirmation approval for the employees on probation.
The Job card should be maintained in the system itself.
- Employee ID
- Name
- CanFin Employment History
- Job Title
- Joining Date
- Reporting Manager
- Manager
- Job Profile
- Branch/RO, branch name and ID in case of branch
- Blood Group
- Photo of the employee
The system should maintain the acknowledgement/uploading of medical reports, background check ,police verification, verified
authenticated testimonials, NOC from previous organizations, caste certificates and other relevant certificates as per the user de
checklist

All details of the employee in the system should be there:

- Name
- PF detail
- Employee ID
- Date of Joining
- Service bond
- Service Agreement
- Facility to add the attachment of joining formality forms in the system once the employee joins.
- Facility to provide the checklist of forms to be filled by the new candidates and attachments with respect to the same.
- Facility of maker checker for creation of staff ID. Maker should be branch pin charge, HR RO should be checker.
- Facility for adding remarks/comments in case any joining.
System should have a checklist for the joining process for each employee and each detail should be entered in the form of a scan
document or data entry
- The following information shall also be captured by the system:
- Job Title
- Job Profile
- Location
- Branch/RO - if branch, then branch name and code to be updated
- Reporting Manager
- Manager
- Management Level, eg: Junior Officer, Officer, Assistant etc
-Full Time/Contractual
- Hire Date
- Joining date
- Probation Period
- Length of Service
- Confirmation Date
-Bank Details - For eg: Account Number, Bank Name, PAN number, IFSC code
- Upload - Checklist of documents which include PF Form, Nominee Form, Service Bond, Service Agreement etc

Integration with Training and Development module for the purpose new joiner training.
The system shall have the provision to provide virtual training links to new joiners.
The system should track the completion of induction training of new joiners and also reschedule for those who have not attende
assigned training session
PF and Gratuity Nominee
-The nomination form shall be a part of joining formality.
- This shall be among the check list of document that is provided along with other forms as a joining formality.
Declaration to be submitted by staff(Title)
- The system shall provide the option of the following to be associated with a given employee:
1. Declaration Undertaking -TPE 2. Return of Movable/Immovable Properties 3. Code of Conduct for Senior Management ( for
Managers and above)

The system should automatically generate the employee ID after the joining formalities are done by the candidate after joining.
Note: The person in charge will upload the joining formality details in the HRMS system.
- Staff ID to be created from the Date of Joining and salary to be worked upon from date of joining.
The system should support for generation of offer letter for finally selected applicants

Facility to create a standard recruitment template host it on the internal website, recruitment portals and other placement agenc
Ability to capture details of the policy for recruitment to various level in the Institution

Ability to interface with the accounting system to create accounting entries for any payments made to vendors like newspaper ad
Linkage to resumes received from the extranet (careers page on websites or homepages on external job sites). The resumes must
importable from these sites to the HRMS
There must also be provision to centrally maintain the final assessment of candidates interviewed
System should be able to generate a report on the list of new joiners along with other user defined details
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Leave Management
Ability to maintain all types of leave like CL, PL, ML, SL, UCL1 and UCL2, extra-ordinary leave, sabbatical leave, special leave,
unauthorized absence, leave without pay, etc. for each employee.
Maintain leave rules for availing leave, encashment of leave, accrual of leaves, lapsing of leaves, ceilings for accumulation of leav
restriction in combination of leave types, etc. for each categories of employees
System should record leaves availed and balance leave calculation at any point of time
System should link Leave record to payroll and employee history to record Loss of Pay.
System should have leave cancellation, leave extension/ amendments advancement and postponement of leave.
Ability to override a sanctioned leave/planned leave in case the employee reports to work during the time
Ability for leave application by the employee themselves IN THE SYSTEM and its approval by the employer(higher authority) in
system itself.
- The system should have the process for privilege leave encashment and maintain leave encashment records.
- The system should have the ability for LTA and leave encashment and relevant TDS applicability.
The system should have the leave tracking mechanism and trigger alerts to the users as and when they apply for leave more than
allocated one.
- The system shall be able to calculated the balance of leaves as and when the employee applies for the leave. This should be appl
for all type of leaves - Sick, casual, privilege etc
Balance leave = Total leaves allocated – Total leaves taken
- The user shall be able to apply as well as revoke their leave.

Attendance Management
-The system should have the ability to connect with the biometric devices.
-The system should maintain the attendance record of the employees and generate report at any point of time - only accessible b
team.
- Facility to generate report at any frequency with the provision for area wise, branch wise, region wise, employee wise, designat
wise reports.
- The system should be integrated with the HRMS system to keep track of new joiners or the employees who have resigned.
The system should have provision to add new type of leave with leave rules
The system should be able to identify all public holidays and company holidays as well as log holidays declared as per Govt of In
different states which are automatically identified and taken into account when leave is calculated.
The system should credit PL, CL and SL annually and send emailers to employees on the same
The system should support exception workflows to support leave requests and sanction/rejection by competent authority keepin
and relevant dept. informed
System should allow the employee to nominate a person at the same level as a replacement to him during the leave
System should not allow the nominated person to go on leave during the period he is working on behalf of another employee
The system should be capable of conducting analysis of Leaves taken by all employees in order to decide leave calendar for next y
on March 31st of the closing financial year.
Carry forward of leaves shall be available in the system
The system should interface between attendance captured with that of leave record
The system should enable alternate approvers for leave to be added or changed which can either be selected by the approver or t
employee applying for leave - this may include situations where the manager is already on leave or the person is on temporary
secondment and therefor an additional approver is required.
System should escalate the request to the one level higher than the employee's manager in case manager is on leave or is not app
the request
Capability to provide the Manager consolidated status of present/absent employees working under him/her

Capability to intimate the manager when an employee goes on unauthorized leave (unmarked attendance) / returns back from
unauthorized leave/ extends leave/ reports in the middle of the sanctioned leave period (along with appropriate reduction in san

Provision to generate intimation to employee about PL/CL/SL/UCL1/UCL2 at Credit with reference to overflow of leave carry fo
Automatic generation of reports as on the beginning of each year, containing the details of employees not availing any category o
leave during the preceding calendar year.
Provision of calculate the number of days of leave availed by a probationary employee for the purpose of confirmation and active
service norms.
Provision to capture the first-in & last-out entry of the biometric/ card reader/online system
Ability to calculate the number of hours spent in office ;
Ability to calculate the overtime hours of any and link them to overtime payments on salary
Report on the number of hours spent in office employee-wise/department-wise/branch-wise/cluster wise etc
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.
Trigger alerts/Error mechanism for leaves not allowed or balance not available or unauthorized combination of leaves

Payroll Management
System should record basic Master Data for an Employee for following areas along with all related and incidental information co
at least the following:
- PF Number
- The basic details should be extracted from the joining details - Name, Age, DoB, PAN etc
- The financial details of the employee should also be updated in the system.
- System should record Date of termination/restoration
- System should record the date of termination/probation/change in designation date for the calculation of salary.
- The salary structure is in the HR Policy attached.
- The following details can be viewed in the system:
Employee Name
Employee code
Date of Joining
PAN Number
Bank Account number
PF Number
Location
UAN
The system should have the capability to record the disciplinary actions and its impact on the salary.
This shall be done as per the HR policy.
- Integration with salary system for pay cuts or increment modification.
The employee has to provide bank details in the system by themselves with the attachment - account number and proof(passboo

The system should define pay structures and include earning, deduction, contribution and provision heads for each pay structur

The salary module of the HRMS system should be integrated with the CBS system for the accounts team to incorporate the
information on the same.
The system should be able to configure the salary increments which take place from time to time for all the employees
The leave management system must be integrated with the salary package in order to calculate loss of pay for the employees and
recovery of allowances which include conveyance.
Facility of comments/remarks in the salary system by the employee in case of any query.
- Facility for separate salary system for full time employees and contractual employees.
The salary system should be integrated with LoS and LMS system in case there is a staff advance taken by an employee.
System should provide link with CBS system to effect the credit of salary, loan instalments to their corresponding accounts direc

Integration with rent module for monthly reimbursement for employees. This module will come under the purview of Admin tea

Data for reporting of IND AS 19 -Gratuity, Earned Leave (PL) & Sick Leave
- System should calculate Gratuity and superannuation for multiple trusts and user definable contributions and PL encashment
applicability of TDS.
- The calculation and capping should be in line with the HR policy for PL encashment/gratuity/superannuation. The same is pr
in the HR policy.
The system should be able to generate payslip every month when the salary is disbursed.
System should support to view pay details of current month, pay history, net amount paid, unpaid deductions – Employee-wise
month-wise, financial year-wise
In case of over payment of salary, option should be there for deduction of additional salary in subsequent months
The salary package should be integrated with the investment detail system. System should calculate Income tax, Professional tax
all modules which have incidents of such taxes i.e Payroll, pension etc. The system has to adequately support all requirements of
statutory tax deduction.
- Facility to incorporate LTA, submitted by the employee in the system.
The system should have the approval mechanism to approve and reject the bills in the system.
- The following details should be added for the bill claim:
Employee Name
Employee code
Branch ID and Code/Name - in case the employee is in a branch
Date of Joining
PAN Number
Account number
PF Number
Location
NPS
Date of expense
LTA
- Eligibility
- Opted
Phone Expenses
- Eligibility
- Opted
Conveyance Expenses
- Type of Vehicle
- Eligibility
- Opted
Upload
PL Encashment

Facility to incorporate TA bills, submitted by the employee in the system.

The system should have the approval mechanism to approve and reject the bills in the system.
The system should be able to provide other staff expenses using the Salary system only.
- The GST details of the bills should also be added and should be taken into account.
- The following details should be added for the bill claim: Employee Name
Employee code
Employee Name
Branch ID/Code and Name
Date of Joining
PAN Number
Account number
PF Number
Location
Travel Details - Mode of transport/Amount/Date/From and To Location
Conveyance Details - Mode of transport/Amount/Date/From and To Location
Halting Details - Name/Amount/Stay Date/Place
Hotel Expenses - Name/Amount/Stay Date/Place
Breakage Allowance - Name/Stay Date/Place
Tax calculation
- Provision to add any Miscellaneous Expense. For Eg: in case there is a transfer, the movers and package expenses shall be add
Tax - The employee shall add appropriate tax details - GST details from the bill must be added.
Upload

System should allow employees to upload supporting documents for the claims made
System should calculate the eligibility of the employee based on level/region TA HA rates for Travel( by car/taxi), hotel expense,
expenses etc
Facility to generate online reminder letter for the concerned employee in case of non-submission of tour expense claim within a
time period
Generation of statement of travel expenses department/center-wise for monitoring of budget
Facility to generate online reminder letter for the payment of advance and in case non submission of advance, it should be deduc
from the salary.
Approval for request and payment of TA advance from relevant authority.
- The salary module must be integrated with the CBS system for flow of information. This information might include the staff sa
information, staff loan advance information etc. The LoS/LMS system to be integrated for staff advances.
- Integration with the Accounts Department for salary and staff advances.
- Integration with the Admin team to manage with the monthly rent disbursement.
PF
PF Settlement to be a part of salary system where the system should be able to perform the following:
- Record of PF amount for each month and year.
- The calculation of interest on should be compounded monthly.
- Appropriate report should be generated for the settlement process.
- The system should be able to generate reports with the information on:
Closing balance
Employer's contribution
Employee Contribution
VPF Contribution
Interest payable - both for Employer and Employee
PF Loans taken
EMI recovered

Settlement
Upon resignation/VRS/retirement etc., settlement of salary/Gratuity/PL Encashment/PF etc., shall be calcula
by the system and the reports shall be generated by the system.
Summary report of the salary of the employees. This will include all the details
- Employee ID
- Salary amount
- Bank details
- Joining etc
This can be viewed by HR team and the employee(only their respective summary)

Capability to maintain a single central payroll depository and be able to run payroll in a centralized manner
Audit trails to capture any modifications to employee payroll information
Support to view pay details of current month, pay history, net amount paid, unpaid deductions – employee wise and month wise
financial year wise and department wise
Facility to indicate taxable earnings, deduction priority, carryover and partial recovery
Facility to provide investment declaration form in electronic format. The employee will be required to fill and submit the form
electronically so as to automatically updating of salary record and tax calculation by the system

Generation of all types of statutory reports of taxes like Form 16 and Form 24 in the user­defined format (16AA, 12BA AND 27A
Generation of employee’s individual tax return
Release of festival advance against salary. Employee­wise recovery position, recovery list and outstanding balances list – month
or as user defined
Support calculation and payment of arrear/bonus with consequent tax adjustments and retrospective benefits.
Support payment of transfer allowance and any other user defined allowances with automatic updating (non-payroll)
Provide an impact analysis tool for analysis of impact of salary revision
Facility for automatic Voucher generation for tax /accounting calculation.
Monthly salary payment calculations and generation of related reports, salary slips, deduction lists, vouchers, tax challans, PF
Challans, Professional Tax challans
Should compute various benefits provided to our employees such as Leave Travel Allowance, Medical Reimbursement, Medical
Insurance, House Rent Allowance and other long term reimbursements and general expenses. Eligibility, computation and taxab
should be considered.
Starting & stopping salary with to and from date
Loan Details to be attached to an employee's salary history
Reversal of all deduction, to be included in next salary if incorrectly withheld or provided for
Provision for generating various tax related report and salary report of employees across CanFin
Investment Detail & Tax Declaration
Facility for the investment details of the employees to be submitted in the system.
Facility to choose the Old regime and New regime. This is a one-time activity and the employee is not allowed to change it later.

The system shall provide tax declaration options to the employees which includes deductions under Income Tax Act, House Ren
details, home loan details etc and Maintenance of slab wise details for DA, HRA, Income Tax, Professional Tax etc
Calculation of income tax as per rate slabs & standing instructions.
The system should be able to generate tax sheet and salary sheet for the employees, once the investment details are submitted.
Tax calculation and tax slabs to be a part of this system under various section of Income Tax Act.
The investment detail system should be integrated with the salary system for the update and changes in the salary made due to t
system.
Maker checker for the purpose of investment proofs. Employee to be the maker and HRMS to be checker.
Facility to submit investment proofs in the system by the employees themselves.
The system should be able to point out discrepancies in the investment detail submission.
The investment detail submission system should be accessible to the HR and finance team. The team should be able to
approve/reject/revert for modification, a given investment detail.
The system should be able to fetch the PAN card details of the employee.
The system should let employees submit their investment in the system.
The proof submitted should be of standardized format
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Performance Appraisal
The system should be able to perform quarterly appraisal of the employees
The system should also provide the option for annual appraisal in case for employees on probation and employees other than off
grade.
Facility to update the quarterly targets(parameters) in the appraisal system by the Planning and development team
The system have the facility for the categorization of the branches and the parameters and targets set for these branches.
This to be evaluated for each employee and marks should be as per the target parameter set and the achievements of the same.
The targets should be allocated with certain marks, and the scoring should be given to the given employee.
The overall marks correspond to a rating based on which the variable pay is set.
-Facility for configuring the marks for appraisal in the system as per the HR policy.
Facility to provide the option for remarks/comments in the system
Facility to provide approval for the appraisal in the system itself.
Ability to define the rules for promotion eligibility in terms of tenure, consistent achievement of high performance grades, etc
The appraisal module must be integrated with the salary module for the variable pay.
The hierarchy for the approval for the appraisal is as follows:
Staff>Branch In charge
Branch In charge>Cluster Head
Cluster Head>GM
The overview to be done by the HR
ADD: For staff at Regd.office/other Offices - Dept. Heads, For Managers and above - GM/DMD/MD

The system should support maintenance of history of performance appraisals and promotions
The system should have direct integration to the training needs analysis which can be used as input in training calendar design a
as employee nomination
Provision to create a consolidated report of all the employees under a reviewer with all individual scores
Facility to consolidate the overall points and calculate an overall grade for the appraisee
Capability to integrate with training module to consider recommended trainings during training need analysis
System should be able to calculate the incentive based on performance assessment scores, mobilization figures (as applicable) &
quartile ratings( for managers)
System should be able to generate automated letters to the employees to indicate the increment & revised salary amounts
Ability to define competency requirement for each role and assessment of the same
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Employee Self Service

The system should have the Employee self-service portal.
The self-service portal should be integrated to appraisal system for the employees to see their rating.
Facility to raise employee issues with relevant department.
The Employee self-service portal should be used to view the employee details by themselves. The details with respect employee
information should include:
- Joining Details
- Transfer
- Probation
- Promotion
- Salary details and summary
- PF details
- Leave

Promotion
- The system should be able to configure the promotions
- The minimum eligibility for promotion should be configured in the system.
- Facility for maintaining the marks for the promotion - written test and the interview marks in the system.
- Facility to trigger alerts in case potential employee has completed minimum satisfactory services and having
minimum educational qualification as on relevant date
- Parameters for promotions to be configured in the system.
The system should update employee profiles on the promotion
Ability to define out of turn promotions

Exit Management
- The system should provide the facility for resignation to the employees.
- The application for such resignation should go to the concerned authority
-The approval for the resignation in the system itself.
Clearance form all the relevant departments in the system. All these department clearance(s) will be checked with and only then
final approval is given - Credit, RBIA, HRM and IT and the Admin department(for handover of asset)
- The System shall provide for the status of resignation - Accepted/Rejected/Pending etc
- The System shall provide for the reason For resignation along with the comments/remarks - Resignation, termination,
superannuation
The followings should be available in the system:
-Resignation Date
-Notice Period
-Exit Date(Last Working Date)
-Clearances - IT, Admin, Credit and other relevant department. All relevant department clearances and the branch incharge clea
in case the employee works in branch.
-Closure of Liabilities Checklist - Return of asset, Return of Power of attorney, ID card return.
-Exit Formality Checklist - Exist Interview form.
The system shall be able to generate termination letter.
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Transfer
- The system should provide the facility for transfer to the employees.
The transfer order has to be approved by the GM in the system. In case of CM and above, MD should approve.

- The request for transfer shall be available in the system. There are two method for the same:
o At employee’s request.
o At senior management decision
The system should be able to generate the Transfer order letter.
- Transfer role - Deputation/promotion/general transfer/investigation
- Transfer location
- Transfer Date
- Date relief
- Date of report joining
- Transfer Reason
- Remarks and Comments
- Upload

Should maintain number of transfer requests rejected, number of transfer requests/rejections upheld and reason for the same et
The system should support online updating of joining details from the new place of posting
The system should track relieving /joining delays and generate reminder mails for the employees to follow up on the transfer
implementation
Linkage of transfer to specific allowances for auto incorporation in the payroll
Provision to record the transfer orders cancelled/ deferred/ modified and follow up with the respective Regional offices for
implementation
Provision for recording inter-departmental transfer within the same branch/RO for specific roles.
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Manpower Study
Manpower study to be done by system - resignation reporting with the reasons to be generated by the system and the requireme
each branch with the manpower and the shortage of manpower.
This needs to be calculated by the system.
Facility to support analysis of the branch or office-wise / Scale-wise/ department–wise proposed staff strength based on branch/
categorization and defined parameters
Facility to support analysis of proposed (planned) manpower strength, existing working strength and the gap for which
recruitment/promotions is required
The system should capture the data relating to resignations / retirements/VRS/terminations etc.
The system should allow receipt of specific staff requirement from zones and offices for consideration before finalization of man
plan
Facility to prepare Board Note/NRC to competent authority for getting approval to sanction the assessed staff requirements
Provision to upload board approved manpower and recruitment plan
Provision to define requirement plans (periodic) in terms of specific skills, Qualifications, experience, designation, etc.
Facility to prepare Board Note/NRC to competent authority for getting approval to sanction the assessed staff requirement and
automatic generation of communication to the concerned Branch / RO
Facility to update the staff strength sanctioned under various departments to arrive at the vacancy position
Capability to integrate with the recruitment/promotion module for filling up of vacancies with required approval.
Capability to issue alerts before any position falling vacant due to retirement/ term of temporary or contractual employee gettin

Facility to allow receipt of projected manpower from all departments(RO)/clusters/branches and create a finally approved manp
plan. Capability to generate consolidated manpower plan ( Unit wise ) for Approval.
Preparation of budget on the basis of information received from all departments(RO)/clusters/branches

Training and Development

Capability to publish training calendar for in house training.
Basic training with respect to CanFin working for all cadres of new joiners
Subsequent trainings schedules or required by the employees should be published in the system
The system should be capable of capturing qualification/training completed by the employee externally or prior to joining the
organization.
This should include trainings attended internally as well. This information should be imputable by the employee.
Capability to record competency development needs basis competency assessment done during appraisal process
Training material to be provided in the system for the staff to understand the business
Virtual training links to be provided to the employees in the system
Integration with Joining module for the purpose for new joiners training with provision for virtual meeting links.
Map competency that employees gains from completing a course completed or training program attended and provide for autom
updating of employee competency inventory (from training module)
Capability to record competency development needs based on the competency assessment done during appraisal process
Capability of generating letters through print/browser/email with features of on line confirmation, cancellations, explanation fo
nonattendance as well as communication on re-scheduling of training courses
The system should capture number of sessions, maximum / minimum employees that can be enrolled, maximum wait listed
employees, and based on mapping module and program should be automatically updated and online training facility.
Provision to record reason for non-attendance and permission granted thereby and also recovery of notional cost for non-attend
without valid reason.
There should be a facility to automatically update the employees profile without any manual intervention upon his/ her successf
completion of the training program
Maintenance of course fees paid to external training institutes
Number of trainings and type of trainings provided to be captured in the system
Upload of training certificates - internal / external training

Organization Structure
The system should be able to provide a hierarchy of the organization with all the names, employee ID and designation of the
employees.
The names of all the employees under a given department and the authority should be available.
Similarly, The number of employees under a given department and the authority should be available.
The system should reflect the changes in case there is some addition/deletion/ modification in the organization structure.
This should be under the purview of HRM, Board Secretariat, Product development

Rewards & Recognition

Based on target achievements, the rewards and recognition should be given.
This should be reported in the system - in coordination with the Product and Development department - for yearly / quarterly
reporting from them.
The system should link the rewards and recognition to the salary system for relevant TDS calculation with proper tax bracket.
Authority Workflow mechanism
The authority workflow should be maintained in the HRMS system for approval, rejection etc
This will be part of all the HR related activities like leave application, appraisal etc.

Disciplinary Action
The system should have the capability to record the disciplinary actions and its impact on the salary.
This shall be done as per the HR policy.
- The Disciplinary Action decision should be restricted to the HR department - specific people.
- Facility to attach and upload documents with respect to the disciplinary action.
- The system should have a provision for an approval mechanism to approve/reject the disciplinary actions complaint - from the
higher authorities.
- Integration with salary system for pay cuts or increment modification.

Ability to for employees to lodge a complaint against any other employee on discipline/sexual harassment /non compliance grou

Capability to categorize a case as pending, contemplated, cleared case for use by other modules e.g. promotion, retirements etc.
Ability to grant vigilance clearance certificate
Capability to maintain record of employees with complaints lodged against them and restrict the list's access to only authorized
officials
System should allow the capturing of details from the employees regarding any improper practices and also allow HR to lodge
disciplinary proceedings against any employee as required
System should reflect the disciplinary proceedings in the employee details & employee lifecycle chart
System should allow uploading of relevant documents supporting the disciplinary proceedings
System should allow multiple disciplinary details to be logged in for an employee

Mobile Application Access

The solution should have the capability to run on the mobile application with access provided to CanFin employees
The functionalities defined above shall be accessible to the employees such as applying for leave, accessing the payroll system,
attendance help, self-service portal etc
The employee should also be able to view the overall information about themselves - CanFin Employment History, job title, join
date, Reporting Manager, Manager, Job Profile etc on the mobile application.
The solution should be capable of sending important updates as alerts and notifications in the mobile app itself.
Index

Please populate only these columns with your responses

Bidder
Importance Response Bidder Clarifications / Comments
(S/A/C/U)
Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical
DMS
Sheet 6: Document Management System

Response
S
A
C
U

Id
1

1.1
1.2

1.3

1.4

1.5

1.6

1.7
1.8
1.9
2

2.1

2.2

2.3
2.4

2.5
2.6
2.7
2.8
2.9
2.10
2.11

2.12
3
3.1
3.2
3.3
3.4

3.5
3.6

4
4.1
4.2
4.3
4.4
4.5
5

5.1

5.2

5.3

5.4

5.5

5.6
5.7

5.8

5.9

6.1.

6.2
6.3

6.4

6.5

6.6
6.7

6.8

6.9

6.10
6.11
7

7.1

7.2

7.3

7.4
7.5

7.6

8
8.1

8.2

8.3

8.4

9
9.1
9.2

9.3

9.4

9.5

9.6

9.7

9.8
9.9
9.10
10
10.1

10.2

10.3

10.4

10.5

10.6

10.7

10.8

10.9

10.1
11

11.1

11.2
11.3

11.4

11.5

11.6
eet 6: Document Management System

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement
DMS
The DMS system should have the capability to integrate with Core Banking and other ancillary systems deployed in the bank for
storing of documents.
The business user should be able to view the document linked to a particular account on the core system
Integration with CBS and other ancillary system should be in a seamless manner such that access view to document is available o
single click and the flow of documents to DMS system is smooth.
- Implementation of the barcode system at the branch and CDSC level and its integration with the CBS and DMS system to direc
record and track the documents dispatched.
- The system should be able to capture the loan document movement from branch to CDSC and vice versa. ( Date of dispatch by
branch and Acknowledgement by CDSC on receipt of documents, Date of request by the branch to CDSC and acknowledgement
branch to CDSC on receipt of documents)
- For easy identification, barcode will be used.
- Facility to provide description of the location where that given document is positioned at the CDSC center- this should be hidde
branch person/users.

The access to document should be available in the following manner:

- Given branch documents - only the users at the branch and RO
- RO documents - only the RO users.
The system should have the functionality to record the number of documents and type of documents received from a given custo
corresponding to the loan.
The system should configure the following information for the record of documents-
- Customer ID
- Loan Account No
- Total number of documents sent
- Total Number of documents pending
- List of documents - document name in the drop down menu so that the branch officer can select the documents they are sendin
The system should have the capability to provide maker checker control for the document management.

The document management module should be managed at the following levels - at the branch level and the CDSC(Document
management center for CanFin) and RO Admin department users only.

The system should be able to generate reports for the pending documents
- Facility to reconcile the documents twice a year.
- The system should be able to reconcile the total documents at CDSC and branch with the total live loan accounts.
Note: The physical verification takes place at the branch and CDSC center twice a year and the information is provided in the sys
- Facility to provide maker checker control for the reconciliation of the documents. Maker checker at branch level and maker che
at CDSC level. At RO, the admin department should overview the whole reconciliation process.
- The reconciliation should be done in the month of May and Nov and once the checker approves, the data should be frozen.
- Audit trail for maker checker to be present.
- Reconciliation report to be generated.

Upload of Documents
System should be able to upload and store the all the KYC documents and Loan documents of the customer.

The system should be capable enough to enable users to continue with other tasks in the system while the documents are being
uploaded.
It should be possible to scan and upload documents including pictures and images. The system should allow bulk scanning of th
documents.
System should support quick scanning of all the documents submitted
The system should be able to indexing/tagging of documents to a loan application from front-end. This should be applicable for
documents as well.
The system shall have the capability to compress the size of the documents
System should allow printing of the uploaded document
The system should be able to retrieve the documents as per the needs of the business user.
The system should have the capability to keep a backup of all documents uploaded as well as the documents submitted.
The system should be able to archive the documents uploaded.
The system should be able to maintain the audit trail for actions on each document.
Only the branch in charge should handle the view of the documents - access to view restricted to in charge.
- Maker checker for loan documents upload should be there.
Linking and categorization of scanned documents
System should be able to link the documents to a customer account
System should allow viewing of the a specific branch documents in a given branch
System should allow to categorize the document as mandatory and non-mandatory documents.
System should tagged document into categories like “Mandatory / Optional”, “Original / Copy / Authorized copy”, etc.
System should allow user to categorize scanned KYC documents
PAN card
Voter ID card
Aadhar Card
Passport
Ration Card
Driving License
Bank Statement etc.
The system shall be able to fetch the document checklist loan origination solution.
- The system should be able categorize the loan documents. The categorization is as follows:
Application form
Field Report
Collateral Copy
Legal documents/LSR
Valuation document
Financial Statements
Credit Appraisal report
Stock report
CIBIL report
Credit History
- The system should be able to categorize the documents submitted after the loan has been sanctioned and linking the same to th
account.
- The system should be able to categorize the documents received after they have been received. This includes:
Loan agreement
Sale deed
Sale agreement
Property/Building Plan
Licenses

Document Search
System should allow documents to be moved from one folder to another and re-indexed without re-scanning
System should have ability to tag same document to multiple loan accounts without duplication.
System should support indexing of the document based on different parameters.
System should allow searching of the documents based on the search criteria
Audit trail of access to the document should be maintained
Technical Requirement
The DMS should be a highly available, scalable platform on which to support a library containing files and documents in the tar
state architecture
All Administrative functionality should be accessible remotely using a web browser over the internet or through the companies L
WAN. SSL and VPN support further secure remote user and administrator access.
The DMS should be providing a web browser, a desktop client, and a mobile browser as standard features.
The DMS should provide both full user licenses for users to add, edit, and delete documents in the system, as well as limited use
licenses to restrict document access to read-only status. These limited licenses will also be restricted from processes such as wor

The DMS must have a tool that checks server configuration and health settings to ensure the document repository is running pro
and without errors.
Capability to allow the configuration of multiple balanced storage repositories to allow scalable growth.
Capability of exporting documents out of a test system and importing them into a production system.
The DMS should have an optional document portal, where anonymous or named users can access a web-accessible interface wit
extremely limited rights.
The solution should be an overarching enterprise level Document Management Solution and should be able to plugin the docum
from the applications to storage in a bi-directional manner.
Document Storage & Retreival
Should have multiple methods to import documents from existing third-party applications, desktops, network drives, and file se

Ability to store virtually any kind of document in its native file format and ensures it will not be altered when added to the system
The DMS should provide check-in/check-out ability, preventing documents from being overwritten or deleted when updated. Ab
to review the status of all documents checked out and check a document back in on behalf of another user.
The DMS should automatically increase the version number of the document upon check-in. Previous versions of documents are
maintained by the system if a rollback is required.
Ability to classify documents by use-type. These schemas will be customizable to match organizational needs, the number of whi
should be practically unlimited.
Ability to track the physical location of contracts and agreements, and identify the individuals responsible for them
The DMS should allow users to define metadata with indexed information from a controlled vocabulary.
The DMS should allow metadata to be configured as text, number, dates, URL, currency, checkboxes, or from drop-down menus

The DMS should allow users to subscribe to be notified of edits, changes, or version updates to documents or folders they are
watching.
Soultion should have the "watermarking" like features to avoid copyright conflicts and factor additional security feature
The Solution should readily understand/read the documents with OCR, Barcoded content, Bio-metric, QR encoded data
Document Security
The DMS should allow navigational security, with multiple layers of user-definable security, to limit access at department, user,
system, function, and document levels.
Should have a role-based, granular security model where access can be given to users from a level of read-only to system
administration.
Inclusion of a role-based security model with the ability to establish exceptions. Additionally, access can be limited to “read-only
the user level.
Ability of administrators to block users from emailing a document as an attachment from the DMS.
Documents accidentally deleted by users (with delete permissions) should be easily recovered from a "recycle bin".
The Solution should be able to encrypt the data,documentation,sensetive and business critical information with the help of prop
encryption method/framework
Interface
The interface must be easy to use and familiar to users of a Windows environment.
The user should be able to trigger actions through contextual menus that can be activated through on-screen buttons, system me
or right-click contextual menus.
The DMS should have document-to-document linking to allow users to bundle files into logical groups and integrated viewing
capability to display all linked files screen. Users should be able to point-and-click on the linked file to access to the record set.
The DMS should provide the ability to personalize user preferences, views, alerts, workflow notification preferences, and folder c

Searching
The DMS should offer web-based, mobile-based, and desktop clients for document searching.
The DMS search capability can be restricted to a specific area of the library (e.g. cabinet or folder).
The DMS search capability can search the metadata associated with the document as well as the content of the document. The so
should have the wildcard document search abilities to facilitate content search within the document
The DMS search capability can be configured to only search document metadata and exclude document content.
The DMS search capability must index document file properties, including the date added to the system, document owner, size,
format, and file type.
The DMS should save searches for re-use. These searches can be made public for use by others or private for use by only the user

Ability to retrieve documents by document title, classification, type, address, customer name, number, or any other user-defined
value.
The DMS should allow a user to search for documents using terms from a controlled vocabulary in the document metadata.
Ability to retrieve documents using multiple index words, numbers, dates, etc., simultaneously.
The DMS could be able to configure the search engine.
Workflow
The DMS must provide a document review and approval workflow for documents needing to pass through several authors, revie
and approvers before being ready for general distribution.
Workflow should be customizable to fit the specific document review and approvals processes required by the organization
The DMS must keep a sign-off sheet for each document version so users can see who approved or rejected the document, and an
feedback provided.
Delegation of a task and signing authority can be given to other users for individual tasks, or for all tasks over a given period.
The workflow should allow specific users to act as observers of review or approval workflows. Observers can track the progress o
documents as they proceed through the workflow and view any comments and feedback as provided.
Workflow should allow user to define conditions, or be locked-down to prevent changes.
The workflow should alert users of upcoming deadlines and when tasks are overdue. These alerts can be repeated at defined inte

The DMS must support an external workflow feature to allow documents to be sent to external users for viewing or approval. Th
approvals will be part of the audit trail for documents.
The web-based viewing platform for viewing or approving externally-transmitted documents must be viewable easily on mobile
devices.
The Solution should have digital signature feature to incorporate additional security feature in agreement with the CFHL Team
Integration and Customization
The DMS should synchronize users or groups from objects in Active Directory, LDAP, or NT Domain directory servers. Once
integrated, both users and groups can then be assigned to functional roles.
The DMS should have an industry-standard, fully-documented API that allows integration with third-party applications.
Ability of expansion of document repositories while remaining seamless to the user.
The DMS must be capable to integrate with multiple data providers such as ODBC, OLE DB, Oracle, and SQL Server to single-so
metadata.
The DMS must have an importing tool that can perform server-side lookup of metadata or perform a lookup of metadata from a
database.
The solution should be able to integrate with the existing document repository solution at no additional cost to CFHL
Index

Please populate only these columns with your responses

Bidder Response Bidder Clarifications /

Importance
(S/A/C/U) Comments

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical
Insurance
Sheet 9: Third Party Insurance Commission Tool

Response
S
A
C
U

Id

Module
1

1.1

1.2
1.3

1.4
1.5
Module
2
2.1

2.2
Module
3
3.1
3.2
3.3
3.4

3.5

3.6

3.7
Module
4
4.1

4.2

4.3
 4.4
4.5
4.6
4.7

4.7.1

4.7.2

4.7.3

4.7.4

4.7.5

4.7.6

4.7.7
4.7.8
4.7.9
4.7.10

5.1

5.2
5.3
5.4
5.5

5.6

6
6.1
6.2
6.3
 6.4

6.5
6.6
6.7

6.8

7
7.1
7.2

7.3
7.4
7.5
7.6
7.7

7.8
Module
8
8.1
 8.2
8.3
9

9.1

10
10.1
10.2
11
11.1
11.2
12
12.1
12.2
12.3
12.4
Module
13
13.1
13.2
13.3
13.4
13.5
13.6
13.7
13.8
14
14.1
14.2
eet 9: Third Party Insurance Commission Tool

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Specified Person
Specified Persons
System functionality to ensure that the application form and SP training certificate signed by PO can be uploaded online in bulk
IRDAI website
System functionality to track and manage the validity of the SP certificate
Facility to manage the repository of SP certificate with SP number mapped to branch and HRMS at RO
Facility to trigger the system based reminders for renewal of SP certificate at RO level and respective branch level
System functionality to enable tracking, mapping and management of SP mapped to CFHL branches
Real-time information to flow to RO and ensure zero-dependency on the insurance partners.
Details of SP including: name, address, telephone number, photo, date of commencement, resignation, salary needs to be maint
as a register and in system.
Record of all employees (SP’s)
New Insurance Partner Onboarding
Onboarding New Insurance Partners
Facility to onboard and integrate new insurance partners through system level integration as per IRDAI guidelines and service le
agreement
System functionality to incorporate the details of commissions charged by CFHL against the terms of insurance partners and
premiums charged by the insurance partners
Need Assessment
Need Assessment Form
System functionality to capture the need assessment form for recording customer consent and purpose for applying for the insur
System functionality to incorporate the details of product: GI, LI being opted for by the borrower and record in the system
Facility to upload the details of the product: GI, LI or both: A scanned copy of the assessment form
System functionality to cross-sell the insurance to existing customer only, with a live loan account. The same is not to be sold to
customer not within the system
System functionality to map against whose name, the policy is being issued: applicant, co-applicant, others (legal heir etc.).
Facility to note the account to be debited against the EMI
System functionality to record, confirm and validate the beneficiary (CFHL) to be assigned to CFHL across all the insurance poli
issued.
System functionality to capture the change of insurance claim settlement beneficiary post the closure of loan account
Facility to map the information captured in need assessment form against the premium calculator
Application
Digital Customer Onboarding
System functionality to source and onboard customers digitally

Facility to provide online application form for insurance partner

Facility to submit /upload insurance related documents through online portal for insurance partners
System functionality to provide access for insurance partners to push the policies into common folder owned by RO and access g
to CFHL branches (e.g. SFTP folder or others options)
Facility to provide oversight to RO for tracking the documents and application for received for GI, LI
System functionality to allow integration of insurance module to HRMS
System functionality to capture the employee ID of the existing staff and validate against HRMS for premium collection
Storage of Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML containing Aadhaar number an
data)
System Functionality to Record the Aadhaar number in the CRM/Lead Management, Deposit, Lending, Insurance Modules or o
modules as may be deemed necessary by the management at CFHL
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the CRM/Lead Management, Deposit
Lending, Insurance Modules or other modules as may be deemed necessary by the management at CFHL
System Functionality to record the Name, DOB, Address, Gender or other details as may be deemed necessary by the manageme
CFHL based on details mentioned in UIDAI database.
System Functionality to record the verified details in Lending, Deposit modules or other modules as may be deemed necessary b
management at CFHL
System Functionality to generate associated unique reference key stored in HSM.
System functionality to replace the Aadhaar number with the reference key across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of any transaction where Aadhaar number is exchanged, the reference key t
replace the Aadhaar number, when needed.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to ADV:
All the existing Aadhaar related information to be stored in the Aadhaar Data Vault.
Functionality to ensure that the scanned copy of the physical Aadhaar card be masked and stored in an encrypted format within
database.
System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the Aadhaar information based on reference number, if needed for regulatory purposes/other man
business engagements, but referenced through the key post the transaction, via APIs to whitelisted IP addresses.
System functionality to conduct Re-KYC of the customer based on risk category and update the same in ADV.
System functionality to conduct de-duplication checks based on unique reference keys mapped against Aadhaar number.

Premium

System functionality to ensure integration with customer facing applications (Lending application, CFHL mobile application* an
insurance partners) for quoting of insurance premium by insurance partner and collection of premiums through online mode.

Facility to collect and record premium payment at the branches against the loan account number by cheque, along with cheque
number, cheque details
Functionality to ensure mode of payment cannot be cash.
System functionality to provide an option to check for staff discount on insurance premium, if any
System functionality to check the borrower eligibility for I-secure
System functionality to capture and upload the I-secure application form seeking authorization from customer to fund the insur
premium through a loan product
For digital applications: Facility to capture the I-secure loan authorization digitally through customer facing application and ver
digitally from customer's end
Application Tracking
Functionality to track status of insurance applications being shared with insurance partners.
System facility to mark the SP number against each application for insurance policy
Functionality to tracking and manage lifecycle management of issuing insurance policy and related process: document collection
submission, stage and conduct of due-diligence checks: success, reject cases, reason for rejection.
Following Status to be captured for all insurance policies:

Accepted Standard
Accepted with Loading
Cancelled from Inception
Declined
Fully Suspended
Lapsed
Member in Grace Period (Renewal)
No underwriting
Pending Reinstatement
Pending Application Data Incomplete
Premium Paying Regular
Rejected
Terminated
Underwriting Pending
Withdrawn by Bank/Member

System functionality to record policies solicited with respect to new business

System functionality to record policies solicited with respect to renewal business/non renewed business (including capturing gra
period)
System functionality to capture the reason for cancellation of insurance policy

System functionality to mark the following statuses for cancellation of insurance products (tentative):

Cancel-Customer Request
Cancel-Non completion of PFR
Easy Bima Rejection
File Closed
Not eligible for requested plan
Not proceeded with (new bus)
Others
Overweight
Rejected by insurer
Rejected due to requirement pending
Termination-major alteration
Withdrawal request

Auto-Intimation
System functionality to generate and send auto-email to branches after the issuance of insurance policy
System functionality to provide the insurance policy to the branches through official e-mail, uploading in SFTP (or other folder)
customer e-mail address registered with CFHL
System functionality record the status of insurance policy issuance (issued/rejected) by the branch user and inform the credit te
further steps
System functionality to record if the case is funded or not funded
System functionality to record the insurance partner against whom the policy is issued (funded/non-funded)
Facility to record the reason for decline of property insurance
Intimation to customer through pre-defined format of SMS intimating him of disbursals under I-secure loan towards insurance
premium
System functionality to track if the insurance premiums are funded to retail customers or non-retail customer
(organizations/corporates etc.)
Insurance Policy Details
Recording of Insurance Policy Issued
System functionality to record the insurance policy number of the property insurance against the loan account number
System functionality to manage and provide oversight into the assets secured by PI (mandatory) and LI: Outcome to know how
assets are secured by property insurance (GI), how many also insured by LI
System functionality to map the insurance policy issued against the team hierarchy (SP number, cluster, area, region, state etc.)
Terms of Policy
Facility to manage and record the terms of policy issued to customer along with the type of policy and the name of the policy hol
(including but not limited to):
Start date,
Risk commencement,
End date,
Date of renewal,
Amount insured, etc.
Controls and Triggers
Triggers for missed out customers (if any).
Triggers for regular pay customers into one-time payment.
Document Management
System functionality to tracking and maintain digital records for insurance at branch and RO.
Physical copies may be stored at branch only.
Query Resolution
Functionality to ensure query resolution over e-mail
Integration for resolution handling along with buckets for scenarios, description, and attachments
System functionality to keep a record of grievances and complaints
Facility to record and attribute escalation matrix for complaints received to area, regional team
Insurance Claim Recording and Settlement
Claim Settlement
System functionality for customers to raise a request for claims and submit necessary documents against the insurance and loan
account (offline through branches and online through website of insurance partner/CFHL loan servicing website)
System functionality to track the claims raised by customers through the branches/online channels
System functionality to keep a record of claims, if serviced and processed through the insurance intermediary
System functionality to keep a record of claims, in case the claim is serviced and processed through third party administrators
System functionality for RO to know the status of the settled accounts in real-time.
Facility to record if the insurance claim is denied and premium is refunded, reason for such denial
System functionality to determine the adjustment of such premium**
Facility to compute and credit the account of the beneficiary (CFHL), and excess to borrower's/beneficiary's account
MIS
System functionality to compute commissions and generation of invoice to be shared with insurance partners
System functionality to automate the generation of desired MIS, dashboards, provision to create new dashboards and MIS
 Index

Please populate only these columns with your responses

Bidder Bidder
Importance Response Clarifications /
(S/A/C/U) Comments

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
CRM/Lead Management
Sheet 11: CRM/Lead Management

Response
S
A
C
U

Id

Module
1
1.1
1.2
1.3
1.4

1.5

1.6

1.7
Module
2
2.1
2.2
2.3
2.4
2.5

2.6
2.7
2.8

2.9

2.10
 2.11
2.12
2.13
2.14
Module
3
3.1
3.2
3.3
3.4
3.5

3.6

3.7

3.8

3.9

3.10
3.11
3.12
3.13

3.14
3.15
3.16
3.17
3.18
4
4.1
4.2
4.3
 4.4

4.5

4.6

Module
5

5.1

5.2

5.3

5.4

5.5

5.6
5.7

5.8

5.9

5.10

5.11
Module
Module
6
6.1
6.2
6.3

6.4
6.5
6.5.1

6.5.2
 6.5.3
6.5.4
6.5
6.5.1

6.5.2

6.5.3
6.5.4
6.6
6.6.1
6.6.2
6.6.3
6.7

6.8
Module
7
7.1
7.2
7.3
7.4

7.5

7.6

7.6.1

7.6.2
7.6.3

7.6.4

7.6.5
7.6.7
7.6.8

7.6.9
7.7

7.7.1

7.7.2
7.7.3

7.7.4

7.7.5

7.8

7.9

7.10
7.11
7.12
7.13
7.14
7.15
7.16

7.16.1

7.16.2
7.16.3

7.17
7.17.1
7.17.2
 7.17.3

7.17.4
7.17.5

7.17.6
7.17.7
7.17.8
7.17.9
7.17.10

Module
8
8.1
8.1.1
8.1.2
8.1.3
8.2
8.3
8.4

8.5

8.6

8.6.1

8.6.2
8.6.3

8.6.4

8.6.5
8.6.6

8.6.7

8.6.8
8.7
8.7.1

8.7.2
8.7.3

8.7.4

8.7.5

8.8

8.9

8.10
8.11
8.12
8.13
8.14
8.15
8.16

8.16.1

8.16.2
8.16.3

8.17
8.17.1
8.17.2

8.17.3

8.17.4
8.17.5

8.17.6
8.17.7
8.17.8
8.17.9
8.17.10

9.1

Module
10
10.1
Module
11

11.1

11.2

11.2.1

11.2.2

11.2.3
11.2.4
11.3

11.3.1

11.3.2

11.4
11.4.1
11.4.2
11.4.3
11.5
11.5.1

11.6

11.6.1

11.7

11.8
11.8.1
11.8.2
11.8.3
11.8.4

11.8.5

11.8.6
11.9
 11.9.1

11.9.2

11.10

11.11
11.12
11.12.1

11.12.2

11.12.3

11.13
11.13.1
11.13.2

11.13.3

11.13.4
11.13.5

11.13.6
11.13.7
11.13.8
11.13.9
11.13.10

12
12.1
Module
13
13.1
13.2

13.3

Module
14
14.1
 14.2

14.3
Module
15
15.1
Module
16

16.1
16.2

16.3
16.4

16.5

16.6

16.7
Module
17
17.1
17.2
17.3
17.4
17.5
17.6
17.7
 17.8

17.9
17.10
Module
18
18.1
18.2

18.3

18.4

18.5
RM/Lead Management
eet 11: CRM/Lead Management

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Marketing Management
Marketing Management
System should have ability to plan, track and analyze marketing campaigns and find out the ROI of each campaign includ
budget and expenses.
System should have ability to define budget approval mechanism
System should have ability to record and track marketing events, product promotions and expenses, manage marketing calenda
track responses to teaser campaigns
System should have ability to assign budget for the marketing campaigns and able to define target segments.

Target Customer Grouping (including but not limited to):

System should have ability for customer segmentation based upon user defined categories e.g. existing and new customers, age
gender, income, geographical locations, status (residential/financial), nature of service, etc.
System should be able to further group customers on the basis of parameters as per the business need.
System should have the provision to identify customers belonging to the same family/group and group them together, if needed
System should have the provision to define customer relationships. For example, in case of joint account holders, primary-sec
owner flagging, relationship, KYC status etc. can be flagged.
System should have the provision of 360 degree view of customers associated in same hierarchy/group, and/or associate one cu
with another customer
System should have the provision to group customers as per the sourcing agent, sourcing branch, sourcing channels etc.

System should have ability to create, execute and monitor marketing activities across multiple channels such as email, w
department specific portals, SMS, contact center, mobile apps, branches, third party partners/aggregators
System should have ability to upload data lists into the CRM. Lists can be internal lists or external lists from integration with An
or BI tools.
Communication Engine-Integration and Management
Communication Engine
CRM system should have the functionality to integrate with all internal and external systems
Facility to migrate customer and product information from all internal and external systems into CRM Solution.
System should have the provision to update either on an individual record basis or through bulk upload.
System should have an updating module, which will link to UCIC module, to capture and confirm the details of the customer
System functionality to incorporate inputs and details entered by branch staff into the CRM module/solution.
System should have the provision to update either on an individual record basis or through bulk upload
System should have verification and authentication during the contact updating process
Document upload feature should be enabled for verification
Functionality for real time update in CBS
In case of existing customer, regular alerts at specified time intervals should be triggered to the employees regarding the upda
the customer contacts.
In case of existing customer, regular alerts at specified time intervals should be triggered to the customers for updating of the c
details using various modes of communication: SMS, E-Mail, Mobile App notification, website notifications etc.
System should have the provision to associate existing customers or prospects to opportunities.
System should have capability of sorting, prioritization, flagging features for the customers.
System should have capability to add customer segments for revenue projection.
System should have capability to add priority flags to the customers
Campaign Management and Analysis
Campaign Management
System should have ability to create campaigns & events including details such as campaign/event type, campaign/event statu
expected response, proposed start and end date, actual start and end date
System should have capability to create campaigns at a defined level: branch, cluster, region
System should have ability for complete omni-channel campaign integration used for campaign management.
System facility to incorporate the end-to-end digital management of the leads generated through online channels
System should have ability to associate SMS, USSD Short Codes with campaigns. System should have ability to extend to QR
and run campaigns on CFHL mobile banking applications and website as well.
System should have ability to choose to send a combination of campaign messages across various channels:
a. E-mail, Standard mailing
b. SMS messages
c. Variable, multiple or specific methods, based on customer contact preferences
d. Push messages through WhatsApp.
e. Notification through Mobile Application
f. Social media campaigns

System should have ability for creation of categories:

a. Each contact (customers, internal employees, third party vendors, etc.) may belong to several categories
b. The categories should be able to be either static or dynamic, and easily configurable
c. Dynamic categories must include geographical targeting – for instance, creation of a category, or campaign, by physical add
location (irrespective of customer’s contact preference)
d. The system will allow an expiration date to be on a category
e. There must be the system should have ability to easily add, delete and/or inactivate categories
SMS:
System should have ability to preview messages before being sent
System should have ability to comply with anti-spam laws and also for SMS messages validate against DND filtration
E-mail:
System should have ability to allow images within e-mail body with appropriate text box alternates for text only recipient
System should have ability to associate sales literature such as product brochures to campaigns.
System should have ability to associate target product(s) to campaigns
System should have ability to associate target marketing list of prospects and customers to campaigns.
System should have ability to support workflow based approval to route planned campaign to management for approval
System should have ability to execute social media and mobile marketing campaigns with tracking and monitoring mechanisms.

System should have ability to support the use of historical campaign data in future campaigns Previous campaign reports/ cam
success, lead generation, etc. are to be generated for future planning with relevant data.
System should have ability to pass the target list to the Contact center to call to the target audience.
System should have ability to allow agents to record leads for those customers that express interest in the marketing campaign
Functionality to suggest an in-principal sanction amount based upon terms of the lead, basis minimum eligibility check
System functionality to generate editable application form online
Campaign Response and Analysis
System should have the capability to track campaign responses for users to capture prospect/customer's response if they are inte
or not interested in the offer.
System should have the capability to create segments based on past responses of prospects
System should have the capability to post campaign response and identify the total number of positive, negative response ha
received. Identify the effectiveness and reach of the campaign.
System should automatically or manually capture all the responses against the campaign and identify the existing customer an
customers from the responses. For existing customers new opportunity can be tagged. For new customers contact, product
leads related details need to be tagged.
System should able to capture the interaction of customer who has been contacted through various campaigns. All the respons
feedback should be stored against the contact.
System should able to show active campaigns running against a customer and all the campaigns of which customer was a part an
many times he was contacted for which campaign and what was his response to the communication. Response can have NU
blank values as well.
Sales Management
Sales Management
System functionality to manage and automate sales management, sales pipeline management, lead management, forecastin
closure

System functionality to configure and maintain the master list of channels for driving sales, marketing and communication chan
System should have provision to add/update/delete the master lists

System should be seamlessly integrated with Master Data Management solution and get the relationship information about cus
across the Group.
It should display the product holdings of the customer across CFHL
Individual:
System should have capability to extract meaningful information regarding customer behavior, spending pattern, channel pref
etc. about the customer using analytical platform (external or part of the system).
Non-Individual:
System should be able to display partnership, subsidiaries, trusts, association details for corporate customers.
System should have flexibility to add more parameters to add as per the business needs.
System should have the capability to show 360 degree view of a customer (individual/non-individual) including but not rela
Accounts (Loans, Deposits), Third Party Products (Insurance), Channel Preference, Years of Relationship with CFHL associate
the customer.
System should be able to identify the transactional pattern for a customer.
System should have the capability to flag a particular account/customer based on business rules configured in the CRM.
(e.g., this feature should allow the CRM users to identify suspicious transaction, frauds etc.)
System should able to identify life time value for the customer. Identify the potential customers based on the current holdin
calculate Life time value using business rules configured in CRM or Analytical Models outside CRM.
System functionality to define rules for conducting strategic marketing initiatives (e.g., pre-approved products based on sp
patterns across various channels that can be offered to the customers)
System functionality to conduct strategic marketing for the key customer segments
System should have ability to assign an assessment score or risk score to customers business rules configured in CRM or Ana
Models outside CRM.
Lead Management
Lead Generation - Quick Data Entry
Lead generation - Quick Data Entry
Provision for borrower to apply for a product through alternate channels (Aggregators, Website, Mobile Application etc.)
Functionality to configure the list of products customer is applying for through alternate channel (Refer B14 in LOS)
System functionality to configure the details/headers/information to be captured during generation/recording of the lead
System functionality to define categories of customer segment:
Individual
Non Individual
Individual
Provision to define details to be captured for lead generation through alternate channels
Applicant Details:
Name: First Name/Middle Name/Last Name
Demographics: Age, DOB, Gender, PAN No. Employment Status, Residential Status
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place
Communication Details : Mobile Number and/or Email only, for CFHL to contact customer
Non-Individual
Provision to define details to be captured for lead generation through alternate channels
Name of the Organization
Applicant Details (POC for Non-Individual):
Name: First Name/Middle Name/Last Name
Demographics: Date of Incorporation, Nature of Business, PAN No. of Organization & POC
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place
Communication Details : Mobile Number and/or Email only, for CFHL to contact applicant
System functionality to refer a new customer to CFHL by an existing customer: Customer Referral Schemes
Offline (through branch visit) reference code generation for existing customer to incentivize it
Functionality to generate the referral code for customers to act as feeder into the referral scheme
Define the minimum and maximum incentives to be paid for referral schemes
System functionality to generate and assign a lead number to customer and CFHL
System Functionality to assign the lead to nearest branch based upon PIN Code, call center team, Marketing Team or any
functional team as per requirement
Customer Self Application - Quick Data Entry
Customer Self Application
Loan Enquiry
Provision for borrower to apply for a loan through alternate channels (Website, Mobile Application etc.)
Functionality to configure the list of products customer is applying for through alternate channel (Refer B14 in LOS)
System functionality to configure the details/headers/information to be captured during generation/recording of the lead
System functionality to define categories of customer segment:
Individual
Non Individual
Individual
Applicant Details and Co-Applicant Details:
Name: First Name/Middle Name/Last Name
Father's Name/Mother's Name/Spouse's Name
Demographics: Age, DOB, Gender, PAN No. Employment Status, Residential Status
Work and Income & Liability Details
Legal heir(s)
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place
Communication Details (including PIN details): Permanent and Present Address
Capability to consider (or not to consider) the income of applicant / co-applicants for eligibility amount computation
Provision to view the list of document required for the respective loan application along with the sample images.
1. Pan-Card
2. Aadhar Card (to be stored in ADV against unique reference number as per ADV requirements)
3. Passport for NRI
4. Any other KYC document
5. Income Proof
Option to upload the images of the documents.
Provision to upload the photograph of the primary applicant by customer himself/herself.
Non-Individual
Name of the Organization
Applicant Details (POC for Non-Individual):
Name: First Name/Middle Name/Last Name
Demographics: Date of Incorporation, Nature of Business, PAN No. of Organization & POC
Revenue and Profit, Asset & Liability Details
Co-Applicant details, Other Owners/Directors/Partners
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place

Provision to view the list of document required for the respective loan application along with the sample images.
1. Pan-Card
2. TIN/TAN/GSTIN
3. Aadhar Card
3. CIN
4. Service Tax/Sales Tax
5. Income Statement/Balance Sheet
Option to upload the images of the documents.
Provision for customer to specify the Existing Relationship with CFHL (if any).
Existing vs new customer

Capability to send SMS/Email confirmation (Acknowledgement, Lead Generation, In-Principle Sanction Letter etc.,) along w
"Reference Lead Number" to Customer, Branch, call center team, Marketing Team or any other functional team as per requirem

Provision to capture Name, Mobile Number and/or Email only, for CFHL to contact customer
Provision for customer to print the application details along with "Reference Lead Number".
Facility to suggest to the customer nearest branch location based on PIN Code captured for the borrower
Provision to schedule appointment
Functionality to suggest an in-principal sanction amount based upon terms of the lead, basis minimum eligibility check
System functionality to generate editable application form online
Aadhaar Data Vault

System functionality to incorporate and integrate Aadhaar Data Vault (ADV) to store Aadhaar Numbers and any connected Aadh
data (e.g. eKYC XML containing Aadhaar number and data) in a centralized storage accordance with the regulatory requirement
Facility to access only on need to know basis.

System functionality to access ADV only on need to know basis.

System functionality to incorporate and integrate Aadhar Data Vault (ADV) with the CRM/Lead Management, Lending, Deposit
Insurance Module or other modules as may be deemed necessary by the management at CFHL
Storage of Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML containing Aadhaar number an
data)
System Functionality to Record the Aadhaar number in the CRM/Lead Management, Lending, Deposit, Insurance Modules
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI
System Functionality to record the Name, DOB, Address, gender based on details mentioned against Aadhaar Card Number.
System Functionality to record the verified details in Lending/Deposit modules
System functionality to compute the age of the borrower with the DOB assigned.
System Functionality to ensure editable fields for all such populated data.
System Functionality to generate associated unique reference key.
System functionality to replace the Aadhaar number with the reference key across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of transaction where Aadhaar number is exchanged, the reference key to re
the Aadhaar number.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to ADV.
System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the masked Aadhaar card based on reference number, if needed for regulatory purposes/other man
business engagements, but referenced through the key post the transaction.
System functionality to conduct Re-KYC of the customer based on risk category and update the same in ADV.

DSA - Quick Data Entry

Through DSA Agents
Handheld Devices
Facility to provide for handheld device for DSA agents
Ability to capture the basic customer details in the handheld device
Integration of the device with the core banking solution system
Provision for borrower to apply for a loan through alternate channels (Website, Mobile Application etc.)
Functionality to configure the list of products customer is applying for through alternate channel (Refer B14 in LOS)
System functionality to configure the details/headers/information to be captured during generation/recording of the lead
System functionality to define categories of customer segment:
Individual
Non Individual
Individual
Applicant Details and Co-Applicant Details:
Name: First Name/Middle Name/Last Name
Father's Name/Mother's Name/Spouse's Name
Demographics: Age, DOB, Gender, PAN No. Employment Status, Residential Status
Work and Income & Liability Details
Legal heir(s)
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place
Communication Details (including PIN details): Permanent and Present Address
Capability to consider (or not to consider) the income of applicant / co-applicants for eligibility amount computation
Provision to view the list of document required for the respective loan application along with the sample images.
1. Pan-Card
2. Aadhar Card
3. Passport for NRI
4. Any other KYC document
5. Income Proof
Option to upload the images of the documents.
Provision to upload the photograph of the primary applicant by DSA
Non-Individual
Name of the Organization
Applicant Details (POC for Non-Individual):
Name: First Name/Middle Name/Last Name
Demographics: Date of Incorporation, Nature of Business, PAN No. of Organization & POC
Revenue and Profit, Asset & Liability Details
Co-Applicant details, Other Owners/Directors/Partners
Product Requirement (Details of Products)
Product Type, Purpose of Loan
Loan Amount
Present Address,
Project Address, if any: Standardized Code/Names for State/District/Place

Provision to view the list of document required for the respective loan application along with the sample images.
1. Pan-Card
2. TIN/TAN/GSTIN
3. Aadhar Card
3. CIN
4. Service Tax/Sales Tax
5. Income Statement/Balance Sheet
Option to upload the images of the documents.
Provision for customer to specify the Existing Relationship with CFHL (if any).
Existing vs new customer

Capability to send SMS/Email confirmation (Acknowledgement, Lead Generation, In-Principle Sanction Letter etc.,) along w
"Reference Lead Number" to Customer, Branch, call center team, Marketing Team or any other functional team as per requirem

Provision to capture Name, Mobile Number and/or Email only, for CFHL to contact customer
Provision for customer to print the application details along with "Reference Lead Number".
Facility to suggest to the customer nearest branch location based on PIN Code captured for the borrower
Provision to schedule appointment
Functionality to suggest an in-principal sanction amount based upon terms of the lead, basis minimum eligibility check
System functionality to generate editable application form online
Aadhaar Data Vault

System functionality to incorporate and integrate Aadhaar Data Vault (ADV) to store Aadhaar Numbers and any connected Aadh
data (e.g. eKYC XML containing Aadhaar number and data) in a centralized storage accordance with the regulatory requirement
Facility to access only on need to know basis.

System functionality to access ADV only on need to know basis.

System functionality to incorporate and integrate Aadhar Data Vault (ADV) with the CRM/Lead Management, Lending, Deposit
Insurance Module or other modules as may be deemed necessary by the management at CFHL
Storage of Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML containing Aadhaar number an
data)
System Functionality to Record the Aadhaar number in the CRM/Lead Management, Lending, Deposit, Insurance Modules
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI
System Functionality to record the Name, DOB, Address, gender based on details mentioned against Aadhaar Card Number.
System Functionality to record the verified details in Lending/Deposit/Insurance modules
System functionality to compute the age of the borrower with the DOB assigned.
System Functionality to ensure editable fields for all such populated data.
System Functionality to generate associated unique reference key.
System functionality to replace the Aadhaar number with the reference key across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of transaction where Aadhaar number is exchanged, the reference key to re
the Aadhaar number.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to ADV.
System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the masked Aadhaar card based on reference number, if needed for regulatory purposes/other man
business engagements, but referenced through the key post the transaction.
System functionality to conduct Re-KYC of the customer based on risk category and update the same in ADV.

Lead Status Management

Provision to mark the lead as "Convert" after conversion of the product
Capability to "Reject" a lead. Provision to capture rejection reason.
Provision to put a lead on "Hold"
MIS and Dashboards
Reports
System to customize, generate and publish the desired dashboards, as per management discretion
Unique Customer Identification Code (UCIC)
At branch
Auto-mapping of customer fed details from various channels
Facility for the system to auto-populate the applicant fed details from alternate channels to create new Unique Customer
Identification Code (UCIC)
System functionality to create the UCIC as per the constitution of the customer
System functionality to create, modify, cancel, suspend, revoke suspension
Individual: System functionality to map the existing customer details from lead to UCIC Module, through KYC identifiers

Applicant Details:
Name (with title)
Demographics: Age, DOB, Gender, PAN No. Employment Status (Salaried, Professional, Pensioner, Self-Employed), Resident St
Parent's name

Communication Details (including PIN details):

Permanent and Present Address
E-mail Address, and phone number with validation
Provision to map the photograph of the primary applicant as uploaded by customer himself/herself.
Facility for the branch staff to modify the details provided in the lead by the borrower/depositor
Non-Individual
Name of the Organization
Applicant Details (POC for Non-Individual):
Name
Demographics: Date of Incorporation, Nature of Business, PAN No. of Organization & POC

Provision to view the list of document required for the respective loan application along with the sample images.
1. Pan-Card
2. TIN/TAN/GSTIN
3. Aadhar Card
3. CIN
4. Service Tax/Sales Tax
5. Income Statement/Balance Sheet
Option to upload the images of the documents.
Staff as borrower: Provision to capture additional information on existing staff loans
Employee ID
Employee name
Employee mobile Number
KYC Document checklist should be configurable
The minimum information to be captured for the retail customer are:
- Facility to auto mapping the Branch ID and Branch Name with the prospect, but should be interoperable by all CFHL branches
- Prospect name and title
- Prospect's DoB, Age, Gender, Residential Status, Marital Status, Religion, Caste, Category of Caste, Educational Qualification,
Customer Profile, Contact details (email, mobile, address),
- Identification document details PAN, Aadhar etc. (document type, unique id, place of issue, country of issue, issue date, ID issu
organization),
- PAN and Aadhar Validation, GSTIN validation in case of Business - logic to check for the correctness of PAN/Aadhar/GSTIN a
integration with regulatory portals to validate the same.
- Prospect's Legal Heir(s)
- Prospect Present and Permanent address details with option to select preferred address for communication (Present / Perman
New property address)

Customer Data Entry

Facility to parsing required customer details from KYC documents:
Name
Photograph (Aadhaar and PAN)
Signature (PAN)
DOB (Aadhaar)
Address (Aadhaar)
Provision to rectify the details parsed from KYC documents

eKYC verification of the customer with UIDAI and NSDL data base.
e-KYC:
e-KYC of PAN:
a. System functionality to conduct eKYC of PAN for the application in the CRM/Lead Management, Deposit, Lending, Insurance
Modules or other modules as may be deemed necessary by the management at CFHL
b. System Functionality to record the Name, Validated PAN Number or other details as may be deemed necessary by the manage
of CFHL based on details mentioned in NSDL database.
System Functionality to record the verified details in Lending, Deposit modules or other modules as may be deemed necessary b
management at CFHL
e-KYC of Aadhaar:
a. System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI in the CRM/Lead Management, Depos
Lending, Insurance Modules or other modules as may be deemed necessary by the management at CFHL
b. System Functionality to record the Name, DOB, Address, Gender or other details as may be deemed necessary by the managem
of CFHL based on details mentioned in UIDAI database.
System Functionality to record the verified details in Lending, Deposit modules or other modules as may be deemed necessary b
management at CFHL

Provision to have a configurable check (on specified fields)

De-duplication engine should check for the existing customer online based on configurable parameters like
Pan-Card
Aadhar Card
Any other KYC document
CKYC:
Registration
Verification
Integration
1. Ability to attach and upload the relevant documents - Photo, Signature
2. Upload of images and documents in a standardized format
Checker Functionality
System functionality for:
1. Movement of customer details from maker to checker bucket
2. Maker Checker provision for the purpose of customer creation.
3. Editing flexibility with the checker for the customer creation.
4. System should be able to show the audit trail/modification history with maker details.
System functionality for the checker to modify, cancel, revert for correction, suspend, revoke the customer
System facility to recognize lead generated by the borrower
Functionality to recognize the leads mapped by DSA to branches against DSA number
Functionality to map the leads to branches generated through alternate channels
Functionality for branch user to search an existing applicant so that same details can be used again for punching an application.
can either fill fetch UCIC number. By filling UCIC number, the customer details shall be auto-populated
Integration with Other Systems
The application shall have the capability of Enterprise CIF interfacing with E-KYC module for PAN/Aadhar based authentication

The application shall have the capability of CIF module to seamlessly integrate with DMS solution in order to capture customer
details, application form, KYC documents, customer communication letters etc.
Capability to integrate with LOS, LMS, Deposit, Insurance and other such applications to auto populate the customer informatio
these applications once the customer ID or any other customer identifier is provided(PAN no, Aadhar No etc.)
Storage of Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML containing Aadhaar number an
data)
System Functionality to Record the Aadhaar number in the CRM/Lead Management, Lending, Insurance Modules
System Functionality to conduct eKYC verification of the Aadhaar Number with UIDAI
System Functionality to record the Name, DOB, Address, gender based on details mentioned against Aadhaar Card Number.
System Functionality to record the verified details in Lending modules
System functionality to compute the age of the borrower with the DOB assigned.
System Functionality to ensure editable fields for all such populated data.
System Functionality to generate associated unique reference key.
System functionality to replace the Aadhaar number with the reference key across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of transaction where Aadhaar number is exchanged, the reference key to re
the Aadhaar number.
System Functionality to ensure the legacy data of the CFHL ecosystem be stored and migrated to ADV.
System functionality to replace Aadhaar number in log database with reference keys.
System functionality to fetch the masked Aadhaar card based on reference number, if needed for regulatory purposes/other man
business engagements, but referenced through the key post the transaction.
System functionality to conduct Re-KYC of the customer based on risk category and update the same in ADV.

Video KYC
Facility for video KYC to authenticate the information customer provided during online application
UCIC Changes
Changes/Modifications
System to enable branch users to modify the changes in UCIC Module basis customer request and documents submitted
System to enable maker-checker process for verification of customer details
Audit Trail to be maintained, including but not limited to:
Changes Made
User Details for recording changes, with date and time stamp
Re-KYC
Reports
System functionality to incorporate the Re-KYC module for KYC updating based on existing regulatory requirements
System functionality to provide multiple options for customer to provide KYC documents for Re-KYC purposes:
Online:
Self-Submission (WhatsApp/SMS/e-mail Link)
Mobile Application
Website
Offline through branches (walk-in)/DSA
System functionality to conduct Re-KYC of the customer based on risk category and update the same in ADV.
MIS and Dashboards
Reports
System to customize, generate and publish the desired dashboards, as per management discretion
De-Dupe Engine
De-duplication Engine

System functionality to define the parameters on which the de-duplication engine is to be configured and triggered (tentative b
limited to):
Full Name
Customer Mobile Number
PAN Number
Aadhaar Number (against unique reference number as per ADV)
Passport number
Any Other KYC Number
Customer DOB
Address (Passive)

System functionality to trigger the de-duplication check automatically and manually

Facility to run/re-run de-duplication checks at pre-defined stages and centrally across entire customer and customer master dat
Customer Creation
Application Processing (Loans/Deposits)
Post Application (Disbursal/Deposit Creation) De-dupe Checks
Master database de-dupe at specified intervals basis management discretion: monthly, quarterly, semi-annually, annually

System functionality to validate the de-duplication checks across customer categories: individuals and non-individuals
System functionality to report the de-dupe checks to defined authority within CFHL for processing, rectification and analys
correction

Facility to report the cases on which multiple IDs have been identified and suggest scenarios accordingly, including but not limit
Contacting customer
Merging the IDs
Suggesting and updating the customer details based on their verified KYC

System functionality to validate duplication checks against internal (across CFHL) and external databases (regulatory an
regulatory databases e.g. politically exposed persons, negative list etc.)
Application De-duplication Check
Application De-duplication
System functionality for user to log in into de-duplication search engine
Facility to select product, and sub-product
Facility to select application/deposit number for running the systemic de-dupe checks
System functionality to create a de-duplication check ID
System functionality to display the deduplication ID, Matched Customer ID, Matched Parameters, Current Input Value, Matche
Score, Data Source and matched parameters validity
System functionality for the maker to accept and suggest matched parameter validity
System functionality to display the customer details post the de-duplication check upon expanding UCIC number
Display details like (tentative but not limited to):
Customer Name
Customer Type
UCIC
Customer Name, Gender, DOB
PAN, Passport, Aadhaar (against unique reference number as per ADV), Voter ID, DL Number
Complete Address
Phone Number
Father/Mother/Spouse Name
System functionality to reflect the details filled in the application form versus available in database
Facility to check, respond and correct the details in either the application form or the UCIC module for the customer
Checker
Checker
System Functionality to include provision for checker in the de-duplication search engine module
System functionality to ensure that dedupe verifier checks & verifies the Details of each & every Parameter between the Request
Response and then decides to Approve or Reject the Customer Code to avoid the duplicate detail[s] of the UCIC
System Functionality to mark the case as checked & verified by the Approver ensuring the details are appropriate while compari
Request & Response details, then the Approver selects the option ‘Valid’ from the list
For modifications in customer data post de-duplication checks, the user selects UCIC mapped from data base.
Once the appropriate UCIC is selected, the checker clicks the Update Dedupe Status button for updating the details of the Custom
thereby, updating the details
Rejection of de-duplication results/UCIC:
Post de-dupe, if the maker-checker are not satisfied with the details while comparing the Request & Response details, then the c
selects the option ‘Invalid’ from the list
Index

Bidder
Bidder
Clarificat
Response
Importance ions /
(S/A/C/U
Comment
)
s

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
 
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
 
Critical
Critical
Critical

Critical

Critical

Critical
Legal & Secretarial Services
Sheet 12: Legal & Secretarial Services

Response
S
A
C
U

Id

1.1

1.2

1.3

1.4

1.5
1.6

1.7
2

2.1

2.2

2.3

2.4
3
3.1

3.2

3.3
4

4.1

4.2
4.3
4.4
5

5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
6

6.1
6.2
7
7.1
7.2
7.3
7.7

7.5
7.6
8
8.1

8.2

8.3

8.4
gal & Secretarial Services
eet 12: Legal & Secretarial Services

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Empanelment of advocates

- The system should be able to empanel the advocates.

- Unique ID for the empaneled lawyer. The recommended ID should be - State Code-District Code-Code number
- The system should have the capability to capture the basic minimum details of the potential advocate.
- Name
- ID Proof
- Branch ID/Code/Name
- Phone number
- Bar Council code/certificate etc.
- The system should be able to upload the mandatory documents provided by the potential advocate.
- The system should have checklist to verify the documents which needs to be provided by the potential advocate.
- The system should be able to map the branch code to the potential advocate and this should be mandatory.
- Facility for maker checker should be provided by the system. The branch should be the maker for the empanelment of advocate
officers and managers to be the reviewer and the RO Legal HOD should be the checker.
- Facility for remarks and comments to be added in the system.
- Integration with the LoS system for the list of authorized empaneled lawyers to be available in the LoS screen.

- The system should have the provision for HOD-Legal to have complete control over all the legal masters.
- The system should make fields for mandated documents to be compulsory for submission of form.
- The system should have the capability to attach all the documents in a standardized format. The system should be able to hand
size types documents.
- Facility for allocation and redistribution of empanelment cases for review to legal officers. This should be handled by HOD - Le
and managers.
- The system should be able to keep the incomplete/unauthorized/pending empaneled applications in a queue and the name of t
reviewer(Officer or manager)
- The number of days officers or manager take to finally review and send the doc
- The system should also reflect the status of such application as pending/rejected/completed/unauthorized etc.

- The system should be able to provide de dupe check for the application of the empaneled lawyers.
- The de dupe check can take place basis the following: Name, phone number, Bar Council number etc.
- The branch code, branch ID should be mapped to a potential empaneled advocate.
- Facility to provide the expiry date and renewal date of empaneled lawyers in the system.
- Facility to trigger alerts in case of expiry of empaneled advocate's contract.
- Facility to maintain the rejected cases in the system.

- The list of empaneled lawyers should be maintained in the system and the branch in charge should be able to view the same.
- The system should maintain the audit trail in the system - maker, reviewer and checker.
- The system should be able to trigger alerts when the expiry date of the contract of the empaneled lawyer is approaching.
- Facility to Dis empanel a lawyer.
- Facility to track and raise alerts in case of shortage or excess of lawyers.
- Facility for the renewal date of the empaneled lawyer.
- Facility to map the ID of the LSR cases to the empaneled lawyer. The ID should be reflected in the+C7:C8 system.

- The system should be able to intimate the branches for the final status of empanelment of each lawyer.
- The system should intimate the empaneled lawyer post successful empanelment stating the terms of empanelment - the standa
empanelment letter to be generated from the system and the relevant details like Branch Name or Branch ID along with the lawy
details should form a part of the given empanelment letter.
Legal Scrutiny

- Facility to provide for a separate Legal Scrutiny application system.

- Facility to provide the basic details of the legal cases. This include the following:
Branch Code
Branch ID
Branch Name
Loan details
Customer ID and customer details
- The system should have the features to upload all the details of the legal documents in the legal scrutiny system.
- The system should include a checklist of legal documents that needs to be uploaded by the branch for the purpose of legal scrut
- The system should have the capability to attach the original and the photocopy of the legal documents.
- The RO legal team should have the accessed to the Legal scrutiny screen.
_ The system should have the facility to provide status of a given legal report. The status such as approved/rejected/under review
should be updated for a given legal case.
- Facility to provide remarks/comments/recommendation for a given legal case.

- The system should have the authority workflow configured so as to route the given legal cases to the concerned authority - Cred
team or Legal team.
- The system should have the tracking and monitoring of the legal cases and their status.
- Facility to reflect the list of legal cases pending in the system. The system should have the logic to assign a given legal case regio
wise /area wise / cluster wise /Loan amount with an officer or manager.
- The HOD Legal should have the final authority to reallocate or reassign cases to a given officer or manager
- Facility to reflect the list of legal documents pending to be collected form the customer.
- The system should be able to provide the checklist of documents needed at each stage of pre-sanction, pre-disbursal and post-
disbursal to ensure that the branches keep track of the same.
- The RO legal team should have the authority to overview all the legal cases.
- The system should have the facility to generate a summary of reports of the legal cases, along with loan details mapped to them
the status of such cases as on the given date.
Agreements
- The system should be able to create and generate the loan agreements - for all types of loan.
- The loan agreement generated from the system should have all the information fetched from the LOS system.
- The system should auto populate the terms and conditions of the loan in the loan agreement generated by the system. The bran
should ensure that the revenue stamp should be attached to the loan agreement.
- The system should have a standard loan agreement template.
- The access to view/modify/comment should be provided to the legal team.
- The system should automatically route the loans above 75 Lakh to the RO legal team for verification.
- The system should provide an option to the branches to route a given loan to RO legal team for verification with reasons.
- The authority workflow should be configured in the system and the loan agreements should be routed through that.
- The above points should also be applicable on:
1. MODTD - Memorandum of deposit of title Deeds
2. LEDTD - Letter Evidencing deposit of Title Deeds
3. Affidavit cum Undertaking
4.Letter of Guarantee and such other documents.

- The system should be capable enough to track and manage the agreements/deeds/Letter of guarantee/affidavit and provide th
status of the same verified by the legal team.
- The system should be able provide status of the agreements/deeds/Letter of guarantee/affidavit verified by the RO Legal team
pending/completed/in progress.

The standard premise lease deed template to be generated from the system. This should be for both- for renewal and for fresh le

Central Repository
The system should be able to maintain a central repository for the purpose of storing and maintain all the latest circulars issued
regulatory bodies like NHB, SEBI etc.

The system should have the capability to keep a backup of these circulars in case the given regulatory website is not responding.
The access of this repository should be available to all the major departments at RO.
In case any given circular is in physical form, such circulars should be scanned and uploaded in the system.
Compliance Calendar
- The system should be able to maintain a compliance calendar with the information on all the regulatory and compliance related
which are due along with completion status.

- The system should be able to maintain the regulatory and organizational tasks along with the start date and deadlines.
- The system should be able to assign tasks for completion and notify others of task status.
- The system should also be able to track status of tasks including open, closed, past due or WIP tasks.
- The system should also have the summary of tasks to provide an overview of the tasks present.
- The system should have the filtering option along with daily, weekly, monthly, quarterly etc. due dates.
- The system should also be able to provide annual calendar view for the same.
- Trigger alerts for regulatory tasks as and when they are approaching in form of email reminder or notifications.
- Facility to mark task as very important, important as per the requirement of the task.
- The responsible party should also be mentioned and the trigger alerts should also be provided to them.
- The system should be able generate a report which will provide the graphical representation of compliance levels.
Office notes

- The system should be able to maintain all the office related communications in the form of digital notes.

- All communications should take place using digital notes.

Investor Details
- Currently, RTA provides the investor information in the format of an excel. This information should be stored in the system. Th
business user can upload the information in the system.

- The system should have the capability to maintain investor details and the investments made by them.
- This should be available on Can Fin website.
The basic details such as name, address, phone number, KYC etc should also be maintained.
The system should also maintain the details of the investment made by the investor. The details should include the amount, date
dividend amount, dividend distribution date, etc.
The investor information is crucial, so all data related to them must be backed up by the system.
Dividend Revalidation Data
- The system should maintain the dividend details of the investors.
- The data for dividend revalidation must also be maintained. This majorly includes the dividend which is not been claimed by t
investor.

- The system should be able to generate report for such unclaimed dividend.
Note: The unclaimed dividend is mostly in cases where the investor does not have a demat account.
In case the unclaimed dividend is there for more than 7 years, the same is transferred to IPEF.
- This should be a part of Investor detail information. The Dividend revalidation data should also be added along with attachmen
case the information is physical).
Index

Bidder
Bidder
Clarificat
Response
Importance ions /
(S/A/C/U
Comment
)
s
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical
Good to
Have

Good to Have
Good to Have
Critical
Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical
API Manager
Sheet 13: API Manager

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement
1 API Manager Deployment & Update
API Manager shall support a solution where the API gateway and the rest of the
components like the API dashboard, API Developer Portal etc. are available on
1.1 cloud. Cloud datacenter location must be in physical boundaries of India. Bidder
must ensure to provide services from same cloud provider where target
infrastructure is hosted.
Solution shall provide timely notifications and information regarding software
1.2 upgrade and other patches. On a cloud deployment option, all components shall
be automatically updated.
API manager should comprise of the following components (not limited to)
1.3 API Gateway, API Dashboard, API Creation, API Publication, Securing API and
monitoring API.
Module Functional Requirements
2 API Manager
API Manager shall provide a management portal to configure and manage the
2.1
life cycle of the API.
API Manager shall provide the capability to deploy APIs on API Gateway using
2.2
the API management portal (WebUI).
API Manager shall provide the capability for APIs to be published through an
2.3
API catalogue (Pre-defined API).
API Manager shall provide the capability to show API blueprint for the API
2.4
documentation.
API Manager shall provide the capability to define security policies. Security
2.5 policies shall include parameters like API access control, usage quota, rate limit
etc.
2.6 API Manager shall provide the capability to link security policies to APIs.
API Manager shall provide capability to optionally integrate with 3rd party API
2.7
key generator.
API Manager shall provide capability to optionally integrate with 3rd party
2.8
identity providers.
API Manager shall provide capability to specify the error response on failed
2.9
authentication. It should maintain logs required for audit.
API Manager shall provide the capability to define APIs versions (a.k.a. API
2.10 versioning) to support multiple versions of the API. This feature shall be
available as configuration through API dashboard or the admin portal.
API Manager should provide the capability to customize the API developer
portal based on the customer requirements (API Manager developer portal
2.11 should be customizable).
API Manager should provide basic transformation capabilities (e.g.
2.12 protocol/message transformation, enrichment, routing etc.).
The API Manager should have capability to create/support SOAP based/REST
2.13 based/Any other API's based on the requirement.
 API Manager should provide the capability to configure/deploy/manage API
2.14 gateways at both DC/DR location.
The application developers should be able to request for API/API plan access
2.15 using the API developer portal.
The API admin should be notified for the API plan request made by developer.
The API admin should be able to grant or reject the request using a workflow.
The workflow should be customizable and configurable to add different level of
2.16 approvals.
API Manager should provide the capability to notify subscribed consumers
2.17 about any change or update into the published APIs.
API Manager should provide out of the box API analytics capability (to
determine how, when, and why APIs are being used, review how often and why
2.18 requests are rejected, and monitor data trends).
API manager should provide the capability to customize the analytics as per
2.19 requirements.
API Manager solutions must be easy to deploy, operate & scale up/down based
2.2 on the target state application's requirement.
API Manager should provide the capability to Integrate with 3rd party as well as
2.21 native cloud tools for logging, error & log analysis tools.
API Manager shall support TLS (Latest version) connections for secured
2.22 communication channel.
2.23 API Manager should have capabilities to support SaaS based applications.
API Manager should have capabilities to support notifications through WebUI,
2.24 Email or SMS.
Index

Importance Bidder Response (S/A/C/U) Bidder Clarifications / Comments

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
ADV Index
Sheet 14: ADV

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement Importance

Module Aadhaar Data Vault

1 Aadhaar Data Vault Critical
System functionality to incorporate and integrate Aadhaar Data Vault (ADV)
to store Aadhaar Numbers and any connected Aadhaar data (e.g. eKYC XML
1.1 Critical
containing Aadhaar number and data) in a centralized storage accordance
with the regulatory requirements.
1.2 System functionality to access ADV only on need to know basis. Critical

System functionality to incorporate and integrate Aadhar Data Vault (ADV)

1.3 with the CRM/Lead Management, Lending, Deposit, TP Insurance Module Critical
or other modules as may be deemed necessary by the management at CFHL

Module Functional Requirements

2 Aadhaar Data Critical
System Functionality to Record the Aadhaar number in the CRM/Lead
2.1 Management, Deposit, Lending, Insurance Modules or other modules as Critical
may be deemed necessary by the management at CFHL
System Functionality to conduct eKYC verification of the Aadhaar Number
with UIDAI in the CRM/Lead Management, Deposit, Lending, Insurance
2.2 Critical
Modules or other modules as may be deemed necessary by the management
at CFHL
System Functionality to record the Name, DOB, Address, Gender or other
details as may be deemed necessary by the management of CFHL based on
details mentioned in UIDAI database.
2.3 Critical
System Functionality to record the verified details in Lending, Deposit
modules or other modules as may be deemed necessary by the management
at CFHL
System Functionality to generate associated unique reference key.
2.4 System functionality to replace the Aadhaar number with the reference key Critical
across the entire ecosystem of CFHL.
System Functionality to ensure that post completion of any transaction
2.5 where Aadhaar number is exchanged, the reference key to replace the Critical
Aadhaar number, when needed.
 System Functionality to ensure the legacy data of the CFHL ecosystem be
stored and migrated to ADV:
All the existing Aadhaar related information to be stored in the Aadhaar
2.6 Critical
Data Vault.
Functionality to ensure that the scanned copy of the physical Aadhaar card
be masked and stored in an encrypted format within CFHL database.

System functionality to replace Aadhaar number in log database with

2.7 Critical
reference keys.
System functionality to fetch the Aadhaar information based on reference
number, if needed for regulatory purposes/other mandated business
2.8 Critical
engagements, but referenced through the key post the transaction, via APIs
to whitelisted IP addresses.
System functionality to conduct Re-KYC of the customer based on risk
2.9 Critical
category and update the same in ADV.
System functionality to conduct de-duplication checks based on unique
2.10 Critical
reference keys mapped against Aadhaar number.
 Bidder
Bidder
Clarificat
Response
ions /
(S/A/C/U
Comment
)
s
Reports Index
Sheet 15: Reports

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement Importance

Module Reports
1 CUSTOMER AND AGENTS
1.1 Dsa Commission report (proposed) Critical
1.2 loan Disbursed -Sourced Through DSA Critical
1.3 K Y C Details Critical
1.4 DSA Agent Detail report Critical
1.5 Customer Portal Access enabled Loan Account Details Critical
1.6 Customer Portal feedback Critical
1.7 Month End DSA Commission Posting (Actual) Critical
1.8 applicant and Coapplicant Mobile Number Critical
1.9 HL (Home Loans) Not linked with PL (Personal Loans) Critical
1.10 Marketing Officer Commission Report (proposed) Critical
1.11 loan Disbursed -sourced Through Marketing Officer Critical
1.12 Month End Deposit Commission Posting (Actual) Critical
1.13 Month End Marketing Officer Commission Posting (Actual) Critical
1.14 Deposit commission payable for the period for the month Critical
2 DEPOST Reports
2.1 201 Balance Outstanding Report Critical
2.2 202 Deposit Account Ledger Critical
2.3 203 Account Status Critical
2.4 204 Register Of Deposits Critical
2.5 205 Interest to be posted Critical
2.6 206 TDS Submit Form Critical
2.7 207 Deposit Overdue Report Critical
2.8 208 Deposit Renewal and repaid Critical
2.9 209 Deposit Closed/Preclosed Critical
2.10 210 Deposit Interest Paid Certificate Critical
2.11 211 Deposit Matured List Critical
2.12 212 Details Of Unclaimed Deposit Critical
213 Deposit Account Due For Transfer to IEPF (Investor Education and
2.13 Critical
Protection Fund)
2.14 214 Deposit Maturity Letter Critical
2.15 215 Deposit Interest Paid Through Cheque Critical
2.16 216 Form 15 G -15 H Covering Letter Critical
2.17 217 TDS Form 15 G to be received Critical
2.18 218 TDS Form 15 H to be received Critical
2.19 219 TDS Form 15 G Generation Critical
2.20 220 TDS Form 15 H Generation Critical
2.21 221 15G/15H Submission Details Critical
2.22 222 Deposit Master Sheet Critical
2.23 223 Deposit Master Sheet Critical
2.24 224 Deposit Application Form Critical
2.25 225 Accounts Matured and to be Matured in next 14 days Critical
2.26 226 Control Report for Deposit Critical
2.27 227 Deposit Interest Posted For Month Critical
2.28 228 Customerwise Deposit Interest Reports Critical
3 CLEARING
3.1 600 . Bills Payment Received Report Critical
3.2 601 . Deposit PDC (Post dated Cheques) Report Critical
3.3 603 . Bank GL (General Ledger) Reconciliation Report Critical
3.4 602 . Cheque to be Presented Critical
3.5 3 All Bounced Details for Branches Critical
3.6 4 All Bounced Details for RO (Registered Office) list Critical
4 FAS
4.1 301 Monthly Profitability Statement Critical
4.2 302 Day Book cum Trial Balance Critical
4.3 303 Trial Balance Critical
4.4 304 Daily Transaction Check List Critical
4.5 305 Cash Summary Critical
4.6 306 Voucher Printing Critical
4.7 307 General Ledger Critical
4.8 308 General Ledger - All Accounts Critical
4.9 309 Consistency Check - For all products Critical
4.10 310 Interest Spread Critical
4.11 311 PDC To Be Presented Critical
4.12 312 Cheque Return Letter Critical
4.13 313 Cheque Return List Critical
4.14 314 PDC Exhaust List Critical
4.15 315 PDC Exhaust letter Critical
4.16 316 PayIn Slip Critical
4.17 317 PDC Acknowledgement Critical
4.18 318 PDC Pending Critical
4.19 319 Audit Log Report for the branch Critical
4.20 320 Rejected Transaction Critical
4.21 321 List of Users Added Critical
4.22 322 List of Blocked Users Critical
4.23 323 PRR 1 (Periodical Review Return) Business Performance vis a vis Target Critical
4.24 324 Cash Incentive Score Card Critical
4.25 325 Pending Transaction For the Day Critical
4.26 326 Cash Receipts for 10 Thousand or more for Loans and Others Critical
327 Cash Receipts for 10 Thousand or more for PF (Processing Fee)
4.27 Critical
Collection
4.28 328 Product Wise Outstanding Critical
4.29 329 LS (Liability Suspense) - Charges Critical
4.30 330 Tally Sheet (Excluding Loan and Deposit Heads) Critical
4.31 331 Branch Manager MIS II Critical
4.32 332 Master list of vendors for Taxes Critical
4.33 333 LS AS (Liability Suspense-Asset Suspense) Link Balance Details Critical
4.34 334 LS AS Link Transaction Details Critical
4.35 335 Sarfaesi Balancing Report Critical
4.36 336 BRANCH CSR (Corporate Social Responsibility) Reports Critical
4.37 337 NACH Mandate Critical
4.38 338 Tally Sheet for the day (Excluding Loan and Deposit Heads) Critical
4.39 339 Audit Trail report Critical
4.40 340 LS Charges for the File Critical
4.41 341 Control Report for PF Critical
4.42 342 Nach Mandate Master Critical
4.43 343 LS Charge Details for Account Critical
4.44 345 LS-Charges Details 144009 Critical
4.45 346 LS Charges 144009 Critical
4.46 347 Link Letter Status Critical
4.47 348 Link Letter Missed Accounts Critical
4.48 350 PF (Processing Fee) Appropriation Critical
4.49 351 PF (Processing Fee) Appropriation for file Critical
4.50 352 Newly Developed or Well-Developed Layout Pending – Cluster MIS Critical
4.51 354 ROI Reduction with IAC (Interest Adjustment Charges) Concession Critical
4.52 355 Vendor Transaction Branch during the period Critical
5 YEAR END REPORTS
5.1 401 Trial Balance Critical
5.2 403 Annexure BS6 (Balance Sheet) Critical
5.3 404 Statement of Service Tax Payable Critical
5.4 405 ADVANCES AND BORROWINGS MATURING IN NEXT 12 MONTHS Critical
5.5 406 Annexure BS7 (Balance Sheet) Critical
5.6 408 Details Of Unclaimed Deposits Critical
5.7 409 Details Of Deposits Critical
5.8 410 PA (Performing Asset) Supporting Sheet Critical
5.9 411 NPA SUPPORTING LIST - Month End Critical
5.10 412 ROI /Period Wise Outstanding Critical
5.11 413 Loan Consolidate Product Wise As On Date Critical
5.12 414 TB (Trial Balance) before Inc. and Exp. Transfer Critical
5.13 415 Dep Int Grtr than Five Thousand Critical
5.14 416 Statement Of Fixed Asset Critical
6 F&A
6.1 1100 . Trial Balance Consolidate - RO Critical
6.2 1101 . Interest Spread F A (Finance and Accounting) Critical
6.3 1102 . FD Notional Interest Critical
6.4 1103 . RO Br Reconciliation Critical
6.5 1104 . Deposit Matured 7 Year and Above Critical
6.6 1105 . NPA Provision Statement Critical
1106 . NPA Provision Statement without TWO (Technically Written Off)
6.7 Critical
Accounts
6.8 1107 . NPA Provisioning - RO Critical
6.9 1108 . NPA Provisioning Account wise - RO Critical
6.10 1109 . CAR (Capital Adequacy Report) Report Critical
6.11 1110 . NPA Provisioning - RO Group Critical
6.12 1111 . Details of Exempted Deposits Critical
6.13 1112 . BALANCING OF LS. BAD DEBTS TWO HL ACCOUNT Critical
6.14 1113 . GL Code List Critical
6.15 1114 . Monthly Profitability Statement _ FA Critical
6.16 1115 . NEW CAR (Capital Adequacy Report) INPUT DATA Critical
6.17 1116 . RO Branch Transaction Critical
6.18 1117 . EMI Receivable and Received Report Critical
6.19 1118 . Cheque ECS Return Charges Critical
6.20 1119 . Category Wise Disbursement Critical
6.21 1120 . NACH Transaction Details Critical
6.22 1122 . Nach Account Transaction Details Critical
6.23 1123 . Nach Upload Status Details Critical
6.24 1124 . Nach Mandate Cycle Details Critical
6.25 1125 . Top 20 Deposit Loan Customers Critical
6.26 1126 . NACH Acct TXN Details Critical
6.27 1127 . Consolidated Product changed Details - Branch wise AsonDate Critical
6.28 1130 Report for Excess EMI Balance Critical
6.29 1131 Periodic Disbursementwise Yield calculation Critical
6.30 1132 Closed Accounts with ECS Repaymode Critical
6.31 1133 Income Expenses Critical
6.32 1134 DSA Commission RCM (Reverse Charge Mechanism) Report Critical
6.33 1135 LS AS Balancing Report Critical
7 RECOVERY
7.1 1200 . NPA Support For RO Critical
7.2 1201 . NPA Provision Statement Critical
7.3 1202 . NPA Provision Statement without TWO Accounts Critical
7.4 1203 . NPA Provisioning - RO Critical
7.5 1204 . NPA Provisioning Account wise - RO Critical
7.6 1205 . NPA Provisioning - RO Group Critical
7.7 1206 . Special Mentioned Accounts Typewise consolidated Critical
7.8 1207 . NPA Reversal Analysis Critical
7.9 1208 . NPA Accounts List Consolidated Critical
1209 . SARFESI (Securitisation and Reconstruction of Financial Assets and
7.10 Critical
Enforcement of Security Interest) Details
1210 . QMA (Quarterly Management Audit) Reports and SMA2 Less than 1
7.11 Critical
Year
7.12 1211 . Daily SMA2 Analysis Critical
7.13 1212 . Daily SMA1 Analysis Critical
7.14 1213 . Daily NPA Analysis Critical
7.15 1214 . Daily SMA NPA Analysis Critical
7.16 1215 . SMA Movement Critical
7.17 1216 . Builder Loan Critical
7.18 1217 . Return Transaction List Critical
7.19 1219 . Outstanding Grt than Disb Amt Critical
7.20 1220 . Loan Account Statement - NPA Critical
7.21 1221 Daily Check List For SMA and NPA Critical
7.22 1222 NPA Added Accounts Details Critical
7.23 1223 NPA Valuation Of Properties Critical
7.24 1224 SARFAESI Information Critical
7.25 1225 SMA Current Position Critical
7.26 1226 SMA Total Delinquent Details Critical
7.27 1227 SMA Delinquent Details All Accounts Critical
7.28 1228 Loans for Cross Verification for the Period Critical
7.29 1229 Loan Closed Preclosed Critical
7.30 1230 Normal Closure Report Critical
7.31 1231 TAKEOVER Closure Report Critical
7.32 1232 Return Instrument Status Critical
7.33 1233 Restructured loan Details-Due detail Critical
7.34 Report 130 CDSC (Central Document Storage Center) Retrieval Process Critical
7.35 Report 131 CDSC (Central Document Storage Center) Submission Process Critical
7.36 Report 132 Account List No Credits Critical
7.37 Concall data Critical
7.38 Lon_SMA0Probable_New Critical
8 LOS REPORTS
8.1 500 . RO Sanction Communication Letter Critical
8.2 501 . Letter of Guarantee Critical
8.3 502 . Letter Evidencing Deposit of Title Deeds Critical
8.4 503 . Check List for scrutiny and Approval of LSR (Legal Scrutiny Report) Critical
8.5 504 . Acknowledgement DSA Critical
8.6 505 . Acknowledgement Direct Critical
8.7 506 . Affidavit cum undertaking Critical
8.8 507 . Sale deed authorization letter Critical
8.9 508 . Compliance certificate Critical
8.10 509 . Disbursement request Critical
8.11 510 . Tripartite agreement Critical
8.12 511 . CDSC Consolidated Document Details for All Branches Critical
8.13 512 . MITC (Most Important Terms and Conditions) Report Critical
8.14 513 . Concise Report for Obtaining Sanction From RO Critical
8.15 514 . Concise Report for Obtaining Sanction From RO (BUILDER) Critical
515 . Concise Report for Seeking Reduction in ROI and PC (Processing
8.16 Critical
Charges)
8.17 516 . Appraisal Report Critical
8.18 517 . Concise Tracking Report Critical
8.19 518. LinkLetter Upload Report Critical
8.20 519. Loan File Report Critical
8.21 520. CPC Inwarded Files Status Critical
8.22 521 Concise Product Change Status Critical
8.23 522 Concise Product Change RO Pending Status Critical
8.24 523 CONCISE FOR LOAN PRODUCT CONVERSION Critical
8.25 524 PENDING FILE STATUS FOR THE PERIOD Critical
8.26 525 Notice to the borrower branch on revision in interest Critical
8.27 526 PRE-SANCTION VERIFICATION REPORT(PSVR) Critical
8.28 527 Credit Score Sheet for File Critical
8.29 528 FORM NO.60 Critical
8.30 171 Security Details of File Critical
172 Pradhan Mantri Awas Yojana (U)-CLSS (Credit Linked Subsidy Scheme)
8.31 Critical
Aadhaar Consent for Authentication
8.32 173 CLSS Affidavit-Cum-Undertaking Critical
8.33 174 Fair Practices Code (FPC) Critical
8.34 175 Most Important Terms and Conditions (MITC) Critical
8.35 176 Annexure for FPC and MITC Critical
8.36 177 Request Apporoved Staus Report Critical
8.37 178 Request Pending Staus Report Critical
9 GENERAL R O REPORTS
9.1 1000 . Day Book cum Trial Balance Critical
9.2 1004 . NPA CONSOLIDATED Critical
9.3 1005 . RO GL Extract Critical
 9.4 1006 . Deposit Balancing Report Critical
9.5 1007 . Loan Balancing Report-RO Critical
9.6 1008 . Asset Price Monitoring System Critical
9.7 1009 . NHB Residex Critical
9.8 1010 . Negative Balance Report Critical
9.9 1011 . PEMI (Pre-EMI) B226Demand Report For RO Critical
9.10 1012 . Term Closure Report For RO Critical
9.11 1013 . ROI /PeriodWise Outstanding Critical
9.12 1014 . MonthWise ROI/EMI/Interest For All Branches Critical
9.13 1015 . Details of Loan Canvassed By DSA Critical
9.14 1016 . CREDIT MONITORING - Sanction Review Details Critical
9.15 1017 . CREDIT MONITORING-Overseeing Executive Review Pending Critical
9.16 1018 . CREDIT MONITORING-Overseeing Executive Review Completed Critical
9.17 1019 . Overseeing Executive Review Critical
9.18 1020 . ECS Mobile Number Critical
9.19 1021 . Deposit Maturing Mobile Number Critical
9.20 1022 . Loan SWL (Special Watch List) Mobile Number Critical
9.21 1023 . Regular Account Mobile Number Critical
9.22 1024 . Loan Accounts Top 100 and 10 Critical
9.23 1025 . Customer Bday Greetings Critical
9.24 1026 . Sanction Review-MIS Critical
9.25 1027 . List of Files sanctioned by RO Critical
9.26 1028 . List of Files Pending at RO Critical
9.27 1029 . Monthly Yield Caluclation Product Wise Critical
9.28 1030 . SO Sanction Details Critical
9.29 1031 . HRM STAFFLOAN REPORT Critical
9.30 1032 . Deposit and Loan Files Critical
9.31 1033 . Probable SMA - RO Critical
9.32 1034 . Credit Monitering Consolidated Critical
9.33 1035 . First Disbursement Details of Loan Accounts with in date range Critical
9.34 1036 . Disbursement Details Critical
9.35 1037 . PDC Exhause List Critical
9.36 1038 . Marketting officer Sanction Details Critical
9.37 1039 . Inwarded File List Critical
9.38 1040 . Sanctioned File List Critical
9.39 1041 . RO CSR Reports Critical
9.40 1042 . GLHead Extraction Reports Critical
9.41 1043 . Credit Monitoring Ageing Report Critical
9.42 1044 . Daily SMA NPA Analysis Critical
9.43 1045 . Lead Management Report Critical
9.44 1046 . Lead Status Report Critical
9.45 1047 . End of Day Log Critical
9.46 1048 Monthly Yield Caluclation SUB_Product Wise Critical
10 IND AS Reports
10.1 12001 INDAS Trial Balance Critical
10.2 12002 INDAS Grouping Critical
10.3 12003 INDAS Notes Critical
10.4 12004 INDAS Profit and Loss Critical
10.5 12005 INDAS Balance Sheet Critical
10.6 6 PF (Processing Fee) Amortization Critical
10.7 8 Balancing Processing Charges Critical
10.8 9 PF Amortization for closed Account Critical
 11 LAM REPORTS
11.1 1 Loan Statement and Closure Details enabled Account Critical
11.2 2 Closure Account Details Critical
11.3 3 Loan Closed Preclosed Critical
11.4 4 Normal Closure Report Critical
11.5 5 TAKEOVER Closure Report Critical
11.6 6 LOAN CLOSED DETAILS Critical
11.7 7 TakeOver Bulk Upload Report Critical
11.8 8 Takeover Status Report Critical
11.9 48 Cluster Wise Outstanding Critical
12 INSURANCE
12.1 Insurance Report Critical
12.2 Claim Register Critical
12.3 Premium register Critical
12.4 CA (Corporate Agency) ledger Critical
12.5 Daily MIS CHOICe Critical
12.6 Daily MIS BAGIC Critical
12.7 Commission Statement Report CHOICe Critical
12.8 Commission Statement Report BAGIC Critical
13 LSWRO (Loan Sanction Workflow RO)/CPC--CPC REPORTS
13.1 List Of files Sanctioned By CPC-------------not fetching the data Critical
13.2 Appraisal Report Critical
13.3 CPC (Central Processing Center) Inwarded File Status Critical
13.4 Loan File Report Critical
13.5 CPC Sanction File Comminication Letter ---------no matching record Critical
13.6 CPC Rejected Files Critical
13.7 CPC Pending File Status Critical
13.8 345 LS-Charges Details 144009 Critical
13.9 346 LS Charges 144009 Critical
13.10 Loan Statement Of Account Critical
13.11 New Appraisal Reports Critical
14 LOANS
14.1 101 Loan Outstanding Critical
14.2 102 Loan Statement of Accounts Critical
14.3 103 Loan Restriction Report Critical
14.4 104 Interest Not Debited Critical
14.5 105 PEMI Demand Critical
14.6 106 Sanctioned But Not Disbursed Critical
14.7 107 Sanction List MIS Critical
14.8 108 Disbursement List MIS Critical
14.9 109 Overdue Letter Account wise Critical
14.10 110 NPA List as on date Critical
14.11 111 Provisional I T (Income Tax) Certificate Critical
14.12 113 Last Fn IT Statement Critical
14.13 114 Agent Commission Details Critical
14.14 115 Loan Closed/Preclosed Critical
14.15 116 Loan Closure Details Critical
14.16 117 Letter Of authority From Joint Borrowers Critical
14.17 118 Letter Of Pledge For Deposits Critical
14.18 119 Risk Assessment ROI Details Critical
14.19 120 ROI 13 and above PA (performing assets) accounts Critical
14.20 121 . Accounts in Pre EMI for more than 24 months Critical
14.21 123 . CREDIT MONITORING-Branch Review Completed Report Critical
14.22 124 . Credit Balance in loan accounts Critical
14.23 125 . NPA Account History Card - IAMS Critical
14.24 126 Accounts in which Mortgage details Critical
14.25 127 . SMA 0 Critical
14.26 128 . SMA 1 Critical
14.27 129 . SMA 2 Critical
14.28 130 . CDSC Retrieval Process Critical
14.29 131 . CDSC Submission Process Critical
14.30 132 . Account List No Credits Critical
14.31 133 . Customer Mobile Number Details Critical
14.32 134 . LTV greater than or equal to 75 Critical
14.33 135 . PEMI Account O/s Amount greater than disbursal Critical
14.34 136 . ECS Mandate Form Critical
14.35 137 . Uniform ROI Critical
14.36 138 . Revised EMI Accounts List Critical
14.37 139 . Pending CERSAI Updation Accounts Critical
14.38 140 . All accounts with cersai details Critical
14.39 141 . Second Loan And PL Pending For CERSAI Modification Critical
14.40 142 . Rejected Loan accts Pending For SI Creation Critical
14.41 143 . Outstanding Grt than Disb Amt Critical
144 . First EMI Greater than System EMI As On 14-03-15 AFEOD (After
14.42 Critical
EOD)
14.43 145 . March15 sch greater than Feb15 sch as on 21-03-15 AFEOD Critical
14.44 146 . Revised EMI greater than System EMI As On 14-03-15 AFEOD Critical
14.45 147 . PeriodWise Seasoning of Asset Quality Critical
14.46 148 . Productwise Seasoning of Asset Quality Critical
14.47 149 . Customers Having Duplicate Customer-IDS Critical
14.48 150 . Probable SMA Critical
14.49 151 . Perfection Of Security Pending List Critical
14.50 152 . PF Demand Arrears Critical
14.51 153 . Customer Wise Loan Account Details Critical
14.52 155 . Pre EMI Aging Report. Critical
14.53 156 . Loan Acount Details Critical
14.54 157 . Suite File Details Critical
14.55 158 . EMI Payment Mode Critical
14.56 159 . Composite Loan Details Critical
14.57 160 . Manager - MIS I Critical
14.58 161 . Customer Invalid Mobile Number Details Critical
14.59 162 . Composite loans gr 18 months Critical
14.60 163 . QMA Reports and SMA2 Less than 1 Year Critical
14.61 164 . IAMS (Individual Account Monitoring Statement) NPA History Card Critical
14.62 165 . SARFESI Details Critical
14.63 166 . Sanction List of SO with Forwarded Date Report Critical
14.64 167 . NPA Accounts History Card Report Critical
14.65 168 . SMA1 Accounts History Card Report Critical
14.66 169 . SMA2 Accounts History Card Report Critical
14.67 170 . Loan Demand Critical
14.68 171 . Cersai Pending beyond 30 days Critical
14.69 172 . Cibil Rejected Records Details Critical
14.70 178 . Demand Collection Report Critical
14.71 179 . SMA Reminder - I Critical
14.72 180 . SMA Reminder - II Critical
14.73 181 . SMA Reminder - III Critical
14.74 182 . SMA Reminder - VI Critical
14.75 183 . ROI Reduction - Link Letter to Borrower Critical
14.76 184 . ROI REDUCTION DETAILS Critical
14.77 185 . InPrinciple Report Critical
14.78 186. Revised Schedule For Account Critical
14.79 187. NACH Deactivation Report Critical
14.80 188. Pending CERSAI Details Critical
14.81 189. EMI Revision List Critical
14.82 190 CREDIT LINKED SUBSIDY SCHEME PRODUCTS ONLY Critical
14.83 191 Notice of revision in rate of interest on loans Critical
14.84 193 Income Category Details Critical
14.85 194 Excess EMI For Account Critical
14.86 195 Excess EMI Branchwise Critical
14.87 196 CDSC Return Request Pending Critical
14.88 198 SARFAESI Information Critical
14.89 199 197 Branch Rejected Files Critical
14.90 200 Composite loans greater than 15 months Critical
14.91 201 Cersai Pending beyond 7 days Critical
14.92 202 CLSS Details from Branch Critical
203 Loan Agreement Except GRHS (Gruhalakshmi Rural housing Loan)
14.93 Critical
and NLUH (New Loans for Urban Housing)
14.94 204 Loan Agreement for GRHS and NLUH Critical
14.95 206 Loan Sanction Letter Critical
14.96 207 Concise Report One Critical
14.97 208 Concise Report Two Critical
14.98 209 Concise Report Three Critical
14.99 210 Advance EMI for Account Critical
14.100 211 Advance EMI Branchwise Critical
14.101 212 205 Appraisal Reports Critical
14.102 213 CLSS Additional Details Critical
14.103 214 Probable SMA1 Report (SMA 0 if not recovered) Critical
14.104 215 Probable SMA2 Report (SMA 1 if not recovered) Critical
14.105 216 Moratorium Bulk upload Critical
14.106 217 Account Details with Covid 19 Moratorium Critical
14.107 218 SMA Total Delinquent Details Critical
14.108 219 Probable SMA0 Report (If not recovered) Critical
14.109 220 Loan interest posted for the month Critical
14.110 221 LS Want of Particulars Critical
14.111 222 Report for Advocate Empanelment Critical
14.112 223 Report for Advocate Empanelment(Approved and Non Approved Case) Critical
14.113 224 Newly Developed or Well Developed Layout Approved Applications Critical
14.114 225 Newly Developed or Well-Developed Layout Rejected Application Critical
14.115 226 Newly-Developed or Well-Developed Layout Pending-Branch MIS Critical
14.116 227 CDSC Reconciliation Report Critical
14.117 228 Return Instrument Status Critical
14.118 229 In-Principle Sanction MIS Critical
14.119 230 In-Principle Sanction Communication_Restructuring Critical
14.120 231 List of Accounts where Mortgage is not Created Critical
14.121 232 Report On Concession of ROI Critical
14.122 233 CLSS New Report Critical
14.123 234 Probable SMA0 Report New (If not recovered) Critical
15 OFF SITE MONITORING
15.1 901 Loans permitted beyond the delegated authority Critical
15.2 903 Loan Accts. where disbursement completed within a month Critical
15.3 905 Standard asset Accts. where periodical interest not debited Critical
15.4 906 Any manual interest reversals in standard assets Critical
15.5 907 Any Manual Debits in Income heads Critical
15.6 908 Accts having Credit Baln or nil baln or negligible baln Critical
15.7 909 Accts. of Rs.1 lakh and above closed within 6 months Critical
15.8 910 Audit Log Report Critical
15.9 911 LS Debits more than 75 Lakhs Critical
15.10 912 Cash remittance of Rs. 2 Lakhs or more Critical
15.11 913 All Credits Debits in the form of JVRS (Journal Vouchers) Critical
915 Bulk deposits and LOD granted against such deposit on same opening
15.12 Critical
date
15.13 916 Accounts in which Mortage is Pending or not created Critical
15.14 917 List of deposits where Value date is permitted Critical
15.15 918 Any Debits to expenditure heads beyond delegated powers Critical
15.16 919 Spurt in expenditure Critical
15.17 920 Manual Reversal of provisions Critical
15.18 921 Spurt in credit Critical
15.19 922 Particulars of fees paid to DSA and Legal Advisor Critical
15.20 924 TDS Service tax outstanding beyond the due date of remittance Critical
15.21 926 PF Demand Collection and Arrears Critical
15.22 927 Quick Morttality NPA Critical
15.23 928 Cersai Pending beyond 30 days Critical
15.24 929 Credit entries value date Critical
15.25 931 Concessional ROI Critical
15.26 932 Variation in ROI Critical
15.27 933 Income - Expense GL Balances Critical
15.28 934 Transaction vs GL Tally Critical
15.29 935 Sanction TAT Analysis Critical
15.30 936 Perfection Of Security Pending List Critical
15.31 937 Outstanding Grt than Disb Amt Critical
15.32 938 Account List No Credits Critical
15.33 939 PEMI Accounts Total Demand is greater than Current Month Demand Critical
15.34 940 Deposits open without receipt of money Critical
15.35 941 Security Value Lower than Sanction Amount and Outstanding Critical
15.36 942 Accounts with Zero Nill Os Balance Status not Closed Critical
15.37 943 Closed accounts with balances Critical
15.38 944 Outstanding greater than schedule outstanding Critical
15.39 904 Loan Accounts where EMI Begin date not updated Critical
15.40 946 Cersai Pending beyond 7 days Critical
15.41 947 902 Disbursements exceeds sanctioned loan limit Critical
15.42 948 LOD Accounts where loan is not linked to deposit Critical
15.43 949 LOD Accounts where margin is eroded Critical
15.44 950 Composite loans gr 18 months Critical
15.45 951 AS-LS General pending more than 30 days Critical
15.46 952 Report On Cash Balance Critical
15.47 953 Interest Not Debited Critical
15.48 954 Report for Negative LS Excess EMI Critical
15.49 955 Report for Excess EMI Balance Critical
15.50 956 Credit Review Monitoring Remarks Critical
15.51 957 Loan Account Having No ROI Or EMI Critical
15.52 958 Deposit Account Having No ROI Critical
15.53 959 Valuer Details of Sanctioned File Critical
15.54 960 194 A TDS on Deposit Critical
15.55 961 TDS and Others Details Report Critical
15.56 962 GSTLSTDS Critical
15.57 963 Deposit Maturity Details Critical
15.58 964 Loans With Project Details Critical
15.59 965 Loans With Employment Details Critical
15.60 966 Deposit Master Report Critical
15.61 967 Loan Account Having No ROI Or EMI Critical
15.62 968 Panel Valuer Report Critical
15.63 969 Branch Sanction Power Report Critical
16 B & ST REPORTS
16.1 1300 . Service Tax Fee Critical
16.2 1301 . PRCM (Partial Reverse Charge Mechanism) Service Tax Critical
16.3 1302 . FRCM (Full Reverse Charge Mechanism) Service Tax Critical
16.4 1303 . 194 A TDS on Deposit Critical
16.5 1304 . Service Tax Credits Critical
16.6 1305. GST and TDS Master List Critical
16.7 1306 . TDS and Others Details Report Critical
16.8 1307 . GST InWard Supply Report Critical
16.9 1308 . GST OutWard Supply Report Critical
16.10 1309 . GST InWard Supply RCM (Reverse Charge Mechanism) Report Critical
16.11 1309 . GST InWard Supply RCM Report Critical
16.12 1311 . GST OutWard Supply Branch Wise Critical
16.13 1312 . GST OutWard State and Date Wise Critical
16.14 1313 . Report For Fee And Charge Critical
16.15 1314 . Report For OutSideModule Critical
16.16 1315 . Report For ExNRNonGSTInward Critical
16.17 1316 . DSA Commission GST - Headwise Critical
16.18 1317 . GSTLSTDS Critical
16.19 1318 . DSA Commision with GST Critical
16.20 1319 . TDS Form 15G To be Received Critical
16.21 1321 . TDS Form 15G Generation Critical
16.22 1322 . TDS Form 15H Generation Critical
16.23 1323 . Invoice for Inward Supply RCM Critical
16.24 1324 . Outward Supply Invoice Critical
16.25 1325 . General Tax Invoice Critical
16.26 1326. Vendor Transaction during the period Critical
16.27 1327. CustomerWise Deposit Interest Reports Critical
16.28 1328. Report For Fee And Charge(Kerala Cess) Critical
17 Development Reports
17.1 1400 . Closed Deposit Accounts List Critical
17.2 1401 . Fresh Opened Deposit Accounts List Critical
17.3 1402 . Newly Opened Deposit Accounts List Critical
17.4 1403 . Renewed Deposit Accounts List Critical
17.5 1404 . DSA Agent Detail Report Critical
 17.6 1405 . Lead Management Report Critical
17.7 1406 . Lead Status Report Critical
17.8 1407 DSA Agent Detail Report Critical
17.9 1408 Loan Disbursed - Sourced through DSA Critical
17.10 1409 Customer Portal Feedback Critical
17.11 1410 Details Of Unclaimed Deposits Critical
17.12 1411 Register of Deposits Critical
17.13 1412 Deposit Accounts due for transfer to IEPF Critical
17.14 1413 Details of Exempted Deposits Critical
17.15 1414 Deposit Matured 7 Year and Above Critical
17.16 1415 GL Code List Critical
17.17 1416 PRR 1 Business Performance vis a vis Target Critical
17.18 1417 Cash Incentive Score Card Critical
17.19 1418 Pending Transaction For the Day Critical
17.20 1419 RO Periodical Review Critical
17.21 1420 Details of Loan Canvassed By DSA Critical
17.22 1421 Asset Price Monitoring System Critical
17.23 1422 NHB Residex Critical
17.24 1423 Loan Accounts Top 50 and 10 Critical
17.25 1424 Overseeing Executive Review Critical
17.26 1425 SO Sanction Details Critical
17.27 1426 Lead Management Report Critical
17.28 1427 Lead Status Report Critical
17.29 1428 Letter of Pledge for Deposits Critical
17.30 1429 Details Of Unclaimed Deposits Critical
17.31 1430 First Disbursement Details Critical
17.32 1431 Valuer Master Details Critical
17.33 1432 List of Files sanctioned by CPC (Central Processing Center) Critical
17.34 1433 CPC Inwarded Files Status Critical
17.35 1434. CPC Inwarded Files Status Critical
17.36 1435 CPC FILES INWARDED Critical
17.37 1436 RO Periodical Review HL NHL Critical
17.38 1437 Performance Of DSA and MO Critical
17.39 1438 RO Periodical Review - Product Change Critical
17.40 1439 Revised PRR with Product change Critical
17.41 1440 Breakfast MIS Critical
17.42 1441 Daily Yield MIS Critical
17.43 1442 Sanction Appraial Customer Feedback Report Critical
17.44 1443 Disbursement List MIS Critical
17.45 1444 Income Category Wise PRR Report Critical
17.46 1445 Weekly Deposit Details Critical
17.47 1446 Data regarding the takeover of loans by CFHL from other institutions Critical
17.48 1447 Customer Feedback After Disbursement Critical
17.49 1448 Post Month DSA Business Report Critical
17 FAM REPORTS
17.1 1500 . FAM (Fixed Asset Module) Asset Details Critical
17.2 1501 . Depreciation Report Critical
17.3 1502 . Insurance Expiry Report Critical
17.4 1503 . Warranty Expiry Report Critical
17.5 1504 . FAM AccountLink Report Critical
17.6 1505 . AMC Report Critical
 17.7 1506 . FAM Transfer Report Critical
17.8 1507 . FAM Sales Report Critical
17.9 1508 . FAM Purchase Report Critical
17.10 1509 . AMC (Annual Maintenance Contract) Sold Transfer Report Critical
17.11 1510 . AMC Service Report Critical
17.12 1511 . AMC Purchase Transfer report Critical
17.13 1512 . AMC ProductWise Report Critical
17.14 1513 . AMC HardWare Report Critical
17.15 1514 . AMC Expiry Report Critical
17.16 1515 . AMC CompanyWise Expenditure Report Critical
17.17 1516 . AMC CompanyWise Report Critical
17.18 1517 . AMC BranchWise Expenditure Report Critical
17.19 1518 . Deatails of Assets Capitalised Critical
17.20 1519 . Fixed Assets Master Return Critical
17.21 1520 . Details of Asset Purchased Critical
17.22 1521 . Asset Capitalised Between BusnDt Critical
17.23 1522 . Deletion Report Critical
17.24 1523 . Asset Transfered From one Branch to Other Critical
17.25 1524 . Statement Of Fixed Asset Critical
17.26 1525. Vechicle Insurance Details Critical
18 IT REPORTS
18.1 1701 OM (Online Money) Tr Acct Opened Closed Critical
18.2 1702 HL not linked with PL Critical
18.3 1703 Control Report for NPA Reversal Analysis Critical
18.4 1704 LS Bifurcation Details Critical
18.5 1705 Ctrl Report for ROI EMI in LOS vs LMS Critical
18.6 1706 Ctrl Report for LS Charges Critical
18.7 1707 Ctrl Report for NPA Regularization Critical
18.8 1708 Ctrl Report for NPA Reversal Analysis Critical
18.9 1709 Ctrl Report for Deposit OD Movement Critical
18.10 1710 Ctrl Report for Consistency Checks for Loans and Deposits Critical
18.11 1711 Ctrl Report for Consistency Loans for Ex Loans and Deposits Critical
18.12 1712 Ctrl Report for Deposits Critical
18.13 1713 Ctrl Report for Inwarded File Status Critical
18.14 1714 Ctrl Rpeort for Customer wise Loan Acocunt details as on Date Critical
18.15 1715 Net Collection Analysis Report Critical
18.16 1716 Ctrl Report for LS Charges All branch Critical
18.17 1717 List of Files Source by Staff in the Period Critical
18.18 1718 Auit Log IP Details Critical
18.19 1719 Customer Details Critical
18.20 1720 Annual Resetting of ROI Critical
18.21 1721 EOD Completion Status Critical
18.22 1722 Login Password-Audit Log Critical
18.23 1724 Back Up Process Critical
18.24 1725 Synchronisation Activity Log Report Critical
18.25 1726 Masters- User Profile List Critical
18.26 1727 Latest ROI Offer Critical
18.27 1728 Loan Acocunt Having Future EMI Date Critical
18.28 1729 Transaction Log Report Critical
18.29 1730 Report on Transaction Log Critical
18.30 1731 Connectivity Toggle Report Critical
18.31 1732 CERSAI Satisfaction Details (All Branches) Critical
18.32 1733 LSW_Branchwise Critical
18.33 1734 LSW_Userwise Critical
18.34 1735 Control Report for Change of ROI and EMI Critical
 Bidder
Bidder
Clarificat
Response
ions /
(S/A/C/U
Comment
)
s
VM Storage & Platform
Sheet 16: VM Storage & Platform

Id

9
10
11

12

13

14

15

16

17

18
19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39
40
VM Storage & Platform
Sheet 16: VM Storage & Platform

System Requirements

Bidder shall be responsible for setting up, installation, configuration (Operational as well as management as per
the ITSM framework),upgradation, and migration of application service, database service, storage & Network
Service
Maintain and manage the required network components like VNET, Subnets, Load Balancers etc for the cloud
services procured for DC. Along with Setup and configure the VMs, storage, Network, Database etc. at DR. The
bidder is required to adhere to the RPO and RTO (Recovery Time Operations) requirements laid out by CFHL.

Bidder shall not delete any data before without approval of CFHL during the period of Contract and will not
delete any data after the expiry of Contract without written approval from CFHL. By default data is preserved 30-
90 days before data is permanently deleted within which the subscription needs to be renewed.

Bidder shall be responsible for implementation, management and monitoring of DDOS, IPS, IDS Services for the
service provisioned by the bidder on Cloud
Bidder will implement anti-malware and conduct regular vulnerability scanning and penetration testing of
systems and infrastructure. The frequency of vulnerability scanning needs to be decided by CFHL. The bidder
needs to provide their scope of work on this, which needs to be sent to the Bidder.
Bidder shall have public Services and High security services in DMZ zone as per the Deployment Architecture
requirements.
Bidder should configure connectivity so the data from external sources can be saved in Storage services either via
Bastion hosts or through any IAM rule which provides access to Storage service
Bidder is expected to understand the complete as is state of architecture of existing applications and processes
shared by the consultants necessary for smooth migration of applications and databases including
interdependencies between applications and data.
Bidder shall be responsible for deployment of Security patches on the PAAS . IAAS Services consumed by the
Bidder / OEM.
Bidder will be responsible for data migration to target cloud if any and managing the cloud services.
The Bidder shall be responsible to monitor the cloud services and ensure uptime of all services as per SLA agreed
with CFHL
Bidder/Bidder Partner should be able to deploy target state applications on cloud, security administration,
planning and implementation of cloud management and monitoring portals for complete infrastructure and
services procured within the cost for subscription from the Cloud Service Provider
Bidder needs to use IAC pipelines for provisioning of cloud services ( Infra, PAAS, Integration Components etc ).
The Bidder should ensure the version control of IAC scripts is maintained in repositories.
Provisioning of scalable storage capacity as per requirements of CFHL and availability of such services as per
agreement is to be provided by the bidder. The scalability factor & it's subscription should be taken into
consideration in the cost.
Bidder shall ensure committed time taken for restoration of data from Backup as claimed
Bidder shall demonstrate/Submit documentary proof for POC (Proof of Capability) as part of technical
evaluation to understand the key features but not limited to, such as AUTO Scale up/down, Security protocols,
Denial of Service (DoS, DDoS) attack), management and administration and audit capabilities of offerings,
setting up of DR facilities, etc
Bidder is expected to provide inter-operability support with regard to APIs and Data Portability to explain how
different cloud services interoperate with each other
Bidder shall be responsible for any Risk Management and planning, issues related to migration of data from DC
to DR & ensure that the required services are up and running as per RTO and RPO timelines committed
Bidder shall be responsible for managing the PAAS services/ infrastructure used in cloud environment to host
the third party applications
Bidder to take understanding from Consultants on the target Architecture during and after the migration period.
SI will further provide granular level of understanding into the Architecture for additional functionalities.

Bidder shall provide necessary training to CFHL or its Systems Integrator on management of cloud services.

Bidder shall provide necessary technical documentations, Architecture documents, SOPs, High level and
detailed design documentations, Data Models and Data migration specifications , Change and Patch
Management documents as per the technical scope
All risk management related to migration, migration plan shall be jointly worked out with Bidder and Cloud
Service Provider. For the governance part of it , CFHL should be addressed by Bidder.
Bidder should consider the capacity planning, including sizing, current loads, utilization, expected
growth/demand and other details for scale up/scale down at the beginning of the agreed period with CFHL and
must take into consideration that there should not be any deviation from that.
The OEM shall provide Annual Technical Support under Software procured as PaaS/ SaaS during entire period
of Contract.
Bidder shall workout multi-factor authentication for root account as well as any other privileged identity and
access account associated with. CFHL will provide necessary governance for this.
Bidder shall be responsible for the availability of services , the implementation of tools and processes for
monitoring the availability of applications, responding to system troubleshooting.
Bidder to ensure Monitoring of performance, resource utilization and other events such as failure of services,
degradation of services, availability of network, storage, Database systems, OS & raise necessary tickets to the
cloud service provider / OEM with the agreed SLA.
Bidder needs to ensure that the OEMs and Cloud service provider provide the relevant reports, including real
time as well as past data reports through a dashboard.
As part of the DR drill, bidder needs to plan the exercise, communicate , co-ordinate & provide status update to
all the stake holders including consultants, CFHL business, CFHL IT. Bidder will ensure all the issues found
during the DR drill are resolved & ensure success of the DR drill. The DR drill has to be conducted by the Bidder
as per the frequency determined by CFHL / as per the CFHL needs.
There should not be any data loss during backup from DC to DR to be ensured by the Bidder in co-ordination
with the OEMs.
Bidder shall monitor Internet Links, bandwidth, data transfer, response time and packet loss and perform
corrective measures.
Bidder to ensure cloud backup and restore management for backup and restore, including performance of daily,
weekly, monthly, quarterly and annual backup functions (full volume and incremental) for data and software
maintained on the servers and storage systems using Enterprise Backup Solution on Cloud.
Bidder should be able to support following: Windows Server 2016, 2019 and higher and / or Linux distributions -
(RedHat, SUSE, Ubuntu, CentOS) as per the target state application requirement.
Bidder must provide the PAAS service which must allow publishing Web apps running on multiple frameworks
and written in different programming languages.
Bidder must provide the PAAS service which should provide a serverless compute service that enables user to
run event-triggered code without having to provision or manage infrastructure
Bidder must provide the PAAS service which should be distributed systems platform to make it easy to package,
deploy, and manage scalable and reliable microservices and containers
IaaS services should be inline with the requirements shared, growth projected and target state technical cloud
architecture
PaaS services should be inline with the requirements shared, growth projected and target state technical cloud
architecture
The existing applications supported by other vendors like CKYC, RBIA and ADF) to be moved to new tenant and
proper integrations with core applications to be ensured as a part of core application implementation. Bidder to
provide new VM’s and related technologies at DC/DR for these applications and maintain the same.
Index

Bidder
Bidder
Clarification
Technical Specifications Importance Response
s/
(S/A/C/U)
Comments

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Database
Sheet 17: Database

Id
System Requirement
Proposed DB solution should be a relational DB solution. The following
1 requirements are referring to the RDBMS solution. The solution must have
capabilities to support un-structured data as well.
2 Bidder should ensure encryption of data at rest and data in motion.
Bidder should encrypt all the sensitive data in database and
3 supports Data Encryption Standard [DES], 3 DES (Triple Data
Encryption Algorithm) and PKI (Public Key Infrastructure) security
algorithms, AADHAAR vault integration
4 Database should have capability to support many workload types within the
database like (but not limited to) transactions, analytics workloads.
5 The database should support concurrent data loading without compromises for
batch and trickle loading.
6 The Database solution must be compatible with multiple Operating systems such
as Windows, Linux, Unix.
7 Database solutions must communicate with Applications on custom defined DB
interface (TCP/UDP ports).
8 Database solutions must ensure zero downtime & no data loss.
9 Database solutions must support inbuilt replication functionality & should be
capable of asynchronous & synchronous replication.
10 Database should support many data types and data models (but not limited to)
JSON, graph, spatial, text,OLAP, XML.

11 At any point of time, database solution must ensure CIA Triad (Confidentiality,
Integrity and Availability) which helps in avoiding compliance issues, ensures
business continuity, and prevents reputational damage to the organization.
12 Direct access to Database should only be provided to the authorized users &
should maintain the users log required for audit.
13 Bidder must ensure application/middle layer compatibility with database
identified versions & editions for the target environment

14 It is the responsibility of the bidder to change/upgrade/customize its DBMS

solution for ensuring the compliance to regulatory/statutory/supervisory/parent
CFHL's requirements at no extra cost.
15 Bidder to ensure all required database licenses & software support/assurance is
inline with the target state application's requirement.
16 Database solutions must be easy to deploy, operate & scale up/down based on the
target state application's requirement.
17 Database Solutions can be configured for automated backup & DB snapshot as
per the guidelines defined by CFHL.
Bidder to ensure migration capabilities of the database solutions. i.e. Database
must support both homogenous & heterogeneous migration based on the
18 requirement & in that case, bidder needs to do migration at no extra cost.
For the data migration, OEM approved/native DB migration tools must be used

19 Database solution must support seamless integration with multiple cloud service
providers.
20 Bidder should consider licensed version of DataBase over Open-Source for any
application
21 Proposed solution of DB should have the VM based hosting as well as managed
service on single public cloud.
 The DB set up on cloud as part of managed service should be hosted on a single
22 cloud and preferably on the cloud environment on which Application will be
hosted
Bidder should take into consideration on the aspects of ease of migration of data
23 from existing SQL server DB. Tool based migration approach is preferred to
achieve higher accuracy and faster Turn-around-time (TAT)
24 Type of licensing of the DB on target environment must be clearly specified in the
solution.
25 Bidder to ensure the Data Sync-up as per the functional requirement of the
different applications in the target state architecture
26 Suggested DB solution should have the minimum support & maintenance
requirements with respect to operations & functionality.
Bidder to ensure additional storage for database refresh as & when required in
27 PRE-PROD/PROD/DEV/SIT/UAT environment. All database objects must
remain intact during this process.
Index

Bidder Bidder
Response Clarifications /
Technical Specifications Importance (S/A/C/U) Comments

Critical

  Critical

Critical
 
Critical
 
Critical
 
Critical
 
Critical
 
  Critical
Critical
 
Critical

Critical
 
Critical
 
Critical
 

Critical
 
Critical
 
Critical
 
Critical
 

Critical

 
Critical
 
Critical
 
Critical
 
 Critical
 

Critical
 
Critical
 
Critical

Critical

Critical
Virtual NW and Load Balancer
Sheet 18: Virtual NW and Load Balancer

Id System Requirements

1 Routing-Switching

2 Network Connectivity

3 WAN

4 VPN

5 Load Balancer
 Index
ad Balancer

Technical Specifications

·The Bidder shall provide router on cloud which will dynamically exchange the routes between two Virtual Private
Cloud Networks. Router uses dynamic routing protocols to exchange routing information between the networks.

·A Cloud Router also serves as the control plane for Cloud NAT
Solution should provide plug and play installation, but requires an annual license fee for highly automated
operation.

·Cloud-enabled network involve actualizing fault-tolerant protocols and fault-tolerant state storage in the router

·Proposed should be scalable, Available, Reliable as per the CHFL requirement

·Should support IPv4/IPv6 routing (dual stack)

·The solution should provide isolated environment for all the application
·The solution should build traditional site-to-site (S2S) VPNs to securely scale cloud datacenter capacity. S2S VPNs
use IPSEC to provide a secure connection between your corporate VPN gateway
·Solution should support direct and secure communication between services and VMs. Inside VNET, the NATing
should be implemented for granular control
. VNET Peering capabilities should be provided in the target cloud infrastructure between DC and DR.

·Provide real-time KPIs, disaster recovery/business continuity (High availability) services and control of the network
path to support current and anticipated data privacy requirements.

·Clouds and multiclouds require a unified and centrally managed approach to networking in order to meet an
organization’s requirements for performance, latency and cost containment. Enhanced cloud interconnection
services can supplement and eventually replace existing WAN architectures to achieve a truly cloud-optimized
networking stack

·The solution should allows users secure access to a company’s cloud resources, files, data or applications, such as
via a website or an app
·The solution should support remote workers, secure cloud servers, and improve access to the data stored on such
servers.
·Solution should provide direct cloud access, Global accessibility, Flexibility, Scalability.
.VPN solution should be capable of doing the posture assessment on the remote end devices before giving the access
to the cloud infrastructure

·Network and server load balancing should be incorporated with the help of load balancing protocols like Round-
Robin or weighted round robin (but not limited to)
·Solution should support proxy protocol
·Solution must be scalable, high available, reliable and maintain minimum downtime
·Solution should provide SSL offloading and Geo-routing
 Bidder
Bidder Response
Importance Clarifications /
(S/A/C/U)
Comments

Critical

Critical

Critical

Critical

Critical
Infra & Network Security
Sheet 19: Infra & Network Security

Id System Requirement

1 Intrusion Detection and Prevention

2 Identity Access Management

3 Firewall/NGFW

4 Web Application Firewall (WAF)

5 Endpoint Security
6 Alert, Logging & Monitoring

7 Vulnerability Management

8 Proxy Solution

9 Cloud Infrastructure Security

10 Minimum baseline security standards

Id System Requirement
1 Native integration

2 Pre-Integrated protection

3 24x7 traffic monitoring

4 Flexible tuning

5 Multi-Layered protection

6 Extensive mitigation practices

7 Attack analytics & reporting

8 Attack alerting
Index

Technical Specifications Importance

Solution should have Network intrusion detection & Host Based Intrusion Detection. Additionally
below key points (but not limited to) to be taken into account

•Recording information related to observed events. Critical

•Notifying security administrators of important observed events.
•Producing reports related to the identification and blocking of malicious traffic traversing the
IPS & IDS blades

The Solution must provide centralized reporting and audit ability for Single Sign On (SSO)
The Solution must support following features (but not limited to):
Multi-factor Authentication
User Interface must be customizable
Critical
Account Provisioning & De-provisioning
Authentication
Authorization & Role Management
Session Management

Solution should support technologies (but not limited to) such as Intrusion Prevention &
Detection Systems, Application Control, DoS and DDoS protection, Global Threat Intelligence,
Deep Packet Inspection, Stateful packet inspection Critical
If any advisory from the regulators and other bodies are supposed to be detected, reported and
blocked

-The Solution should support “On Demand” Vulnerability Scanning of Applications

-WAF shall ensure automatic protection with minimum manual intervention for initial
configuration, timely policy updates, and others operational activities as required
-The WAF should be capable of decrypting the SSL/TLS traffic to analyze the HTTP data, and re-
encrypt the SSL/TLS traffic. Solution should be capable enough to identify Critical
vulnerabilities/threats/anomalous behavior with the latest and all the supported versions of SSL
& TLS protocols
WAF should be capable of blocking the IOCs identified by the regulators.
NGFW should be capable of blocking the IOCs identified by the regulators

-Solution to provide advanced intrusion detection, full visibility, and prevention solution for
malware, spyware, ransomware, zero-day threats) Response and Data Recovery Capabilities
-Should support Sandboxing Capability(replicate the behavior of real end user systems to run
malicious files without affecting the network, intended to detect malware. To assess malware,
sandboxes enable organizations to run multiple code evaluation processes using different
Critical
technologies and operating systems)
-End-point protection solutions are able to perform AI/ML based malware detection, anomaly
detection, behavior monitoring, or root cause analysis)
-Solution should have a provision for features (but not limited to) application, device, host
firewall control, Host vulnerability management
Solution should have integrated logging services on cloud to store, search, analyze, monitor, and
alert on log data and events. (email, call, SMS)
Solution to automatically collects logs from the services of Cloud to build metrics for monitoring. Critical
Logging solution should be aggregated to a large extent instead of segregated logging solutions.
Bidder to propose a consolidated logging solution.

Bidder is responsible for supply, installation, configuration, integration with existing

technologies, use case creation, maintenance, and providing support services as per SLAs for
Vulnerability Management solution on periodic and the ad-hoc basis as agreed by the CFHL & SI
team.
Critical
The bidder should provide a suitable vulnerability assessment scanner installed on target
environment, and do vulnerability scanning on periodic basis or as and when needed by CFHL.
The proposed solution/procedure should be focused on target environment and there should not
be any dependency on OEM environment.

The Bidder has to supply, install and configure the cloud based web proxy solution provided as
Critical
per the timelines and SLA levels prescribed in the RFP.
The solution shall include Web Proxy with Caching, Web Content Filtering, URL) filtering, Anti
Malware, Anti-Virus, Application layer filtering (Transparent and gateway mode), Application Critical
control features etc
The service should be comprehensive and include Configuration, Operations and Management of
Critical
the solution.

The solution must not be a "single point of failure" in network traffic flow; the failure of one or
Critical
more components of the solution should not affect the organizational network’s functionality

Solution should support policies as per usernames, groups, IP or IP ranges and time bound.
Critical
Solution should have the capabilities of IOC blocking and domain filtering
Solution should provide reports with (but not limited to) HTML/CSV/PDF formats. Solution
should have built in various reports and should be able to create custom reports like Executive
report, Investigative report, Top 10 reports for various category and Health reports etc. Solution Critical
should be able to schedule reports and also provide the flexibility to generate on-demand reports
in daily/weekly/monthly/yearly or specific range (by day and time).
The solution must support granular access control and authorization to facilitate gathering of
logs of user’s access. The solution should create custom reports on a granular and/or enterprise Critical
level.
The solution should have capabilities to automatically deliver reports based on schedule to
selected recipients. The solution should be able integrate with Mailing and Collaboration solution Critical
so that the automated, periodic delivery of the reports can take place.

Solution should be capable to integrate with AD, SIEM, PIM and NTP(public/internal) Server.
The local NTP server should sync with public NTP. All other VMs in cloud should sync with this Critical
local NTP server.

The proposed solution should support to monitor traffic from multiple segments of IT
Critical
Infrastructure landscape (but not limited to) i.e. WAN, DMZ, Server Farm, Wi-Fi network.
Cloud IaaS component level security to be incorporated by the Public cloud service provider
Including the components (but not limited to) VMs, VPN/Internet gateways and all the target Critical
state cloud services which are actively managed by the CSP

Bidder to ensure that the minimum baseline security standards to be maintained on all the Critical
network and other active components in the target state architecture. While achieving this, SI to
ensure that the optimum performance level is maintained for all the active components.
DDOS
 Technical Specifications Importance
Critical
Native integration with public cloud which understands the resources and resource configuration
Simplified configuration immediately protects all resources on a virtual network as soon as DDoS
Critical
Protection Standard is enabled. No intervention or user definition is required
Monitoring of application traffic patterns 24 hours a day, 7 days a week, scanning indicators of
DDoS attacks. DDoS Protection Standard should instantly and automatically mitigate the Critical
detected attacks
Application's traffic should be learnt by Intelligent Traffic Profiling over time and the most
suitable profile for user service to be selected and updated. Profile should be adaptive with the Critical
changing traffic with time.
DDoS Protection Standard should protect both at the network layer and at the application layer
Critical
when deployed with a web application firewall (WAF)
Mitigation of all L3/L4 attack vectors, with global capacity, to ensure protection against the
Critical
largest known DDoS attacks
Detailed incremental reports should be available during an attack, including a complete summary
Critical
after the attack ends.
Capability to configure alerts at the start and stop of an attack, and throughout the attack's
Critical
duration, using built-in attack metrics.
Bidder Response (S/A/C/U) Bidder Clarifications / Comments
NOC
Sheet 20: NOC

Id System Requirement

The Bidder shall provide 24x7x365 remote proactive monitoring service of the
entire branch office, cloud based DC & DR infra, and SD-WAN network from
their own NOC by specialized technical team to ensure that the services are
always operational end-to-end.

Dashboard & Reporting:

The Bidder responsible for providing different operational and business GUI
based dashboards as per CHFL requirements
The dashboard must have a drill-down approach to the
2
branch level, incident ticket updates, and log of times from
when the incident has occurred and what actions are taken
till resolution.
The entire dashboard should be as real-time as possible
with capability for back in time and calendar filters
All SLA reports should be available on the portal which can be downloaded as
3
and when required by the CHFL
The Bidder shall provide availability reports on weekly, monthly basis and
ensures that proactive notification is provided to CHFL as per the CFHL policy
4 in case of any network element (Internet, SD-WAN CPEs, etc.) failure. The
reports should be customizable and should be capable of providing the data for
the intermediate timeframes also.

Managed Services shall include (but not limited to) providing up/ down status
reporting, malfunction alarms/ alerts, fault monitoring, incident management,
5 patch management, performance management, change management (including
device configuration, backups, and log reporting, changing faulty device, etc.),
escalation, and resolution; 24x7x365 network monitoring; and online portal-
based device/ network availability performance reporting.
Bidders to carry out the changes on the infrastructure through proper change
management process only. SI to ensure proper approvals are in place from
CFHL's side and the change management procedure should be documented
 The Solution should offer Single Global View of all the log data received from
devices deployed across sites/geographies. The solution shall have the following
provisions for log storage, Logs should not be tampered/edited in the raw
format and ensure proper timestamping:
6
(a) Raw Logs: On Log Collectors (for 72 hours) and Archival Servers (for the
entire duration of the contract)
(b) Normalized Logs: On Log Manager (online for 6 months at any given point
of time)
Archival logs should be encrypted to ensure the data integrity
A Log Management Solution (LMS) is a Software system that aggregates and
stores log files from multiple network endpoints and systems into a single
7 location. LMS applications are used to centralize all of the log data from
disparate systems into a single place where they can be viewed and correlated by
an IT security analyst
The Solution must supply API and graphical tools for creating new connectors
8 or similar parsing solution. The Solution should provide ease of use of regular
expression based ability to create custom parsers.
The Solution must support the ability to integrate with cloud intelligence system
9 with information from global risks, advisories on-boarded by CFHL on time-to-
time basis and use the information collected in this system in the correlation of
events.

The Solution should support integration with RADIUS, TACACS+, Active

10
Directory, and other similar external servers for performing AAA functionalities
(Authentication of users/admins)
The Solution should be able to collect data from new devices added into the
11 environment, without any disruption to the ongoing data collection and without
any additional cost to CFHL
The Solution's log receiver/collector component should be able to work in high
12
availability (HA) mode dedicated to CFHL
The proposed Solution should have the facility for retrieval of logs in a fast
13 manner without impacting (like device hang, high CPU and Memory utilization,
console access termination, etc.).

Bidder should ensure before any application/infra is moved to production, All

14 Indicators of Compromise(IOCs)/Alerts/Knowledge Base(KBs)/Guidelines
received  from RBI/CSITE/NCIIPC/Parent Bank/NHB are to be implemented.
New IOCs/KBs/guidelines released from time to time should be
implemented/configured without loss of time and disruption of services.

Bidder should ensure that the proposed NOC must be physically secured and
must have separate entry and exit gates for NOC personnel with multi-factor
15 access control with one factor should be a biometric feature (preferably face
recognition). Physical access to the NOC premises at bidder's location should be
under continuous surveillance via CCTV. Similar access control to be provided
for network/server rooms wherever required.

Configuration Management:
16 Ensure the proper configuration of network devices, systems and applications
for the provision of reliable and high quality end-user services. Hardening of the
infra devices, scheduled backup for the Infrastructure components should be
integrated in the NOC solutions per the ITSM framework
 Change Management, Network Extension:
17 Ensure efficient day-to-day management of short-term network changes and
optimization, including their implementation. This activity shall be
synchronized with the maintenance scheduled activities
Performance Management:
18 Provide efficient performance management procedures ensuring a reliable,
high-quality network performance and service
Service and Network Provisioning:
19 Define all necessary actions to be performed when a request for a new
node/branch is implemented. SI to control the actions performed at NOC level
or field level until completion.
Scheduled Activities Planning:
Provide regular plans for all scheduled activities, including preventive
20 maintenance in respect of a schedule, and achievement of the plan. This is
linked to the change management function which ensures overall
synchronization of all network activities
IT and DB Management:
21 Activities including (but not limited to) Day-to-day management of all OSS
systems, IT systems and databases (administration, backups)

Security Management:
Define and implement security policies, guidelines, and best practices, and
22 check for compliance with security regulations. Minimum Security Baselines
(MSB) roadmap to be developed, discussed with CFHL IT team. Post approval
from the CFHL, the documentation to be submitted to CFHL without any
additional cost
Quality Management:
23 Define quality management policies, and ensure implementation and usage for
competitive quality of service
Workforce Management:
24 Manage field personnel to ensure timely interventions and respect of the
preventive maintenance plan
The Bidder shall provide the adequate manpower at NOC throughout the
25
contract period
The network visualization and analytics should be able to identify network
26
optimization issues and improve application performance
Bidder should ensure that NOC telephony systems should support Inbound
27
/outbound domestic voice calls through a toll-free number at no extra cost.
The solution should be comprised of one unified platform for all IT
28
infrastructure components
Solution to provide complete end to end health checkup for links and devices
29
under monitoring
30 Incidents to be managed by the ticketing tool provided by the SI
NOC solution will be managed by the NOC to encompass all the monitoring
31 aspects of the IT infrastructure. The tools, licenses required to managed the
same will be managed by the SI/managed service provide (MSP)
Application, Network and Infrastructure monitoring
Supply, installation, integration, testing, management, maintenance and
1 monitoring through cloud based APM Solution along with Software, operating
system and other peripherals of the application/s
2
The proposed solution to ensure near zero downtime and near zero data loss.
 Monitoring to meet the basic functional dimensions of Digital Experience
3 Monitoring (DEM) (but not limited to); Application Discovery, Tracing and
Diagnostics (ADTD); and Application Analytics (AA).
Application of data-driven analytics and ML technology to enhance the
4
effectiveness of monitoring.

5 Network performance monitoring and diagnostics (NPMD): Managing network

quality and optimizing the performance and availability of networks.
The solution must be capable to collect Application-wise system and application
6 logs and centralize the storage of log data for analysis and transformation.
Collected logs should be stored encrypted and should reside in the Indian
territory only.
7 Ability to monitor overall application health dashboards.
Provide Real-time Technical Dashboards for all configured technical
8
transactions amongst the application tier
Prevent alert fatigue by triaging alerting rules continuously. Use a combination
of notification rules, process changes, dashboards and machine learning (ML)-
based platforms.
For Example:
1. Assembling data for post mortem
9 2. Ensure alerts are entered into an alert databases learning and the
identification of trends can happen over long-term.
3. Creating alerts for improvements such as thresholds, whether runbooks need
to be updated, or whether the updates were directed to the right people and
teams

Solution must be able to monitor Usage and performance of all application

10 dependencies like (but not limited to) databases, middleware, web services,
caching
Solution should include Application framework metrices like (but not limited
11 to) average response time, error rate, count of application instances,
inbound/outbound traffic
The APM solution should scale up the monitoring capabilities in terms of
12
Integration with various applications & services during the contract period.
Configure Admin Module of the APM solution to integrate various applications
13
to the centralized deployment.
14
Apply patches for the solution and keep all the solution environments up to date
Configure user management module to handle user creation / modification /
15
configuration
SI to access user interface, Report(s) & Dashboard(s) for generating Application
16 health alerts, online real-time User Dashboard. SI to provide the support for
configuring the rules for monitoring & reporting
Provide online query facility for users: application-wise, department-wise as
17
well as exporting the report for the same
Solution should be capable of seamless DC-DR replication of the applications in
18
real time

The proposed solution should be architected such that maximum resource

utilization of the monitored host, at any time during the day, (by the monitoring
19 solution, in terms of compute) should not exceed the preset resource utilization
threshold. However, in such a scenario, the solution must generate an alert and
provide a RESOURCE UTILISATION MATRIX - Host-wise for all the
monitored systems.
 Solution must generate the RESOURCE UTILISATION MATRIX at any given-
20
point-in-time.
Solution must generate the reports for the parameters (but not limited to)
UPTIME, LATENCY and other performance benchmarking parameters (of the
21 monitoring solution / other applications) through the solution and to be
submitted to the CFHL on Quarterly/Monthly/Weekly basis or as per the agreed
frequency with CFHL
The solution must be able to generate and send automated triggers via SMS,
22
Email and System alerts (system health)
The solution must integrate with various systems / applications in the CFHL
23 including (but not limited to) SOC, NOC, SD-WAN, SIEM, AD, ITSM at no extra
cost.
The Product should be compliant with guidelines issued by applicable
24 regulatory authorities such as RBI, NHB. Also the solution should be compliant
with respect to the Cyber Security requirements
Solution should have Automated capability to monitor End-to-End Transaction
25 in synthetic monitoring along with OTP and SMS Delivery. This should also
include the Journey involving 3rd party integrations.

If the CFHL desires to have, in case of mobile applications, solution should have
26 a capability to provide Automated monitoring of applications on real devices
(Android and IOS) along with Real Sim-cards and 2G/3G/4G/5G Networks.
The mobile monitoring needs to happen from SI’s NOC. The SI needs to
ensure zero nuisance alarm rate for real time device monitoring

Solution must be capable of Synthetic Monitoring which is to be managed

24x7x365 along with the support. L1 support needs to verify all alerts for
authenticity before escalating to the CFHL’s team.
Synthetic monitoring include the features like (but not limited to):
27
1. Get the context of failures by connecting the availability and performance of
endpoints to the underlying applications and infrastructure.
2. Easily diagnose if an issue stems from the network or cloud location, a slow
third party resource, or the health of backend services or infrastructure.
3. Add synthetic monitoring into build automation and CI/CD pipelines to
automatically track performance and check functionality for each deployment.
4. Expand monitoring further with real, Selenium-powered scripted browsers,
which test login procedures, searches, and other critical business transactions.
5. Monitor API endpoints with API tests.
The SI must ensure the closure of all the security review observations, if any, as
28 pointed-out / advised by the information security team of the CFHL/GISC, with
in the timelines advised by the CFHL/GISC
Service Provider shall identify and document the risk in delivering the Services.
29 Service Provider shall identify the methodology to monitor, report, mitigate and
prevent the risk and shall also document the steps taken to manage the impact
of the risks.
 The Service Provider must provide all the project relevant/related documents to
the CFHL. The Documentation includes, but not limited to, user manuals,
installation manuals, operation manuals, design documents, process
documents, technical manuals, functional specifications, software requirement
30
specifications, on-line tutorials/ Cognitive behavioral Training (CBTs), system
configuration documents, system/database administrative documents,
debugging/diagnostics documents, test procedures, Review Records/ Test Bug
Reports/ Root Cause Analysis Report, list of all Product components, list of all
dependent/external modules.

The SI to provide APM integration experts to setup Application Monitoring and

End User Experience Monitoring and to develop dashboards per application to
31 address both business and technical use cases as per the requirements.
Implementation to ensure proper integration with the Triage call used by the IT
operations and Development teams to perform root cause analysis, proactively
monitor and resolve issues in Production IT Environment (SI as well as OEM
resource) during all the integration activities.
SI to develop customized Report(s) / Dashboard(s) to meet day to day
32 operations as well as monitoring and regulatory requirements during the entire
contract period.
Solution should monitor various operating system parameters but not limited to
33 processors, memory, file-system where applicable using agent/agentless on the
servers to be monitored
The proposed solution must have role based access control (RBAC)to define
34 privileges for the users to raise a request to add, modify and delete node/devices
in their web dashboard/console and the request should be effected only after
the approval of the super administrator.
The proposed solution must have capability to automate all report generation &
35
distribution through mails.
The proposed solution must have the capability of looking into the details of
36 individual user sessions to understand the activities and identify difficulties
such as slow performance, errors or application crashes.
The proposed solution must have capabilities to capture and monitor details
37
about how fast web pages and its components were rendered.
The proposed solution must have capability to capture storage response time,
38 IOPS, CPU utilization, free capacity in order to capture entire user journey of a
monitored user session. The integration capability can be through SNMP, SSH,
HTTPs
The proposed solution should be able to score the events and display the highest
39 impacting events in descending order or any other order as per the criticality set
by CFHL
The proposed solution must have capability to perform end to end application
performance monitoring which will include monitoring of underlying OS, web
40 servers, application server, databases, application code execution. The solution
must provide in-dept analysis of application performance problem and
determine the root cause of the problem.
The proposed solution must have capability to store and maintain historic
41 data(as per RBI Data Retention Policy) and also able to generate analytic report
based on the user requirement.
The proposed solution must have capability to support monitoring of micro
42
service and API based applications
 The solution should have the capabilities to integrate with AD, LDAP solution
43
along with the MFA for added security controls.
The Solution should be capable of integrating with the cloud based monitoring,
44
reporting and logging solutions
Index

Technical Specifications Importance

The bidder shall ensure adherence to the following prerequisites:

All the devices that are installed by the bidder shall be Simple Network Management
Protocol (‘Secured SNMP version’) enabled and the bidder shall centrally and remotely
monitor and manage the devices on a 24x7x365 basis.
Bidder to establish and implement leading practices of IT service Management like
Information Technology Infrastructure Library (ITIL), International Organization for
Standardization (ISO)/IEC 20000 standard that shall promote the adoption of an Critical
integrated approach to effectively deliver managed services to meet the requirements
of CFHL.

Critical

Critical

Critical

Critical

SI shall undertake scheduled and ad hoc maintenance (on need basis) and operations
like configuration backup, patch management and upgrades
 Critical

SI shall establish basic tools for IT management to undertake health check monitoring,
troubleshooting etc. for all Network operations
1.Log Collection
2.Secure Log Storage
3.Log Normalization Critical
4.Log Analysis
5.Report and Alert Generation

Critical

Critical

Critical

Critical

Critical

Critical

Critical

SI shall establish access control mechanism and shift wise attendance management
system

Critical
 Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

n, Network and Infrastructure monitoring

  Critical

  Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
 Bidder
Bidder Clarifications /
Response
Comments
(S/A/C/U)
Mailing & Collaboration
Sheet 21: Mailing & Collaboration

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement

1 The proposed cloud base productivity suite must be IPv4/ IPv6 compliant with dual
stack compatibility.
Solution must have risk management feature in terms of vulnerability management, threat
2 intelligence capability, licensing. Solution should have inbuilt Anti-spam/Malware/Antivirus
and any other such type of threats control
Solution must have capability to integrate with Azure AD in the target state architecture
3

An email solution to be accessible over multiple devices on two factor authentication & device
code authentication. All the devices should be in Sync. Solution should have following features:
 Meeting/Calendar/Task list
4  Email clients should be accessible over web browsers as well as applications, mobile devices
 Email archival and advanced security solutions

Solution should compatible and be capable for integrating, with the CFHL's future state
5 solutions/applications Active Directory/AD federation Services which should be done by the
bidder
Solution must be having email communication broadcasting feature (One to Many, Many to
6
many)

7 For a Saas product/solution the SLA of the services should be maintained by the OEM as per the
contract and the same to be ensured by the SI
Records and email archival as per the CFHL's Data & Email retention policy of mail and data
8 including attachments must be available in the proposed solution with the facility of archival /
retrieval at any time as requested by the CFHL, during the contract period.
Solution should have the capability of sending to Bulk mails with multiple
9
attachment/promotional emails to users, customers and potential customers
10 Solution should be able to support multiple domains on single application
Solution should have capability to Create Mailing Lists, automated emails, access Control Level
11
etc. and should have the ability to control Attachment size, type and extension.
The proposed mail solution should provide the administrators web-based user management
12 facility
Solution should have capability for Mail Queue management/Priority Management and should
13
handle SMTP Secured connection
Solution should provide access from Mobile devices/Mobile Apps with real time syncing of
14 mails between all the access points and should support third party email clients & must be
compatible with MDM solution.
15 Solution should have HDD encryption
16 Solution should provide functionality for Self-password reset/Password Management with
support to multi factor authentication
Solution should have capability to provide Alerts and monitoring interface and solution support
17
Remote Administration for administrators
Solution should have Data Loss Prevention (DLP) capabilities: Keeping organization safe from
users mistakenly sending sensitive information to unauthorized people. Following actions (but
not limited to)
a) Block sensitive content mail from being sent based on policies
18 b) Rights-protect sensitive mails at server before sending to recipients based on admin policies
c) Provide Policy Tips to users to inform policy violations before sensitive data is sent
d) Email call-back features (including attachment) should be there

Solution should have Capability to integrate with the authentication servers (LDAP/ADFS etc.)
19
and Integration with applications using API
Solution should have Capability to send and receive authenticated and encrypted emails and
archived mail backup and restoration at user level. OEM has to ensure the backup is taken for
20 the mailboxes at a user level. SI has to ensure the backup relevancy for the mailboxes and
should raise a concern with OEM in case of a discrepancy

The proposed Mail Messaging OEM application should be an enterprise class, commercially
21 available solution and should have a version history and published future roadmap for the
contract period
Solution should have Support to mark/filter Spam/Junk mail management to Administrators
22
and end users
Solution should allow end-user to remotely wipe data from mobile devices with Administrator
23
intervention/permission

24 Solution should have Ability to open/edit/download documents/spread sheets/presentations on

mobile devices (iOS, Android, Windows etc.) as attachments in email
Solution should have Rich features e.g. mail search, calendar and Task Management,
25 Reminders, meetings setup along with desktop sharing capabilities from all types of clients-
thick/fat, thin browser clients
The proposed messaging solution on cloud should provide high availability. The email quota
26 should be 100GB/user and the retention period should be minimum of 10 years. Email and the
file storage capabilities should be flexible
The proposed messaging solution on cloud should support recalling, resending and delivery
27 notification of messages sent and also should notify the user on the success or failure of the
message recall. This facility should be available to users and administrators

28 The proposed messaging solution on cloud should support standard protocols like
POP3/IMAP/HTTP and SMTP /MIME over normal and secure channels. The email solution
should support Mail clients having the following features viz. POP3, IMAP, LDAP, SMTP
 Solution should factor in Multi-factor authentication and should be capable of administration
through a single window interface to provide solution level control and configuration of the
messaging system for all features including, (but not limited to):
 Create / rename / delete mail accounts
 Reset / set user passwords for both Directory & Messaging platform
 List all users in the messaging system
29  Search for a user and modification of user object attributes
 Enable / disable user accounts
 Change delegated administration passwords
 Add alias e-mail address for a user
 Create transport rule as per requirement.
 Ability to see and export all type of logs like mail tracking logs, audit logs etc
Configuration of filter rules on user account basis
Retrieval of the email logs based on the requirement through authorized admin
The Bidder
solutionwill implement MS
to incorporate Teams
DKIM, SPF,forDMARC
all usersfeatures
or as decided by CFHL. List of such
30
users will be provided during implementation

31 Files uploaded to OneDrive for Business, must reside in Data Centers within the boundaries of
India.
No network/replication of data is permitted to Data Centers outside the boundaries of India.
CFHL also reserves the right to subscribe to additional licenses under various profiles at the
32
rates being contracted and also surrender a license as per Enterprise Agreement
Any reduction in the license cost during the contract period should be passed on to CFHL
upfront
33 The Solution must provide for configurations/filters along with standard MIS Reports
Performance Requirements: Solution should provide an uptime of 99.99% and in case of
34
failures, penalty shall be levied on the successful bidder as per SLA
The proposed solution should support MS Outlook 2013 & office suite applications or above as
35
the e-mail client for end user without loss of any functionality
36 The proposed mail solution should provide Front-end user management to Administrators
Service provider will enable and configure DLP as per requirement of the CFHL.
37
DLP will be enabled on eligible mailboxes as per license activated on a particular mailbox
38 Ability to use a PC, Mobile/Tablets, laptop etc. for a complete user experience outside the office
Scalability Requirements: The solution should provide high scalability and there should be no
39
capacity/ performance issues due no of users
MIS Report generation Requirements: The bidder will provide/enable a centralized portal for
40 administrator, which should be capable of generating standard MIS reports to view usage of
Mailing and Collaboration solution services, service health, status of users, incidents, utilization
and usage etc with filtration capabilities.
Solution should be able to support SSO integration with Cloud Identity to prevents users to log
41 in separately into different applications eliminating user-managed passwords . Along with this it
should also support multi factor authentication & Group Policy Objects (GPOs)

Audit Trail & Logging Requirement:

The solution should maintain and manage the logs for all the necessary services under this
42 solution. The solution should have capabilities to integrate with the CFHLs existing and future
state systems/ application (For e.g. in case an application from CFHL wants to send alerts/
automated mails and SMSs etc.) should be able to integrate with the email system in the
proposed solution.
Audit logs reporting & analysis tool:
43 Log monitoring capabilities to be provided to the CFHL and in case of incidents, security
breaches, CFHL has to be notified in real time. Tools and capabilities to analyze the usage of the
licenses/ application/ functionality to be provided.
44 In case the existing data is not compatible with the new solution offered, service provider has to
convert the data so as to migrate in new solution offered to the CFHL at no additional cost.
Mailing and Collaboration solution suite includes Exchange Online, which is a hosted messaging
application that provides organizations with access to the full-featured version of Exchange
Server. It includes access to email, calendars, contacts and tasks for any endpoint device.
Automatic patching eliminates the time and effort of maintaining your system. Give your users
45 an In-Place Archive, so they can keep all their important data in one place. And provide them
with anywhere access to email, calendar, and contacts on all major browsers and across devices.
Integration with Outlook means they’ll enjoy a rich, familiar email experience with offline access

Regulatory / Compliance Requirements

The solution should comply with all the Regulatory/ Compliance guideline of the CFHLs,
Regulatory authority in India, NHB, RBI etc. CFHL has right to change the compliance/
1 guideline at any point of time and the service provider has to comply with the guidelines. CFHL
has right to audit by regulatory authority or any agency appointed by the CFHL, the data
centers/ premises wherein the solution is hosted or CFHLs data is kept.
SI need to address and comply with such audit observations on priority.
Phishing simulation activity need to be carried out on a periodic and 'as and when' required
2 basis. Customization and simulation of phishing activity should be carried out by the SI as
required by the CFHL environment
The solution should comply with CFHL IT policies. Advertising products shall not be built out of
3 CFHL’s data or scan email or documents. Usage of Mailing and Collaboration solution by CFHL,
doesn't provide the rights to the OEM for endorsement

To comply with Recovery Time Objective (RTO)/ Recovery Point Objective (RPO)/ SLA
4 requirement and retention policy as agreed and defined by CFHL's. If required by regulators/
court/ police/ any investigation, Mailing and Collaboration solution OEM should maintain the
email data on permanent basis during period of contract

CFHL shall be the owner of its data, and shall retain all rights, title and interest in the data
stored with Office 365. It reserves its right and should be able to download a full copy of its data
at any time and for any reason, SI need to facilitate the same. Upon Office 365 subscription
5 expiration or termination, CFHL should be provided with 90 days period to access to export
data.
Migration of the data and email solution to new platform from the existing OEM should be
supported by SI at no extra cost to CFHL
Right to Audit: SI to facilitate the platform that will provide rights to audit including rights of
6 access to the CSP's premises where relevant records and CFHL’s data is being held. Audit rights
for the CFHL or its appointed auditor (nominee) or regulators should be ensured
APIs and Data Integration: For integration with external applications, The Solution needs to
7 have well defined APIs and that only authorized applications can invoke such APIs. Such APIs
should be in compliance with the regulatory/advisory guidelines.

There are various laws like Information Technology Act, Data Privacy Act, Data
Retention Directive, Data leakage act, E-Privacy Directive, E- Commerce Directive, The
Computer Fraud and Abuse Act 1984, Digital Millennium Copyright Act 1988 will be
8 applicable to Cloud service providers and also the customers of the Cloud service. It will be
mandatory to protect the data privacy as per Indian Data Privacy Law. Bidder should comply
with all such laws in existence currently or introduced in future by the Govt. agencies or any
other regulatory body. Compliance report need to be share with CFHL on periodic basis or as
required by the CFHL management
Management, Monitoring and Reporting
The bidder should provide on-premise qualified professional at CFHL registered office
1
during implementation, migration & support of proposed solution to users 24x7x365.
 The on-premise dedicated support engineer/s should remain available during the contract
2
period
Events that prevent CFHL from accessing or using office 365 services or data, severely
3 impact deadlines or profitability, or affect multiple users or services, should be available
24x7x365 and response time should be 60 minutes
SLA should be maintained by SI as per the contract including resource availability issues
4
reported by the user/s
The bidder should ensure that the SaaS solution has the capability to integrate future state
Enterprise Ticketing Tool portal for raising user queries/ tickets and real time updates at no
5 additional cost to CFHL. However, CFHL at its own discretion may use future state Enterprise
Ticketing Tool software and bidder may be required to do requisite integration at no additional
cost to CFHL

The bidder should facilitate generation of SLA and MIS reports periodically e.g. volume of call
6 per day, resolution percentage, categories of the issues etc. for which calls/ mails/tickets are
received
Bidder shall ensure that the provided solution should facilitate the platform to provide a Service
7
Health Dashboard
VAPT activities on the proposed solution are performed by the SI on quarterly basis or as and
8
when required by CFHL
Activities like (but not limited to) User ID creation, deletion, modification, mail configuration,
9 add/ remove group membership, mail routing & mail delivery permission, mail tracking,
recovery of deleted mailbox etc shall be in the scope of support for SI
The bidder to have Back to back support arrangement with the OEM and it would be the
10
responsibility of the SI to co-ordinate with OEM for early resolution of issues
Documentation

1. As part of deliverables, successful bidder shall prepare following documents, (but not limited
to):
1 (a) Project Documentation – Solution Architecture, Deployment architecture, Implementation
& Roll-out plan, Test strategy, Data Migration Plan and Integration architecture.
(b) SOP Document for remote users for operating all the solution components.
(c) User Training material ( including the features and functionalities of the products)
DLP
Proposed Data Loss Prevention Solution shall be able to have controls that encompass the
entire Corporate Network of CFHL. It shall cover Target environment, Network devices, Emails,
Collaboration platforms, storages, BYODs and endpoints as well. The solution shall be able to
1 start at the very basic level and progress to subsequent advanced levels of usage as and when
required. The solution shall be device agnostic. The bidder shall involve its best resources for
development of policies that takes risk based approach.

The proposed DLP solution shall consist of following broad functionalities (but not limited to):
a) Discover Sensitive data b) Monitor user actions to understand the risk involved c) Educate
2 the users and the management so as to reduce the risk. d) Enforce security controls

Data protection should be able to identify known and unknown plug and play devices being
3 connected to critical data resources. Also, the solution shall seamlessly integrate with
Encryption which shall be intelligent enough to enforce Encryption of sensitive data.
 The Bidder is expected to provide Data Leakage Prevention solution, covering (but not limited
to):
a) End points & Servers
b) Email
c) HTTP/S and FTP, Shared storages
4
d) Integration with SIEM
e) Analytics
f) Perform Data discovery
g) Scanned Documents

The proposed DLP solution shall have the minimum following features (but not limited
to):
-Identify data leakage across all vectors, irrespective of
policy being in place or not
5
-Protect data
-Have flexible control over Remediation of Data Leakage
-Ease of Use and Quick to Deploy

The Bidder is required to monitor all relevant data leaving the client Network and be
6
able to create policy for protection and implement the same
The Bidder is required to locate all of the Sensitive data and classify it according to set
process. The CFHL or its appointed consultant will classify the data based on
7 criticality. The bidder shall also ensure that any new data format or data types flowing
over network is detected and is included in the rule set within 24 hours of detection of
data

The Bidder is required to put in place prevention or protection rules for that data
8
(structured as well as unstructured) deemed necessary
The Bidder is required to create policy and the data control measures for identifying
9
any change in the critical files identified by the CFHL
The DLP solution should have the capabilities to identify encrypted and encoded data.
10

The Bidder shall configure integrity monitoring for the files and ensure write
11
protection wherever necessary
There shall be adequate audit trail capability to identify drift in the document and all
12
the relevant details like who made what changes and change details
13 Audit trail shall allow for Reporting and Search capabilities
The Bidder shall involve their resources in Data Collection, Policy/Rule Creation/Fine-
14 Tuning, Policy/Rule Enforcement and Incident Management Support

The Bidder shall abide by the Incident/Alert Closure timeline defined by the CFHL
15 according to alert/incident severity and co-ordinate with Data/Policy Owners to ensure
closure of incidents within the stipulated timeline.
Bidder shall conduct awareness programs among end users as and when CFHL
16
requires
The bidder is expected to enable the DLP platform across the proposed architecture
17

18 The bidder should ensure that the advisories coming from regulatory bodies on time-to-time
basis should be addressed in the proposed solution
19 The bidder should participate in all the audits and represent the outcomes of the solution in the
audits
 Antivirus
The support for maintenance of Antivirus solution in the target environment including
1
endpoints should be done by the Bidder
The bidder shall be responsible for the maintenance & support Antivirus application in CFHL
2
offices across the country
3 Antivirus solution should cover all the endpoints, servers, and all the applicable devices.
Solution should encompass the resources in the target cloud architecture with antivirus and
4
DMS solution only
The bidder should generate daily/weekly/monthly reports as required by CFHL. The bidder
should distribute Antivirus patches/updates/signatures on Daily basis to all end points. Incase,
5 Offline installation is required, the OEM has to provide the support at no additional cost and SI
to ensure the same.
The bidder shall ensure the AV client installation on all end-points (servers, desktops, Laptops,
6
and Mobile devices owned by CFHL) at all locations
The bidder shall work with all stakeholders to ensure AV is installed in all end points across the
7 country and the patches are applied on a daily basis throughout the contract period

8 SI to ensure OEM support for all the devices during the contract period
9 Antivirus OEM should have the hub location within the Indian territory
Antivirus solution should have the capability to schedule auto-scan feature as per the
agreed schedule with CFHL. The process should take place without intervention of the
10
end user

AV solution should have the posture assessment feature (parameters like latest
Antivirus signatures, Group policy settings, Latest OS patches) and device health check
11 feature. Also it should have the ability to isolate the infected system. Solution should
also guide the procedure to mitigate the posture failures
SI to ensure the dedicated resources to be allocated for the CFHL account at no
12
additional cost to CFHL
AV solution should be capable to block the Indicator of Compromises (IoCs) shared by
13
the advisory/regulators on a time-to-time basis

14 The bidder should ensure that the advisories coming from regulatory bodies on time-to-time
basis should be addressed in the proposed solution
15 The bidder should participate in all the audits and represent the outcomes of the solution in the
audits

16 AV logs, processing and meta data should reside within Indian geographies and should be
stored in the data centers withing India only
Desktop Management Systems
Periodic review from SI on the implementation and progress of the solution with proper
1 certification of compliance and best practices of the solution provided from the OEM after due
analysis in consultation with CFHL
Offline implementation of patches and updates , if the same is not possible on the online mode
2 using existing bandwidth. DMS solution provide resources for offline patching and SI to
monitor the progress for the same

At all points of time the bidder should integrate, coordinate and support with all our existing
3
System Integrators (SI) involved in various projects of CFHL for smooth functioning

4 Renewal of all the licenses to be managed by SI Team. SI to provide a tracker for the same.
 SI to keep track of AMC contract renewal with the OEMs (back to back) for the hardware
5
components as and when due for renewal.
Bidder to initiate OEM support (under the back to back arrangement) when necessitated by Can
6
Fin Homes as per the complexity/criticality of the problem.
The bidder has to download all the latest patches/updates/signatures from the OEM to DC/DR
7 servers within the timeline to comply with the regulatory requirement or as per the mandate
from CFHL
The bidder should monitor the updates and upgrades and should extend the support for
8
troubleshooting
Solution to include patch management and SI shall undertake scheduled and ad hoc
9 maintenance (on need basis) and operations like configuration backup, patch management and
feature upgrades related to endpoints as per the ITSM framework
Solution should provide quick and easy remote access to end user machines located in different
10
remote locations of the CFHL connected through different types of connectivity
Solution should be able to support SSO integration with Cloud Identity to prevents users to log
11 in into separate instances of the same application. Along with this it should also support multi
factor authentication & Group Policy Objects (GPOs).
The solution must support web filtering of roaming endpoints / users which are not connected
12
to corporate network
SI Team has to generate compliance report for endpoint security, patch upgradation & OS
13
upgradations weekly/monthly or ad-hoc basis as mandated by CFHL
SI should define the group policies in line with the industry best practices for group policies to
14
comply with CFHL's IT policy requirement
DMS Solution should be public cloud based SaaS solution. OEM should provide timely updates
15
which will be ensured by the SI/bidder
The bidder should ensure that the advisories coming from regulatory bodies on time-to-time
16
basis should be addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the
17
audits
DMS solution should provide MIS report (Daily/ Weekly/Monthly or as an when required by
18 CFHL) to provide the overview regarding the patching, OS upgradation status, AV Upgradation
status
The solution must have a close integration with the Active Directory, OS update & patching,
Antivirus solution and SCCM tool. The DMS solution should provide the administrative control
19 over the end-points (Activities not limited to Managing the Desktop screen, Auto-update details,
enabling or disabling the USB ports)
Encryption for Data at Rest
The Bidder is required to implement Encryption on the all the devices identified by the CFHL in
1
the target state architecture
Bidder will be responsible for implementing & managing the policies defined by CFHL for
2
encryption
The solution shall provide option for encryption of attached external storages (managed by
3
CFHL or its affiliates only)or simply disconnect
Bidder will give a brief introduction & mitigation steps to users using encryption. This will also
4 cover but not be limited to various scenarios in case of lost password or theft of devices

5 Bidder will ensure a central helpdesk resource to cater to user issues on ongoing basis
Bidder will maintain the record of encrypted/non-encrypted endpoints and ensure compliance
6
Bidder shall deploy their resources to handle Disk Encryption/Decryption Tasks and further
7
technical/operational support
 The bidder should ensure that the advisories coming from regulatory bodies on time-to-time
8
basis should be addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the
9
audits

Active Directory

1 AD solution should be a cloud native solution and must have capability to integrate with all the
components of the CFHL's IT infrastructure landscape

2 Bidder is required to design, size, supply, implement Active directory service at CFHL's cloud
DC and DR with DNS services along with Active Directory Management solution for AD users.
AD Service must be capable of preparing multiple of Organizational Unit (OU) as per CFHL's
3
need and must integrate with all solution channels LDAP

Bidder is required to perform group policy management, ensure users can access only the
4 resources they are privileged, in order to provide a secure infrastructure, automate, track, alert
on changes, automate AD data backup and recovery to mitigate downtime in the event of an
outage.
Bidder is required to perform AD Implementation, Integrating User(s) profiles and policies in
5
the Active Directory Solution.

6 Management of Active Directory for CFHL

Implementation of Active Directory Management solution including, Active directory

7
Management, Self-service portal, Audit and accounting, Backup and restore
Bidder will provide a detailed formulated project plan with timelines for the implementation of
8
the AD solution in consultation with CFHL
Services required to achieve the suggested solution, bidder is required to perform the same at no
9 additional cost to CFHL. Also activities & troubleshooting, but not limited to DNS entries,
cluster formation of servers shall be performed by the bidder.
The bidder is required to integrate all servers, applications and desktops running on
10
Linux/Solaris/Windows/MacOS (but not limited to) through Active Directory.
Bidder to ensure that no software reaches end of life or end of support during the entire contract
11 period, failing which, bidder will be required to upgrade or replace the same at no additional
cost to the CFHL.

12
Vendor should have to perform/configure backup for all the supplied solutions/applications as
per CFHL’s policy/requirement.
Bidder is also required to maintain, manage the active directory in terms of group/user
13 management, schedule management, domain management etc. as per best industries practice
for the duration of the contract.
The Solution should be able to track changes in AD like User creation/deletion/modification,
Groups, group policies, DNS. Provide alerting and reporting for the critical changes. Capability
14 to provide all regulatory compliance reports like SOX compliance, any other compliances as
mandated by CFHL. Audit logs for the Active Directory should be made accessible as and when
required by the CanFin Officials
 The Solution should be able to provide functionality which helps in automate backups and
15 quickly recover (As per the SLA timelines) everything from a single object to an entire forest, in
the event of a major disaster or corruption. Also, to have capability to test back restoration by
creating virtual environment, as per the RTO & RPO defined by the CFHL
The Solution should be able to provide deep visibility into Active Directory (AD) users, groups,
16 roles, organizational units and permissions by providing detailed reports on various aspects of
it. Apart from reports, it should also perform security assessments, configuration change history
reviews
Solution must provide self service password reset capability. The solution must be capable
17 enough to dictate the password policy in terms of complexity to the users. Should periodically
prompt users to change the password as per the agreed policy
Bidder to provide complete identity and access management (including PAM, PIM) solution
18 with integrated security and governance that connects all CFHL users to their apps, devices, and
data
Active Directory Solution should have integration with Multi Factor Authentication Mechanism
19
for additional security
The bidder should ensure that the advisories coming from regulatory bodies on time-to-time
20
basis should be addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the
21
audits
Index

Please populate only these columns with your responses

Bidder
Bidder Clarificati
Technical Specifications Importance Response ons /
(S/A/C/U) Comment
s
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
 Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Email Quota 100GB (add Critical

pointer)

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical
 Critical

Critical

Critical

Domain, Tree, Forest, Trust,

Schema, Global Catalog Server Critical

Critical
Group Policy Object(Directory
Service/File Share), Group Policy
Container, Group Policy Critical
Template. Three types of GPO's,
local, non-local and starter.

Local, Roaming and Mandatory

Critical
User Profiles
Software Details (but not limited
to):Windows 10, Windows Server
2019 or higher, Microsoft .NET Critical
framework v4.6.1 or higher
required.
Critical

Critical

Critical

Critical

Critical

Full server backup, System State

Backup, Authoritative, Non-
Authoritative and Primary Critical
Restore

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Backup solution
Sheet 22: Backup solution

Id System Requirements
Bidder has to provide the native backup solution of proposed cloud infrastructure provider as a primary
1
backup solution for CFHL
Backup Strategy
System Integrator will provide a detailed backup strategy inline with CFHL's IT policy. Get it approved and
2 implement the same for all the endpoints identified by the CFHL in the target state architecture. Server
Configuration and Data to ensure business continuity
The backup strategy should include the following items (but not limited to):

a) Backup plan should include databases, files, operating systems, applications, and configurations.
b) It should elaborate the Backup Infrastructure required to carry on the activities.
c) Backup retention policy
d) Cloud based backup solution
e) Schedule of Backup
f) Step-by-Step Recovery Plan
g) Plan for testing of backup system.
h) Daily, Monthly, Quarterly, and Yearly backup from both DC and DR must be done.
i)Daily, Monthly, Quarterly, and Yearly backup restoration from both DC and DR must be done
3 j)The solution must enable the Interoperability between DC and DR
k)Backup taken from DR must be restored in DC and vice versa
l)The bidder has to submit the consolidated (Daily, Monthly, Quarterly) compliance certificate of Backup and
Restoration on a quarterly basis to CFHL.
This should include the following (but not limited to)
a. File recovery
b. Server and VM recovery
c. Data recovery
d. Application recovery (source code repository)

4 The proposed backup solution should be compatible with any OS platforms

The software should have web-based GUI so that backup server can be managed centrally, regardless of
5
location. GUI should be same across heterogeneous platform to ensure easy administration
6 The backup software should support Backup to disk and Deduplication on DR Site
The proposed solution shall be able to copy data across firewall and should support full Backups. The backup
7
software should be able to recover all critical and other volumes and restore them effectively
The proposed solution must support data backup from all the server/storage/VM to be deployed in the target
8
state architecture including existing applications and IT infrastructure.
9 Solution to provide ingress and egress rule for backup solution
SI to ensure that the backup solution along with the data is encrypted and due care must be taken to prevent
10 the potential cyber attacks on the data, highlight the vulnerability and take necessary action to protect the
data from any possibilities of ransomware attacks.
For the SaaS solution, SI has to ensure the periodic/ad-hoc backup is carried out. Compliance of the backup
11
should be reported to CFHL periodically or as and when required
12 SI to implement suitable backup management software to ensure the backup compliance
Index

Technical Specifications Importance Bidder Response (S/A/C/U)

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical
Critical

Critical

Critical
Critical
Bidder Clarifications /
Comments
Backup as a service Index
Sheet 23: Backup as a service

Id System Requirements Technical Specifications

In addition to the cloud native Back up solution, bidder

must provide the backup as a service to ensure next layer of
1 redundancy.
The proposed Backup as a service solution should not be
the same as the proposed backup solution
Bidder has to ensure the Daily, Monthly, Quarterly, and
2
Yearly backup from both DC and DR must be done
Bidder has to ensure the Daily, Monthly, Quarterly, and
3 Yearly backup restoration from both DC and DR must be
done
The solution must enable the Interoperability between DC
4
and DR
5 Backup taken from DR must be restored in DC
The bidder has to submit the consolidated (Daily, Monthly,
6 Quarterly) compliance certificate of Backup and
Restoration on a quarterly basis to CFHL
 Bidder
Bidder Response Bidder Clarifications / Response
Importance
(S/A/C/U) Comments (S/A/C/U
)

Critical

Critical

Critical

Critical

Critical

Critical
 Bidder
Clarificat
ions /
Comment
s
SOC tool
Sheet 24: SOC tool

Id System Requirement

The Bidder shall provide 24x7x365 remote proactive monitoring service of the entire branch office
network, cloud based DC & DR infra, and SD-WAN network from their own SOC by specialized
technical team to ensure that the security services are always operational end-to-end.
1 The solution to cover the entire target state architecture for monitoring, alerting, reporting,
logging & troubleshooting prospects.

The solution should encompass appliance or software with a clear physical or logical separation of
2
the collection module, logging module and correlation module
3 The solution should be able to support automatic updates with minimal user intervention.
The solution must ensure all the system components continue to operate in case of any other part
4
of the system fails or loss of connectivity.
Log retention duration for all the SOC components is one year. Logs should be archived for
additional 4 years. Logs to be stored in encrypted format. Logs data should be stored within the
5 target state cloud environment for CFHL. All forms of audit trails and logs should be made
available to CFHL as and when required.
The Bidder should factor following pointers:
Whether log processing will be done in the SI Data center or in the target state cloud architecture
6 for CFHL. SI should come up with separate costing solution for both the scenarios and consider
the cost whichever is low.
7 The solution must automate internal health checks and notify the user in case of problems
The solution should be able to continue to collect data during database backup, de-fragmentation
8
and other management scenarios, without any disruption to service
The solution shall be able to capture all details in raw log, events and alerts and normalize them
9
into a standard format for easy comprehension.
The solution should be able to part and filter logs on the basis of type (but not limited to) of logs,
10
date, origin, time, network segment
In addition to the advanced analytics capabilities (but not limited to) like Managed Detection and
Response (MDR), Endpoint Detection and Response (EDR), Network Detection and Response
(NDR), solution should have capabilities to define rules on event logs captured from various
sources to detect suspicious activities Examples (but not limited to): • Failed login attempts •
11 Login attempts from suspicious locations (based upon the IP addresses) • Authorization attempts
outside of approved list • Vendor logins from unauthorized subnets • Vertical & Horizontal port
scans • Traffic from blacklisted IPs • Login attempts at unusual timings

The solution should support log collection, flow collection and other standard method for
integrating devices and applications. Logs obtained from CFHL device & application should be
12 copied and stored in vendor SoC within 5 minutes from the actual log event at the integrated
device/applications
Bidder should ensure automated log and event collection from sources (not limited to) IT, security
13
and network assets, operating systems, applications and databases, endpoints
The solution should have connectors or similar integrators to support the devices/applications,
14 wherever required the bidder should develop customized connectors/integrators at no extra cost
to CFHL
 The proposed solution should support collection of events through customization of connectors or
similar integration for the assets that are not natively supported. Solution should adhere to
15 industry standards for event collection (but not limited to): syslog, OPSEC, WMI, SDEE, ODBC,
JDBC, FTP, SCP, HTTP, text file, CSV, XML file, JSON.
All log data to be authenticated (time-stamped across multiple time zone) encrypted and
16
compressed before transmission to manager console
The solution should have high availability feature built in for automated switch over to secondary
17 collector/integrator in the event of primary collector failing. No performance degradation is
permissible even in case of failure of any of the security device
The solution should seamlessly integrate new devices with the environment without causing any
18
disruption to ongoing services
The bidder should support and integrate data (log and/or flow) collection from different OS and
their versions (but not limited to) Windows, Linux, AIX, Solaris etc, networking devices, security
19 devices and solutions, physical access control systems, Endpoints as required by CFHL.

The proposed solution should have connectors to support listed devices/ applications, wherever
20 required the bidder should develop customized connectors for seamless integration.

The solution should provide time based, criticality based, store and forward feature at each data
21
collection point
The solution should have a centralized correlation engine and a management center/console
22
which allows creation of an unlimited number of correlation rules
The solution should be able to perform different correlations (but not limited to): Rule based,
23 Historical based, Heuristics based, Behavioral based, etc across different devices and applications

24 The solution should be able to parse and correlate multi-line logs and flow data
25 The solution should have the ability to correlate all the field present in a log/flow data.
The solution should have the ability to gather information on real time threats and zero day
26 attacks from anti-virus, Intrusion Prevention System (IPS) and Intrusion Detection System (IDS)
and analyses data against the information for any threats
The solution should provide a web-based, user friendly console or a wizard based console to create
27
rule.
28 The solution should support logical operation and nested rules for creation of complex rules
29 The solution should allow applying filters and sorting of query results
The solution should be able to accept or integrate with asset details to provide asset level events,
30
security related incidents, vulnerabilities and issues.
The proposed solution should have the ability to perform free text search on events, incidents,
31
rules and other parameters
The solution must be able to integrate with real time threat intelligence feeds for the purpose of
32
correlating events. These feeds should be updated automatically
The correlations engine should be updated with real time security intelligence updates from the
33
OEM
34 The solution should be able to integrate with incident management and ticketing tools
The solution should provide a dashboard to display all the real-time events with drill-down
35
functionality
The solution must provide different role-based, user-based views to the dashboards which can be
36
customized as per the requirements
The solution should be able to generate reports of user activity, configuration change, attack
37 source etc. The solution should have report customization and report writing tool for development
of any ad-hoc reports
The collection solution, correlation Engine and the management console should support high-
38
availability feature at individually.
39 The solution should allow for load balancing the network bandwidth
The solution should auto replicate all the rules, logs, data, etc, to DR site for continuing the
40
operations without any loss in data
The collectors should be able to store/retain both normalized & raw data for forensic purposes for
41
the duration of One year and later on should be archived for next 4 years
42 The solution should support configuration backup and data backup separately
43 The solution must support export and import of backed up configuration and data
Threat Intelligence should deliver a comprehensive range of timely alerts/advisory and technical
44
threat intelligence through a customizable portal or Dashboard
Threat Intelligence should provide data feeds and API's for automated consumption by the SIEM
45
Tool
46 Threat Intelligence provided must be relevant, context-rich, timely and accurate
47 Threat Intelligence feeds should contain who, how and why are you being targeted
48 Threat Intelligence must enable to perform countermeasures for current and future threats
Threat intelligence feeds should enable efficient security operations and reduce the time for
49
investigation
Threat Intelligence should be capable to integrate with security, risk and management systems
50
and provide insights about emerging and current threats
The threat intelligence feeds should be available in multiple formats (but not limited to) CSV,
51
XML, CEF.
52 The Threat Intelligence Portal/Dashboard should provide End-to-End picture of threats
Threat Intelligence to provide reputation data feeds for actionable intelligence on IP addresses
and Domains/URLs exhibiting malicious activity such as malware distribution and botnet
command and control (C&C) server communication. The data feeds should be derived from
53 activity on the Internet and a reputation score along with additional contextual
attributes should be provided for each of the IP address and
Domains/URLs.

The solution should have capabilities to detect any compromises by linking related alerts collected
54
together over a period of time.
Alert analytics and attack detection Solution should have capabilities not limited to the events like
55 correlate alerts between sources & destination IPs to find similar or colluding threat signals.

Alert analytics and attack solution should have a knowledge base on methods used by attackers in
56
various past breaches globally to create models to detect such attacks.
Alert analytics and attack solution should utilize data science techniques to identify kill
57 chains for attacks such as lateral movements e.g. If a destination IP of one alert later becomes a
source IP of another alert this suggests existence of a sequence.
Alert analytics and attack solution should have detection models to find out threat’s sources are
58 linked to the same attacker by grouping alerts with common characteristics like (but not limited
to) time, day, location, target asset profiles etc.
The ticketing tool should be a software base solution which can be installed and configured on
59
different OSs but not limited to Linux, Ubuntu, Windows, etc
The ticketing solution must have the option to be hosted in on-premise environment of SOC
60
vendor or in CFHL cloud environment
Bidder should describe the all the target state solutions’ inline with the best practices in a
61
proactive manner
62 The ticketing solution should be able to integrate with Azure AD for user authentication
The ticketing solution shall support ITIL v3 & v4 best practice for service desk and incident
63 management process and also should provide the solutions key features which support the ITIL v3
& v4 for different process
Bidder shall provide a detailed description on how the solution will address the cases through
64
helpdesk or call centers including capabilities, constraints and restrictions involved
 The ticketing solution should easily initiate or transition into a major incident process from the
incident process, including changing the categorization, escalation, emergency notifications and a
65 critical incident management process. The solution should be capable of accepting user/SOC team
inputs like comments and screenshots etc
The ticketing solution should be capable enough to link incidents to completed change requests
66
The ticketing solution shall identify a failed change and identify the SLA breach for the change
67
requests
The SI has to adhere to the Solution based SLA inline with the timelines mentioned in the RFP
68
User identity should be accessible in terms of his details, L+1 details & contact details in case of
69 any breach, security violations. The solution should have capabilities to integrate with
the Identity and Access Management (IAM) solution
70 The ticketing solution should be able to track and maintain a knowledge database
Bidder should be aware of how the solution will utilize the initial repository of knowledge database
71
The ticketing solution should be capable to track the tickets for until closure and a record of all the
72
closed tickets
The ticketing solution should be able maintain a list of pending tickets and their SLA's. SLA's to be
73
defined by the SI in consultation and agreement with the OEM & CFHL Team
The ticketing solution should send regular updates/alerts for pending incidents along with the
74
aging details to SOC& the CFHL Team based on the level of escalation.
75 The ticketing solution should be able to create user based and role based access
76 The ticketing solution should provide dashboards for easy viewing tickets and their status
The ticketing solution should provide reports on various parameters like type of tickets (based on
77
severity e.g. P1, P2, P3 tickets)
The ticketing solution should provide the flexibility to download report in different formats like
78
PDF, EXCEL, etc.
The incident response solution should support auto-triggering of alerts from a number of security
79
products including (but not limited to) Firewalls, PIM, DLP, IPS, WAF, Anti-APT, AV
The incident response solution should have advanced techniques such as machine learning that
80 considers contextual parameters, historical behavior& external threat intelligence to score an alert
based on criticality in real time.
The Service Provider should provide automated incident analysis features/service for analysis of
alerts received to answer the following:  Impact on the assets  Attributes of an attacker 
81 Determine other assets which may have been compromised  Determine how long the attack
campaign was & where was first compromise  Maintain artifacts IoAs & IoCs of an incident

Bidder to describe how it performs a strong Incident Response Mechanism in providing a

82 comprehensive information about a potential incident, assemble the appropriate context,
investigate and make recommendations, containment & remediation activities.
Bidder should maintain an Incident Management Plan with at least the following:  Incident
Management Plan & Governance  Incident Response plan & Governance  Workflows for
83 Incident Management & Response  Communications & escalations Plan, Process & Metrics 
Incident Management & Response Case Management
Bidder will provide a detailed process for managing incidents - describing each phases of the
84 process – prepare, identify, contain, eradicate, recover and learn from the incidents responded to.

Bidder to develop response plan/ strategy which will describe the prioritization of incidents based
85
on the organizational impact (BIA analysis)
 SI to deploy a skilled team for handling incidents with proper segregation of roles (L1,L2,L3). The
86 incident handling team must make use of the incident management solution in order to raise the
incident ticket and track the incident to closure.
The incident management solution should be able to register any security event and generate
tickets. The solution should provide complete life cycle management of tickets from incident
87 generation till closure of the incident. The solution should have capability to structure rule based
workflow and calendar/ event based alerting capability.
The tool should facilitate time/ event based automated escalation of tickets as per the escalation
88 matrix defined by the CFHL. The solution should be able to send notifications and alerts in
different formats, such as e-mail, SMS, etc.
Bidder to provide services for brand monitoring of CFHL provided domain names, logos on social
89 media and dark web and keep a track of any suspicious activities by any of the CFHL domain users

Bidder should scan on any suspicious chatter, abuse of brand, phishing domains and report
90
proactively if something malicious is found published by any of the CFHL domain users
Bidder should look out for keywords (but not limited to), publicly exposed information, domains,
91 logs, customer abuse emails, phishing emails, social engineering attack, fake offerings, misleading
customer campaigns.
92 Bidder should also enable take down or delete of the content found objectionable by CFHL.
93 The reporting tool solution should be software based same should be accessible to CFHL
The reporting tool solution should be easily installed and configurable on different OS platform
94
like Linux, Ubuntu, Windows, etc.
The reporting tool solution should easily integrate with incident management platforms, SIEM
95
platform, Ticketing tools etc. to generate automated reports and dashboards
The reporting tool solution must provide an overall view of the functioning of CFHL to the
96
management, in the dashboard
The reporting tool solution should provide different types of reports (but not limited to) SLA
97 compliance report, operational reports, performance and availability reports, user activity reports

The reporting solution should integrate with Active directory and multi-factor authentication for
98
user authentication
99 The reporting solution should provide role-based and user based access
The reporting solution should alert any failure in data collection to the operational personnel as
100
per the SLA
The dashboard should be in the form of a unified portal that can show correlated alerts/ events
101 from multiple disparate sources (but not limited to) such as security devices, network devices,
enterprise management systems, servers, applications, databases, etc.
The reporting solution should support reporting for consolidated relevant compliance across all
102 major standards and regulatory requirements. This includes ISO 27001, RBI regulations,NBFC,
HFCs, IT ACT for the Indian territories, etc.
The reporting solution should support different views relevant for different stake holders
103
including top management, operations team, CISO Office
The reporting solution should support export of data to multiple formats (but not limited to) CSV,
104
XML, Excel
Events should be presented in a manner that is independent of device specific syntax and easy to
105
understand for all users
 Last mile connectivity shall be the responsibility of the vendor/ SOC provider. Bidder has to
provide the specifications and bear costs of entire connectivity setup.
The specifications for connectivity has to be in line with CFHL security policy relevant portions of
106 which will be shared with Bidder. CFHL will only enable the access as recommended by vendor in
line with CFHL policy.
The retention, deletion, synchronization with SIEM database should be automatic but it should be
possible to control the same manually.

The proposed SOC solution should ensure that the overall load on the network bandwidth at DC,
107
WAN level is minimal
The proposed SOC solution should have the capability to compress the logs at maximum possible
108 level without impacting the overall performance for storage optimization at no extra cost to CFHL.

The proposed SOC solution should have capabilities to store the event data in its original format in
109
the central log storage
The proposed SOC system shall be able to capture all details in raw log, events and alerts and
110
normalize them into a standard format for easy comprehension
The proposed SOC solution should support the following log collection protocols (but not limited
111 to): Syslog over UDP / TCP, Syslog NG, SDEE, SNMP V2 & 3, ODBC, FTP, Windows Event
Logging Protocol, Opsec, Netflow at a minimum.
The proposed SOC solution should prevent tampering of any type of logs and log any attempts to
tamper logs. It must provide encrypted transmission of log data to the log management. Log data
112 in transit or at rest should be encrypted with the help of hashing or any other secure encryption
mechanism
Logs older than 1 year should be kept in the proposed archival backup solution for a period of 5
113
years
Bidder to support in analyzing and advising CFHLs on advisories received from State-CERT,
114 National-CERT, security vendors/ OEMs, NCIIPC, RBI CSITE and any other government
agencies.
Bidder should help in providing root cause analysis, regulatory reporting in case of an incident
115
and take and advise remedial actions to prevent recurrence.
Advanced persistent threat detection solutions are required that intercept potential attacks by
116
using the latest information on threat methodology and the threat actors pulling the strings.
Bidder to provide hands-on training to the CFHL team on the product architecture, functionality
117
before implementation
SOC solution to monitor the integrated solutions in the target architecture like (but not limited to)
118
PIM, PAM, NGFW, WAF, IPS & IDS alerts
PIM
119 Monitor events from PIM and suggest/ take appropriate action to the bank on an ongoing basis
120 Improve the policies configured on an on-going basis to reduce the occurrence of false positives
121 Integrate PIM with SIEM to generate alerts for any PIM violations.
Anti APT
122 For Anti APT- Integrate Anti-APT with SIEM solution for any Anti-APT violations.
Monitor events from Anti-APT and suggest/ take appropriate action to the bank on an on-going
123 basis.
124 Improve the policies configured on an on-going basis to reduce the occurrence of false positives
SOC Reporting
Reporting and logging of information security incidents, track and monitor the closure of these
information security incidents and escalation of these incidents to appropriate teams/ individuals
in the banks if required. Documentation of Incidents along with their root cause to build a known
125 database of incidents to refer in future.
 Adherence to agreed Service Level Agreement (SLA) and periodic monitoring and reporting of the
126 same to the CFHL.
127 Periodic reporting to the CFHLon the status, issues/challenges faced and how they are handled
Vulnerability management and scanner
For Vulnerability Management and Scanner- Deploy the Vulnerability Management and
128 Assessment Scanner to scan the identified systems by the CFHL
Configure the vulnerability management (VM) policies and manage the vulnerabilities across
129 vulnerability management life cycle.
Integrate VM with SIEM solution to provide a correlated view of threats and vulnerabilities
130 associated with them along with remediation mechanism
131 Conduct periodic scans as defined by the CFHL on the identified assets
132 Ad-hoc scans to be conducted as and when required by the CFHL
133 Perform dynamic risk rating based on the exposure and likelihood of exploitability

Provide the report with following metrics (but not limited to)
I. List of top 10 vulnerabilities
II. List of assets with repeat vulnerabilities
III. List of all the vulnerabilities along with asset details (IP/host) and remediation plan in line
with bank's business requirements (for example if a server can't be patched then what work
around can be done to mitigate the vulnerabilities such as disabling the impacted service in case
134 that service is not required etc.)
135 Provide inputs to SOC team related to newly identified vulnerabilities to create use cases.
136 Conduct scan to confirm closure of vulnerabilities
Provide inputs for golden image (to ensure golden image is hardened for newly identified
137 vulnerabilities)

Standard Practice
Identify exploitable vulnerabilities that may impact the confidentiality, integrity, or
availability of the CFHL’s information. When appropriate to prove or demonstrate
identified vulnerability, the testing emulates an attack externally (or by an external
138 entity) attempting to breach the system from outside.

Assess current application security measures as they compare to security best practices,
business objectives, and regulatory requirements (But not limited to RBI, NHB). Security
Measurement Assessment Frequency has to be as per CFHL requirements.
139
Identify, collect, and review existing IT security policies, guidelines, standards, practices,
processes, and procedures. Review meeting frequency should be as per CFHL
requirements. Update & baseline the IT security policies, guidelines, best practice,
140 processes, and procedure documentation as per the CFHL requirement.
Bidder team to provide the qualifications, skills, and expertise of the SMEs in the
141 respective domains who will be part of the engagement during the contract period.
Conduct periodic external and internal vulnerability assessment and threat / penetration
142 assessment for the target state IT setup.

OEM should scan existing source code repository as well as modified source code,
identify the vulnerabilities, group them by severity (Critical, High, Medium, Low),
recommend the best remediation approach and provide a report to Bidder. Bidder should
ensure that the activity is conducted periodically or as and when required by CFHL.
143
 OEM to analyze the security assessment findings and prepare documentation to provide
a detailed analysis of the desired security posture in relation to industry best practices
and provide a prioritized action plan to Bidder. Bidder should ensure that the activity is
144 conducted periodically or as and when required by CFHL.
Bidder needs to co-ordinate and provide detailed remediation process & technical steps
145 for any of the problems identified during the security assessment
OEM to provide sample deliverables. This includes reports, project plans impacting the
target state of the applications, mitigation plans, and other services. SI to validate the
146 same
OEM has to provide a knowledge transfer plan regarding the mitigation approach for
vulnerabilities observed in the existing/new code repository to the Bidder. SI has to
ensure that the knowledge transfer sessions are documented and shared with CFHL IT
147 Security team
Respective OEMs have to do the analysis (automated or manual) of the target state
application portfolio to identify and remediate vulnerabilities and flaws in software that
may lead to security breaches. SI to ensure that the activity is performed periodically as
148 and when required by CFHL.
Examination (Code Review) of source code to identify, detect, and report weaknesses that
can lead to security vulnerabilities. SI to ensure that the activity is performed periodically
149 as and when required by CFHL.

Testing including but not limited to Blackbox, Whitebox and Greybox testing to detect
conditions that indicate any security vulnerability in an application in its production
environment, and to detect issues with & not limited to interfaces, requests, responses,
scripting (i.e. JavaScript), data injection, buffer overflows, sessions, authentication, etc.
150
Analysis of the target state application databases to check for the parameters (but not
limited to) like updated patches and versions, weak passwords, configuration errors. SI
has to ensure the activity is carried out periodically and the report for the same is
151 submitted to CFHL.
OEM has to conduct penetration tests every 2 months or as and when required to identify
exploitable flaws and measure the severity of each application and database identified in
this RFP. SI has to ensure the activity is carried out periodically and the report for the
152 same is submitted to CFHL.

The respective application OEM shall provide application vulnerability assessment and
penetration testing services including but not limited to the following: a) Authentication
process testing; b) Automated fuzzing; c) Development of test datasets and harnesses; d)
Encryption usage testing (e.g., applications’ use of encryption) e) Forming manual or
automatic code review for sensitive information of vulnerabilities in the code; f) Testing
of the application functionality including but not limited to:  Input validation (e.g. bad
or over‐long characters, URLs):  Transaction testing (e.g. ensuring desired
application performance); g) Testing systems for user session management to see if
unauthorized access can be permitted including but not limited to:  Input validation of
login fields;  Cookie security;  Lockout testing; h) User session integrity testing.
153
SI, should identify vulnerabilities in and exploit client‐side software, such as (but not
limited to) web browsers, media players, document editing programs, Operating
154 system,applications,softwares installed in endpoints
 SI to finalize the vulnerability assessment , penetration testing requirements, scope of
tools & the design of test cases, plan & strategy. Same need to be agreed by the OEM and
155 CFHL
156 SI to ensure review of test cases by the IT Project Team within the specified time.
OEM to define the test data required for penetration testing (White/Grey/Black) each
test case & execute the tests as per the test cases. SI to ensure that the activity is carried
157 out periodically and should report to CFHL
158 SI to coordinate for the final sign‐off from the authorized personnel.
SI to prepare recommendations to address vulnerabilities for IT Management systems in
159 the target state architecture
SI to suggest the IT Security best practices aligned with CHFL's IT, Information security
160 framework and SOP for IT Management.
OEM to provide the document including pointers (but not limited to) threat
modelling/source code/secure code to SI.
161 SI has to ensure that the documents are shared with CFHL whenever required
SI has to ensure that vulnerability assessment to be carried out for all the IT
infrastructure components (Not limited to Network components, servers, VMs,
162 endpoints, load balancers, DNS, AD) in the target state
SIEM Tool
Solution should be compatible with cloud architecture (preferably cloud native) and capable
1
enough to integrate all the target state infrastructure, security and endpoints components.
The solution must ensure all the system components continue to operate in case of any other part
2
of the system fails or loses connectivity.
The proposed solution must be scalable and have a distributed architecture with native replication
of data across DC & DR (Active-Active). Solution should have capability to create connector
3 between DC & DR.(Logs from DC should be available at DR & vice versa i.e. Site level redundancy
for SIEM mgmt + logs)
The proposed solution must support single site or multiple site clustering allowing data to be
4
replicated across the peers nodes and across multiple sites with near zero RTO & RPO.
The solution must have an automated backup and recovery process. Backup should be archived in
the encrypted format. The solution should maintain one year of logs on-box and 6 years of logs in
5 the offline mode. Total 7 years of logs should be available. The bidder to size the storage
accordingly
The solution must automate internal health checks and notify the SIEM Administrator from the SI
6
team in case of problems. SI team to take prompt action basis the notification.
The solution should be able to continue to collect data during all types of scheduled backup,
7 Antivirus scans, configuration level changes and other management scenarios, without any
disruption to service.
The proposed solution should be sized for all the endpoints in the target state infrastructure (but
not limited to Endpoints, Network & security devices, servers, VMs, active components) sustained
8 endpoints at correlation layer per Data center but should be able to handle future state scalability
of the CFHL infrastructure at correlation layer without dropping events or queuing events (for
SIEM) per Data Centre.
The Proposed solution should have capability to collect logs from most of the standard platforms
(but not limited to) like Microsoft Windows, Linux(All flavors),MAC OS,AIX, Solaris, Firewalls,
Network, network security devices or solution/s, identified database servers, endpoint security
9 management servers, web application firewalls, network firewalls ,Active Directory servers, Web
servers, Private cloud (VMware,Openstack) & cloud services (Aws/Azure/GCP), SaaS Solutions,
Mailing and Collaboration solution, etc.
 Proposed SIEM solution should act as common data lake for Correlation, SOAR,NDR,UEBA and
10
threat hunting
The Proposed solution should have inbuilt security mechanism for protecting itself from security
11
attacks
The proposed solution should have physical or logical separation of the collection module, logging
12 module and analysis / correlation module with the ability for adding more devices, locations,
applications, etc (High availability)
The proposed solution must support caching mode of transfer for data collection, so as to ensure
13 data is being logged in the event loss of network connectivity, and resume sending of data upon
network connection.
The SIEM platform should have capability to provide automatic notification to SOC teams. SIEM
14 solution should be able to categorize the alerts based on the severity as aligned with the CIA model
of infrastructure security
The proposed solution must be able to collect data from new devices added into the environment,
15
without disruption to the ongoing data collection.
The proposed solution must have a user-friendly interface to convert statistical results to
16
dashboards with a single click.
The proposed solution must be able to monitor and report user and privileged users access
17
activities.
The Proposed solution must offer all of the below built-in threat detection techniques out of the
box based on standard security frameworks for e.g.(but not limited to) NIST , ISO standards:
1.Detect Web Application Threats. 2.Detect APT Threats. 3.Integrate with leading HoneyPot
18 solutions. 4.Integrate with leading NBAD,NDR tools. 5.Give visibility of endpoints also by
integrating with EDR,DLP,Antivirus etc for endpoint analytics. 6.Integrate with SOAR tools for
automation. 7.Integrate with leading Threat intelligence Platform(TIP)

The solution shall be able to capture all details in raw log, events and alerts and normalize them
19
into a standard format for easy comprehension.
In addition to the advanced analytics capabilities like MDR, solution should have capabilities to
define rules on event logs captured from various sources to detect suspicious activities Examples
but not limited though : • Failed login attempts • Login attempts from suspicious locations •
20 Authorization attempts outside of approved list • Vendor logins from unauthorized subnets •
Vertical & Horizontal port scans • Traffic from blacklisted IPs • Login attempts at unusual timings

The proposed solution should be able to receive, ingest and index structured or unstructured data
21 without schema or normalization and no events should be dropped if log source changes the
format of log data.
The solution must have an incident review framework for incident management. Incident review
22
framework to facilitate incident tracking, investigation, pivoting and closure
Risk scoring framework to apply risk scores to any asset or user based on relative importance or
23
value to the CFHL's business
The proposed solution must be able to read data input from the following static log file formats
(but not limited to): a. Archived Log Files (Single line, Multi-line, and Complex XML and JSON
24 Structure) b. Windows Events Logs c. Standard Log Files from applications such as Web (HTTP)
servers, FTP servers, Email (SMTP/Exchange) servers, DNS servers, DHCP servers, Active
Directory servers, etc.
The solution must be able to provide the capability to fully customize alerts, reports and
25
dashboards to the CFHL's business requirements.
The solution must allow tracking of incidents from correlation rule through investigation of that
26
event to closure with respect to the incident reporting framework
The proposed solution must come with out-of-the-box integration and dashboards, reports, rules
27 etc to provides rapid insights and operational visibility into large-scale Unix and Linux
environments machine data : syslog, metrics and configuration files.
 Integration with corporate directories (AD, LDAP, etc) to extract employee information including:
-- Employee user names, first, last, phone, manager, department, location, if privileged, if on
28 watchlist, start and end dates, etc. Enables ability to correlate multiple user names back to a single
employee
The solution must be able to provide the capability to annotate events, modify status, build a
29
chronological timeline for the incident before and after a triggered event.
The solution must be able to assign any arbitrary risk score to any data point or fields, example,
30
user name, host name, location etc.
The proposed solution must be able to run any search on a schedule and set alerting conditions
31 based on thresholds and incremental inputs in the number and distribution of results across a
time range or days like a histogram visualization.
The solution must be able to support multiple transport mechanisms such as TCP,STIX and
32
Trusted Automated exchange of Indicator Information (TAXII).
The proposed solution must support viewing of the same log data in different formats or should
33 support multiple schema views during search time or report building time without redundant
storage or re-indexing so that complex report or user defined reports can be built.
The solution must be able to support the following indicators (but not limited to): 1.Network,IP -
HTTP Referrer, User Agent, Cookie, Header, Data, URL - Domain - Endpoint - File Hash, Name,
Extension, Path and Size - Registry Hive, Path, Key Name, Value Name, Value Type, Value Text,
34 Value Data - Process Name, Arguments, Handle Name, Handle Type - Service Name, Description -
Certificate - Certificate Alias, Serial, Issuer, Subject, Start Time, End Time, Version, Handshake
Type, Public key Algorithm, Signature Algorithm - Email - Email Address, Subject Body

Solution should support triaging of alerts from number of security products including (but not
35
limited) to NGFW, DLP, IPS, WAF, Anti-APT, AV, EDR.
Solution should support machine driven triaging algorithms that considers contextual parameters,
historical behavior and external threat intelligence to enrich and arrive at a triage score in real
time. Triage score should form the basis for prioritizing the alert and further action on the same.
Environmental parameters should include and not limited to asset criticality, user criticality, and
vulnerability status for every alert.
36
Historical parameters should include and not limited to attack volume, attacker volume,
destination volume for every alert, severity of alert and so on. Central Threat Intelligence feed
should also be applied to identify threats through known bad actors

Solution should support a rule engine for users to define custom triage rule. Rule engine should
37 support asset data fields, event data fields, user data fields, triage score, and triage parameters

Investigation module should integrate with log sources (not limited to) (ETDR, EPP, Data Lake)
38 on demand to pull data related to the investigated alert. It should also include charting and graphs
to analyze data
Solution should have features to analyze impact of the attack on the targeted asset including
39 configurations, Indicators of Compromise(IOCs), external network connections, Indicators of
attack (IoAs).
Solution should support models to build up the entire attack chain- from attack inception,
40
progress of the attack and spread of attack in the network.
Solution should support features to identify attacker attributes including threat intelligence score
41 of attacker using a sandbox solution, "who-is" lookup information, geomapping in a single
console.
Solution should provide runbooks for investigation steps corresponding to different types of
attacks, derive attack inception and progress of the attack. i.e. Detect Patient Zero, Attack origin
42 and Blast Radius.
MSSP to ensure the availability of runbooks in the proposed solution.
 Solution should support integration with commercial IOC sources. List the supported sources
which can be integrated with Solution and brief on the integration approach. Solution should
43 support features to analyze and identify the impact of this attack on other assets.

Solution should provide case management features to store raw and analyzed data for a specific
44 alert or set of alerts. Provide details on the what artefacts can be stored related to an investigation

Solution should support quick search across stored datasets in the Solution. Provide details of
45
search features supported.
Solution should provide features to do free flow visual analysis of alerts and logs from integrated
46 data sources based on custom criteria. This visual analytics feature should have appropriate
graphical representation options to visualize large scale data.
The proposed solution must come with pre-packaged alerting capability, flexible service-based
hosts grouping, and easy management of many data sources, and provide analytics ability to
47 quickly identify performance and capacity bottlenecks and outliers across all the environments

The proposed solution machine learning capabilities must includes API access, role-based access
48
controls for machine learning models.
The update in log format for a given OEM in its OS upgrade or other patch should be accordingly
49
parsed on to the OEM
The solution should support log collection, flow collection and other standard method for
integrating devices and applications. Logs obtained from devices should be copied and stored in
50 log service hosted in the cloud environment within agreed SLA timelines from the actual log
event at the integrated device
The solution should have connectors or similar integrators to support the devices/applications,
51 wherever required the bidder should develop customized connectors/integrators at no extra cost

The proposed solution should support collection of events through customization of connectors or
similar integration for the assets that are not natively supported. Solution should adhere to
52 industry standards for event collection (not limited to): syslog, OPSEC, WMI, SDEE, ODBC,
JDBC, FTP, SCP, HTTP, text file, CSV, XML, JSON file etc.
All log data to be authenticated (time-stamped across multiple time zone) encrypted and
53
compressed before transmission to manager console.
The solution should have high availability feature built in for automated switch over to secondary
54 collector/integrator in the event of primary collector failing. No performance degradation is
permissible even in case of failure
The solution should provide time based, criticality based, store and forward feature at each data
55
collection point
Solution should have capability to filter undesired, non-security logs at collection, processing and
56
visualization layer.
The proposed solution must be able to read data input from the following static log file formats
(but not limited to): a. Archived Log Files (Single line, Multi-line, and Complex XML and JSON
57 Structure) b. The solution must be able to accept the following live data streams like raw data or
JSON formatted data over HTTP/HTTPS.
The proposed solution should have a parsing capability once the log is ingested. The solution
58
should be able to parse and correlate multi-line logs and flow data.
The Solution must provide capability to search raw and indexed logs as full text, (text to speech
format) language, time range values, IPs, MAC address, IP subnet mathematical & statistical
59 functions, logical operators, occurrences count, regex, similar events, first & last seen, predictive &
prescriptive search suggestions etc.
The solution should provide detection/correlation of logs with malicious IP's / hosts / Domains /
60
sites /IOC's/hashes (leveraging external/Third Party sources)
 The solution should have a centralized correlation engine and a management center/console
61
which allows creation of an unlimited number of correlation rules
The solution should be able to perform different correlations (but not limited to): Rule based,
62 Historical based, Heuristics based, Behavioral based, etc., across different devices and applications

63 The solution should have the ability to correlate all the field present in a log/flow data.
The solution should have the ability to gather information on real time threats and zero day
64 attacks from anti-virus, IPS and IDS and analyses data against the information for any threat
intelligence, advisories
The solution should provide a web-based, user friendly console or a wizard based console to create
65
rule.
66 The solution should support logical operation and nested rules for creation of complex rules.
67 The solution should be able to integrate with incident management and ticketing tools
The proposed solution should detect threats using graph-based threat anomalies, which are
computed based on groups of similar anomalies rather than anomalies grouped by user or device.
68 Example graph-based threat anomalies are public-facing website attack or fraudulent website
activity.
The Proposed solution TI Service should anticipate likely threats to the Organization based on
69 global threat events and data and provide proactive measures to prevent such happenings in the
Organization.
The Proposed solution should support integration of machine readable threat intelligence from
70 different open and commercial sources. It should support providing weightage against sources and
support algorithms to reduce noise & false positives in threat intelligence feeds
The Proposed Solution should track status of assets against IoCs, CVEs and support the workflow
for remediation. As an example, CVEs related to shadow broker release should be used to identify
71 affected assets. Workflow should enable tracking the CVEs to closure through patching/other
activities. Service provider should track closure and corresponding risk reduction

The solution should support 3rd party / external threat intelligence to aid incident response by
72 bringing in organizational context and internal information available in SIEM and other sources of
security information
The proposed solution should detect threats like Lateral Movement and Data Exfiltration. These
73 should collect data about anomalies and users or devices to determine the likelihood of a threat.

The Proposed solution should Automatically enrich all incoming events with minimum following
information. These fields should be customizable to add/modify/delete as desired by
administrator): - Asset Owner, BIA & CIA - Geo-location of IP - Reputation of IP, URL, File etc. -
Hash of files - Historical security incidents on same IP/same host/same user/same
74 vulnerability/same location etc. - Threat Intelligence: (IoAs), (IoCs), and adversary’s TTPs -
Vulnerability information of asset. - Application Security review data. - Zone classification - Risk
score of assets Bidder to Provide details on what additional enrichment options can be provided by
the solution.

The Proposed solution should be capable to correlate events, network activity data, alerts, and
75 vulnerability data to provide complete view of security threats and generate real-time security
alerts
The Proposed solution should be capable to detect Slow attacks, advance persistent threats, file
less attacks, advance malwares, zero-day attacks, in-memory attacks, leveraging in-built self-
76 learning and analytics leveraging AI / ML. Also, capable to prevent & predict known-known,
known-unknown and unknown-unknown threats by monitoring entire IT infrastructure and
leveraging real-time threat intelligence.
The solution must be able to integrate with real time threat intelligence feeds for the purpose of
77
correlating events. These feeds should be updated automatically
 The correlations engine should be updated with real time security intelligence updates from the
78
OEM
79 The solution should support Cloud deployment
80 The Proposed solution must be ISO 27001 Compliant
Scalability of the proposed solution should be such as to cover critical network segments/verticals
81 with ability to ingest up to 10,000 FPS / 10 Gbps Per Data Centre ( DC & DR )

The Proposed solution should have separate component for packet/flow sensor, telemetry
82 processing (Telemetry is the automated communication processes from multiple
data sources) and management functions for ideal performance.
The Proposed solution should support installation of all components manually e.g. Threat
83 intelligence database, Geo-IP database, IP reputation, Upgrade firmware/ upgrade patches etc.
(offline download & install).
The solution must display visual traffic profiles in terms of bytes, packet rates and number of
hosts communicating. These displays must be available for applications, ports, protocols, threats
84 and each monitoring point in the network. All of these views must support network location
specific view such that they can present information from a single location, the entire network or
any other defined grouping of hosts.
The solution must support application definition beyond protocol and port. The system must
support the identification of applications using ports other than the well-known, and applications
85 tunnelling themselves on other ports (e.g., HTTP as transport for MS-Instant Messenger should
be detected as Instant messenger - not HTTP).
86 The solution must Identify & profile traffic by TCP and UDP ports.
The Solution should capture flow information from multiple network points like Network traffic
87 collected via (Not limited to)TAP, SPAN, and/or Mirror OR must support Flow, SFLow, IPFIX
collection and correlation.
The solution must support traffic profiling associated with logical network design (e.g.,
88
Subnet/CIDR).
The solution must identify network traffic from potentially risky applications (e.g. file sharing,
89
peer-to-peer)
The solution must create clearly independent and differentiated profiles from local traffic vs.
90
traffic originating or destined for the internet.
The solution must be able to adjust itself in DHCP environment and yet uniquely identify
91
machines with high accuracy despite change of IP Address
Solution shall have a feature capable of enabling retrospective analysis of the incident's logs,
92 returning the connection in seconds, minutes, hours or days before a certain anomaly had been
identified, SI to ensure the same
Solution shall create unique profiling for each user and device, as well as for the relations between
93
them.
94 The Proposed Solution must be able to scale up and down based on changes in scope
95 The Proposed solution must able to monitor all network traffic in real time
96 The Proposed solution able to query at least 3 months’ duration of past meta data
The solution should Integrate with Microsoft Active Directory (Azure AD), RADIUS, and DHCP to
provide user Identity information in addition to IP address information throughout the system &
97 allow groups based on Identity or Active Directory workgroup & Provide full historical mapping of
User Name to IP address logins in a searchable format
The solution should provide the capability to respond quickly and effectively with complete
98 knowledge of threat activity, network audit trails for forensic investigations, and integrations with
existing security controls.
The solution should be capable of providing visibility of east-west & north-south interface traffic
99 in an encapsulated network of ACI / SDA fabric, Natively or with a Use of VM based Telemetry
sensor or should be feasible in a way. (Bidder to mention feasibility)
 The Solution should be intelligent and should automatically tweak itself through automated
100
learning
101 Support creation of custom models for anomaly detection
102 The solution must detect “zero-day” events by leveraging anomaly based detection.
103 The solution must dynamically learn behavioral norms and expose changes as they occur.
The solution must detect and present views of traffic pertaining to observed threats in the
104
network.
The solution must display traffic profiles in terms of packet rate. This capability must be available
105 for simple TCP analysis (TCP Flags, etc.) but rate-based information may be presented for other
profiles (e.g Target state infrastructure devices, applications).
The solution must be able to profile communication originating from or destined to the internet by
106
Geographic regions in real-time.
107 The solution should Analyze access and its abuse with identity-centric behavior analytics
The solution should Model good behavior to expose unknown bad through peer groups, clustering
108
and outliers
109 The solution should Leverage predictive security analytics to risk-score incidents.
Solution must be able to identify/alert new and unknown attack behaviours without making use of
110
signatures or rules.
Solution should support a rule engine for users to define custom rules to leverage Network
111 Detection and Response (NDR) capability. Rule engine should support all possible fields &
parameters from a Packet header.
The solution must detect internal denial-of-service (DoS) and distributed denial-of-service (DDoS)
attacks including floods of all types (but not limited to) ICMP, UDP, TCP SYN, TCP NULL, IP
112 NULL etc identify the presence of botnets in the network, identify DNS spoofing attack etc. and
detect long-lived connections that may be associated with data-exfiltration.
The solution must be able to detect suspicious communication channels Services or applications
113
not running over its standard ports. (i.e. HTTP not over port 80)
The solution must be able to Detect and predict any data exfiltration by identifying abnormal
114
behavior as a part of cyber kill chain stages / MITRE / a well known attack framework
115 The solution must be able to identify IP / Port scanning reconnaissance attacks
The solution must be able to identify Malware / malicious bots detection through C2 (command
116
and control) communication
The solution should provide Detection of data exfiltration based on abnormal packet size (such as
117
exfiltration in ICMP,DNS packets)
The solution should provide Detection of lateral movement based on suspicious connections with
118
machines in the network
The solution should provide Detection of network crawling based on anomalous pattern detection
119
The solution should be able to store PCAP & Meta data of Communication/Flows if matched with
120 malicious IP's / hosts / Domains / sites /IOC's as prescribed by the regulators (leveraging
external/Third Party/Open Source TI feeds)
The solution must be able to identify Attack & Reconnaissance Tools - Check for commonly used
121
penetration testing tool and malware user agents
The solution must be able to identify Possible Masqueraded file transfer - Look for files
122
transferred with an incorrect file extension. Ignore common external domains.
The solution must be able to identify BitCoin Activity - Any communications using the BitCoin
123
mining protocol
New User Agent communication - Any new/suspicious user agent communication seen on from/to
124
device which is rare on the device/in the whole environment
Identifying traffic of Privacy VPN's - Personal VPN solutions which enable the user to avoid
125
network monitoring solutions.
 The proposed Solution should have inbuilt Models to detect use of various cloud storage services.
126
(eg. Amazon S3, Dropbox etc)
The proposed solution should be capable of identifying APT Activity - Detection of known
127
Advanced Persistent Threat indicators.
The proposed solution should be able to identify TCP/UDP malformed packets, TCP/IP stack
128
fingerprinting methodologies e.g. Christmas Tree packet.
Solution should identify and notify the instances where, Non-standard DNS servers are used
129
(Devices using uncommon DNS servers which were previously idle/were not DNS servers)
The solution must be able to identify RST storm- A large number of packets with the reset flag set.
130
This may disrupt normal communications
The solution must be able to identify Vulnerable Protocols( but not limited to ) - Use of out-of-
131
date/Known Vulnerable Protocols e.g. SMB, Kerberos,NetBios, old versions for TLS/SSL
The solution must be able to identify Unusual Connectivity- New or unusual connections, either
132
an external connection to/from domains/sources that are Unusual/Suspicious/rare.
The solution must be able to identify Address Scan - Scanning for single/multiple devices listening
133
on a specific port
The solution must be able to identify Port Scan - Scanning single/multiple devices to see which
134
ports are open on it.
The solution must be able to identify Bruteforcing - Repeated failed logins (but not limited to
135
KERBEROS,NTML, SSH or FTP).This could be indicative of malicious password guessing.
Solution must identify a ransomware attack basis the network traffic and alert the respective team
136
137 Solution must identify and investigate suspicious volumes of data transferred internally.
138 Solution must identify and investigate anomalies in patterns of DNS requests.
139 Solution must check for any Active sessions for longer than accepted time period
The solution should detect and alert on anomalies in DNS communications so as to pre-emptively
140
help detect security risks.
141 The solution shall be able to identify crypto compliance for endpoints (TLS, SSL versions)
The solution must do Identification of Malicious behavior in encrypted traffic without decryption.
142
SIEM dashboard access should have the extra layer of security with MFA integration along with
143
the standard AD credential method
144 Solution should have the capabilities of IOC blocking and domain filtering
The bidder should ensure that the advisories coming from regulatory bodies on time-to-time basis
145
should be addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the
146
audits
The bidder should ensure that the advisories coming from regulatory bodies on time-to-time basis
147
should be addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the
148
audits
Index

Bidder
Bidder Clarificati
Technical Specifications Importance Response ons /
(S/A/C/U) Comment
s

Critical

Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical
Critical
Critical

Critical
Critical
Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical

Critical
Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
 Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Desirable

Critical

Critical

Critical

Desirable

Critical

Desirable

Desirable
 Critical

Desirable

Desirable

Critical

Critical

Desirable

Critical

Critical

Desirable

Desirable

Desirable

Critical

Critical

Critical

Critical
 Critical

Critical

Critical

Critical

Critical

Desirable

Critical

Critical

Critical

Critical

Critical

Critical

Desirable

Critical

Critical

Critical

Critical

Critical
 Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical

Desirable

Critical

Desirable

Critical

Critical

Critical

Critical

Critical

Critical
 Critical
Critical
Desirable

Critical

Critical

Desirable

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical

Critical

Critical

Desirable
 Critical
Critical
Critical
Critical
Critical

Critical

Desirable
Desirable
Critical
Critical
Critical

Critical

Critical

Critical

Desirable
Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical
Critical
Critical
Critical
Critical
Critical

Critical
Critical
Critical

Critical

Critical

Critical
SDWAN
Sheet 25: SDWAN

Id System Requirement

Bidder to do the current state assessment of the existing internet setup

1
and feasibility at the branch level at no additional cost to CFHL

SD-WAN controllers, edge devices and all the SD-WAN component to

achieve the last-mile connectivity are to be set up, deployed and managed
2
by the managed service provider and SI to ensure the end-to-end
connectivity

SDWAN solution should be an OPex model. OEM should ensure the

3
availability to ensure uptime for the solution as per agreed SLA.

4
Ability to monitor real time network performance , quality parameters
like round-trip delay, jitter, packet drop etc and route critical
applications on the link with better characteristics.

5
Management of Customer Edge (CE) device should be available from the
Managed Service Provider's (MSP) cloud
Visibility on application-wise bandwidth consumption and control all
6
available bandwidth allocation in optimal way

Each edge device must dynamically establish fully meshed encrypted

7 overlay paths to every other edge device, across multiple different
WAN services through Internet. Bidder should provide technical layout
on this in co-ordinance with OEMs . CFHL will provide due governance.

8 The solution must support dynamic optimal direct site-to-site remote

routing (spoke-to-spoke model). The technical steps are to be provided
by Bidder which needs to be in adherence with CFHL's requirements.
The solution must respond to measured performance changes
9 (degradation) in addition to link and node state changes (up/down) and
adjust application forwarding accordingly
Edge devices must be able to load balance traffic across multiple WAN
10 paths based on load balancing algorithms efficiently using all
available WAN bandwidth.
The solution must be able to dynamically control data packet
11 forwarding decisions by looking at application type, performance,
policies, and path status.
 Target SDWAN solution must include Enterprise Application-Aware
Firewall, Intrusion Detection System (IDS)/Intrusion Prevention System
(IPS), deep packet inspection DNS/Web Layer Security, URL Filtering
12 ( Global & User based ), SSL Proxy, Advanced Malware Protection (AMP),
and Unified threat management (UTM) features(but not limited to)

NOC –The bidder to setup NOC for managing the SD-WAN links with
13 necessary software and to be deployed by the bidder. Access to be
provided to CFHL for monitoring.
Since SD-WAN implementation will be an OPEX model, as an when new
14
branches are opened, open model will be extended
End-to-end traffic segmentation is desirable with VPNs via SDWAN IP-
15
Sec Tunnel. Mesh network is desired.

16
The proposed SD-WAN solution should have stateful security features
(L3/L4 filtering, Zone-Protection for network, DDoS Protection) for
network isolation in the CPE along with SD-WAN features
Proposed solution must be scalable, bandwidth augmentation must be
17 considered and centrally manageable includes centralized fault,
configuration, accounting, performance, and security management
18 The centralized management solution must have web-based GUI

Proposed SDWAN solution must have Automated Zero-Touch

19 Provisioning in plug n play manner. The WAN Edge router must discover
its controllers automatically and fully authenticates to them and
automatically downloads its prepared configuration before proceeding to
establish IPsec tunnels with the rest of the existing network
The solution must provide guided workflows for deployment and
20
management of SD-WAN infrastructure
The solution must support end-to-end real-time flow visualization
21 for the application paths for identifying issues and taking corrective
actions.
All network-wide configurations shall be from the centralized
22
management appliance (SD-WAN Controller)
All application forwarding policies shall be configured from the
23
centralized management appliance

The centralized management solution shall have Network Management

System (NMS) capabilities and must support network wide device and
24
network visibility for all the devices in the scope of the solution. The NMS
should be configured to monitor all the links terminated on the devices
irrespective of the type of link
The solution must be able to collect and aggregate traffic statistics for all
25 WAN paths. Traffic statistics include path utilization, application specific
utilization and path performance
The solution must support device health monitoring for all the devices
26
within the solution scope without impacting bandwidth
The solution must store historical traffic and performance information as
27 per CFHL's instruction with trouble analysis, traffic forecasting and SLA
compliance.
28 The solution must support email based alarm to notify the administrators
when any device/link fault or network performance degradation happens.
Solution should support alert triggering based on the escalation levels

The solution should provide detailed dashboard & reports on network

performance parameters like utilization, packet loss, jitter, latency,
availability etc., and security of all the transport media terminated
29 (including media proposed to be terminated during the period of SDWAN
contract) on the CPE. The dashboard should support at least 10
concurrent admins (should have the capability of enabling/disabling
concurrent admin logins) of the CFHL, including service provider
engineers. Dashboard views for SD-WAN, security, CPE functionality etc.
Visualization using charts, real-time views, maps, grids.
The SDWAN service provider to ensure the SLA for the service uptime.
Bidder to ensure the SLAs are adhered throughout the contract period
Any other hardware / software required to complete the solution /
30 achieve functionality to be provided by the bidder, without any additional
cost to CFHL
Bidder to develop the cost-optimized best solutions for SDWAN
31
implementation

Target SDWAN Solution must include a secure web gateway, DNS-layer

32 security, on-device firewall, cloud access security broker functionality,
and threat intelligence. The Bidder to provide technical steps on this in
co-ordinance with OEMs which would reviewed by CFHL
Proposed solution must support Quality of Service (QoS) includes
33
classification, scheduling, queueing, shaping and policing of traffic
Proposed solution must support Forward Error Correction (FEC) and
34
Packet Duplication without impacting bandwidth
Proposed solution must support TCP optimization and Session
35
Persistence
Detailed deployment architecture must include the deployment flow
36 chart and steps of integration and Network planning and the SD-WAN
controller deployment should come first. The solution must be ready for
the time to time upgrades in the infrastructure landscape
Solution to ensure best quality Video Conferencing & VOIP services
communication receiving the as and when required priority when
37 traversing the enterprise's Wide Area Network (WAN) network by
applying policy rules to WAN traffic regardless of the transport method
with low latency thereby adhering to SLA
Solution to provide scalability both Horizontally(adds more machine
38 resources to your existing machine infrastructure) & vertically (adding
more power to your current machines )

39 Bidder should offer Zero Trust Solution to secure all access across CFHL
applications and environment, from any admin, device, and location to
mitigate, detect, and respond to risks across your environment
Solution must provide regularly backup for all SDWAN devices. Backup
40 should be encrypted and should be pointed towards the CFHL controlled
environment as per the defined backup policy
 Solution to enable DHCP service functionalities which includes MAC
41
binding and IP lease duration settings
The bidder is responsible for buy-back of the existing network devices
42
(Routers and switches) depending on the value and condition
Bidder will be responsible to provide L2 switches to all CFHL branches
along with RO.
43 No of L2 switch with 32-Port for RO: 10+
No of L2 switch with 32-Port for Cluster/VLBranch: 15+
No of L2 switch with 24-Port for Branches: ~185+
Bidder has to ensure to provide minimum bandwidth capacity of the SD-
44 WAN device as below:
100 Mbps at RO and Cluster/VL Branches: 19+
20 Mbps at branches: 200+
Bidder has to ensure to keep the standby SD WAN device and switches in
45
bidder location closer to CFHL cluster centers.
Index

Bidder Response
Technical Specifications Importance
(S/A/C/U)

Critical

SD WAN Core Components:

1.Controller –This device makes path optimization decisions and
configuration of application‐based forwarding policy and security
rules are done on this device. a)All policy and security rule
Critical
configurations are done at the Controller device b) Controller
devices make path optimization decision for the respective
sites and receives policy configurations from the centralized
Controller device.

WAN Edge Device(CPE) –This is the device where WAN interfaces

terminate. Edge device in each site make dynamic fully meshed
encrypted overlay paths to every other edge device. This device Critical
forwards traffic to other branches over WAN including direct
Internet access.

Analytics–SD-WAN analytics which analysis logs, events and

provide reports, analytics capabilities. It supports historical and Critical
real-time data reporting for application usage based on total
sessions, volume, bandwidth, application performance based on
latency, jitter, packet loss and WAN links performance.
Centralized Network Management–This device provides
comprehensive solution to manage, visualize, provision, automate Critical
configuration and monitor the proposed SD-WAN infrastructure
from a single graphical interface.
Critical

Critical

Critical

Critical

Critical

Critical
 Critical

Critical

Critical

Critical

The service provider should ensure that major security features

against attacks as mentioned below are implemented in their Critical
network: a)Protection against all kinds of attacks including DDOS
attacks, SYN attacks, smurf attacks etc.)Protection against all
kinds of spoofing like VPN spoofing/lP spoofing etc.

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
 Critical

Critical

All the reports as specified in the RFP should be able to be

generated from the NMS tool / SD-WAN analytics
Bidder should submit reports like Uptime, Bandwidth
utilization, Link error, latency, etc. on daily / monthly basis and
as per the CHFL requirement. All the locations are to be
monitored as per SLA.

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical
Bidder Clarifications /
Comments
ITSM Index
Sheet 26: ITSM

Bidder Bidder
Id System Requirement Technical Specifications Importance Response Clarifications /
(S/A/C/U) Comments
Solution 1- IT Service Management Solution
The Solution should have a process driven workflow which will incorporate actions (but not
1 limited to) routing of request, setup of service desk, SLA management, electronic request approvals Critical
by actionable e-mail, SMS alerts etc.
The solution supports ITIL V4 and above framework including terms and definitions. Also the
2 Critical
solution should be backward compatible with the ITIL versions.

3 The solution should be a web-based one and should provide an interactive interface to the end Critical
users.
The solution should support mobility devices to allow for role-based views that can be accessed
4 while away from the office. The solution should have the ability to operate all functionality (but not Critical
limited to) available in the incident, problem, change, assets, requests, as per the scope of this RFP
via mobile devices.
The system should be able to handle loss of connectivity failure of the Centralized ITSM tool with
5 the ability to support mirrored (redundant) systems at offsite Disaster recovery facilities across Critical
different geographic locations.
6 SLA for the ITSM tool to needs to be provided by the OEM as per the RFP and same needs to be
monitored by SI.
ITSM tool should have in-built reporting dashboard and capabilities of generating the reports
7 (Standard and customized) and logs for Audit Trails on daily/weekly/monthly/quarterly/ad-hoc
basis
8 The solution should provide Search capabilities in all ITSM processes Critical

9 The solution should be able to enable rapid creation of new users and administration of Critical
existing users
10 The solution should be able to support hot topic or news flash window within the graphical user Critical
interface
11 System should be able to generate an automated survey to the requestor to measure satisfaction of Critical
requestor
Tool should have the ability to segregate tickets based on IT needs of the end users (new
12 request/troubleshooting and additional categories as per CFHL requirement) following the security Critical
and compliance aspects
13 The solution should be able to configure the graphical user interface by using drag and drop for Critical
windows and fields

The bidder/solution provider has to provide the documentations (but not limited to) on concept
14 Solution, Scope, Functional and Operational requirements (for integration in the target state Critical
architecture/identification of resources), Project design and Plan, product description, guidance for
best practices, implementation guidelines, operation manual and training materials
15 The solution should have readily available for integration in the target environment Critical
The solution should have a Single Architecture and leverage a single application instance across
16 ITIL processes, including unique data and workflows segregated by business unit, cost center, and Critical
user role

17 The solution should have a persona-based approach for different roles so that user sees his relevant Critical
UI based on his role, for example change manager should see change functionalities only
18 The solution should have an interface with all the information about user, readily available when a Critical
user calls the helpdesk
19 Self Service capabilities of the ITSM solution should enable users to troubleshoot common issues Critical
through FAQ knowledge base with the help of an interactive interface
20 For integrations with other EMS/NMS tools, various options for integration should be provided by Critical
the ITSM solution (but not limited to)- APIs, web services, SDKs
21 The solution should integrate the call tracking and ticketing with the target state architecture. It Important
should be able to track logged calls.
22 The proposed solution shall provide an identity management that allows user/role management Important
and integration with authentication systems such as LDAP/AD
23 The proposed solution should also offer a service catalog as part of the license for all the IT Important
functions
24 The proposed solution should allow the analysts to create custom work streams from the analyst Important
interface & can hide, show, edit, or delete these custom work streams
The proposed solution must include timeline features for the representation of the activities on a
25 ticket displayed in a chronological order. Every activity on the ticket is captured on the timeline Important
along with contact information and the time stamp. A unique icon must represent each activity
type
26 The support person can interact with the end users through chat in built and add those chat Important
transcripts in the ticket
Incident and Event Management Requirement
1 Ability to set up a standardized incident management tool within various IT verticals Critical

2 Ability to manage and link incident records to multiple SLAs and tiers of service based on IT Critical
departments
3 The solution should have distributed event management with filtering, correlation, and enrichment Critical
to filter out unimportant events
4 Ability of the tool to facilitate the automatic prioritization, assignment and escalation of Incidents Critical
based on the record categorization on customized criteria
5 The solution should supports the ability to automate incident models and workflow based on Critical
record classification
6 Ability to support hierarchical escalation, either manually or via business rules, upon incident Critical
status change, priority change and/or service level change
The ability for hierarchical notification about incidents that exceed or will soon exceed
7 Priority/SLA parameters Important

8 Ability for users (Incident Owners) to create incident records through the Self Service portal Important
9 Ability to see countdown time left on response time (associated with priority or SLA) Important
10 Ability for users to choose to receive an email any time their ticket is updated Important

11 Automated ticket closure at a predetermined number of business days after a ticket enters resolved Important
status
ITSM tool to provide flexibility for the support. It should have the provision for the prioritization
12 based on the severity of the tickets. Ticket history should be logged and should be accessible for the Important
incident creator

13 Important
Flexible search capabilities for incident matching and trending based on various data elements
14 Ability to allow for multiple types of alerts, including SLA alerts, excessive reassignment alerts and Important
inactivity alerts
15 Ability to notify incident owners when the associated problem is resolved Important

16 Ability to set up a trigger for existing documentation to facilitate first contact resolution based on Important
product or service entered (i.e. Scripting from knowledge management)
17 Ability to store and maintain alerting distribution lists based on Incident types Important

18 Important
The solution supports the ability to automatically generate a unique case number to each request
19 Capability to link Incidents to Problem Records, Knowledge Base, known workarounds and Important
Request for Comments (RFCs)
Ability to link to the Configuration Management database or Configuration Management data; i.e.,
Incident record is pre-populated with relevant information from the Configuration Management
20 database related to the item that failed. The CMDB database to be managed by the OEM. SI should Important
be able to raise a ticket in case of an incident related to the CMDB/ITSM solution directly with the
OEM

21 Capability for storing historical incident data and other Incident related information including an Important
audit log with updates and resolutions
22 Ability to support highly flexible routing of incidents based on available resources located across Important
multiple sites and other factors, such as time of day, tiered service values
Ability to input free text, screen captures, and file
23 attachments for the recording of incident Important
descriptions and resolution activities
24 Ability to use knowledge and/or support scripts Important
for incident diagnosis and resolution
25 Ability to create an RFC or problem from an Important
incident with an automatic population of fields
26 The ability to collect feedback (satisfaction survey) upon the closure of an incident Important
27 The ability to put incidents on hold so time does not count against SLA Important
28 Ability to differentiate between an incident and a service request Critical

29 Ability to reopen incident in resolved status, in case the issue persists or the end-user is not Critical
satisfied with the resolution
30 Ability to generate reports on incident history and trends, by type of incident and by user Critical

31 Ability to support the creation, modification, resolution and closure or cancellation of incident Critical
records
32 Business owners should be able to graphically view the health of their business services and its Critical
related tickets pertaining to Business applications like (but not limited to) CRM, HRMS etc
Solution should have the ability to display the events in a table, service, infrastructure, tree views,
33 heat maps, etc. It should provide each user the ability to select, group or view the events as per Critical
their convenience
34 Should support advanced filtering to eliminate extraneous data / alarms in Web browser, GUI and Critical
any other channels supported by the solution
Change and Request Management
1 Ability to provide configurable change process and categorization templates Critical

2 Provide template workflow best practices and/or ITIL (all existing and upcoming versions) for Critical
emergency, normal and preapproved change
3 Provide basic required change record data fields Critical

4 Ability to relate post implementation incidents and problems resulting from an implemented Important
change
5 Ability to create sub activities or task records for a specific change record, for separate assignment Important
to an individual, group or vendor (OEMs)
6 Ability to provide role-based approval, retracting or rescheduling of Request for Change (RFC) Important

7 Ability to provide a change calendar with scheduled change viewing by group, and to Important
customize the sorting and filtering of calendar views
8 Ability to allow for scheduling of recurring events, such as certain types of maintenance Critical

9 Ability to easily identify the affected Change Incidents (CIs) whenever a change is made to a Critical
particular CI
10 Ability to provide visual depictions of upstream and downstream CIs that can be navigated in a Critical
configuration management database (CMDB)
11 Ability to select and create "preapproved changes" from a list of predefined templates with Critical
prepopulated content, such as (but not limited to) categorization, text etc

12 Ability to open an RFC against an incident/problem/known error record, and automatic population Critical
of the RFC
13 Ability to reference Change Model that clearly depicts the requirements and activities Critical
associated with the change process
14 Critical
Automated notification of RFC's to appropriate person(s) when change is updated, status change
15 The solution should have the ability to edit RFC's based on roles and change status. Should be able Critical
to map the role segregation as per the organizational hierarchy
Automated Approval workflow –
1. Ability to automatically send approval requests to designated approvers.
16 2. Ability to pick up and record approver responses. Critical
3. Ability to change status if approval criteria met.
4. send notification of approval (rejection) to change owner and change manager
17 Ability to have multiple approvers and electronic routing of those approvals Important
The ability to send approval requests several times and to store multiple instances of
18 approvals. The ability to reset approval status, resend approval requests and history logged of Important
approval requests
19 Ability to set response thresholds for automated approval process Important

20 Ability to progress requests through the appropriate stages of authorization and Important
implementation and to maintain clear records of this progress
21 Ability to provide real-time dashboards Important
Ability to integrate with Incident Management, Problem Management, Configuration
22 Management and Release and Deployment Management Important

23 Ability to use different process flows according to urgency Critical

24 Ability to clone change records/incidents Critical

25 Critical
Ability to restrict desired deployment dates during RFC submission based on minimum lead times
26 The ability to enter free form text, screen captures, and file attachments as well as the use of codes Critical
for recording of change requests

27 The ability to monitor and track the lifecycle of a Change request through proper hierarchy Critical
followed by the Change Advisory Board (CAB)
28 Discovery capabilities for service dependencies highlighting potential impact if a service is added, Critical
modified or deleted
Ability to calculate an objective risk assessment considering business impact, affected
29 application/business services criticality, collision, historical change information, and compliance Critical
with maintenance windows and black-out periods
Ability to provide proactive notification and approval workflow to stakeholders and change
30 advisory board (CAB ) members for changes with critical business impact, collisions and Critical
compliancy issues
31 Ability to support release and deployment management as part of the change process Critical
32 Ability to promote one or more RFC(s) to a release, with corresponding notifications Critical
33 Provide change workflow feeds into release workflow Critical

34 Ability to reference change policy and frameworks which reflect management’s expectations and Critical
intentions
35 Predetermined fields shall be auto-populated when a standard change from the library is entered. Critical
Manual entry for certain fields shall be permitted.
36 Ability to customize Change Dashboard by person, group of authorized personnel Critical

37 Ability for automated notifications sent at the scheduled start time to the activity assignee to Critical
remind them of the change
38 Critical
Automatic warnings of any RFC's that exceed pre-specified time periods during any stage (OLA)
39 The ability to communicate information of changes and schedules that can be distributed to the key Critical
groups such as the Service Desk and user groups
40 Solution should have self-service interface for end users to submit and track service request, Critical
spanning both IT services and non-IT services
Solution should provide for Service Requests Workflows and Fulfillment definitions for
41 commonly used IT/non-IT services with approvals, auto assignment, SLA and escalations. Critical

42 Catalog based on User role – enables access to service request on user role Critical

43 The solution should have wizard / graphical workflow editors allowing definition of new service Critical
catalog items in minutes – without any programming
The solution should integrate with any underlying service management including Change
44 Critical
Management, Service Level Management and CMDB for request fulfillment

45 Critical
The self-service interface should support knowledge base available to end users’ self resolution
Problem Management Requirements
1 Ability to provide configurable problem process and categorization templates Critical
2 Ability to provide standard required problem record data fields Critical
3 Provide problem process templates based on industry best practices and/or ITIL (present and Critical
upcoming versions)
4 Ability to prevent closure of a problem before all assignments have been resolved Critical

5 Ability to automatically update status or close all related incidents to a problem upon updating of Critical
status or closure of the problem
6 Ability to integrate problem management with incident and change management, i.e. ability to Critical
associate problem records with change records and incident records
7 Ability to automate opening of a problem record from an incident record based on business rules Critical
and SLAs
8 Ability to view impacted CIs from within a problem record, and to view upstream and downstream Critical
affected CIs and IT services through a visual depiction
9 Ability to track the total amount of time the problem was worked on and how long it was open Critical
10 Ability to link problems/known error records to a CI, group of CIs or a service Important
11 Ability to assign impact and urgency codes to problem records Important

12 The ability for authorized users to create new problem records, and enforce data rules and required Important
fields
13 The ability of differentiating between problems and known errors. Important

14 The ability of assigning tasks to individuals to be accomplished within a specified time frame. The Important
tool shall notify the assignee of the task and due date and the associated Problem record

15 The ability to make problem and known error details available to Incident Management for use in Important
matching, troubleshooting and resolution.
The ability to integrate with Incident Management allowing for the linking of Incident records to
16 Problem records in order to provide full visibility into incidents caused by problems and the impact Important
of problems to the business users
The ability to integrate with Change Management allowing for the linking of Problem records to
17 Change records in order to provide full visibility into problems caused by changes and changes that Important
are input to resolve problems
The ability to integrate with Configuration Management allowing for the linking of Problem
18 records to CI records in order to make CI information readily available to assist in the classification Important
and prioritization of problems and to allow visibility into problems associated with a CI or set of
CIs
19 The ability to route and assign problem records to pre-defined support staff or groups Important

20 The ability to present historical data on problems and known errors for use by support staff during Important
the investigation process
21 The ability to support free text, screen captures, and file attachments for the recording of problem Critical
descriptions and resolution activities
22 The ability for the problem management team to communicate status and progress reports, as well Critical
as temporary solutions and workarounds
The ability to increase/decrease the severity or impact classification of a problem according to the
23 number of associated incidents and/or the number of end users affected Critical

24 The ability to create, maintain and monitor a knowledgebase Critical

25 The ability to publish FAQ’s and supporting reference documents within the knowledgebase that is Critical
accessible by end-users
26 The ability to search for known solutions, work around and known errors based on the description Critical
of the problem
27 The ability to track multiple tasks and assignments with a problem Critical
28 The ability to document root cause analysis Critical

29 Ability to integrate with event and alert monitoring tools, and allow for automatic creation, update Critical
and closure of tickets from these tools
30 Ability to provide for documenting and managing knowledge data pertaining to problem and error Critical
control (e.g., data entry point for knowledge management databases, posting of FAQs)
31 The ability to link with third party knowledge bases Critical

32 The ability to report on the number of proposed solutions, most used solutions, and least used Critical
solutions in the knowledgebase
33 The ability to use solutions developed in response to past incidents to create new knowledge base Critical
entries
34 Ability to develop templates for recurring problems Critical
Knowledge Management
1 Ability to provide knowledge management capabilities by floating the most relevant hits to the top, Critical
in order of closest match to search
2 Ease of administering the weighting and relevancy scores associated with knowledge Critical
articles
3 Ability to launch fast knowledge searches using the categorization (or partial categorization) Critical
selections as key value search parameters
4 Ability to create a knowledge article via a fill-in-the-blank template Critical
5 Ability to automatically populate a knowledge article into an incident Critical
Bidder to maintain and periodically update the document repository. For instance, (not limited to)
6 DataSheets for the active components, Standards Operating Procedures (SOPs), Runbooks,
Handbooks
7 Ability to support role-based knowledge items (i.e., a technical role can access either technical-
facing or customer-facing articles)
8 Critical
The solution should leverage some of the fundamental knowledge repository modules out of the box
9 The solution should have the ability to automatically create knowledge management entries from Critical
incident, problem and change modules
10 Ability to manage full life cycle of knowledge articles through administration capabilities (e.g., Critical
submission, editing, review, approval, publishing, usage monitoring, etc.)
Ability for tool's knowledge management database to search other knowledge bases in Critical
11 environment

12 Ability to have a rich-text editor (RTE) that supports links within documents, document-to- Important
document links and attaching images to documents
13 Ability to provide automated administration (ease of adding, editing and maintaining the data, and Important
ability for end-user submission to require review/approval prior to posting)
14 Ability to have a defined workflow process for reviewing and approving pending knowledge articles Important
that can be displayed graphically
15 Ability to make certain fields in the knowledge article template mandatory Important

16 Important
Ability to embed Web links, images and objects into knowledge articles (e.g., screenshots, etc.)
17 Ability to provide a web-based knowledge base that assists in finding, organizing, and publishing Important
knowledge articles that aid in self-service & faster turn-around time
18 Solution should be able to communicate with multiple sources, internal incident resolution Important
repository, internet for knowledge search.
19 Ability to build Knowledge repository based on knowledge-centered support (KCS) standards and
guidelines
20 Ability to define role based access restriction to access and perform changes on the target Important
environment/devices
Orchestrator
1 The proposed solution should include an orchestrator, which facilitates the integration of the Critical
proposed OEM products, and create end to end process workflows
The proposed solution should have the ability to
graphically design process workflows such as
2 automatically triggering a discovery scan, through Critical
an ITSM request, or automating a package
deployment or patch analysis job, through a self-service request in ITSM solution
 The proposed solution should have the ability to
create Operator initiated change requests i.e.,
any operation performed via the automation tools
3 for server and network device related patching or Critical
configuration, should automatically log a change
request in the ITSM tool without any human
intervention
4 Offline development - Support for development of offline workflows in the tool in local Critical
environment as per the target state requirement
The proposed solution should have the ability to
5 re run a workflow from the point where it failed Critical
instead of starting from the beginning
6 The proposed solution should have the capability of error Handling - Ability to incorporate error Critical
handling mechanism within workflows
7 The proposed solution should have the capability of resolving workflow dependencies Critical
The proposed solution should have an operational Dashboard/Command Line Interface (CLI) -
8 Trace workflow's failure, active/inactive workflows, archived Critical
workflows
9 The proposed solution should have the capability of package Deployment - Deployment of a single Important
workflow or a package with multiple workflows in integrated target state environments
The proposed solution should have the capability
of version controlling of workflows - Should be
10 able to revert to older version, and facilitate a Important
backup repository for recovering accidentally
deleted workflows
The proposed solution should have the roadmap
and the facility of on boarding additional modules
11 for additional use-cases and integrate with other Important
OEM Solutions in the future if required by the
CFHL_x000D_
Solution 3: Capacity Management

The solution should facilitate the collection of

data to measure capacity and performance levels
of IT components beyond the defined thresholds from various domains/platforms
used as part of an IT system including:
1 Critical
-Servers (Physical and Virtual)
-Databases
- Middleware
- Web Servers
- Application
The solution should facilitate the monitoring of CI
2 performance and usage levels against customer Critical
defined thresholds
The solution should be able to control the
3 frequency and format of the monitoring activities, Important
discarding non-relevant periods such as
weekends or non-business hours
The solution should perform trend analysis by
4 providing access to historic and time-based Important
capacity and performance data
Solution should analyze how capacity needs are related to business drivers by correlating resource
5 performance with business KPIs, such as identifying the storage space requirements of Business Important
applications as per the business model
Solution should estimate thresholds in
6 terms of business metrics, such as identifying the Important
maximum number of transactions that can be
supported by the current infrastructure
 Solution 7: Configuration Management

1 The tool must have the ability to encompass the applications and establish the relationship with Critical
different types of underlying infrastructure assets. The configuration level backup for the endpoints
& active Infrastructure components to be stored on the target state cloud storage infrastructure.
2 Ability to add or delete Configuration Item (CI) Types and their corresponding fields Critical
Monitor the environments under scope to identify :

1. changes in software installations and business services/applications

2. removal of software/applications
3. unauthorized software installations as compared to an existing software white-list;
4. changes to databases
5. Privilege assignment, modification and deletion, with respect to active directory, database, ERP
3 & BPM Solutions, business services/application, networking equipment, Critical
firewall devices, web servers & applications, IP telephony systems and infrastructure
devices/equipment
6. Changes in firewall rule-base and configurations
7. Configuration & routing table changes in networking devices

4 Ability to maintain an audit trail of changes made to a CI attribute over time. Critical
5 Ability to search for a CI by any CI field (Management IP, Hostname, IP address) Critical
Ability to perform adhoc/general queries. Ability to track Asset status and lifecycle management
6 such as procurement, stored, configured, deployed, active and retired stages to get the control & Critical
visibility over the asset repository.
7 Support release, impact analysis, planning, rollout and deployment activities Critical

8 Critical
Ability to record a wide variety of contracts and licensing agreements by attaching them to records
9 Ability to perform software license management including automated notification of license Critical
expiration and noncompliance and reporting, tracking and auditing.
Ability to support both flexible data import/export, and simple points of integration for associated
10 tools. Ability to interface with Inventory Control tools to automate gathering of asset and inventory Critical
information.
11 Integrates with Release Management allowing for the display and reporting of impacted CIs via Critical
their link to changes associated with a Release.
12 Ability to distinguish an Asset from a CI. Important

13 Integrates with Capacity Management allowing for CI information that is readily available Important
regarding capacity status and metrics.
14 Ability to "freeze" a CI so that it cannot have an RFC logged against it at all. Important
15 Ability to auto discover CIs in the environment. Important
16 Ability to do automated dependency mapping. Important
17 Ability to set automatic workflow triggers based on CI attribute values. Important

18 Important
Bulk import of licensing data – save time with simultaneous uploading of multiple licensing records
19 The proposed solution should integrate with SIEM solution Important
20 The proposed solution must support IPv4 & IPv6. Important
Release and Deployment Management Requirements

1 Ability to manage all aspects of the end to end release process for example (not limited to) Critical
Application Patches, OS patches for the endpoints, Firmware upgrades for the active components
2 Ability to capture implementation risk and integration issues related to any release Critical

3 Ability to maintain the release log a Release so that changes can be identified and related to the Critical
release.
4 Ensures coordination of build and test environments teams and release teams Critical
5 Ensures teams to follow the organization’s established policies and procedures Critical
6 Provides management reports on release progress on a real time basis Critical
 7 Ability to capture the release date and time, and the responsible team implementing it. Critical
8 Ability to attach and store documentation with the Release record. Critical
9 Ability to link resources/approvers to releases. Critical
10 Ability to display impact of release on configuration items like servers, applications etc. Critical
11 Ability to assign release tasks to individuals to be accomplished within a specified time frame. Critical
12 Ability to notify the assignee of the release task and due date and the associated Release. Critical
13 Ability to change status of release and linked changes. Critical
14 Ability to change status of release approvals. Critical
15 Ability to automatically send approval requests to the appropriate approvers Critical
16 Ability to alert release manager when approvals are past due. Critical

17 Ability to be automatically notified when the status of a change associated with a release changes Critical
status

18 Ability to automatically approve releases when all approvals are returned approved, and Critical
communicate with appropriate parties regarding the approval.
19 Critical
Ability to store approver comments with the approval, and store approval history for a Release.
20 Ability to integrate with all types of Change Managements allowing for the linking Release records Critical
to Change records
21 Critical
Ability to validate required information from the CMDB for release build and deployment activities.
22 Ability to ensure that release deployments are subject to scheduling and approval requirements Important
managed by the change management process.
23 Ability to automatically flag for update CMDB Configuration Items prior to or following an Important
approved release
24 Ability to support varying Release models such as large-scale or phased deployments. Important
25 Ability to integrate with the CMDB to support the association of release records to CI records. Important
26 Ability to configure an acceptable date range for approval for each release. Important
27 Ability to manually kick off approval process or override approval workflow. Important

28 Ability to create a real-time dashboard that allows the Release manager or any other approved user Important
to quickly ascertain details on release management in one location.
29 Ability to search all releases by any 'release data attribute' captured by the tool. Important

30 Ability to integrate with Problem Management allowing for the linking of Problem and Known Important
Error records to Release records.
31 Important
Ability to define Release Windows (show conflicts that impact when Releases can be scheduled).
32 Ability to create and publish a Master Release Schedule. Important
33 Ability to support the establishment and governance of release readiness criteria. Important
34 Ability to build, bundle and schedule different types of release packages for deployment. Important
35 Ability to identify and control a release package. Important
36 Ability to version release components and packages. Important
37 Ability to verify license and warranty information Important
Enterprise Ticketing Feature

Solution to resolve general issues such as service questions, FAQ’s, information on features and
1 Critical
should provide the resolution during the interaction (Over Inbound Call/Mail/Chat/App Store
Comments). Customer Service Executives (CSEs) shall try to resolve the reported query/issue
(wherever possible) and if the query/issue requires further investigation/fixing. Users will be either
directed to contact Help Desk of departments for any issues related to services of department
 The tickets will be assigned Priority (1 to 4) based on the criticality of the issue (P1 , P2 , P3 , P4)
2 Critical
The ticket will then be picked by the TechOps team which will work on the resolution of the issue
and once resolved or in case of any further queries will update the ticket and assign it back to the
Customer Service Executive(CSE) which will notify the User accordingly. If the grievances are
related to specific departmental service, the same will be notified to the department through in
house built CRM system in the 'To-be" state

The particulars of the business services that shall be provided by the Bidder can be broadly
categorized as:
I. Handling inbound voice calls.
3 II. Making outbound voice calls. Critical
III. Handling inbound E-mails.
IV. Handling Inbound Chats.
V. Handling queries received on WhatsApp Business number incase any
VII. End-to-End Responsibility

The Bidder shall provide inbound voice call services in the below languages:
Hindi, English and should factor in other regional languages in future as required by CFHL

Most of the queries / grievances may be resolved by the Customer Support Executives (CSEs) using
4 the information available. CSEs may be required to provide information on specific Services or Critical
work flows to the callers. Usually, the nature of informational services remains static over a period
and it is common for all the Users, e.g. CFHL Registration, Login procedure, Service information,
etc and in case of any reported bug/issue or grievance, CSEs are required to generate a ticket as
explained above in the CRM system. However, for any queries/grievances related to services
of department availed through CFHL, the Bidder CSEs shall forward the cases to the concerned
departments using CFHL’s CRM application in the target state.

The Bidder shall be required to add new flows/modify existing flows/ change prompts and publish
these immediately in the IVRS without having to take the services down with no additional cost.
e.g.
Bidder may be asked to add a “User Satisfaction survey” in the IVRS flow so that the User can be
guided to rate the interaction which he/she just had.

Outbound Voice Calls:

5 Critical
Outbound call service shall be used to pro-actively get the User feedback/experience with regards
to the services availed on CFHL or to encourage the User to do registration on CFHL and avail
services.
The outbound calls shall be done in Hindi, English and should factor in other regional languages in
future as required by CFHL Rephrased

Inbound E-mails

6 The Bidder CSEs shall reply to inbound emails received on CFHL's mail customer service mail Critical
address. The email module should be integrated with CRM system in the target state. Emails shall
only be answered in English.
The Solution must have predefined timelines for the escalation (Depending on the severity and as
decided and agreed with CFHL
 Replying Inbound Chats
7 Critical
The Bidder CSEs shall reply to inbound chats received on CFHL’s Mobile app using CFHL’s CRM
application. The chat module is integrated with CFHL’s CRM. Chat support should be available
24x7x365 in English. The Bidder can develop and use Chat Bots intermingled with agents to answer
user’s queries

CFHL Chat Mechanism Comments

8 Critical
The Bidder CSEs shall review the User Comments received on CFHL chat groups and provide
resolution to User queries/grievances

End-to-End Responsibility

The Bidder shall take end-to-end responsibility to close the loop with different entities that may
have to come together to provide a resolution to Customer queries through proactive follow-up.
The Bidder to identify problem resolver groups within the program Technical groups to resolve
9 queries and grievances that reach the Help Desk center. Critical

The Bidder shall also work closely with in developing work flow, escalation procedures and
reporting mechanism for resolution of queries/grievances through different resolver groups.
Bidder shall interact with the identified resolver groups and assume responsibility for driving
closure of open queries and grievances from different stakeholders

Automatic Call Distributor (ACD)

ACD distributes incoming calls to CSEs as they are received. It should be pre integrated with the
IVR with at least below features and Bidder may propose additional features:
i. Handle high call volumes efficiently
ii. Provide the capability of combining data with the Interactive Voice Response (IVR) menu system
that can intelligently route calls requesting further assistance to a smart Automatic Call Distributor
10 (ACD) Critical
iii. Provide highly configurable system for adding/removing users, assigning users to different
queues
iv. Allow calls to be transferred within the Help Desk Center
v. Support relaying of the information messages (marketing messages) to voice callers waiting in
queues or on hold
vi. Skill based routing: Standard features like Call Transfer, Conference, Barge in, Dialed Number
Identification Sequence (DNIS), Automatic Number Identification (ANI), Caller Line Identification
(CLI), etc.
vii. System should be able to intelligently route the callers to CSE’s as defined by the administration
viii. System should announce the queue waiting time for the caller before getting attended by an
CSE

Data Storage and Archival

11 The operational data such as Call records, Chat, emails etc. being generated during the operational Critical
period will be properly stored and archived for at least 180 days as per the industry standard
practices to
be used for as per the requirement. After 180 days backup has to be moved to the archival solution
in the target state.
At no point shall any data of CFHL system be ported outside the geographical limits of the country

12 The Vendor should generate daily/weekly/monthly reports as required by CFHL and on demand Critical
between any time frame
13 Solution to provide user feedback experience via SMS/WhatsApp/Email from end user on ticket Critical
closure
14 The ticketing tool should be accessible and available to use 24x7x365 Critical

15 Solution must provide knowledge base and should be integrated with the overall knowledge Critical
repository
16 Solution must provide Auto alerts for SLA breach Critical
Disaster Recovery Drill
Sheet 27: Disaster Recovery Drill

Id System Requirement

Perform detailed risk and Business Impact Analysis (BIA) of current business processes and underlying
1
systems to identify and clarify the business availability requirements
2 Identify critical resource recovery requirements and establish the recovery strategies
Develop a detailed Disaster Recovery Policy & Plan with clearly identified strategies for various disaster
3
scenarios.

4 Plans and key documentations should be printed, stored safely and accessibly away from work

5 Insurance policy (wherever applicable) should include business interruption coverage

Potential financial and non-financial impact of a business interruption involving major human, physical
6
and technology loss should be known
Information on maximum tolerable outage and critical activities in the event of a disaster should be
7 available. SI should ensure the RTO & RPO parameters are adhered during the DR-Drill or an un-
anticipated incidents
8 Minimum resources needed to recover the critical business functions should be available
Business Continuity Teams including the crisis management function and critical business functions
9
should be defined
Alternate resources for all personnel, especially recovery team members who hold responsibilities during a
10
disaster, should be available
11 DR Plan should include backup facilities, hot backup site, cold site and reciprocal agreement
Project management skills or staff to identify, plan and execute the next steps in re-building as well as
12
continuing to operate as a business should be present.
RTO (30 mins) the time an application can be down without causing significant damage to the business to
13
be specified and maintained across all the platforms
RPO (10mins), the departments data loss tolerance should be specified and maintained across all the
14
platforms
CSP ahs to make sure that the availability of subscribed Cloud Services should be provided. SI has to keep
15
track for the same

16
Solution must provide Database, Applications, File storage sync between DC-DR real time basis
SI should maintain the checklist for the activities to be performed during the DR-Drill and the same should
17
be shared with all the stakeholders.
Before conducting the DR-Drill, Dry Run for the same needs to be conducted. The results for the same
18
should be documented and shared with the CFHL team
Results for the actual DR drills should be documented and should be made available for future reference
19 and as and when requested by CFHL and auditor. Due diligence for the DR-Drill reports should be
conducted by SI as desired by CFHL.
 Discrepancies observed during the DR-Drill should be rectified on priority basis. RCA to be shared for any
20 sort of issues observed during the DR-Drill. These RCAs should be shared with the stakeholders. "Lessons
Learned" should be documented for future reference.
The SI should ensure the Triage calls for all the stakeholders before, during and after the DR-Drill as
21
required.
DR drill activity should cover CKYC,RBIA and ADF applications also along with other core applications as
22
per bidder scope for target state.
23 VM/Platform/Connectivity to be supported by bidder and application support by respective OEM.
Index

Bidder
Technical Specifications Importance Response
(S/A/C/U)

Critical
Critical

Critical

Names, addresses and phone numbers for the crisis

management staff, staff members, clients and vendors.
Location of the offsite data backup storage media. Critical
Locations of alternative worksites.
Copies of sales contracts, agreements or other key
business documents.
Copies of insurance contracts.
Other critical materials necessary for business survival.
Critical
Critical

Critical

Critical

Critical

Critical
Critical
Critical

Critical
30 minutes
Critical
10 minutes
Critical
>=99.9%

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical
 Bidder
Clarifications /
Comments
Data and Analytics Index
Sheet 28: Data and Analytics

Id System Requirement Technical Specifications

Establishment of a robust Management Information
System (MIS) for the different users at functional
departments and data requirements of CFHL,
1 specified external stakeholders for their internal,
external and regulatory purposes duly ensuring
speed, data integrity and consistency.

The Proposed solution given by the SI should have

detailed steps on Data Acquisition to connect
2 different types of storages, mentioned native standard
connectors for wide variety of inputs & unstructured
data integration and parsing.

Data Extraction for internal sources will be in form

csv extracts or any other industry standard formats
provided by the internal source systems and
3 periodicity required by the system. For external data
sources, a suitable data feed format (csv extract or any
other industry standard formats) will be agreed with
the data provider.
SI is responsible to ensure solution components The solution should be compliant from
4 deployed as per the scope, dependencies on the security standpoint
software/tool.
SI must consider Data Security – Access
(Authorization) &​Protection​for user authentication,
5 authorization, accounting with MFA, integration with
Active Directory & native data masking feature and
protection tool​.

The proposed solution should have steps to include

Data Governance for Metadata management
6
(Business Glossary, Search functionality)​& Data
catalog experience (such as Define business glossary )​

The proposed solution should address data ingestion

7 from different business and application components
of CFHL and keep a real time sync of data.

The SI needs to create a strong foundation with data

8 quality check that enables the analysis of the various
business domains
The SI shall also provide an incident
management solution to log issues and with
Solution document should provide onsite managed facility to generate reports for review and
services for supporting the tool which includes monitoring.
9 extraction and development of reports and onsite help
desk services (both technical and functional support)
during the Contract Period.
 The proposal should include a 24*7 available incident
SI to propose Ticketing System for Incident
10 management system to cover batch jobs as well as real
Management for this project.
time data sync and user support
The proposed Solution should continuously evolve to The Solution should manage the data flow
meet new and changing user from the source systems to data warehouse
11 information needs, keeping in mind visualization, and finally to users interconnected and
display, alert and user self generated reports wherever bidirectional data pipelines.
considered feasible

The Solution should automate the dataflow from the In a real time environment, it must detect
source systems to the data analytics tool. In addition, anomalies and notify the appropriate
12 it must detect changes in the source schema and individuals or trigger alerts in operational
identify impact of changes on downstream objects dashboards.
and applications.
The Solution must be flexible enough to support The Solution must be flexible enough to
multiple types of users, load operations, refresh rates enable easy transition in case CFHL wishes
13 and query operations (e.g., create, read, update, to go for data virtualization
delete)
The proposed solution must split the responsibility
between acquiring & transforming data and
consuming information. The end users (with requisite
14 skills and need) should have
the flexibility to explore the data on an ad-hoc basis.

The architecture of the solution must define access Users may be classified as data generator,
points, access control and usage framework for each data collectors, data aggregators, data
15 category of user to meet their information managers, data consumers, data explorers,
requirements data analysts, data scientists

The solution should enable addition, modification The proposed solution will store the data on
16 and disablement of source systems (both internal and premise/ Cloud as agreed with CFHL.
external ) anytime in the future
The solution should support seamless integration of The solution may contain cloud
compute resources and data from the sources to the services for ETL, graph database and No-
proposed cloud without any downtime SQL database. In the event of ETL services
being deployed on cloud the processed data
must be seamlessly synchronized to target
17
storage services.
The solution should be able to access the
databases across multiple cloud platforms.

Security features of the solution to confirm to The SI shall provision and monitor all the
industry standards including Information Technology security layers.
Act 2000, Information Technology Rules 2011,
Aadhaar (Data Security Regulations)
18 2016 (if Aadhaar is used in any manner as part of the
solution), GDPR,
ISO 27108, Personalized Data Protection Bill 2018,
etc
 The Solution provides end user cross functional
requirements across the areas of finance, loans,
19 development, staffing, disbursements, repayments
and activities of corporate functions encompassing
planning, strategy and supervision.
The Solution should include automation of report
20 generation by the proposed tool as and when required
by CFHL
The SI shall also propose an adequately sized training The SI shall provide and maintain the
environment separately for internal training to be training environment by right-sizing the
conducted for CFHL. CFHL function team can solution and any other application to
21 designate dedicated SPOC for training and the same
conduct and support internal training
SPOCs can train the rest of the functional staff programs for CFHL for up to 30 people
members logged in concurrently
The SI shall customize syllabus for technical training, Provide comprehensive training covering all
executive training, end user training, super user functional and
22 training as per consultation with CFHL. technical aspects of the Solution to be
provided to all the individuals identified by
CFHL
The documentation should provide manuals ,
including all user and technical documents for all
functionalities / modules / tools forming part of the
23 Solution, in electronic format. In addition, provide
online help with search option to all users for all
features forming part of the solution

The selected SI shall consult with the business,

development for Analytics and Reporting purpose,
information technology, risk management,
compliance, audit and any other team from CFHL or
24 third party outsourced vendors, appointed by CFHL
for modifying, amending, editing, altering, and/or
improving and finalizing the Business Requirement
Document.
 Bidder Clarifications /
Importance Bidder Response (S/A/C/U)
Comments

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
Critical

Critical

Critical

Critical

Critical

Critical
HSM
Sheet 29: HSM

Id System Requirement

HSM is required for performing UIDAI such as e-KYC, AADHAAR Data Vault &
1 other HFC related activities. The bidder must integrate the HSM solution with CFHL
required applications & need to be integrated with other applications.
The bidder must mandatorily use Hardware based security module (HSM) for
2 encryption/decryption & digital signing of data wherever required as per the mandate

The scope of work shall broadly cover end to end implementation, commissioning,
3
testing, configuration and maintenance of the KMS/HSM.
The proposed solution must support, 99.9%. UPTIME along with 24x7x365 support
for warranty and post warranty support period.
4

It is the responsibility of the bidder to change/upgrade/customize its KMS/HSM

solution for ensuring the compliance to regulatory/statutory/supervisory/parent
5 Bank requirements at no extra cost.

The proposed solutions must be FIPS140-2 Level 3 Certified or above.

6

The bidder must ensure the high availability of the HSM solution with same level of
7 security.

The proposed solutions should support customer managed keys. i.e., it should
8 support BYOK (Bring Your Own Key).

Solution must support integration through REST API, key rotation & both Symmetric
9 and Asymmetric Key types.

Support for various cryptographic algorithms & signature modes but not limited to:
RSA (2048-4096 bits), DSA, ECDSA, Elliptic Curve Cryptography, RSA PKCS,
ECDSA with P-256, ECDSA with P-384, ECDSA with P-512, ECDSA with SECP-256k1
10

The implementation of HSM should comply with UIDAI guidelines

11

 The Aadhaar number entered in system should be validated with UIDAI systems.
12
The bidder has to ensure the integration & migration of the existing Aadhaar related
13
user information.
Index

Technical Specifications Importance Bidder Response (S/A/C/U)

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical

Critical
 Bidder
Clarifications /
Comments
DNS
Sheet 30: DNS

Response
S
A
C
U

Id

7
8
9
10

11

12

13

14
15
16

17
18
Sheet 30: DNS

Status as per RFP

Standard
Alternate available
Customization
Unavailable

System Requirement

Web Portal based access for configuration of DNS service must be provided and must be integrated with
domain services. Zone based segregation should be considered. DNS solution should have the capability of
integration with on-premise HRMS solution with could based DNS Service

DNS service must be designed for Availability and Performance

Bidder should ensure that the CSP must have the facility to whitelist CFHL IP Addresses through a Web
interface. This is to ensure that any configuration changes are done from CFHL VNET.
Facility to enable MFA for access to all the applications must be provided followed by the SSO. This will
provide additional layer of security.
Bidder should ensure that CSP should provide DNS Services with unified portal to monitor complete DNS
security related tasks like configuration and reporting.

Bidder should ensure that CSP should provide DNS solution that will be both IPv4 and IPv6 compatible
Bidder should ensure that CSP should provide dashboard which allow the manual submission of domains,
IPs, email addresses, Autonomous System Number (ASNs) and hashes.
Role based access control for DNS records Management and for DNS Security portal access
DNS service must be designed for Availability and Performance
DNS service must work on IP Anycast

DNS service must provide protection against DDoS attacks directed at DNS

Solution should have capability to provide end point detail i.e. IP address, Hostname of the system which is
sending suspicious DNS traffic.
The Solution must support the prevention from Data Exfiltration over DNS with Behavioral Analysis / DNS
Tunneling VPN
Solution should provide capability to access threat intelligence for view of relationship between domains, IP
and malware for investigation
Solution should have capability to protect Data breach/Data exfiltration protection through DNS

Solution to provide backup DNS , to have a copy of the zone data (DNS records) of the Master DNS service
The bidder should ensure that the advisories coming from regulatory bodies on time-to-time basis should be
addressed in the proposed solution
The bidder should participate in all the audits and represent the outcomes of the solution in the audits
Index

Please populate only these columns with your responses

Technical Specifications Importance

DNS solution should be a cloud Critical

native solution
The solution should support
adding the following types of Critical
DNS records: A, AAAA, MX,
CNAME, TXT, SRV, PTR
Critical

Critical

Critical

Support of IPv6 : A, AAAA, PTR,

host, ip6.arpa, DDNS records, Critical
Came
Critical
Critical
Critical
Critical
DNS attack protection, DNS
hijacking, DNS amplification,
DNS Protocol Anomaly, DNS Critical
NxDomain Attack,DNS Cache
poisoning

Critical

Critical

Critical
Critical
Critical

Critical
Critical
 Bidder Clarifications /
Bidder Response (S/A/C/U)
Comments
General Requirement Index
Sheet 31: General Requirement

Response Status as per RFP

S Standard
A Alternate available
C Customization
U Unavailable

Id System Requirement

1 Platform Dev

2 CI/CD

3 Web/Mobile
 Application Requirement

4 Integrations, API

5 Task Automation

6 Optimization
6 Optimization

7 Dashboard

8 Licensing

9 Metering

10 Billing
Cloud Enabling Functions

11 Integrations
11 Integrations

12 SAAS Features

13 Auditing

14 DLP

15 Anti-virus

16 Instance
 Please populate only these columns with your responses

Bidder Response (S/A/C/U)

Technical Specifications Importance

The Bidder should provide creation of Software Critical

Developement Plan. Critical
Bidder needs to ensure that Passwords entered are
hashed (and salted) securely with a SHA512 Critical
encryption.
Bidder needs to implement SSO based integration
with Active Directory & Multi factor authentication
support with multiple identity providers like via Critical
SAML 2.0
The proposed CFHL solution should have
Continuous Integration code pipeline for compiling Critical
testing & deployment of the code

The Bidder should ensure that the sequencing the

application deployment is inline with the integration Critical
of the applications in Target state application &
getting deployed followed by other applications
An artifact from the code to be produced which is
ready to be deployed (Continuous Delivery) by Critical
Bidder
Deploying the application to a server automatically
Critical
(Continuous Deployment)
Bidder should automate key aspects of development
in the software development ecosystem, mitigate a
large number of risks, have a quicker deployment Critical
and enable easy integration of the various systems

Every release should undergo a real device testing

which would be coordinated in between Bidder and
OEMs. The testing setup should include a large
number of real mobile devices used by the target Critical
audience. This needs to be done in co-ordination of
CFHL / CFHL appointed consultants.

Bidder needs to ensure that Mobile apps automate

the entire testing process and saves precious time Critical
depletion on manual testing.
Bidder to ensure that user feedback is converted into
enhancement requests and user story is one of the
ways developers can take advantage of the unique Critical
feedback mechanism that mobile apps offer via app
stores
API security to be embedded into every stage of the
lifecycle. This includes
PRE-PROD/PROD/DEV/SIT/UAT environment, Critical
versioning, and even the retiring of APIs
A key to securing APIs is scaling modern user
authentication and access features. A few examples Critical
include OAuth, JWT tokens, and OIDC
Bidder to use an API management platform for
automation to simplify managing policies,
authentication, authorization, redirecting, logs, and Critical
other oversight tasks
Set thresholds based on compliance requirements of
CFHL. This includes everything from restricting user
API access based on geolocation to setting up custom Critical
alerts for threat detection
API keys may not be directly embedded in the code
as exposure/sharing of the code without removing
the keys may lead to accidental exposure of the keys. Critical

API keys should not be stored in files inside the

Critical
application’s source tree
Use of API keys should be restricted (for example to
the IP addresses, verified referrer URLs, mobile apps
etc.,) to reduce the impact of a compromised API key Critical
and unnecessary needed API keys should be deleted

API keys should be regenerated periodically, and

applications should be updated to use the newly Critical
generated keys
Bidder is expected to embrace modern Software
Development Lifecycle (SDLC) methodologies such
as Agile, Scrum, and Kanban, to deliver product Critical
features, improvement, and bug fixes.
Integration of Infrastructure with CI/CD Tools
should be planned and executed by Bidder.
Necessary co-ordination is required from Cloud Critical
Provider and OEMs which needs to be ensured by
the Bidder.
Application performance monitoring with
Monitoring Tools to monitor production site, after
the deployment of the software and understand the Critical
problems, issues, improvement areas to be
implemented by SI.
Understand the scope of Application issue, either in
the architecture and/or the database by SI and Critical
accordingly take necessary actions.
Adopting best practices and standards for code like
upgradation of application code and underlying
components and maintaining versioning of that in Critical
remote repositories.
Choice of correct Infrastructure components by
Bidder as per suggestion by Consultants and offered
by Bidder which are scalable as per load of Critical
application & as per agreement with CFHL
Availability of Chart metrics and display of entries
Critical
from multiple applications to be ensured by SI
Chart metrics for multiple services & display alerting
Critical
policies
SI to manage custom dashboards and the widgets on
those dashboards by using the Dashboard resource
in the Cloud Monitoring API. API provides you with Critical
a programmatic way of managing many dashboards
at the same time
Subscription Licenses to pay month-to-month and
Critical
cancel at any time as per experience
There should be flexibility to change cloud provider
vendor or stop using the Cloud for a particular Critical
service altogether
Cloud Service Provider should offer fixed term
contract Licenses to track usage of software and Critical
services accurately
SI will cap CPU resource consumption by all services
Critical
that are deployed
For capping, SI to specify a CPU capping type (based
on Logical Partition - LPAR share percentage, service
units, number of CPUs, or Measure amount of CPU Critical
consumed per hour - MSUs) and a CPU capping
limit. 
View the metered CPU use by using the View
Metered Usage action for the tenant in the tenant's Critical
table to be in place
The Billing Cycle should be quarterly in arrears and
services to be quantified on annual Critical
subscription/utilization basis.
A Cloud Billing account should be present and must
Critical
be linked it to Cloud projects.
SI to suggest ways to optimize the resource usage
and further reduce the cost of cloud consumption Critical
periodically or as and when requested by CFHL
The Billing should be based on the actual usage on
the cloud services used as per it's metrics. This has to Critical
be as per the TCO valuation provided by SI.
SI to ensure integration of 3rd party endpoint
security to secure the host machines with offloaded Critical
antivirus, antimalware, firewall
Storage API's/API manager providing integration
with supported third-party data protection, multi- Critical
pathing and disk array solutions
Proposed solution should support integration
options to enable DevOps and Infrastructure Critical
automation
SI must follow -
Active Directory (AD) integration
Multi-tenancy model
Automated provisioning
Single Sign On
Subscription based billing
High availability Critical
Elastic Infrastructure
Data Security
Application Security
Rate limiting/QoS
Audit

CFHL must have the Access to audit logs of -

1. Information Security
2. Privacy
3. Performance & Service Management Critical
4. Web Application Firewall (WAF)
5. Any others logs as required by CFHL/ CFHL
consultants / Other regulators & Auditors.

The Bidder is expected to provide Data Leakage

Prevention solution, covering (but not limited to):
a) End points & Servers
b) Email
Critical
c) HTTP/S and FTP, Shared storages
d) Integration with SIEM
e) Analytics
f) Perform Data discovery
g) Scanned Documents
Antivirus solution should cover all the endpoints,
Critical
servers, and all the applicable devices.
Application , infrastructure, hardware, network
including data must be dedicated instance for CFHL Critical
in India only.
Bidder Clarifications /
Comments