Customer Accounts - Unlocked

ADMINISTRATOR TRAINING MANUAL
CUSTOMER ACCOUNTS
www.infosys.com/finacle
Document number: VersionRev: 1.00
Authorized by: R N NAGARAJ Signature/Date:
Document revision list
Ver.Rev Date Author Description

1.00 01-08-2003 Sameer Shirgurkar Original version
1.01 20-02-2006 Rohit Johri Revised and updated
document to 9.1 release
1.02 22-02-2007 Giridhar Mohan Bhat Revised and updated
1.03 16-04-2007 Bindu Bhargavi Revised for 10.0v
1.04 07-06-2007 Raghavacharyulu Revised for 10.0
1.05 17-07-2007 Bindu Bhargavi Revised for 10.0v
1.06 04-01-2007 Naga Krishna Prabhu Revised for 10.1 version
1.07 B.Sudhir Kumar Revised for 10.2 v
1.08 03-03-2009 Raghavacharyulu Reviewed & updated
© 2009 Infosys Technologies Limited, Bangalore, India
All rights reserved by Infosys Technologies Limited,

Electronics City,
Hosur Road,
Bangalore – 560 100
India
No part of this volume may be reproduced or transmitted in any form or by any means electronic or mechanical including
photocopying and recording or by any information storage or retrieval system except as may be expressly permitted.
This Training manual has been written and produced by the FINACLE -PSUSER EDUCATION TEAM of Infosys
Technologies Limited.
Infosys believes that the information in this publication is accurate as

of its publication date. This document could include typographical
errors, omissions or technical inaccuracies. Infosys reserves the right
to revise the document and to make changes without notice. Infosys
acknowledges the proprietary rights in the trademarks and product names
of other companies mentioned in this document.
Infosys FINACLE – PSUET Administrator Training Manual
TABLE OF CONTENTS
1 OVERVIEW ..................................................................................................................... 4
1.1 SALIENT FEATURES ........................................................................................................... 4
2 SECTION OBJECTIVE .................................................................................................. 6
3. PROCESSES INVOLVED............................................................................................ 6
3.1 PROCESS DIAGRAM............................................................................................................ 7
3.2 PROCESS DIAGRAM FOR CUSTOMER ACCOUNT OPENING .............................. 8
3.3 PROCESS DIAGRAM FOR CHEQUE ISSUE ................................................................... 9
4 DBA RELATED ACTIVITIES .................................................................................... 9
4.1 INITIAL SETUP - OPERATING SYSTEM LEVEL ........................................................ 10
4.1.1 CUST-OPTIONS ............................................................................................................................ 10
4.2 INITIAL SETUP - APPLICATION LEVEL...................................................................... 11
4.2.1 REFERENCE CODES ................................................................................................................... 11
4.2.2 EXCEPTIONS ................................................................................................................................... 11
4.2.3 ACCOUNT PLACEHOLDERS ........................................................................................................... 19
4.2.4 MISCELLANEOUS ............................................................................................................................. 21
4.3 PARAMETER SETUP ......................................................................................................... 21
4.3.1 SYSTEM CONTROL FILE MAINTENANCE ................................................................................. 21
4.3.2 CREATION OF SCHEME CODE USING HGSPM ........................................................................ 25
5 GENERAL USER ACTIVITIES................................................................................... 45
5.1 CREATION AND MAINTENANCE OF CIF...................................................................... 45
5.2 FINACLE CORE SPECIFIC CUSTOMER DATA ............................................................ 46
ANY CHANGES MADE USING HCCFM MENU OPTION NEED TO BE VERIFIED BY THE
SAME MENU OPTION. 5.3 CUSTOMER ACCOUNTS OPENING ( SB, CA, CC, OD) ................. 47
5.3 CUSTOMER ACCOUNTS OPENING ( SB, CA, CC, OD) ............................................................... 48
LOAN AGAINST DEPOSITS ...................................................................................................................... 64
CONCEPTS AND EXAMPLES ................................................................................................................... 64
HLAGSPM/HCLGSPM/HGSPM ................................................................................................................. 66
5.3.1 ACCOUNT OPENING/MAINTENANCE ......................................................................................... 67
HLACREV .................................................................................................................................................... 68
INTEREST CALCULATION ....................................................................................................................... 68
5.3.2 CUSTOMER ACCOUNT MODIFICATION BEFORE VERIFICATION OF OPENING ........... 69
5.3.3 CUSTOMER ACCOUNT VERIFICATION ...................................................................................... 70
5.3.4 REVOLVING OD ACCOUNTS........................................................................................................ 70
5.3.5 LINK ACCOUNTS TO MULTI CURRENCY ACCOUNT ................................ 74
5.3.5.1 LINKING/DELINKING OF ACCOUNTS TO A MULTI CURRENCY
ACCOUNTS .......................................................................................................................... 77
5.3.6 CUSTOMER ACCOUNT MAINTENANCE................................................................................. 78
5.3.7 LIQUIDITY MANAGEMENT ...................................................................................................... 83
5.3.7.1 MAINTAIN LIQUIDITY MANAGEMENT STRUCTURE ............................. 84
GENERAL VALIDATIONS....................................................................................................................... 85
VALIDATIONS FOR DE-LINKING OF ACCOUNTS ........................................................................ 85
5.3.7.2 MAINTAIN LIQUIDITY MANAGEMENT GROUP ...................................... 87
5.3.7.3 LIQUIDITY MANAGEMENT BALANCE SWEEP ........................................ 90
5.3.7.4 INTRA DAY LIQUIDITY MANAGEMENT BALANCE SWEEP .............. 92
5.3.7.5 RESET LIQUIDITY MANAGEMENT BALANCE IN BATCH .................. 93
Customer Accounts Ver Rev 1.08 Page 1
PROCESSING LOGIC: ............................................................................................................................ 93

5.3.7.6 RESET LIQUIDITY MANAGEMENT BALANCE ........................................ 94
5.3.7.7 LIQUIDITY MANAGEMENT BALANCE REVERSE SWEEP ................ 95
5.3.7.8 CALCULATE INTEREST FOR LM STRUCTURES .................................... 99
SCRIPT: .................................................................................................................................................... 103
INPUTS: .................................................................................................................................................... 103
5.3.7.9 INQUIRE ON LIMIT TREE STRUCTURE .................................................... 104
5.3.7.10 LIQUIDITY MANAGEMENT UPLOAD STRUCTURES .......................... 104
5.4 ACCOUNT LIEN MAINTENANCE ................................................................................ 105
5.5 ACCOUNT LABEL CODE MAINTENANCE ................................................................ 106
5.6 SUPERCEDING THE EXPIRY LIMIT ........................................................................... 107
5.7 PRINTING OF PASS SHEET FOR AN ACCOUNT&OTHER PROCESSES: ........... 107
5.7.1 PRINTING OF PASS BOOK ......................................................................................................... 109
5.7.2 EMAILING FACILITY ................................................................................................................... 109
5.7.3 HSWEEPS ...................................................................................................................................... 111
5.7.4 CHANGE OF CUSTOMER ID FOR AN ACCOUNT .................................................................... 119
5.7.5 VIEWING THE JOINT HOLDERS FOR AN ACCOUNT:........................................................... 119
5.7.6 TRANSFER OF ACCOUNTS BETWEEN GLSUBHEADS .......................................................... 121
5.7.7 TRANSFER OF ACCOUNTS BETWEEN SCHEMES ................................................................. 123
5.7.8 TRANSFER OF ACCOUNTS BETWEEN SOLS ........................................................................ 127
5.8 CHEQUE BOOK MAINTENANCE ................................................................................. 131
5.8.1 ISSUE OF CHEQUE BOOKS ......................................................................................................... 131
5.8.1.1 STOP PAYMENT ..................................................................................................................... 133
5.8.2 CHEQUE BOOK MAINTENANCE .............................................................................................. 135
5.8.3 UPDATION OF CHEQUE STATUS-HUCS .................................................................................. 136
5.8.4 PDC FOR OPERATIVE ACCOUNTS ............................................................................. 137
TRANSACTION ACCOUNT PDC MAINTENANCE .......................................................................... 137
CLEARING ZONE MAINTENANCE FOR POST DATED CHEQUES-HPDCZM........................ 141
LODGING AND PROCESSING OF PDC ........................................................................................... 142
UPLOAD OF TRANSACTION ACCOUNT PDC..................................................................................... 144
5.8.5 TRANSFER OF CHEQUE BOOKS (HXFCHBAC):...................................................................... 144
5.9 FREEZING OF ACCOUNTS .......................................................................................................... 144
LOGGING ACCESS DETAILS FOR RESTRICTED ACCOUNTS ......................................................... 148
5.10 CLOSURE OF ACCOUNTS (HCAAC) ........................................................................ 149
5.11 PAST DUE MOVEMENT OF ACCOUNTS ...................................................................... 150
5.12 CHARGE OFF CC/OD A/C ................................................................................................ 151
VERIFICATION OF CHARGE OFF: ....................................................................................... 151
REVERSAL OF CHARGE OFF ................................................................................................. 152
VERIFICATION OF REVERSAL OF CHARGE OFF: .......................................................... 152
RECOVERY/REVERSAL AFTER CHARGE OFF ................................................................. 152
VERIFICATION OF COLLECTION AFTER CHARGE OFF .............................................. 153
REVERSAL OF COLLECTION AFTER CHARGE OFF ...................................................... 153
VERIFICATION OF REVERSAL OF COLLECTION AFTER CHARGE OFF ................. 154
FOR DETAILS ON ASSET CLASSIFICATION OF CC / OD ACCOUNTS, REFER TO
THE DOCUMENT ON ASSET CLASSIFICATION AND PROVISIONING NORMS. ...... 154
5.13 PURGING OF DATA ........................................................................................................... 154
5.13.1 UPDATE ACCOUNT PURGE FLAG ........................................................................................... 154

5.13.2 PURGING OF CUSTOMER DATA ............................................................................................. 154

5.13.3 PURGING OF AN ACCOUNT ................................................................................................... 155
5.14 INQUIRY AND REPORTS ............................................................................................ 155
5.14.1 ACCOUNT SELECTION .............................................................................................................. 155
5.14.2 ACCOUNT SELECTION PRINT.................................................................................................. 156
5.14.3 CHEQUE BOOK ISSUED REGISTER PRINTING ..................................................................... 157
5.14.4 COMPONENTS OF ACCOUNT BALANCE INQUIRY ............................................................. 158
5.14.5 ACCOUNT LEDGER INQUIRY .................................................................................................. 158
5.14.6 ACCOUNTS BELOW MINIMUM BALANCE ............................................................................ 159
5.14.7 AVERAGE BALANCE REPORT ............................................................................................ 159
5.14.8 ACCOUNT TURNOVER INQUIRY ....................................................................................... 162
5.14.9 ACCOUNT MASTER PRINT ..................................................................................................... 163
5.14.10 CHEQUE BOOK PRINTING (RANGE OF ACCOUNTS) ........................................................ 164
5.14.11 INQUIRE ACCOUNT NUMBER FOR A CHEQUE .................................................................. 164
5.14.12 CUSTOMER ACCOUNT LEDGER PRINT ............................................................................... 164
5.14.13 CUSTOMER INTEREST REPORT ............................................................................................. 165
5.14.14 CUSTOMER MASTER PRINT ................................................................................................... 165
5.14.15 INQUIRIES ON CUSTOMER ACCOUNTS:: ............................................................................. 166
5.14.16 ACCOUNT INTEREST DETAILS INQUIRY ............................................................ 166
5.14.17 CUSTOMER BALANCES PRINTING ........................................................................ 168
5.14.18 ACCOUNT TURNOVER REPORT ............................................................................ 170
5.14.19 CUSTOMER INTEREST PREF AND PEG REPORT.............................................. 170
5.14.20 ......................................................................................................................................................... 171
6 RELATED MENU OPTIONS ........................................................................................ 172
7 RELATED TABLES ...................................................................................................... 174
8 BATCH JOBS .................................................................................................................. 174
9 UPLOAD OPTIONS ........................................................................................................ 175
10 MRT / MRR / SAMPLE REPORTS ............................................................................ 175
11 SCRIPTS ......................................................................................................................... 176
12 FLASHBACK ................................................................................................................. 176

1 OVERVIEW
This Document discusses process involved for set-up, creation and operation of customer accounts
like Savings, Current, Cash Credits and Overdraft accounts. This document also explains the allied
other operations on customer accounts like Issue of Cheque books, maintenance of Customer
accounts and processing customer requests.
In Finacle™, before an account is opened for a customer, the account holder/customer must have
a CIF ID. All the general information related to the customer is captured as a part of CIF ID
creation. This reduces the repetitive entry of information to be given while opening multiple
accounts for the same customer. Customer information being the backbone, Finacle ™ is customer
centric. All the information that are common to all the accounts of a customer is captured at CIF
creation level and same is default populated at account level during opening of a new account for
the customer.
1.1 SALIENT FEATURES

The following sections outline the salient features of customer accounts.
 CIF and/or account number can be system generated or user enterable. The user can
also specify the logic for the system to arrive at the CIF/account number for each type of
accounts.
 A 34 character (alpha numeric) field is provided at the general account master to enable
the storage of IBAN against each customer account as well as office account
 Customer accounts can be opened in any currency. Multicurrency accounts supported.
 Interest credit or debit account (operative a/c to which the credit/debit to be made) can
be specified. This account can be of different Service outlet. Also, the interest credit
amount can be remitted through payment system.
 Accounts can be marked as Inactive, Dormant. Necessary charges can be collected.
 Accounts can be frozen and the reason for freezing can be specified.
 Signatures can be captured and linked to customer or accounts. Image Access feature for
dormant accounts based on the image access code of the image and the codes to which
the user has access depending on the user‟s role (defined in HRPM).

 Pass sheet frequency can be parameterised. The Pass sheet printing is based on the local
/ English calendar. The default population of pass sheet frequency is obtained from
customer master. Charges can be collected for both Regular and Ad hoc pass sheet
printing.
 Account Opening, Maintenance and Closure can be handled across Service Outlets
(SOLs).
 Facility is available for calculation of uptodate interest during the Account closure process.
 With holding or Customer level tax (TDS) facility and the concept of floor limits is
available for credit interest amount.
 Interest accrual, booking and payment/collection based on Local or English calendar
 Various charges can be collected for different operations/events on an account.
 Nomination facility is available for customer accounts.
 Multiple sanction limits can be created for an account
 Statement of accounts can be transmitted via SWIFT
 Freezing of operations in the account (Debit/Credit or Both)
 Combined customer statement and E-mailing
 Sweep facility is available for the customer accounts/multicurrency sweeps also
 ATM facility is enabled for the operative accounts.
 Lien marking is allowed.
 Cheque related operations like Issue of cheque books, stop payment of cheques, caution
noting, transfer of cheques between accounts of the same customer, destruction of the
cheques, cheque status reversal.
 Transfer of accounts between GL subheads
 Transfer of accounts between scheme codes
 Account turnover details for a specified period
 Linking joint holders (multiple CIF) to an account for various statements/notice sending
 Limit level interest for an account
 Document details maintenance
 Automatic disabling of expired limits
 Automatic TOD creation
 Creation of Standing instructions
 Maintenance of customer account status (Active, Inactive and Dormant)

 Revolving OD facility
 Stop payment advice
 Collection of service tax on charges collected
 Collection of charges on sweep operations
2 SECTION OBJECTIVE
The main objective of this section is to make the user familiar with customer accounts related
processes such as
 Opening of Customer accounts and verification of account opening
 Opening of multicurrency accounts and verification of account opening
 Cheque related operations such as issue of cheques, stop payment processing, revocation
of stop payment, destruction and transfer of cheques, reversal of cheque status.
 Enabling/Disabling Cash, clearing and transfer transactions in accounts
 Maintenance of Customer Accounts/multicurrency accounts
 Concept of Account manager
 Freezing of Accounts
 Marking an account as Inactive or Dormant.
 Operations like Statement Printing, Pass book printing, combined statement printing
 Lien marking on accounts
 Computation and maintenance of Sanction limits and Drawing power for accounts.
 Sweep In and Sweep Out facility.
 Customer account closing
 Marking of accounts as Past Due
 Charge off of accounts
 Recovery after charge off
3. PROCESSES INVOLVED
The process involved for customer accounts operations are described below

3.1 PROCESS DIAGRAM

The diagram shown below illustrates the processes involved in the creation of a CIF ID
HASTM
Amount Slab Code Maintenance
(For TDS calculation)
HRRCDM
Customer Title Code HBKTM
Bank Code Maintenance

Customer Type Code
(Customer of Other bank Code)
Customer Status Code
HUPM
Customer Group Code
Account Manager for the Customer
Occupation Code
Customer Constitution Code
Customer Introducer Stat Code HSCFM
City Code System generated cust Id , OR flag
State Code to assign the cust id by the user.
Country Code Community Code CUST ID Prefix
Caste Code
Health Code
Cust. Asset Main Classification
Cust Asset Sub classification CIF
Customer Rating Code Customer Information File
Relationship Code
Charge Level Code
Marital status
Charge Level Code

3.2 PROCESS DIAGRAM FOR CUSTOMER ACCOUNT OPENING

The diagram shown below illustrates the processes involved in the opening of Customer Accounts.
HRRCDM
HNNTM
Tran Report Codes
Sys. Generated Account No.
HRRCDM Series
Work Class for posting HEXCDM

Exceptions
HITCM
Interest Table Code
HCNCM
Currency Codes
HIVSM
Interest Version Slab
HINSTM
HRRCDM Valid Instruments for Dr. & Cr.
GL Codes
HAPHM
Account Placeholders
HGLSHM
GL Subhead Codes HGSPM
Scheme Code
HOAAC (SB/CA/CC/OD)
Open a Customer Account
HOAACM/HOAACV(SB/CA/CC/
OD)
Verification of Account Opening

3.3 PROCESS DIAGRAM FOR CHEQUE ISSUE
HEFM
HIIM
Employee
Inventory Type
Record
Account
Number
HSCFM
Chq. Acknowlegdement
needed ?
HPTTM
Event Type - MICR - Cheque Issue
STPMT Stop Payment HICHB/HICHBA
Issue of Cheque Book
HRRCDM HICHB/HICHBA HCHBM

Stop Reason Code Verify Issue of Cheque Book Cheque Book Maintenance
HCHBIR
Cheque Book Issued
Register
HSPP HICTM
Stop Payment Cheque use Cheque
HUCS
Update Cheque Status
HTM
use Cheque
HINQACHQ
Inquiry on Cheque
HSPPAU
Stop Payment Cheque -
HXFCHBAC
Verification
Transfer Cheque book
Across Accounts
HXFCHBAC
HSPRG verify transfer Cheque book
Stop Payment Register print Across Accounts
Refer Inventory Document for Inventory movement to employee

This process diagram assumes account exists to issue cheque book
CHBM is mandatory if SCFM flag is Y for Cheque Book Acknolwledgement needed
Inventory should exists only with either enterer or Authorizer only
Only 100 leaves per cheque book allowed to be issued
Cheque Books can be uploaded directly through menu CHQUPLD
4 DBA RELATED ACTIVITIES

This section explains all the DBA related activities which are mostly one time set ups.

4.1 INITIAL SETUP - OPERATING SYSTEM LEVEL

The initial set-up needed to be done for customer accounts module is explained here.
4.1.1 CUST-OPTIONS
The cust-options related to customer accounts are listed below.
CUST_OPTION VALUE DESCRIPTION
PBP_PRINT_NOM_DETAILS 1 To print Nomination details in pass book(1) or not (0)
PBP_ USING_ MRT 1 Printing of pass book using mrt(1)/Not using mrt (0)
PBP_MR_TEMPLATE Mrt file Mrt file name used for printing passbook
PBP_FORMAT_FILE1 Printer id Printer id for PR-50 printer
PBP_FORMAT_FILE2 Printer id Printer id for PR-40 printer
PSP_TEMPLATE_HALF Mrt file Mrt file used for half size pass sheet
PSP_TEMPLATE_FULL Mrt file Mrt file used for full size pass sheet
PSP_TEMPLATE_WIDE Mrt file Mrt file used for wide pass sheet
VAL_FREE_CODE_REQUIRED 1 When value entered in free codes needs to be

validated(1) or not (0)
OFTI_ADVC_MRT Mrt file Mrt file name used for printing
OFTI_VCHR_MRT Mrt file Mrt file name used for printing
FFD_MIN_BAL_IN_OPER_AC_A 1 If the Operative account is in Credit balance and less

S_BASE than schm level minimum balance, by default no Linked
FD's will be broken to maintain the minumum balance.
However if this cust option is set to 1, FFDBATCH will
break the linked deposits to bring the Op A/c balance to
the min bal threshold.
FFD_BREAK_MIN_BAL_FROM_F 1 or 0 If set to 1, system will pickup FFP

FP min_bal_in_oper_acct for reverse sweep. If set to zero
system will continue with the existing functionality i.e it
will pickup
acct_min_balance of CSP for reverse sweep.
 An mrt file is a Maha Report file. These are files stored in the $TBA_PROD_ROOT/cust/mrt or
$TBA_PROD_ROOT/cust/INFENG/mrt directory..

4.2 INITIAL SETUP - APPLICATION LEVEL

In this section all the set ups done at the application level are discussed.
4.2.1 REFERENCE CODES
Listed below are the reference codes that need to be created using the HRRCDM menu option.
 Customer sector
 Customer Sub sector
 Mode of operation
 Guarantee cover Code
 Nature of advance
 Type of advance
 Mode of advance
 Purpose of advance
 Charge Level Code
 Asset Sub Classification
 Asset Main Classification
 ISO country code IBAN creation
 Document code list
 Marital status
4.2.2 EXCEPTIONS
Listed below are the exceptions related to customer accounts. These can be set as warnings,
exceptions, or errors so that they will be triggered appropriately; approval of exception is
dependent on the user‟s work class. All exceptions are created through HEXCDM Menu option.
HGSPM - GENERAL DETAILS
LIABILITY EXCEEDS GROUP LIMIT
If the liability exceeds the maximum group(overall) limit set through limit nodes, this exception is
validated.

INSUFFICIENT AVAIL BAL EXCP
Insufficient available balance is always a hard coded error. This exception is over & above the hard
coded error and hence is redundant. This exception will get invoked if debit transaction on an
account which does not have sufficient funds excluding shadow balance and no TOD is granted for
the transaction to go through.
CHANGE IN A/C NAME
If the account name is changed during Account opening, then this exception is validated. (For ex:
RIL –DW1998, RIL-DW1999 etc.,).This exception is also also raised if the account name is
changed through HAALM menu option.
INSTRUMENT IS STALE
If the stale instrument (i.e., instrument date exceeding the validity period) is entered, then this
exception is validated. The validity period for an instrument is set using menu option HINSTM.
ACCOUNT IS FROZEN
When a transaction is put in for an account which has been freezed, this exception is validated.
CIF ID MISMATCH(DR.)
When the CIF Id of the Interest debit account specified is different from the CIF id of the account
for which debit interest is calculated, then this exception is validated.
CIF ID MISMATCH(CR.)
When the CIF Id of the Interest credit account is different from the CIF id of the account for which
credit interest is calculated, then this exception is validated.
BACK DATED TRANSACTION
When the user tries to put through a back dated transaction, then this exception is validated.
VALUE DATED TRANSACTION
When the user tries to put through a value dated transaction, then this exception is validated.
CASH TRANSACTION
This exception is validated when cash transaction is put through for an account.
DEFAULT VALUE DATE CHANGE EXCEPTION
This exception is raised when the value date arrived based on Script is changed
CLEARING TRANSACTION
This exception is validated when clearing transaction is put through for an account.
TRANSFER TRANSACTION
This exception is validated when transfer transaction is put through for an account.

SANCTION LIMIT EXPIRED
When a transaction posting is attempted for an a/c whose sanction limit is expired, this exception
is validated.
SANCTION EXCEEDS LIMIT
When the aggregate of sanctions exceeds the Maximum Sanction Limit specified for an account,
this exception is validated.
CUST DR WITHOUT CHQ
For a scheme under which a/c is opened cheque book usage is defined and appropriate exception
is set, then while doing the transaction, if a customer debit is done without using a cheque, this
exception is raised.
REFERRED A/C CLOSURE:
This exception is validated when an account which is referred in other a/cs is attempted for
closure.
USER TOD GRANT EXCEPTION:
For user created TOD on an account belonging to other SOLs, this exception is validated during
verification.
AUTO TOD GRANT EXCEPTION:
This exception is logged in the database for all system created TODs during Debit against FFD,
Drop in Sanction Limit, TOD during Int Calculations, Demand Satisfaction process, TOD for
accounts belonging to other SOLs etc., during batch process.
ACCOUNT IN DR BAL
Whenever a transaction is put for an account which is in debit and/or the part transaction posting
results in Account balance going to Debit, this exception is validated.
ACCOUNT IN CR BAL
Whenever a transaction is put for an account which is in credit and/or the part transaction results
in Account balance going to Credit, this exception is validated.
DEFAULT PARAMETERS OVERRIDDEN
If the cash/clearing/transfer debit limit or service charge, account report code, turnover details
flag etc., defaulted from HGSPM is modified during account opening, then this exception is
validated.
INVALID RPT CODE
In HGSPM, the valid transaction report codes created through HRRCDM and the corresponding
debit and credit limits can be specified. During the transaction, if the wrong report code is
specified, system will validate this exception.

MEMO PAD EXISTS
Any specific noting(memo pad) which needs to be prompted during transaction processing,
account maintenance, closure can be created using functional key. Also, an exception code is to be
created through HEXCDM. Such exception codes are to be linked thru HGSPM. During transaction
processing/any other process for which memo pad is created, the same is validated and exception
is displayed. User can view the memo pad(noting made) by specifying the account number in the
memo pad screen.
DEFAULT INT PARAMETERS OVERRIDDEN
When the interest related parameters defaulted from HGSPM is modified at the account level
during account opening, this exception is validated.
ACCT BAL BELOW MIN
When the transaction posting causes account balance to go below minimum balance set for the
account, this exception is validated.
MIN. BAL PENAL FEE NOT CALCULATED
When an account is attempted for closure for which the minimum balance penal charges
calculations for non-compliance of the minimum balance requirement is not run, this exception is
validated at the time of account closure verification.
INT FOR PAST DUE ACCCOUNT NOT UPTO DATE
This exception is raised if interest calculation is not upto date on a past due account when the user
tries to mark the account as past due .
DEBIT TRAN ON PAST DUE ACCOUNT
This exception is raised if a debit transaction is attempted on a past due account .
HGSPM - SCHEME DETAILS
DEBIT BALANCE LIMIT
when the transaction posting results in a/c balance exceeding the debit balance limit set at the
scheme level this exception is validated.
C.I. TRAN ON INACTIVE A/C
This exception is validated, when customer-induced transactions are attempted on Inactive

accounts.
C.I. DR TRAN TO DORMANT ACCT
When customer induced debit transaction to a dormant account is attempted for posting, this
exception is validated.

CHEQUE ISSUED ON INACTIVE A/C
When a cheque is issued to an Inactive account this exception is validated.
CHQ ISSUED ON A DORMANT ACCT
When the user tries to issue a cheque to a dormant account, this exception is validated. (Account
status can be made dormant through HACM option. Account selection based on account status is
possible through HACS option.)
CHQ ISSUE WITHOUT MIN. BAL
This exception is validated when a cheque book is issued to an account whose account balance is
below the minimum balance stipulated for cheque book issue mentioned at HGSPM for the
relative scheme.
ACCT CLOSED WITHIN AN YEAR
When an account is attempted for closure within one year of account opening date, this exception
is validated.
NO. OF WITHDRAWALS EXCEEDED
When the maximum number of debits in an account during the calendar month exceeds the
allowed number of withdrawals specified in HGSPM, this exception is validated.
TOD ON A MINOR ACCOUNT
When user tries to create TOD in a minor account, this exception is validated.
INTRODUCER NOT A CA HOLDER
While opening an account under a scheme code belonging to scheme type CAA (current account),
the introducer of such CIF id needs to be a customer having at least one account under CAA
scheme type, else this exception is validated.
A/C. MIN. BAL. BELOW SCHEME MIN. BAL.
This exception is raised by the system if the account balance goes below the scheme minimum
balance mentioned at HGSPM
NOMINATION DETAILS MODIFIED
This exception is validated by the system if the user tries to change the nomination details
through HACM,HACMTD.
DEBIT AGAINST DAFA LIMIT EXCEPTION
Exception is raised when an account is being debited against future value dated transactions which
are not effective still. The limit for DAFA can be set at the account level and system will allow debit
up to that limit. The limit can be either a “Flat Amount” or a “Percentage of the Future Amount” in
Limit Maintenance

HGSPM -TRANSACTION A/C.
CHQ. NOT ALLOWED
If the „Cheques Allowed‟ column value is set to N in HOAAC/HACM and chequebook issue is
attempted in such accounts, this exception is validated.
CHQ. NOT ISSUED
During transaction creation, if cheque particulars are entered for an account and the referred
cheque is not issued to the account, this exception is validated. The cheque issued to any account
can be inquired using menu option HACM/HCHBM.
CHQ ISSUED TO MINOR
If the user tries to issue cheque book to a minor account, then this exception is validated.
CHQ. STOPPED
When the cheque is stopped using menu option HSPP, then during transaction creation or inward
clearing if the same cheque is entered, this exception is validated.
CHQ. CAUTIONED
When a cautioned cheque is used for transaction creation or inward clearing, this exception is
validated.
INTRODUCER NOT CUSTOMER
If the introducer is not an existing customer of the bank(introduction without specifying CIF id in
Introduction details column), this exception is validated at the time of account opening verification
.
INTRODUCER NEW CUSTOMER
In Finacle ™, the customers are treated as new customers for a specified period (as per set up in
HSCFM) from the date of CIF ID creation. If such CIF id is used for introduction, this exception is
validated.
EMPLOYEE’S OWN ACCT:
In CIF id, if staff is set as Y, staff id is a mandatory field. This staff_id is created using menu
option HEFM. When such CIF ids are used for account opening, the staff flag is default populated
to the account. Also, when an account is opened for a relative of the staff, then relative staff_id is
to be entered. When transactions are attempted in employee‟s own account/relative account, this
DR AGAINST CC
Whenever the transaction is against the shadow balance (i.e., clearing cheques that are not yet
regularised - unclear balance), this exception is validated.

CLS PENDING JOBS
When Account closure is attempted and interest calculation is pending, this exception is validated.
CLS PENDING S.I.
When Account closure is attempted and associated Standing instruction is pending, this exception
is validated.
CLS PENDING CHQ
When unused cheques are available for an account which is attempted for closure, this exception
is validated.
CLS PENDING PROXY:
This exception is validated when account closure is attempted for which some transactions are
pending in proxy accounts. This exception is raised when credit proxy posting is being done as for
debit proxy posting a lien will be marked and the system will prompt the user at the time of
account closure
SI PREFIX CHARGES:
This exception is not validated and hence can be left blank.
CHQ ISSUED BUT NOT ACKNOWLEDGED:
This exception is validated when chq is presented for payment which is issued but not
acknowledged. This depends upon a parameter set up in HSCFM.
CHQ UNUSABLE:
This exception is validated when the unusable cheques(viz cheques with status other than unused)
are presented for payment.
CHQ. STOPPED BUT NOT VERIFIED::
This exception is raised on cheques stopped but not verified. By setting the exception, one can
prevent the payment of stopped cheque. The time stamp of stopped cheque is that of the time its
verified.
HGSPM - CURRENCY DETAILS
CASH LIMIT (DR)
For cash debit transactions, when the tran amount exceeds the debit cash limit set in HGSPM ,
this exception is validated.
CLEARING LIMIT (DR)
For clearing debit transactions, when the tran amount exceeds the debit clearing limit set in
HGSPM, this exception is validated.

TRANSFER LIMIT (DR)
For transfer debit transactions, when the tran amount exceeds the debit transfer limit set in
HGSPM, this exception is validated.
CASH LIMIT (CR)
For cash credit transaction, when the tran amount exceeds the credit cash limit set in HGSPM, this
CLEARING LIMIT (CR)
For clearing credit transactions, when the tran amount exceeds the credit clearing limit set in
HGSPM, then this exception is validated.
TRANSFER LIMIT (CR)
For transfer credit transactions, when the tran amount exceeds the credit transfer limit set in
HGSPM, then this exception is validated.
CHANNEL CASH LIMIT EXCEEDED (DR)
For Channel cash transactions if the limit set for a channel has exceeded, then system validates
subject to the setup.
CHANNEL CASH LIMIT EXCEEDED (CR)
For Channel cash transactions if the limit set for a channel has exceeded, then system validates
subject to the setup.
CHANNEL TRANSFER LIMIT EXCEEDED (DR)
If the limit set for a channel has exceeded, then system validates subject to setup.
CHANNEL TRANSFER LIMIT EXCEEDED (CR)
If the limit set for a channel has exceeded, then system validates subject to setup.
DEBIT TRANS RESTRICTED
When debit transactions are made on an account, this exception is validated.
CREDIT TRANS RESTRICTED
When credit transactions are made on an account, this exception is validated.

EOD MIN BALANCE
This exception is raised by the system if the balance in the account at the time of eod is lesser
than the value mentioned at “EOD Min Bal” mentioned at the currency details of HGSPM provided
if the eod balance check flag is checked
EOD MAX BALANCE
this exception is raised when the account balance is greated than the value specified in the EOD
MAX BAL field
TRAN AMOUNT LIMIT
This exception is validated when the report code is made as mandatory and if the selected report
code for the transaction amount mismatches with the limit mentioned for each of the report codes
mentioned at the tran report codes sub option of HGSPM.
OPERATION ON CURRENCY HOLIDAY
The exception will be raised if any of the following account dates fall on the currency holiday:
Open date, transaction entry date, transaction posting date, maturity date, renewal date during
manual renewal, closure date for all participating account currencies.
HSCFM - DATA CENTER MAINTENANCE – EXCEPTION HANDLING TAB
COMB STMT CIF ID MISMATCH EXCP
When accounts of other CIF ID(non related accounts) is linked for combined statement printing
this exception will be raised.
CHARGE OFF ATTEMPTED FOR NON PAST DUE ACCOUNT
When accounts for which the status is not past due are attempted to be charged off, this
exception will be raised.
4.2.3 ACCOUNT PLACEHOLDERS
The account placeholders related are
 Int Paid A/c Placeholder: Interest is paid to customer accounts by debiting this office
account. This is the „interest payable/provision‟ account. This account is credited during
interest booking for credit interest application.
 Int Coll A/c Placeholder: Interest collected from the customer accounts is credited to
this account. This is the „interest collectable/provision‟ account. This account is debited
during interest booking for debit interest run.

 Serv Coll A/c Placeholder: NOT IN USE
 Int. Parking A/c. Prior to Tax Deducted at Source: Parking account (Intermediary
a/c) where interest amounts are credited for accounts involving customer level TDS
calculation. This account is credited during credit interest calculation and debited
subsequently during TDS calculation.
 Parking Account Placeholder: When the balance in the account is not sufficient for
debiting the interest, then an intermediary office account can be specified for debiting
(parking) interest. This office account is arrived based on the Account placeholder
specified here. This account placeholder can also be used for recovering shortfall from
office account in case of credit interest run.
 P&L A/c. Normal Int. Paid: Income - Expense A/c placeholder to which accrued credit
interest is debited.
 P&L A/c. Normal Int. Received: Income - Expense A/c placeholder to which accrued
debit interest is credited.
 P&L A/c. Penal Int. Received: Income - Expense A/c placeholder to which accrued
debit penal interest is booked.
 Tax Coll A/c Placeholder: This placeholder is used for pooling of taxes recovered from
customer accounts.
 PDC Contingent Dr PlaceHolder :This placeholder is used to arrive at the ontingent

debit account when the PDC‟s are lodged in the system not affected by margin mentioned
in HTAPM. The office account linked to the place holder will be partitioned by account ID
 PDC Contingent Cr PlaceHolder: This place holder is used to arrive at the contingent
credit account for posting the contingent entries when the PDC‟s are lodged in the
system.
 Interest suspense A/c Placeholder: Any interest, which is charged to the account, but
not realised, can not be recognised as an income and therefore needs to be reversed
from the Profit & Loss account. Such amount of unrealised interest reversed from the P&L
account is parked in a separate account for future recovery. This account is called the
interest suspense account.
 Provisioning place holders are used for creation of transaction for provisions done.
Provision account place holder (debit)
This place holder is set up at scheme level. The account is used for debiting the amount at
the time of asset provisioning.
 Provision account place holder (Credit)

This place holder is set up at scheme level. The account is used for crediting the amount at
the time of asset provisioning.
4.2.4 MISCELLANEOUS
The other set-up requirements are:
 Setting up the Interest Codes and Rates through HITCM, HIVSM
 Setting up Next Number codes for CIF id/TDS table code/a/c nos through HNNTM
 HASTM set up for TDS calculations and other charges
 HINSTM – Validity period for various debit instruments
 Setting up appropriate event_ids for various charge calculation processes
Creation of account placeholders and opening of office accounts for the placeholders in all the
SOLs for charges/interest/tax.
4.3 PARAMETER SETUP

This section covers the parameter set ups for handling Customer accounts under the scheme types
SBA, CAA, CCA & ODA are dealt in this chapter.
The scheme codes are created after creating the GL Codes and GL Subheads.
HGSPM is the menu option used for creation of scheme codes. These activities are explained
below.
4.3.1 SYSTEM CONTROL FILE MAINTENANCE
The following are the parameters that control the customer Id creation and accounts of the
customer at data centre level. The set ups are done through the menu option HSCFM.
New Customer Period: Period specified in months. Customer is deemed as new customer up to
the period specified here from the date of customer master creation.
Maximum Lines in Passbook: The number of lines that can be printed in each page of the pass
book. This is dependent on the pass book inventory used by the bank. Appropriate value has to be
entered here.
No. of Lines in Folio: The number of lines which is to be treated as one folio for Ledger folio
charges calculation. This value is considered for arriving at the number of folios for LF calculation.
Max No. of TODs per customer: This is a bank specific parameter. When the number of TODs
for a customer exceeds this value system validates and appropriate exception is displayed.
Segregate Interest and Principle during Charge off flag – to be selected when such
segregation is required by the Bank

Age when minor becomes major: This value is used to determine the date for changing the
status of minor to major. The period is expressed in number of years.
Image access code for Dormant a/cs: The image access code to be assigned for dormant
accounts is to be specified here. The users who has permission to this access code(created
through HRPM) only can view the signatures of such customers.
Clerk‟s work classification: The user who has work class greater than the work class specified
here can only authorise (verify) financial/non financial transactions.
Temporary A/C ID - Required: System provides facility for generation of temporary account
number which can be used for authorising the account opening and creating credit transactions to
the account. This number generation is not based on HNNTM set up. Alternatively, this flag is not
set, in which case the permanent account number is populated during account opening itself. This
number will not be available even if the account opening process is cancelled. Temporary account
number is prefixed with ZZ and is a numeric value which is a oracle sequence number.
IBAN Implemented: this will indicate whether to include IBAN in screens/downloads or not. This
parameter can have 4 values:
1) Only screen changes(IBAN to be shown on screen)
2) Only down load changes (download programs will include IBAN in downloads)
3) Both screen changes and download programs will have IBAN.
4) NONE (IBAN is not implemented)
A 34 character (alpha-numeric) field will be provided at the general account master to enable
the storage of IBAN against each customer account as well as the office account .IBAN will be
automatically generated by the system for the newly opened accounts. Hot key Ctrl+X will be
enabled to toggle between the account number and IBAN.
However in order to generate the IBAN for Accounts migrated to Finacle a menu option has
been provided : IBANGEN

In the Criteria screen User can input either cif id or account id or both. There will be Validation to
ensure that Acct Id belongs to the entered CIF ID.
If only CIF id is given, all valid operative accounts belonging to that CIF ID that do not have
IBAN number are listed in the listing screen. However if Acct id is given in the criteria screen, only
that acct id is listed in the criteria screen.
User can select the list of accounts for which IBAN has to be generated and then submit.
IBAN will be generated for the selected accounts and autoverified.
Future Value Dated Credit Flag & Future Value Dated Debit Flag: The valid values are Y/N.
When the “Future Value Dated Credit Flag” is set to „Y‟ and whenever any credit transaction is
happening with a future value date (i.e. value date greater than the BOD date), system will not
update the “Clear Balance Amount” of an A/c and instead increment the “Future Balance
Amount”. Whereas, if the value of the flag is set to „N‟, then the system will not touch the
“Future Balance Amount” at all and instead increment the “Clear Balance Amount” (i.e.
existing functionality prevails). Similarly the concept holds good for the Future Value Date Debit
Flag.
Num of Future days allowed: Once set, system will not allow future value date beyond the no.
of days specified.
Num of Back days allowed: If this value sets, system will not allow back value dated transaction
beyond the no. of days specified.
Cheque book Ack - Required: Bank can decide to make the cheque book effective only after
entry of acknowledgement by the customer. In such a case, this value has to be set. Else, the
cheque book is effective once the cheque book issue is verified by the user.
Acct Turnover Period Ind: Whether Account turnover details are to be generated based on the
account open date or the calendar. The frequency of generation of account turnover details is
specified at HGSPM which can be further modified at the account level.
Stop Payment: The event id for stop payment charge calculation is specified here in the fees tab
of HSCFM. Event id is created through HPTTM.
Stop Payment – Delivery Channel: When stop payment instruction is received through Delivery
channel (Connect 24), the stop payment charges could be different. In that case, the event id
defined for that purpose is to be assigned here. If the charges are same even when received
through BANCSCONNECT, then the same event id is to be specified.
Dormancy for CC/OD A/cs - Applicable Whether dormancy status is required for CC/OD
accounts or not is dependent on this flag.
Sweep A/c order: When a/cs of more than one scheme type is specified for the sweep facility,
then the order in which accounts are to be considered for SWEEP facility is specified here.
Duplicate Combined Statement: The event id for charge calculation for Adhoc printing of
combined statement
Regular Combined Statement: The event id for charge calculation for Regular printing of
combined statement.
Exception for Expired Limits for Dr. Tran: This flag will indicate whether the exception set at
general details for “Sanction limited expired” should be raised or not during debit transaction to an
account where limit is expired.
Case 1: Exception set at Scheme level. Flag is set. A debit transaction to the account
which results in credit balance, exception is not raised.
Case 2: Exception set at Scheme level. Flag is set. A debit transaction to the account
which results in debit balance, exception is raised
Case 3: Exception set at Scheme level. Flag is not set. A debit transaction to the account
which results in credit balance, exception is raised
Case 4: Exception set at Scheme level. Flag is not set. A debit transaction to the account
which results in debit balance, exception is raised.
Comb Stmt CIF Id Mismatch Excp: When the non-related account is linked for Combined
statement facility, this exception is validated.
Sweep Relation Mismatch Excp: When the account linked for sweep facility is not a related
account this exception is validated.
The HNNTM code set for customer number generation is to be specified here. The prefix/suffix for
a customer_id can be SOL ALIAS, DC ALIAS, SERVICE OUTLET ID.
GLCODES AND GL SUB HEAD CODES CREATION

These codes are created using HRRCDM & HGLSHM menu options.

4.3.2 CREATION OF SCHEME CODE USING HGSPM
MENU OPTION: HGSPM
Set Id: the SOL set ID for which the scheme is applicable is entered in this field
Effective Date: the date from which the scheme code has to be effective. The date specified in
this field should be a valid date that is greater than or equal to the BOD date.
Expiry date: The date till which the scheme code is effective
Tran Restriction: The valid values for this field are C- Credits Not Allowed D –Debits not
allowed and B – Both Debits and Credits not allowed for accounts opened under this product. Used
to restrict the debits or credits or complete transactions.

Account ID Generation: Whether the account numbers of accounts opened under this scheme
have system generated account numbers or user entered account numbers.
Min Post.workclass: The minimum workclass required for posting financial transactions of a/cs
opened under this scheme.
Acct Prefix & Sequence: Acct Prefix for the account number field. This can be used as one of
the prefixes/suffixes for account number generation. Sequence is the Nxt Nbr Tbl code defined in
HNNTM for automatic generation of account numbers.
Non Resident: User can indicate if residents,non residents or both can open accounts under this
scheme.
FCNR scheme? - whether the scheme is an FCNR scheme. This is applicable only in Single
Currency mode.
Acct Closure Across SOLs awd? This is to enable Acct closure by any of the SOLS.
Rpt Tran? flag indicates if a report with a list of transactions is to be generated, for accounts
belonging to this scheme. If the Rpt Tran flag is checked then the Tran Report Codes are to be set
using T – Tran Report codes sub option in HGSPM.
Staff Schm: Valid values Y & N. It is possible to restrict opening of accounts under the scheme to
customers who are employees of the bank only.
TRANSACTION ACCOUNT SCREEN
New Account duration: The number of months from the account opens date till which the
account is treated as a new a/c.

Min Acct Closure Period(Mths/Days): The number of months/days within which if the a/c is
closed, A/c closure charges to be levied.
Account Maintenance Period(M/Q/H/Y): The periodicity for collecting Account maintenance

charges.
Dflt clg tran code & Dflt inst type: The default clg tran code and instrument type for this
scheme is to be entered here. These values get default populated during lodging of inward clearing
instruments.
Commitment Fee calc method & Min Commit utilisation: This is applicable only when limits
are sanctioned to an account.
Dormant Fee Period(MM/DD) & Inactive Fee Period(MM/DD): The maximum number of
months for which the account can be dormant without being penalized.
Chq allowed: Indicate if cheques are allowed for accounts opened under this scheme
Account statement: the frequency of the pass sheet printing for the accounts opened under this
scheme is mentioned here
Turnover details: If the turnover details like the average balance, total credits, total debits are
required for an account opened under the scheme then the flag should be checked . Turn over
details frequency must be mentioned in the next field if the turn over details flag is checked.
SCHEME DETAILS FOR SCHEME TYPES SBA & CAA
No of withdrawals: The number of withdrawals permitted during the month.

No Int If withdrawals exceed: If the value is set to „YES‟ then no interest is computed for such
months. When the value is set to „NO‟ interest is computed for all the months irrespective of
whether the no of withdrawals exceed the set parameter.
Min bal with chq: Minimum balance required for cheque book facility is to be entered here. This
is associated with an exception while chq book is issued to an a/c.
Debit balance limit: The maximum debit balance that an account can have under the scheme.
This is also associated with an exception.
Ledger folio Fee/folio: The charges prescribed for LF is entered here. This will be provided as an
input in the mrt dump for LF charge calculation.
Service Charge/extra withdrawal: Currently there is no menu option available for charge
calculation for extra withdrawals. Hence, this field may be left blank.
Inactive a/c/Dormant a/c Abnormal transaction limit: Abnormal transaction limit can be
set for Dormant and Inactive accounts. When the transaction amount exceeds the specified limit
an entry is made in the abnormal transactions list which is available for inquiry/report generation.
Duration to Mark A/c as Inact. The period is specified in months. When there are no customer
induced transactions in the account for the specified period, the status is changed to Inactive
account. When customer induced transactions are attempted in inactive accounts, an exception
can be set which will be validated. Also, charges can be prescribed for Inactive accounts. There is
also a flexibility to specify additional conditions by way of customization for handling status
change of accounts to dormant or inactive. A script by the name MarkAcctsInactiveDormant.scr
has to be present in the relevant path for adding additional criteria for marking account status. If
in case the script is not present batch job will be executed as per existing behavior. A Script hook
is added to the existing Inactive Dormant Batch job to facilitate marking of accounts to dormant or
inactive. The existing behavior is not altered with the introduction of the script hook.
The script (MarkAccountsInactiveDormant.scr) when present and returns account status will
override the existing criteria for marking accounts as inactive or dormant. The script will have
various fields available in it, which can be utilized to form the criteria for marking accounts as
inactive or dormant. Account Status will be taken as output from the script for every account
which is selected for marking as inactive or dormant. The account status can be set in the script
which will be updated accordingly.
User can mark the accounts as Inactive (I) or Dormant (D) or can choose not to change the
status; in that case only account status date is updated with the BOD Date for that particular
account.

Duration From Inact. to Dorm: The period(in months) after which Inactive status is changed to
Dormant status for an account. Specific charges can be associated with Dormant status accounts
and also validate for transactions in the dormant account through an exception set for the
purpose. There is also a flexibility to specify additional conditions by way of customization for
handling status change of accounts to dormant or inactive. A script by the name
MarkAcctsInactiveDormant.scr has to be present in the relevant path for adding additional criteria for
marking account status. If in case the script is not present batch job will be executed as per existing
behavior. A Script hook is added to the existing Inactive Dormant Batch job to facilitate marking of
accounts to dormant or inactive. The existing behavior is not altered with the introduction of the script
hook. Account Status will be taken as output from the script for every account which is selected for
marking as inactive or dormant. The account status can be set in the script which will be updated
accordingly.
User can mark the accounts as Inactive (I) or Dormant (D) or can choose not to change the status; in
that case only account status date is updated with the BOD Date for that particular account.
The script (MarkAccountsInactiveDormant.scr) when present and returns account status will override
the existing criteria for marking accounts as inactive or dormant. The script will have various fields
available in it, which can be utilized to form the criteria for marking accounts as inactive or dormant.
Domant Fee and Inactive Fee: Event ids can be specified for levying prescribed charges for
dormant and inactive accounts at specified frequency. These event id‟s are created through HPTTM
Allow Sweeps ? : Whether the accounts opened under the scheme is eligible for Sweep facility or
not. The flag value set here is default populated to the account.
Debit against unclear Bal: whether the accounts opened under the scheme should be eligible for
debit against the clearing credit or not.
Interest Calculation Parameter Details( For SBA Scheme Type only)
Interest Method : Valid values are M-Minimum balance, A-Average balance and E-EOD balance .
This is to enable which balance to be considered for computing the product for interest
calculation.
Balance Between And Of The Month: When the value is M or A for the above column,
then entry of these fields is mandatory. When the value is E, this is optional.
The appropriate exception codes are to be assigned in the Exception codes screen based on the
scheme specific requirements.
Dormant frequency code and Inactive frequency code
Here the user can define the frequency in case of dormant accounts and inactive accounts


SCHEME DETAILS FOR CCA SCHEME TYPES
SCHEME DETAILS FOR ODA SCHEME TYPES
Maximum Sanction Limit: The aggregate of the total sanctions made for an account is
validated against the value entered here. Appropriate exception code is created in General Details
for the same.

Debit balance limit: The debit balance in the account is validated against the value entered
here. Appropriate exception can be set for this in Exceptions details in the subsequent screen.
Maximum Penal Interest%: The maximum cap on the penal interest % can be specified here.
When the aggregate of Additional, QIS, Stock statement and Penal interest components set up
through IVSM exceeds the limit specified here, then this value is considered for penal interest %
during interest calculation.
Ledger folio Fee/folio: The charges per folio can be entered here. This is provided as an input
to mrt for LF charge calculation.
Inactive A/c/Dormant A/c Abrnml Tran Lim: The transaction limit for Inactive and Dormant
account which is treated as abnormal transaction amount can be set here. An inquiry option „ATI‟
is provided to view the transactions which have exceeded the limits set above.
Duration to Mark A/c as Inactive: The duration for marking an account as „Inactive‟ when
there are no customer induced transaction for an account for the period specified here.
Duration to Mark A/c From Inactive to Dormant: The period which is to be considered for
marking the status of an Inactive a/c as Dormant, when there are no customer induced
transactions for the period specified here.
Dormant/Inactive Account Charge Event: The appropriate event ids set up through HPTTM
for Dormant/Inactive account charges calculation is to be specified here.
Allow Sweeps? Valid values are „Y‟ and „N‟. The value entered here is default populated to the
account during account opening.
The valid exception codes created through EXCDM has to be entered here in the appropriate
columns for proper validations(depending on the scheme specific requirements).
Revolving Facility (For ODA scheme type of accounts): Whether revolving OD accounts are
opened under this scheme or not depends on this flag. More regarding revolving OD is explained
later in this document.
If Revolving Facility is set as „Y‟, following details are to be maintained. These details are specific
to revolving OD/CC/Bills. The screen interface is as below.
Revolving OD/CC/BILL PARAMETERS:

Billing frequency: This is the frequency at which bill is raised for an account with this facility.
This frequency basically determines when to raise a bill for an account.
Minimum Payment %: The percentage of total outstanding that will be considered as minimum
payment. If it sets as 2% and outstanding is Rs. 10,000. Minimum amount due will be 2% of
10,000 i.e. Rs. 200.
Minimum Payment Amt: This is the minimum amount for which bill will be raised if the
percentage of total outstanding is less than this amount. But if the outstanding balance of the
account itself is less than this minimum amount, bill will be raised for the outstanding balance of
the account.
Penal interest on minimum amount due or outstanding: This determines whether penal
interest will be only on the overdue minimum amount or on the outstanding. If this flag sets as
“M”, only overdue minimum amount due will be considered for penalty else it will be on
outstanding amount as of billing date.
Include Accrued Int In Min Amt Due: This is a flag which determines whether the accrued
interest amount up to the statement end date (billing date) to be included in the minimum amount
due.
Include Late Fee In Min Amt due: This flag indicates whether the late fee (if any) of the
previous cycle to be included in the minimum amount due.
Late Fee Charge Event Id: Late fee charge event id. This will be a HPTTM event id under event
type RODLF. If event id is not entered, no late fee will be charged.
Apply Penal Interest / Late Fee/Both : If this is „P‟, penal interest will be applied. If this is „L‟,
late fee will be charged. If this is „B‟. both penal interest will be applied and late fee will be
charged.

Payment Period (Days): This is the number of days after the statement end date that will
indicate the payment due date. If it is set as 10 and billing date 31/1/2002; payment due date will
be 10/2/2002.
Grace Period (Days): This is the grace period after the payment due date. Bill will be considered
overdue only after the grace period. Payment made within grace days will not be charged any late
fee. Grace days will be considered for penal interest.
DPD to start after grace period: This indicates whether DPD will start after grace period or not.
If value is not set or is set as N, DPD will start from the next day of payment due date.
Tolerance % for DPD: This is the percentage of minimum amount due. If overdue is within this
percentage, bill will not be considered for DPD. Say if the value is 10%, ie ieven if the customer
pays 90% of the minimum amount due then it will not be considered for the DPD.
Consider tolerance for late fee: “Tolerance % of DPD” will also be considered for late fee
charge if this flag sets as Yes (Y). If flag value is Y (Yes) and overdue within this percentage, bill
will not be charged with late fee.
Auto Renewal Parameters:

Utilized % of sanction limit for renewal: The percentage of average utilization of the limit
throughout the tenor should be greater than or equal to this value.
DPD cycle during tenure: The DPD throughout the tenor should be less than equal to this cycle.
Asset classification: The current asset classification of the account should be this.
Renewal Period (yrs/mnths): The period for which the account will be auto renewed.
If renewal period is set as null, auto renewal of the accounts under this scheme will not happen.
OTHER SETUPS FOR REVOLVING OD ACCOUNTS:
- Following MRTs for success/renewal letters have to be added under module id “ACCT”.
Bill generation – REVOD_BILL_GEN

Bill and collection history – REVOD_BILL_HIST
Renewal letter – REVOD_AUTO_REN

CURRENCY DETAILS – CURRENCY TAB


In the currency details tab, in page 1 we attach different event ids for collecting charges. These
include stop payment event id, passbook issue fee, commitment fee etc.,

In page 2 Interest tax and rounding off parameters are defined. Eg: we attach the interest table
code here. This interest table code gets defaulted at the time of account opening. Similarly we
define ethe minimum and maximum rates of interest here.
In page 3 of currency details we define the transaction limits, channel parameters, EOD balance
parameters and report codes.
In the screen 4 of currency details various exception codes are attached which get validated based
on the events.
Cr Int Rate code & Dr Int Rate Code:
The rate codes to be used for converting the interest amount into home currency when interest
accounts are maintained in home currency only.
Default Customer Preferential to Account ? If the value is set as „Y‟ then customer
preferential specified in CIF id is default populated to the account.
Ac.Open fee, Ac.Mtc.fee, Ac.Cls.fee, Ledger Folio Calc fee, Adhoc Pass Sheet Print fee, Regl Pass
Print fee and Commitment fee
The specific event ids created for charge calculation for the above specified events are specified in
HPTTM and the same is assigned here.
Int Table Code: The default interest code used for interest calculations for accounts falling under
this scheme is defined here. All other interest related parameters are explained in the „Interest
Calculation document‟.
MICR Chrg Event: The event id created through HPTTM for MICR cheque book charges is to be
entered here.
MINIMUM BALANCE DETAILS

Min.Bal.Fee Event: The event id created through HPTTM for minimum balance charges
calculation is to be entered here.
Acct min bal: The minimum balance to be maintained for accounts opened under the scheme is
entered here.
Include min bal for sweeps: Valid values are F - Funding account only, T - Target account only,
B - Both Funding and Target account, N - None This flag value will decide whether the minimum
balance also is to be included for sweep process When the account opened under the scheme is
used as Funding account only(F)/ Target account only(T)/used as either funding or target
account(B) or should not be considered in both the cases.
Minimum Fee period: Penal charges for non-maintenance of minimum balance for a specified
period.
Penal Fee period: The period specified in months which is to be considered for penal charges
specified above.
Minimum bal Fee: The charges to be levied for non maintenance of minimum balance.
Note: All the values entered relating to minimum balance charge calculation is passed as an input
for charge calculation.

Also, appropriate exception codes created through HEXCDM has to be entered in the valid columns
of the above screen.
Currency Based Tab – Linked Collaterals, is provided for Product Level Parameter Maintenance.
Following parameters are accepted in this tab.
• Is Loan Against Collateral
• Collateral Type
• Mark Up Applicable
• Mark Up Interest Method
• Mark Up %
• Recalculation of Interest on pre-closure
These parameters determine the property of Loan/OD accounts. However, user can override these
parameters at Account Level. Exceptions will be thrown in case if user overrides the Product Level
parameter values at A/c. Level.
Following Exceptions can be set at Product Level.
• Linkage of Third Party Deposit
• Loan Maturity Date greater than highest Deposit‟s Maturity Date
• LTV/Margin not confirming to Product Rules.
• Default Interest Parameter changed.
Restrictions/Validations
 All the parameter and exception related fields in Linked Collateral Tab will
be enabled only if Is Loan Against Collateral Flag is selected as YES.
 If Loan Against Collateral Flag is YES, then setup/parameters related to
DL/UIC is restricted.
 If Loan Against Collateral Flag is YES, then parameters related to Planned
Deferment can not be set.

VALID INSTRUMENTS ARE ENTERED THROUGH “INSTRUMENTS” TAB
Through this sub option, user can specify the valid instruments which can be used for credit/debit
transactions. The instrument codes should have been defined through HINSTM menu.
VALID GL SUB HEAD DETAILS ARE ENTERED THROUGH “GL SUB HEAD” TAB
The valid GL subheads that can be used for accounts opened under the scheme is specified here.
Also, the GL subhead code which has to be default populated during account opening can be set
as „Y‟. The flag value „Y‟ can be assigned to any one of the GL subheads specified here.

LEDGER FOLIO DETAILS ARE ENTERED THROUGH “LEDGER FOLIO” TAB.
The amount range with the number of permitted free folios can be specified here. This information
is passed on the mrt for Ledger folio charge calculation.
TOD REFERENCE DETAILS ARE ENTERED THROUGH “TOD REFRENCE”TAB

The details of values to be entered here is explained in detail in „Temporary Over drawings‟
document.
INTEREST DETAILS – INTEREST TAB
The interest related parameters are explained in the Interest calculation document which has to be
referred for setting up the appropriate parameters. Loan scheme Related parameters is specific to
scheme codes opened under LAA scheme type.

ASSET CLASSIFICATION DETAILS ARE ENTERED THROUGH ASSET

CLASSIFICATION TAB.
The details to be entered in the above screen are dealt in detail in Asset Classification doc.

LOAN PAPER/DOCUMENT DETAILS – DOCUMENTS TAB
The document details relating to the accounts opened under the scheme can be specified here.
The various documents which are mandatory and non-mandatory have to be codified through
HRRCDM and appropriate codes have to be entered in the above screen. Based on this, report can
be generated for the pending documents.

DSA DETAILS – DSA TAB
The appropriate values to be entered for DSA details are dealt separately in „DSA‟ document.
The scheme code once created needs to be verified using HGSPM. All scheme codes will
be effective once created from next login. Hence user needs to log out and login.
5 GENERAL USER ACTIVITIES

The following sections outline the general user activities.
5.1 CREATION AND MAINTENANCE OF CIF

For creation of a customer account, a CIF is needed. For further information on creation and
maintenance of CIF, please refer to the CIF document.

It is possible to generate a list of customers who are becoming major today using the menu
option HCBM. The screen shot looks as below.
5.2 FINACLE CORE SPECIFIC CUSTOMER DATA

Creation of customer master is done using CIF. However, some data is still required to be
maintained in Finacle Core. This is accomplished using the menu option HCCFM.
We capture important information like whether sweeps allowed for the customer, whether
combined statement is allowed, charge turnover required or not using this menu option.
Also in case of trade finance customers we capture the buyer seller limits through this tab.

Any changes made using HCCFM menu option need to be verified by the same menu option.

5.3 CUSTOMER ACCOUNTS OPENING ( SB, CA, CC, OD)
 The account can be opened for a customer under a valid GL subhead, scheme code and
Currency Code combination.
 The scheme based details for opening the account are accepted depending upon the
scheme under which the account is opened
 The Authorised signatories, account nomination details can also be captured as part of
account opening.
 A temporary account number is assigned on acceptance of the data entered for opening
an account. This is dependent on the data centre level parameter HSCFM Temporary
Account Number Reqd ?
 The account number can be assigned manually or can be set for the system to generate
the account number. If the account number is not system generated then the user has to
assign it at the time of verification.
 Credit Transactions can be done even before verification of the account opening using the
temporary account number. Debit transactions are not allowed on unverified accounts.
 Exceptions set in HGSPM/HSCFM are handled as part of account

opening/maintenance/closure.
 Consolidated statement of all the accounts of a customer can be generated
 Transaction/Cheque status reversal is possible
 A 34 character (alpha numeric) field is provided at the general account master level to
enable the storage of IBAN against each customer account as well as office account.
 IBAN will be automatically generated by the system for the newly opened accounts
 A script hook is provided to validate the IBAN when manually given on screen . the
output of the script will be success or failure(ie valid IBAN or not).
 The ease of data capture is a pre-requisite for efficiency and Productivity and is
much needed for optimum resource utilisation. For this, Banks require a
functionality to create pre-filled up forms for common activities such as Account
Opening.
 IBAN will be generated during account opening verification and will be shown on the
screen along with account number after the account is successfully verified.

5.3.1 OPENING AN ACCOUNT

For customer accounts, the various menu options used are
- SB acct – HOAACSB
- CA acct – HOAACCA
- CC acct – HOAACCC
- OD acct – HOAACOD
All the above menu options have following sections to capture relevant details
- Template ID field and searcher is available in the criteria pages of these menu options
along with a dropdown for indicating normal account opening or copy from template mode.
The default value for the dropdown will be “O-Open an Account”. Template ID will be enabled
only in “Copy from Template” mode. The screen interface for the same is as under:
On change of the template ID, template data will be populated in the criteria page.
- General Details
- Interest Details
- Scheme Details
- Nomination Details
- Related Party Details
- MIS Codes

- Payment System
- Other Details
- FFD Parameters
- Document Details
- Account Limits
- Link collaterals (only for OD/CC accounts)
Note: Not all the above sections need to be visited for account opening. Depending on the
type of account, visit the relevant sections.
Screen interface for all the sections except the scheme details are same.
A tab Link Collaterals, is available in Account Opening (HOAACOD/HOAACCC). This tab is

optional tab. If the scheme entered by the user in criteria supports LAD, then user will be
forced to visit this tab after General Details Tab and before visiting any other tab.
This tab is a multirec screen and will have following fields.

 Collateral Code
 Entity Id – It‟s a deposit Account Id. On tab out, following values will be displayed
to the user.
• CIF Id – CIF Id of Linked Deposit A/c.
• Bal. Tenor – Balance Tenor of linked deposit.
• Collateral Rate – Interest rate attached to linked deposit A/c.
• Deposit Amount – Total Deposit Amount.
• Bal. Apportioned Amt. – This is the amount available for Linking net to lien
placed on Deposit Account. It is a display field and populated when deposit
account is entered.
 LTV % - It is default populated, when collateral ID is entered. But user can modify
this.
 Apportioned Amt – This is the amount to be utilized for loan while linking this
account to loan account.
 Lendable Amt – This is display field and is populated by applying LTV on
apportioned amt.
Other than the multirec fields, following mark up level values are accepted. The values
in these fields are defaulted from Scheme Level Setup. User can override these values.
 Mark Up Applicable – Radio Button with Yes/No
 Mark Up Int. Method – A selection field with Ascending, Descending, Weighted
Average and Highest as valid values. This will be disabled if Mark Up Applicable
flag is „No‟.
 Mark Up % - A field accepting numeric values. This will be disabled if Mark Up
Applicable flag is „No‟.
In Accounts Limit Tab, the sanction limit is populated with the sum of lendable amounts of
Linked Deposits. However user will be able to modify it. But DP will be the sum of lendable
amounts. Also Drawing Power Indicator will be populated with D- Derived and will be
protected. In case of OD/CC accounts, user will not be allowed to select Limit Level Interest.
All the Linkage related details are stored in LAC_CLT table.
During Verification of the account, linkage will be created between Loan/OD/CC A/c with
Linked Deposit A/c. Also, lien equivalent to Apportioned amount will be marked on Linked
Deposit A/c.

HOAAC (SB/CA/CC/OD) are the menu option used for capturing information at the time of
opening any customer account - SB, CA, CC or OD account. The values specified in HGSPM/CIF id
get defaulted during account opening based on the scheme code and the customer id specified
during account opening. The screen interface is as under
The user has to specify the CIF Id for whom the account is opened, the currency code and the
valid Scheme Code. System populates the default GL subhead code specified at HGSPM. If no
default GL subhead code is specified and more than one GL subhead is defined at HGSPM, the user
has to procedurally enter the GL subhead code and press GO. Also, the permanent account
number needs to be entered if the parameter value at the scheme code level Sys. Gen A/c No.? is
set to „N‟. The currency code defined while opening account should be defined both in CIF ID and
at scheme code.
The main screen of account opening is then displayed and the user has to specify the details of the
account. The values specified at HGSPM and CIF are default populated during account opening.
GENERAL DETAILS:

A/c open date by default is the BOD date. This date can be modified.
A/c Name: the name of the customer will get default populated based on the CIF ID entered
which can be modified during the account opening . The modification is validated through an
exception linked at the general details of HGSPM.
A/c Short Name: here the short name of the customer gets default populated from the CIF Id .
the short name is used for account retrievals.
The cash, clearing, Transfer Exception limits Dr & Cr will get default populated from the HGSPM of
the scheme code under which the account is being opened. These limits can also be changed at
the account level.
Fee Level Code is the charge level code specified at CIF level. This code is used for
concession/discount. This code can be changed or removed while opening the account.
Account Manager is the field where the relevant manager for the account is specified. The look
up searcher for ‘Account Manager’ has been provided to capture the relationship managers from CRM in all the customer
account opening/modify menus. The lookup searcher for account manager will display all the users who are designated as
Relationship managers in CRM. In all the customer account opening /modifying menus, the validation is handled for the
account manager field. The account manager should be a valid core user and also he should be a valid relationship manager
in CRM
Mode of operation: Appropriate code can be entered here. This is a display field during
transaction creation.
Collect Fees: This column used to indicate whether charges should be collected for this account
or not. If this is not set, then charge calculation will be skipped for such accounts.
Turnover Details: This column value will determine generation of account turnover details.
Also, when the account is opened for relative of a staff, then the flag can be set and the
employee id of the relative staff can be entered. When these values are entered, during
transaction creation, if the tran is created in such a/cs by such employee, system validates for the
same and appropriate exception set at the scheme level is displayed.
Account statement is a mandatory field. It is possible to enable the account for statement
generation/pass book generation or both or none. When „S‟ or „B‟ is entered for A/C statement,
then entry of frequency is mandatory.
If the value specified is “Pass Sheet”, the frequency of pass sheet, despatch mode have to be
specified.
Allow Sweeps: This will determine whether the a/c should be considered for SWEEP facility or
not.
ECS Enabled: The parameter specified here decides whether this account is enabled for Electronic
Clearing or not. More about ECS is covered in ECS document.
INTEREST DETAILS:

All interest and tax related parameters can be entered in Interest Details screen.
Int. Cr. A/c. Flag : the valid values are O - Operative A/c,S - Original A/c., T - Payment
System
Facility is provided for giving preferential rate of interest(more credit or debit interest) to the
customer and to the accounts of a customer. This can be done by using the customer preferential
and account preferential fields. The customer preferential can be specified during CIF ID creation
which can be modified at account level.
Account Pegged: It is possible to make the interest rate constant for a specified period using
the following facility.
If this flag is set and pegging frequency is given, then any change in the interest rate is not
applicable to this account. All such accounts are to be reviewed on review date else the interest
calculation does not go through for these accounts. There is an option CIPPRPT which gives the
report of all such accounts which are to be reviewed.
Here, the Customer Pref. Interest (Cr) and (Dr) flags indicate the percentage of corresponding
(credit or debit) preferential interest at the account level. The Account Pref. Interest (Cr) and (Dr)
flags indicate the percentage of corresponding preferential interest at the account level. A positive
or negative value can be specified. The Account Pegged flag indicates whether the interest rate for
the account is to be pegged. The Pegging Review Date indicates the date until which the account
is pegged. The pegged interest rate for the account will automatically be reviewed by the system
on this date. The Pegging Frequency is the frequency in Months and Days for pegging of the

account. The interest rate code will get default populated from the scheme level which can be
modified and also the interest calculation frequency.
Also, interest calculation frequency and next execution date can be specified.(both for debit and
credit interest run). This will be useful for batch processing of interest calculation.
APY & APYE : These measure the actual interest paid in the account based on the interest rate
and the compounding frequency. The fields have to be populated with Zero while opening the
Account.The Apy is calculated by the system during the verification process and is displayed
during Inquiry.
Tax Details : The relevant details have to be fed in the fields if tax has to be recovered on the
Interest paid. The mechanism of recovery is similar to that of the tax recovered for TD accounts
.Thge menu option WTAXACCR will be used to collect the tax.
The related details set up is explained in TDS document.
SB and CA account specific scheme details are captured as part of the following screen.
SCHEME DETAILS:
Cheque Allowed: Whether cheque book facility to be allowed or not.

Recover Fee for Chq. Issue: Whether cheque book charges to be levied or not.
Nomination: Whether Nomination is required or not. If this flag value is „Y‟, entry of nomination
details is mandatory.
Dr Balance limit: Here the debit balance limit can be set for the account which will be validated
against the exception set in HGSPM.
Max. Allowed Limit: The ceiling limit on the sanctions for an account. When the aggregate of
sanctions made to an account exceeds this limit, the system validates for the exception set in
HGSPM.
In case of transferred accounts, facility is provided for capturing of pending interest amount(Dr
or Cr), account balance and the minimum balance during the month of transfer which needs to be
considered during next interest calculation. The relevant columns are Interest Amt (Dr/Cr),
Minimum balance and account balance.
RELATED PARTY DETAILS:
To capture the power of attorney holder information, letter of authority information, joint holder
information and authorised signatories information, the following screen interface is provided.

The first record in Related Party Details is populated from the CIF id. All other joint holders for an
account can be assigned here for specific business purposes like generation of account statement,
SI advice, Deposit maturity notice, loan notice, combined statement, entry of the validity period
and the amount limit for joint holders. Relation type and Relation code of the joint holder to the
a/c has to be entered here. It is to be noted that the joint holders need not have a CIF record.
Also, the address default populated from customer master can be modified here. The list of joint
holders to an account
NOMINATION DETAILS:
The nomination details can be maintained in the system and these details are captured while
opening or maintaining the account.. This is a co-mandatory screen. User can invoke this screen
only if the nomination flag is set in scheme details.

MIS CODES:
MIS codes can be entered for the accounts opened using this screen interface.
Entry of details are through the codes which are created using HRRCDM. The entry of appropriate
codes is useful for generating various MIS reports.

FFD PARAMETERS:
System supports Flexi Fixed deposit facility. Under this, the customer has the option to choose for
making deposits under specified scheme for specified period when the balance in the operative
account exceeds specified threshold limit. Also, the funds available in the linked Fixed deposits can
be used for passing debits in the operative account which automatically gets adjusted by
part/premature closure/closure on maturity. The screen interface for the same is given below.

FFD scheme code/GL sub-head: The Term deposit scheme code and the GL subhead code to
be used for making deposit out of surplus funds.
Auto Sweep: Whether system should take care of SWEEP in or not.
On entering the FFD Scheme Code and pressing the validate button all the scheme details will get
populated like int rate code, GL subhead code, auto renewal details,link to operative account, next
sweep out date,safe custody, print receipt, tax category etc.
There is a special feature in auto sweep. If the auto sweep has to be run for specific condition for
a certain days or for certain types of accounts only, then the Bank can make use of two sample
scripts for this purpose.
They are:
PreFFDSweep.sscr - In this script user can give the dates for which he doesn"t want to run the
FFDBATCH.
FFDSweepCrit.sscr- In this script user can define the condition for selection of account.
Sweep out In Multiples Of: The multiple amount which is to be considered for SWEEP. (in steps
of 1, 10,100 etc)
Sweep out Deposit Period & Sweep out Frequency: The period for which deposit is to be
made out of surplus funds and the frequency at which sweep has to be considered for the account.
Next Sweep in date is populated based on this frequency.

Sweep-out when Bal Above: The threshold balance in the operative account. The balance in
excess of this amount is considered for making deposits.
Next Sweep out Date: By default this date is BOD date and this date can be maintained by the
user. Next Sweep out date gets updated based on the frequency set up above.
Also, facility is provided for renewal of the sweep in deposits on maturity and specifying separate
interest rate code for Flexi deposits. These parameters can be entered in the above screen. This
aspect is explained in more detail in Term Deposits document.
DOCUMENT DETAILS:
The details of documents can be captured using the following screen.
Document codes are reference codes created using HRRCDM.
PAYMENT SYSTEM:
If the Interest credit flag is set as T-Payment System in “Interest Details”, then payment system
details can be captured using the following screen interface.

More about payment systems is explained in the document on payment system.
OTHER DETAILS:
The details like SWIFT, DSA and Account Label are captured as part of below screen interface.
SCHEME DETAILS (CC/OD ACCOUNTS);

Whenever an account is opened under a scheme code applicable to CCA and ODA scheme type,
the following screens is shown for capturing data under scheme details.
Max Allowed Limit: The aggregate of sanctions made to an a/c cannot exceed the value entered
here.
System populates the customer health code from customer master. Account health code can be
assigned here. Health codes are reference codes.
Interest Amount: This is applicable in case of opening of transfer in accounts. This field can be
used to capture the pending interest amount(debit/credit) to be considered during next interest
calculation.
ACCOUNT LIMITS:
Sanction details for an account can be specified during a/c opening through this option. While
entering the sanction, the sanction applicable date(start date), sanction limit, sanction expiry
date, penalty period(the period after which the sanction has expired) for penalty rate
documentation date, review date and other sanction details can be entered. Also, the interest rate
specific to the sanction can be specified here by setting the „Limit Level Interest‟. Normal and
penal interest rate can be specified if the limit level interest flag is set. Care should be taken to
see that the preferential are also included in the rate specified, if required, as the system does not
load the preferential to the interest rate during interest calculations when the limit level interest
flag is set.
Drawing power details can be entered as part of the same screen.
Here the Drawing power can be „E-Equal to the sanction limit, „D-Derived from the securities, „M-
Maintained by the user or „P-Parent i.e percentage of parent limit. Here „M‟ indicates that the user
can enter any amount.
Also, the DACC limit can be specified during account opening which can be an absolute amount or
percentage of the shadow(unclear) balance.

Sanction limit and drawing power can be set using HACLHM menu also. User can add multiple
limits using HACLHM.
Once all the details are entered click on <SUBMIT> button. Account creation requires verification.
Credit transactions can be posted even before the account is verified.
DAFA Limit -%" and "DAFA Limit - Absolute(where DAFA stands for Debit Against Future Amount):
The values given for either or both of these fields will be used to calculate the Dafa Limit amount
while posting a future dated transaction on the account created.
The minimum of "DAFA Limit amount from percentage" and “DAFA Limit Absolute" will be taken as
the DAFA Limit.
LOAN AGAINST DEPOSITS
CONCEPTS AND EXAMPLES
Deposit(s) can be linked during opening of Loan/OD accounts itself. It determines the
sanction limit, applicable interest rate, loan tenor, sanction expiry date (for OD a/c). These
are determined as below.
Sanction Limit/Loan Amount

Sanction Limit or Loan Amount is determined as sum of Lendable Amounts derived
from Linked Deposits.
Lendable Amount is derived by applying the LTV on apportioned amount.
Example:
Deposit Amt : Rs. 1,00,000.00
Existing Lien : Rs. 10,000.00
Balance Apportioned Amt. : Rs. 90,000.00 (Deposit Amt. – Existing Lien)
LTV % : 90% (Specified By User)
Apportioned Amt. : Rs. 80,000.00 (Specified By User)

Lendable Amt. : Rs. 72,000.00
So Sanction Limit (or Loan Amount) will be Rs 72,000.00.

In case multiple deposits are linked, Lendable amounts for each deposit is derived and
summed to get the sanction limit (or Loan Amount).
DP will be equal to the sanction limit.
Applicable Interest Rate

User has choice to select from Account Level or Mark up Level Interest Rate.
In case of Account Level Interest Rate, the interest rate is determined from Interest
Table code specified at Loan/OD Account Level. This is the existing feature.
In case of Mark up Level Interest Rate, applicable Interest Rate is derived from the
Linked deposits. It is calculated on the basis of Mark Up Rate pcnt and Mark Up
Methods specified by the user.
Mark up Rate is the spread applied to the interest rate applicable for Linked Deposits.
If multiple deposits are linked, Interest Rate is derived using any of the following
methods.
Ascending –
Interest Rate will be applied in ascending order of Interest Rate of Linked
Deposits.
Descending –
Interest Rate will be applied in descending order of Interest Rate of Linked
Deposits.
Highest –
Highest Interest rate among the Linked Deposits will be applied.
Weighted Average –
Weighted Average of Interest Rates of Linked Deposits is applied.
Example:
Linked Dep A/c. Apportioned Amt. LTV Lendable Amt. Dep. Int. Rate
TD1 Rs. 50,000.00 75% Rs. 37,500.00 6.5%
TD2 Rs. 1,00,000.00 75% Rs. 75,000.00 7%
Sanction Limit : Rs. 1,12,500.00

Loan Amt. : Rs. 1,00,000.00 Mark Up Rate : 2%
Interest Rate Applicable in different methods:

Case I : Ascending
37,500.00@8.5%+62,500@9%
Case II : Descending
75,000.00@9%+25,000@8.5%
Case III: Highest
1,00,000@9%
Case IV: Weighted Average
WAR = (37,500*6.5%+75,000*7%)/112,500 = 6.8%
Interest = 1,00,000@8.8%
Loan Tenor / Sanction Expiry Date

Sanction Expiry Date/ Loan Tenor are the highest of Linked Deposits‟ Maturity Date.
Event wise changes with respect to LAD enhancement are as below.
HLAGSPM/HCLGSPM/HGSPM
A Currency Based Tab – Linked Collaterals, is provided for Product Level Parameter
Maintenance. Following parameters are accepted in this tab.
• Is Loan Against Collateral
• Collateral Type
• Mark Up Applicable
• Mark Up Interest Method
• Mark Up %
• Recalculation of Interest on pre-closure
These parameters determine the property of Loan/OD accounts. However, user can
override these parameters at Account Level. Exceptions will be thrown in case if user
overrides the Product Level parameter values at A/c. Level.
Following Exceptions can be set at Product Level.
• Linkage of Third Party Deposit
• Loan Maturity Date greater than highest Deposit‟s Maturity Date
• LTV/Margin not confirming to Product Rules.
• Default Interest Parameter changed.
Restrictions/Validations
 All the parameter and exception related fields in Linked Collateral Tab will be
enabled only if Is Loan Against Collateral Flag is selected as YES.
 If Loan Against Collateral Flag is YES, then setup/parameters related to DL/UIC is
restricted.
 If Loan Against Collateral Flag is YES, then parameters related to Planned
Deferment can not be set.

5.3.1 ACCOUNT OPENING/MAINTENANCE
A tab – Link Collaterals, is added in Account Opening

(HOAACLA/HOAACCL/HOAACOD/HOAACCC). This tab is optional tab. If the scheme
entered by the user in criteria supports LAD, then user will be forced to visit this tab
after General Details Tab and before visiting any other tab.
This tab is a multirec screen and will have following fields.

 Collateral Code
 Entity Id – It‟s a deposit Account Id. On tab out, following values will be displayed
to the user.
• CIF Id – CIF Id of Linked Deposit A/c.
• Bal. Tenor – Balance Tenor of linked deposit.
• Collateral Rate – Interest rate attached to linked deposit A/c.
• Deposit Amount – Total Deposit Amount.
• Bal. Apportioned Amt. – This is the amount available for Linking net to lien
placed on Deposit Account. It is a display field and populated when deposit
account is entered.
 LTV % - It is default populated, when collateral ID is entered. But user can modify
this.
 Apportioned Amt – This is the amount to be utilized for loan while linking this
account to loan account.
 Lendable Amt – This is display field and is populated by applying LTV on
apportioned amt.
Other than the multirec fields, following mark up level values are accepted. The values
in these fields are defaulted from Scheme Level Setup. User can override these values.
 Mark Up Applicable – Radio Button with Yes/No
 Mark Up Int. Method – A selection field with Ascending, Descending, Weighted
Average and Highest as valid values. This will be disabled if Mark Up Applicable
flag is „No‟.
 Mark Up % - A field accepting numeric values. This will be disabled if Mark Up
Applicable flag is „No‟.
In case of LAA/CLA Accounts, a new repricing parameter – Relatively Pegged to

Collateral, is introduced. This can be selected only for LAD Accounts, where mark up is
applicable. Also, when mark up is applicable, repricing parameters – Fixed Till
Maturity, Fixed Till Maturity and Relatively Pegged to Collaterals will be applicable. All
other floating related parameters will be restricted for LAD accounts. The reason
behind this is interest is governed by Deposit Account.
In Accounts Limit Tab, the sanction limit is populated with the sum of lendable
amounts of Linked Deposits. However user will be able to modify it. But DP will be the
sum of lendable amounts. Also Drawing Power Indicator will be populated with D-
Derived and will be protected. In case of OD/CC accounts, user will not be allowed to
select Limit Level Interest.
All the Linkage related details are stored in LAC_CLT table while mark up interest
related details are stored in LAC_IT table.
During Verification of the account, linkage will be created between

Loan/OD/CC A/c with Linked Deposit A/c. Also, lien equivalent to Apportioned
amount will be marked on Linked Deposit A/c.

HLACREV
Whenever the interest rate of deposit is changed by adding new version in using
HTVSM, same should impact the interest rate of Linked Loan/OD A/c. This functionality
is taken care by this batch job.
This batch job will pick up all the loan/OD a/cs, where interest rate of deposits linked
to them is changed by adding the new version in ICV. It will pick up only those
loan/OD a/c, for which mark up is applicable and they are „Relatively Pegged to
Collateral‟.
The new interest rate on Loan/OD account will be applicable from the same date,
when the new version is applicable for linked deposit.
There are certain events on Deposit A/c., which can impact the interest rate of
Loan/OD Account. These events are as below.
Renewal of Deposit
Interest rate may change on the renewal of Deposit. Thus it will change the
interest rate of Linked Loan/OD A/c. from the renewal date.
Part Closure of Deposit
In case of Part Closure of deposit, amount slabs may change for deposit a/c.
In this case, interest rate of deposit will change with respect to change in slab.
Thus, new rate will applicable to Linked Loan/OD a/c. from this date onwards.
Pre Closure of Deposit
In case of Pre Closure, interest rate of deposit may change because of
a) change/reduction in tenor of deposit
b) Customer may opt to close the deposit on some absolute rate.
If because of any of the reason, if interest rate of deposit changes, this will
impact the interest rate of Linked loan/OD A/c.
In case of pre closure of deposit, the interest rate on deposit may change from any
back value date or from a/c. open date of deposit. In such cases, the interest rate of
Loan/OD a/c. may also change from closure effective date and may cause the
recalculation of interest for Loan/OD A/c. However, this is governed by on scheme
level parameter “Recalculate Interest on Pre Closure”. If the value of this flag is set as
YES at scheme level, the interest on loan/OD a/c. will be applicable from closure
effective date/Deposit a/c open date and hence will trigger the recalculation of interest
on Loan/OD a/c. But, if this flag is set as NO, then new rate will be applicable on
loan/OD a/c. from BOD date and will not trigger any recalculation of interest.
INTEREST CALCULATION
In LAD, if mark up is applicable, interest rate applicable to loan/OD a/c. is derived

from the linked deposits. As explained above, the following methods of interest
calculation are applicable in case if multiple deposits are linked.
1) Ascending
2) Descending
3) Weighted Average
4) Highest
Interest Calculation for different methods can be explained as below.
BOD Date : 01-03-2006

Loan Amount : 100,000.00
Mark Up Rate : 2%
Deposits linked are :
Deposit A/c. Deposit Amount Deposit Rate
TD1 75,000.00 10%
TD2 40,000.00 12%
Method 1 : Ascending
Interest Rate will be applied in ascending order of the interest rate as below.

75,000.00 @ 12% (10% + 2%)

25,000.00 @ 14% (12% + 2%)
Method 2 : Descending
Interest Rate will be applied in descending order of the interest rate as below.
40,000.00 @ 14% (12% + 2%)
60,000.00 @ 12% (10% + 2%)
Method 3 : Weighted Average

In this case, first weighted average rate will be calculated for deposits and same
will be applied during interest calculation.
Weighted Average Rate =

( (75,000 * 10 ) + (40,000 * 12) ) / 115, 000 = 10.70%
Interest calculation will be as below.
100,000.00 @ 12.7% (10.7% + 2%)
Method 4 : Highest
Highest of all the Interest Rates will be applied as below.
100,000.00 @ 14% (12% + 2%)
In case, if linked deposit amounts are not sufficient enough to cover the entire loan
outstanding, then A/c. level interest rate will be applied on uncovered loan (Loan o/s.
– total deposit amts) during interest calculation.
In case, if interest rate is not setup at Mark up Level, interest calculation will continue
to behave in the same way as of a normal loan/OD A/c.
5.3.2 CUSTOMER ACCOUNT MODIFICATION BEFORE VERIFICATION OF

OPENING
Customer accounts can be modified before opening of account has been verified. This can be done
using the following menu options:
SB Acct – HOAACMSB
CA Acct – HOAACMCA
CC Acct – HOAACMCC
OD Acct – HOAACMOD
While verifying the account, authorizer has to visit all the screens, which the user who has opened
the account has visited. Multi user modification is allowed for the above menu options

5.3.3 CUSTOMER ACCOUNT VERIFICATION
Customer accounts are verified using the following menu options.

SB Acct – HOAACVSB
CA Acct – HOAACVCA
CC Acct – HOAACVCC
OD Acct – HOAACVOD
While verifying the account, authorizer has to visit all the screens, which the user who has opened
the account has visited.
5.3.4 REVOLVING OD ACCOUNTS
Revolving overdraft is a facility offered to retail clients with credit card features such as billing
date, minimum payment, pay by date, penal interest and late fee for late payment. The sanction
limit is approved for a tenor and the account is opened as an OD account. Billing date and pay by
date are decided for each account and minimum payment is demanded as a percentage of the
outstanding amount on the billing date. Bank can decide on providing additional grace period
beyond pay by date.
DPD (days past due) starts depending on the set up at scheme level. Depending on “DPD to start
after grace period” indicator and value of “grace period(days)”, DPD starts from next immediate
day to pay by date or just after the expiry of grace period. If “DPD to start after grace period
indicator” is Y and “grace period days” is not zero then DPD starts after grace period else if its N
then starts the day immediately after pay by date irrespective of the grace period days set. If
Automatic renewal is done and percentage of utilization is above a cut off. Limits are renewed
manually for the accounts not satisfying the auto renewal criteria.
Additional parameters are to be set up at scheme level to enable the „Revolving Facility‟. Some of
these parameters are defaulted to account opening and can be modified for each account opened
with the Revolving Facility.
Some critical behaviour of OD accounts under this scheme are as follows:
 Penal interest product: Penal interest will be either on the overdue minimum amount after
grace days after pay by date or on the total outstanding amount as on statement end date
after the grace days after pay by date. This will be over and above the utilized TODs of the
OD account. Penal will be charged from grace days after pay by date to next bill‟s penal
start date.
 Multiple limits: Accounts with this facility cannot have multiple limits.
 Limit Level interest: Limit level interest is not possible.
 Account Recall: Account recall can be done, but recall flag value will not be effective for
penal interest calculation of this type of account.
 DPD and Delinquency: DPD will be maintained for each of the overdue bills and not on
TODs for the accounts with this facility.
 Bill generation: A bill is raised for a statement period with minimum amount due, pay by
date and late fee (if any).
 Bill Collection: The minimum amount due has to be collected from the operative account if
it is available.
Direct collection is also supported. Any credit to the OD account after the statement end
date is considered as payment towards overdue bill.
 Billing and Collection History: Printing of the billing and collection history is enabled. The
viewing of this history is also be enabled through CRV.
 Late fee: Late fee is to be charged for overdue bills. The fee will be assessed during the
next cycle billing and will be debited from the OD account itself.
 Auto Renewal: Revolving overdraft facility will be renewed automatically for all the
accounts satisfying some criteria like average utilization of limits, the DPD through out the
tenor is less than the specified DPD and the current asset classification. These auto
renewal parameters are set at parameter/product level.
 Review and Renew: Accounts that do not satisfy the auto renewal criteria are candidates
of review and renew. In this process the user will select the a/cs that are to be renewed
and confirm. There is an option to reduce the limit and the sanction period.
 Enquiry of DPD and Delinquency: The general account enquiry of OD accounts through
CRV will also contain the DPD information.
SCHEME LEVEL SETUP:
The Revolving Overdraft facility is enabled to set up at the scheme (product) level. All accounts in
this scheme will acquire this feature.
 On the 1st screen of scheme details of OD scheme, flag for Revolving facility is
captured. Only for ODA scheme type this field will be enterable.

 If Revolving overdraft flag is set as Y then the revolving od scheme details like the
billing frequency,grace period, dpd counter,auto renewal parameter details etc are to
be filled in the revolving od screen details by clicking on the revolving od tab.
Note: All the parameters specific to revolving OD are already explained in the section
“Creation of scheme using HGSPM – Scheme details of ODA scheme type” in DBA related
parameters in this document.
REVOLVING OD ACCOUNT OPENING:
- Account is opened using HOAACOD and verify the same using HOAACVOD. Account
opening process is same as explained in the “OPENING OF ACCOUNTS” above.
The screen details of the revolving od parameter at the time of account opening is here below.
REVOLVING OD BILL GENERATION
 Menu option: HODBLGEN

 Bill is generated for each overdraft account account with the revolving OD facility. Bill will
inform the customer what is the minimum amount the customer has to pay and by what
date, what is the credit limit available for this account as on the statement end date. All
the transactions on the account during the bill period will also be listed in the bill. Accured
interest will be included in the minimum amount if it is mentioned at account level. Late
fee and penal interest will be charged if customer fails to pay minimum amount by
payment due date. Late fee will be included in the minimum amount based on account
level parameter. Bill will be despatched according to the despatch criteria set at the
account level. Two reports will be generated , one containing all the bill s that need to be
emailed and another containing all the bills that need to be posted .

- HODBLGEN will accept the criteria and will fetch the accounts according to the criteria
after validating the criteria. Statement start date will be next date of the last statement
date of bill date as in HACM. But if bill generation is skipped for a period or periods then
the bill be generated for the current period and not for the previous period .
- Statement end date will be calculated from frequency (statement start date+frequency -1)
- This is a BJS enabled batch job and supports non business parallel run.
- There are two possible function codes for the bill generation . these are “generate” and
“Reprint”
- If the sanction limit has expired then it is the total outstanding amount
BILL COLLECTION FOR OVERDRAFT ACCOUNT
Any credit to the od account after the billing date will be treated as payments to all the overdue
bills . a bjs enabled batch program ODBLCOL is provided to collect the minimum amount due from
the operative account.
 Part collection from operative account is also be possible . if available amount of

operative account is less than minimum amount due only available amount will
be debited and remaining uncollected minimum amount will be overdue .
 If the operative account is part of a pool then pool effective available balance
will be considered
 If operative account balance is found to be zero failure report will be given for
this.
 This will be a customer induced transaction type . Transaction narration

contains “Transaction to OD <a/c no><minimum amount due> as per statement
date<date-DD/MM/YYYY>”
 If the transaction could not be posted due to the exceptions then the transaction
will be left in the entered status.
 Collection will be done for all the accounts whose minimum amount has not been
satisfied.

 If operative account is different than overdraft account currency then the rate
code needs to be maintained . if the rate code is not given processing will not be
done for that od account.
 This is a BJS enabled batch job.
using the menu option HREVREN we can review and renew the revolving overdraft accounts
provided the accounts satisfy the norms of renewal as set forth in the parameterisation.
5.3.5 LINK ACCOUNTS TO MULTI CURRENCY ACCOUNT
Multi Currency A/c. number is captured while opening a currency account using
HOAACSB/CA/ menu option
Multi Currency A/c. is captured during currency account opening in the criteria screen
Multi Currency A/c. field is enabled only if the Multi Currency Enabled flag is set to „Y‟ in
the HSCFM level
Currency account cannot be opened under a multi currency when multi currency account is
pending verification for opening and closure.
Details from multi currency account will be populated to currency account automatically and
are not available for further modification
During the opening of multi currency account through HMCAM, the user needs to specify the
general details, related party and document details along with some SWIFT related
information. This information will be percolated to the currency account during opening of a
currency account (linked with multi currency account). These fields will not be modifiable at
the currency account level.
Multi Currency A/c. number is displayed in the header block of currency account opening and
maintenance screens.
While opening a currency account, the CIF ID and Scheme Code of multi currency account
given will be validated with the CIF ID and scheme code of the currency account. If they do
not match, the system displays an appropriate error message.
Document details and related party details will be percolated to the currency account from
multi currency account. The user cannot modify these details at the currency account level.
However, the details can be modified at the multi currency account level.
If any change is required in the document details of an account, the details have to updated
in the multi currency account using the HMCAM menu option. After verification these details
will be percolated to the account.

Multi Currency Account maintenance menu has 5 fields Freeze Remarks1,Freeze Remarks2,
Freeze Remarks3,Feeze Remarks4 and Freeze remarks5 in the details page of the menu to
display the freeze remarks of the account.
Function: Indicates the function to be performed. Valid choices for this field are
A-Add, M-Modify, V-Verify, I- Inquire, D-Delete
General Details TAB:

Document Details
Tab
Related Party Details TAB

5.3.5.1 LINKING/DELINKING OF ACCOUNTS TO A MULTI CURRENCY ACCOUNTS
After a currency account is opened and verified, can be linked with a multi currency account using
the HMCAL menu option.
Any number of currency accounts can be linked to a single multi currency account, as long as the
following conditions are maintained.
The currency accounts must have the same CIF ID as that of the multi currency account
The currency accounts must have the same scheme code as that of the multi currency
account
The currency accounts must have the same scheme type as that of the multi currency
account
The scheme type of the multi currency account and the currency account has to be either
SBA/CCA/ODA or CAA
The scheme code of the multi currency account and the currency account should not be null
as well
There should not be other currency account, with the same account currency code, already
linked to the multi currency account.
If a currency account is linked to a pool, that currency cannot be linked to a multi currency
account..
When the accounts are being linked, the Core Banking Solution checks whether there are any
accounts linked to the multi currency account in the same currency. If so, an appropriate error
message is displayed. Also, an account which is linked with some multi currency account cannot
be linked with some other multi currency account.
The currency accounts can be directly accessed and transactions can be done independently.
Multi Currency account related party and currency account related party must be the same. If any
difference is there then the linkage is not possible.
In Link mode, if the multi currency account is entered it will list out all the currency account under
this multi currency account. User can add a new currency account to the present list if all the
validations are through.
User cannot modify the existing list of linked account in Link mode.
All the data which has been entered in the multi currency account level will be percolated to the
currency account and this will be done by a batch job. If the multi currency account details are
changed then the change will still be percolated. This will again be done by a batch program.
The account access code of the currency account can be different than the multi currency account
before linkage. But after the linkage the account access code of the multi currency account will be
percolated to the currency account.
If the multi currency account is in dormant state then also the currency account can be linked with
the multi currency account status.
If the multi currency account is in frozen status then the Core Banking Solution will not allow the
addition of the currency account to the multi currency account .
Linking/Delinking of Accounts to a Multi Currency Accounts in Finacle
Linking/Delinking of Accounts to a Multi Currency Accounts in Finacle can be initiated by HMCAL

The screen interface for the same is given below:
Function : This field provides for Functions like Link, Delink, Verify and Cancel.
On clicking Go the following screen is displayed
The field information for this screen is as below:

A/c. ID: The Id of the Operative account to which the Multi currency A/c. is linked.
Using the menu option HMACLS the user can batch close the multi currency accounts. But when
some accounts are linked to a multicurrency account, the multi currency account can not be
closed.
5.3.6 CUSTOMER ACCOUNT MAINTENANCE
Maintenance of customer accounts is done through the menu option HACM.
Some of the activities that could be done through account maintenance are modification of the
frequency of pass sheet/interest calculation, interest credit and/or debit account, changing the
charge level code for a customer, enabling/disabling interest credit/debit, charges etc., Other
operations includes tax category, marking account status as Inactive, dormant etc.,
The following details can be maintained/viewed using HACM menu option.
- General
- Interest & Tax
- Scheme
- Nomination
- Related Party

- MIS Codes
- Payment System
- Flexi Deposit
- Document
- Linked Deposits
- Additional Info
- Others
Some of the options are explained below.
Scheme Details:
Above screen can be used to mark the account as inactive or dormant also.
The verification of the modified record is done using HACM itself.
NOTE: It is possible to do auto verification of the modification by using scripting logic. The user
has to write the logic of auto verification in “ACMV.scr”
Modifications of account details can be done using the account maintenance option
- HACM
Interest code can be modified using interest maintenance menu option- HINTTM
Limit and drawing power changes can be done by invoking HACLHM menu option
For Change in Name, Short name, abnormal limits user has to invoke HAALM
menu option
Any change made is available to the users only after verification
The Memo pad entry is created by the system when change is made using the
option HACM.
The Memo pad entry is deleted by the system on verification.
The a/c balance is got from the relation:
A/c balance = Clear balance + Un clear balance
The available balance is got from the relation
Eff. DP + Tot. Clean Limit + Clear balance + Dacc Limit + System Gen
Limit – Total lien amount – System reserved amount
Total clean limits = clean Adhoc limit + clean Emerg. Advance + clean single Tran
limit
The system reserved amount includes the amount carved for inward clearing and for any
transaction module related transactions like ATM and Anywhere transactions which are pending
posting.
GENERAL DETAILS:
All the general details are available as part of this screen.
Most of the details which are populated from customer master, scheme and account can be
modified.

RELATED PARTY:
Related party details can be viewed, modified and added using the following screen.
The Relation Type field indicates the type of relation of the customer to the account. The
Valid values are Authorized signatory, Co-obligant, DSA, Guarantor, Joint holder, Legal Heir, Letter
of attorney, LHV Hirer, Main, Others, Power of attorney, Portfolio statement.
This is a multi-rec screen. More related parties can be added using <NewRec>.
Null values or spaces should not be entered in this field. The Start Date indicates the date from
which the person is authorised to operate the account. This field is mandatory if data has been
entered in the Relation Type field above. The End Date indicates the date up to which the person
is authorised to operate the account. The Name indicates the name of the authorised signatory.
This field is mandatory if data has been entered in the Relation type field above. The Designation
Code is for the entering designation of the authorised signatory. Amount column is for specifying
the amount up to which the authorised person can operate the account. This is for information
only and no validation is done at the transaction level.

Other Details:
SWIFT, A/C Label information, DSA information can be viewed/modified using the above section of
HACM. A/C label information is a multi-rec screen. Use <Next Rec> to add more recoreds.
Addl. Info:
As part of this screen interface the components of available amount, customer details and freeze
details can be viewed. None of these can be modified. The screen interface for the same is given
below.

Other details can be viewed/modified using the options specified above.
5.3.7 LIQUIDITY MANAGEMENT
Liquidity Management (LM) is a product range or a service provided particularly for corporate
customers to achieve any or all of the following benefits:
Holistic view of a group of accounts to take funding or investment decisions

Minimize overdraft charges on individual account balances
Enhance customers‟ return on funds management
The two most common liquidity management techniques adopted by banks are as follows:
Target Balancing (TB)

Notional Pooling (NP)
The group of accounts that form the liquidity management setup is known as the liquidity
management structure. In the Finacle Core Banking Solution, accounts belonging to ODA
(Overdraft), SBA (Savings Bank), CCA (Current) and CAA (Cash credit) scheme types can be
configured in this structure.
Note:

The liquidity management service can be used by other customers, apart from corporate
customers.
Features of Target Balancing Accounts:
Supports multi level pooling

Set up sweeps and reverse sweeps among the pool members
Sweep options help customers manage the liquidity position among the pool accounts to
minimize the overdraft interest outflow
Set up rules for sweep and reverse sweep options amongst the pool members
Batch jobs are available to reset the balances of the pool members
Shadow accounts opened automatically during the opening of target balancing accounts
help keep track of the sweep operations using suspense placeholders
Shadow accounts are created based on the linkage between accounts
Interest application is based on a separate interest table for the shadow balance accounts
and the sweeping options set
Features of Notional Pooling Accounts:
Supports better interest returns on the balances held in the pool

Single level pool
Single shadow balance account
Interest calculation happens on the net balance of all accounts belonging to a customer
and defined in the structure. Hence, sweeping as a functionality is not seen in notional
pooling accounts
Entries are separate for each day and values cannot be carried forward
Interest calculation is based on the calculation method selected
In Finacle, the system handles back-value dated sweeps in Liquidity Management System. If a
back-value dated transaction happens on an account of a Target Balance type of LM structure,
then a value dated sweep is also triggered to the higher levels of the link which results in a
cascading effect. A bank level parameter is introduced in this release to enable or disable this
functionality.
The following business processes, critical for the efficient functioning of Liquidity Management
operations at the bank, are supported by the Core Banking Solution:
5.3.7.1 MAINTAIN LIQUIDITY MANAGEMENT STRUCTURE
Use the HLMMAS menu option to create the Target Balancing or Notional Pooling
structure. You can do the following using the HLMMAS menu option:
Create a structure for either Target Balancing or Notional Pooling. The Structure ID can
either be user specified or system-generated (HNNTM setup, where the HNNTM code is
mentioned in the HSCFM menu option)
Add parent accounts to the structure. The accounts can belong to SBA, CCA, CAA or ODA
scheme types
Note:

1. The currency of the parent account is also the currency of the structure. All accounts
added to the structure at different levels must be of the same currency.
2. In case of Notional Pooling, the Core Banking Solution creates a shadow account. The
shadow belongs to the ODA scheme type defined in the HGSPM menu option as a LM
scheme. The shadow account is created for Target Balancing too.
3. Access to this menu is based on the work class
The following validations are taken care of in the HLMMAS menu option:
GENERAL VALIDATIONS
The parent account ID added is not used in any other structure. An account which is
part of a TB structure cannot be a part of an NP structure and vice-versa.
An account is not part of two Notional Pooling or Target Balancing structures
Sweep effective date is not greater than the sweep expiry date
Balance Reset frequency is specified only if the Balance reset flag is set to Y
In Notional Pooling information, the Interest allocation % is specified only if the
interest allocation method is %.
VALIDATIONS FOR DE-LINKING OF ACCOUNTS
No group or subsidiary accounts is linked to the account being de-linked

Interest calculation for shadow account is up to date
Interest allocation for shadow account is up to date
Balance of shadow account is zero (effected by interest allocation process or balance
reset process)
Reverse sweep has happened for the account, in case it belongs to a reverse sweep
structure
The parent account ID is a valid account
LM type – Valid indicators are T / N
Sweep type – Valid indicators are O / R
Validates sweep effective date and sweep expiry date
Validates sweep frequency, balance reset frequency and interest application
frequency
Checks for a valid flag value for the interest allocation method
Checks if a valid interest table code is specified. It also validates if the currency of the
interest table code is the same as the currency of the structure or parent account.
Checks if a valid number is specified for the Interest Allocation Percentage field.
This value cannot be greater than 100%.
INVOKE HLMMAS:
HLMMAS – SCREEN 2

Some of the field information is given below:
General Details:
Parent A/c Id: The parent account ID.
Liquidity Management Type: Indicate the type of the liquidity management. Valid Values:
Are Target Balancing / Notional Pooling
Structure Name: Indicate the name of the liquidity management structure.
Suspense A/c. Placeholder: The suspense account placeholder to which transactions to the
shadow account are reflected.
Sweep Type: Select the appropriate option button to indicate if the sweep of funds is one way
or if it is a reverse sweep
Relationship Manager: Select or type the relationship manager for the liquidity management
structure.
Int. Allocation/ Application Freq.: Indicate the frequency of Interest allocation.
Target Balancing Parameters:

Sweep Effective Date: Select or type the date from which the sweep operation is effective on the
structure.
Next Sweep Date: Select or type the date on which the sweep operation is to be done next
Bal. Reset: Select the appropriate option button to indicate if balance reset is to be done to
shadow accounts or not.
Reset Freq.: Type the frequency at which the reset operation is to be done.
Notional Pooling Parameters:
LM Sweep ID: Displays the shadow account number:
Int. Allocation Method: Select the method of interest allocation from amongst the following.
Fixed Percentage / Absolute Bal./ Credit Bal / Debit Bal / Custom Logic
Int. Allocation %: The percentage of interest to be allocated to the parent account in the NP
structure.
‘Negative Int. Benefit Allocation’which is available in the Notional Pooling Parameters

section will determine whether a negative interest benefit should be allocated or not when
there is a negative benefit calculated for the LM structure.
5.3.7.2 MAINTAIN LIQUIDITY MANAGEMENT GROUP
Use the HLMGRP menu option to define group or subsidiary accounts in the liquidity
management structure. This is the second step in the liquidity management setup. The
HLMGRP menu option supports the following features:
For every Linked To – Linked From account ID combination, a shadow account is

automatically created by the Core Banking Solution using the default setup. This
shadow account is used to track the amount contributed due to liquidity management
sweep or reverse sweep transactions. The shadow account is created in the HLMGRP
menu option only for links created for a target balancing type of structure
The shadow accounts are auto created out of the ODA schemes already created. For
this purpose there will be two scheme codes, one enabled for Target Balancing and
one scheme code enabled for Notional Pooling in ODA sheme – General Details tab
When the shadow accounts are created the interest credit account will be
automatically selected as „L – Parking Account‟ for the shadow account and interest
will be credited to the parking account
In case of Target Balancing, Sweep Priority is populated by default as 99. Also, the
transfer limit is populated by default as high amount and the target balance as 0
Add, Modify, Verify, Inquire modes are available in the HLMGRP menu option.
You can de-link a linkage in the M - Modify mode using the Del Linkage check box
Menu access is controlled by the work class
In case of addition of group accounts at Level 1, the Linked To account ID is
populated by default with the Parent account ID (only in case of Notional Pooling)
In case of addition of group accounts at other levels, you can specify the Linked To
and Linked From account IDs
INVOKE :HLMGRP
LM Structure ID: Select or type the liquidity management structure identification number.
HLMGRP – SCREEN 2:
Some fields are explained below:
All fields up to LM Sweep ID are display fields.
Structure Details:

Structure Name: Displays the name of the liquidity management structure1.
Liquidity Management Type: Displays the type of Liquidity management.
Target Balancing: Displays the target balance.
Int. Allocation %: Displays the interest allocation percentage.
Parent A/c Id: Displays the parent account number of the liquidity management
structure.
A/c. Linkage Details:
LM Sweep ID: Displays the shadow account ID.
Relationship Level: Type the level at which the user is trying to add group accounts
Linked to A/c. ID: Select or type the account number to which the group accounts has to
be linked, depending on the relationship level in the structure.
Int. Table code for Sweep Amt.: Select or type the interest table code to be used for
interest calculation on the sweep amount
Force Debit: Select the appropriate option button to indicate if the system must force a
debit transaction ( by granting a TOD), if sufficient funds are not available during a sweep
operation.
Credit Utilisation: Select the appropriate option button to indicate if the system must
utilize the limit sanctioned by the bank, apart from the account balance, during the sweep
operation.
Transfer Limit Amt. : Type the amount limit for transfer.
Note:
During all sweep condition executions, while considering the amount to be transferred, the
transfer limit will take precedence over the target balance. Hence, for all scenarios where
there is a debit balance in the subsidiary account, the processing logic looks at the target
balance in the subsidiary account and determines the effective transfer amount that
should be credited to the subsidiary account.
Subsequently, the system looks at the amount available in the master account and
compares it with transfer amount. If the amount in the master account is greater than the
transfer limit, the system completes the transaction by transferring the limit amount.
If the amount in the master account is less than transfer limit and if the Force Debit flag is
set to Yes, the system transfers the limit amount, and grants a TOD for the balance
amount. If the Force Debit flag is set to No, the system transfers the amount in the
master account.
Linked From A/c. ID: Type the account number from which the group accounts must be
linked, depending on the relationship level in the structure
„Cover OD‟ flag determines the type of sweep to be implemented for the link. Each link
will have this flag.

Sweep Priority: Type the priority assigned by the system for satisfying the funds.
For Example:
Consider that a parent account A at relationship level 2 has got a credit balance of 10,000.
After a sweep is effected, and accounts A1 and A2 which are linked to account A have a
debit balance of 5000 each, the system will use the sweep priority defined, to decide
which account – A1 or A2, is to be satisfied first. In case both have the same sweep
priority, the system satisfies depending on the order of account number.
Target Bal.: Type the minimum that must be maintained in the linked account
Notional Pooling Int. Allocation %: Type the percentage of notional pooling interest
rate.
Note:
1. The sum of Notional Pooling Int. Allocation % must not exceed 100% for all
allocations.
2. A value can be specified in this field only if the structure is a Notional Pooling structure.
3. This field is applicable only if the interest allocation method is fixed percentage for the
structure.
Points to Remember:
1. Account currency of all group accounts being linked to the structure, should be the
same as the currency of the structure or parent account currency.
2. While de-linking accounts (Target balancing), following are validated:
No group or subsidiary accounts are linked to the account being de-linked

Balance of shadow account is zero (effected by interest allocation process or
balance reset process)
Reverse sweep has happened for the account, in case it belongs to a reverse
sweep structure
5.3.7.3 LIQUIDITY MANAGEMENT BALANCE SWEEP
The following features govern the sweeps process in the Liquidity Management System:
Sweep is run as on the value date specified in the criteria. By default, the value date is
the BOD date. If the sweep program is initiated by the user, it overrides the sweep
frequency mentioned in the HLMMAS menu option. Sweeps are defined by frequency, not
the value date.
For each structure ID specified in the criteria run the processing. (more than one
structure ID can be specified in the criteria. If more than one structure ID is to be
specified, the list of structure IDs are specified)
The sweep operation in case of HBJSTM menu option, happens as per frequency defined
in the HLMMAS menu option
See Setting Up of Batch Jobs in the EOD BOD Processes module for HBJSTM menu
option details.
Sweep is run for all structures belonging to a particular relationship manager, if the
relationship manager is mentioned as part of the criteria.
The following processing occurs between two relationship levels at a time:
The credit balances from the accounts in the lower level is transferred to the master
account in the next higher tier
The debit balances in the lower tier are satisfied or made zero by credit balance in the
master account at the higher level
Satisfaction of debit balances happens based on the priority set up for the accounts
For example
Consider the following structure:
Account P (Parent account): Balance = 700 Cr. (After credit balances are swept) – Level 0
Account A – Group / Subsidiary account of P – Level 1 – Balance = 500 Dr./ (Sweep priority
= 1)
Account B – Group / Subsidiary account of P – Level 1 – Balance = 500 Dr. (Sweep priority
= 2)
The system carries out the following transactions based on the sweep priority set in
HLMGRP menu option:
Dr. INR 500 Account P
Cr. INR 500 – Account A -> Since sweep priority is 1
Dr. INR 200 Account P
Cr. INR 200 – Account B -> Since sweep priority is 2
In case of value dated transactions to an account belonging to the liquidity

management structure, only credit transactions are considered for sweeps. If the sweep is
run as on the value date, the Core Banking Solution considers only credit transactions,
since debit transactions could result in an indefinite loop
All transactions created by the sweeps program populates the module-ID as LMS
Handling Back-value Dated Transactions in Sweeps

If the sweep job finds that a back value dated credit or debit transaction has happened on
an account after the last sweep, a transaction for this amount is put in the shadow account.
This is because a credit transaction on the account could have triggered an upward sweep.
So the shadow account is credited and the suspense account is debited. Similarly a debit
transaction on the account could have triggered a downward sweep from parent. This value
dated entry in shadow account will in turn trigger a re-calculation of the interest. The same
entry is done for the shadow account of the corresponding higher level in the liquidity
management structure to handle the cascading affect of the sweep process.

Note:
The Balance sweep program is used to sweep balances from accounts in the lowest level of
the liquidity management sweep structure to the highest level or Parent account.
INVOKE HLMSWP:
LM Structure ID: The LM structure Identification number
Report To: Specify the name of the person to whom the report should be sent.
Value Date: The Value date of the sweep operation.
LM Relationship Manager: The relationship manager for the LM structure.
5.3.7.4 INTRA DAY LIQUIDITY MANAGEMENT BALANCE SWEEP
This program is the same as the sweep program run by HLMSWP, with the only difference
being that this program is to be invoked during an intra day sweep, whereas the reverse
sweep for the sweep transactions does not occur during the next day. This is a provision
for the user to run an intra day sweeps operation when the user is required to transfer
funds due to sweeps operation, out of the bank. The physical transfer of funds, after the
intra day sweep program is run, is done procedurally. All other processing and validation
logic is similar to that of HLMSWP.
System Control File Maintenance (HSCFM)

In Bank Maintenance, the field „Handle LM Back Value Sweeps‟ is available in the General Tab. This
will determine whether a back value dated sweep should be done or not when there is a back
value dated transaction in an account belonging to LM structure.
Liquidity Management Balance Sweep (HLMSWP/HLMSWPID)

If the above flag is “Yes”, the functionality will be as per the current LM behavior. If the flag is
“No”, the sweep batch process should not sweep the back value dated transactions with value
date. The entire balance in the account will be considered for sweeping as if the entire transaction
is with value date same as transaction date. All the transactions required to adjust the effect of
back value dated transactions will be handled by users manually if the flag is “No”.
INVOKE HLMSWPID:

LM Structure ID: The LM structure Identification number.
Report To: The name of the person to whom the report should be sent.
LM Relationship Manager: The relationship manager for the LM structure.
5.3.7.5 RESET LIQUIDITY MANAGEMENT BALANCE IN BATCH
Use the HLMBRST menu option to reset the liquidity management balance. This feature is
required in case of one-way sweeps or intra-day sweeps, where the balance of the shadow
account goes on accumulating and needs to be reset.
Note:
Intra-day sweep amounts are not reflected in the shadow account or in the balance reset.
PROCESSING LOGIC:
The balance reset program posts a transaction making the balance zero in the shadow
account. For this, a transaction is passed between the shadow account and the suspense
placeholder.
All transactions created by the balance reset program have the module_id populated as
LMS.
For Example :
Scenario 1 : Shadow A/c. A1A has a credit balance of 10000 INR.
The following transactions make the balance NIL:
10000 INR Dr. Shadow A/c. A1A
10000 INR Cr. Suspense A/c. Placeholder SP
Scenario 2 : Shadow A/c. A2A has a debit balance of 5000 INR.
The following transactions make the balance NIL:
5000 INR Cr. Shadow A/c. A2A
5000 INR Dr. Suspense A/c. Placeholder SP
This menu performs the following validations:

Structure ID specified as criteria is valid. If more than one structure ID is specified, they
are separated by a standard de-limiter as used in the ONS functions
If only the structure ID is specified as criteria, the system resets the balance only for the
structure specified
In case of two-way sweeps, the batch reset program checks if any reverse sweep is
pending. If so, the reset operation does not happen and an error message, 'Reverse
sweep operation is pending,' is displayed.
Balance reset is not allowed for two-way sweep accounts
Standard validations as also performed during posting of transactions. Errors which occur
during transaction processing are displayed in the failure report for the batch job.
Note:
Only Target Balancing structures are eligible for balance reset

The reset happens only if the Reset Indicator is set to Yes in the HLMMAS menu option
for the structure
Sweep ID field is validated for LM type only
The balance cannot be reset if a newly opened Sweep ID or Sweep ID with zero balance
is specified
INVOKE HLMBRST
Some of the fields are explained below:
LM Sweep ID: The shadow account ID.
Reset Freq.: Indicate whether the reset must be on a specified frequency (frequency
based).
5.3.7.6 RESET LIQUIDITY MANAGEMENT BALANCE
Use the HLMRST menu option to reset the balance of a particular sweep ID or shadow
account balance. You can also specify a non-zero balance to be reset for the shadow
account.
This facility is similar to the batch program for balance reset, the only difference being
that this is an online program and can be used for a non-frequency based balance reset.
The following validations are addressed:
Only LM type account is specified in the criteria (only LM sweep ID)

Standard validations:
Value date format

Value date is not a future date

Validates reset amount
Note:
1. In case of a debit reset, if the reset amount specified is greater than the account
balance, an error message, 'insufficient balance,' is displayed
2. Only Target Balancing structures are eligible for balance reset.
Invoke HLMRST:
HLMRST – SCREEN 2:
Some of the fields are explained below:

Reset Amount: Type the amount to reset.
Tran. Type Ind.: Select the appropriate option button to indicate the transaction type
(Dr/ Cr).
Value Date: Select or type the value date of the transaction.
Tran. Particulars: Type the particulars related to transaction.
Tran. Remarks:Typethe remarks, if any, related to transaction.
5.3.7.7 LIQUIDITY MANAGEMENT BALANCE REVERSE SWEEP
The balance reverse sweep program is used to sweep back balances to accounts, which were swept
out during the previous day.
Reverse sweep is run as follows:
For each structure ID specified in the criteria run the processing mentioned below. (more than
one structure ID can be specified in the criteria. If more than one structure ID is to be specified,
the list of structure IDs are specified – separated by a de-limiter as per standard ONS functions)
Reverse sweep is run for all structures belonging to a particular relationship manager, if the
relationship manager is mentioned as part of the criteria
The processing happens between two relationship levels at a time
During Reverse Sweep, the Force Debit flag is ignored, and the system automatically forces a
debit transaction if sufficient balance is unavailable.
All transactions created by the reverse sweeps program have the module_id populated as LMS

For Example:
Sweeps operation (between Level 0 and Level 1) :
At the end of the reverse sweep operation between Level 0 and Level 1 :
Balance in account A : INR 6000 Cr.
Balance in account B : INR 3500 Cr.
As a part of the Level 1 – Level 0 sweeps operation, the following transactions take place :
INR 6000 Dr. Account P
INR 6000 Cr. Account A
Shadow account transactions reflected in shadow a/c AP :
INR 6000 Cr. Suspense A/c. placeholder SP
INR 6000 Dr. Shadow A/c. AP
Now the sweeps program will effect the following transactions between B and P :
INR 3500 Cr. Account B
INR 3500 Dr. Account P

Shadow account transactions reflected in shadow a/c BP :
INR 3500 Cr. Suspense A/c. placeholder BP
INR 3500 Dr. Shadow A/c. AP
Balance in account A will be INR 6000 Cr.
Balance in account B will be INR 3500 Cr.
Balance in account P will be INR 10000 Cr. (INR 19500 (existing balance in account P) - INR 6000
- INR 3500 )
Sweeps operation (between Level 1 and Level 2) :
The system reverses all Sweep transactions that happened the previous day :
INR 1000 Cr. Account A1
INR 1000 Dr. Account A
Balance in Account A will now be INR 5000 Cr.
Shadow account transactions reflected in shadow A/c. A1A :
INR 1000 Cr. Suspense A/c. placeholder SP (The suspense A/c. placeholder SP is to be defined in
HLMMAS menu option for this structure, by the user)
INR 1000 Dr. Shadow A/c. A1A
Next set of transactions are as follows:
INR 2000 Dr. Account A2
Balance in Account A2 will now be INR 2000 Dr.
Balance in Account A will now be INR 7000 Cr.
INR 2000 Dr. Suspense A/c. placeholder SP
INR 2000 Cr. Shadow A/c. A2A

Third set of transactions are as follows:
INR 3000 Dr. Account A3
Balance in Account A3 will now be INR 3000 Dr.
Balance in Account A is INR 10000 Cr. (INR 7000 + INR 3000).
INR 3000 Cr. Shadow A/c. A3A
The system also does the following transfers during the Level 2 – Level 1 operation :
INR 500 Cr. Account B1
INR 500 Dr. Account B
Account B will now have a balance of INR 3000 Cr.
Account B1 will have a balance of INR 500 Cr.
Shadow account transactions reflected in shadow A/c. B1B :
INR 500 Cr. Suspense A/c. placeholder SP
INR 500 Dr. Shadow A/c. B1B
Now, the system will do the second set of transactions as follows :
INR 2000 Cr. Account B
INR 2000 Dr. Account B2
The balance in Account B2 will be INR 2000 Dr.
Balance in Account B will now be INR 5000 Cr.
Shadow account transactions reflected in shadow A/c. B2B :
INR 2000 Cr. Shadow A/c. B2B
Thus all the transactions are reversed, and the balances before the sweeps operation on the
previous day are restored to all the accounts in the liquidity management structure.

Note:
1. If more than one structure ID is specified in the criteria, they are separated by a de-limiter.
2. Reverse sweep does not occur if the regular sweep for that instance has not occurred the
previous day. The Core Banking Solution displays an appropriate message when this option is run,
in this context.
3. Value date cannot be greater than the BOD date.
4. Value date is default populated with the BOD date.
5. Value date of reverse sweep cannot be greater than the last sweep date. If so, the Core
Banking Solution gives an error.
6. Reverse sweep cannot be run for a future date. Reverse sweep can occur only to all
transactions effected by the previous sweeps operation.
7. Errors in posting are shown in the report generated as part of the batch job.
Invoke HLMRSWP:
5.3.7.8 CALCULATE INTEREST FOR LM STRUCTURES
Using the appropriate menu options available in the Finacle Core Banking Solution, you can
perform the following interest-related activities in the liquidity management structure:
Book Interest:
Use the HLMBOOK menu option to run interest booking for shadow accounts. The processing logic
for the HLMBOOK menu option is the same as that for HACBOOK. The only difference being that
while it is possible to run interest booking for shadow accounts using the HLMBOOK menu option,
it is not possible to do the same using the HACBOOK menu option.
INVOKE : HLMBOOK:

Accrue Interest :
Use the HLMACCR menu option to calculate the interest accrued on shadow accounts. The
processing logic for the HLMACCR is the same as that for the HACACCR menu option. The
only difference being that while it is possible to run interest accrual for shadow accounts
using the HLMACCR menu option, it is not possible to do the same using the HACCR menu
option.
INVOKE : HLMACCR
Run Interest:
Use the HLMINT menu option to run interest calculation for shadow accounts. The
processing logic for this menu option is the same as that for HACINT menu option. The
only difference being that while it is possible to run interest calculation for shadow
accounts using the HLMBOOK menu option, it is not possible to do the same using the
HACINT menu option.
See Apply Interest for Accounts in the Interest Calculation module for HACINT menu
option details.
Note:
If one or more structure IDs are specified in the criteria, the Core Banking Solution
processes all accounts corresponding to these structure IDs. This happens in the
HLMBOOK, HLMACCR and HLMINT menu options.
If a Relationship Manager is specified in the criteria, the Core Banking Solution
processes all accounts corresponding to the Relationship Manager specified. This
happens in the HLMBOOK, HLMACCR and HLMINT menu options.
INVOKE : HLMINT
Allocate Interest:

Use the HLMALLOC menu option for interest allocation in case of Target Balancing and
Notional Pooling structures.
Note:
In case of a Target Balancing structure, interest allocation occurs for the interest
accumulated by virtue of contributions to other accounts, which are effected in
shadow accounts by means of transactions.
All transactions created by the reverse sweeps program have the transaction
module_id as LMS
INVOKE : HLMALLOC
If the „Negative Int. Benefit Allocation‟ flag is “No” in the HLMMAS menu , the functionality will be
as per the current LM behavior. If the flag is “Yes”, the interest allocation process should allocate
the benefit interest even if it is negative. The transactions will be a reverse of what happens
during a positive benefit interest allocation as below:
CR. – PARKING A/C
DR. – Account A
DR. – Account B
Value Date Behaviour in HLMINT, HLMACCR, HLMBOOK and HLMALLOC Menu

Options
Value date has different impact on different menus. The impact of value date on HLMINT,
HLMACCR, HLMBOOK and HLMALLOC menu options is as follows:
HLMACCR – The calue date has no impact as no transactions are created

HLMBOOK – The value date can be changed to a date less than the BOD date. The
transaction will be created on the value date specified by the user. By default the value
date will be populated as the BOD date
HLMINT – The value date can be changed to a date less than the BOD date. The
transaction will be created on the value date specified by the user. By default the value
date will be populated as the BOD date. If the user changes the value date of the
transaction, the next interest application will trigger a recalculation
In case of Notional Pooling, recalculation will be triggered if any group account has a
value dated transaction in it. If all the group accounts have value date transactions, the
minimum value date will be taken into consideration for recalculation
For Example:

If a Notional Pool structure S1 is created on 1/1/2006 with following accounts,
Account A (SB account opened on 1/1/2006)
Account B (OD account opened on 1/1/2006)
A has been credited with Rs 100 as on 10/1/2006
B has zero balance
Let Shadow Account be SS1
When the HLMINT menu option is run on the Structure S1 on 1/2/2006, the system
calculates interest on the shadow account SS1 by considering the balances of accounts A
and B.
BOD date 3/1/2006
If there is a transaction on account A, say Rs 50 is credited with a value date as

20/1/2006
When the HLMINT menu is run on the Structure S1 on 1/3/2006, the system calculates
interest on the shadow account SS1 by considering the balances of accounts A and B.
Since there is a value date transaction on account A, the system triggers a recalculation.
The behaviour of value date in the HLMBOOK and HLMINT menu options is similar to that
of the Value Date field in HACBOOK, HACINT.
See Book Interest for Accounts in the Interest Calculation module for HACBOOK menu
option details.
option details.
HLMALLOC - By default the value date is populated as the BOD date. The value date
cannot be greater the BOD date. The value Date in the HLMALLOC menu option affects
the value date of transaction, but bears no significance for arriving at the period for
which interest allocation must be done
For Example:
If a Target Balance structure S1 is created on 1/1/2006 with following accounts (one link),
Account A (SB account opened on 1/1/2006)
Account B (OD account opened on 1/1/2006)
During sweep on 10/1/2006, Account B gets debited by Rs 50 and Account A get credited
by Rs 50
The HLMINT menu option has been run for the shadow accounts SS1 which represents the
link between accounts A and B on 1/2/2006.
BOD date 1/2/2006

If the HLMALLOC menu option is invoked on 1/2/2006 with a value date as 20/1/2006, a
value dated transaction is created which transfers the interest amount (shadow accounts)
from Account A to Account B.
BOD date 1/3/2006
Now, if the HACINT menu option is invoked on 1/3/2006 for either Account A or B, a
recalculation is triggered as there is value date transaction happening on accounts A and B
during the interest allocation process.
option details.
The process details above also holds good for notional pooling. In this case, all group
accounts will have a value date transaction if the user has changed the value date to a
date other than the BOD date and if the benefit amount is not zero.
Customization of Script during Interest Allocation in Target Balancing
Use the following script to customize the logic used to allocate the benefit amount during
interest allocation for Target Balancing:
SCRIPT:
LMTargetBalanceIntAlloc.sscr
INPUTS:
To Account
From Account
Structure ID
Structure Type
AmountToAllocate
Structure Currency Code
Example:
Consider a target balance structure S1 of INR currency created on 1/1/2006 with the
following accounts:
1. Account A (SB account opened on 1/1/2006)

2. Account B (OD account opened on 1/1/2006)
During sweep on 10/1/2006, Account B is debited by Rs. 50 and Account A is credited by

Rs. 50.
The HLMINT menu option is run for the shadow accounts SS1, which represents the link
between accounts A and B as on 1/2/2006.
Interest amount = Rs. 2.
If the HLMALLOC menu option is invoked on 1/2/2006 with the value date as 1/2/2006,
the system checks whether LMTargetBalanceIntAlloc.sscr exists. If it exists, the following
data is provided to the script:
A (To account)
B (From account)
S1 (Structure ID)
T (Structure type)
Rs. 2 (interest amount to be allocated)
INR (Structure or Account Currency)
In the script, the interest amount to be allocated can be modified by the user, if required.
If the user has specified an amount greater than the system-calculated amount (in this
case Rs.2), the system throws the following error, 'Allocation amount cannot be greater
than system-calculated amount'.
If the user specifies a negative amount as the amount to be allocated, the Core Banking
Solution treats the interest amount to be allocated as zero.
The Core Banking Solution checks for the presence of the script and script logic for all
structures as specified in the criteria and the linkages within each structure, if the script is
used.
5.3.7.9 INQUIRE ON LIMIT TREE STRUCTURE
Use the CRV menu option HLMI to inquire into the limit tree structure and linkage pattern.
INVOKE HLMI:
5.3.7.10 LIQUIDITY MANAGEMENT UPLOAD STRUCTURES
Use the HLMUPLD menu option to upload existing Liquidity Management details into the
Finacle Core Banking Solution. The following options are available in this menu to upload
liquidity management details:
Liquidity Management Master Details Upload

Liquidity Management Group Details Upload
Invoke HLMUPLD:

5.4 ACCOUNT LIEN MAINTENANCE

Menu option HALM can be used to create lien on the account and make lien related
inquiries. The placing of lien manually is irrespective of the balance in that account. The
user cannot modify the system created liens. The “Future Value Dated Balance” will not be
considered during any operations of Lien (i.e. Lien Marking, Lien Lifting, etc.)
The screen interface for lien maintenance is as under:
It is possible to list liens with expiry, liens without expiry and both.
Functions available are : Add(A), History (H), Inquire(I), List(L) Modify(M), Verify(V) and
Cancel(X),
Addition and Modification of liens of module type ULIEN (user created liens) is possible through
this menu. During addition/modification of lien, the user has to enter the following values.
The screen interface for the same is:
New Lien amount : The amount for which lien has to be place

Expiry date: The period till when the lien is valid. Lien is valid only upto the expiry date.
Lien reason: Appropriate lien reason code has to be entered here. Lien reason codes are created
through HRRCDM menu.
Lien Remarks: This is a free text field. User can enter any free text.
During modification process, user can modify the lien amount/expiry date. While lifting lien, the
new lien amount should be entered as zero.
Facility is provided to enter the specific CD Denomination No. against which lien is marked in case
of CD type of deposits.
Note: User can create liens of Module type ULIEN only. For user created liens, module ID column
is not enterable. Also, user can create liens for accounts belonging to scheme types SBA, CAA,
CCA, ODA, BIA, FBA & TDA.
5.5 ACCOUNT LABEL CODE MAINTENANCE

Account Label codes are created using menu option HACLCM. Labelling of accounts is used for
various MIS report generation/inquiries and asset provisioning purposes. The menu options which
have this value in the selection parameter screen are HACS, HACMP, HACLPOA, HACLPCA, HFTI,
HPSP and HEXCPRPT. The screen interface is as under.
MENU OPTION: HACLCM
Functions available are: Add(A), Modify(M), Verify(V), Inquiry(I), Cancel(X), Delete(D),

Undelete(U) and List(L). This process requires verification. The label codes created here can be
assigned during account opening using the other details tab account modification #. Also, facility
is available for specifying the value for a label which is useful for Asset Provisioning. This aspect is
covered in detail in Asset Classification doc.
On clicking Go in the criteria the following screen is displayed.

5.6 SUPERCEDING THE EXPIRY LIMIT

Facility is provided to disable the expired limits for an account after the sanction expiry date. Till
now, this is handled through an exception. If this is set as an exception/warning, then user will
still be able to use such expired limits. In other words, the user can enable the system to super
cede all the expired limits. This is handled through the menu HSEL.
MENU OPTION: HSEL
The user can specify the date in the Expiry date column. All the limits which have expiry date prior
to this date will be super ceded effective from BOD date irrespective of the actual expiry date.
(i.e., super ceding of limits is effective from BOD date and not expiry date + 1).
As part of marking the limit as super cede, the system will grant a TOD for the liability in excess
of active limits provided set up is available for DL type of TOD at corresponding scheme level. If
the TOD cannot be granted or set up is not available for DL type of TOD at the scheme level, the
system will skip such accounts for processing. However a report will be generated for such
accounts where the process has failed. For any modification in the report the user can do
modifications for the “sel.mrt” which uses “sel.mri” as the input file.
Facility is also provided to skip specific accounts from processing. This can be achieved by entering
some valid value in Free code 10 of MIS details(V sup option) during account
opening/modification and „Y‟ for the column in „Exclude A/c with "Free Code 10"?‟ of SEL.
 Note : Ideally this option should get executed daily. If due to some reason this option is not
executed for some day, then on the next day if it is executed then system will mark them as super
ceded from the BOD date and not the Expiry Date + 1. Also, user should be educated to know the
significance of value in Free Code 10.
This menu option can be set as a batch job also.
5.7 PRINTING OF PASS SHEET FOR AN ACCOUNT&OTHER

PROCESSES:
Statement of accounts, Combined Statement, Swift Message can be generated by invoking the
menu option HPSP. All these can be regular or duplicate. Separate Charges can be collected for
both regular as well as duplicate pass sheet printing by specifying appropriate event_ids. Pass

Sheets can be generated for all the joint holders who are eligible for the statement. Also facility is
provided to generate statement for select joint a/c holders when statement is generated for a
specified account.
Combined statement facility is also provided through this option. Combined statement charges
event (both Ad hoc and Regular) can be specified in HSCFM.
It is possible to generate MT 940/950 or MT 942 messages using this menu option HPSP.
MENU OPTION: HPSP
Selection criteria for Pass sheet can be account/CIF id/GL subhead/Scheme code/A/c
Manager/Account Label/Custom List Id/Despatch Mode/Open/Closed a/cs/specified date range etc.
Also, pass sheet can be generated for those a/cs for which pass sheets are allowed/not.
In case of Regular pass sheet printing, the date up to which statement is generated is updated
and during the subsequent printing, period from date will be default populated with „last printed
date + 1‟. Pass sheet generation is through mrt and appropriate mrts are to be specified in cust
option file for the purpose. The statement charges can be waived by setting the flag value for
„Waive Fees‟.
For an account of scheme type SBA/CAA/CCA/ODA the reversed transactions will also be
dumped into the mrt along with the additional parameters when the srgpm parameter is
set to Y. Based on the condition in mrt the reversed transactions will be printed/skipped.

Now the menu will print only those reversed transactions which are not reversed on BOD
if the srgpm parameter is set to Y. If the parameter is set to N/NULL then the menu will
print/skip the reversed transactions based on the conditions mentioned above for HPSP
menu.
5.7.1 PRINTING OF PASS BOOK
Pass books can also be printed for a account where the pass sheet/ pass book flag is P-pass book
for the account. The menu option for printing of pass book is HPBP. Special pass book printers
are supported by the application. In case of a FFD account ,the effective balance is also printed
( It is the sum of the amount contributed towards the FFD and the available balance in the
account )
MENU OPTION: HPBP
The menu will select and dump the reversed transactions also into the mrt.
So, only those transactions which are not reversed on bod date will get printed if the
srgpm parameter is set to Y. If the parameter is set to N/NULL all the reversed
transactions will get excluded.
5.7.2 EMAILING FACILITY
Facility is provided to capture the email ID of the customer. This email ID can be used for
communicating with the customer. At present, the system provides a feature of sending the
following statements/advices to the customer through email.
1. Statement of account
2. Combined statement of account
3. Advice to customer

Once the statement is generated, the system will automatically transfer the file (FTP) to the mail
server. For this, the system uses the email id provided/furnished at the time of entering the
address details for any of the three addresses and also depends upon the mode of despatch.
In order to facilitate the system to transfer the file to the mail server, the user has to furnish the
necessary information like IP address, Login ID, Password etc. Using these information system
will transfer the file. These details are to be specified in a file “ftpinfo.dat” which should be in the
B2K_SECURE_DIR.
The information in the file will be like
192.168.77.30 #– IP address of the mail server

shekar # user ID
shekar123 # password
Since the file has to be transferred from one server to another server (mail server), in order to
have a security feature, the file can be encrypted and sent to the mail server. If the file is
encrypted and sent to the mail server, it needs to be decrypted before the mail is sent to the
customer. Encryption is an option given to the user. If he wants he can encrypt or send it in text
format also. If encryption is required, then the user has to set up a parameter to this effect in
HSCFM. Based on this flag, system will do the encryption. During encryption of the file, the key
word used for is the value entered in HSCFM for the field “encryption” at group level.
If the file is encrypted, it should be decrypted before finally sent to the customer. Utility for
decrypting is provided by us and should be available in the mail server. Decryption of the file is a
procedure which the Bank has to take care of.
The HSCFM set up for encryption are as under:

If the flag for encryption is set, system uses MD5 method of encryption. During decryption of the
file, the user has to enter the key word. The user should invoke “bauu9375” exe to decrypt the
file.
It is possible that the Bank generates statement for a range of customers by indicating the ID. It
is also possible that each customer will be more than one account. Since a single file is generated
for the entire process in order to identify the end of statement for each customer a value is put
before the commencement of the next customer‟s statement using the MRT feature. The value
that is put is <!>abc@efg.xyz<#>.
The explanation for the above value is
“!” is a field separator

“#” is the row marker
“abc@efg.xyz” is the mail id of the customer as got from the address
The values “!” and “#” can be changed in the MRT. The values which are used here should be
distinct and the user should ensure that those values are not used anywhere in the transaction
particulars for any TM transactions or in MTT scripts as this will affect the functionality itself.
The Bank can add any of its promotional materials also as a part of sending these
advices/statements.
5.7.3 HSWEEPS
It is possible that a customer has more than one account of the types like Savings Bank, Current
account, Overdraft facility, Term deposit accounts or Loan accounts. There may be a situation
that one of the SB accounts on which a cheque has been issued does not have enough funds for
passing of the same but substantial amount is available in any of the other account. In such a
situation the Bank may not return the cheque and would like to allow the debit to go through. In
order to facilitate such a feature, SWEEPS helps the Bank.
The Bank can have a pool of accounts for each customer from where the amounts could be taken.
The application provides a feature to pull the amounts available from various accounts, opened in
different currencies, under different scheme types. The scheme types from where the pull can be
done are SBA, CAA, CCA, ODA and TDA.
FBA, PCA, BIA and LAA even though belong to customer accounts are not eligible for this
feature. Along with these scheme types OAB and OAP are also not considered. However unlike
Single currency pools. TD accounts and operative accounts linked to FFD Accounts cannot be
included in a multi currency pool.

Finacle supports collection of charges for sweep operations. SWPC, SWPM and SWPR are the event
types used for creation, modification and regularisation of sweeps.
It is also possible to generate a report using SRCDR menu option – sweeps regularisation charges
detail report
Disable auto-linking to pool (Y/N)”. For a scheme When this parameter is set to „Y‟ new
accounts under the scheme and for customers having existing pools will not be automatically
added to the existing pools during account opening verification.
However, if the “Allow Sweeps” flag is set at scheme and customer levels, these accounts can be
linked to the pool manually at a later stage.
The following are the set up requirements for enabling this feature.
SET UP – HSCFM LEVEL
The bank can set up the order for sweep. The system will process accounts in that order only. The
order indicated here is on scheme type.

While indicating the pool of accounts, the user can include an account which does not belong to a
customer at all. In order to track that the above, exception is provided which is set up at HSCFM
level. This exception is validated when an accounts is attached for pool facility.
Sweeps Rate Code: To calculate the pool balance and for sweeping of funds from
surplus to deficit account in a multi currency pool, sweeps rate code is used that is
captured at the bank level.

SCHEME LEVEL PARAMETER – HGSPM – SCHEME DETAILS

In order to have the feature of sweep, the product/scheme level set up for the field “Allow
Sweeps” should be set to “Y”
CREATION OF A POOL FOR A CUSTOMER – MENU OPTION HSWEEPS
The functions available are C-Create / I-Inquire / M-Modify / R-Revoke Suspend / S-Suspend / X-
Cancel / V-Verify.

If the user is creating a pool, he has to use function code “C” with account number, customer id
and pool description pool type, mode of regularisation. CIF ID field is not mandatory. Once the
user indicates the account number ,pool description , pool type, mode of regularisation and clicks
on “Go”, the system picks up the primary customer ID from the account number indicated and
lists all the accounts which matches the relation ship of the account indicated as under:
Auto regularisation : When the value is set to „M‟, then automatic regularization of un-
regularized pool will be disabled and the, user will have to make a manual fund transfer to the
account in pool having deficit balance to bring it to a regularized state.
However no manual interference is allowed for FFDs. However, the operative accounts linked to
the FFDs can participate in the manual fund transfer.
Eg: If a pool has multiple operative accounts and one or more of these accounts have linked
FFDs, then system behavior for FFD-linked operative accounts and non-FFD-linked operative
account will differ. For a non-FFD-linked account, no automatic regularization will take place .
However, for FFD-linked operative accounts, regularization funding from FFDs will take place
automatically by the existing FFD regularization .
When the value of Mode of Sweep is set as „S‟ for a pool, the System will trigger regularization by
itself.
The option of modification of the Mode of Sweep is available

(a) Modification from „S‟ to „M‟: Modification of the Mode of Sweep from System to Manual is
allowed only for a regularized pool. If the pool is in an un-regularized state, then this modification
will not be allowed.
(b) Modification from „M‟ to „S‟: Modification of Mode of Sweep from Manual to System will be
allowed without any restrictions. However, this modification should always be done only
after due regularization of un-regularized pools by manually transferring funds from
funding accounts to the deficit accounts. System will display an information message stating
the same during such modification. However, there will no system restrictions if an un-regularized
pool in modified from Manual to System. The probable results of such a modification will be:
ORDER :
Once the system displays the eligible accounts for this pool, the user can indicate the order in
which the sweeps should happen within the scheme type. This order is based on the ascending
order of the account opening dates of the accounts in a pool for a give scheme type. There is no
restriction that the user should enter the order in the same way. He can just go on giving
whatever number he likes. But finally when the order is to be arrived, system will simply put it in
ascending order within the scheme type.
ACCOUNT NUMBER:
System first displays the account. If the user wants to add some more, he can do so at the end. If
the user picks up an account which does not match with the relation ship type of the account
indicated in the function block, the exception set up at HSCFM would be raised. While selecting an

account which does not match with the relation ship type of the indicated account, if that
customer ID is not enabled for sweeping, the user cannot select such accounts for the pool. If the
account is already selected for one pool such accounts cannot be included in any other pool
whether for the same customer or for a different customer. However this restriction is not
applicable for TDA type of account. All Flexi Fixed Deposits (TDA) type of accounts can be linked to
more than one pool also. If the user wants to use an account which is already in a different pool,
first the account should be removed from the pool where it is included and then use it in the other
pool. The accounts which are enabled for pool facility can only be used for SWEEP facility.
ACCOUNT NAME:
This is only a display field
SCHEME:
The scheme under which the account is opened.
CONTRIBUTION TO POOL
Contribution to pool to the extent of effective available amt.
while creating a single currency pool, accounts of the customer having currency
same as the pool currency are displayed on the detail page .
If the pool type is selected as multi currency and the next record button is
clicked, all the accounts of customer irrespective of the currency are displayed.
CHECKS AND VALIDATIONS

a) Single currency pool with the value of auto regularization flag as No can not be
created,
b) Multi Currency Pool can be created with auto regularization flag as Yes or No,
c) TD accounts cannot be linked to a multi currency pool,
d) Operative account having Flexi Fixed Type of deposit linked to it cannot be
linked to a multi currency pool,
e) Operative account having its Flexi Fixed Parameters set cannot be linked to a
multi currency pool,
f) By default, pool type is single currency and auto regularization flag as yes.

RELATION TYPE:
System displays the relation ship of the account. The relation ship could be Main account holder,
Joint account holder etc. This is a display field and protected
SWEEP:
Here the user can decide whether the account has to be used for sweeping or not. Even if at the
account level the flag is set as “N”, that account can be used for sweeping in here. This
modification will go and update the flag at account level also. At the account level the user cannot
go and modify the field values. It is a protected field at the account level.
Once the pool is created, the pool needs to be verified. Only after verification the pool will be
effective. Once the pool is created, system will show the effective available balance for the
account, which is being debited taking into the account the balances from all the accounts based
on the indicator (available balance or book balance) set up at pool level.
Other functions are modification. Cancellation is to be invoked before verification. It is also

possible to suspend a pool. Suspension of the pool will result in not considering the accounts for
sweeps. Revoking of suspension of the pool is also possible. Both suspension and revoking the
suspension requires verification. Inquire is another function available for the menu.
If the user is invoking any of the above function for the pool, description field <list> is available.
The user can list for a given CIF ID and select the pool that needs to be accessed.
If the pool is suspended, then the status of the pool is shown as “Suspended” else the status
would be “Active”
FUNCTIONALITY – CALCULATION OF AVAILABLE BALANCE

The available balance will be calculated based on the following process
1 System first identifies all the positive balance and negative balance accounts.
Negative(Debit) balance accounts could be accounts belonging to ODA and CCA accounts
where the balance are less than zero and still balances are available for withdrawal
2. Out of the positive balance accounts system goes by the order in which the
scheme types are mentioned at HSCFM
3. System then looks at the order of the accounts in which sweep should happen
within the scheme type based on the pool set up
4 System will now look at the parameter set up at scheme level to consider whether
minimum balance should be taken into account or not
5 Finally, the debit balance accounts would be considered
Effective Available Amount for Sweeps will display the Amount as zero where pool effective available
amount is negative.

While calculating the available amount, system also looks into whether it should take the available
balance or the book balance (balance in the account including the shadow balance. In case of
debit balance account shadow balance plus the un drawn amount of the limit or drawing power
plus TOD etc if any)
 If the set up is that book balance should be considered and debit against clearing credit is ERROR,
system will take into account the balance outstanding in the account including the clearing credit
but during sweeping out the funds, the system may encounter some problem. The user has to
handle this situation procedurally.
Since the amount is a stored value, this would be constantly monitored and any of these
processes which happens on the account will recalculate the available amount
Lien marking on the account

Any transaction to the account which affects the GAM balance
Account closure
Change in the sweep flag from “Y” to “N” or vice versa
Change in lending margin money
FUNCTIONALITY – PROCESS DURING DEBIT TRANSACTION

Once the system arrives at the effective available balance, a debit can be done to the account.
FUNCTIONALITY – PULL SWEEP PROCESS

The system tries to adjust the proceeds by pulling the amounts as explained in the availability of
the amount process. This process happens as an end of day process. If the user wants to adjust
the proceeds, he can invoke the menu SWOPS during the day also.
Note: Sweeps related process involving term deposit account(s) are explained in term deposit
document.
NOTE:
 In a pool it is possible to have accounts of only one currency
 User can maintain any number of pools for a single customer. If accounts are there in different
currencies, the user can have different pools involving different currencies
 A frozen account is not allowed to be a part of a pool. Also freezing of an account, which is in a
pool, is not allowed.
 The “Future Value Dated Balance” will not be considered during any operations of FFD and POOL
(i.e. FFD Breaking, FFD Creation, POOL Contribution, etc.)

HMPRPT : A menu option to report unregualrised manual pools . It chooses all the manual
pools and all the account in the pools and these details are the input for script PoolScript.scr . This scrip
identifies the A/cs having Debit balance and reports them as Un-regularised Accounts. The output is used by themprpt.mrt
to generate the final report.
5.7.4 CHANGE OF CUSTOMER ID FOR AN ACCOUNT
The customer Id can be changed for an account using HCCA menu option. If the account is
opened for a wrong customer, this option can be used to rectify the same. It also provides the
option of changing the Account ID , for the new CIF ID . An account can be made a joint account
by using this option. i.e by changing the individual cust id to a joint cust id. This process needs
verification.
MENU OPTION: HCCA
On clicking Go the following screen is displayed.
5.7.5 VIEWING THE JOINT HOLDERS FOR AN ACCOUNT:
MENU OPTION: HJHOLDER

The HJHOLDER menu option allows the user to view the details of joint holders or authorised
signatories of an account. This is useful while processing transactions in an account. This option
should be invoked from the background menu.
The Display Type field indicates the type of signatories list to view. The Valid Values are A for All
and J – Joint. Once these details are entered and accepted, the following screen appears.

The Relation Type field indicates the type of signatories, the Name field, name of the signatory
and the End date field indicates the valid date up to which the signatory is allowed to sign for the
account holder. The Remarks field stands for relevant remarks if any.
5.7.6 TRANSFER OF ACCOUNTS BETWEEN GLSUBHEADS
The accounts can be transferred between GL sub heads and also between the scheme codes.
Using the menu option HTACBSH, transfer is possible only between GL Subheads and using
HACXFRSC, transfer is possible between scheme codes also.

OPTION: HTACBSH
From GL Sub Head, To GL Sub Head and Currency code are mandatory. It is possible to transfer
the GL subhead of one particular account or range of accounts. When the account range is not
specified, the system displays all the accounts, which has From GL Sub Head. The user can select
the accounts that need to be transferred to the To GL Sub Head. The To GL subhead code entered
here should be a valid GL subhead defined for the corresponding scheme with the same currency.

5.7.7 TRANSFER OF ACCOUNTS BETWEEN SCHEMES
MENU OPTION: HACXFRSC
Using this menu option, accounts can be transferred between scheme codes of the same scheme
type belonging to the same SOL.
User has to enter the source and target scheme code and also the source and target GL subhead
codes, as they are mandatory. The source and target scheme codes should be of the same
scheme type. Currency code is also a mandatory field.
When account number is not entered, then currency code being one of the mandatory fields has to
be entered. The accounts for scheme change are selected based on the currency code also being
one of the criteria.
The non mandatory fields are:
Account Number - The account number that is to be transferred. If a account is entered then,
only one account is considered for transfer. If this field is kept blank then all the accounts in the
source scheme are considered depending on the value entered in the 'Account Status' field.
Account Status - This field is used to filter the accounts that are to be transferred. It can have
values [A]ctive, [D]ormant or [I]nactive. Using this field the user would be able to transfer
only Active, Inactive or Dormant accounts. If this field is kept null, then all types of accounts are
transferred.
Suppose the account number is entered, system automatically populates the status of the Account
and by default the trial mode will be set to Y. To do an actual transfer, change the flag to “N”.

When an account is considered for transfer, it can also be transferred across GLs. If trial mode is
'Y', then no actual updates are done on the database but all validations are done for that account.
In the update mode, if the account passes all validations successfully then the account is
considered for transfer otherwise a failure report is generated. If the account has any booked
payable or receivable interest or TDS then that amount is transferred and a transaction is created.
A financial transaction report is also generated for the same.
In Addition to the above the menu option will check/validate for the following conditions as
detailed here under, before the actual transfer of account to new scheme takes effect during
Verification run of the menu option. The system will generate a report of all such accounts,
which have been transferred as part of this process along with any errors due to which the
transfer could not take place.
Check if Account entered is valid.
Check if account is already closed.
Check if any non- authorized audit records are pending for the account.
Check if the account falls under the schemes SB/CA/CC/OD/TD.
Check if there are any transactions in entered status for the account being transferred.
Check for any future dated transactions
Check if TDS calc is up-to-date.
Check if the target scheme belongs to the same scheme type as the source scheme.
Check if the target scheme code currency is the same as source scheme code.
Check for future dated account open effective date.
Check for any cheques that are be logged in Inward/ Outward Clearing.
No transfer is allowed for following type of deposits

Certificate of deposit
Notice deposits
Recurring deposit.
The Account will be locked once the transfer is initiated through HACXFRSC menu
option. During this period no transactions will be allowed on the Account/Accounts.
Note: More details about Term Deposit account transfer are given in TD document.
The following values are carried out in the report

Success Report
1. Account Number
2. Account Name
3. Account Currency
4. Account Balance ( Clear Bal + Unclear Bal)
5. Transfer Date
6. User id who verified the transfer
7. Tran id

8. Tran date
9. Minimum balance information
10. Proxy posted transactions.
Failure Report
1. Account Number
2. Error Message
FT Report gets generated for all the transactions

Note: The Success report will not have the Tran id of GL transfer Transaction.
Audit trial is available for the account and for the menu option. This includes the transfer enterer
id, verified person id, the old record, the new record, the time stamp of such change. And when
inquired on the transferred customer account itself, the audit trail will contain the information of
old record, new record,
who entered, who verified with time stamp.
Audit Trail is available for the following tables
GAM, TAM, EIT and SCT.
General Information
The functionality will retain the same account number for the transferred account. Customers will
be able to use the same account for their ECS (electronic clearing services) mandate, standing
instructions, chequebook purposes.
As part of the transfer all the account related standing instructions, FFDs, linked sweeps/Liens will
also get carried over.
If the subject account is referred to as the operative account/applicant account/party account in

Bills module, documentary credits, forward contracts, the same relationship will be carried over.
The effects and report of transfer will take place only after the request of transfer has been
verified.
The Bank can opt to transfer either one account or all accounts belonging to one scheme to
another scheme.
If the account is transferred to a scheme which has the turnover flag as “Y”, but the earlier
scheme was not having it. In such cases the last turnover date for the new scheme will be the
Transferred date of the account. If in the old scheme the Turnover flag was “Y”, and the new
scheme is having turnover flag as “N”, then the system will not calculate any turnover for the

account after transfer. In such case the last turnover is the last run date and the system will not
update after that date.
The audit record remarks for the changed account will contain the text “Scheme code Change”.
Whenever there is a transfer of an account where charges are not defined, to a scheme where
charges are defined, then the account transferred date will be the last run date for future charge
calculations. The charges are minimum balance charges, account maintenance charges, ledger
folio charges, commitment charges.
As part of account transfer the following transactions are created:
For Accounts under SB/CA/CC/OD/TD
1. Transfer of Interest paid Account.
2. Transfer of Interest receivable Account.
3. Transfer Penal P & L Account.
4. Transfer Parking account.
For All Accounts except TD
5. Transfer of Interest suspense account
For TD Account only
6. Transfer of Penal Fee account.
Interest Treatment
The system will accrue the interest as per the new scheme
The interest payable account should be existing in the new scheme
If there are any interest adjustment entries for the subject customer account, then such entries
will be carried over along with the transfer activity.
Any retrospective change in the interest table code or the customer/account preferential as
applicable for the account will continue to work as it is working today even after the transfer. But
any recalculated interest will be charged to the respective income/expenditure account of the new
scheme.
If there is interest table code change and also there is a back value dated transaction beyond the
transfer date, then the system will recalculate the interest as if there is a new version added to
the existing interest table code
If it is a frequency based interest calculation like Savings Bank scheme where interest calculation
happens on semi annual basis and not in between, the Bank has to ensure that either the up-to-
date interest is calculated and collected according to old scheme before transfer. Or else calculate
and collect the interest in the new scheme for the entire period. Further, for any request for
change in interest method, the user has to ensure that the interest calculation is carried out
according to the old method and then transfer the account. Or else the system will calculate the

interest using the new interest method only. Also the user has to change the next interest
calculation date procedurally.
Minimum account closure period, account maintenance period of the new scheme will be applied
for the transferred account.
In case of change in the withholding tax % age, then the same is applicable from last interest
calculation date.
Note: Restrictions on TD account transfer are covered as part of the document on Term Deposits.
Procedural control to be carried out by the bank before transfer activity
Once the account is transferred, if the banks are generating the product profitability
reports, the allocation and apportionment of revenues and costs between the old and the
new scheme will be handled procedurally by the bank
If there is a change in GL subhead for that customer account because of the new scheme,
the user has to ensure that the specified GL is defined for that scheme.
The bank has to ensure that there are no financial transactions for the account in the
entered status, or transaction under clearing or any future dated transactions.
The bank has to ensure that are there no non-authorized audit record verification pending
for such accounts such as un verified records in for HINTTM, HACLHM, HCLM, HLNM,
HICHB
Bank has to ensure that backdated transactions for such transferred accounts beyond the
transferred dates are not passed after the transfer.
In case of transfer of SB accounts with a change in the interest method from Minimum
balance to Average or to End of day balance or otherwise, the user has to ensure that the
up-to-date interest is calculated and then the transfer takes place.
If there any transfer of FCNR Deposits, the bank has to take care of the consequent
reporting of such transactions in R-Return procedurally.
The MTT script used for creating transactions(if any) for transfer across placeholders is
createSchemeTranForAccount.scr
5.7.8 TRANSFER OF ACCOUNTS BETWEEN SOLS
The Menu option namely HACXFSOL is available for transfer of accounts across
SOLs.
MENU OPTION: HACXFSOL

The menu option has the following functionality as detailed here under
Function code will have the following values „T‟ – Transfer, „V‟ - Verify, „X‟ – Cancel.
When Function code „T‟ is the user can make a request for transfer. Source sol id and
destination sol id is mandatory. Any one of the other fields namely Account Number,
Customer Id, Scheme type, Scheme code, GL subhead has to be entered. Help message is
available for the same.
The effects of transfer and the report of transfer will take place only after the transfer
request has been verified.
The system will generate a report of all such accounts which have been transferred as part
of this process along with any errors or exceptions due to which the transfer could not
take place.
Account transfer across SOL is supported for only those accounts belonging to
SBA/CAA/CCA/ODA/TDA/LAA/PCA type of scheme.
The menu option will check/validate for the following conditions before the actual
transfer of account takes effect.
Check for future dated transactions
Check for any transaction that may have happened on the account on the day of transfer.
Check for any transactions that may be in entered status.
Check for any cheques that may be logged in Inward Clearing.
Check if there are any printing Jobs that are pending like HPSP,HPBP etc.
Check for existence of GL Subhead in the destination SOL id.
Check for existence of Placeholders in the destination SOL id.
Check for Non authorized records for the account
Transfer of customer account across sols allowed only for SB/CC/CA/OD/TD/PCA and LAA
type of accounts.

No transfer if the transfer request is for transferring account from one currency SOL to
another currency sol.
No transfer facility for Certificate of Deposits and Notice deposit types under TDA scheme
type.
The Account will be locked once the transfer is initiated through ACXFRSOL menu
option.
During this period no transactions will be allowed on the Account/Accounts.
The following values are available in the report
Success Report
1. Account Number
2. Account Name
3. Account Currency
4. Account Balance ( Clear Bal + Unclear Bal)
5. Transfer Date
6. User id who verified the transfer
7. Tran id
8. Tran date
9. Minimum balance information
10. Proxy posted transactions.
Failure Report
11. Account Number
12. Error Message
Report gets generated for all the transactions
Audit trial is available for the account and for the menu option. This includes the transfer
enterer id, verified person id, the old record, the new record, the time stamp of such
change. And when inquired on the transferred customer account itself, the audit trail
should contain the information of old record, new record, who entered, who verified with
time stamp is available.
Audit Trail is available for the following tables

GAM, TAM and SCT.
General Information
The functionality will retain the same account number for the transferred account.

Customers should be able to use the same account for their ECS (electronic clearing
services), standing instructions, and chequebook purposes.
 No transfer if the transfer request is for transferring account from one Data center to
another data center.
As part of the transfer all the account related standing instructions, FFDs, linked
sweeps/Liens will get carried over.
If the subject account is referred to as the operative account/applicant account/party
account in Bills module, documentary credits, forward contracts, the same relationship will
carried over.
The effects of transfer and the report of transfer will take place only after the transfer
request has been verified.
Following entry will be passed when the subject account is transferred to the new SOL.
Dr. Customer A/c 1234 in Sol 1 INR25000 (for accounts having credit balance)
Cr. Customer A/c 1234 in Sol 2 INR25000
Cr. ISO account of Sol 2 in SOL 1 INR25000
Dr. ISO account of Sol 1 in SOL 2 INR25000
Cr. Customer A/c 1235 in Sol 1 INR25000 (for accounts having debit balance)
Dr. Customer A/c 1235 in Sol 2 INR25000
Dr. ISO account of Sol 2 in SOL 1 INR25000
Cr. ISO account of Sol 1 in SOL 2 INR25000
Procedural control to be carried out by the Bank before transfer of accounts
If the account has been issued a MICR cheque, which has the branch code encoded on the
cheque, the Bank has to ensure that such chequebooks cannot be used after the account
transfer.
Back dated transactions for such transferred accounts beyond the transferred date are not
permitted after transfer.
There will not be any transfer allowed if there are any transactions for the account in the
entered status, or transaction under clearing or any future dated transactions. The user
has to ensure that such transactions are posted and then transfer the account.
There will not be any transfer allowed if there are any non-authorized items pending for
the customer account. Including pending printing jobs such as DD/Pay order including any
non-verified audit records for the subject account. User has to ensure the above.
For a customer account to be transferred, if the same has interest credit account specified

in payment instructions as the DD/Banker‟s cheque account of the existing sol, then the
user has to ensure that with the change of Sol, the DD/Banker cheque Account also should
be changed to that of the target sol.
Further, the user has to ensure that up-to-date charge calculation to be carried out for the
account prior to the transfer for the subject accounts. Before transfer the user has to
ensure that appropriate charge accounts/place holders are set up in the destination SOL so
the future charges can be credited to the destination sol.
Bank has to ensure that appropriate GL subhead exists for the transferred account in the
new sol.
Bank has to ensure that there is no transaction for the account is in proxy posted status.
Note
Once the account is transferred to the new sol, and any transactions as a result of this account
being referred in standing instructions, sweeps, or in bills, forward contracts, DCs, will result in
intersol transactions.
Limitation
Back dated transaction will fail in FAB when offline transactions are with date earlier to account
transfer of SOL are replayed.
5.8 CHEQUE BOOK MAINTENANCE
5.8.1 ISSUE OF CHEQUE BOOKS
 The issue of cheque books is two level
 The entry of cheques that are to be issued and verification of the same need to be done.
By default, the system displays list of cheques for the specified inventory type.
 It is possible to specify another employee who is in possession of cheque books for listing
of cheque books
 At the time of verification of the issue, the cheque book should be available either with
the person who has issued it or the person who is verifying the issue.
 The enterer and verifier cannot be the same person
 The system displays the current balance of the account and the total number of unused
leaves with the customer
 It is possible to select any range of cheque leaves
 It is suggested that at the employee location, cheque books should be split and kept as
per the physical no. of leaves in the book for easy issue of cheque(s)( upto 1000 leaves
per cheque book )
 It is possible to collect the cheque book issue charges while issuing cheques
 Cheque books issued to an account holder can be transferred to another account of the
same customer.
 It is possible to print the cheque book (Function – P). Appropriate mrt has to be specified
for the corresponding inventory class and type.
MENU OPTION: HICHB
During cheque book issue, the user has to enter the A/c number in the function block and cheque
type, and cheques with and collect MICR charges are to be entered. By default, the cheques with
column is populated with the employee_id of the user who is issuing the cheques. It is to be
ensured that the cheques being issued should be in the enterer/ verifier location at the time of
verification . Cheque book charges are collected as part of verification process.
In HSCFM, facility is provided to enable cheque book issue as effective only after entering the
Cheque book acknowledgement in the system. For this purpose, chequebook Ack Reqd? flag
should be set in HSCFM. If the flag is set, then during issue and verification of cheque book
process itself Acknowledgement process can be completed.
Otherwise subsequent to the issue and verification of cheque book issue, one more process of
entry and verification of Acknowledgement is to be made in the system using menu option
„HCHBM‟.
When flag value is not set in HSCFM, then there is no need for entry and verification of
Acknowledgement to make the cheque book issue effective.
MENU OPTION : HCHQUPLD

A cheque book can be issued for an unverified account via an upload file if the cheque allowed
flag is set as “Y” in the upload menu
The upload files should be placed in cdci logs folder. After uploading check for the entries in CBT
table.
Issue of cheque books without validating the inventory can be done using the menu option
HICHBA. The screen shot is as follows.

Verification of cheque book issed is done using HICHB/HICHBA
5.8.1.1 STOP PAYMENT
 Facility to stop a single cheque or a series of cheques, is available
 The details are accepted only if the number of leaves stopped is one
 A Memo pad entry is created on entry of stop payment details. On verification of stop
payment details, the memo pad entry is deleted by the system
 Charges can be collected for processing Stop Payments. Stop payment charges
transaction is created as part of verification process. Event_id is specified in HGSPM.
MENU OPTION: HSPP, HSPPAU

The HSPP menu option is used to stop or revoke payment processing.
General Details:

It is possible to print the stop payment advice immediately or later or specify “Not Required”. If it
is specified as “immediate”, then the advice will be printed during verification of stop payment
process. This will use the MRT specified in HSPP.
Charge details:

The payment that is stopped through HSPP has to be authorised through the HSPPAU menu
option. Stop payment charge details can be seen through the option „C‟. Stop payment charges is
not modifiable.
If the cheque comes for payment before the stop payment process is verified, system raises an
exception “Chq stopped but not verified”.
It is possible to print/re-print stop payment advice using SPP at any later date also.
5.8.2 CHEQUE BOOK MAINTENANCE
 The Cheque maintenance option provides facility for acknowledge, cautioning, revoking
the caution and destroying cheques.
 The Inquire option will display all cheques along with their status
 It is possible to explode and obtain more details about an individual leaf
 Updation of cheque status - HUCS
MENU OPTION: HCHBM

5.8.3 UPDATION OF CHEQUE STATUS-HUCS
This menu option can be used for changing the cheque status as Unused and Paid. Some times it
happens that the user enters the cheque number wrongly and if it is not paid system update the
wrong cheque number as “paid”. But when actually that cheque is presented, the system may not
allow debit to go through especially when the exception is set as “Error”. Under this
circumstances, if the user wants to change the status of the original cheque paid to a different
number and the present cheque status to “unpaid” then the system provides a feature to do so.
The user has to invoke the menu HUCS to update the cheque status.
MENU OPTION: HUCS

The user has to enter the account number, instrument number and <GO>. System validates with
the instrument number indicated, validates against the begin cheque number for that particular
number and displays the current status of the instrument. There are chances that the cheque
number can have the same begin number. In that case use has to go and change the begin
cheque number. User can go and indicate the new value and <submit>. This will update the
status. This process requires verification by the same menu option.
5.8.4 PDC FOR OPERATIVE ACCOUNTS
The post dated cheques (PDC) submitted by the customer for credit to the operative accounts can
be managed and maintained. PDCs supported for operative accounts are:
Clearing PDC: PDCs submitted are issued from Different Data center.
Transfer PDC: PDCs submitted are issued from same Data center.
Bank can take responsibility of lodging the clearing PDCs in clearing on the
instrument date and crediting the proceeds to the customer accounts. In case of transfer
pdcs, bank creates transfer transaction on the instrument date.
TRANSACTION ACCOUNT PDC MAINTENANCE
Maintaining the PDCs for transaction accounts (operative accounts) can be done with menu option
HTAPM (Transaction Account PDC Maintenance). PDCs will be accepted for SBA, CCA, CAA, ODA
and non-partitioned OAB type of accounts. When PDC is added or modified account drawing power
is updated , contingent transactions are made, charges can be collected for events like PDC
Creation,Substitution,Delay Presentation Etc with the set up at HPTTM. This is a multi record
screen.
The operations of M (MAINTAIN), R (RETURN), I (INQUIRE), V (VERIFY), X (CANCEL), G (MARK

MISPLACED), E (REVOKE MISPLACE), D (SUSPEND) and K (REVOKE SUSPEND) are possible to this
menu option.
MAINTAIN: Maintain function is to accept the PDC cheques. In Maintain function, specify the
account to which credit should happen, and click on Accept. On click of accept the screen interface
is as follows:

Start No.: The start number of the PDC cheques to be submitted to the bank.
No. Of PDC: Total number of PDC submitted to the bank.
Next PDC Date: The immediate next date for lodging the cheque for realization
Freq: The frequency at which the cheques should be submitted for realization.
PDC Amt: The amount of PDC to be realized
PDC Type: PDCs submitted to the bank can be Clearing or Transfer type. If the PDCs are of
Clearing type, O – clearing should be selected else if it is of transfer type, X Transfer needs to be
selected. If the PDC is of transfer type, Transfer A/c ID is mandatory. If the PDCs
Bank: The bank code of the PDC.
Branch: The branch code to which the PDC file belongs .
When a bank branch combination is specified, then MICR code is not must. MICR code is
automatically populated based on bank branch combination.
Record Del: If a wrong entry is made, deletion of the wrong entry can be done by checking the
flag against the record. Unique set number for PDC‟s will be generated as shown below.
This option requires verification. As soon as one comes in verification mode by giving the account
number, the following screen comes up:

The start number of the PDC is given in hyper link. ON click of the hyperlink, the following screen
comes which shows the payment schedule and the cheque .

To verify the record the user has to select the record and press the submit button the PDC
maintenance is saved and verified.
SUSPEND OF PDC: The PDC which are accepted can be suspended using function suspend of
HTAPM menu. The function is D-Suspend. The user has to enter the account number of the
customer and also the set number needs to be entered. The screen interface is as follows:
The record needs to be selected before pressing Submit button. Suspend of PDC is allowed for a
set. Each PDC of that sets will be marked as suspended. Selective Suspension within a set is not
allowed e.g. - one set corresponds to 10 PDCs from 1000 to 1009. All the 10 will be marked as
suspended; user can not select only 1002 or 1003 for suspension.
PDCs are in entered status can be suspended. Normal lodging cannot be done for these PDCs.
After suspension function, the status of checks will show as suspended as below:
Revocation of suspension is possible through REVOKE SUSPEND Option. After revocation all
normal operations can be done on these set of cheques.

There could be a chance of misplacement of PDC which can be marked in the system using
function of MARK MISPLACE. The screen interface is as follows:
Unlike suspension, mark misplace can also be done for a specific PDC only. Individual PDC mark
misplace is possible. PDC which are in entered status only can be marked misplaced. Normal
operations cannot be done on the PDC which are mark misplaced. Check the box corresponding to
the cheque which is misplaced and submit, which marks the specific cheque misplaced.
If PDC which is marked misplaced is found, one can do revoke misplace using REVOKE MISPLACE
function. REVOKE MISPLACE can also be done for a specific PDC.
Bank can return the PDC to the customer using function RETURN. PDC which are in entered status
and bounced status only can be return to customer. Selective return is also possible. During
return function system will show only those which are in entered status or bounced status. Other
status PDC are not shown at all.
CLEARING ZONE MAINTENANCE FOR POST DATED CHEQUES-HPDCZM
HPDCZM menu option is used to capture zone code for a given bank and branch combination. This
option will ensure the PDC cheques are lodged to the appropriate clearing zone. When the batch
job HLAPTAP which is used for lodging of the PDC in the clearing zone user can specify the clearing
zone to which the pdc‟s are to be lodged . However in real life different cheques may go to

different accounts based on bank code, branch code and high value/low value. In HPDCZM the
high value and low value zone is maintained for a given bank and branch. This is stored in PDCZT
table. While running LAP TAP if appropriate zone code cannot be found for the bank+branch
combination then the zone code provided in the LAPTAP/HLAPTAP will be used.The screen shot is
show below.
On Clicking GO the following screen is displayed
LODGING AND PROCESSING OF PDC
Once the PDC are accepted, the same needs to be lodged and processed in clearing, on the
instrument date and crediting the proceedings to the customer accounts. In case of transfer PDC,
a transfer transaction will be created.
For transfer PDC, the transaction will happen as a part of lodging and status is immediately
updated. The lodging date will be the value date of transaction. All scheme level check of account
frozen, account closed or stop payment will be done. For clearing PDC, the status is changed as a
batch job which will be called as a part of EOD.
Lodging of PDC can be a normal lodging or Exceptional lodging. Normal lodging is allowed for
instruments dates less than or equal to BOD date. PDC which are in entered status can only be
lodged in normal lodging. PDC in entered, bounced and misplaced status can only be lodged
through exceptional lodging. All PDC of instrument dates less than or equal to BOD date only are
picked up for exceptional lodging.
Menu option HLAPTAP is used to do normal lodge and process the PDCs. The lodging of PDC can
be based on the accounts range or on scheme codes. Zone details needs to be specified for
lodging the PDC. Based on the criteria, application automatically picks up the instruments and
lodged. Application gives a success report or failure report based on the situation. For clearing
PDC after lodging the status is updated to cleared. For transfer PDC in the lodging process if the
transfer of amount from the source account to destination account is success, status will be
marked as cleared else it will be marked as bounced. For clearing PDC clearing cycle will update
the bounce status. At the time of verification of PDC maintenance and PDC Clearing drawing power
of account is updated.
 At the time of maintenance DP is increased.At the time of regularisation /reject DP is
decreased.
 Contingent entry will be created at the time of PDC maintenance. The contingent entry will
be reversed at the time of regularisation/reject.
The screen interface is as follows:
This can be done in trail mode or actual mode.
TRAIL MODE: PDC in entered status will be picked up for lodging. This is mainly for report.
Future dated lodging is also allowed here.
ACTUAL MODE: The instrument date should be less then or equal to BOD date. For clearing PDC,
the instrument date should be less than or equal to zone date.Once the actual mode is run, one
can see the automatic lode of the instruments through menu option OCLODGE. Upon successful
run of the batch programme a Acknowledgement letter of receipt of Post Dated Cheques is
generated for the customer in the background.
Exceptional lodging of PDC is done through menu option HXLAPTAP. The screen interface is as
follows:
The criteria for exceptional lodging can be instrument dates range or cheque number ranges or no
of cheques. One can also specify weather only Bounced PDCs or Misplaced PDCs should be
consider using the status type. If the status type is blanked all the eligible status is considered.

Bounce count: once can specify the PDCs to be considered which has bounced less than or equal
to the number specified here.
Lodge all pending: If this flag is Y, system tries to lodge all the instruments which are due but not
lodged till date.
UPLOAD OF TRANSACTION ACCOUNT PDC
The existing PDCs details for transaction accounts can be uploaded to the database through a
menu option HUPLTAP. The screen interface is as follows:
File Name: The upload file name with complete path should be specified here.
Test Mode: If this field value is “Y”, just reports are generated. No database updates happen.
Rename File: Weather the file name should be renamed after the upload or not. If the upload file
name should be renamed, the value should be given as “Y”
Acknowledgement Letter: If this flag is “Y”, apart from status report, an acknowledgement letter
to customer will also generate with account number, start PDC and end PDC numbers.
Note:
The upload account should be of type SBA, CCA, CAA, ODA or non-partition OAB.Account should
not be closed, suspended or deleted and should be verified.PDC type should be O (Clearing) or X
(Transfer).PDC frequency can be bimonthly, monthly, quarterly, half-yearly or yearly.There should
not be any pending verification of previous PDCs for the account.Either the bank and branch code
or the MICR code should be entered.In case of transfer PDCs, transfer account should be
specified.No PDC in current set should have added previously.For clearing PDCs, cheque level
validations will be done. ( like the cheque issued to the account, not stopped etc).
5.8.5 TRANSFER OF CHEQUE BOOKS (HXFCHBAC):
Cheque Books can be transferred between accounts of the same customer. Verification is done
with the same menu option or through XFCHACAU
5.9 FREEZING OF ACCOUNTS

The freeze status of accounts can be maintained using the HAFSM menu option. The screen that
appears when the HAFSM menu option is invoked is shown below.
„Freeze Remarks 1‟, „Freeze Remarks 2‟, „Freeze Remarks 3‟ and „Freeze Remarks 4‟ and „Freeze
Remarks 5‟ are available in the details page of the menu to capture the freeze remarks for the
account while freezing it.
The menu option HFEPM is used to define the freeze exception parameters. Here we can define the
reasons and the exceptions for freeze. The screen shot looks as follows:

The Freeze Reason Code indicates the reason for freezing the accounts. This field is mandatory if
the Function field is specified as F. The Freeze Code is the code for the type of freeze for the
accounts. Valid Values are : T - Total Freeze D - Debit only and C - credit only. The Ent. Tran
indicates the number of part transactions in the entered state for the account. The Clearing
I/Wfield indicates the number of pending inward clearing transactions. The Clearing O/W field
indicates the number of pending outward clearing transactions. The SI field stands for the number
of active standing instructions for the account. The AT field indicates the number of un dispatched
ATM transactions. The AN field stands for the number of un despatched Anywhere transactions.
The SW field indicates the number of un despatched Switch transactions.
User cannot freeze those accounts which are participating in pool.
Salient feature:
By default it will list all A/cs of the customer.
But only A/cs not in pool and not frozen will be selected for freezing.
The system can display maximum 8 A/cs in the list block.
If any of those 8 A/cs are found to be participating in pool system throws a warning
message "Cannot Freeze Accounts which are participating in Pool". Upon key-commit the
remaining all unfreeze and non-pool A/cs will be frozen.
HBFAC - Batch job can be created for batch freezing of accounts based on the
criteria chosen by the user. The criteria screen will give user the option of
choosing the criteria from the fields available on page.
The mandatory fields in the screen are:-

1. Set Id
2. Report To.
Rest are optional fields which can be given to fetch the records whose freeze
status needs to be modified.
User can mark the accounts as Total Freeze (F) or Debit freeze (D) or
Credit Freeze (C).
An account which is in freeze status already the behaviour will be as given in the table
below and as explained further in the bulleted points under the table.
Batch
Freeze Total Debit Credit
Account
Freeze Status
Total Retain Status Retain Status Retain Status

Debit Change to „Total Retain Status Change to „Total
Freeze‟ Freeze‟
Credit Change to „Total Change to „Total Retain Status
Freeze‟ Freeze‟
If in case an account is already debit frozen and comes for credit freeze it will be
updated to Total freeze , same will be the case if in case it is already a credit freeze
and it comes for debit freeze then also it will be updated to Total freeze.
If in case an account is already credit or debit frozen and the user does not change the
freeze code of the account and the output from the script is the original freeze code of
the account it remains unmodified and same will get updated.
In case it is already total freeze and it comes for Debit/Credit freeze it will not change
the status of the account and it will remain as total freeze.
An account which has been manually frozen for Credit/Debit Freeze is available for
Total freeze type in the batch mode.

Finacle also provides the facility to log the details of accesses done from online ONS
menus on accounts that are marked restricted for access through Restricted Accounts
Access Inquiry.
LOGGING ACCESS DETAILS FOR RESTRICTED ACCOUNTS
An account that satisfies any of the conditions below is a restricted account.

 Status is Inactive / Dormant
 Is Frozen [total/debit/credit]
 Is having an access code set up through HAACM.
The logic to check if an account is restricted is present in RestrictedAcctAccess.scr .
 The set of menus which are to be tracked for restricted access will be listed and provided.
 Menus can be added or taken off this list, provided the modifying person has sufficient
privileges to modify this list.
 Also, the menu has to be an online ONS menu.
Whenever an account which is restricted in nature is accessed by any online

fincore/FinCRV menus, a log file containing below details will be written in the directory
RSTRCTD_ACCT_AXS_LOG_DIR. This directory has to be created as mentioned in setup.
 User id who accessed the account
 User work class of the user
 CIF id of the account
 Account id
 Date & time of access
 Menu id from which account was accessed
 Reason for restriction
 Emp name of the user id
 Sol id where to which user belongs
 Acct Name for the account id
 Bank ID
For every access to a restricted account, there will be log file created. These files will be
later processed by another finacle script [called through a batch exe] and the contents of these
files will be dumped to a customized table and these files will be deleted once details are
successfully inserted to the table.
 If the file containing the list of menus is not readable/accessible or

 In case directory RSTRCTD_ACCT_AXS_LOG_DIR doesn‟t have write permissions
an error log named RestrictedAcctAccess_ERROR.log will be dumped in the default working
directory for finlistval services [cdci_logs]. The script will not throw any error to the user and it
will continue with the operations normally.
The batch exe babx4061 should be run periodically with

DumpRestrictedAcctAccessDetails.scr as the argument. This script reads the text files in the
directory RSTRCTD_ACCT_AXS_LOG_DIR, inserts the details into the customized table
CUST_AXS_LOG. This customized table has to be setup as specified above.
Upon successfully inserting this data to DB, the text files will be deleted from the folder. In
case the script fails, a file RestrictedAcctAccess_ERROR.log with error details will be written to
cdci_logs folder.
 The module is specifically meant for ONS menus [FinCore and CRV] only.
 Allied products FAB/FI/CRM is not under the scope of the current module.
 If an account id range is specified and account ids are listed, only the from and to
account‟s access details will be logged. The account ids falling in the range will not
be taken into consideration.
 The access details will be logged only if accounts are accessed from online ONS
menus [FinCORE/FinCRV].
 An account id if accessed by
o A batch exe
o A daemon process
o Implicit system level transactions [interest calculations etc.]
Will not be considered and access details will not be logged.
 No purging mechanism for the customization table is provided. This has to be

addressed during customization.
5.10 CLOSURE OF ACCOUNTS (HCAAC)

Closing of an account is done in two stages
 Closure of accounts is done using the menu option HCAAC and verification of closure is
done through the same menu option.
 The initiation of closure process displays information such as the date up to which interest
has been calculated, whether unused cheques are with the customers, whether un posted
transactions exist for the account etc.
 The pending processes have to be initiated and completed before verification of account
closure

The user should ensure that „shadow balance amount‟ and „account balance amount‟ are zero
before closure. Once the auto interest calculation is run, there is no need to run it again, provided
no transactions have been put to that account. The system displays the message „interest
calculation is up to date now‟.
The charges related to an account can be calculated before closing the account using the menu
option HCACC. After this the account can be closed.
BATCH CLOSURE OF OPERATIVE ACCOUNTS : BCLSOP
A bank normally has a huge numbers of operative accounts running into thousands, lots of them
in dormant status or with negligible balance with little or no-activity on such accounts. The present
method of Account closure through HOAAC is an online method and doesn‟t provide any interface
for such mass closures.
BCLSOP menu option has been enabled to close OPERATIVE ACCOUNTS ( SB , CA ,ODA and CCA type of accounts )
5.11 PAST DUE MOVEMENT OF ACCOUNTS

In case an asset of the bank becomes a non-performing asset, the bank would like to reverse
income booking done for the account. The bank will classify the asset and then move the account
into the non accrual mode. The income booked would be reversed to the Suspense account. Past
due movement of Transaction accounts is enabled in the menu options of HSASCL and HMAPD.
The un-serviced interest during the look-back period, and the total interest booked but not applied
have to be moved to suspense.
Look-back period specifies the number of days to be considered for back calculation and
assessment of un-serviced Interest (de-recognition of Income) portion from the Past due / Charge
off date.

5.12 CHARGE OFF CC/OD A/C

There might be some customer accounts such as Overdraft or Cash Credit accounts in debit
balance to which no credit is forthcoming and even the security is far below the outstanding
amount. In these cases, bank may take a conscious decision to charge-off these accounts which
remain past – due for a defined period of time so as to present a true picture of its assets and
liabilities.
Similarly , some Current accounts and Savings bank accounts might also be in Debit balance with
no servicing of the Interest or of the charges. For eg: this might be due to grant of TOD aftere
which no money has been credited or is likely to be credited. In such cases, the Bank might want
to charge-off these accounts in debit balance.
The account to be charged off may or may not be a past due account. When a non – past due
account is sought to be charged off, at the time of running the charge off process, systems should
first identify the un-serviced interest component in the account and charge the same to Profit and
Loss account by way of transfer to Interest Suspense account, and mark the account as past –
due.
HCOTA menu option will work in the modes ; Charge off, Verify , Reversal Charge-off and Cancel.
Charge off mode could be full or partical. If the user has selected partial write off, then he has to
enter the amount that needs to be written off. Else system assumes that the entire amount I
balance in the account is being written off.
Note:
Whether the account is written off partially or in full, the system adjusts the entire
amount which is lying in interest suspense account. This is one by debiting the interest
suspense account and crediting the loan account. This is the portion of interest which is
derecognised by marking account as past due.
VERIFICATION OF CHARGE OFF:

The charge off process requires verification. Transaction are actually created as a part of
verification. User will be invoking the same menu option – HCOTA – for verification.

REVERSAL OF CHARGE OFF
If for any reason the user has done charge off of a wrong account, it is possible to reverse the
process. The user will be invoking the same menu option for reversal of the charge off process.
The option to be selected would be Reversal of Charge off and the user will select the account for
which reversal process has to be initiated and click on Accept button.
On <Accept> system will display the transaction that is going to be created as a part of reversal of
charge off process. Whatever transaction got created as a part of the charge off process will be
reversed.
VERIFICATION OF REVERSAL OF CHARGE OFF:

The process of reversal of charge off requires verification and transaction are created only as a
part of verification. The verification is done using the same menu option by a different user.
RECOVERY/REVERSAL AFTER CHARGE OFF

. After an account has been charged off, banks put in efforts for realisation of dues. In case, there
are some recoveries, banks have a practice of crediting the same to Profit and Loss Account. The
recovery sequence will be the following:
1. Amount written off
2. Un-serviced , applied interest amount lying in Suspense ( due to partial movement at
the time of partial charge-off).
3. booked interest already moved from suspense
4. booked interest lying in suspense
5. accrued but not booked interest.
A new menu option HTARACO has been provided for recovery after Charge Off of transaction
Accounts for which the screen interface is as under:

After indicating all the details user has to click on Accept button.
The system displays the information on the account as to what are all pending. System by default
adjusts the recoveries in the account to Principal. But the user has the option to modify the details
and can indicate what is being recovered on the account. Based on the information provided to the
system, system creates appropriate transactions to the respective accounts.
Following are the transaction that are created

Principal recovery
Debit Cash/customer account
Credit CC/OD account
Debit Charge off account
Credit Recovery loss line
Interest recovery/Accrued Interest recovery
Debit Cash/Customer account
Credit Interest income account
Recovery of charges/other charges
Debit Cash/Customer account
Credit Income account (Depending upon the Charge set up)
System displays information about transaction creation process as explained above depending
upon the recovery items indicated. If it is OK user has to <Accept> to proceed further. Successful
completion of the process is indicated as under:
VERIFICATION OF COLLECTION AFTER CHARGE OFF
The above process requires verification. Transactions are created as a part of the verification
process only. Verification is to be carried out using the same menu HTARACO.
REVERSAL OF COLLECTION AFTER CHARGE OFF
If for any reason wrong collections are indicated to a charged off account, it can be reversed using
the same menu option ie HTARACO.
The user has to indicate the account for which reversal transaction has to happen. The user also
needs to select the transaction which needs to be reversed. In order to select the transaction
which needs to be reversed, <list> facility is available in the field “Reversal Transaction ID”. User
can <list> and select the transaction that needs to be reversed.
The reversal transaction can be either Cash or Transfer. If it is transfer transaction, then user has
to enter the account ID for which the credit should happen.

On <selecting> the transaction and clicking on <Go> button will bring up the above screen
indicating the transaction that are going to be created. If the user is OK with the displayed
information he can click on <Submit> button which will complete the process
VERIFICATION OF REVERSAL OF COLLECTION AFTER CHARGE

OFF
The above process requires verification. Verification is done using the same menu option by a
different user.
For details on Asset Classification of CC / OD accounts, refer to the document

on Asset Classification and Provisioning norms.
5.13 PURGING OF DATA

5.13.1 UPDATE ACCOUNT PURGE FLAG
Accounts of a particular customer can be enabled for the purging program by invoking the option
HACPF and updating the purge enable flag. The Screen is as shown below.
MENU OPTION: HACPF
5.13.2 PURGING OF CUSTOMER DATA
Over a period of time, some of the customer information captured may no longer be needed and
to save space, the data can be purged. The customer master data can be purged through the
menu option HPUCMG. The screen is as shown below.

The prerequisites for purging customer master information of a particular customer is that the
customer should not hold any accounts and if they exist and are closed then, the accounts need to
be purged and then the customer master record.
MENU OPTION: HPUCMG
5.13.3 PURGING OF AN ACCOUNT
A closed account can be purged provided all the transactions to that account are purged. The
menu option HPUACC. The screen details are as shown below.
MENU OPTION: HPUACC
5.14 INQUIRY AND REPORTS

This section covers the inquiry and report options used by the general users.
5.14.1 ACCOUNT SELECTION
Based on a specific criteria, inquiry on accounts can be done by invoking the menu option HACS.
The Screen details for HACS is as shown below.

On executing the option a list of accounts that match the criteria specified are displayed as shown
below.
5.14.2 ACCOUNT SELECTION PRINT
HACSP is a menu option, which is available for the account selection print.

This menu option is ROTM enabled. The user can write his own MRT and indicate it as a part of
ROTM and depending upon the requirement, he can generate the report. In the first screen the
system accepts the MRT file name. <accept> from here will take the user to the regular ACS
menu option explained/shown above. By giving the required criteria, the user can list the account
and print the report by giving one more <accept>. <accept> brings up the print parameter
screen from where the user can generate the report.
5.14.3 CHEQUE BOOK ISSUED REGISTER PRINTING
A report of all cheque books issued to customers can be generated by executing the menu option
HCHBIR. The screen details are as shown below.

5.14.4 COMPONENTS OF ACCOUNT BALANCE INQUIRY
MENU OPTION: HACCBAL/ HACCBALI
Effective available balance shown here and in TM as well as HACTODM menu options are based on
the scripting logic. The user has to write the suitable logic for the script. Script name is
“GetEffAvailableAmt.scr”. “Future Amt.” will display the total future balance amount for the
particular account and “Overdue Future Liab” is sum of all future value dated debit as of BOD
date. “Eff. Future Avail. Amt” is available amount plus future component that is available to
account for any transaction. If “Calc. DAFA bsd on Cr. Comp” is set as „Y‟ at HSCFM, “Future Cr
Amt” will be displayed.
Another menu option which helps in inquiring on the balances of accounts pertaining to one CIF ID
is HCUACC.
5.14.5 ACCOUNT LEDGER INQUIRY
The account ledger inquiry can be invoked through the menu option HACLI. The screen details are
as shown below.

MENU OPTION: HACLI
5.14.6 ACCOUNTS BELOW MINIMUM BALANCE
Invoking the menu option ABMR can get the report of all accounts below minimum balance.
MENU OPTION: HABMR
5.14.7 AVERAGE BALANCE REPORT
The Average Balance of an account or for a range of accounts can be obtained using the Menu
Option HABR. The criteria screen will give user the option of choosing the criteria from the fields
available on page. The CRV menu option HABI is used for viewing Average Monthly, Quarterly,
half-yearly and yearly balances for an account.
Average Balance Computation in HABR and HABI
1. Financial Start date for the Year entered will be based on the Financial Year Start
DD/MM given in HSCFM menu.
2. For the A/c Id entered, if the Account is not active for the year entered, it gives an error
message “Record not found for the period given”. Example: If the BOD date is 20 th
Jun2007, Financial Year selected is Previous, Financial Start date is 1 st Jan 2006 and
Account opened date is 3rd Mar 2007, then it gives the above mentioned error message as
account is not active for the Financial year 2006.
3. For the A/c Id entered, if the Account is already closed ie. Account closed date is before
the Financial Start Date, then it gives an error message - “Record not found for the period
given”.
Example: If the Financial Start Date is 1st Jan 2006 and Account Closed date is 25th Dec
2005,

it gives the above mentioned error message.
4. For the A/c Id entered if the account is opened /closed during the year selected, then the
Average balance will be computed for the exact no. of the days the account was active.
5. If there are no records in the EAB table for the A/c Id and financial year entered, it gives
the error message – “Record not found for the period given”.
6. The average balance of a particular period will be available only after the period has
elapsed fully. For E.g. In calculation of monthly balances the average balance of March
2007 will be available only from April 1st 2007 onwards. In case of Quarterly, Average
Balance will be 0 as that quarter has not yet lapsed. Same applies to half-yearly and
yearly.
7. Average balance for an account is calculated by adding up the value date balance for each
day of the period divided by the total no of days in the period.
8. If the account is opened / closed during the Financial Year entered, then Average Balance
will be computed as: Sum of value date balance divided by the exact number of days the
account was active.
9. If the account is opened during the year entered, then the EOD balance from the Financial
Start date to the Account open date will be taken as 0.
10. If the account is closed during the year entered then the EOD balance from the Account
Closed date to the Financial End date will be taken as 0.
11. If the account is active only partially in the period being considered, only those days in
which the account was active /open will be considered for average balance calculation.
12. If the year entered is a leap year, the average debit, credit and account balance for
monthly, quarterly and half yearly balances involving February will be computed on the
basis of 29 days. Also for calculation of monthly balances of Feb- the no. of days
considered will be 29.
Calculating Average Balance for an account.

Example 1:
1st April (Opening Balance) 500.00 Cr
3rd April 1000.00 Cr
th
10 April 2000.00 Cr
th
15 April 1200.00 Dr
th
20 April 1000.00 Cr
rd
3 May 500.00 Cr
th
15 May 1000.00 Dr
th
30 May 1200.00 Dr
th
20 June 1000.00 Cr (Closing Balance)
st
Financial Start Date is 1 April.
BOD Date is 25th Jun2006
Year selected is Current.
Average Monthly Balance Calculation - (for the month of April)
Average Credit Monthly Balance
1160 = 500 x 2 + 1000 x 7 + 2000 x 5 + 1000 x 11

--------------------------------------------------------------
30

Average Debit Monthly Balance:
1200 = 1200 x 5
------------
30
Average Account Monthly Balance
776 = 500 x 2 + 1000 x 7 + 2000 x 5 + 1000 x 11 + (-1200) x 5

----------------------------------------------------------------------------
30
Average Quarterly Balance Calculation –

(Quarter1 consisting of months April, May, June)
Average Credit Quarterly Balance
= (500 x 2) + (1000 x 7) + (2000 x 5) + (1000 x 13) + (500 x 13) + ( 1000 x 11)

-----------------------------------------------------------------------------------------
-------
91
Average Debit Quarterly Balance:
= (1200 x 5) + (1000 x 16) + (1200 x 22)

------------------------------------------------
91
Average Account Quarterly Balance
= (500x2)+(1000x7)+(2000x5)+(1000x13)+(500x13)+(1000x11) +(-1200x5)+(-1000x16)+(-
1200x22)]
-------------------------------------------------------------------------------------------------------
-----------------
91
Similarly, for Half-yearly and yearly, Average Balance is computed.
Example 2:
Balances
1st April 500.00 Cr
rd
3 April 1000.00 Cr
th
10 April 2000.00 Cr

15th April 1200.00 Dr

th
20 April 1000.00 Cr
rd
3 May 500.00 Cr
15th May 1000.00 Dr
st
31 Dec 2099 1500.00 Cr
Financial Start Date is 1st April.

BOD Date is 25th Jun2006
Year selected is Current.
Average Monthly balance for April:

From 1st Apr to 19th Apr, Average Balance will be computed as mentioned in the above example.
From 20th Apr to 2nd may, the balance is 500. So, From Apr 20th to Apr 30th, the balance will be
considered as 500
Similarly for the month – May:

From 1st May to 2nd May, balance will be considered as 500
From 3rd May to 14th May – 1000
From 15th May to 30th May, balance will be 1500 as the High date given is 31 Dec 2099.
5.14.8 ACCOUNT TURNOVER INQUIRY
The turnover details of an account can be displayed by executing the menu option HACTI. the
details will be as displayed below. The user can explode to the individual transaction and see the
transaction details.
MENU OPTION: HACTI
 NOTE: If there are any value dated transaction which affects the frequency of the account
turnover details subsequent to running the process, the system will make appropriate changes to
the turnover details if the value date of the transactions pertain to the frequency period.

MENU OPTION : HATO

It is a batch menu option which helps to build the turnover for an account.
5.14.9 ACCOUNT MASTER PRINT
The print of all the details of a account or a set of accounts can be got by executing the report
option HACMP. The screen of HACMP is as shown below.
MENU OPTION: HACMP

5.14.10 CHEQUE BOOK PRINTING (RANGE OF ACCOUNTS)
Cheque Books for a range of accounts can be printed using the web menu option CBP. The screen
is shown below. The mrt file must be indicated for the inventory item being printed while creation
of the inventory item.
MENU OPTION: CBP
5.14.11 INQUIRE ACCOUNT NUMBER FOR A CHEQUE
By specifying a cheque number, the account to which the particular cheque leaf is issued can be
inquired by executing the menu option HINQACHQ.
MENU OPTION:
HINQACHQ
5.14.12 CUSTOMER ACCOUNT LEDGER PRINT
The ledger print of a range of accounts can be got by executing the menu option HACLPCA.
MENU OPTION: HACLPCA

5.14.13 CUSTOMER INTEREST REPORT
A customer wise interest report can be generated by executing the menu option HCUIR.
MENU OPTION: HCUIR
5.14.14 CUSTOMER MASTER PRINT
Execution of the menu option HCUMP generates a print out of all customer master information.
The screen details are as shown below.
MENU OPTION: HCUMP

5.14.15 INQUIRIES ON CUSTOMER ACCOUNTS::
The following menu options are used for making inquiries on customer accounts.
HCUSB inquire on savings accounts of customer
HCUCA inquire on current accounts of customer
HCUOD inquire on overdraft accounts of customer
HCUCC inquire on cash credit accounts of customer
HACCDET inquire on general details of an account
HCUDET inquire on general details of a customer
HCUMAT inquire on forthcoming maturities
HCUPSD inquire on portfolio details of a customer
HLINKACI inquire on linked accounts
HCUMI inquire on multi currency accounts
5.14.16 ACCOUNT INTEREST DETAILS INQUIRY
MENU OPTION: HAITINQ
This option allows the user to view interest details of an account like the interest accrued, interest
paid, interest collected, etc.

User can get the interest details like normal, penal, additional by pressing the int break up botton.
MENU OPTION: HINTTM
The HINTTM menu option is used to modify the existing rate of interest set up for an account. The
following are the fields which can be modified through the above menu option.
Interest table code, Customer Preferential Int (Cr) & (Dr), Minimum & Maximum Interest (Cr) &
(Dr), Account preferential Interest (Cr) & (Dr), Interest Pegged Flag, Start Date and End Date

5.14.17 CUSTOMER BALANCES PRINTING
MENU OPTION: HCUSBALP

Using the CUSTBALP menu option user can print the all the account balance‟s under a particular
CIF ID

MENU OPTION : HMCSR
Using the HMCSR menu option we can inquire as well as generate a report on the status of the
multi currency pools of the customer.
INQUIRY
BY opting for the inquiry mode we can get the details of the pools displayed on the
screen as shown below.
REPORT GENERATION
If the print option is selected from the criteria page, all the pools selected as per the
criteria get printed in the form of a report.

5.14.18 ACCOUNT TURNOVER REPORT
MENU OPTION: HATOR
Account turn over report for an account can be printed using the menu option HATOR. The screen
interface is shown below:
5.14.19 CUSTOMER INTEREST PREF AND PEG REPORT
MENU OPTION: HCIPPRPT

This option generates reports of accounts or customers, whose accounts are pegged and due to be
reviewed within a specified period.

5.14.20 PRINTING VOUCHERS AND ADVICES

MENU OPTION: VCHR web menu
The user can print debit and credit vouchers and advices for transactions related to a given set of
accounts or currency. To print voucher the user has to invoke the menu option VCHR. The screen
interface is here below. Based on the criteria mentioned the records will be retrieved by the
system. As shown once the records are displayed the user has the facility to <explode> the
records upon which the Transaction maintenance screen will be displayed by the system. By
default all the records displayed will be in the select mode , the user has the option to deselect
any of the records if required. On pressing <commit> the records will get printed.
MENU OPTION: HADVC
Similarly debit /credit advices can be printed for customer by using the menu option HADVC. The
screen details are as shown below.

There are additional parameters being dumped into the mrt.

Now, the menu will print only those reversed transactions which are not reversed on
BOD if the srgpm parameter is set to Y. If the parameter is set to N/NULL then the menu
will continue to print all the transactions including the reversed ones as before.
MENU OPTION HNRDCSR
This menu is specific for Indian Banks and is useful for generation the monthly report of
Non-resident Accounts and their transactions . This report has to be submitted to RBI
6 RELATED MENU OPTIONS

Given below are the menu options related to Customer Accounts
MENU OPTION DESCRIPTION

HCUMP Customer Master Print
HCUIR Customer Interest Report
HOAAC(SB/CA/CC/OD) Customer A/C Opening

HOAACM(SB/CA/CC/OD) Modification Of Customer A/C Before Opening Is

Verified
HOAACV(SB/CA/CC/OD) Verification Of Customer A/C Opening
HACM Customer A/C Maintenance
HLMMAS Maintain Liquidity Management Structure
HLMGRP Maintain Liquidity Management Group
HLMSWP Liquidity Management Balance Sweep
HLMSWPID Intra Day Liquidity Management Balance Sweep
HLMBRST Reset Liquidity Management Balance in Batch
HLMRST Reset Liquidity Management Balance
HLMRSWP Liquidity Management Balance Reverse Sweep
HLMBOOK Book Interest
HLMACCR Accrue Interest
HLMINT Run Interest
HLMALLOC Allocate Interest
HLMI Inquire on Limit Tree Structure
HLMUPLD Liquidity Management Upload
HAALI A/C Abnormal Limits Inquiry
HAALM A/C Abnormal Limit Maintenance
HATOR A/C Turnover Report
HACLI A/C Ledger Inquiry
HACCBAL Components of Account Balance Inquiry
HALM Account Lien Maintenance
HACMP A/C Master Print
HACS A/C Selection
HACTI A/C Turnover Inquiry
HCAAC Close An Account
HCHBM Cheque Book Maintenance
HCHBIR Cheque Book Issued Register
HCHQUPLD Cheque Book Upload
CBP Cheque Book Printing (Range of Accounts)
HCOTA Charge off of Transaction Accounts
HUCS Update Cheque Status
HUPLOAD Customer / A/C Master Upload
HACLPCA Customer A/C Ledger Print
HAITINQ Inquire AIT table For A Given A/C Number
HINQACHQ Inquire A/C Number For A Given Cheque
HICHB Issue Cheque Book
HICHB Issue Cheque Book – Verification
HJHOLDER List Joint Holders Of An A/C
HPBP Passbook Printing
HPSP Pass sheet Printing
HADVC Print Dr/Cr. Advice To Customer
VCHR Print Dr/Cr. Voucher
HABMR Report Of A/Cs Below Minimum Balance
HSPP Stop Payment Processing
HSPPAU Stop Payment Processing – Verification
HSPRG Stop Payment Register Print
HSEL Super ceding Expired Limits
HTARACO Recovery after charge off of Transaction accounts
HXFCHBAC Transfer Of Cheques Between Two A/C‟s Of The Same
XFCHACAU Transfer
CustomerOf Cheques Between Two A/Cs Of The Same
Customer – Verification
HCUSBALP Customer Balance Printing
HCIPPRPT Customer Interest Pref And Peg Report

HCCA Change cust_id for an account

CBP Cheque Book Printing For A Range Of Accounts
HCAMC Change Account Manager Of Customer
HINTTM Interest Table Maintenance
HAFSM Account Freeze Status Maintenance
HCBM Customer Becoming Major
HSWEEPS Pool of fund maintenance
HUCS Update cheque status
HACXFRSC Transfer of accounts Between Schemes
HACXFSOL Transfer of Accounts Between SOL
HTACHOFI Inquiry on charge off & non accrual of transaction
HCUPSD Portfolio statement of customer
a/ca/a/csaccounts
HCUSB Savings accounts of customer
HCUCA Current accounts of customer
HCUOD OD accounts of customer
HCUSWP Sweep details of customer
HNRDCSR Non resident deposit comprehensive single report
SRCDR Sweeps Regularisation Charges Details Report
HFEPM Freeze Exception parameter Maintenance
7 RELATED TABLES
Table Abbr Table Description
AAS Account Authorised Signatories Table
A
ANT Account Nomination Table
AST Account Passbook Table
ATO Account Turnover Table
CAM CCOD Account Master Table
CBT Cheque Book Table
CMC Customer Master Currency Table
CMG Customer Master General
CMT Customer Minor Table
CPT Customer Person Table
CRT Cheque Refused Table
GAC General Account Classification Table
GAM General Account Master Table
NCT NRE Customer Table
OSP OD Scheme Parameter Table
PCR Paid Cheque Return Table
SMT SBCA Master Table
SPT Stop Payment Table
SSP SBCA Scheme Parameter Table
PFT Pool of funds table
PF0 Pool of funds modification table
PAR Pool account relation table
8 BATCH JOBS
The batch jobs that are related are
 babx4006 1 BATCH Update Account Dormancy Status
 bafe3027 1 FORM Cheque Book Report
 bafe3029 1 FORM Stop Payment Report

 bafe3032 1 FORM Ledger Folio Charges Calculation
 bafe3032 2 FORM Minimum Bal Penal Charges Calculation
 bafe3042 1 FORM Customer Master Register Print
 bafe3044 1 FORM Account Master Print
 bafe3055 1 FORM Pass Sheet Print
 bafe3057 1 FORM Resume Of Accounts
 bafe3066 1 FORM Accounts Below Minimum Balance
 bafe3211 1 FORM Customer Account Ledger Print
 baor5020 1 BATCH Accounts Opened During the Day
 baor5021 1 BATCH Accounts Closed During the Day
 icfe3002 1 FORM Accrual Of Interest For Customer A/cs
9 UPLOAD OPTIONS
The upload related options are
 HUPLOAD
 HUPLOADB
 HCHQUPLD
 HUPLSPT – stop payment upload
 HUPLMISC – Upload of MIS codes – ACM-(V) to GAC table.
 HLMUPLD - Liquidity management upload
10 MRT / MRR / SAMPLE REPORTS

The mrts are used for various report generation like Pass sheet print, pass book print, stop
payment register etc. The report structure is user defined and mrts are written to suit the bank‟s
specific requirements. The mri which provide the inputs to the various report generation are as
under:
REPORT mri
Customer Master Print - HCUMP Cump.mri
Account master print - HACMP Acctmast.mri
A/c Turnover Report Ator.mri
Pass sheet printing Psp.mri
Stop Payment Register Print Sprg.mri

Customer becoming major report-CBM Minor.mri
11 SCRIPTS
jthldrlmt.scr - To decide on the number of joint holders allowed to an account
jthldramtsum.scr – To decide whether currency-wise break up of total of debits and credits to

the account is required.
bafe3019PreLoad.scr - To restrict Account opening verfication to the SOL which has initiated
the account opening.
bafe0077PreLoad.scr - To restrict the verification of Account modification to the SOL which has
initiated the account modification.
Two sample scripts generate IBAN.sscr and validateIBAN,sscr are provided to generate and
validate the IBAN number respectively.
However, modifications made to the account using INTTM/ACLHM/AALM cannot be restricted to

the initiating SOL which has initiated these processes and can be authorised by users of any SOL.
12 FLASHBACK
To summarise what was discussed in this document: to open a customer account a CIF ID must be
created initially for the customer. All the customer details are captured and stored as a part of
Customer master only. The scheme type for saving, current, overdraft and cash credit are SBA,
CAA, ODA and CCA respectively.
The system validates the NRE status and Staff status of a customer during account opening.
Cheque books can be issued to all these types of accounts. Issue of cheque book needs
verification. Cheques can be stopped, cautioned and destroyed. Once a cheque is destroyed and
verified it cannot be reverted to any other status.
Customer accounts can have pass books or pass sheets or both. It is possible to print pass-book
and pass sheet and also keep track of last print date in the system itself.
Before the closure of an account is initiated, interest calculation must be up to date the account
balance must be zero. It is possible to zeroize the balance of the account during HCAAC process
itself.

QUIZ
Sl. Question True False

No
01. CIF Ids can be assigned manually also
02. There is a provision in the system to attach any prefix to

the CIF id.
03. Customer can open accounts without CIF id.
04. Customer name cannot be modified at account level
05. Many customers with different CIF Ids can have a

common account
06. Transactions are created and posted on the basis of CIF

id only and not for accounts
07. General account details are available in the table called

GAM.
08. There is no provision to capture details of a customer

who is a minor
09. After opening the account the CIF id can be created.
10. Freezing of an account refers to in Finacle ™ as closing

all accounts of the customers
11. Account frozen status will not allow transactions for all
the accounts of the customer.
12. A single or a series of Cheques can be stopped.
13. Provision is available in the system to warn while

passing a transaction with stop payment on a cheque.
System will generate an exception if set.
14. TOD's can be created in advance for an account.
15. Either Pass Books or Pass sheets can only be issued to

customer accounts and not both.
16. Interest needs to be computed and input to the system.
17. Cheques can be marked as caution and is equivalent to

Stopping only.
quiz Page 1
18. AAS is the table, which contains authorised signatories

of an account.
19. An account can have different CIF ids but a CIF id

cannot have different accounts.
20. Nomination can be accepted for SB accounts only

if the minimum balance is above USD 1000.
21 It is not possible to know whether the account is closed

within a year of opening from the system.
22 Sanction limit and Drawing power cannot be maintained

by the user.
23. Signatures can captured and stored in the system for an

account and can be retrieved whenever required.
24. Permitted debits and Credits for an NRE/NRO type of

accounts may be controlled using Tran report codes.
25. System will calculate the minimum balance every day

for SB accounts and stores it in the system.
26. Available amount should always be equal to Account

balance – Shadow balance only.
27. There is no provision in the system to view the

components of available amount.
28. GAM is the table, which contains the transactions

history.
29. Accounts can be inquired based on account

open dates, GL subheads and CIF Id.
30. Minor customers cannot open accounts in the system.
31 A customer cannot be a minor as well as a staff.
32 A cheque once stopped cannot be reused.
33 Accounts can be transferred from one CIF id to another.
34 If a saving account does not maintain minimum balance,

then it is possible to collect charges for the same
automatically.
35 Folio charges can be collected for customer accounts.
36 Customer accounts can be frozen either for debit or
quiz Page 2
credit only.
37 Once a cheque book issue process is authorized the

status of the cheque leaves linked to the account will be
unused only.
quiz Page 3

Customer Accounts - Unlocked

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Customer Accounts - Unlocked

Uploaded by

Copyright:

Available Formats

ADMINISTRATOR TRAINING MANUAL

Document revision list

Ver.Rev Date Author Description

© 2009 Infosys Technologies Limited, Bangalore, India

All rights reserved by Infosys Technologies Limited,

Infosys believes that the information in this publication is accurate as

PROCESSING LOGIC: ............................................................................................................................ 93

Customer Accounts Ver Rev 1.08 Page 2

5.13.2 PURGING OF CUSTOMER DATA ............................................................................................. 154

Customer Accounts Ver Rev 1.08 Page 3

1.1 SALIENT FEATURES

 Customer accounts can be opened in any currency. Multicurrency accounts supported.

 Accounts can be marked as Inactive, Dormant. Necessary charges can be collected.

Customer Accounts Ver Rev 1.08 Page 4

 Interest accrual, booking and payment/collection based on Local or English calendar

 Various charges can be collected for different operations/events on an account.

 Nomination facility is available for customer accounts.

 Multiple sanction limits can be created for an account

 Statement of accounts can be transmitted via SWIFT

 Freezing of operations in the account (Debit/Credit or Both)

 Combined customer statement and E-mailing

 Sweep facility is available for the customer accounts/multicurrency sweeps also

 ATM facility is enabled for the operative accounts.

 Lien marking is allowed.

 Transfer of accounts between GL subheads

 Transfer of accounts between scheme codes

 Account turnover details for a specified period

 Limit level interest for an account

 Document details maintenance

 Automatic disabling of expired limits

 Automatic TOD creation

 Creation of Standing instructions

 Maintenance of customer account status (Active, Inactive and Dormant)

 Stop payment advice

 Collection of service tax on charges collected

 Collection of charges on sweep operations

 Opening of Customer accounts and verification of account opening

 Opening of multicurrency accounts and verification of account opening

 Enabling/Disabling Cash, clearing and transfer transactions in accounts

 Maintenance of Customer Accounts/multicurrency accounts

 Concept of Account manager

 Marking an account as Inactive or Dormant.

 Lien marking on accounts

 Sweep In and Sweep Out facility.

 Customer account closing

 Marking of accounts as Past Due

 Charge off of accounts

 Recovery after charge off

Customer Accounts Ver Rev 1.08 Page 6

3.1 PROCESS DIAGRAM

Amount Slab Code Maintenance

(For TDS calculation)

Customer Title Code HBKTM

Bank Code Maintenance

Customer Constitution Code

Customer Introducer Stat Code HSCFM

City Code System generated cust Id , OR flag

State Code to assign the cust id by the user.

Country Code Community Code CUST ID Prefix

Cust. Asset Main Classification

Cust Asset Sub classification CIF

Customer Rating Code Customer Information File

Charge Level Code