#

1.1
1.1.1
1.1.2
1.1.3
1.1.4

1.1.5
1.1.6

1.1.7

1.1.8

1.1.9

1.1.10

1.1.11
1.1.12

1.1.13

1.1.14

1.1.15

1.1.16
1.1.16.1
1.1.17
1.1.17.1
1.1.17.2
1.1.18
1.1.18.1
1.1.18.2
1.1.18.3

1.1.18.4

1.1.18.5
1.2
1.2.1

1.2.2
1.2.3
1.2.5
1.2.5.1
1.2.5.2
1.2.5.3
1.2.5.4
1.2.5.5
1.2.6

1.2.7
1.2.7.1
1.2.7.2
1.2.7.3
1.2.9

1.2.10
1.2.11
1.2.12
1.2.14
1.2.15

1.2.16
1.2.17
1.2.18

1.2.19

1.2.20
1.2.21

1.2.22
1.3
1.3.1
1.3.1.1
1.3.1.1.1

1.3.1.1.2

1.3.1.1.3

1.3.1.1.4

1.3.1.1.5
1.3.1.1.6

1.3.1.1.7

1.3.1.1.8

1.3.1.1.9

1.3.1.1.10
1.3.1.1.11
1.3.1.2
1.3.1.2.1
1.3.1.2.2

1.3.1.2.3

1.3.1.2.4
1.3.1.2.5

1.3.1.2.6
1.3.1.2.7

1.3.1.2.8
1.3.1.2.9

1.3.1.2.10

1.3.1.2.11

1.3.1.2.12

1.3.1.2.13

1.3.1.2.14

1.3.1.3
1.3.1.3.1

1.3.1.3.2
1.3.1.3.3

1.3.1.4
1.3.1.4.1

1.3.1.4.2
1.3.1.4.3

1.3.1.4.4

1.3.1.4.5
1.3.1.5
1.3.1.5.1
1.3.1.5.2

1.3.1.5.3
1.3.1.6
1.3.1.6.1

1.3.1.6.2

1.3.1.6.3
1.3.1.6.3.1
1.3.1.6.3.2

1.3.1.6.3.3
1.3.1.6.4

1.3.1.7
1.3.1.7.1
1.3.1.7.2
1.3.1.7.3

1.3.1.8
1.3.1.8.1

1.3.1.8.1.1
1.3.1.8.1.2
 1.3.1.8.1.3
1.3.1.8.1.4
1.3.1.8.1.5
1.3.1.8.1.6
1.3.1.8.1.7
1.3.1.8.2
1.3.1.8.2.1
1.3.1.8.2.2
1.3.1.8.2.3
1.3.1.8.2.4
1.3.1.9
1.3.1.9.1
1.3.1.9.2
1.3.1.10

1.3.1.10.1

1.3.1.10.2

1.3.1.10.3

1.3.1.11
1.3.1.11.1
1.3.1.11.1.1
1.3.1.11.1.2
1.3.1.11.1.3
1.3.1.11.1.4
1.3.1.11.1.5
1.3.1.11.1.6
1.3.1.11.1.7
1.3.1.11.1.8
1.3.1.11.1.9

1.3.1.11.2

1.3.1.11.3

1.3.1.11.4

1.3.1.11.5
1.3.1.11.6
1.3.1.11.7
1.3.1.11.8

1.3.1.11.9

1.3.1.11.10
1.3.1.11.11
1.3.1.11.12

1.3.1.11.13

1.3.1.11.14

1.3.1.11.15

1.3.2
1.3.2.1
1.3.2.1.1
1.3.2.1.2
1.3.2.2
1.3.2.2.1
1.3.2.2.2
1.3.2.3
1.3.2.3.1
1.3.2.3.2
1.3.2.3.3
1.4
1.4.1
1.4.1.1
1.4.1.1.1
1.4.1.1.2
1.4.1.1.3
1.4.1.1.4
1.4.1.2
1.4.1.2.1
1.4.1.2.2
1.4.1.3
1.4.1.3.1
1.4.1.4

1.4.1.4.1

1.4.1.4.2

1.4.1.5
1.4.1.5.1

1.4.1.5.2

1.4.1.5.3

1.4.1.5.4

1.4.1.5.5

1.4.1.5.6

1.4.1.5.7

1.4.1.5.8

1.4.1.5.9
1.4.1.5.10
1.4.1.5.11

1.4.1.5.12

1.4.1.5.13

1.4.1.5.14

1.4.1.5.15

1.4.1.5.16

1.4.1.5.17

1.4.1.6
1.4.1.6.1
1.4.1.6.2
1.4.1.6.3
1.4.1.6.4
1.4.1.6.5
1.4.1.6.6

1.4.1.6.7

1.4.1.6.8
1.4.1.6.9
1.4.1.6.9.1
1.4.1.6.9.2
1.4.1.6.10

1.4.1.6.11

1.4.1.6.12

1.4.1.6.13
1.4.1.7

1.4.1.7.1

1.4.1.7.2

1.4.1.7.3

1.4.1.7.4

1.4.1.7.5

1.4.1.7.6

1.4.1.7.7

1.4.1.7.8

1.4.1.7.9

1.4.1.7.10
1.4.1.7.11
1.4.1.8
1.4.1.8.1
1.4.1.8.2
1.4.1.8.3

1.4.1.8.4

1.4.1.9

1.4.1.9.1

1.4.1.9.2
1.4.1.9.3
1.4.1.9.4
1.4.1.9.5
1.4.1.9.6
1.4.1.10

1.4.1.10.1

1.4.1.10.2

1.4.1.11

1.4.1.11.1

1.4.1.12
1.4.1.12.1
1.4.1.13
1.4.1.13.1
1.4.1.15
1.4.1.15.1

1.4.1.15.2

1.4.1.15.3
1.4.1.15.4
1.5

1.5.1

1.5.2

1.5.3
1.5.4
1.5.5

1.5.6

1.5.7

1.5.8
1.5.9
1.5.10

1.5.11

1.5.12

1.5.13
1.5.14

1.5.15
1.5.16

1.5.17

1.5.18

1.5.19

1.5.20

1.5.21

1.5.22

1.5.23

1.5.24

1.5.25

1.5.26
1.5.27
1.5.28

1.5.29

1.6
1.6.1
1.6.1.1.
1.6.1.2
1.6.1.1.

1.6.1.3

1.6.1.1.
1.6.1.4
1.6.2
1.6.2.1
1.6.2.2

1.6.2.3

1.6.2.4

1.6.2.5

1.6.2.6
1.6.3
1.6.3.1

1.6.3.2

1.6.3.3
1.7
1.7.1
1.7.1.1
1.7.1.2
1.7.1.3
1.7.1.4
1.7.1.5
1.7.1.6
1.7.1.7
1.7.1.8
1.7.1.9

1.7.1.10

1.7.1.11

1.7.1.12

1.7.1.13

1.7.1.14

1.7.1.15
1.7.2
1.7.2.1
 1.7.2.1.1

1.7.2.1.2
1.7.2.1.3

1.7.2.1.4
1.7.2.1.5

1.7.2.1.6
1.7.2.1.7

1.7.2.1.8
1.7.2.1.9

1.7.2.1.10

1.7.2.1.11
1.7.2.2
1.7.2.2.1

1.7.2.2.2

1.7.2.2.3
1.7.2.2.4

1.7.2.2.5

1.7.2.2.6

1.7.2.2.7

1.7.2.2.8
 1.7.2.2.9

1.7.2.2.10

1.7.2.2.11
1.7.2.2.12

1.7.2.2.13

1.7.2.2.14

1.7.2.2.15

1.7.2.2.16

1.7.2.2.17

1.7.2.2.18
1.8
1.8.1

1.8.1.1

1.8.1.2

1.8.3.2.

1.8.1.3

1.8.1.4
1.8.1.5
1.8.2

1.8.2.1

1.8.2.1.1
1.8.2.1.2
1.8.2.1.3
1.8.2.1.4

1.8.2.1.5

1.8.2.2
1.8.2.3
1.8.2.4

1.8.2.5

1.8.2.6

1.8.2.7

1.8.2.8

1.8.2.9
1.8.2.10
1.8.3

1.8.3.1

1.8.3.2

1.8.3.3

1.8.3.4

1.8.3.5

1.8.3.6
1.8.3.7
1.8.3.8
1.8.3.9

1.8.3.10

1.8.3.11

1.8.3.12
1.8.3.13
1.8.3.14

1.8.4

1.8.4.1

1.8.4.2

1.8.4.3

1.8.4.4
1.8.4.5

1.8.4.6

1.8.5

1.8.5.1

1.8.5.2

1.8.5.3

1.8.5.4

1.8.5.5

1.8.5.6
1.8.5.7
1.8.5
1.8.5.1
1.8.5.1.1
1.8.5.1.2
1.8.5.1.3
1.8.5.2

1.8.5.2.1

1.8.5.3

1.8.5.3.1
1.8.5.3.2

1.8.5.3.3

1.8.5.4
1.8.5.4.1
1.8.5.4.2
1.8.5.4.3
1.9
1.9.1
1.9.2
1.9.2.1
1.9.2.2
1.9.2.3
1.9.3
1.9.4
1.9.4.1
1.9.4.2
1.9.4.3
1.10
1.10.1
1.10.1.1
1.10.2
1.10.3
1.10.3.1
1.10.3.2
1.10.3.3
1.10.3.4
1.10.3.5
1.10.3.6
1.10.3.7
1.10.4
1.10.4.1
1.10.4.2
1.10.4.3
1.10.4.4
1.10.4.5
1.10.4.6
1.10.4.7
1.10.4.8
1.11
1.11.1
1.11.1.1
1.11.1.1.1
1.11.1.1.2
 1.11.1.1.3
1.11.1.1.4
1.11.1.2
1.11.1.3
1.11.1.3.1
1.11.1.3.2
1.11.1.3.3

1.11.1.5

1.11.1.6
1.11.1.6.1
1.11.1.6.2
1.11.2
1.11.2.1
1.11.3

1.11.3.1

1.11.4

1.11.4.1

1.11.5
1.11.5.1
1.11.5.2
1.11.5.3
1.11.6

1.11.6.1

1.11.7

1.11.7.1

1.11.8

1.11.8.1

1.11.9

1.11.9.1

1.12
1.12.1
1.12.1.1
1.12.1.2
1.12.1.3
1.12.1.4
1.12.1.5
1.12.1
1.12.1.1
1.12.1.2
1.12.1.3
1.12.1.4
1.13
1.13.1
1.13.2
1.13.3
1.13.4
1.13.5
REQUIREMENT
GENERAL REQUIREMENT
Ability to provide single sign-on for all modules
Ability to accommodate Centralized CIF (Customer Information File)
Ability to set mandatory and non-mandatory fields in key menus or screens without technical involvement
End of Day processing should be user defined and user enabled. IT operator should be able to invoke EOD
processing/batch processing through front end screens, without needing to update tables or call kernel
scripts.
Ability to support Multi Entity and Multi Currency in the core banking platform
Allow users to customize their own reports using the report generator, with functionalities including but not
limited to defining simple and complex calculations to be used in the report, adding additional columns in
the report which are calculated from other data, retrieving data from one or more flat files or databases, etc

Ability to add, modify and delete the approval flow and authorization matrix by configuring the New Core
System without system customization or IT involvement

Ability to accommodate log history or audit trail for tracking and monitoring purpose of each process and
transaction. The log history or audit trail should minimum contained the following information:
• Activity name being processed by the user
• User Name and User ID performing the activity
• The latest status of the process
• Timestamp

Ability to accommodate Role specific activities and duties for each role and user based on their job
responsibilities (i.e. User Access Authorization Matrix, which include the privilege granted for each roles)
including easy configuration without system customization or IT involvement

Support Calendar and Public Holidays functionality. All maintenance / update to the calendar has to be
supported on a short notice

Ability to maintain foreign exchange conversions and conventions.

Able to automatically open or accommodate user to perform system opening, and automatically process
any transaction.

Ability to ensure that there is no pending prerequisite activity before EOD process. System should also be
able to provide a warning to the user if there are failed jobs so that user can take an action to complete the
transaction (process or cancel)

Ability to automatically open the system for next day system opening process after the EOD process has
been completed.
Ability to generate MIS reports such as transfer pricing, profitability management reports, customer
insights, Asset and liability management , liquidity management reports etc.

Fiscal Year
Year end processing to be automated with minimal manual intervention
Time Zone
Time zone to be automatically controlled in the application without manual intervention.
Ability to display time zone according to international standards.
Schedule
Currency and decimal formats to be as per ISO4217 standards.
Ability to support different holiday calendars for each branch and/or Bank-wide system.
Country masters and location masters should be parameterizable such that bank can define and modify
master data without technical help.

Ability to define branch hierarchy and administration hierarchy - i.e. Bank, Head office, Branch, Extension
counters/agency branches.

Ability to automatically recalculate changed due dates and payment dates for any changes in the business
day calendar.
Interest Management
Ability to support interest calculation using user-defined rules that make it easy to create, change and
manage interest computation methods

Ability to manage interest rates and define new interest rates

Ability to define an interest rates to a products and by add criteria such as time limit, customer/account
level
Ability to support interest calculation rules, including but not restricted to:
Time-based interest calculation: daily, monthly, quarterly, six monthly, annually, end of defined period
Ability to calculate daily interest for holiday or non-working day. Apply to deposits and loan
Interest recalculation option for a previous period
Interest calculation option for a future defined period
All Interest adjustments has to post to the sub-ledger, general ledger
Support the following interest calculation methods:
- 360/360
- 360/365
- 365/360
- 365/365
- 30/365
- actual time/360
- actual time/365
- actual time/actual time

Allow multiple features to be used in the calculation of interest, including but not restricted to:
Variable tiers/bands/slab within pre-determined limits
Band/tier/slab rates by balance
Band/tier/slab rates by tenor
Support tenure pricing to be supported by the system (e.g. first period at one band/tier rate, second period
at another band/tier rate).

Ability to change base rate by account type.

Ability to setup formula for interest calculation rate plus margin rate for any defined account type.
Ability to setup formula for interest calculation for any defined account type.
Multiple reference rates should be supported (e.g. London Interbank operating rate (LIBOR) etc.)
System supports manage interest rates in min-max and for each product and sub product for every currency

Ability to prevent all product or account creation with rates that are out of the defined min-max interest
rate range
Interest rates on a product should be set or changed centrally with changes applied to all appropriate
accounts.
The system support: calculate, accrue, pre-notify (where defined), apply and report debit/credit interest
based on transactions processed up to close of business.

System has the capability to set how interest will be applied by product, customer or account. It will
determines whether accrued interest is to be applied to, or automatically waived for an account.
Allow the set up of preferential interest rate by currency and by customer and its validity period.
The system has the capability to calculate total balances for one customer or a group of customers, and
allow to revise the effecting the interest rate.

The system allows change to the date of payment of interest for a customer (the life of an account).
CUSTOMER
General characteristics
Customer attributes
Support a broad range of customer types including but not limited to:
- Group Leader/Group Member
- Minor/non minor
- Individual (e.g. Single / Joint Account)
- Corporate (e.g. sole proprietorship, partnership, single group, inc government, bank, trust, club,
association, etc)
- Guardian (e.g. parents, court appointed, etc)
- Prospect
- Mandate holder for Individual & Corporate

Support individual customer information including but not limited to:

- Title (e.g. Mr., Mrs., etc.),
- Customer name (e.g. customer long name, customer short name, customer alias, etc.)
- Identification (e.g. national ID card no., passport no., birth certificate no., etc.),
- Background (e.g. country of residence, residency status)
- Gender
- Sensitive personal information (e.g. mother's maiden name, date of birth, country of birth, etc.)
- Customer risk level/risk classification from Central Bank

Support corporate customer information, including but not limited to:

- Customer type (e.g. bank, corporate, government, etc.),
- Identification (e.g. company registration no., trade license no., etc.)

Support additional core customer information for corporations, including but not limited to:
- Business sector (in classification consistent with those used in Central Bank and credit bureau)
- Background (e.g. country of registration/incorporation, date of registration/incorporation, etc.)
- Parent company (e.g. name, ID, etc.)
- Child/subsidiary company (e.g. name, ID, etc.)
- Ownership/major shareholder details (e.g. name, ID, sharing holding, voting right, etc.)

Support contact information including but not limited to:

- Address (e.g. home, work, correspondent, etc.),
- Contact number (e.g. home, work, mobile)
- Fax number
- Email address
- Preferred contact channel (outbound)/media/time, opt-in/opt-out to direct marketing/cold calling)
Support socio-economic information including but not limited to:
- Individual (e.g. annual income, monthly salary income, spouse income, other income, etc.)
- Corporate (e.g. annual turnover, net worth, authorized capital, paid-up capital, etc.)

Support customer status such as:

- Active
- Inactive (based on customer request)
- Blocked
- Dormant [derived based on system based rules to automatically update the status]
- Blacklist check status
- Customer segment

Support demographic information including but not limited to:

- Employer/sponsor name
- Employer contact no. (e.g. home, work, mobile, fax, email, etc.)
- Sponsor contact no. (e.g. home, work, mobile, fax, email, etc.)
- Duration of employment
- Marital status (e.g. single, married, etc.)
- Parent (e.g. name, ID, etc.)
- Spouse (name, ID, etc.)

Support information regarding means of customer identity verification including but not limited to online
signature card, photograph and any other identity proof

Allow authorized user to perform customer information modification

Support relationships: Customer/group customer to facility/product/limit on a one-to-many basis
Customer data management
Support 4-eyes principle (e.g. maker/checker role) for customer information setup
Support the presentation of a complete and real time single customer view through any channels (e.g.
branch, contact centre, Internet, etc.)
Customer 360 degree view that displays the customer's relationship portfolio - all accounts that he holds
with the bank, along with average balances, net relationship value and split based on assets, liabilities,
income and expenditure for that customer.

Ability to create new fields for capturing data at customer level and account level
Support the assignment/unassignment of mandatory data fields to be captured as part of master customer
data, yet providing the flexibility to adding optional data to be captured against the customer profile

Assign and tag a relationship manager to a customer portfolio

Ability to record uploaded supporting documents and link it with respective specimen signature (e.g.
supporting document management for specimen signature) for corporate customer
Ability to deactivate specimen signature data and keep historical data changes.
Allow authorized users to capture & maintain relationships between customers & their associating
relationship with the bank, including corporate relationships and group structures
Support the identification of duplicate customer records by verifying against criteria including but not
limited to passport number ID card number, phone number, etc.
Support the automatic & manual assignment of bank officers (e.g. relationship manager, customer service
representative, etc) responsible for managing the relationship between the customer & the bank
Support the set up & maintenance of third party type (e.g. brokers, agents, etc.) and contact information
(e.g. title, name, address, telephone numbers, email address, etc.)
Support the linking of the third party to the customer / opportunity for commission calculation. For e.g.
Commission calculation based on the number of members in the group or the total principal outstanding
balance in the group member's accounts.

Support the set up & maintenance of commission calculation rules including but not limited to introducer
commission structure, split commission structure, etc.
Consolidated Statement
Support issuance of account statement as per banks standards and in PDF form that can be mailed to
mailing address.
Support statement delivery options including but not limited to mail, email, hardcopy, etc.
Support the issuance of the customer's consolidated statement in multiple frequencies such as daily,
weekly, biweekly, monthly, quarterly, half yearly, yearly, etc.
Relationship Pricing
Support the configuration of multiple pricing (multiple fees and charges) based on customer segment or
other predefined criteria

Allow the authorized user to perform override on the pricing (waiver) for specific customer
Support combination of Fixed pricing or variable pricing and a combination of fixed and percentage based
pricing for every charge type.
Support segment based pricing - i.e. preferential and segment based pricing to support members belonging
to a particular segment or a demography.

Provide a detailed report of the various pricing charged on a customer, waived on a customer.
Customer Accounts Structure/Codification
The System must support a Flexible Customer ID Structure, that is easily able to identify and configure by
the bank.
Provide flexibility and options for the bank, to migrate the existing customer numbers as is, and also to
provide a Old to New mapping that will allow new account records to be created with the new logic and
algorithm, and a mapping prevails between old and new account number for better customer experience.

Configurable account number structure.

Customer Information Creation
Ability to create CIF by batch when importing customer lists from external files into the system. Ability to
check and notify duplications if any.

Ability to automatically check, alert and prevent it from being opened when a CIF is created without
approval or agreement of HO in the case that customer and the blacklist or restricted list have some
information in common.
Ability to link CIF and sales staff as follows:
CIF must be mapped only to effective sales staff and such CIF needs some prerequisites before
mapping
Only one sales staff per CIF

Sales staff mapping can be adjusted

Have the flexibility to define the minimum and maximum number of characters when creating and adding
new customer information fields.

Customer Profile Maintenance

The system should have the ability to prompt and notify users and customers of the customer's incomplete
data.
Ability to automatically check, and alert when there is a query of blacklist, or restricted customer list.
When there is a query of customer information, the system has ability to automatically integrate with other
modules, calculate (if necessary and the calculation can be adjusted manually on demand) and display such
information such as: last transaction date, currently used products etc.

Corporate Customer Relationship

The system should at a minimum, be able to automatically verify, store and prompt alerts for the following
customer relationships and create customer relationship information, including but not limited to:
Customer to customer/customer group
Customer to account
 Customer to facility relationships
Customer to business
Customer to officer in charge
Customer to Relationship Officer
Customer to corporate clients/government agencies
The system has the ability to store and link corporate customer relationship information, including but not
limitedCompany
to: owner's information (shareholders, information of company share, cross-share), number of
staff
Affiliates' information
Customer segment of the corporate customer
Other information (e.g. financial, non-financial information)
Field management
Ability to define customer information fields as mandatory or optional
Ability the Bank customises and defines maximum field length of defined fields
Storing
Ability to close/delete the CIF and to combine and store automatically and effectively for all the modules.

Ability to store all history of changed information (e.g. change of address, company, salary etc.).

Ability to store information of customers that have transactions with the Bank but do not yet have accounts
in the Bank.

Customer Enquiry
Allow searching for customers by the single or multiple following criteria, including but not limited to:
CIF
Customer name (full name, short name, English name)
Customer address, telephone number, fax, email
Account number, card number, card used
ID number/business registration number/tax code
Company name
Spouse, parent or children name
Number of staff of the corporate entity
Relevant customer group
The system should support wild card search or search name based on few literals

The system should be able to store transaction information of non-account and non-insurance policy
holders
The system should be able to automatically flag up customers if the customer is no longer tied to any
accounts after a user-defined period of time.

Ability to look up customers on the blacklist and on other lists (such as the State bank’s list and internal list).
Ability to limit access and extraction of information for each CIF.
Ability to query all history of changed information (e.g. change address, company, salary etc.)
Ability to query missing verification requirements and related reasons.
Ability to manage, extract customer verification information and allow it to be used based on the Bank's
authority hierarchy level overall in the system.

Verification that information is stored as mandatory, optional or additional for each account.
Ability to manage signatures by group and/or credit limit.
Ability to list specimen signatures of existing accounts in CIF.
Ability to query upcoming expired date of signatures, ID numbers, valuable papers base on time range
chosen by the Bank.

Ability to manage customer verification information as a standard function in CIF and information can be
queried from any transaction screen.

Ability to support checklist of verification requirement that user check the completeness of checking
documents and input reason for lacking document if any

Offline banking
Customer creation
Ability to support creation of individual customers through offline
Ability to support maintenance of customer data through offline banking
Lending
Ability to disburse loan accounts through offline banking
Ability to collect repayments through offline banking
General
Ability to create Savings account and deposit accounts through offline banking
Maintenance of accounts and deposits through offline banking
Ability to top up and close deposit accounts
ACCOUNTS
Account & Transaction
Interest Bearing
Savings account - Group Leader
Savings Account - Group Member
Premium savings account
Current Account - Interest Bearing
Non Interest Bearing
Current account
Current account in Foreign Currency
Fixed Deposit
Term Deposits in VND currency
Account Attribute

Ability to record administrative data and business parameter setting to be used in the transaction (activated
based on predetermined activation date), including but not limited to:
• Management of product/ service with relevant predefined properties such as tax and fee, interest rate/
remuneration, and minimum balance;
• Formula configuration (e.g. interest calculation formula, etc);
• Transaction code;
• Blocking Fund;
• Operational calendar & window time;
• Capture various account attributes that are defined at the account level or the product level
Ability to choose following option while setting transaction fee and tax component in Product/ Service
Master Data:
• Fee can be set as fixed rate or proportional rate (by %);
• Set maximum/ minimum fee and tax;
Account Opening
Provide guided/automated procedure or workflow to support the end-to-end corporate/consumer deposit
account origination process including maker-checker role

Support for multiple account holders to the account (joint account arrangements) and multiple account
officers/signatories to the account (corporate accounts)
Ability to validate data input including but not limited to:
• Data format
• Mandatory field;
• Data duplication based on combined primary keys and
• Supporting document’s date validity.

Support the application to be forwarded to approver for approval.

Ability to receive approval or rejection from reviewer. For rejection, system should be able to accommodate
reviewer to set fields need to be revised and record its rejection reason.

Allow authorized users to carry out KYC/Embargo/AML blacklist checks on new (& existing) customer
(without requiring the users to manually re-enter the customer's information)

Ability to upload and record the supporting documents of customer registration data (e.g. signature
specimen, etc) and link it to respective CIF

Ability to accommodate customer-defined authority of the specimen owner such as

- Group A --> minimum of 2-3 of predetermined signature should exist to withdraw the money
- Group B --> any one of the predetermined signature should exist to withdraw the money

Allow authorized users to trigger the issuance of cheque book for customer segments (e.g. corporate,
business, premium, retail), i.e. to be issued instantly, etc.
Ability to create deposit account
Ability to establish and maintain customer limit management
Support 4-eye principle for approving account setting creation or amendment, for passbook, cheque book
issuance, etc.
Support standard and special Fee and Charges rates management per customer segment, per product,
services (e.g. statement printing, card replacement, etc), transaction, region, account level with tiered
pricing table
Support interest types including but not limited to fixed, floating (against index rate for different months),
margin, caps/collars/floors, simple, compound, stepped (introductory period), penalty, etc.
Support standard and special Interest rates management per customer segment, per product, account level
with tiered pricing table
Support various interest calculation methods including but not limited to act/360, act/365, etc. as well as
net, gross, tiered, etc.
Support the notification regarding eligibility of having different account for minor customer once they
reached 18 years old
Maintenance
Ability to update and maintain accounts.
Ability to identify, update and maintain account relationships.
Ability to allow full auto migration of products.
Ability to manage the capture and maintenance of nominated beneficiary details.
Ability to manage the creation, maintenance and termination of accounts for all existing products.
Ability to display account status.
Ability to automatically calculate and post interest accrued, interest payable and fees of deposit products on
daily basis and display the estimations of these amounts in a specific time in future.

The system should allow issue, replacement and update of passbooks.

The system should be able to define account criteria, including but not limited to:
Inactive
Dormant
Ability to monitor and automatically change accounts into inactive status if no transaction occurs after a
user-predefined period.

The system supports the automatic closure of an account after a stipulated time (six months, one year, etc.
This time is defined by user) upon approval by authorised personnel.

The system should be able to auto reactivate a dormant account after a customer performs certain
transactions to verify.

Ability to automatically transfer interest of account types when customer changes account's activities
Account Servicing
Ability to lock/unlock account to prevent transactions and to capture its reasons (e.g. court order, etc), as
well as perform card locks/validity dates management, and locking specific transactions (by currency or
amounts)
For Fixed Deposit accounts, allow authorized users to specify:
- The linked account from where the fund is to be provided to the Fixed Deposit account upon confirmation
of the opening of the account
- The linked account to where the matured principal/interest will be paid out upon maturity/early
termination

For Fixed Deposit accounts, support the early termination of fixed deposit arrangement and support the
penalty calculation to be automated for early termination of Fixed Deposit Account
Allow authorized users to trigger the ordering of additional cheque book(s)
Support issuance of deposit statement containing summary and breakdown of information on transactions,
providing information including but not limited to posting date, value date, fixed description text for the
transaction type, variable description text to outline the details of the transaction, currency, amount, etc.,
i.e. initiated / executed by the system, & by the customer

Supporting time driven deposit account statement generation option at frequencies including but not
limited to daily, weekly, biweekly, monthly, quarterly, half yearly, yearly, etc.

Support same day (real time) account block / closure process when requested by the customer or
automatically when the fixed term deposit reaches maturity & that renewal / rollover has not been
requested

Ability to automatically validate the balance position (including interest calculation) for respective account
and notify the user when the account to be closed still has remaining balance, so that user can take
necessary action (e.g. . cashed out the remaining balance + interest, etc). (Please state notification medium,
e.g. email, text messaging, task dashboard, etc.)

Ability to change account and service status to "inactive/closed" and prevent reactivation after an account is
deactivated/closed. Customer need to initiate new account and service request if customer wants to reopen
similar account.
Support diary functionality containing future events (e.g. statements, deposit maturities, etc)
Support generation of Government Payment Order and Gift Cheque based on customer request
Account Closure
The system must allow closure of accounts automatically or manually in accordance with the Bank's policies
The system should allow auto calculation of interest upon account closure.
The system should handle maintenance of closed account records and deletion of records based on
specified
Ability to rules.
notify any outstanding charges/fees/cheque book/standing instructions/auto debit etc. at the
time of account closure.

Blocking
Ability to allow users to block entire or partial balance of an account or block an amount that is higher than
the account balance. Interest on the blocked balance amount may or may not be calculated depending on
the Bank's guidelines.
Ability to define ‘from’ and ‘to’ date for the block or hold.
Ability to define multiple blocks with the appropriate reason/interest rate codes mentioned above.
Ability to block a c credit transaction.
Ability to block a debit transaction.
Ability to define prohibited transactions of an account.
Transactions
The system should be able to process various type of deposit transaction such as original opening/
additional placement/withdrawals.

The system supports interest withdrawal date/withdrawal of partial amount of principal/entire principal and
the corresponding amounts. The Bidder is to describe this in detail.

Sweep In-Out/Auto Fund Transfer

Ability to support the transfer of funds from and to multiple accounts (CA, SA, FD, loan, etc.) with
conditions on interest, fees, amount, time, priority, etc. defined by user.

Interest Payment:
Ability to calculate interest and pay arisen interest on accounts bearing periodic interests.
Transfer of ownership
The system supports the transfer of ownership among deposit accounts.
Statement, Notification and Alert
The system must provide all requirements for manual and auto-generated statements, notifications and
alerts.
Ability to notice for updates of next required steps to complete transactions/activities to the customer or
user on related interfaces (customer interface and user interface)

Ability to track non-performing accounts functionalities such as tagging, notification, alerts and reporting.
Ability to allow messages to be inserted in statements based on customer segment/group e.g. marketing
messages.
BRANCH OPERATIONS
The System must have ability to support all bank teller and branch operational support services including
cash/cheque deposit, withdrawal and branch automation modules, ability to support all retail /consumer
banking, corporate banking and mortgage finance.

The System must support 24-hours x 7 days x 12 months non-stop continuous processing

The System must be multi-branch

The System must be multi-currency
The System must be Relationship-based and/or Customer-based
The System must allow one or more branches to post transactions for next day after closing the system for
the day. These transactions must be treated by the host as next day’s transactions.

The System must have ability to capture all the details on the deposit voucher: account
name, account number, narration, amount in figures and words, date, depositor’s name etc.
The System must have ability to capture cash denomination details
The System must have ability to support agency banking deposits transactions.
The System must have ability to automate receipt printing for cash deposits
The System must have ability to display/ show relevant customer verification information
on-line e.g. signature, images, Customer photograph

The System must have ability to update and display updated account balances immediately
after every posting

The System must have ability to waive / exempt charges with appropriate user access levels
The System must have ability to allow tellers to view cash transfers on screen

The System must have ability to waive / exempt charges with appropriate user access levels
The System must have ability to generate a report on cash deposits over a given period of time, amounts etc
The System must have ability to show customer photograph and other identification details on screen upon
calling the account.

The System must have ability to support image recognition or thumb print recognition or any other
biometric capabilities for identification

The System must have ability to allow a teller to post withdrawal amounts into customer accounts
The System must have ability to check if the amount being withdrawn is within the teller limit for
withdrawal

The System must have ability to trigger an alert to branch manager/supervisor for approval if withdrawal is
above a teller limit.

The System must have ability to allow for the branch manager/supervisor to document reasons for not
approving withdrawal request above a teller limit
The System must have ability to send alert to customer on any withdrawal or activity on his account through
SMS, email etc.
The System must have ability to set minimum balance per account type
The System must have ability to generate an alert if a payment will result in account balance being below
the set minimum

The System must have ability to generate a report on list of withdrawal transactions
The System must have ability to allow online request and approvals of cash float
The System must have ability to capture cash float details e.g. teller number, amount, time of request etc
The alternative channels (e.g. ATMs, POS, Internet/mobile banking etc) must be available during End of day
processing

TELLER
General Requirements
System provides interface for operations of all modules: CIF, deposit, loan, payments and remittance
System allows to define levels of authorization.
System allows user entitlement flexibly.
Transaction limits and cash limits should be assigned to each teller or each cashier role, and transactions
should be governed based on these limit definitions.

System allows to flexibly decentralize limit to each user by each transaction type
System allows to manage daily transactions of each user, group of users or each operational unit.
Cash management
Ability to manage and record cash by currency type and denomination.
Ability to process loose amount.
Ability to maintain cash balances and manage cash limits separately for vault and tellers.

Ability to sell/buy foreign currency by cash and determine exchange rate as defined by the bank.
Ability to provide report such as cash proofing report that displays the position of cash in that branch, split
denomination wise.

Ability to compare between cash denomination and transaction amount.

Inquiry and reports
System allows users to query transaction logs in multiple criteria.
System allows to generate and export reports flexibly upon to input data sources, fully support types of
report for reconciliation, inventory and administration such as list of transactions by types, summary report,
reconciliation report… by each user/whole branch.

System should allow printing of cash statements and reports as specified by the State bank of Vietnam.
TRANSACTIONS
Transactions-Related Requirements
Ability to show the current balance and available balance before processing a transaction.
Ability to show both account balance and clear balance,
Ability to manage number of days of back and forward value dating of transactions
Ability to post back dated transactions.
Ability to define the rules for back dated transaction.
Ability to re-calculate all the balance positions, charges/fees and interest for a back dated transaction.
Ability to open and closed accounting period in order to process a transaction
Ability to define a type of transactions that are allowed back dated function.
Ability to do adjustment entry on an accounting entry that was automatically generated by the system.
Ability to not allow tellers, supervisors, and supervising levels to approve transactions related to themselves
or customers having relationship with them

Ability to alert and prevent tellers or supervisors from performing/approving transactions when there are
on holidays
Ability to list detailed information for a transactions including but not restricted to: occurring time,
customers, business groups, tellers, supervising level, location, terminal ID that created the transactions
Ability to store all information related to a transaction, including but not restricted to: transaction entity
(receiver, sender, …), place of transaction, transaction channel, transaction fee, commission amount,
products, related accounts, entry person, approval person, transaction time, etc.

Ability to support linking transaction-related information, including but not restricted to: transaction
entities (borrower/lender/commission fee recipient, etc.), transaction fees, commission fees, products,
related accounts, etc.
Ability to create an reversal of transaction
Fund Transfer
Local Remittance
For every customer transaction, system should be able to validate based on the following parameters:
- Account number;
- Insufficient Balance;
- Exchange Rate availability (for cross-currency transaction);
- Blocking Fund; and
- Blocking account

Support transactions using local or foreign currency

Ability to accommodate book transfer transaction, including but not limited to:
1. Balance transfer between customer’s account (in same currency or cross-currency);
2. Auto debit/ direct debit transaction; and
3. Inter-branch transfer.

Ability to perform cross-currency transaction using predefined exchange rate that has been set in the
system.
Ability to accommodate authorized user in the branch to adjust the exchange rate within certain range for
specific transaction.
The system can trigger approval flow if the adjustment is more than certain range.
Support triggering of necessary financial postings including but not limited to deduction of fees, accrual of
interest, transfer of funds, etc. from fixed-term deposit account to linked or designated current/ savings
account, block/lock on unused cheques, etc. as part of account closure process.

Support integration with external system of LPS for making domestic transfers.
Ability to transfer the requested amount to destination account (customer account/ suspense account) and
post multi currency journal including but not limited to:
1. Transaction Journal
2. Transaction Fee journal

Ability to automatically calculate transaction fee based on predefined parameter (e.g. region type,
percentage based on fund transfer amount)

Ability to generate exception report regarding pending transaction

International Remittance (Telegraphic Transfer)
Support Cross border funds transfer through SWIFT
Support capability to capture International Remittance data including but not limited to:
• Source account;
• Beneficiary personal information (Beneficiary name, address, state, country, contact number etc.);
• Beneficiary account;
• SWIFT Code;
• Corresponding Bank information (Bank name, state, country, etc.);
• Transaction amount; etc.

Support setting up of Nostro and correspondent banking information

Ability to perform cross-currency transaction using predefined exchange rate that has been set in the
system.
Ability to accommodate authorized user in the branch to adjust the exchange rate within certain range for
specific transaction.

Support SWIFT messaging outgoing and incoming as per SWIFT 2018 standards
Ability to validate data input during outward remittance request, including but not limited to:
• Data format (e.g. SWIFT Code, contact number, etc);
• Mandatory field;
• SWIFT code availability (If CBS connected host-to host with SWIFT); and
• Supporting document’s date validity.

Ability to validate suspicious transaction based on sanction list/ black list and predefined suspicious
transaction criteria (if any). If the transaction marked as suspicious transaction, system will suspend the
transaction and notify the authorized user.

Ability to allow authorized user to approve or reject the suspend transaction.

Ability to generate SWIFT message including but not limited to MT103 (Single Customer Credit Transfer),
MT202(General Financial Institution Transfer), MT940 (Customer Statement Message), MT950(Statement
Message), MTn99 (Free Format Message), etc.

Ability to send the SWIFT through SWIFT terminal directly to the corresponding bank (Straight Through
Processing). When there is any unusual event during validation in SWIFT terminal, the system will notify
user to provide approval.

Ability to receive acknowledgement from SWIFT regarding the transaction status (e.g. success/ failed).
Support multi-level approval for both transaction data and SWIFT Message (checker-maker).
Ability to process inward transaction message from SWIFT and automatically validate the incoming message
(e.g. match the data in MT103 / MT202 with data in MT900/ MT910/ MT940/ MT950). System also should
be able to store SWIFT supporting information message (e.g.MTn99).

Allow user to verify transaction data before credit customer's account. During verification by authorized
user, system should be able to post the transaction into suspend account.
Ability to accommodate generation of SWIFT Message for the following :
- Transaction cancelation
- Transaction confirmation; and
- Follow up

Ability to transfer the requested amount to destination account (customer account/ suspense account) and
post multi currency journal including but not limited to:
1. Transaction Journal
2. Transaction Fee journal

Ability to automatically calculate transaction fee based on predefined parameter (e.g. region type,
percentage based on fund transfer amount)

Ability to generate summarized and/or detailed reports regarding international remittance.

GENERAL LEDGER
POLICY/GENERAL REQUIREMENTS
The GL must be a module that is integrated in the core banking solution, rather than a separate system that
is outside the core banking solution.

The Bidder is to describe the overall GL structure in the proposed core banking solution, describing the
functions in detail, including but not limited to:

Conventional GL functions including creating/inputting dual entries, checking, posting and saving to
ledger and creating financial reports

Should be able to update entries and manage off-balance sheet accounts. Should be able to reconcile
between off-balance sheet and on-balance sheet accounts and with other related modules.

Should provide maximum support for automatic entries to minimize manual recording.
Ability to record off balance sheet when there is a difference in foreign exchange rate between HO and
branch.
Accounting
The System must support at least Assets, Liabilities, Income, Expenses and off balance sheet Accounts

System must have provision to type GL names with 50 characters

GLs should be pre-fixed with Cost Centre codes
System should be capable of supporting 7-digit number in line with the current Chart of Accounts (CoA).
GL should clearly be designed to allow either electronic, manual or both types of transaction
GL Types:
Income - to include interest, rental, revaluation gain, other income.
Expense - to include staff costs, administration, general, extra ordinary expenses.
Assets - to include cash, placements, other assets, salary advances, B/materials, F/loans, Mortgage,
Investments, Investment properties, property & equipment.
Liability - to include depositor’s funds, deposits from other financial institution, other liability, Loans from
other F/Is, revolving fund.

The System must produce at least a Daily Trial Balance, a Balance Sheet and a Profit and Loss Statement.
The System must support multiple accounts levels
The System must support multi-currency accounts
Cost Centre
- The system must allow for creation of cost Centre/branch.
- Ability to remove redundant Cost Centre/branch.
- Ability to support creation of 3-digit cost Centre code to allow for expansion

Transaction Processing
- The System must support account balance restriction e.g. Zero, Debit only, Credit only etc.
- Bulk transaction processing - Ability to do electronic processing of journals/ cashbooks
- Capturing of transaction details - Ability to capture detail of a transaction at point of posting i.e.,
cheque number, payee and reason for paying
- Post journal restriction - Ability to restrict manual transactions when posting to electronic GL
- System should prompt user to confirm if they are sure with what they would like to post.

The System must enable performance monitoring and reporting

The System must support back/Forward-value-dated voucher entry with a facility to restrict the period of
back and forward valued transactions through a parameter.
The System must support revaluation of currency
The System must show all zero balance accounts in GL.
Balance sheet
Balances of loan accounts must be grouped into separate balance sheet items depending on customer
classification, product type, maturity code, credit grade etc.

Support the online / real time postings for online / real time financial events
Support the ability to apply different accrual methods for different events including but not limited to
accrue immediately for full amount, accrue over time based upon straight line formula, accrue over time
based upon alternate formulas, accrue at end of contract expiry, accrue at contract cancellation, etc.

Support the ability to apply different accrual periods, including but not limited to daily, weekly, monthly, 4
weekly, quarterly, etc.

Support the option to forward or backward accrue. For non-working days, support the ability to either
calculate accruals the day before for the day after, or to calculate accruals the day after for the day before

Support handling of back dated entries

Support balance checking during the GL posting
Supporting manual postings/adjustments
Support 4-eyes principle (maker/checker) for General Ledger postings/GL accounts maintenance
Support the ability for every entry in the core banking application (e.g. transactions, interest, fees &
charges) to be clearly assigned to the corresponding GL accounts

Support the execution of end of period closures & associated accruals including but not limited to end of
day, end of week, end of month, end of year, etc.
Support GL account validations and control based on Chart of Account segments, etc.
Assist bank in setting up GL chart of accounts and migrate the existing GL accounts to the new GL charter.
Allow the ability to have real time online GL. Any transaction posted to customer account should be able to
effect the underlying GL account real time and online, without having to wait till EOD for GL build.

Reporting
Support the reporting of general ledger at views/levels including but not limited to bank, country, branch,
business unit, business segment, business sub-segment, acquisition/service channel, product category,
product type, transaction type, etc.

Support the generation of a range of exception reports to help identify/monitor exceptions arising & cause
of such exceptions

Support the generation of a range of standard audit/accounting reports including but not limited to trial
balance, P&L statement, balance sheet, etc.

Support drill down of the report by customer classification, product type, etc.
Allow authorized users to view account balances in the general ledger
Support authorized users to retrieve & review reports structured in predefined format to meet the required
Central Bank's monthly/semiannual/annual regulatory reporting requirement, including but not limited to:
- Consolidated Trial Balance
- Consolidated Detail Trial
- Domestic Consolidated Trial
- Cash In Hand Position
- Cash Flow
- Financial Position
- Daily Progressive
- Deposit Position

Reconciliation
Allow authorized users to create/manage suspense accounts for various purposes (e.g. expense, petty cash,
reconciliation, etc)

Allow authorized users to review outstanding clearing & settlement totals in multiple currencies & reconcile
these with counterparties information

Allow authorized users to view balances & transactions held within suspense accounts
Allow authorized users to search for debit / credit postings within suspense account based upon user-
defined criteria (e.g. posting date, settlement date, amount, reference number, etc.)

Support the automatic assignment of a unique reference number to every transaction / posting in the
suspense accounts to facilitate matching & reconciliation
Support authorized users to post comments / additional references to the entry to the suspense account
Support the generation of suspense account balance reports
PROCESS/FUNCTIONS
Accounting Entry Input
Allow the processing of automatically reversal entries, standby entries, and recurring entries.
Ability to support the upload function for online posting instead of posting entry by entry.
Ability to calculate and report on the average balance of GL accounts on a daily, weekly or monthly basis.
End of Quarter, End of Year
Ability to allow user to define the accounting policies for closing, transferring of accounting books at year
end or end of fiscal year. The Bidder should describe this in detail.

Financial Control
Ability to control and monitor transactions posted to suspense accounts. The system should alert the user
on pending amounts, transactions.
Items posted to suspense account must be processed properly before EOD

For posted items the option of carrying additional text narration for cross reference purposes and the
addition of purpose or reason codes and phrases should be available.

COMPLIANCE
Ability to comply with rules including but not limited to the following:
Vietnamese accounting principles, standards and regulations
Vietnamese banking accounting rules and regulations
END OF DAY PROCESSING
Features of the system that allows staffs to run EOD separately for each branch
Features of the system to run EOD, EOM and EOY by staffs:
• At one time for all branches automatically
• Branch by branch phases
• Module/ EOD batch wise
Ability of the system to run offline while EOD runs at the back
Features of the system that prohibit EOD processes unless the following are done:
• Unauthorized transactions get authorized or deleted
• All users are logged out of the system
• Relevant batches are closed
STANDING INSTRUCTIONS
Features of the system that allows staffs to define standing instructions with
• Both customer accounts and General Ledger accounts
Flexibility of the system to define
Ability of the system to define standing instructions for the following frequencies:
• Daily
• Weekly
• Fortnightly
• Monthly
• Quarterly
• Half Yearly
• Yearly
Flexibility of the system to define standing instructions with the following parameters/ features:
• By assigned to Start/End of Day operations

• To be user revocable
• To have start date and expiry date for instructions
• To temporarily suspending of standing instructions
• To carry forward of failed instructions till ‘N’ times

• To define charges for acceptance, failure, success of standing instructions

• Charges can be debited from an account which is different from the standing instruction debit account
• Conditions such as fixed/ percentage/ variable definable for each standing instruction
REPORTS
General Requirements of Internal Reporting
Please describe briefly the Reporting system used to define and design the following reports
Management Report
Regulatory Report ( for State Management Bodies)
 Ad Hoc Report
Ability to generate reporting in the currency of choice (local currency, base currency or currency of
choice).
The system provides a database to support extracting information and reports as required.
Provide tools for designing reports, and enable the Bank to customize the report interface including but not
limitedSet
to:up reporting information

Assign reports for each menu, screen of each module, etc.

Assign the assessing authority of reports for multi different levels
Allow the Bank to drill down into the information within the report easily.

Allow the Bank to generate and review reports in multiple file formats, including but not limited to:
Acrobat reader (.pdf)
Excel (.xls)
Deposit Reporting
Provide reports related to Deposits held by customers in bank's along with maturity information, interest
information
Overseas Remittance Reporting
Report of the details of remittances of international nature made during a specific time period, with an
option to select and choose results based on filter criteria.

VND Settlement Reporting

Report of all the domestic remittances initiated during a specific timer period, with an option to select and
choose results based on filter criteria.

Transaction Office Reporting

Transaction check list printing and reports
List of all transactions initiated by a teller or branch user
List of exception transactions initiated by a branch or a branch user.
Customer Reporting (provided to customer)

Ability to generate reports specifically for Account & Transaction, including but not limited to:
• Balance confirmation
• Debit/Credit advice
• Customer’s bank statement in original currency and MMK equivalent
• Customized report with agreed format and content according to business needs

Bank Reporting
Ability to generate reports specifically for Account & Transaction, including but not limited to:
• Report of administrative data and business parameter history
• Report of transaction
• Customized report with agreed format and content according to business needs

Regulatory Reporting

Ability to generate reports specifically for Account & Transaction, including but not limited to:
• Daily position across all products per branch
• Book value (bank cash from cash transaction at the branch)
• Clean cash (including clearing, transfer, cash, etc)
• Customized report with agreed format and content according to business needs

CIF Reporting
Reports related to new customers opened, customer details and other details that could help relationship
manager take conscious decisions on product offering.
Internet and Mobile banking
Internet banking
Ability to initate funds transfers, basic account modifications and bill payments through internet banking
Ability to maintain the added beneficiaries (add, modify and delete) through internet banking
Ability to maintain the list of billers available for the customers through an admin module
Ability to view the account statement/disbursement summary/repayment summary.
Ability to download historical statements for each account or for all the accounts available for the customer.
Mobile banking
Ability to initate funds transfers, basic account modifications and bill payments through mobile banking
Ability to maintain the added beneficiaries (add, modify and delete) through mobile banking
Ability to maintain the list of billers available for the customers through an admin module
Ability to view the account statement/disbursement summary/repayment summary.
Reporting and Dashboard
Ability of the system to allow the bank to configure reports and dashboards without depending on the
vendor
Ability of the system to support in configuration of adhoc reports.
Ability of the system to spool data from multiple systems and use the data for reporting, customer
segmentation etc. to support in predictive analysis
Ability of the system
Ability of the system to generate role based dash boards and reports
Response
Detail description
# REQUIREMENT
1.1. Loans
1.1.1 Origination
1.1.1.2 Application search
Support search based on the critical following fields such as
1. Application Id or Passport Number or any other national ID
2. First Name, Middle name, Last name or name in native language
3. Person who recorded the application
4. Application status

1.1.1.3 Application Creation

Support for multiple types of loans for individuals, Small and
medium enterprise (SME), Corporate customers :1. System should
support initiation of loan applications for fresh loans as well as for
loan modifications (term extension, limit extension, rescheduling,
change in interest rates)
Customer Search :1. System should support to search customers with
the CIF id during application processing.
2. Allows the user to search against the customer database
maintained in the system or within the bank data base or core
banking system.
3. If no matches are found, then the system facilitates and mandates
creation of a Customer Information File (CIF), at the time of
application entry.

Multiple applicants to application :1. System should supports

multiple applicants, each with varying capacities and roles.
2. There should be a minimum of one applicant in the role of a
borrower.
3. Applicant types should be definable in the system as per the
business needs.
4 System should support to capture various details across personal,
employment and address details.

Process identification based on product attributes :1. The Origination

system should facilitate to defining different process flows for each
super product, product and credit scheme.
2. Process flow to product attribute mapping should be configurable
in the system.

Applicant details capture :1. System should support capturing the

personal, address and employment details for every applicant.
2. System should support capturingthe family members' name and
national id, and their relation to the applicant.
3. Address Types - Office, Residence, Mailing (Address types are
configurable)
4. Feature to record details (name, address and national id) of 2
references.

Asset details capture :1. System should support capturing the asset
type, location, status of the asset, FMV and the valuation currency
and the o/s loan commitment against each asset.
Liability details :System should support to records Liability Type,
Originating FI, Liability amount, estimated monthly commitment,
adjusted monthly commitment.

Income Details :System should support capturing records income

source and currency, income frequency and the amount

Expense Details :System should support capturing Expense type,

amount and the applicable currency

Collateral capture :1. System should support capturing the details of

the primary collateral that would be linked to the loan account.
2. System should support to Integrated with the Collateral module for
creation/selection of an asset as a collateral

Support for Multiple collaterals types :1. System should support

capture of multiple collateral types for the same application
2. System should support in capturing detailed collateral related
information like collateral type, location, status of the asset, FMV and
the valuation currency and the o/s loan commitment against each
asset.
3. System should support collaterals to be defined as sharable and
non- sharable collaterals
4. System should support restriction of collateral to a single credit line
5. System should support collateralization of assets while collateral
creation
6. Capture of collateral specific information
6. The following asset types can be collateralized (Can be configured)
1. Fixed Deposit
2. Guarantee
3. Pledge / hypothecation
4. Mortgage
5. Lien on stock and bad debts
6. Security Cheques
7. Vehicle

Single collateral supporting multiple applications :Collateral ids

should be allowed to be linked to multiple applications subject to the
sum total of percent of utilization of the underlying asset(s) not
exceeding 100%
Application edit prior to contracting :System should allow
modifications to applications before the contract is finalized.

Limit set up :System should support to set up multiple credit limits for
each entity in an application

Limit set up :System should support to create a group and add

multiple entities under it for monitoring the exposure.

Limit set up :System should allow user to attach a collateral and

secure a line.

Limit set up :System should allow partial or full collateralization of

limits.
Deduplication
 Internal Dedupe function :1. Dedupe should be done for all the
parties to the application.
2. Search strings should be derived from the applicant data, after
applying a series of formula/computations on the same
3. More than one applicant data can be merged together to build a
search string.
4. Deduplication should be an auto stage process.
5. User should have a provision to view the results and either select a
probable match or overide the system results and create a new
customer CIF with justification.

1.1.1.5 Credit Approval

Objective Credit Policy Checks :1. System should be able to auto
compute the policies based on defined business rules
2. Credit Policy rules should be configured using the Rules Engine
module.
3. Policy evaluation should be automatically done by the system.
4. Policy check should be re-executed at different stages depending
the user requirement.
5. Different Policies for different products should be configurable in
the system.

History of credit policy changes :The Origination system should

maintain a history of all changes in the policy evaluation results, as a
result of iterations and various modifications to the applications

LTV & PTI Calculation :1. Loan To Value (LTV) and Payment To Income
(PTI) computations should be done as a part of the Credit Score
transaction.
2. Computation logic should be configurable through the Rules
Engine module.
Credit Scoring :1. System driven.
2. Credit Scoring rules should be configured using the Rules Engine
module.
3. Score computation is automatically done by the system.
4. Credit scoring should be done at different stages of an application
for a product and different products should have different scoring
sheets at the will of the user
5. It should also be possible to integrate system with an external
credit scoring application if required.

System recommended loan amounts :System recommended loan

amount should be computed by the system.

Existing Asset & Liability view :1. Details of all assets and liabilities
that have been recorded during the data entry stage, should be
available as a link in the decision screens.

Negative List Results :It should be possible to view negative list during
underwriting and credit scoring

Credit Bureau Results :It should be possible to integrate with a Credit

Bureau through a web-service interface
Loan Terms and conditions review :1. The edit offer link in the credit
decisioning stage provides the facility to edit or modify the terms and
conditions for the loan to be approved.
2. This feature of the Origination system provides a concise view of
the loan amount requested, loan tenure, rate of interest, repayment
frequency and mode of repayment.

Repayment Schedule generation :1. Repayment schedule should be

simulated during decisioning and underwriting stages.
2. System should support generation various repayment schedules like
equated, varying dates and amounts, Balloon payments etc.

Edit Data Entry :1. The Origination should system supports the credit
team’s decision to send back an application for correction of terms or
addition/deletion of applicants.
2. The bank team should also edit the application details and proceed
with decisioning.

Refresh of Scoring, Policy, LTV & Profit to income (PTI) calculation :1.
The user should manually initiate re-computation of scoring and
policy evaluation, from the decisioning stages, using the 'Redo Score
and Policy evaluation, as and when data is changed by using Edit data

Document collection :1. should be updated at any stage of

application processing.
2. Checklist should be different for each applishouldt type.
3. System mandates collection of mandatory documents to proceed
with contracting.

Verification
Rule based Verification Grid Marking :Verification and grid marking
rules configured in Rules Engine

Grid level marking at application level :The user should be able to

override and waive verifications that have been marked for an
application, through the grid marking process

Agency Allocation :1. Rules for agency allocation can be configured

using the Rules Engine module.
2. The user can select one of the shortlisted agencies and assign the
verification for that application, to that agency.

Sourcing details capture :1. Records the dealer who has sourced the
application, the loan purpose and the sourcing channel.
2. Loan purpose and Sourcing channel should be defined based on
business needs, at the time of implementation

Underwriting
System Recommendation :Compute the recommended loan amount
for every application, based on the rules configured in Rules Engine.
User override :Override of the system recommended limit should be
done by the credit approver.
Multiple levels of approvals :1. System currently supports any
number of level of underwriting.
2. Deviation entry level for underwriting is configured in the Rules
Engine
3. Approval from the entry level moves the application to Contracting
stage.
4. System also supports a recommend feature to escalate the
application to the next level of underwriting.

Approve, Decline, Cancel, and reinitiate credit approval. :1. The user
should either approver or shouldcel or reject or push back an
application to the credit approval stage.
2. The reasons for the decisions of the approval from underwriter
should be recorded
3. The system provides a maintainable list of decision linked reason
codes, at each stage of decision making. The user should select one
or more reason codes as applicable.

Approval history :All decision screens display the decision history and
comments provided by the earlier decision makers.

Approval Authority Matrix :Business Rules Engine is used to configure

the underwriting delegation matrix.

Application Referrals :1. System also supports a recommend feature

to escalate the application to the next level of underwriting.

Committee Approval :System should support Committee approval of

loans by forming a committee of approvers

Delegation :System should support to deligate the approval to other

deligated approvers for a defined time based on maintenance
Reject
Reject Review Queue :1. Reject review queue displays the decision
history.
2. The user should be able to select the mode of reject reason for
communication.
Restart from Reject :1. Restart move the application to the credit
approval stage.

Contracting and Disbursal

Approval for contracting :Contracting is the final stage of application
processing in Origination. Approval at this stage hands off the details
to the Lending system for disbursal.

Disbursal handoff :Should trigger disbursal of loan amount once all

approval and contracting process is complete.

Master Maintenances
Document Master :1. Document codes are assigned to various
documents.
2. Each document should be classified as either as an income proof
or address proof or as an ID proof.
Document Group :1. Different documents should be grouped
together for a given combination of super product, product, customer
type, applishouldt type and loan scheme.
2. For each document added to a group, the collection mode (copy,
original) and the collection frequency is defined.
3. The system also allows to define mandatory and optional
documents within the group scope.
4. The system generated the document collection checklist based on
this grouping.

General Parameter :A separate master should be available to maintain

the LOV for various field elements. These include applicant type,
payment frequency, credit decisions,

Agency Allocation :1. System shortlists an agent by following a round-

robin allocation logic.
2. The user should be able to override the system allocation in the
Pre-CPV stage

Negative list maintenance :It should be possible to maintain a

negative list on the origination system.

Also system should support integration into external negative list

providers if necessary

Document Management & Imaging and Notepad

Document checklist generation :1. System generates separate
document checklist for each applicant type.
2. Document checklist generation is based the document group
maintenance done for a given product and applicant type.

Document Receipt :The user marks a document as collected, there by

acknowledging receipt of a document.

Document Waiver :System should support to mandate collection of

mandatory document and allow waiver of optional documents

Document Deferral :1. When the user defers a document, the system
mandates the deferred date to be entered.
2. Collection of a document can be deferred to a date marked as
deferred date.

Additional document :1. Documents that are not a part of the

checklist but have still been collected, should be allowed to be
recorded under the additional documents section.
2. The user should be able to add any number of additional
documents.

Mandatory & Optional classification for documents

:Mandatory and optional classification is defined at the time of
document grouping. The same is reflected in the collection checklist
generated for every application.
Upload of document images :There is a separate link for document
upload. This is available from the document collection checklist and
also independently, as a link in the page header at every stage.
Document image view :View image link is found in the document
collection checklist and also as a link in the page header at every
stage.
Customer Advice Generation
Advice Templates :It should be possible to generate various contracts
and advices through the application. The application should support
configuration of the appropriate communication templates.

Advice communication :The System supports the following

communication modes
1. E-Mail
2. FAX
3. SMS

MIS Reports
MIS Reports :1. MIS Reports can be configured to suit the business
needs, using the Reports tool.
2. The report output should be in any one of the following formats
a) CSV
b) HTML
c) PDF

Data Handoffs :1. System to support configuring reports as data hand

off files
2. The handoff would be in a CSV format.

Process Configuration
Business Process Setup :1. Workflow is used to configure the business
process.
2. The process studio is a graphics based canvas where the user
should be able to configure various stages of a business and sequence
the same.
Parallel Processing :Workflow should support parallel processing
wherein an application should be processed across more than one
stage of activity
Access Control :Stage level access restrictions should be allowed to be
configured.

Version control :All versions of a process must be available for

viewing, at any given point of time.

Maker Checker facility :Any modification done in the Workflow, should

come into effect only after the same has been authorized. The maker
and authorizer cannot be the same.

Utilities
Notes - Add :Additional comments and observation, should be
allowed to be recorded at every stage, by each user.

View Notes :1. Comments and observations recorded by each user at

each stage of application processing is tagged with the application id.
2. Such recordings can be viewed by all users at all stages.

TAT Summary :This is available as a link at all stages of application

processing. The elapsed time at each stage is displayed. The summary
includes stages where system has processed the application without
any manual intervention.
 General
2.1.1 Single Loan Application to process single multiple
Facilities/borrowers (Funded & Non- Funded). Types of facility to be
configurable.
2.1.1.1 Solution should facilitate upload of information through batch files
containing the application details.

The fields to be captured should be country specific. It should be

possible to add or remove fields based on any other specific
attributes in the application such as type of facilities/ securities/
pricing / workflow etc.
User definable rules for scoring, de-dupe, eligibility, customer
exceptions, workflow movement, etc. using rule builder.

The system should provide ability to Record all user activities with
audit trail.

Referencing on the basis of defined rules.

2.1.1.2
Capture the financial data of the customer both current and
projections, as needed. Equity / capital details, Credit facility
sanctioned/availed by/ from other Banks/institutions, profit and loss
statements, balance sheet statements, projected cash flows etc

Due diligence/ compliance checks through interface

Workflow & Allocation

Further, there should be a queuing system that has the capability to
allocate based on preset logic. Approver level can be defined as single
approver or multiple approvers.

2.1.1.3 Process of approval may have defined sequential and parallel

movement. It should be possible to have both in workflow
simultaneously.
Parameter/Role based allocation of workflow items.
Fast track processing. Solution should provide a feature whereby a
single user (duly designated) to process an application from start to
finish or may have limited access to a specific task.

Ability to reallocate or reassign cases from one user to another.

2.1.1.4 Multiple to & fro movement of work items possible. Comprehensive
Reports for workflow.

The queuing feature should include the ability for escalation to higher
supervising authority in case the application has remained pending
without any activity for a specified period.

Ability to have workflows for credit lines based on the current process
of the Bank. Interact dynamically between the rules engine and the
queuing process to move across queues based on process results at
each stage of credit processing
– Example: risk based verification process resulting in instant approval
or based on potential credit limit
 Assignments queue to credit officers who can cover such limits.

System should have provision of maker checker facility for different

activities like data entry, documents, approval based on risk segment.
However this may be defined by administrator.

Ability to allocate automatically to each user based on role and also to

a pool/ team so that the available users can select case to work on if
needed.
2.1.1.5 Ability to define external agencies and their users like Direct Selling
Agency (DSA), Data Management Agency (DMA), dealers, Bank Mitra,
valuation agencies, Law Firms, verification agencies etc.

Ability to allocate relevant cases to these external agencies and give

controlled access to work or give them facility to upload their reports

Application Input and Tracking

Ability to capture customer details like:
‒ Borrower Information
‒ Personal information
‒ Loan Application details etc.
Capture financial & non-financial details for Organization inclusive but
not limited to type of customers like organization name, registration
details, constitution, address etc.

1. Date of appraisal initiation.

2.Registering the application details in a user defined format
3.Company master data 4.Customer Follow Up reports 5.Write Up
Details
a. Company Financials
b. Board Details
c. Background information
d. Key Business risks & mitigation
e. Comments on Industry
f. Key Financials Comments
g. Facility Details
h. Pricing Details
i. Security Details
j. Standard Terms &Conditions
k. Rating results (obligor & facility rating)
l. Financial ratios and calculation from rating input/output sheets
m. Document checklist
(The list is illustrative only and input parameters fully in line with the
Banks appraisal formats to be built during the customization stage).

Ability to input varied loan application scenarios (e.g. varied loan

amount, repayment terms, pricing etc.) for customer and view the
implications/ outcome of the scenarios to front office team/ agents/
officer.
2.1.1.6 Should provide a space to provide additional information that may be
relevant in making credit decision e.g. number of bounced
instruments, failed standing orders, window dressing of accounts
issues, Credit summation vis-à-vis sales.
System should support Qualitative Data Extraction (QDE), Dynamic
Data Extraction (DDE) and checking of the data for any corrections
extensively so as to ensure integrity of data.

System should have facility to validate the data being entered with
validations like mandatory/ non- mandatory, format validations etc.

Must generate a unique loan number for every

loan application and the application enquiry should be possible on
specific keys definable parameter.

The unique loan number generated should be easy to trace by the

various users who may wish to track the application. For example: can
be queried by inputting customer's id no, name or business
registration number.
Credit Evaluation / Rating
‒ Interface with Internal/ External credit rating system for borrowers.
‒ Capabilities for scoring parameters based assessment abilities in
case of schematic
lending. ‒ should provide flexibility in defining credit scoring rules/
policies with different multiple combinations and base criteria,
provide online credit scoring processing with auto approvals.

The product should have a scoring engine that is capable of credit

scoring across demographic and bureau variables with ability to
handle multiple
score cards across products and segments. Amendment of credit
scoring parameters to suit particular purposes.

Ability to key in financial data and use the same for scoring.
Ability to interface with third party external credit rating systems and
use the same for defining different paths of the workflow or in
internal scoring engine real time or in batches

Ability to interface with multiple credit bureaus and use the results of
same in scoring.

Eligibility
Ability to define the customer eligibility rules based on different
parameters.
Ability to arrive at eligible loan amount for a customer based on these
rules and data entered for application.
System should support financial analysis based on parameters like :-
‒ Turnover
‒ Liquidity
‒ Profitability
‒ Leverage
‒ Debt Service Coverage ratios
‒ Balance sheet and Profit and Loss analysis
‒ Cash flow and fund-flow analysis
‒ Ratio Analysis as per ratio formulae given by the Bank etc.

Analysis
 System should support definition of standard formats for financial
data and statements like Balance sheet, Cash Flow statement, P&L
account, and Funds flow statements. Definition of financial structures
based key parameters like Industry segment, customer type etc.

Structures can be defined for various financial statements like Balance

sheet, Cash Flow statement, P&L account, Funds flow statements etc.

System should capture any Number of years for which the financial
projections/ cash flow/ loan
/covenants data can be recorded & processed.

The system should capture remarks (with replies) of latest internal/

external auditors (concurrent, statutory, stock audit, etc.), first site
inspections. It should also support capturing of text comments along
with capturing of remarks and irregularities pertaining to the account
in the Bank’s monthly / quarterly monitoring reports.

Standard analysis of financials using basic analytics/ratio.

Project appraisal
Standard & customized project appraisal tool & processes.
Building up/ importing/ assessing various financials & business
models and other appraisal requirements of project funding.
Verification Management
Ability to generate different verifications for customer based on his
application and evaluation process.

Allocate verifications like phone, income, personal, address etc. to

user/agencies.

Ability to initiate and do field investigations.

Ability to capture details and documents related to each verification.
2.1.1.7 Credit Approval
Ability to define the sanctioning authority based loan size, product
etc. Ability to have a multi-level sanctioning matrix and automatic
routing of the case based on that.

The system should aid credit decision making based on the proposal
evaluation analysis and credit risk rating. It should facilitate users/
reviewers in understanding assessments through electronic case files.

Ability to allow authorized personnel to override System credit

approval or rejection recommendations but with an audit trail that
can be tracked.
Ability to route the case for committee approval in case of higher loan
amounts.

Ability to generate Credit Appraisal report

System should provide for definition of the minimum requirements
for one to qualify for a credit facility generally and within each stage.

Ability to allow reviewing personnel to view defined sets of

information/ comments on each credit request.
 Ability to view the application data in a summarized form to
take credit action.

2.1.1.8 Exception Handling

Ability to add certain actions/conditions if the application is not fully
up to the mark for approval like addition of co-borrower, collateral
etc.
Ability re-routing the case to an appropriate officer in case of any
changes or amendments to be made.

Ability to automatically reroute the case in case of any data change

based on which the approval was done.
Ability to reject the application with reasons. The system should allow
review of rejected applications through a screen that includes the
reason for rejection.

Ability to review rejected applications for reopening in special cases.

Facility to recommend an application if it is not in users approving
authority
The system should facilitate archival of rejected applications for de-
dup purposes.

2.1.1.9 Once an application for credit is closed, it should not be possible to

change the data, except for certain non-critical fields.

The system should have a mechanism that cancels an application if it

is pending for more than a specified number of days after follow-up
for missing documents/ information.

The system should have override options whereby an earlier rejection

or cancellation can be revoked and the application be brought back
into the mainstream for positive closure.

Output Format : Loan proposal, Loan offer letter & documents

Generate offer letter & Loan Documents for customer.

Allow printing of approval / rejection letter in desired format.
Ability to view the status of applications under process Stage wise,
branch wise and user wise.

2.1.1.10 The system should support creation of sanction advice with the
following details (but not limited to):
‒ Customer details
‒ Product details
‒ Classification of loan / sector code
 ‒ Purpose of the sanctioned loan
‒ Terms and conditions of the sanction amount (rate of interest
including any additional charges applicable)
‒ Period of sanction or tenure of loan ‒
Payment terms of interest, margin etc.
‒ Credit rating
‒ Repayment schedules
‒ Moratorium period
‒ Renewal details (where applicable)
‒ Charges to be created with appropriate authorities
‒ Guarantees
‒ Insurance details
‒Documentation and legal formalities to be executed

Customer correspondence, including reminder letters, etc.

automatically generated by the system in accordance with defined
parameters.
Appraisal Note
System to have the capability to show a snap shot view of the entire
appraisal.

Loan Account Management

Ability to generate the following types of repayment schedules
Equated Montly/Qaurterly/Half yearly /Annual Installments
Bullet type of repayment
Balloon type of repayment
Inrregular repayment scheduels with varying dates
Inrregular repayment scheduels with varying dates and varying
amounts
Step /Step down
Due Generation
2.1.1.11 Is generated based on the EMI schedule
a. Due will be created on the date of EMI of each loan. Due
amount will include the following:

o Principal amount
o Interest accrued in the previous month
2.1.1.12 b. Accounting entry will be generated on the date of due creation
Repayment Management
System should support repayment by the follwwing modes
Over the counter by cash
Instrument
Electronic payments
Status Tracker
Ability to track status of the loan to the following. These statuses can
only be modified by the authorized personnel.
o Active
o Closed
o Written off
 Collateral Management
Business will record most collateral information during the origination
o System should have ability to update information that was
previously entered during the origination phase or enter additional
collateral information

o User access to this information to be limited based on

role/designation
o Reportsin case any applicable collateral validity is expiring
o Ability to manage release of collateral through the maker/checker
concept
o Ability to manage replacement of collateral through the
maker/checker concept

Customer Service
a. Service Requests (examples below)
o Foreclosure/Early settlement
3.1.1
1. Key business requirements include:
3.1.1.1 · System should provide the facility to close the loan before
maturity period

· System should provide the facility to calculate the total

receivable amount at any point of time.

3.1.1.2 · System should provide the facility to simulate scenarios with

various closure-related parameters, only applicable for current and
future dates.
· There should be facility to generate simulation reports for
calculations for the foreclosure.

· There should be a facility to enter foreclosure reasons. These

reasons populate in a list from a master, which is user definable.

· There should be a provision to capture notepad details after

closure of loan.

3.1.1.3 · System should allow operator to override the early termination

fee that has been calculated. Should have option of waiver.

· There should be a facility to terminate a loan when the due

against the loan is within a defined threshold amount.

The customer is given different options or scenarios by generating

combinations of the variables and one of these is finally agreed upon
and frozen as the “closure terms”.
3.1.1.4 The scenario agreed upon is reported in the form of a “foreclosure
letter ” which shows the following:
· Date of generating the letter
· Date of effective closure chosen for calculations
· Customer Name
· Product
· Loan Account No
· Principal Outstanding
· Overdue Instalments (if any)
· Late payment or bounce charges (if applicable)
3.1.1.5 · Interest for the period from the last due date to closure date
· Closure Charges (%)
 · Closure Charges (value)
· Net Amount payable for closure
· Validity date of the foreclosure amount

3.1.1.6 o WAIVER
1. In Case business wants to waive fees / charges for customer,
system should provide functionality to waive with defined delegation
matrix
2. System should have audit trail of waiver

Interest Accruals
a. There should a provision to accrue the interest on daily basis.
b. Computation of accrued income should be done on Actual/360
method where the difference in actual days will be taken in
consideration. Days in a year should be considered as 360 days.

c. For leap year, system should calculate interest computation

based on 360 days. Interest accruals would still occur on a daily basis
(including 29th February).

d. Accounting Requirements:
o System is required to post accounting entry of interest accruals on a
daily basis.

3.1.1.7 o Accounting should be posted on portfolio level and not on individual

loan level

Rescheduling and Deferment

Loan reschedulements, which could be instances of customers
seeking to change the loan parameters in respect of the following:

o Principal Reduction (Part Prepayment)

o Due Dates
o Tenure Change
o EMI Change
EMI Deferral

Payment Allocation
3.1.1.8 The company would receive various payments through the different
channels. These payments would need to be allocated to the various
dues existing against a particular Loan, with defined priorities for each
type of due.

o From a system perspective, funds should be allocated to the dues

only after the funds are actually realized. Any payment, which is still in
process of realization, should not be allocated to the dues.

o The allocation priority shouild be definable at the loan product

level
o Application of Allocation Priority to received funds should
automatically happen upon upload of the information files.
 o No manual allocation to be allowed for manual receipts also.
Allocation to be set to auto with no override allowed.

o Every month during the billing process, dues would be raised for
the instalment amount, PDC amount. In the event of the contract
having an excess payment against it, funds from the excess amount
would get allocated towards the dues as per the allocation priority.

Bucketing
3.1.1.9 The accounting entries related to a contract changes when a contract
becomes delinquent, depending upon the level of delinquency. Also,
contracts would need to be classified into different classes based on
the delinquency level/extent. This classification of contracts/accounts
is termed bucketing Classification.

o At due date + 1, if there is any outstanding amount in installment

component (P&I component), then the account would be stated as
delinquent. System should increase the DPD counter of the account
moving onwards until the overdue installment is paid

§ LPP Grace days = 3 days (Calendar Days)

§ DPD (Days Past Due) counter shall start from the date of due.
§ Collection extract to treat a case as delinquent only after “3”
number of days.

o Bucketing Movement
3.1.1.10 § When loan is charged off, system would need to generate the
appropriate charge off GL entries as specified in accounting policy

o System should start income recognition (both from fees, interest

accrual, and amortization) in suspense account when account reached
90+ delinquency.

o When account cures below 90DPD, system would then continue to

recognize income as usual. Suspended income earlier would need to
be recognized as normal income.

o When account reaches 180 DPD, system must perform charge off on
the following accounting entries:

§ Income (fees, interest income) would be booked in charge-off GL

§ Unearned amortization would need to be earned upon chargeoff
3.1.1.11
Account Statement
o System should support in generating account statement at
account level and facility/loan level

o A fee may be charged to generate account statement which will

be a defined amount

Limit Setup
Ability to define facility types (details, product restrictions)
Ability to handle the following Customer-Facility relationships-1
customer, 1 facility,-multiple customers, 1 facility,-1 customer ,
multiple facilities,-multiple customers, multiple facilities

Ability to support multi-tier facilities of more than 3-levels.

Able to maintain the following information per customer
Approved Amount (currency and amount)
Member/s (can be more than 1)
Customer number and name
Approved Limit (currency and amount)
Collateral assignment, can be more than 1
Collateral pool ID - should be defined in Collateral Management
System
Ability to maintain Single Borrower's Limit per customer
Ability to support multi-currency
A Limit of a customer can be sub-divided into sub-limits. The total
outstanding of the sub-limits of the next level cannot be more than
the limits of the higher level.

Member's limit should not exceed the customer's (parent) limit

Limit Utilisation
Must be able to convert the transaction amount to currency of
approved limit

Ability to accept or reject transaction and send appropriate message

to the source application after validation

Ability to update the balances of the correct facility as the transaction

happens
Ability to capture the transaction date when the line exceeded limit

Debt Management

Host Data Extraction

Batch upload of files from Loan management system
User Maintenance
User Hierarchy definition - Multiple level support
User information capture - Demographic information of each User
with information such as Maximum Load and entitlements for
downloading information

Agency user mapping - Mapping Collectors and the Agency they work
for
Management of Portfolio
Relationship view of customer
Single View of customer
Portfolio Segmentation & Work Allocation
User definable queries for the segmentation (Queuing). Product
based strategies

Product - such as Personal finance, Home Loans

Queuing based on customer attributes such as VIP, Skip, Fraud, Legal
and so on
Account attributes - Buckets, Overdue amount, Outstanding amount,
installment date and so on

Special attributes - Broken Promise, Cheque return and so on

A combination of all of these attributes
A hierarchy of Queues to avoid conflict - to avoid one account falling
in multiple Queues when they satisfy multiple Queue logic

Difficulty index definition for each Queue for Load balancing based on
the perceived difficulty

Allocation of Queues - Beginning of day - Back end process

Attaching Queues to Agencies according to skill sets
Assigning Queues to Collectors under respective Agencies - Dynamic
movement of accounts satisfying a Queue logic
Assigning Queues to a pool of Collectors under an Agency
Reassigning Queues to another Collector / another Agency -
escalation for effectiveness during operation

Reassigning accounts to Collector / another Agency - escalation for

effectiveness during operation

Action based prioritization for follow up - Beginning of day Back end

process

Rule (algorithm) based work list generation for the day, from actions
such as promise to pay, broken promise, cheque return, no follow-
Call back,
up
Fresh accounts where follow up is yet to begin
Work Prioritization
Action code priority for calling
By products

Account priority within the action code groups by products

Classification Process
Special handling for designated customer such as VIP, business
partner etc.
- By amount range
- By delinquent days range (segment collection by days)
The criteria setting for determine the classification parameter which
can set up the new criteria of delinquent days range (the number of
overdue days) in each buckets.

The working Queue within the classification by System parameter

setting as flexible parameter setting for example:
- The amount of overdue installment in each buckets
- The number of overdue periods in each buckets etc.

The classification of accounts by billing/ statement cycle for low level

dunning on mild delinquent accounts
- By delinquent days range (segment collection by days)
- By segment
- By amount range
Account under litigation recovery
- By delinquent days range (segment collection by days)
- By segment
- By amount range

Classify collection accounts into geo-regional collection branches/

centers for better customer immediacy and turnaround

Account attributed such as setup of the classification

- Product of combination of products
- Amount Due
- Nationality, due date delinquent days
- Billing/ Statement cycle
- Total Loan
- Geo-regional branched or centers
- Open date/ Relationship since
- Utilization of credit limit/line
- Other criteria ……

The dunning letters (reminder letter, terminate letter) / collection

notice should be generated by the automatically and/or manual
which depend on the classification of delinquent accounts such as
overdue 1 period, overdue 2 periods etc.

The solution should have the facility to define function codes.

Accounts will be classified into homogenous groups based on the
function codes to facilitate collection efforts.

Movement of accounts should be governed by:

• State Processors – which route accounts across functions based on
the parameters detailed in the location parameter table
• State Assignment – these are rules based on which accounts are
routed/rerouted on a daily basis to the states in which they are to be
worked

Due Follow-up
Outbound Calling
Calling from the prioritized worklist of a Queue
Automatic pop up(Relationship screen) of accounts from the worklist
in the set priority

Provision to capture follow up trails (actions - such as promise to pay,

call back etc.) to the customer accounts

Provision to attach attributes such as Skip, Disputes, Legal, Employee

etc. for segmentation and allocation

Referring accounts to fellow Collectors for help/advice

Routing (escalating) accounts to Supervisor in case of difficulty
Field Referrals
Statcard generation
Contents definable by product
Sorting by a field (Location / area)
Generation by Agency
Generation by Collector
Legal Recourse
Identification by rules - Queue strategy
Referral to Legal by
Collector
Customer action
Action result
Allocation of Legal accounts to Legal officer
Reports & Dashboards
Bucket flow reports
Detailed with drill down into the accounts
Summary with drill down into the accounts
Portfolio trend reports - with definable sections or cuts
Aging report
Advocate monitoring report
Collection efficiency report
Collector Productivity report
Reference Area General Description
Requirements
General
1 Requirements
General Multi-Currency handling
2 Requirements
General Automatic generation of Ref no for amendments
3 Requirements
General Foreign Exchange support
4 Requirements
General Support levels authorization
5 Requirements
General Recording liability
6 Requirements Warnings for incoherent information
7 Letter of Credit

The system should have the ability to handle different types of

Documentary credit such as:
• Sight Letter of credit (LC)
• Usuance LC
• Negotiation
• Confirmed LC
• Unconfirmed LC
• Back to Back
• Transferrable LC
Letters of Credit • Revolving (Cumulative and noncumulative)
8 (LC)
The system should be able to process trade finance transactions
throughout their life-cycle - from the customer's initial
Letters of Credit application, through issue and payment, up to the time when the
9 (LC) transaction expires and the records are removed from the
system.
Letters of Credit system should support quick /short logging of the events ( for eg
10 (LC) LC issuance or documents received etc.)
Sytem should support Credit Limit Checking module like
authorizer can review the details of the customer's credit line
Letters of Credit utilisation, and decide whether to approve or reject the
11 (LC)
Letters of Credit associated event.
The system should have the ability to process both local and
12 (LC)
Letters of Credit foreign currency LCs.
The system should have the ability to create and allocate unique
13 (LC)
LC reference numbers.
Letters of Credit The system should enable authorized users to amend the terms
14 (LC) including expiry dates of the LCs.
For LCs where partial remittances have been made, the system
Letters of Credit should have the ability to track the unutilized balances in real
15 (LC) time.
Ability to provide for data to be inputted for the creation of a
letter of credit. Data could include but is not restricted to the
following:
Customer Account Number
Customer reference number
Currency of L/C
Letter of credit opening date
Expiry date
Shipment details
Letters of Credit Advising bank name
16 (LC)
Letters of Credit Preload special instructions to be displayed to the user in a
17 (LC) ‘special instructions’ text field/screen…etc
 Preload special ‘bank to bank’. instructions that must be
Letters of Credit displayed to the user (i.e.: instructions from BANK to a counter-
18 (LC) party bank that will be displayed on swift messages).
Is a user able to create a documentary credit of a parent
Letters of Credit Documentary Credit (e.g.: on a back to back or transferable
19 (LC) credit).
Functionality required includes the ability manage an import
Documentary Credit through the instruments lifecycle with
regards to:
Documentary Credit issuance
Amendments
Payments
Letters of Credit Cancellations
20 (LC) Queries etc
The user shall have the flexibility either to automatically assign
Letters of Credit advising banks or to maintain list ( drop down) of advising banks
21 (LC) from which the user can select and assign.
Generate appropriate SWIFT message types: MT700, MT701,
MT705, MT707, MT710, MT711, MT720, MT721, and sends to
Letters of Credit SWIFT Alliance Entry modification, Verification, Authorization or
22 (LC)
Letters of Credit Ready-to-send queue as per the end-user’s requirement
23 of Credit Provision to send notification of discrepancies
(LC)
Letters
24 of Credit Discrepancies via SWIFT
(LC)
Letters
25 (LC) Register beneficiary response to discrepancies
Letters of Credit Ability to retrieve an existing Export L/C record and issue one or
26 (LC) multiple Import L/Cs against it (Back-to-Back).

Letters of Credit Ability to cross-reference, inquire and view Back to Back L/C
27 (LC) records (Import and Export) during processing.
Letters of Credit
Provide outstanding report of Back to Back L/Cs with
28 (LC)
outstanding documents.
29 LC Payment
Ability to retrieve L/C Details from the system on the basis of
30 Payment of LC
reference number
31 Payment of LC Ability to input payment details in the system
32 Payment of LC Ability to allow part payments for the LC
Ability to input details of charges / expenses, correspondent
33 Payment of LC bank charges, commission etc., if applicable
Ability to automatically convert rate masters Charges /
Commission into the relevant currency utilizing the applicable
34 Payment of LC rate
Ability to override system generated rates with Supervisory
35 Payment of LC
approval
36 Payment of LC Allow for early payment or late payment.
Ability to support mixed payment terms and allow processing in
37 Payment of LC
any order
Option to deduct fees from principal or collect it separately from
38 Payment of LC
a different account.
Allow processing of payments after the L/C has expired but
39 Payment of LC
within the grace period.
40 Payment of LC Ability to finance/discount
41 Payment of LC Support various confirmation commitments
42 Payment of LC Allow multiple drawings under the same L/C.
43 LC Ammendment
Amendments to System to prohibit making amendments to any L/C that has been
44 Letter of Credit closed in the system
 Amendments to Ability to retrieve L/C Details from the system on the basis of
45 Letter of Credit reference number
Amendments to Ability to amend details of the L/C in the system in the permitted
46 Letter of Credit fields
Amendments to In the case of an increase in L/C amount system should have the
47 Letter of Credit ability to validate sufficiency of balance / limit
Amendments to Ability to print the amended Letter of Credit in the standard
48 Letter of Credit format
LC
Cancellation/Clos
49 ing
Cancellation/Clos
ing of a Letter of Ability to cancel Letter of Credit in the system
50 Credit
Cancellation/Clos
ing of a Letter of Where the L/C amount has been fully paid / no outstanding
51 Credit balance, the system to automatically close the Letter of Credit
Cancellation/Clos
ing of a Letter of Ability to capture reason for cancellation
52 Credit
Cancellation/Clos
ing of a Letter of Ability to input cancellation request of Letter of Credit in the
53 Credit system on receipt of confirmation from the Advising Bank
Cancellation/Clos
ing of a Letter of Ability to review cancellation details and return it to the data
54 Credit entry personnel for modifications, if required
Cancellation/Clos The ability to automatically change the status of a documentary
ing of a Letter of credit to ‘Closed’ after a specified grace period has lapsed after
55 Credit
Cancellation/Clos expiry / maturity date.
ing of a Letter of The ability to reverse all outstanding liabilities on deactivation
56 Credit and process all financial entries in this regard.
Cancellation/Clos The ability to produce reports showing which transactions are
ing of a Letter of about to deactivate in xxx days time, and which are due to
57 Credit
Cancellation/Clos deactivate on the day.
ing of a Letter of Ability to deactivate or close after the expiry date and give
58 Credit suitable reports
59 Transferable LC
To capture Export L/C and record transfer particulars such as ,
transfer reference no., date of transfer, amount, name of L/C
issuing Bank, name of beneficiary, name of Local Bank through
60 Transferable LC which transfer be affected etc.
To transfer full amount or a part of the amount to
single/different second beneficiary, if Export L/C is transferable,
61 Transferable LC under intimation to L/C issuing Bank
To customize cover letters based on the user needs and
62 Transferable LC
requirements
Documentary
63 Collection
 Functionality required includes the ability to manage an import
documentary collection through the full life cycle of the
instrument with reference to:
Lodging
Avalising
Managing acceptance
Amending
Managing payments
Sending of tracers or queries
Documentary Cancelling
64 Collection
Documentary Does the solution cater for the processing of Documentary,
65 Collection Direct and Clean collections?

Documentary Are users able to create collections by copying from a previously

66 Collection captured collection?

Documentary Is the capture process fully compliant with the URC522 – ICC
67 Collection rules for collections?
Does the solution cater for the capturing, modifying or deleting
Documentary of all terms and conditions relating to the collection as provided
68 Collection in the schedule received?
Documentary Financial and Tenor information (including maturity date
69 Collection calculations)

Documentary Information regarding when the docs were sighted and any
70 Collection special conditions.

Documentary Specify who the bearer of the fee/charges will be

71 Collection
Documentary Transport information (e.g.: consignors, transport document
72 Collection information)

Documentary Document information

73 Collection
Does the solution provide the necessary functionality to record
Documentary and process an acceptance under the collection? (Describe what
74 Collection is available in this regard).
Documentary Can a user capture special attributes relating to the collection?
75 Collection
Documentary whether to release documents on acceptance or payment,
76 Collection
Documentary whether to waive charges
77 Collection
Documentary whether to collect or waive interest and the % interest that must
78 Collection be collected

Documentary whether to apply a discount and the % discount that must be

79 Collection applied

Documentary Does the solution cater for the computation and collection of
80 Collection interest and discounts on a collection – to what extent?
 Functionality required includes the ability manage an export
Documentary Collection through the full lifecycle of the
instrument with regards to:
Establishments
Amendments
Acceptances
Payments
Cancellations/discharge
Documentary
queries/tracers
81 Collection
Does the solution cater for the processing of Export
Documentary Collections? Please provide information on the
Documentary offering available and the types of export collections are
82 Collection
Commission/Cha available with baseline.
83 rges
Commission/Cha
The system should have the ability to vary fees and commissions
84 rges
on LCs.
Commission/Cha The system should have the ability to automatically charge fees
85 rges and commissions in real time.

Commission/Cha The system should have the ability to generate advices for
86 rges letters of credit in bank defined format.
Commission/Cha
Commission & charges should have option to be realized
87 rges
periodically
Commission/Cha To compute and collect percentage based charges on the full
88 rges exposure period of the transaction, where applicable?

Commission/Cha Is there ability to compute and levy minimum and maximum

89 rges fees/charges per interval period over the full exposure period?

Commission/Cha Does the solution cater for the “holding” of fees (i.e.: compute
90 rges the fee amount but only collection the fees at a later date).
Commission/Cha
Can minimum and maximum fee/charge amounts be calculated
91 rges
and levied?
Is there capability to differentiate between different types of
Commission/Cha fees levied e.g.: differentiate between a commission and a
92 rges
Commission/Cha charge (e.g.; for tax purposes)?
Are there capabilities to distinguish between our fees/charges
93 rges
and those of another bank?
Is a user able to collect “foreign bank / other bank charges”
using the solution? Can these also be collected after release of a
Commission/Cha transaction, but be maintained as part of the transaction’s
94 rges history?
Commission/Cha Can fees/charges be waived or deleted and if so, are these
95 rges recorded for audit and MIS purposes?
Commission/Cha
96 rges
Commission/Cha Can event driven fees/charges be levied?
97 rges Does the system support amortization of charges / fees?
98 Margin
Calculate and realise cash Margin from Customer’s accounts as
99 Margin per sanction terms and pass entries.
100 Margin Issue intimation/ advice to Customer on Margin realised.
Allow the user to take additional margin over initial margin
101 Margin
already
Allow thetaken
user to release/refund the Margin to the customer
102 Margin
with approval
For foreign Guarantee- there should be options to keep margin
103 Margin in multi currency against an account
104 Margin To pass necessary entries to realize margin.
105 Limits
106 Limit Verification of transaction within customer limit online
107 Limit To affect the exposure when entries are posted
108 Limit To establish different limits for each Documentary Credits type
109 Limit To monitor credit limits bank wide, per customer
110 Limit To flag customer credit limit review/expiry date
111 Limit Inquiry on credit limit online
112 Limit To override credit limits with proper authorization
113 Limit To block user from processing instrument if over credit limit
To require authorization to go over limit, ID of authorization is
114 Limit
captured
115 Advices
System should be able
To generate remote printing of Documentary Credits at
116 Advices operating centre/ Branches.
To print customers advice for all types of transactions,
117 Advices
depending on parameters
118 Advices To customize advices based on the user needs and requirements
119 Advices Advice set up in terms of text and lay out.
Automatic capturing and generation of SWIFT messages and
120 Advices
documents.
121 Accounting
Automatic generation of accounting entries on authorizing the
122 Accouting
transaction
123 Accouting Online update of customer’s accounts
124 Accouting Online update of customer’s margin accounts
125 Accouting Online update of commissions/charges/fees accounts
126 Accouting Online update of Tax/VAT on commissions/ fees /charges/etc.
127 Accouting Online update of Nostro accounts
128 Accouting Online update of other accounting entries (if any)
Enquiry to view both authorised and unauthorised accounting
129 Accouting
entries.
130 LC Inquiries
System should be able to support:
Inquiry on To inquire on Letters of Credit instruments using L/C reference
131 Letters of Credit number / transaction reference number.
To inquire and generate report on customer-wise / commodity-
Inquiry on wise/ country-wise Letters of Credit opened, outstanding,
132 Letters of Credit settled, expired and cancelled on any specific date range.
Inquiry on To display Letters of Credit instrument that are due for expiry
133 Letters of Credit
Inquiry on To display Letters of credit details history online
134 Letters of Credit
135 Reports
Ability to provide a report of all L/C's opened for the defined
136 Report date range and defined customer range.
137 Report Details of open Letter of Credit by currency
138 Report Details of expired Letter of Credit by currency
Ability to provide a report of all L/C's payments made for the
139 Report defined date range and defined customer range
Ability to provide a report of all cancellations to L/C's for the
140 Report defined date range and customer range
141 Bills Processing
142 Bills processing Link bills to credit lines or bank's commitments
Discounted rates, Variable, Flat, compounded, pricing to be
143 Bills processing
linked to tenor of bill
144 Bills processing Charging fees and commission by bill / by schedule
145 Bills processing Bills settlement
146 Bills processing Early payment or settling all the bills before the maturity
147 Bills processing Manual rescheduling and maintenance of the bills.
Response Detail description

S
S
S
S
S
S

S
S
S

S
S

S
S
S
S

S
S

S
S
S

S
S
S
S
S
S
S
S
S

S
S

S
S
 Reports can be sent,
tracer not available in
our system

S
 Tracers not available

S
S

S
S

S
S

S
S
S

S
S
S
S

S
S
S
S
S
S
S
S
S
S
S

S
S
S
S
S

S
S
S
S
S
S
S
S

S
S
S

S
S
S
S
S
S
S
Reference Area Description
Bank Guarantees
Guarante System should support issuance of open ended, close ended
1 es & hybrid guarantees.
Guarante System should support issuance of all types of financial and
2 es
Guarante non-financial letter of guarantees, but not limited to:
3 es
Guarante Direct Guarantee
4 es
Guarante Demand Guarantee
5 es
Guarante Tender Guarantees / Bid Bond
6 es
Guarante Performance Guarantee
7 es
Guarante Advance Payment Guarantee
8 es
Guarante Retention Money Guarantee
9 es
Guarante Payment / Trade Debt Guarantee
10 es
Guarante Facility Guarantee
11 es Guarantee securing a credit line
Guarante System should support issuance of guarantees with
12 es evergreen clause.(assumed renewed at expiry date)
System should support issuance of guarantee with an
Guarante expiry date or specific event when the guarantee ceases to
13 es be valid.
Upon authorization of the guarantee, system should
generate a MT760, in case the guarantee is sent to an
advising Bank, otherwise should generate a guarantee
Guarante letter which is printed on a stamp paper to be handed over
14 es to the applicant to be sent to beneficiary.
System should allow amending the guarantee - amount,
tenor and other contents / clauses. Upon authorization,
system should generate MT767 where it is sent to an
Guarante advising Bank or otherwise generate a guarantee
15 es amendment letter to be printed on a stamp paper.
Guarante System should support advising guarantees to the
16 es beneficiary that are received from the issuing bank.
System should allow users to utilize applicant's credit line
during issuance of guarantee for the amount and tenor and
Guarante during amendment for the incremental amount and
17 es extended tenor.
Guarante System should allow collection of charges, fees & tax
18 es during issuance, advising and amendment of guarantee.
System should support collection of commission for
Guarante guarantees - commission set-up & collection is on line with
19 es what has been discussed above.
For close ended guarantees, system should have the option
of collecting commission periodically or upfront for the full
tenor of the guarantee or for each financial year, provided
Guarante the expiry date of the guarantee extends to the next
20 es financial year.
For hybrid guarantees, system should have the provision to
define the amount of collection / period for which
Guarante commission is to be collected upfront after which
21 es commission for the balance period should be periodic.
 System should support marking lien on deposit, blocking
Guarante account or collection of collateral / margin at the time of
22 es issuance as well as amendment of guarantee.
Guarante System should pass contingent entries upon issuance of
23 es guarantee and amendments involving amount.
Guarante
24 es System to further support the following during amendment:
Collect additional commission: if there is an increase in
amount or where expiry of the Guarantee is extended
where the new expiry date goes beyond the period for
Guarante which commission had been collected during issuance or
25 es during the previous amendment where tenor was extended.
Guarante Utilize limit for the incremental amount / tenor or release
26 es limit for the amount / tenor decreased.
Collect additional margin or release excess margin
Guarante collected in the same proportion as collected during
27 es issuance.
Guarante Outstanding liability of the guarantee at any given point of
28 es time should be displayed in the contract.
System should support sending payment through Swift
Guarante (MT103 / MT202), EFTS, issuance of a DD / PO / MC or by
29 es crediting to a customer's account.
Response Detail description
Reference Area Description Response

Treasury
1 Management End to End support
Treasury Treasury products - Mark to Market
2 Management Valuations

Treasury Entries for Rate Fixings / Premium /

3 Management Commission etc..

Treasury
4 Management Counterparty confirmations

Treasury Netting Facility (payments / CP exposures)

5 Management wherever required.

Counterparty payment generation wherever

Treasury required (Including XAU transfer messages
6 Management MT 604 / MT 605)

System should be capable of providing a

Treasury report of payments that are released / to be
7 Management released for next two working days.
System should be capable of CP
Treasury confirmations auto match based on pre
8 Management defined criteria.

Treasury Deal ticket generation for deals between

9 Management Treasury and Branches.

Treasury The solution should enable the back office

10 Management users to authorise deals at the back office
The system should be able to capture the
Treasury relevant details for the following master
11 Management data

Counterparty Data - Counterparty details,

such as postal address, electronic
Treasury address(es), account numbers, short names,
Management credit ratings etc.
Treasury Counterparty Standard Settlement
12 Management Instructions

Treasury
13 Management Broker details

Currency definition and Currency calendars -

Treasury Currency information, holidays and interest
14 Management calculation bases

Treasury
15 Management Nostro details

Treasury
16 Management Portfolio setup

Treasury
17 Management User data maintenance

Treasury
18 Management Security definitions
Treasury
19 Management Reference rate maintenance
Maker checker for key standing data like
Treasury Counterparty, SSI, Security definition and
20 Management User
 The system should support all standard
SWIFT confirmation messages - provide a
Treasury list of all supported SWIFT confirmation
21 Management messages in the system

Treasury The solution should allow customisation of

22 Management messages using tag level formatting

The solution should be able to print deal

Treasury confirmations and deal contracts based on
23 Management user defined templates
Please describe the capabilities of the
solution to handle Simultaneous PvP
Treasury (payment vs payment) rather than “real
24 Management time”.
Treasury The solution should handle interest rate
25 Management resets that impact retrospectively

Treasury Please explain the support for Back value

26 Management Dated transaction accounting in the solution

Treasury Please explain the support for accounting

27 Management for Split value date deals in the solution

The solution should support revaluation of

open currency positions. This should
indicate the profit (or loss) of closing
positions at either the current market rates
Treasury or at a rates specified by the settlements
28 Management department.
Facility to capture each treasury bill/bond
details such as instrument serial number,
amount, maturity date, discount and issuing
Bank’s detail
Treasury
29 Management
Facility to allow passing accounting entries
for transactions such as at the time of
Treasury purchase and settlement
30 Management
Facility to accrue discount earned on
treasury bills when the year-end closing
date of the Bank falls between the
purchasing date and maturity date
Treasury
31 Management
Query facilities to avail treasury bills/bond
details that will mature in user definable
Treasury forward date
32 Management
• Cash Notes (Purchase)
Treasury
33 Management
• Cash Notes (Sales)
Treasury
34 Management
• Guarantee – Foreign
Treasury
35 Management
• Inward Bills For Collection (IBC)
Treasury
36 Management
• Import Letter Of Credit (L/C)
Treasury
37 Management
 • Non-resident Foreign Currency Account
Treasury
38 Management
• Outward Bills Purchase (O.B.P)
Treasury
39 Management
• Clean Outward Remittances
Treasury
40 Management
• Outward Bill for Collection (O.B.C)
Treasury
41 Management
• Outward Documentary Bills Purchased
Treasury (ODBP) (export)
42 Management
• Outward Documentary Bills for Collection
Treasury (ODBC) and Advance On Export Bills (AB)
43 Management
• Incoming Transfer
Treasury
44 Management
o Foreign Exchange services (buying and
Treasury selling of Forex to general public and own
45 Management customers)
 To support cash replenishment
Treasury transactions such as receiving and shipment
47 Management of cash
 Asset-Liability Management analysis
(including maturity, interest and Forex
Treasury positions)
48 Management
 Deal list can be obtained with user
Treasury defined fields
49 Management
 Transaction processing according to
permitted sequence and privileges for a
Treasury select deal in the list
50 Management
 Deals can be amended and cancelled at
Treasury any stage
51 Management
Facility to design foreign currency
conversion rates and keep daily history of
Treasury the conversion rates
52 Management
Store Conversion Rates Rolling 12 months
Treasury
53 Management
Capability to convert third currency to dollar
amount to home currency amount and vice
Treasury –versa
54 Management
Foreign currency transactions shall use rates
from a user-defined rate table. The rate
Treasury table shall specify buy, sell rates and
55 Management spreads.
The system shall support entry of ‘special
deals’ (based on security profile) that use a
Treasury rate different from the standard table.
56 Management
 The system shall provide for the input,
maintenance, processing and reporting of
all deals contracted by the Bank or on the
foreign exchange market. The system shall
be multi-currency and record all assets and
liabilities irrespective of whether or not
they have matured.

Treasury
57 Management
All deals are input, on-line, in real-time,
through a central input facility, which
updates both the position and
customer/nostro accounts. The main deal
types are
• Spot
• Forward
• Swap

Treasury
58 Management
Spot
The system shall provide the ability to post
either purchase or sale with following fields
as minimum:
• Customer Number - either directly or via a
search feature.
• Date Arranged – default to system date
but ability to amend.
• Confirmation type – optional formats
available.
• Purchase Currency – from drop down box.
• Sale Currency – from drop down box.
• Purchase Amount – once exchange rate is
entered, sale amount is automatically
calculated.
• Sale Amount – conversely if a sale, then
the purchase amount would be
automatically calculated.
• Exchange Rate – entered manually.
• Debit Account Number.
• Credit Account Number.
• Value Date.
• Free form Narrative.
• Settlement Instructions.

Treasury
59 Management
Forward
Same as Spot but with value date greater
than two days future.
Treasury
60 Management
 Swap
A swap spot deal is the spot purchase of
one currency against the forward sale of
another currency. A swap forward deal is
the forward sale of one currency against the
spot purchase of another currency. The
system should be able to accommodate
these types of deals.

Treasury
61 Management
Other Transactions
The industry provides for many
permutations of the above transactions.
Indeed, new twists can appear on a regular
basis. The system shall provide the ability to
be able to add different types of FX deals as
required with minimum system support.

Treasury
62 Management
Fixed Deposits (FD)
Treasury
63 Management
Fixed Loans (FL)/Placements
Treasury
64 Management
Reuse FD and FL/Placement Account
Treasury Number
65 Management
Amendments Fixed Deposits and Fixed
Treasury Loans
66 Management
The system should be able to run summary
Reports weekly, monthly, and quarterly of
all Treasury dealings i.e. Forex transactions,
interbank placements
Treasury
67 Management
The system should enable the dealer to
Treasury select the counter party already created in
68 Management the system
For money market placements or
borrowings, the system should be able to
capture;
• Counter party details
• Transaction amount
• Interest rate
• Tenure of deal
• Value date/Effective date

Treasury
69 Management
The system should have the ability to
compute interest on all days in a year
Treasury including weekends and public holidays
70 Management
The system should have the ability to
restrict maturity of a deal to a working day
or next working day for unpredicted public
holidays (disallow maturities on public
holidays and weekends).
Treasury
71 Management
 The system should be able to accrue and
apply interest(both Simple and Compound)
Treasury on Money Market instruments
72 Management
The system should be able to generate a
Treasury deal ticket for the transaction
73 Management
The system should have the ability to
terminate and/or rollover deals upon
Treasury maturity based on pre-determined
74 Management parameters at deal initiation
The system should have the ability to charge
penalty on pre-mature terminations (A
certain percentage of the accrued interest
should be charged as penalty for pre-
matured termination)
Treasury
75 Management
The system should support segregation of
duties, through front and back office
functions, ensuring that all transactions are
approved by a separate authorized official/s
in line with the bank’s structure
Treasury
76 Management
The system should support product
structure definition for General ledger
postings at;
• The capture of a money market deal
• Transactions for interest accrual
• Transactions at maturity of the Money
market deal
• Settlement and completion of the
transaction
Treasury
77 Management
The system should have the ability to diarize
Treasury the repayment of the borrowed funds
78 Management
The system should be able to generate
settlement instructions (RTGS,SWIFT) at
Treasury back office where applicable
79 Management
The system should have the ability to
interface with the Reuters and other trading
platforms to capture and post transactions
with the following details but not limited to
;
Value date
Principal
Period
Interest rate
Interest rate basis; (actual/365).

Treasury
80 Management
The system should be able to interface with
several platforms such as SWIFT/RTGS and
support straight through processing to
capture transactions through these
Treasury platforms
81 Management
The system should have the ability to allow
change of terms on deals and keep record
Treasury of change history with the necessary
82 Management approvals
 Define transactional process & manage it:
Treasury Intentions - orders - transactions-
83 Management reconciliation
Ability to calculate profitability based on
Treasury customer transactions and investments
84 Management
Ability to support complete deal life cycle
Treasury management
85 Management
Detail description
Reference Area Description
Agency banking
Agency
1 Bankin Ability to define and maintain agencies
g
Ability to integrate with various service channels
Agency
to support the Agencies products offering e.g.
2 Bankin
Point of sale (POS), Card management system,
g
internet banking, mobile banking etc
Agency
Ability to deploy client with select features to
3 Bankin
agencies
g
Agency Ability to split commission sharing for the bank
4 Bankin and the agency through user defined
g configurations.
Management Information System (MIS) to
Agency
support appropriate referencing features for
5 Bankin
easy monitoring of different Agency
g
transactions.
Agency
6 Bankin Cash In and Cash Out through agent – Cash Deposit and
g
Agency Withdrawal with Biometric / One time password (OTP) based
authentication
7 Bankin
g
Agency
8 Bankin
g Loan functionality that includes – loan repayment and
Agency disbursement by agent
9 Bankin
g
Agency
10 Bankin New Savings account creation
g
Agency
11 Bankin Insurance Registration
g
Agency
P2P Payments which include - Internal Funds Transfer , Wallet
12 Bankin based transaction
g
Agency
13 Bankin Top ups through agent such as mobile / cable tv
g
Agency
14 Bankin
g
Agency
15 Bankin
g
Agency The system should have comprehensive Inquiries such as
16 Bankin Balance Enquiry
Transaction Enquiry
g
Agency Mini Statement
Customer 360 View
17 Bankin Agent Transaction enquiry
g Agent Commission enquiry
Agency
18 Bankin
g
Agency
19 Bankin
g
 Agency
20 Bankin
g
Agency
21 Bankin
The system should support basic Account services such as
g Cheque book request
Agency
Channel banking registration
22 Bankin E-statement registration
g Update mobile number
Agency Stop cheque request
23 Bankin
g
Agency
24 Bankin
g
Agency
25 Bankin Agent Hierarchy should be supported
g
Agency
26 Bankin
g Agent Liquidity Management with provision to buy/sell cash
Agency
27 Bankin
g
Agency
28 Bankin Agent Onboarding for Agencies as well as individual agents
g
Agency
29 Bankin
g
Agency
30 Bankin
g
Agency
31 Bankin Agent Management that includes
Commission setup for Agent transactions
g Device allocation
Agency
Agent enablement
32 Bankin Agent status change
g Commission Settlement
Agency Adhoc and Batch reports for tracking and reconciliation purpose
33 Bankin Dashboard for tracking
g
Agency
34 Bankin
g
Agency
35 Bankin
g
Agency
Scalable and can accommodate Agencies
36 Bankin
through the web access model
g
Response Detail description
Reference Area Description
Micro Finance
Micro Finance Institutions (MFI)
1 MFI The system's ability to
mainating group and individual
2 MFI customer information
3 MFI Freeze group balance as guarantee
4 MFI Maintain loan insurance details
Account opening for individual and
5 MFI
group
Consolidated account opened by
6 MFI branch per introducer
Consolidated deposit by branch per
7 MFI
account
Remote access to account
statements, fund transfer,
8 MFI withdrawal
Grouping of account opened per
9 MFI
introducer
Grouping of account opened and
10 MFI deposits to Micro loan officer (staff)
11 MFI Group Features
12 MFI Remote group registration
Remote account statements through
13 MFI mobile phone
To provide features which will
enable classification of consolidated
group account opened by branch at
any given period of time and the
14 MFI amount of deposit in each account
Grouping of account opened per
15 MFI
introducer
Group account opened and deposits
16 MFI per loan officer (staff)
Micro Savings accounts should have
an automated interest component
where the system capitalizes the
17 MFI interest on a monthly basis.
Have the remote account opening
18 MFI
features.
19 MFI Loan monitoring & collection
More elaborate monitoring report
20 MFI on daily, and monthly due accounts,
For managing 1 day arrearage,7
21 MFI
days
Daily arrears
,weekly ,PAR Report per
micro officer ,product, branch and
22 MFI sales centre
Have all the loan accounts attached
to the relationship officer in all
23 MFI sectors
 Have the loan accounts for the
Muslim customers loaded with the
management fees by the time of
24 MFI disbursing the loan in the system.
The relationship officer should be
25 MFI included in the monitoring report
The daily disbursement report
should be easily accessible i.e. by
26 MFI branch, product,
Have the repayment schedule per
27 MFI customer for all the loan products .
28 MFI Monitor business growth in terms of
Loan disbursement per branch/sales
29 MFI
centre
30 MFI Consolidated loan disbursement
Account opened per branch per
31 MFI
introducer
Consolidated account opened per
32 MFI branch per introducer
Consolidated deposits per branch
33 MFI per introducer
Response Detail description
# REQUIREMENT
TECHNICAL REQUIREMENTS
The systems should have the following capabilities.
A Solution Architecture
A1 ● Client Server: The System must adhere to Client/Server principles with high availability of redundancy
A2 ● Real-Time, On-line: The System must perform Real-time and Online transaction processing with
highest rate of TPS
A3 ● Integrated: There must be full integration of all modules to ensure “latest picture” to all users without
interfacing between modules of the System and without manual (user) intervention.
A4 ● Database: The System must utilize an ISO-compliant (ISO-9075) and hardware independent Relational
Database Management System (RDBMS) Oracle. The system must comply with recognized international
standards and in particular Unicode, UTF, ASCII and ANSI. The platform should be based on active-active
database clusters technology. The platform should support seamless integration of failed units that
have been repaired. The platform should support minimal downtime required during future expansion.

A5
● The OS of the Database Server and Application Server should be Linux
A6
● The overall system includes Application, Web nodes must support Virtualization technology
A7
● Prefer Database must in a physical server
A8
● Flexible GUI User Interface for users, admins
A9
● Keyboard: Standard Keyboard (101 keys)
B General Configuration
B1 ● The System must support easy introduction of new financial and static data transactions, new fields
and new products.

B2 ● Programs should be configured to comply with annual calendar year

B3 ● Ability to provide multidimensional views of core banking and financial data.
B4 ● Ability to integrate with standard industry report writers
B5 ● Ability to provide dashboard for specific purposes (e.g. management decision support, etc).
B6 ● Ability to generate various types of Administrative, Management and financial report.
B7 ● The report writer must be capable of producing reports both on screen and printed version in any
presentation format.

B8
● The system must automatically produce daily reports of all transactions of a sensitive and
security nature, for example, static data changes.
B9 ● The system must be capable of producing pre-defined daily and periodic reports for branches and
departments, with control over the user’s ability to suppress report production and ‘suppress’
movements over dormant accounts and static data

B10 ● All the major business rules are totally configurable thus giving the optimum usage of flexibility with
control.
B11 ● The system must be capable to only view/only print/ print and view and export all reports.
B12 ● Apart from role/level wise rights, system must be capable to assigned menu rights as well as
authorization rights based on users.

C Transaction Security
C1 ● The System must provide security and full audit trail of all on-line /offline transactions
C2 ● The System must support remote Supervisor authorization/override.
C3 ● Each transaction should be time stamped in Transaction History File.
C4 ● Transaction recovery/roll-back with full audit trail and manual confirmation by the concerned in case
of any kind of failure.

D User Administration & Management

D1 ● The System must provide Centralized Security Administration
 D2 ● The System must support flexible and easy ways to define and amend user security profiles which
control the user’s rights to access/amend data, or execute programs
D3 ● The System must support the setting of global as well as user-specific security options such as
restricted accounts, restricted branch, restricted work station, restricted product, restricted customer,
and restricted function. Forced inactivity workstation time-out, network traffic protection through
encryption, user authentication, User wise authorization limit, level wise authorization limit, user wise
verifier limit, branch grading on transaction passing and etc.

E Security & Access Control

E1 ● Ability to manage user’s financial rights and financial passing limits controlled over the whole
operations. Authentication - Unique user codes and passwords for access; password expiration and user
disablement; user passwords stored encrypted.

E2
● Authorization - User credentials and privileges validation on every resource and application
block; personal permission on banking services.
E3 ● Cryptography- PKI and digital certificates as a standard for user authentication, integrity of data
interchange, confidentially and preventing repudiation issues.
E4 ● Session management - Unique session identifiers and secured details storage; session lifetime control
on every discrete user action.

E5 ● Sensitive data management - Sensitive data stored, sent over network and logged in encrypted.
E6 ● Infrastructure security - Secured network infrastructure provided by the bank; encrypted traffic
between application tiers; SSL where applicable; securing the financial platform servers.
E7 ● Audition and logging - Full log of user activity; audit of application activity through all application
tiers.
F Bank-wide Parameters, Definitions & Reference Data, Rates, Rules, etc
F1 ● All the products and operations are configured by set of parameters and hence there is very less
dependency on the software for customization.

F2
● The System must not employ hard-coded values: The System must provide and maintain system
constants and bank-wide parameters, definitions, reference data, rates, rules etc as changeable
parameters and not as hard-coded constants
F3 ● Flexible Product Definition: The System must support the speedy and flexible introduction of new
product variations (i.e. a new current account, or a new loan product) through parameters rather than
programming. This should address at least the following:

F4 o Product parameters
F5 o Settlement parameters
F6 o Interest, Exchange rates etc
F7
o Fees, with flexibility of Fix, Variable, etc at bank / branch/ cust/ product/ sub-product/
account/ subaccount /transaction etc.
F8 o Commissions, with flexibility of Fix, Variable, etc at bank / branch/ cust/ product/ subproduct/
account / subaccount/ transaction etc.

F9
o Charges, with flexibility of Fix, Variable, etc at bank / branch/ cust/ product/ subproduct/
account / transaction etc.
F10 o Business Rules should be able to govern all kind of charges.
F11 ● The System must support the development of new products based on existing products through the
different setting of parameters applicable for the existing products together with the introduction of
new parameters.
F12 ● The System must make available automatically new product and transaction definitions to all
branches.

F13
● The System must incorporate mechanisms to control access to the modules/data that are necessary
for the definition of new products
G National Language Requirements
● The System must support certain fields to be held in both English and other language: i.e. Account
G1 Name.
 G2 ● The System must have the ability to generate customer statements, advices, confirmations etc. in
English or other language depending on the language preference specified in customer profile.
H Error Handling
● The System must feature error handling and correction procedures that are effective and also user-
H1 friendly.
I Operational Efficiency
I1
● The System must impose low operational requirements in terms of operators needed, processing
power, environmental needs, etc.
I2 ● The System must be easy to install, customize and interface to other systems.
J System documentation and help facility
J1 ● The System must be supported by appropriate documentation that must describe the system and
provide guidance for its use. Please describe briefly your System’s documentation.

J2 ● The System documentation must include “how to” sections and sufficient examples.
J3 ● The System must provide context sensitive help at the field level
J4 ● The System must have meaningful error messages (not plain error numbers)
J5 ● On-line user-customized help, etc
J6 ● The user must be able to insert bookmarks and additional text to supplement standard help text, etc.
K Batch Processing
K1 ● The System must support efficient batch operations to minimize the processing time for end-of
period batch operations / processing (where period can be daily, monthly quarterly, etc).

K2 ● The System must support the execution of multiple concurrent running streams to reduce the batch
processing time.
K3 ● The System must support dependencies between various batch processes to control the flow and
outcome of batch runs.
Response
Detail description