All in One Account

TEMENOS T24
All in One Account
User Guide
Information in this document is subject to change without notice.
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

All in One Account
Table of Contents
Table of Contents .................................................................................................................................... 2
Introduction .............................................................................................................................................. 5
Overview.................................................................................................................................................. 5
Setup ....................................................................................................................................................... 5
General Setup ...................................................................................................................................... 5
Architecture/Design ................................................................................................................................. 6
AZ Products ......................................................................................................................................... 6
Defining parameters............................................................................................................................. 6
Debit Interest Rates ............................................................................................................................. 7
Draw down Amounts ............................................................................................................................ 8
Interest-Only Repayment Periods........................................................................................................ 9
Penalty Interest .................................................................................................................................... 9
Posting Restriction ............................................................................................................................. 12
AZ.ACCOUNT and AZ.PRODUCT.PARAMETER workflow ............................................................. 12
Default Loan Inputs ........................................................................................................................ 13
Validation of Loan Inputs ................................................................................................................ 13
Default Schedule Inputs ................................................................................................................. 13
Validation of Schedule Inputs ......................................................................................................... 14
Summary of workflow ..................................................................................................................... 14
Amending Product Parameter Records ......................................................................................... 14
Daily compounding of Interest in Call Deposits ............................................................................. 14
Periodic Charges – AZ Account......................................................................................................... 15
Capitalisation rules – Partial Withdrawal / Pre-closure ...................................................................... 17
Capitalisation rules – multi deposits .................................................................................................. 21
AZ Product Start Date End Date ........................................................................................................ 26
Essences of product start and end date......................................................................................... 28
Early Closure Penalty using routine................................................................................................... 30
Grace period for reckoning default .................................................................................................... 35
Bonus on Interest Earned on Savings ............................................................................................... 38
AZ.Reversal ....................................................................................................................................... 41
PD Link to AZ ..................................................................................................................................... 41
AZ.SETTLEMENT.PRIORITY ........................................................................................................... 42
Deal/Transaction Processing ................................................................................................................ 44
Customer and Limit for AZ ................................................................................................................. 44
Defining the AZ Loan (AZ.ACCOUNT) .............................................................................................. 44
TEMENOS T24 User Guide Page 2 of 189

All in One Account
Account Opening procedure .............................................................................................................. 45

Defining Nominated and Repayment accounts ................................................................................. 45
Loan Principal and Drawdown options .............................................................................................. 46
Full Drawdown ................................................................................................................................... 46
Full Drawdown – without a nominated account ............................................................................. 47
Partial Drawdown ............................................................................................................................... 47
First and Subsequent Partial Drawdown ........................................................................................ 48
Final Partial Drawdown .................................................................................................................. 48
Residual on Principal...................................................................................................................... 48
Defining Repayment types ................................................................................................................. 49
Bullet Repayments ......................................................................................................................... 50
Multiple Repayments (Loan Schedules) ........................................................................................ 50
Defining Interest Only Periods ....................................................................................................... 53
Defining Loan Schedules – Schedule Inputs ................................................................................. 54
Drawdown Schedule ...................................................................................................................... 55
Repayment Schedule – Annuity ..................................................................................................... 56
Repayment Schedule – Principal ................................................................................................... 57
Repayment Schedules – Interest ................................................................................................... 57
Rebuilding schedules after an online repayment of annuity loan .................................................. 60
Defining Variable and Fixed rate of interest ................................................................................... 60
Schedules link to Limit and ADI ..................................................................................................... 61
Reschedule Process and Term Priority.......................................................................................... 62
Loan Repayment Schedule History................................................................................................ 62
Current Date Principal increase in Annuity repayment type loans ................................................. 64
When a user defines a repayment amount which is less than the interest repayment amount..... 64
Loan Account Operations ............................................................................................................... 64
Redraw Process ............................................................................................................................. 65
Arrears – Penalty Process ............................................................................................................. 65
Loan Account Closure .................................................................................................................... 65
Minimum Maturity Date .................................................................................................................. 67
SINGLE LIMIT – MULTIPLE LOANS................................................................................................. 68
User Definable Annuity Amounts ................................................................................................... 73
AZ.OVERDUES.............................................................................................................................. 77
Interest Received In Advance (IRA) ............................................................................................... 80
Settlement Priority .......................................................................................................................... 84
Settlement priority rules.................................................................................................................. 86
Suspension of Interest on AZ loans when PD turns NAB ............................................................ 103

All in One Account
Back Dated Rate Change ............................................................................................................ 105

Back Dated Principal Repayment ................................................................................................ 113
Deposits ........................................................................................................................................... 120
Define Product Parameters (AZ.PRODUCT.PARAMETER) ....................................................... 120
Defining parameters ..................................................................................................................... 120
Maturity Process........................................................................................................................... 121
Early Redemption ......................................................................................................................... 122
Late Payment Fee ........................................................................................................................ 122
Fixed Floating Deposit Type ........................................................................................................ 123
Introduction of “R” Schedules for Deposits .................................................................................. 127
Changing the APP code during the life of an AZ.ACCOUNT FD. ................................................ 127
Multi Deposits .................................................................................................................................. 127
Multi Fixed deposits...................................................................................................................... 127
Multi –Savings Plan ...................................................................................................................... 146
Sub Account (AZ.ACCOUNT) Creation – through Clearing Credits ............................................ 156
Credit Card ....................................................................................................................................... 162
Flow to Credit Card ...................................................................................................................... 163
Card.Management........................................................................................................................ 164
Sub- ACCOUNT in AZ.................................................................................................................. 165
Credit Card TXN.CODES ............................................................................................................. 174
Drawdown Procedure ................................................................................................................... 181
Repayment Procedure ................................................................................................................. 188

All in One Account
Introduction
Overview
The All-in-One module (AZ) provides the basic functionality of loan and deposit contracts within an
account based environment. The account-based environment provides the facility to have loans and
deposits with Cheque Card and complex charge functionality.
The module is linked to AZ.PRODUCT.PARAMETER application which allows you to define

different loan and deposit products that will govern the input defaults and validations at the account
level.
Schedules are initiated and maintained in the loan/deposit account, which provides the flexibility to
customize it to the individual customer/account.
Setup
General Setup
The AZ.PRODUCT.PARAMETER (APP) is the first component that needs to be set up. The
general characteristics of the loan / deposit product are defined here. Most of these are defaulted into
the AZ.ACCOUNT (AZA) at the time of creating it, where they can be modified for a specific
customer.
Based on the set up in APP the following components may have to be set up as well,
AC.AUTO.ACCOUNT must be set up if MULTI is set to ‘Y’ in APP.
AZ.SETTLEMENT.PRIORITY might have to be set up for a loan product if ACCT.SYNC is set to ‘Y’
in APP.
The following is the general workflow:

Create a new CUSTOMER.
In case of a loan product create a limit facility for that customer in LIMIT.
Create a new ACCOUNT.
Create an AZ.ACCOUNT.
In case of a loan product attach the limit to the account.
Define the schedules if required in the AZA.
AZ.SCHEDULES (AZS) will show the schedules that are defined on various dates.

All in One Account
The schedules in AZS are built based on the definition of parameters in APP / AZA at that point in time.
If any of these, in AZA, change in due course it will be rebuilt. There are some instances where it is
not, e.g., when the charge / commission definitions are changed after attaching them to the AZA the
amount shown as the ‘C’ schedule is not rebuilt and might vary at the time of schedule processing. If
APPLY.PENALTY is set to ‘Y’ in APP then the ‘I’ schedule amount might vary at the time of
capitalisation due to application of penalty interest.
Once the AZA is created for a loan then ACCOUNT.DEBIT.INT and LIMIT are updated. If a
deposit is created then ACCOUNT.CREDIT.INT is updated. In either case ACCOUNT.DATE will also
be updated.
Architecture/Design
Define Product Parameters (AZ.PRODUCT.PARAMETER)
The product parameters are defined in the AZ.PRODUCT.PARAMETER application. This
application allows for the input of product characteristics that are common to a group of loans or
deposits.
A product parameter record is required in order to use AZ.ACCOUNT.
AZ Products
There are three basic loan products available in this module, viz. ANNUITY, LINEAR and NON-
REDEMPTION. The loan type is defined in the REPAYMENT.TYPE field. For a description of these loan
products refer to the User Guide on MORTGAGES.
A fourth REPAYMENT.TYPE option, ‘OTHERS’, is available. This repayment type does not adhere to
the repayment rules of the other three products and enables you to define a loan with irregular
repayments.
The fifth REPAYMENT.TYPE option is ‘CREDIT-CARD’. This type offers many features that are
similar to a loan issued using credit cards. This does not offer all the features of a credit card.
There are two deposit products available, viz. SAVINGS-PLAN and FIXED. In FIXED the deposit
amount is accepted in a fixed lump sum and repaid as fixed amounts either with interest accumulated
or not. In SAVINGS-PLAN the deposit amount is accepted in a periodic basis and the principal is
increased in a recurring manner till the end of a fixed term.
Defining parameters
Each product may be allocated a specific category within the allowed range.

All in One Account
AZ.PRODUCT.PARAMETER
The standard T24 interest basis options are available and AZ allows for the interest basis ‘G”
(366/364) which provides more accurate payments for weekly and fortnightly repayments. If the
Interest Basis is left open, then for accounts opened under this product the interest basis relating to
the currency of the account will be defaulted.
Debit Interest Rates

The user is able to define default rates for a particular product. These rates will be defaulted to the
loan during input of AZ.ACCOUNT.
The fields allow for definition of Variable and Fixed rates. The percentage of the balance to be used
for variable rate interest calculation is input in the field RATE.PERCENT. The difference between this
value and 100% is taken to be the percentage of the balance to be used for fixed rate interest
calculation, e.g. a value of 70 in this field, means that 70% of the balance will be used to calculate
interest at the variable interest rate, and 30% of the balance will be used to calculate interest at the
fixed interest rate.

All in One Account
The fixed interest rate is input in the field INT.FIXED.RATE.
The variable interest rate is defined in terms of a RATE.KEY that is set up in BASIC.RATE.TEXT and
BASIC.INTEREST, e.g. the selection of 1-Base Rate, for a system with USD local currency, will use
the ‘1USDyyyymmdd’ rate in BASIC.INTEREST. Over and above the rate identified by the rate key,
the user may then increase or decrease this ‘base rate’ by inputting a RATE.SPREAD and a
RATE.OPERAND. The rate spread is the amount by which the user wishes to change the key rate, and
the rate operand determines the manner in which the user wishes to either increase or decrease the
key rate.
EXAMPLE FOR COMBINED INTEREST
BASIC.RATE.TEXT @ID 1
DESCRIPTION Base Rate
BASIC.INTEREST @ID 1USD20001120

INTEREST.RATE 4.5
AZ.PRODUCT.PARAMETER @ID 1
RATE.KEY 1 Base Rate
RATE.SPREAD 2.5
RATE.OPERAND ADD
RATE.PERCENT 70
INT.FIXED.RATE 10
For the above loan product a variable interest rate of 7% (4.5 + 2.5) will be applied to 70% of the
balance and a fixed interest rate of 10% percent will be applied to 30% of the balance. This is an
effective rate of 7.90% ((7*70%)+(10*30%)).
Draw down Amounts

Within the product profile the rules governing the disbursement of funds may be set. The borrower
may receive the loan funds either in one full draw down amount or in multiple partial drawdown
amounts. If the funds are disbursed as partial draw down amounts, the interim repayments before the
final draw down amount may be ‘Interest’ only (i.e. only the interest portion of the loan is repaid, no
principal portion), or “No Interest” (i.e. no repayment is required until the final draw down amount).
The DRAWDOWN.TYPE selected defines the rule in AZ.ACCOUNT, e.g. if DRAWDOWN.TYPE is ‘1 Full
Draw down’, then in AZ.ACCOUNT the user will only be permitted to disburse the funds in one full
draw down amount.

All in One Account
Interest-Only Repayment Periods

The field INT.ONLY allows the user to restrict the option of Interest-Only repayment periods during the
term of the loan. If the value of this field is “N”, no Interest-Only periods may be applied in the loan
account. If the value is “Y”, Interest-Only periods are optional in the loan account.
The field MAX.INSTL.INT.ONLY is only input if the value in INT.ONLY is “Y”. This value is the total
period of time that the interest only repayment could be defined for a loan during the lifetime of a loan
account.
Penalty Interest
Penalty interest is the debit interest that is calculated on the value identified in the field PENALTY.ON,
e.g. “1-Arrears” balance, of a loan account.
The user is able to flag whether or not penalty interest is to be applied for specific products. If the field
APPLY.PENALTY is set to ‘N”, all loan accounts of this product will not have automatic calculation of
penalty interest once the loan account is deemed to be in arrears.
The penalty interest rate is the result of taking the effective debit interest rate and applying a margin in
terms of the operand instruction.

All in One Account
EXAMPLE

INTEREST.RATE 4.5
RATE.SPREAD 2.5
RATE.OPERAND ADD
RATE.PERCENT 70
INT.FIXED.RATE 10

All in One Account
APPLY.PENALTY Y
PENAL.OPERAND ADD
PENAL.MARGIN 5
For the above loan product a variable interest rate of 7% (4.5 + 2.5) and the fixed interest rate of 10%
percent determine an effective rate of 7.90% ((7*70%)+(10*30%)).
The penalty interest rate is thus the effective rate of 7.90% added to the penalty margin of 5, resulting
in a penalty rate of 12.90%. Thus debit interest will be calculated at 7.90% on the specified loan
account balance and penalty interest of 12.90% will be calculated on the arrears balance. The penalty
rate is calculated by the system and defaulted to the no input field, PENAL.RATE. (Please Refer
Figure 2). This penal rate defined in a Product Parameter is defaulted to the AZ accounts opened
under that product. However, at account level it can be modified.
The user is able to define a number of days grace period, during which the borrower may make a late
repayment, after due date, and during which the loan account will not be deemed to be in arrears.
The number of days grace is entered in the field GRACE.PERIOD. This field provides information for
the activation of two processes, viz. Penalty Interest and Arrears Management activation.
Grace Period & Penalty-Interest: If no repayment is received on the due date, the system will wait the
number of days defined in the grace period, before it accrues penalty interest. If the repayment is
made during the grace period no penalty interest will be accrued. If the repayment is not made,
interest will be backdated to the due date and accrued for each day during the grace period. Penalty
interest will be accrued each day thereon, while the account is in arrears.
Grace Period & Arrears Management: Any local Arrears Management application must be set up to
check the grace period before it initiates arrears processes, e.g. spooling letters of demand, raising
arrears charges etc. Where relevant, the arrears process should be set up to backdate to the due
date, e.g. ageing of arrears.
EXAMPLE

INTEREST.RATE 4.5

All in One Account
RATE.SPREAD 2.5
RATE.OPERAND ADD
RATE.PERCENT 70
INT.FIXED.RATE 10
APPLY.PENALTY Y
GRACE.PERIOD 7
PENAL.OPERAND ADD
PENAL.MARGIN 5
PENAL.RATE 12.90
PENALTY.ON 1 Arrears
If an AZ.ACCOUNT loan is set up using the above loan product with the following conditions being in
effect:
• Repayment due date 31 MAR 2001

• Repayment amount USD5000.00
• Bank Date 7 APR 2001
• Total Arrears amount USD5000.00
• Interest Basis A 360/360
The EOD process on the 7th April 2001 will accrue interest for each day from the 31st of March, viz.
USD5000*12.90%*1/360 = USD 1.79 per day.
Posting Restriction
Posting restrictions can be used in All in One Product, for restricting certain features, for a particular
product. For example, accounts opened under a product that has a posting restriction on debit
transaction, will not have the facility of Redraw.
AZ.ACCOUNT and AZ.PRODUCT.PARAMETER workflow

AZ.PRODUCT.PARAMETER contains control and default value parameters.
AZ.ACCOUNT fields belong to two logical groups, viz. Loan Inputs and Schedule Inputs.

All in One Account
When opening a new AZ.ACCOUNT the first field to be input is the ALL.IN.ONE.PRODUCT value.
This is the @ID of an AZ.PRODUCT.PARAMETER record. The system accesses the relevant
AZ.PRODUCT.PARAMETER record.
Default Loan Inputs
Certain AZ.ACCOUNT fields will be immediately populated with the values defined in the
AZ.PRODUCT.PARAMETER record, e.g. PENAL.RATE. Other fields will only be populated with
default values after input of certain values, e.g. selection of “Y” in SCHEDULES results in the default
population of the fields REPAYMENT.TYPE, INT.ONLY and MAX.INSTL.INT.ONLY.
The values of these fields may be overwritten with new values at AZ.ACCOUNT level, thus providing
for individual attributes for each loan, if required.
Validation of Loan Inputs

Other fields will not be populated with default values, but the values input will be validated against
control values on the AZ.PRODUCT.PARAMETER record, e.g. the value input in PRINCIPAL will
be validated against the AZ.PRODUCT.PARAMETER values in MINIMUM.AMOUNT and
MAXIMUM.AMOUNT.
Validation occurs either as field value restriction or override notification.
Default Schedule Inputs
When entering Schedule Inputs on AZ.ACCOUNT, if an “R” type schedule is entered in

TYPE.OF.SCHDLE, the interest rate values will be defaulted from the opened
AZ.PRODUCT.PARAMETER record, viz. fields RATE.SCH.KEY, RATE.SCH.SPREAD,
RATE.SCH.OPERND, RATE.SCH.PERCNT and SCH.FIXED.RATE.
The values of these fields may be overwritten with new values at AZ.ACCOUNT level, thus providing
for individual attributes for each loan schedule, if required.
For certain REPAYMENT.TYPE in AZ.ACCOUNT at the inception of a new loan account, the user is
not required to input an “R” schedule if the default AZ.PRODUCT.PARAMETER record values are
to be used. In this case the default values will be defaulted when the system automatically generates
an “R” schedule in AZ.SCHEDULES.

All in One Account
Validation of Schedule Inputs
For Schedule Inputs no field value restriction applies in terms of the AZ.PRODUCT.PARAMETER
values. Override notification validation of Schedule Inputs does take place in terms of
AZ.PRODUCT.PARAMETER values.
Summary of workflow
AZ.PRODUCT.PARAMETER is accessed for:
Default values at the inception of a new AZ.ACCOUNT loan or when an “R” schedule is generated
for the loan.
Validation at the inception of a new AZ.ACCOUNT loan or when a loan is amended.
Amending Product Parameter Records
Once loans have been initiated against a particular AZ.PRODUCT.PARAMETER record, care
should be taken in respect of amending the record. Changing the values in certain of the fields may
result in loans being updated during the term of the loan, with irregular or contradictory default values
for “R” type Schedule Inputs, or cause conflicting validations in respect of Loan Inputs.
There may be cases where a change in the values is desirable and therefore each product record and
field therein will need to be evaluated on its individual merits.
Daily compounding of Interest in Call Deposits
Compounding of interest in AZ.ACCOUNT Deposits is now possible.
The field COMPOUND.TYPE in AZ.PRODUCT.PARAMETER level is used to determine whether

compounding interest functionality is required or not. This field is the frequency field and will accept
frequencies DAILY, WEEKLY and MONTHLY.

All in One Account
The field COMPOUND.TYPE also found in AZ.ACCOUNT level, the value in this field will get
defaulted from AZ.PRODUCT.PARAMETER. The system will allow the user to change the
defaulted value in AZ level before authorising the contract.
Periodic Charges – AZ Account

AZ module handles both deposit and loan features based on account application. This charge can be
collected as a flat amount or on a percentage based on principal, interest, instalment or annuity. The
charge collection on AZ accounts can be one time or schedule based.
The charge codes can be defined at the AZ.PRODUCT.PARAMETER, AZ.ACCOUNT or at the sub
account level. The charge code accepts valid FT.CHARGE.TYPE or FT.COMMISSION.TYPE codes.
In order to collect one time charges, the charge code has to be defined with a charge type or a
commission type code. The charge liquidation account has to be defined with a valid account number
other than PL account, AZ account, Cash account. (internal accounts can also be defined as charge
liquidation account).
ONE TIME CHARGE COLLECTION
In the same way, for the collection of charges on a periodical basis along with interest, instalment,
principal or Annuity a C type schedule can be defined. Whenever a C schedule is defined, the charge
and the charge code appears on the frequency dates in the schedules.

All in One Account
SCHEDULES - DEPICTING CHARGE
On committing the AZ.ACCOUNT, the above fields is refreshed every time and accepts fresh input
every time. Tax codes can be defined for the interest earned in AZ.ACCOUNT. In the similar way,
tax codes can also be defined for the charges to be collected. If the tax code is defined for both the
AZ ACCOUNT and FT.CHARGE.TYPE or FT.COMMISSION.TYPE used in C schedule or BC
schedule, the tax for charges would be populated in the field TAX.AMOUNT & TAX.AMT.LCY and the
tax on interest earned on deposits would be populated in the field TOT.TAX in AZ.SCHEDULES.
For instance, both in FT.CHARGE.TYPE and AZ.ACCOUNT, the tax code defined contains a rate of
1%. If the charge works out to 50 then tax on charge 0.50 (being 50 x 1%) would be populated in the
fields TAX.AMOUNT & TAX.AMT.LCY and if the interest on deposit works out to 6.67, the tax on it
0.07 (being 6.67 x 1%) would be populated in TOT.TAX

All in One Account
Represents tax
on charge.
Represents tax
on interest.
AZ.SCHEDULES - TAX ON CHARGE & INTEREST
Generally is not advisable to define the charge liq account as the AZ.ACCOUNT in any application.
In AZ SCHEDULES the TYPE.C amount shown in only notional it can vary at the actual time of
collection of charges.
Capitalisation rules – Partial Withdrawal / Pre-closure
Based on their conventions / requirement, banks permit partial withdrawal or pre-closure of deposits
accepted by them. Previously, in the application, AZ.ACCOUNT, on making a partial withdrawal from
the deposit, charges and penal interest were either reduced from the principal amount or from the
withdrawal amount as defined in AZ.PRODUCT.PARAMETER and the total interest payment was
made on the maturity date.
Now, this has been enhanced for the capitalisation and payment of interest online on the partially
withdrawn amount till the date of withdrawal. This is applicable in both cases of either setting up of I
schedule or not. Presently, the defining of CHARGE LIQUIDATION ACCOUNT is made mandatory
when a charge code is defined AZ.PRODUCT.PARAMETER. While making a partial withdrawal the
entries pertaining to charges would be routed through the liquidation account.
Example 1 :

All in One Account
Start date: 01-04-03

Maturity Date: 07-04-03
Interest paid at maturity.
Deposit Amount: 50000
Interest rate: 5.50% (payable at maturity)
Partial withdrawal of 1000 made on 04-04-03.
In this case if the eligible interest for part withdrawal is 2.50%, then,
1) The interest for 1000 for a period 4 days (01-04-03 to 04-04-03) at the rate of 2.50% is to be
calculated and capitalised on 04-04-03 itself.
INT CAPITALISED - PARTIAL WITHDRAWAL

2) The interest accrued at 3% for 1000 for 4 days has to be reversed
3) Charges if any are to be recovered as defined in APP.
4) The remaining principal of 49000 will continue to earn interest at the contracted rate of 5.50%
from 01-04-03
5) So at maturity the interest for 49000 will be paid from 01-04-03 till 07-04-03 (i.e. maturity date) at
5.50%
The field EARLY RED INT in the AZ account populates the penal interest as defined in
AZ.PRODUCT.PARAMETER. In the example defined above, the contract rate is 5.50%, and the
eligible rate is 2.50%. This field denotes the penal interest of 3% (5.50% - 2.50%).
If the field, EARLY RED INT in AZ.ACCOUNT is defined with a rate different from the one defined in
AZ.PRODUCT.PARAMETER, the rate defined in the AZ account will be taken as the penal interest.
In the case of defining INTEREST LIQUIDATION ACCOUNT in AZ.ACCOUNT, all entries pertaining
to interest (in all cases of pre-closure, partial withdrawal or closure on maturity) have to be passed
through this account only. Presently, though the interest liquidation account is defined, the entries are
not routed through the same.

All in One Account
When a partial withdrawal or pre-closure of the deposit is made after capitalisation of interest (on the
execution of N, or IN schedule), if the eligible rate is lesser than the contracted rate, then for the
amount partially withdrawn interest would be recalculated at the eligible rate and the difference
amount would be debited from the nominated account (in case no interest liquidation account is
defined).
In case of pre-closure of deposit, interest for the entire amount till the date of pre-closure would be
recalculated and any excess interest paid would be recovered from the nominated account / interest
liquidation account if defined.
In both the above cases, if only I schedule is defined or if the partial withdrawal is made prior to the
execution of first N schedules, the adjustment would be made through the AZ account itself.
Example 2 :
Start date: 07-04-03
Maturity Date: 22-04-03
Interest payable daily, I schedule defined
Deposit Amount: 15000
Interest rate: 6.9063%
Partial withdrawal of 10000 made on 09-04-03.
In this case the eligible interest for part withdrawal is 4.9063% (i.e., 6.9063-2) then,
1. The interest for 10000 from 7.4.03 to 09.04.03 would be calculated at 4.9063%
[10000 x 4.9063% x 2/360 = 2.73]
Figure 1 ELIGIBLE INT CR
Interest has already been paid for 2 days at 6.9063%.

[10000 x 6.9063% x 2/360 = 3.84]

All in One Account
Hence the differential interest for 10000 @2% would be debited from the nominated account, i.e.
interest actually payable is only 2.73 against an amount of 3.84 already paid. The differential amount
of 1.11 would be recovered from the AZ account if no N schedule is defined or if the partial withdrawal
takes place prior to the date of first N schedule.
REVERSAL - EXCESS INT PAID
In the above case if any accrual entries have been passed after the last capitalisation date, even those
entries would be reversed.
Note: The above functionality is applicable irrespective of whether the interest rate used is a fixed rate,
Basic Interest key, Periodic interest rate key, etc…
For referring to a PERIODIC.INTEREST table for interest in AZ.PRODUCT.PARAMETER

periodic interest key has to be defined in the field PERIODIC RATE KEY and the rate would be
picked based on the values defined in Pi METHOD.
DEFINING PERIODIC INTEREST
As shown in the above figure, PI METHOD can contain values as Interpolate, Next & Previous.

All in One Account
Example 3 :
Periodic Interest Table → 01USD

Interest Rates → 1 Day - 5%, 1 Month - 7%, 3 Months - 9%, etc…
AZ deposit has been opened for a period of 15 days and the AZ.PRODUCT.PARAMETER for the
AZ.ACCOUNT refers to the above table. If PI METHOD is defined as Previous, the interest rate for
the deposit would be 5% and if it is defined as next it would be 7%. If the field contains the value
“Interpolate”, the interest rate would be the interpolation of both previous and next rates.
Now for making a partial withdrawal from the deposit created as explained in Example 3 above, in
AZ.PRODUCT.PARAMETER, even PI TABLE TO USE has to be defined. This field can contain
values as Opening, Current, Lowest & Others. For using the value others, a routine for calculating the
eligible interest has to be attached in the field PRE CLOSE RTN.
As explained in the example above if a deposit is opened for 45 days and an attempt is made for
partially withdrawing the deposit amount after 3 days of opening the deposit, the eligible rate
calculation would be as follows:
a) if the value in pi table to use is current, the interest rate for the applicable period (ie 3 days in
the said case), would be taken from the table for the current date or the latest one.
b) If opening, the interest rate would be taken from the table as on the date of the contract.
c) If lowest, the lower of the above two rates would be taken.
Eligible interest rate = Applicable interest rate – penal margin (as specified in APP / AZ account).
In AZ.ACCOUNT, the field EARLY RED INT would populate the difference between the contracted
rate and the eligible interest rate. (For more details, refer to the user guide on PERIODIC.INTEREST).
The rules for capitalisation of interest online, reversal of accrual interest, if any or adjustment of
interest already paid would be as explained in Examples 1 & 2.
Capitalisation rules – multi deposits

The concept of Partial withdrawal / pre-closure deposits is applicable in the case of multi deposits also.
For the creation of multi deposit the fields MULTI and ACCOUNT.SYNC should be defined as ‘yes’.
AZ.PRODUCT.PARAMETER - MULTI DEPOSIT

All in One Account
Partial withdrawal of the sub account can be done either by specifying the amount in REDEMPTION
AMT in sub account or by defining account.REDEMPTION AMT and SUB AZ ACCT in the main
Whenever a partial withdrawal is made defining the interest to be paid at maturity,
The principal is reduced by the withdrawn amount.
Interest accrued for the withdrawn amount till the date of withdrawal is reversed
ACCRUAL REVERSAL
For the amount withdrawn interest at the eligible rate (contracted rate – penal rate) is capitalised
immediately and credited to the nominated account.
INT CAP - ELIGIBLE INT
In the same way, when a partial withdrawal or pre-closure of a sub account is made after the
execution of I schedule,

All in One Account
a) If on pre-closure or partial withdrawal, the eligible interest is lesser than the contracted rate
and as on the date of partial withdrawal / pre-closure excess interest is paid, the excess would
be debited to the AZ account.
b) If the I schedule is defined as D03, and if the partial withdrawal or pre-closure is made after a
day after the execution of I schedule, not only the excess paid interest would be reversed but
also the accrued interest for the day would be reversed. (Refer Example2)
Example : 4:
AZ deposit has been opened for a period of 20 days with I & N schedule frequency defined as D02, at
a rate of 10% and penal rate of 4%, i.e. the eligible rate would be 6% in case of pre-closure. I & N
schedule have been executed for 6 frequencies. The entries for the cap and the credit of int cap to the
nominated account is as follows:
ENQUIRY – STMT.ENT.BOOK – SHOWING I & N SCH
The account has been pre-closed. The adjustment entry is raised by way of debit to AZ account on
each date of I schedule and then is recovered from the nominated account. In this case, the interest
prior to preclosure works out to 54.79,(100000*2/365*10%). On preclosing the account, the eligible
rate works out to 6% (10% - 4%). The interest is recovered @4% on the respective dates of the
interest amount credited (100000*2/365*4%) which is also the difference between the interest amount
calculated at the contract rate and the eligible rate.

All in One Account
If no ‘N’ schedule is defined, the interest recovery would be as above, except that the same would not
be debited back to nominated account.
ENQUIRY – STMT.ENT.BOOK – AFTER PRE-CLOSURE
Example : 5:
Interest rate – 10%, eligible int.rate – 6%
AZ deposit has been opened for a period of 20 days with I schedule frequency defined as D02, at a
rate of 10% and penal rate of 4%, i.e. the eligible rate would be 6% in case of partial redemption. I
schedule have been executed for 6 frequencies. The entries for the cap to the account is as follows:

All in One Account
ENQ.STMT.ENT.BOOK SHOWING I SCH
A partial withdrawal of USD 20,000 is made on this account. The adjustment entry is raised by way of
debit to AZ account on each date of I schedule for the redempted amount. In this case, the interest
prior to partial redemption works out to 54.79,(100000*2/365*10%). On partial withdrawal of USD
20,000, the eligible rate works out to 6% (10% - 4%). The interest is recovered @4% over the
redempted amount on the respective dates of the interest amount credited (20000*11/365*4%), which
is also the difference between the interest amount calculated at the contract rate and the eligible rate.
If ‘N’ schedule is defined, the interest recovery would be as above, except that the same would be
debited from the nominated account.

All in One Account
ENQUIRY – STMT.ENT.BOOK – AFTER PARTIAL WITHDRAWAL
AZ Product Start Date End Date
AZ.PRODUCT.PARAMETER is the application that allows the user to define the features of an AZ
product either loan or deposit.
Formerly, the AZ product parameter is valid forever and there is no way the opening of accounts under
the product can be restricted after a specified date.
However, business needs may bring to surface such a scenario, for example a product may be
introduced for a lesser interest rate for the festive season alone. In which case AZ product should be
in a position to handle the validations to such seasonal products introduced repeatedly for that specific
period alone
This led to the

introduction of PROD START DATE and PROD END DATE in
AZ.PRODUCT.PARAMETER application.

All in One Account
AZ Product Parameter –with Start and End date

• This indicates that the product will start on 25.09.2003 and will end on 31.12.2003.
• Both the start and end dates when compared to the T24 date can be either back dated or
forward dated.
• The validations are for the VALUE DATE field only. I.e. when an a/c is attached to an AZ
product, of the above kind – then the value date of such AZ a/c can neither be before the
product start date nor it can be after the product end date.
To illustrate:- If the above product parameter i.e. 1000 is attached to the a/c 37559 and
Case –1:-Value date is input as 24.09.2003- which is < than the

product start date.
The system will raise an error “Date must be > or = Product Start date.

All in One Account
ATTACHING AZ a/c 37559 TO AZ PRODUCT 1000
Case-2:- Value date is input as 01.01.2004- which is > than the

product End date -The system will raise an error “Date must be < or =
Product End date
AZ. ACCOUNT – 37559 INPUT
Essences of product start and end date
• Product parameter with start and end date can be defined in advance and the system will start
accepting accounts on or after the start date up to the end date.

All in One Account
• The end date is essential in the sense after the date “NO NEW” accounts will be accepted –
but the accounts input within the start and end dates will continue to exist.
Note: - In case of Multi-deposits there is a differential treatment in respect of Fixed

and Savings plan
Fixed: - In case of Fixed deposits –every sub a/c is a new a/c and any effort to
open a new sub a/c with a value date beyond the product start and end date –
should be blocked by raising an error.
Savings Plan:- In case of Savings plan- for enabling frequent deposits “B”
schedules are defined. Whenever, the “B” schedules are executed a sub a/c is
created which is part of main savings plan. Therefore, in case of savings plan the
creation of sub a/c even if the date of “B” schedules is beyond the product end
date should be permitted. A fresh AZ a/c after the product end date should
however be blocked
• Both the start date and end date of a product can be backdated as well as forward dated.
Even in case both the dates i.e. start and end dates are backdated the validation that
“product end date can’t be less than the start date” is substantiated.
• The opening of an a/c under the product is permitted if
(1) The value date of the a/c is on or after the start date and earlier to the end date.
(2) Suitable error conditions will be stimulated (see screen shots above) both in the case of
value date is EARLIER to the product start date and LATTER than the product end date.
CAUTION: - (1) If the Prod. End. Date field is blank- the

product is valid forever and validations akin if a date is
specified will not happen.
(2) If the product start and end date are left blank, none of the
above validations will happen and the product will be treated as
a normal one- with life forever.
PASS BOOK LAY OUT- for AZ a/cs
The evolving of different passbook layouts also concerns All in One Account (AZ) i.e. to print
passbook in lieu of deposit receipts. The nomenclature for using different layouts in an AZ
environment is explained below
• Set-up a new passbook layout-using TELLER. PASSBOOK application as explained under

teller.
• Input the id of such layout in the AZ.PRODUCT.PARAMETER application as shown below

All in One Account
PASSBOOK LAYOUTDEFINED IN AZ.PRODUCT.PARAMETER
• By verifying the TELLER.PASSBOOK.UPDATE application for the a/c the entries can be
printed for that particular AZ a/c. The account so input can be main a/c only. The entries
pertaining to different sub a/cs for a main a/c is grouped based on MASTER.ACCOUNT field
and printed in the passbook.
• If AZ.PRODUCT.PARAMETER (APP) contains an entry in the field PASSBOOK.ID – then
the a/c so attached to the product parameter must have the passbook field in a/c flagged as
yes.
• TELLER.PASSBOOK.REPRINT application is used to reprint the entries for a particular AZ
main a/c by giving a range of dates.
NON-STOP- PHASE 1
New AZ.ACCOUNT’S and amendments to (LOAN, FIXED DEPOSIT, SAVINGS PLAN) contracts
can be input during COB. No amendment of contracts input prior to COB would be allowed.
Early Closure Penalty using routine

The concept of attaching a routine to the PI key was evolved in AZ. In AZ, the penal rates are
applicable in case of either part or pre closure of a deposit. The penal rate applicable under such
circumstances is defaulted from the AZ.PRODUCT.PARAMETER. However, the penal rate so
defaulted can be altered at the account level.
Altering the penal rate every time a part redemption or pre-closure it time consuming. Hence, a set of
input parameters defining the rate of penalty applicable in different scenarios can be defined and
attached as a routine as shown below.
Step 1: - Create a sub routine and create an id in PGM.FILE as shown below.

All in One Account
PGM FILE RECORD FOR THE INTEREST CALC ROUTINE
Step 2: - Attach the routine in AZ.PRODUCT.PARAMETER application in the field PRE.CLOSE.RTN.
Step 3: - Input at Step 2 is possible only if the AZ.PRODUCT.PARAMETER has a PI key defined and
the PI.TABLE.TO.USE field is input as “Others
ATTACHINGTHE ROUTINE TO THE AZ.PRODUCT.PARAMETER

All in One Account
The field EARLY.RED.MARGIN contains the penalty rate that is applicable in case of part redemption
and pre-closure. To make the penalty rate more dynamic a routine is introduced to overwrite the
penalty rate based on parameters like the no. of days, the deposit was with us etc.
In the above product PI – the PRE.CLOSE.RTN has the following input parameters
IF DAYS LE 1 THEN INTEREST.RATE =3

IF DAYS GT 1 AND DAYS LE 2 THEN INTEREST.RATE=2
IF DAYS GT 2 THEN INTEREST.RATE =1
The input parameters imply, if the deposit has run for less than one day before it is ordered for pre-
close or part redemption then the penalty rate applicable is 3%. For deposit that has run for 2 days
and more than 2days, the rates of penalty are 2% and 1% respectively.
Scenario (1) If the deposit has remained for less than or equal to 1 day- Penalty is 3%
AZ.ACCOUNT WITH PART REDEMPTION OF 15000
• In the above case – part redemption of USD15000 is input.

• The system has populated the penalty rate from the product parameter as 5%
• On committing the EARLY RED INT field rate will be overwritten with the value inscribed in
the routine- as shown below
Note: - this can be viewed by putting the record in INAU

All in One Account
THE EARLY REDEMPTION BEING OVERWRITTEN WITH THE ROUTINE RATE
The ENQUIRY STMT.ENT.BOOK for the nominated/repay a/c clearly indicates that the penalty
charged was 3% as per the input in routine.
Scenario (2) If the deposit has remained for less than or equal to 2 days- Penalty is 2%

All in One Account
The penalty is overwritten with routine value of 2%
PART REDEMTION ON A/C 35418
From the above scenario, it is evident that the system has overwritten the penalty of 5% with 2% (as
input in routine).
Note: - Part redemption can be done using sub a/c directly, inputting in AZ. Main a/c the sub a/c no.
Or using the Teller application. For using teller application – the transactions codes pertaining to part
redemption and pre-closure specified in the AZ.PRODUCT.PARAMETER should be used in the
TELLER.TRANSACTION.
Scenario (3) If the deposit has remained for more than 2 days- Penalty is 1%- further the part
redemption is done using the AZ. Main a/c

All in One Account
Sub a/c No
Note Penalty is
populated as 1%
PART REDEMPTION OF AZ.SUB A/C 35419 USING AZ.MAIN A/C 10138
Note: - Only fixed deposits are permitted. Savings plan is not covered.
Grace period for reckoning default

At present, the concept of Grace period for reckoning penalty calculation in case of Savings plan is not
available.
Depending on the input made in LIAB.TO.PENALTY field the system will automatically calculate the
penalty for defaulted instalments once it crosses the input made in LIAB.TO.PENALTY field. The
calculation of penalty also starts from the day the instalments have become due.
The field GRACE.PERIOD in AZ.PRODUCT.PARAMETER, for loan type contracts, can be input if
the field APPLY.PENALTY is flagged as ‘Yes’ or if the REPAYMENT.TYPE field is ‘Savings plan’. For
fixed deposit type this field is a “No input” field.

All in One Account
AZ. PRODUCT.PARAMETER FOR SAVINGS PLAN TYPE
Field GRACE.PERIOD can take any of the following values

(1) nnC
(2) nnW or
(3) Mont. End
To illustrate: -
If the instalment is due on say 10.3.04 if the GRACE PERIOD field is
(1) 05C – the customer will have the option to pay the instalment on or before 15.03.04 before the
instalment is considered as defaulted. “C” stands for Calendar days.
(2) 02W – the customer will have the option to pay the instalment on or before 12.03.04 (2
working days –not weeks) before the instalment is considered as defaulted.
(3) Month. End- here the customer can pay the instalment before the month end i.e. 31.3.04
failing which the instalment will be termed as defaulted.
(4) The option of Month. End is available for input in case of loans also.
Cross Validations: -

All in One Account
In case of deposits input in Grace. Period is based on the CR.DEP.FEQ field which is trigger for the
generating the instalment frequency i.e. B schedules. Enough logic has been build to raise an error if
the deposit frequency and the Grace days aren’t in tandem. For ex: - the Deposit frequency can’t be
weekly –with grace period flagged as Month. End. Similarly, the grace cannot be 03C when the
deposit frequency is daily.
In CR.DEP.FEQ field the value “w01” indicates week01 and not working days.
Penalty Calculations: -
EARLIER
B schedule date Grace Liab to Bonus Penalty charge Date for
days penalty eligible penalty
10.2.04 –not paid N.A. 1 NO NO 10.2.04$
11.3.04-not paid N.A. 1 NO Yes 11.3.04$
(Already
defaulted
February)
$The penalty
will be
calculated from
“B” schedule
date
Grace days not
applicable and
will be ignored.
After the
present
development
B schedule date Grace Liab to Bonus Penalty charge Date for
days penalty eligible penalty
10.2.04- not paid 2 0 Yes – if bonus Yes- as liab to 12.2.04#- date

on arrears field penalty is “0” of “B” schedule
in APP is plus the Grace
flagged as days.
Yes. If “ “ no
bonus is
payable.
11.3.04- not paid 1 2 * DO * No – as liab to 12.3.04#
penalty is
permitted up to 2
instalments.
#Here the
calculation of

All in One Account
penalty will be
“B” schedule
date + grace i.e.
will start from
12.2.04 and
12.3.04
respectively.
Bonus on Interest Earned on Savings
“Bonus” is an additional amount paid as a reward for paying the instalments regularly in Savings plan
kind of deposits. Presently, the bonus is a fixed amount paid if the schedules and account balance
are same.
The present development aims at providing bonus as a percentage on the amount of interest
accumulated.
Presently, the field BONUS.PREMIUM is input with either a charge or a commission code, which
determines the amount of “Bonus” payable. The field can be input only if the REPAYMENT.TYPE is
Savings plan.
LATE.PAYMENT.FEE field implies the amount of charge that will be levied in case a customer misses
an instalment.
LIAB.TO.PENALTY is another field which determines whether bonus is payable or not. The field
takes a numeric and implies the number of instalments that the customer can miss to avoid the
penalty class. However, any count to the field LIAB TO PENALTY would automatically stop the
payment of bonus to the customer. When the customer crosses the input in liab to penalty field – the
late payment fee is applied.
The proposed functionality aims at (1) An option to pay “Bonus” on principal or interest earned (2)
Even if there is a count on LIAB.TO.PENALTY field still the bonus will be paid based on the flag set
in the field BONUS ON ARREARS. The process flow of the development is as below
AZ.PRODUCT.PARAMETER: -

All in One Account
Fields Permitted inputs Remarks

BONUS.CR A valid credit txn The txn codes are indicative of the type of transaction
code i.e. debit cr that is passed through the AZ.ACCOUNT. When
marker flagged as ACCT. SYNC is yes – these fields are mandatory.
cr.
(1) Principal If the input were “Principal”, the bonus calculation
would be based on the principal amount.
BONUS.ON (2) Interest
If the input were “interest”, the bonus calculation would
(3) “ “
be based on interest paid.
If “ “ then the existing functionality for payment of bonus
is retained.
VALIDATIONS
• The option of “interest” can be input only if the
ACCT.SYNC field is flagged as Yes
Illustration: -

All in One Account
Option (1) Option (2) Option (3) Bonus %
Principal Interest ““ 10%

100000 2000
Option (1)
Means “Bonus” is on principal. The sum accumulated
through sub a/cs is taken and the Bonus as a %age is
calculated and credit to the customer along with
maturity process.
In the present case –100000(principal) 10% bonus on
this i.e. 10000 will be paid to the customer.
Option (2)
The calculation is on Interest – hence the amount of
bonus would be 2000(interest) *10% i.e. 200 will be
credited to the customer along with the proceeds.
Option (3)
“Null” implies the existing functionality of bonus
payment will continue.
This field is to be read with the field “Bonus on

Arrears”. If flagged as Yes – the system will pay
interest even if there is default in payment of instalment
not exceeding the input in LIAB TO PENALTY field.
If “ “ is input in the field BONUS ON ARREARS then any

missed instalment would result in non-payment of
bonus.
Note: - in case FT. commission. Type the minimum
and maximum amount will be the deciding factor
BONUS.ON.ARREARS (1) Yes If flagged as “yes”- even if the customer misses
instalments not exceeding the input in LIAB TO
(2) “ “
PENALTY field the bonus is payable.
If “ “ bonus is not payable even if the customer misses
one single instalment.
Note: - The fields mentioned can be input only for Savings plan type of deposits. No input if it is loan
or Fixed type of repayments.
In case of FT. commission. Type if the arrived bonus amount is less than minimum then minimum is
payable conversely if the amount exceeds the maximum then the bonus amount is restricted to the
maximum amount so entered

All in One Account
AZ.Reversal
For Normal AZ.ACCOUNTS (NON –MULTI type)
Reversal is permitted online and after COB, before processing of schedules (I, N, P etc.). Reversal is
not permitted if part-redemption, repayment has taken place.
For AZ.ACCOUNTS of Multi type (Multi Deposit / Credit Card)

Reversal is permitted at Main AZ.ACCOUNT level only, again, subject to validations as stated for
Normal AZ.ACCOUNTS.
If SUB AZ.ACCOUNT is created through another application, say TT, then reversal through MAIN
AZ.ACCOUNT is not possible online, since it can be reversed through TT itself. After Close of
Business (COB), since the TT record would have moved to HISTORY, reversal through MAIN
AZ.ACCOUNT is possible, subject to above validations.
PD Link to AZ
PD link to AZ is triggered by flagging the field as YES in the AZ.PRODUCT.PARAMETER
application. The concept of PD and how the settlements are made is explained below.
AZ.SCHEDULE –SUB ACCOUNT
The particulars of the above screenshot are:
Amount of Drawdown 150000.00

Rate of interest 8.88%
Billing Close Date 13.11.2002
Repay date 21.11.2002
“CI” schedule- being 296
interest from the date of
[150000*8.88*8/36000]
drawdown until the

All in One Account
repayment date.
“C” schedules –being 500.00
charges to be collected on
REPAY date.
REVOLVING RATIO- 10% -150000*10/100@
applied to generate “CC”
schedule
Minimum Repayment 10000 [If this amount is higher than the amount arrived at after
applying the above %age the system would take the minimum
repayment as the CC schedule amt, automatically] For ex;- in the
above case if Minimum repayment is 20000- 10% 150000 would
be less than this hence CC schedule will be generated for 20000.
[@-If there is more than one drawdown, all the drawdown will be combined and 10% will be
applied to arrive at the CC schedules.]
Now after the bill close –the system generate “CC” schedule for 15000. The Schedule of payments
due from the customer and payable on the repayment date is: -
“C” schedule 500.00

“CI”schedule 296.00
“CC”schedule 15000.00
TOTAL DUE 15796.00
Apart from the set-up the trigger to PD is when a payment is attempted on the account. For example,
on or after the repay date if payment is received, for say 6500, then based on the
AZ.SETTLEMENT.PRIORITY (which is explained separately) the amount will be adjusted towards
“C” for 500.00 and “CI” for 296 and the balance to “CC” schedule. This payment leaves a balance of
9296, which is automatically moved to PD.
AZ.SETTLEMENT.PRIORITY
This application is used to distinguish between charges input during the drawdown in AZ as to which is
part of withdrawal charges and which fall under the Handling fee.
A brief description of how the AZ. SETTLEMENT.PRIORITY works is shown below:
WHENEVER PAYMENT IS RECEIVED

All in One Account
FIRST Appropriation should be made to CHARGES, i.e. Withdrawal Charges then Handling
Charges.
SECOND Appropriation should be made towards PENAL interest.
THIRD Appropriation should be made towards INTEREST due on the principal drawn.
FOURTH Appropriation should be made towards the PRINCIPAL.
In all the above scenarios the appropriation should be on a VERTICAL basis. It means the recovery
should run and not like this for the PD amounts and the current outstanding. However, if
both PD and current outstanding are present then recovery will be FIRST on the PD and then on the
CURRENT outstanding as explained in the appropriation table shown below.
PD
Nature of O/s Principal Interest Charges
Penalty
PD- past due created on 25.10.02 12000.00 850.00 650.00 125.26
PD- past due created on 25.12.02 (4) 8000.00 (3) 650.00 350.00 141.26
Current Month repayment-25.1.03 (6) 14000.00 (5) 755.00 (2) (1)
If the amount received is 24000 then the appropriation of the same will be:
Amount received as repayment Appropriation 24000.00
FIRST adjustment should be toward -125.26 23874.74

Charges -->
-141.26 23733.48
SECOND adjustment should be -650.00 23083.48
towards PD Penalty interest
-350.00 22733.48
THIRD adjustment should be -850.00 21883.48
towards Interest
-650.00 21233.48
FOURTH adjustment should be -12000.00 9233.48
towards the PD principal.
-8000.00 1233.48
Now the remaining amount is -755.00 478.48
adjusted for the current O/s
(Interest is adjusted)
After adjusting -478.48 towards -478.48 0.00
principal the balance principal
will be adjusted in the next
repayment amount.

All in One Account
Deal/Transaction Processing
Customer and Limit for AZ
As for any account or loan contract in T24, a CUSTOMER record needs to be defined.
AZ.ACCOUNT requires that a LIMIT record be defined for the customer against whom the loan is to
be lodged. Standard LIMIT rules apply, so a LIMIT.REFERENCE record will need to be defined
before setting up the customer’s LIMIT record.
The LIMIT record is set up using the format “CUSTOMER.ID”. “LIMIT.REFERENCE.ID”. “Sequence
Number”, e.g. 100138.900.01.
The values of Repayment amount, Frequency and Repayment Date are populated to the respective
fields of the Limit record from the schedule of AZ.ACCOUNT for the purpose of reducing the Limit
on the repayment dates. The system will compare the reduced limit (current Limit) amount with the
Working Balance of the loan account, to arrive at the arrears.
Redraw from the loan account will be permitted up to the Reduced Limit amount and any excess
Redraw will bring an Override message. This provides non-revolving limit functionality.
If a revolving limit is required then the REDUCE.LIMIT field in AZA can be set to ‘N’. In this case the
limit will not be reduced on the scheduled dates. If SINGLE.LIMIT in the ACCOUNT is set to ‘N’,
i.e., more than one AZA shares the same limit, then all the AZA should have the REDUCE.LIMIT set
to be the same.
Defining the AZ Loan (AZ.ACCOUNT)

AZ.ACCOUNT fields belong to two logical groups, viz. Loan Inputs and Schedule Inputs.
Loan Inputs are the parameters that define the basic conditions of the loan contract. The Loan Inputs
are defined at the inception of the loan, with values either defaulted from / or controlled against
AZ.PRODUCT.PARAMETER values. Certain Loan Inputs may be changed during the term of the
loan also like change in rate of interest etc....
Schedule Inputs are the parameters that define the schedule of repayments that govern the
management of the loan until maturity date. The Schedule Inputs may be fully or partially defined at
the inception of the loan. They may also be explicitly defined by the user or, where permissible, be left
for the system to be automatically defined. Additional Schedule Inputs may be added to the loan or
amended after the inception of the loan, subject to stringent validation and control depending on the
activity that has taken place on the loan prior to the amendment. Amendments to Schedule Inputs are
explained in detail in the sections “Defining Loan Schedules – Schedule Inputs” and “Loan Variations”
It is not possible to create a back dated contract beyond the last capitalisation date of the account.

All in One Account
Account Opening procedure

Using AZ.ACCOUNT, the loan account is set up in ACCOUNT. The ACCOUNT record must be
defined before the loan can be set up in AZ.ACCOUNT.
Using the ID of the corresponding ACCOUNT, the AZ.ACCOUNT has to be opened.
When setting up the customer account in ACCOUNT, AZ.ACCOUNT requires that the relevant
LIMIT.REF value be entered. Furthermore, the LINK.TO.LIMIT field should not be entered as YES,
as this may create an ADI record that may not be consistent with the existing ADI record of All in One
account, which has the reducing limit concept.
Defining Nominated and Repayment accounts

AZ.ACCOUNT allows for the loan account to be linked to non-loan accounts for the purpose of
disbursing the loan funds and / or receiving electronic payments.
The field NOMINATED.ACCOUNT, is used for identifying the drawdown account to which the funds are
to be disbursed. The associated fields NOM.INT.BANK, NOM.BEN.BANK and NOM.BEN.ACCT are used to
provide further information for external nominated accounts at other financial institutions.
The field REPAY.ACCOUNT is used for identifying the repayment account from which loan repayments
are to be received. If a valid account is defined under REPAY.ACCOUNT then the system will take care
of transferring the repayments on the COB of scheduled dates, if funds are available. The associated
fields REP.INT.BANK, REP.BEN.BANK and REP.BEN.ACCT are used to provide further information for
external repayment accounts at other financial institutions. Debiting the Nostro account defined under
REPAY.STO.ACCOUNT enables standing order generation. Based on the days defined under
DAYS.BEF.EVENT MT 104 message will be generated to the external bank.
The accounts identified for NOMINATED.ACCOUNT and REPAY.ACCOUNT may be internal customer
accounts, Nostro accounts or internal clearing accounts. Where the account is an external account at
another financial institution the account must be an internal clearing account.
AZ.ACCOUNT will post transactions to the nominated and repayment accounts as the relevant
events are triggered. The application used to process the transactions to / from external accounts at
other financial institutions must be set up to post the necessary debits and credits against the internal
clearing accounts. The same application must be set up to retrieve the associated information in the
fields XXX.INT.BANK, XXX.BEN.BANK and XXX.BEN.ACCT for passing on to the clearing system for the
external account at another financial institution.
In loan or deposit products if NOMINATED.ACCOUNT or REPAY.ACCOUNT is not defined then

TELLER.DEFAULT will be created with the id as 123456*20041222*P, where ‘123456’ is the
AZ.ACCOUNT, ‘20041222’ is the process date and ‘P’ is the ‘P’ schedule that created this
TELLER.DEFAULT. If ACCT.SYNC is set to ‘Y’ then when using this TELLER.DEFAULT in

All in One Account
TELLER the correct transaction code needs to be used on the side where AZ.ACCOUNT is
populated is to identify the correct transaction.
It is now possible when performing a part redemption on an AZ.ACCOUNT Fixed Deposit through
TELLER to specify if a TELLER.DEFAULT record is to be created or not. This must be stipulated
in the AZ..PRODUCT.PARAMETER in field CREATE.TD.FOR.INT.
If this value is YES then a TELLER.DEFAULT record will be created when a TELLER transaction
is processed debiting an AZ.ACCOUNT Fixed Deposit. This will only be created when no
nominated/interest liquidation is specified on the AZ.ACCOUNT.
If the field CREATE.TD.FOR.INT is NULL the interest will be credited to the credit side account
irrespective of it being the till account.
Loan Principal and Drawdown options

The value of the loan is defined in the field PRINCIPAL. Depending on the value selected in the
AZ.PRODUCT.PARAMETER field DRAWDOWN.TYPE, the loan amount may be disbursed either as
one full drawdown amount or as multiple partial drawdown amounts.
Full Drawdown
If the value selected in the field DRAWDOWN.TYPE on the AZ.PRODUCT.PARAMETER record is “1
FULL DRAWDOWN” then the user may only enter the full loan amount, i.e. the Principal, in the field
DRAWDOWN.AMOUNT.
When this value is entered the user is required to enter the drawdown date in the field AMOUNT.V.DATE.
When the record is committed the field FINAL.DD.IND will be auto populated with the value “Y”, and
this field will be a No Input field.
If this field is entered the AMOUNT.V.DATE must be equal to the loan VALUE.DATE. This field
should only be entered when there is no NOMINATED.ACCOUNT identified for the borrower. Once the

All in One Account
AZ.ACCOUNT record is authorised, the draw down amount will be set up in a TELLER.DEFAULT
for manual processing.
By entering the
corresponding loan account number in OUR.REFERENCE of
TELLER.TRANSACTION, all other details will be automatically populated to enable the withdrawal.
Full Drawdown – without a nominated account

If no nominated account has been defined for the borrower and this field is not entered at the time of
setting up the loan the user has the option of entering it at a later time. As explained above, when
there is no nominated account and a drawdown is opted on the loan value date, a
TELLER.DEFAULT will enable the users to draw the amount.
Repayment schedules cannot be defined until the drawdown amount has been entered.
Full Drawdown – with a nominated account

If a nominated account has been defined for the borrower and this field is not entered at the time of
setting up the loan, the user has the option of inputting it at a later time or scheduling it by defining a
“B” type schedule when entering Schedule Inputs. “B” type schedules can only be used if a nominated
account has been defined for the borrower. The “B” type schedule may be entered at the time of
creating the loan or at a later time.
“B” type schedules are discussed later under the section “Defining Loan Schedules – Schedule Inputs”.
Partial Drawdown
If the value selected in the field DRAWDOWN.TYPE on the AZ.PRODUCT.PARAMETER record is “2
PARTIAL & NO INT” or “3 PARTIAL & NO INT” then the user may enter an amount less than or
equal to the loan amount, in the field DRAWDOWN.AMOUNT.
When this value is entered the user is required to enter the drawdown date in the field AMOUNT.V.DATE.
The same rules apply in respect of “B” type schedules and nominated accounts, for Partial drawdown
amounts as do for Full drawdowns.
If a schedule has to be defined during the Partial drawdown period, ‘SCHEDULED BALANCE’ is to be
opted under the field CALCULATION.BASIS. For more details relating to CALCULATION.BASIS,
please refer to Chapter 11 on ‘Defining Loan Schedules – Schedule Inputs’.

All in One Account
First and Subsequent Partial Drawdown
The field FINAL.DD.IND will be an input field with no value. The user selects the option “N” to indicate
that only a partial drawdown has been made. If the user sets up “B” schedules, the value in the field
will remain empty.
Final Partial Drawdown
When the user enters the amount in DRAWDOWN AMOUNT, it causes the total value of all partial
drawdown amounts to be equal to the PRINCPAL amount the system will recognise that full drawdown
has taken place. Similarly, if the user is using “B” type schedules to set up the drawdown, once the
total value of all the drawdown amounts and “B” schedule amounts is equal to the PRINCPAL value,
the system will recognise that full drawdown has been scheduled.
Once the final drawdown is established the system will set the value in FINAL.DD.IND to “Y” and the
field will become a No Input field.
If, when entering a partial drawdown amount, the user decides that adequate funds have been drawn
for the loan, i.e. the total of all drawdown amounts is less than the PRINCIPAL, then the user may
select the value “Y” in the field FINAL.DD.IND. This will have the effect of manually forcing a final
drawdown. When the record is committed, the loan amount PRINCIPAL will be reduced to an amount
equal to the value of the total drawdown amounts.
Residual on Principal
The loan product may allow the borrower to pay a portion of the principal amount as a lump sum on
maturity of the loan. This amount is the residual and the value is entered in the field
RESIDUAL.PRINCIPAL.
Once the Residual Principal is defined, it cannot be changed subsequently.
While calculating the repayment schedule for Principal portion, the Residual portion will be excluded
and the schedule will be defined for the remaining amount as per the frequency. The Residual
Principal will be defined for repayment on the maturity date. Interest is calculated on the full balance
including the Residual principal. A repayment that includes a portion of the interest repayment will
include the interest calculated on the residual balance.
(The payment of Residual Principal at the maturity date is called as Balloon Repayment)
EXAMPLE
For a loan with the following attributes:
• Principal USD100,000.00
• Residual Principal USD25,000.00

All in One Account
• Fixed Interest Rate 10%

• Repayment Type LINEAR
• Frequency Monthly
• Term 3 Months
• Calculation Base Schedule Balance
• Interest Basis A 360/360
The repayment schedule will consist of a fixed amount of USD 25,000.00 plus an interest amount
calculated on the reducing schedule balance.
There will be 3 monthly repayments calculated as follows:
1. USD 25,000.00 Principal + USD 833.34 Interest (USD 100,000.00 * 10% * 30 / 360)
On maturity date the borrower will repay the residual balance of USD 25,000.00.
This is allowed only for ‘PRINCIPLE’, CURRENT BALANCE and ‘SCHEDULE BALANCE’ as the
calculation base. It is not allowed for NON REDEMPTION and OTHER types of loan. As in OTHER type
of loan the system will ask for the P schedule amount to be input. The drawdown amount should be
greater than the residual amount.
Defining Repayment types

AZ.ACCOUNT allows the user to define loans with multiple repayments or with a single bullet
repayment on maturity.
There are three basic loan products available in this module, viz. ANNUITY, LINEAR and NON-
REDEMPTION. The loan type is defined in the REPAYMENT.TYPE field. For a description of these loan
products refer to the User Guide for MORTGAGES.
A fourth REPAYMENT.TYPE option, ‘OTHERS’, is available. This repayment type does not adhere to
the repayment rules of the other three products and enables you to define a loan with irregular
repayments.
The fifth REPAYMENT.TYPE option is ‘CREDIT-CARD’. This type offers many features that are similar
to a loan issued using credit cards. This does not offer all the features of a credit card.
There are two deposit products available, viz. SAVINGS-PLAN and FIXED. In FIXED the deposit
amount is accepted in a fixed lump sum and repaid as fixed amount either with interest accumulated

All in One Account
or not. In SAVINGS-PLAN the deposit amount is accepted in a periodic basis and the principal is
increased in a recurring manner till the end of a fixed term.
Bullet Repayments
The repayment of a loan in a single bullet payment on maturity, by definition, means that no
repayment schedule is required. In order to define a bullet repayment type loan, the value “N” is
selected in the field SCHEDULES.
No values may be entered for Schedule Inputs. When the record is authorised a single repayment is
scheduled for maturity date. The repayment amount includes both the principal and interest portions.
Interest rates for bullet Repayment loans are defaulted from the AZ.PRODUCT.PARAMETER
record and cannot be adjusted at AZ.ACCOUNT level.
Multiple Repayments (Loan Schedules)

The majority of loans are set up for repayment by means of a number of multiple repayments over the
term of the loan. These repayments may be regular or irregular. The repayment amount may be
constant or vary with each repayment due date.
To define a loan with multiple repayments the value “Y” is selected in the field SCHEDULES. The input
of “Y” will cause the field REPAYMENT.TYPE to be populated using the default from the field
REPAYMENT.TYPE on the linked AZ.PRODUCT.PARAMETER.
The user has the option of changing the REPAYMENT.TYPE to one other than that defaulted. Again
AZ.ACCOUNT permits the user to tailor the loan differently for a particular financial product
specifically to the borrower’s requirements.
EXAMPLE:
For an ANNUITY loan with multiple partial drawdown amounts, where the final drawdown will take
place at an unknown date in the future, the loan REPAYMENT.TYPE may be changed from “ANNUITY”
to “NON-REDEMPTION” for the initial loan set up. In this scenario the loan will be set up for Interest
only repayments on the known partial drawdown balance, with the full principal repayment due on
maturity. As each subsequent partial drawdown is made, the Interest only repayment will increase.
Once the final drawdown is made the user changes the REPAYMENT.TYPE to “ANNUITY” and the full
ANNUITY schedule is defined.
When entering Schedule Inputs to define the loan schedules, the REPAYMENT.TYPE selected will
initiate specific Schedule Input validations.
The value selected in CALCULATION.BASE should be consistent with the REPAYMENT.TYPE.

All in One Account
Defining Repayment type in AZ.ACCOUNT

All in One Account
Defining Repayment types in AZ.ACCOUNT

All in One Account
Defining repayment types in AZ.ACCOUNT
Defining Interest Only Periods
The field INT.ONLY allows the user to restrict the option of Interest-Only repayment periods during the
term of the loan. If the value of this field is “N”, no Interest-Only periods may be applied in the loan
account. If the value is “Y”, Interest-Only periods are optional in the loan account.
A default value is populated to this field from AZ.PRODUCT.PARAMETER. The user has the
option of changing the value and will receive an override notification message when committing the
record if the value entered is different to the value on AZ.PRODUCT.PARAMETER. If it is required
that user be prevented from changing the default this restriction must be defined during system set up.
If the value in INT.ONLY is “Y” then a value must be entered for the field MAX.INSTL.INT.ONLY.
This value is the total period of time that the interest only repayment could be defined for a loan during
the lifetime of a loan account.

All in One Account
The input value may be entered as a number of days or a number of periods, where a period is the
time between the repayment due dates, in other words, the number of instalments.
These fields define the scope of Interest Only repayment periods for the loan at AZ.ACCOUNT level.
There is no definition determining the number of times that Interest Only repayment periods can be
defined during the term of the loan, nor the duration of any individual Interest Only repayment period,
provided the total of all periods is within the maximum number of periods defined in
MAX.INSTL.INT.ONLY.
The determination of when an Interest Only repayment period will be applied, and the duration thereof,
is defined when entering the Schedule Inputs.
In the case of AZ loans with repayment type as ‘Non Redemption’, validations with respect to
MAX.INSTL.INT.ONLY will not be done.
Defining Loan Schedules – Schedule Inputs

The loan schedules are predominantly concerned with defining the components and time periods that
are to be used in calculating the repayment amount due on the loan until the due date. The exception
is the “B” schedule, which is concerned with the disbursement of the loan funds. The types of
schedules entered will be governed by the value input in the REPAYMENT.TYPE field.
The Schedule Inputs are the macro level definitions that are passed to the AZ.SCHEDULES
application where each repayment will be calculated for each repayment due date.
If the value in the SCHEDULES field is “Y” then a minimum of one schedule type will be mandatory. The
REPAYMENT.TYPE value will also determine which schedule types may be mandatory. In some
circumstances an “I” “N” or “P” schedule type need not be entered as the system will determine from
the REPAYMENT.TYPE that the schedule is required and use the AZ.PRODUCT.PARAMETER
default values to generate the necessary schedule.
Multiple Schedule Inputs may be entered. Entering the relevant value in the field TYPE.OF.SCHEDULE,
for each multi-value, identifies the schedule being defined.
Each multi-value is made up of a group of associated fields, viz.
• TYPE.OF.SCHEDULE
• AMT.PERCENT
• AMOUNT
• FREQUENCY
• NUMBER

All in One Account
• RATE.SCH.KEY
• RATE.SCH.SPREAD
• RATE.SCH.OPERND
• RATE.SCH.PERCNT
• SCH.FIXED.RATE
Depending on the REPAYMENT.TYPE and TYPE.OF.SCHEDULE input in some of these fields is

mandatory, certain combinations of input are required and certain fields will be blocked from any input.
The AZ.SCHEDULES record stores the values of draw downs made so far, under the field
NEW.AMOUNT, with corresponding dates.
The field CALCULATION.BASIS defines the basis for calculation of repayment amount for the term of
the loan or for recalculation for the remaining term.
If 'Principal' is defined here, entire Principal amount will be taken into account, for deriving the
repayment amount and interest calculations, irrespective of the amount of Principal drawn.
If 'Schedule' is defined, the amount drawn down till date will be taken into account for repayment
amount and interest calculation purposes.
In Loans if SCHEDULES is set to 'N' then allowed value is 'Principal' or 'Schedule Balance'.
In Deposits if it is of FIXED type then allowed value is 'Principal' else 'Schedule balance'.
If a repayment or an instalment is made online and a schedule exists for that day then the schedule
will still execute during COB, e.g., if the B schedule is paid online the one in COB will still continue to
execute.
Drawdown Schedule
TYPE.OF.SCHEDULE = “B”
This type is used for effecting loan drawdown amounts on pre-defined dates. On the specified dates
the system will transfer the drawdown amount to the credit of the nominated account. This type of
schedule will only be allowed if a nominated account was defined in the Loan Inputs. The nominated
account is required to enable the system to carry out the credit on the defined future date.
The associated fields entered for a “B” Schedule are AMOUNT and FREQUENCY.

All in One Account
AMOUNT is the value of the drawdown and is validated to ensure that the total value of the amounts
specified in all B schedules and the Drawdown amounts made to-date, do not exceed the Principal.
FREQUENCY is entered as a date only and identifies the date when the drawdown is to be affected.
The drawdown will be processed at start of day on the specified date.
Multiple schedules may be entered for loans permitting multiple partial drawdown amounts.
Repayment Schedule – Annuity
TYPE.OF.SCHEDULE = “A”
This schedule is allowed only for loans with an “Annuity” REPAYMENT.TYPE and is mandatory. This
schedule will generate a repayment amount that remains constant through the term of the loan.
During the period of the annuity schedule the interest portion of the repayment will reduce and the
principal portion will increase.
In the case of a loan with only one “A” type schedule the loan balance after the last repayment due
date will be zero, where there is no residual defined. In the case of a residual amount being defined
the loan balance after the last repayment due date will be the residual amount.
Multiple schedules may be input for different periods during the term of the loan. Where multiple “A”
schedules are defined, it is necessary for at least one “A” type schedule to be input, which includes the
maturity date and brings the loan balance to zero (or the residual amount).
The associated fields entered for an “A” type schedule are FREQUENCY and NUMBER.
FREQUENCY may be entered as a date, where only one period is identified, viz. the final maturity
repayment. In most cases date and frequency will be entered. The date portion identifies the date
when the first annuity repayment is due. The frequency portion identifies the duration between
repayment periods and determines the date on which repayment will be due. The system will process
the repayment at end of day on the due date.
NUMBER is the number of repayment periods (instalments), for which the “A” type schedule applies
from the schedule’s first repayment due date, and is an optional input. This value will generally only be
entered when multiple “A” type schedules are input. The total number of periods and the frequency
must coincide with the Loan Input MATURITY.DATE.
Annuity repayment schedule with amount as zero can be used for defining repayment holiday (Zero
Repayment) period for the loan account for a fixed period.

All in One Account
Repayment Schedule – Principal
TYPE.OF.SCHEDULE = “P”
This schedule is used to define the amounts and due dates for the repayment of the principal portions
of the loan.
This schedule is not permitted with “ANNUITY” REPAYMENT.TYPE loans.
The associated fields entered for a “P” type schedule are FREQUENCY and NUMBER.
FREQUENCY may be entered as a date, where only one period is identified, viz. the final maturity
repayment. In most cases date and frequency will be entered. The date portion identifies the date
when the first principal repayment is due. The frequency portion identifies the duration between
repayment periods and determines the date on which repayment will be due. The system will process
the repayment at Close of Business on the due date.
NUMBER is the number of repayment periods (instalments), for which the “P” type schedule applies
from the schedule’s first repayment due date, and is an optional input. This value will generally only be
entered when multiple “P” type schedules are input. The total number of periods and the frequency
must coincide with the Loan Input MATURITY.DATE.
In the case of ‘OTHER’ type of Repayment method, AMOUNT field is used for specifying the amount of
Principal Repayment. The system ensures that the sum of the amount entered on various dates, is
equal to the Principal amount.
Repayment Schedules – Interest
Interest Only Schedule
TYPE.OF.SCHEDULE = “I” and “N”
These schedules are used to define the due dates for the interest capitalisation and interest collection.
Since ‘I’ schedule is only for the purpose of capitalising, the interest arrears processing will not happen
based on this. Whereas in the case of ‘N’ schedule, since interest payment is expected from the
customer, arrears processing and penal interest will happen based on account balance.
In the case of ‘I’ schedules, the system increases the banded amount of ADI and increases the limit to
the extent of ‘I’ schedule amount to avoid penalty. For ‘N’ type, the ADI band and limit are reduced to
the extent of ‘N’ schedule amount for arrears and penalty calculation.

All in One Account
By defining ‘I’ schedules and ‘N’ schedules with different frequencies, interest compounding can be
achieved. For example, if ‘I’ schedule is defined monthly and ‘N’ schedule is defined once in three
months, the interest gets compounded on monthly basis for 3 months.
The associated fields entered for an “I” type and “N” type schedules are FREQUENCY and NUMBER.
FREQUENCY may be entered as a date only, to indicate the start of an interest repayment period. The
date portion identifies the date when the first interest repayment is due for the particular schedule.
The frequency portion identifies the duration between repayment periods and determines the date on
which interest repayment will be due. The system will process the repayment at Close of Business on
the due date.
NUMBER is the number of repayment periods (instalments), for which the “I”/ “N” schedule applies from
the schedule’s first repayment due date, and is an optional input. This value will generally only be
entered when multiple “I” type / “N” type schedules are input.
The total period of all “NI” type schedules are validated against MAX.INSTL.INT.ONLY defined in the
Loan Inputs for the loan and an override message is generated if the total period exceeds the
maximum.
In the case of ‘I’ and ‘N’ type schedules amount should not be entered.
Interest Rate Schedule
TYPE.OF.SCHEDULE = “R”
This schedule is used for effecting Interest Rate revision on specified dates. When used at the
inception of a new loan the schedule is used to provide the user with the opportunity override the
default rates of the AZ.PRODUCT.PARAMETER record and to define interest rates specific to the
loan being set up.
When used to amend an active loan the Loan Input value in TERM.PRIORITY will be taken into
account when defining this schedule. If TERM.PRIORITY is defined as Y then, the maturity date will be
retained and the change will be effected on the Repayment amount. If defined as N then the maturity
date will be changed and the repayment amount will remain the same. Based on the value given for
RECALC.CURR.AMOUNT, the changes will be effected in the current repayment period or the next one.
The schedule provides for the revision of the variable interest rate, the fixed interest rate and the ratio
of the application of variable to fixed interest calculation on the outstanding balance.
The associated fields entered for an “I” type schedule are FREQUENCY, RATE.SCH.KEY,
RATE.SCH.SPREAD, RATE.SCH.OPERND, RATE.SCH.PERCNT, and SCH.FIXED.RATE.

All in One Account
FREQUENCY is mandatory and entered as a date only. The date identifies the date when the rate
revision will take effect. The system will process the rate change at start of day on the effective date.
For RATE.SCH.KEY, RATE.SCH.SPREAD, RATE.SCH.OPERND, RATE.SCH.PERCNT, and SCH.FIXED.RATE

the values are input in accordance with the rules explained in the AZ.PRODUCT.PARAMETER
section, ‘Debit Interest Rates’, above.
EXAMPLE
Example of an R type schedule:
Type of Schedule: R
Frequency 20010522
Rate Sch Key: 1
Rate Sch Spread: 6
Rate Sch Operand: Add
Rate Sch Percent: 60
Sch Fixed Rate: 15
As per the above R schedule, a rate revision will happen on 22-05-2001, with 60% of the outstanding
amount by a variable interest (key1 and spread 6 on Basic Interest) and 40% of the outstanding
amount by fixed interest 15%.
Charge Collection Schedule

The schedule file AZ.SCHEDULES already contains the field as TYPE.C for holding the charge
amount as per frequency. This field can be used for filling the charge amount.
As and when the C schedule is defined in AZ.ACCOUNT, after committing/ authorising the value of
charge is to be calculated based on CHARGE.CODE, CHG.BASE.AMT and the amount has to be
written in the AZ.SCHEDULES table.
If it is a one-time charge the frequency will contain a particular day. The date and the charge amount
has to be written in AZ.SCHEDULES
If a frequency is defined for a charge under C schedule, then the AZ.SCHEDULES will be built on
these days with the charge amount
If the user gives a combined schedule as BC, then the AZ.SCHEDULES will be built suitably and
both principal increase and charge collection should happen as per the frequency.
The CHG.BASE.AMT defines the basis on which the charges/ commission has to be calculated
The charges arrived and noted in schedule will be recovered from the CHG.LIQUID.AC specified
If no CHG.LIQUID.AC is defined by the user, then the system has to default the REPAY.ACCOUNT in
the case of AZ Deposit and NOMINATED.ACCOUNT in the case of AZ loan that has been defined
already.

All in One Account
If no CHG.LIQUID.AC, REPAY.ACCOUNT (for deposits) or NOMINATED.ACCOUNT (for loans) is

defined, then an error will be given.
Charges cannot be capitalised
One-time Charge Collection:
This is for collecting a one-time charge as defined in AZ account.
As and when charge details are filled in the relevant fields and authorised, one time charge will be
collected from the CHG.LIQUID.AC as per the CHARGE.CODE and CHARGE.DATE as an on-line
activity
The CHARGE.DATE field mentioned here should have only the process day (business date / T24 date)
by default. That means for future dated charge collection the fields under Schedules have to be used.
The charge fields CHARGE.CODE and CHARGE.DATE are active at present only for pre-closure.
Rebuilding schedules after an online repayment of annuity loan
When INT.CORR.IMMED in the APP is set to “Current” correction interest on account of any
backdated event (eg: drawdown, rate change, principal settlement) will be recovered immediately
When INT.CORR.IMMED in the APP is set to “Next” correction interest will be parked in AZ INT ADJ
Suspense account and collected in the subsequent repayment. “Next” can be set only for Annuity
loans and only when ANNUITY.ADJUST is set to “Yes”
The field INT.CORR.RTN in the APP is a Hook field that can hold a local routine to get values for the
field INT.CORR.IMMED. The local routine should be specified in EB.API application.
AZ.SCHEDULES:
“Online Amt “ in the schedules gets updated with
N - Interest component collected
P - Principal component collected
I - Int Adj Amt (on account of reversal of an online repayment) to be collected
S - Correction interest (on account of backdated drawdown) to be collected
R - Int Adj Amt & Correction interest (parked in AZ INT ADJ Suspense account) collected
during the next online repayment
In case Int Adj Amt & Correction interest component is collected during a scheduled repayment
then the same is added to “Type N”.
When INT.CORR.IMMED is set to “Current” then Correction Interest collected is added to “N”
Defining Variable and Fixed rate of interest

One of the most important features of the All In One Module is defining the combination of Variable
and Fixed Interest Rates in an account, either at the start of the loan as a default from the
AZ.PRODUCT.PARAMETER, or at any time during the life of the account by means of R type of
schedules.

All in One Account
The combination of Variable and Fixed interest may be based on a certain percentage of the
outstanding amount.
Within the life of the account, the Variable interest or Fixed interest or a combination of both can be
defined for any period, by defining R type of schedules. (Please refer to the relevant part in Volume 3
of User Guide for more details and example).
Schedules link to Limit and ADI
REPAYMENT SCHEDULE AND REDUCING LIMIT
In the case of multiple repayments defined through a schedule, the values of repayment amount and
repayment frequency are transferred from schedule to the corresponding LIMIT record of the AZ
account. Based on these values, the system will reduce the available limit amount by the repayment
amount on the repayment date. The current limit arrived in the above manner enables the system to
determine the arrears and the maximum permissible redraw amount. Please refer Figure 9.
As in normal ACCOUNT, an ADI record is created for each AZ.ACCOUNT with account number
and date as its ID. The interest for AZ.ACCOUNT is calculated during End of Day, based on the

All in One Account
corresponding ADI record. Dr Limit Amt field of ADI record stores different slabs relating to different
types of rate of interest. If a percentage of outstanding relates to variable interest and the remaining
amount relates to fixed rate, the percentage value is defined in the first multi-value record and the total
value in the second record with corresponding interest rate details. The interest rate defined in the
third multi value record will take care of charging penalty on the arrears portion over and above the
current available limit.
The Dr Limit fields get updated as and when the outstanding amount changes as per schedule on the
scheduled dates and the interest calculation is done based on the updated amount.
Reschedule Process and Term Priority
Repayment schedule defined for an AZ.ACCOUNT is quite dynamic.
Rescheduling of a loan account can be done whenever the following changes happen to the
AZ.ACCOUNT, by opting the TERM PRIORITY as per requirement:
• Change in Principal amount (Increase)

• Change in Rate of interest
• Change in Frequency
• Change in Term
AZ.SCHEDULE record will contain the current values of the schedule attributes.
In the case of change in Basic Interest attached to a loan account through an interest key, the system
automatically reschedules the repayment. The field relating to reschedule notice period in Product
Parameter, defines the number of days after which the reschedule will be effective, in the case of
change in the Basic Interest rate attached to the account through a key. An option is available to
specify whether the change has to be applied for the existing loans also or not.
The value for Term Priority defined in AZ.PRODUCT.PARAMETER will be taken into
account, for automatic rescheduling.
Loan Repayment Schedule History

Changes in Principal amount, Rate of interest, Term, or Frequency may result in Re scheduling, based
on the value of Term Priority opted by the user, in AZ.ACCOUNT.
Whenever, an existing schedule is rescheduled, as explained above, the revised schedule is written in
AZ.SCHEDULES and the previous schedule is written in AZ.SCHEDULES.HIST.
A combination of AZ account number, date of reschedule and serial number is defined as the ID for
AZ.SCHEDULES.HIST.

All in One Account
The Repayment Schedule history contains the reason for rescheduling also as ‘Notes’.
A view of AZ.SCHEDULES.HIST

All in One Account
Current Date Principal increase in Annuity repayment type loans

Current Date Principal increase i.e. reversal of online repayments can be made only for online
repayments done between two repayment schedules.
The principal increase can be done either through the AZ or TT applications using Drawdown Txn
code.
Set up -Debit transaction code to be defined in AZ.PRODUCT.PARAMETER for Interest
adjustment. ACCOUNT.CLASS to be defined for Interest adjustment. Internal account to be opened
for interest adjustment suspense account.
• Reversal possible only for AZ Annuity type contracts
REDUCE.LIMIT in AZ is set as 'NO'
ACCT.SYNC is equal to “YES”
• Interest adjustment allowed only for TODAY
To differentiate between drawdown and Current Date Principal increase,
LOCAL.TABLE and LOCAL.REF.TABLE to be set for updating LOCAL.REF field of
STMT.ENTRY
When a user defines a repayment amount which is less than the interest
repayment amount.
When the user makes a online advance repayment through TELLER or FT applications then on
committing the TELLER or FT record, a local Post Auth Routine will be called from the version.
Calling of this routine is dependent on the availability of Post Auth API in the
VERSION/VERSION.CONTROL. This routine will be used to redefine the schedule in the
AZ.ACCOUNT record. The APP should be established as follows:-
AZ.PRODUCT.PARAMETER – Annuity Type
Field ANNUITY.ADJUST = YES
Field Term Priority = No
- PD Link to AZ = YES (For PD Creation)
The redefining of schedule through this routine will happen using the following logic. A new local
reference field (MAX.RO.INST) will be defined in the APP which will hold the value of maximum
number of repayment rollovers.
Loan Account Operations

Operation of All in One loan account is similar to that of a normal account. The credit, debit
transactions in the account can be made through any channel like TELLER, ATM, FT, and DATA
CAPTURE etc.

All in One Account
Only during the draw down period, the Bank should take care to restrict operations in AZ.ACCOUNT
through channels other than the AZ.ACCOUNT. The reason is, at present, the system could not
recognize the operations done through other channels for updating the schedule to keep track of total
draw down amounts.
Redraw Process
Redraw process defines withdrawal from the loan account, apart from the principal drawdown
amounts. Any credit to the account that is in excess of the scheduled loan repayment amount can be
withdrawn from the account through any channel, like TELLER, ATM etc. The check on current limit
will be performed by the system, for the withdrawal and suitable override will be produced, when the
redraw amount exceeds the limit available for the loan account.
Arrears – Penalty Process
Penalty is calculated on the amount drawn in excess of the available limit (arrears), if APPLY.PENALTY
is defined as ‘Y’ in AZ.PRODUCT.PARAMETER. The penal rate will be taken from the concerned
AZ.ACCOUNT and penalty is calculated with retrospective effect, after the expiry of grace period.
Loan Account Closure
The field PRE.CLOSURE.IND of AZ.ACCOUNT is used for opting pre-closure of a loan account. If 'Y'
is defined here, the system will inform the users the total amount due in the account, inclusive of
interest. Based on these details, decision can be made to proceed further in closing the account or not.
In the normal course, if there is no debit balance in the loan account on maturity date, then the loan is
treated as closed. If debit balance in the loan account continues even after the maturity date, then the
penalty will be charged on the outstanding debit balance as per the interest defined in AZ.ACCOUNT.
Pre-closure charges for loan account will be charged based on the charge code defined in the
corresponding Product Parameter.
When a loan is preclosured in AZ.ACCOUNT all the files will be moved to history online, whereas if
the preclosure is done from TELLER / FT all the AZ related files will be moved to history only during
COB.
Non Reducing Limits – AZ ACCOUNTS
AZ account which is based on the account module, can handle both non-revolving and revolving type
of loans.
The field REDUCE.LIMIT in AZ.PRODUCT.PARAMETER and AZ.ACCOUNT is used for

revolving type loans. The value of REDUCE.LIMIT in AZ.PRODUCT.PARAMETER is populated in
AZ.ACCOUNT and could be altered at the AZ.ACCOUNT level. While processing the account, the
value in the AZ.ACCOUNT would be checked and if nothing were entered, the value defined in

All in One Account
AZ.PRODUCT.PARAMETER would be taken into account. This field would be available for input
only when SINGLE LIMIT is defined as ‘yes’.
AZ.PRODUCT.PARAMETER- REDUCE LIMIT NO INPUT
The default value would be null which is equivalent to yes. When the value of REDUCE. LIMIT is
defined as ‘yes’ the amount withdrawn is permanently reduced from the limit. Also the related field in
LIMIT is updated.
LIMIT UPDATION - REDUCE.LIMIT 'YES'

All in One Account
Accordingly, when the value is defined as ‘n’, though the amount withdrawn down is reduced from the
limit, the same would be available for withdrawal again once the repayment is made. For ensuring this,
the related fields in the LIMIT are not updated.
AZ.PRODUCT.PARAMETER - REDUCE.LIMIT 'NO'
LIMIT UPDATION - REDUCE.LIMIT 'NO'
Minimum Maturity Date
The field MIN.MAT.DATE is used for AZ.ACCOUNTS of Revolving (Reduce Limit = N) Loan type
(Except Credit Card) to handle the minimum maturity date. On repayment (Not Pre-closure) though
the working balance becomes zero, the contract stays live till the MIN.MAT.DATE defined in the
AZ.ACCOUNT and moves to history during COB of the MIN.MAT.DATE, subject to working balance
being zero.
Past the MIN.MAT.DATE, the contract moves to History during the subsequent COB, again, subject to
working balance of the underlying ACCOUNT being 0 (zero).

All in One Account
During Pre-closure, the contract behaves as per existing functionality. I.e. moves to history online,
irrespective of the MIN.MAT.DATE.
SINGLE LIMIT – MULTIPLE LOANS

Previously, the concept of a single limit being shared by more than one account was available only for
credit card type of loans. This concept is being extended to all other types of loan contracts.
For this purpose, a validation is created to check the value of the field SINGLE.LIMIT in both
ACCOUNT and AZ.PRODUCT.PARAMETER applications. The value input in the field
SINGLE.LIMIT in both the applications should be the same for the creation of AZ.ACCOUNT
ACCOUNT

All in One Account
Since the value of the field SINGLE.LIMIT in ACCOUNT and AZ.PRODUCT.PARAMETER does
not match, while creating an AZ account would raise an error.

All in One Account
SCREENSHOT SHOWING ERROR IN AZ.ACCOUNT
It would permit creation of AZ account only when the value of SINGLE LIMIT is same in both the
applications.

All in One Account
AZ.PARAMETER - SINGLE LIMIT N
ACCOUNT - SINGLE LIMIT N

All in One Account
AZ.ACCOUNT
Once an AZ ACCOUNT is created, the field SINGLE.LIMIT is a no input / no change field in both
the ACCOUNT and AZ.PRODUCT.PARAMETER.
AZ.PRODUCT.PARAMETER - SINGLE LIMIT - NO INPUT FIELD

All in One Account
ACCOUNT - SINGLE LIMIT - NO INPUT FIELD
User Definable Annuity Amounts
In the AZ module, annuity type of contracts can be created only with the frequencies for the amount.
The annuity amount is system generated. Now it has been enhanced to accept user definable
amounts at different dates / frequencies within the maturity date.
In Annuity type of contracts, whenever the user-defined amount is input in field AMOUNT in the type
“A” schedule multivalue set, the AZ.SCHEDULES are rebuilt online. The user-defined amount should
at least cover the interest portion. Once an amount is defined in the ‘A’ schedule in AZ.ACCOUNT, it
is compared with the system-generated amount and if it is greater than the interest portion, then an
override occurs.

All in One Account
AZ.ACCOUNT WITHOUT USERDEFINED AMOUNT

All in One Account
AZ.SCHEDULES
AZ.ACCOUNT - USERDEFINED AMT < INT - ERROR

All in One Account
AZ.ACCOUNT - USERDEFINED AMT - OVERRIDE
If the user defined amount is less than the actual annuity amount, then the differential amount would
be collected at maturity.
AZ.SCHEDULES
If the user defined amount is greater than the actual annuity amount, then the term of the annuity
contract would be reduced proportionately. For instance in an AZ annuity type of contract for 10000 for
a period of 6 months (1 Apr to 1 Oct) the annuity amount works out to 736 approximately when
payment is due bi-weekly. Now when the amount is defined as 1000 the maturity date is reduced to 9
December.

All in One Account
AZ.ACCOUNT - USERDEFINED AMT GREATER THAN ACTUAL
After defining the user defined amount, in case of floating type of contracts, if there is a change in
interest rate during the tenor of the contract, which would result in the increase in the interest amount
that would be greater than the user-defined amount, then the user defined amount is overwritten with
the interest portion and an override is raised in the AZ.ACCOUNT.
AZ.OVERDUES
The concept of AZ.OVERDUES is available inT24. It general under loans the penalty rate is
applicable to only those instalments that have not been paid and become overdue with the remaining
part of the loan amount being charged at the normal loan rate applicable. This file is only for
information and there is no additional processing on this file like PD.
In an UCR (Upper Ceiling Rate) kind of environment it is destined that once a portion of the loan
becomes due and not paid then the entire loan amount including the not due but payable will be
charged at the PENAL rate. In short, a single fall off in the payment of an instalment would entitle
PENALTY being imposed by way of penal rate on the ENTIRE OUTSTANDING.
Note: - The upper ceiling rate functionality is to be handled locally and the interest rate is
populated through a routine, which will effectively do the calculations for the entire outstanding.
Pre-requisites
UCR is handled through AZ. OVERDUES file. A live file that is updated with the instalments due and
payable. The basic set-up to enable the overdues to be listed under AZ OVERDUES live file is to
flag the PD.LINK.TO.AZ field as NO

All in One Account
A LINEAR AZ. PRODUCT. PARAMETER FOR UCR SET UP
Given below is an a/c that is attached to the AZ. PRODUCT. PARAMETER stated above.
Loan amount input $ 100000

Start date 16.09.03
End/maturity date 29.09.03
Schedules – “P” 17.09.03- DAILY
“I” 17.09.03- DAILY
“N” 17.09.03- DAILY

All in One Account
AZ.ACCOUNT ATTACHED TO AZ.PRODUCT
On the dues dates the system would try to recover the interest (“N” schedule)and instalments (“P”
schedule) from the repay a/c (in case interest liquidation a/c is defined – then interest recovery is
made from the interest liquidation a/c) and in case of unavailability of funds –it would updated the
AZ.OVERDUES since the PD.LINK.TO. AZ is set as “NO”.
The first “P”, “I” and “N” are due on 17.9.03 (it can be on different dates also). On the EOD of 17.9.03-
the system realises that the instalment could not be recovered and that it has to update the overdues
file. This is in case of Grace Period field being Null. In case the grace period field in
AZ.PRODUCT.PARAMETER (APP) is taken in to a/c and the AZ.OVERDUES file is updated after
the expiry of the GRACE period with the date on which it was originally due. To continue the present
example if the Grace period in APP is given as 01C –then the system would have written the
AZ.OVERDUES file only on 18.09.03 and not on 17.09.03 as was the case at present.
AZ.OVERDUES FILE UPDATION
As related above when the instalment becomes due the system has updated the OD.PRINCIPAL and
the OD.INTEREST fields as shown above.
ACCOUNTING: -
Unlike PD the system doesn’t raise any entry for the AZ.OVERDUES except for the interest portion.
For the interest amount a sub a/c is created and debited (based on the set up made in

All in One Account
AC.AUTO.ACCOUNT-) crediting the AZ.ACCOUNT or the INTEREST LIQUIDATION ACCOUNT

as the case may be. For one main a/c there is only one sub a/c created to which interest entries are
passed through. The principal amount in AZ.ACCOUNT will remain intact till the payment is affected.
The overdues can be settled through TELLER/FT applications using the OD.PRINCIPAL.TXN and
OD.INTEREST.TXN codes as defined in the AZ.PRODUCT.PARAMETER .Any excess remittance
over and above the dues or over and above the total outstanding will be credited back to the
repayment account.
In continuation, if the subsequent instalments were not paid the system would multivalue the
AZ.OVERDUES live file and write the overdues as shown below ;
AZ.OVERDUES FILE UPDATION.
The OD.AGE field in the AZ.OVERDUES file will be updated with number of days from the date
when the first instalment become overdue.
Even if the maturity date of the AZ.ACCOUNT is over – if there are overdues then the
AZ.ACCOUNT will not be moved to history or closed. This is done subsequent to the closing of the
overdues.
Interest Received In Advance (IRA)

In AZ Loan account the Interest amount due on a schedule date can be remitted to the AZ Account
before the Interest due date and because of this there will be a variation between the actual interest
calculated for the Account and the Interest computed as per original AZ Account Schedule.
For example AZ Loan account has a Principal USD10,000 as on 01st Jan and the Interest payout is
scheduled on 15th Jan is USD1000.

All in One Account
Let us say on 05th Jan customer remits the Interest amount of USD 1000 to the AZ Account. Because
of the advance Interest Received to the AZ account, the Outstanding Principal from 05th Jan to 15th
Jan is reduced to USD 9,000 and actual interest will be calculated using this balance.
Hence instead of posting the interest received before the interest scheduled date (IRA) to the AZ
Account, now facility is available to credit it to a Sub Account and on the interest schedule date- the
amount is taken from Sub Account and posted to AZ account automatically.
IRA facility is available to all AZ Loan repayment types except Annuity & Credit Card
Set-up related to AZ- Interest Received in Advance
The IRA functionality for AZ Loan accounts can be activated by setting the field IRA.PROCESS in
AZ.PRODUCT.PARAMETER as “Yes”. The ACCT.SYNC should also be set to “Yes” so that the
any debit or credit to AZ Account is validated against the appropriate events related to AZ Contract.
IRA.PROCESS setting at AZ.PRODUCT.PARAMETER
The Transaction code related to Interest received in advance has to be given in INT.CR.CAP along
with the other Interest Credit capitalisation related txn codes.
IRA transaction code given in Int.cr.Cap

All in One Account
Add a record in TELLER.TRANSACTION with the IRA transaction code as specified in APP for the
credit leg to Process IRA through Teller. Same transaction code can be given in
FT.TXN.TYPE.CONDITION for FT or Transaction code in DC to process IRA in those applications.
Note IRA transaction code should not be used in any other on line Contract Application processing or
end of day processing other than above.
TELLER.TRANSACTION with IRA-Transaction code
In AC.AUTO.ACCOUNT specify the rules related to creation of sub account from the AZ account to
post IRA. Various defaulting to the Sub account from main Account can be specified here and it is
used while creating the Sub Account automatically.
AC.AUTO.ACCOUNT set-up details
Now input a TELLER transaction using above IRA transaction code by crediting the AZ Loan Account.
On authorisation of Teller record, sub-account is created automatically for the AZ ACCOUNT and the

All in One Account
interest amount received in advance is posted to the Sub Account. In case more than one credit is
received as IRA to the AZ account, then sub ACCOUNT which is already available to the AZ
ACCOUNT is credited with the respective value date.
On the (“N”-Interest recovery) scheduled date, the sub account is debited to the extent of actual
interest and credited to Interest liquidation account if specified in AZ ACCOUNT or to the AZ
ACCOUNT. In sub ACCOUNT, the master account number is available for Cross-reference. * See
the below mentioned table which has various processes related to IRA.
MASTER ACCOUNT REFERENCE AVAILABLE IN SUB ACCOUNT

The details pertaining to Interest received in advance for an AZ account is maintained in
AZ.ACCT.BAL with the value date wise along with amount for each value date and the over all IRA
balance.
AZ.ACCT.BAL WITH IRA Details

All in One Account
IRA AMOUNT POSTED TO SUB ACCOUNT
If overdue interest is present and the user does a transaction for credit IRA then the system would
park the funds in the IRA account and not settle the overdue interest.
The following are the cases when sub accounts are used in az.
1. CREDIT CARD type of products
2. Multi deposit
3. Partial withdrawal of a deposit
AZ.OVERDUES
4. IRA
If IRA and AZ.OVERDUES co-exist then it is possible to use the same sub account for both the
accounts so as to reuse the sub accounts instead of creating a new one every time.
Settlement Priority
In AZ Loans, repayment to the loan contract can be by ways of pre-defined schedules and these
schedules are processed during end of day.
In addition to the predefined schedules, Customers can also remit amount towards their AZ Loan
Accounts through online application like TELLER, FT & DC and during system appropriates the
amount using the predefined rules as specified for an AZ ACCOUNT, CUSTOMER, PRODUCT or
Default rules (System). These appropriation rules can be set for combination of components to a
Loan (like Principal, Overdue Principal, Interest, Overdue Interest, Overdue changes, Penal interest
spread), due dates and across various AZ products.
To trigger settlement priority processing, amount can be credited with the LOAN.REPAY transaction
code as specified in Product parameter either to the AZ.ACCOUNT directly or to a common AZ
REPAY. ACCOUNT to process more than one AZ.ACCOUNTS.

All in One Account
Repayment Methods
There are 3 methods of repayment types and any combination of these can be given to process
settlement priority, which is explained below.
AZ.AMOUNT.TYPE
Amount type refers to the various components in AZ Loan Accounts and for any priority rule
AZ.AMOUNT.TYPE has to be defined with at least one amount type. The valid amount types are
OD.PR - Overdue Principal *

OD.IN - Overdue Interest
OD.CH - Overdue charges
PE - Penalty Interest
PS - Penalty spread
PR - Principal
IN - Interest
*OD as mentioned in the above repayment type refers to the Over dues maintained in
AZ.OVERDUES Application or details as available in PD Application for the respective
AZ.ACCOUNTS. Consult AZ.OVERDUE section in this user guide for creating Overdue (OD) / Past
due (PD) records for the outstanding in AZ Loan Accounts.
Date
When the priority is based on the date, then the component that has the oldest date is processed first.
AZ.PRODUCT.PARAMETER(APP)
AZ loan products can be given to prioritise the settlement based on various Loan products. For a
customer, when same component says Overdue principal is due with the same value date for more
than one AZ loan products then the product that has the high priority as given in the APP is processed
first for repayment.

All in One Account
Settlement priority rules
AZ.SETTLEMENT.PRIORITY (ASP) application is used to define the appropriation rules with the
combination of any of the above repayment methods i.e. AZ.AMOUNT.TYPE.DATE,
AZ.PRODUCT.PARAMETER.
The order of priority is based on the multi value order in which above repayment methods are
specified in ASP and in case any surplus exists after settlement priority processing is credited to the
AZ REPAYMENT ACCOUNT.
For example: If AZ.AMOUNT.TYPE is given in first multi value with Loan components-OD.PR,OD.IN
along with DATE & AZ PRODUCT is defined, then the first priority is based on the amount type which
is sorted by the date in ascending order and then prioritised by the Product.
If DATE is given in the first multi value and in second multi value AZ.AMOUNT.TYPE is specified, then
the components are sorted by dates and the farthest component is processed first irrespective of the
amount type.
The valid ID to the AZ.SETTLEMENT.PRIORITY application is: -
1. AZ Account – prefixed with “A”

2. Customer –Prefixed with “C”
3. AZ product parameter
4. System (Default)
System (Default)
The settlement priority processing is as per the order given in ASP and in case the system doesn’t find
the matching record in Account, Customer or product levels then settlement priority is based default
“SYSTEM” record. Hence, ‘SYSTEM” record has to be defined before defining any record in
AZ.SETTLEMENT.PRIORITY and also once created cannot be reversed.

All in One Account
DEFAULT SYSTEM RECORD IN ASP
In the above example for “System” record has been defined to process the Loan components based
on amount type at first level and in case more than one record is available for the same amount type
then component which has the oldest value date to be processed at second level and in case more
than one Loan product is available with same amount type & with same value date, then at level three
Accounts which have the Product as “ANN-OD” has to be prioritized for settling.
To define an individual Product level Priority, the product has to be added in ORDER.BY.APP. In
case AZ.PRODUCT.PARAMETER is given as one of repayment type in SYSTEM record, then
AZ.ACCOUNTS with other products types cannot be processed under default mechanism.
Moreover the products specified in ORDER.BY.APP & REPAY.ORDER are mutually exclusive.
Account (Level 1)
To define a priority for a deal or for a Particular Account, add a record in ASP with the ID as an AZ
account prefixed with “A-“ and once it is defined it has the highest level of priority.
In the given below example for AZ.ACCOUNT 37467 priority is defined for amount type,
OD.PR,OD.IN & IN which are sorted by date.

All in One Account
ACCOUNT LEVEL PRIORITY DEFINITION IN ASP (LEVEL 1)
Customer (Level 2)
After AZ.ACCOUNT, the next level of priority is for the customer and id can be given with a valid
Customer id prefixing with “C-“.
In the given below example, for customer id –1010, settlement is based on AMOUNT TYPE first. In
case several loan products are due with above combination, then the AZ account/s, which has the
Product “2000” to be prioritised.
CUSTOMER LEVEL PRIORITY DEFINITION IN ASP (LEVEL 2)
To process Settlement priority at the customer level, AZ.CUSTOMER application is referred which
has list of live AZ ACCOUNTS for a Customer.

All in One Account
LIST OF AZ.ACCOUNTS OPENED FOR CUSTOMER
Product (Level 3)
Settlement priority can be defined for AZ Loan products that have the LOAN.REPAY transaction code
set at the Product level. Priority for the product can be defined only when the Product is given in
ORDER.BY.APP in SYSTEM Record.
In the given example, for “ANN-OD”- annuity overdue product, irrespective of the dates, Overdue
Principal (OD.PR) is processed before other components. At the Account & product level settlement
priority, AZ.PRODUCT.PARAMETER repayment method is not allowed.
PRODUCT LEVEL PRIORITY DEFINITION IN ASP (LEVEL 3)
Link to Settlement priority
When an Account / Customer/ Product has the same settlement priority rules like the existing Account/
Customer/ Product, then instead of creating a new record with same details, a link to the existing
record can be given in ASP using the LINK.TO.SETT.PRIOR.
An Account record can be linked to an existing Account & not to any Customer / Product record in
ASP. This hold same for customer & product linkage.

All in One Account
Also in case settlement priority to be skipped for a particular Account / Customer/ Product, a record in
ASP can be created with LINK.TO.SETT.PRIOR set to ‘NONE’.
In the below mentioned example for account 35858 settlement priority is set to “None”, because of
which any remittances made to this AZ ACCOUNT using LOAN.REPAY transaction code through
TELLER / FT/ DC is moved to its Repayment Account and not adjusted towards any of the Loan
components.
SWITCHING OFF SETTLEMENT PRIORITY PROCESSING FOR AN ACCOUNT.
Settlement through Az.Account
Settlement priority can be triggered through TELLER/ FT/ DC application when the AZ.ACCOUNT
or Repay Account (when the customer has more than one AZ.ACCOUNT) is credited with the
LOAN.REPAY transaction code as mentioned in the APP.
The appropriation of amount using settlement priority is explained with the following workflow
Settlement Processing with Credit to AZ.Account
Credit to AZ.ACCOUNT
With LOAN.REPAY
Transaction code through
TELLER/ FT/ DC
Priority Rules Repayment Types
AZ.SETTLEMENT.PRIORITY Level 1 AZ.AMOUNT.TYPE/

AZ.ACCOUNT DATE

All in One Account
If No Matching Account in
ASP –move to Next Level
AZ.AMOUNT.TYPE/
AZ.SETTLEMENT.PRIORITY Level 2 DATE/
CUSTOMER PRODUCT
If No Matching Cust in ASP–
move to Next Level

PRODUCT DATE
If No Matching Product in ASP
–move to Default
AZ.AMOUNT.TYPE/
SYSTEM (Default) PRODUCT
Any Surplus after
Settlement Process
SURPLUS Credit to REPAY.ACCOUNT
Work flow of Settlement processing for an AZ Account.
Example for settlement through AZ.ACCOUNT
AZ Product with repayment type as Annuity is created with PD.LINK.TO.AZ as No’ so to create
overdue records in case of default in repayment. The LOAN.REPAY transaction code ’493’ is added to
process settlement priority. To create PD record instead of Overdues, set the PD.LINK.TO.AZ as
‘Yes’.

All in One Account
PRODUCT WITH LOAN REPAY TRANSACTION CODE FOR SETTLEMENT PRIORITY

PROCESSING
Add a record in TELLER.TRANSACTION with the LOAN.REPAY transaction code as given in APP
to trigger Settlement Priority process. In this case TRANSACTION.CODE.2 is created with code ‘’493’.
TELLER TRANSACTION CREATED WITH LOAN REPAY TXN CODE
To process settlement priority, an AZ Loan Account 37818 is created with repayment type as
ANNUITY and it has following schedules due as on 22 October & 29 October.

All in One Account
AZ.ACCOUNT 37818 SCHEDULES FROM AZ.SCHEDULES
Since the balance in not available in the repayment account and at the product level PD.LINK.TO.AZ
set to “No”- AZ.OVERDUE file is updated for the AZ Account with following details and sub account
(xxxxx) is debited towards overdue interest of USD 833.33.

All in One Account
OVERDUE DETAILS FOR 37818
In case the PD.LINK.TO.AZ were set to “Yes”, a record would have been created in PD application
with the appropriate details.
For AZ.ACCOUNTS which have created an AZ.OVERDUE record the following procedure is
followed:
On 30th October the Customer repays through TELLER USD 200,000,000 against the outstanding of
USD 168413.80 and amount to be adjusted as per the settlement priority created for the Account
37818
SETTLEMENT PRIORITY DEFINED FOR AN ACCOUNT (LEVEL 1)

All in One Account
TELLER TRANSACTION TO THE CREDIT TO AZ.ACCOUNT
In AZ.OVERDUE Application, the outstanding principal as on 22 October is reduced ZERO since the
second level priority is oldest due date, the remaining amount is adjusted towards principal due on 29th
October & overdue file is updated accordingly.
Repayment Methods Details Amount

Amount Remitted 200,000.00 a
OD.PR & Date 22 Oct 168413.80 b
Remaining Amount (a-b) 31586.20 c
OD.PR & Date 19 Oct 164396.21 d
Outstanding after adjustment - OD.PR 132810.01 (d-c)
Over due file after update
OD.PR 14 Feb 132810.01
OD.IN 07 Feb & 14 Feb (Sub Acct 36122) 6895.89
Total Outstanding 139705.90

Settlement priority processing – break up details

All in One Account
OVERDUE DETAILS AFTER REPAYMENT TO AZ.ACCOUNT

In AZ.ACCOUNT, the principal is reduced to the extent of USD200,000.00
TRANSACTION DETAILS OF AZ ACCOUNT AFTER REPAYAMENT
The settlement priority processing is similar to above for Customer / Product settlement priority. In
case matching record is not available in any of the above 3 levels, then processing is based on default
“SYSTEM” record.
Settlement through REPAY.ACCOUNT

When a customer has more than one AZ accounts and all the accounts has common repayment
account, in such cases instead of settling the AZ account one by one- the customer can credit the

All in One Account
amount directly to the common repayment account and system appropriates the amounts to the AZ
accounts as per the settlement priority definition.
When a AZ repayment account is credited with LOAN.REPAY transaction code, then all the AZ
accounts linked to the repayment account is taken from AZ.REPAY.ACCOUNT and AZ.ACCOUNT
which matches with the best fit record for the combination of AZ.ACCOUNT/ CUSTOMER/
PRODUCT is processed first and this loop goes on till the repayment amount is fully used or
processed all the AZ.ACCOUNTS. In case any of the above combination is not available, processed
as per the default record. Any surplus remains after above adjustment are moved to the common
Repayment Account.
Settlement Processing with Credit to AZ REPAY.ACCOUNT
Credit to REPAY.ACCOUNT
With LOAN.REPAY
Transaction code through
TELLER/ FT/ DC
Get List of AZ Accounts from

AZ.REPAY.ACCOUNT
Processes first best Fit in the

following case

AZ.ACCOUNT DATE
If No Matching Account in
ASP –move to Next Level
AZ.AMOUNT.TYPE/
CUSTOMER PRODUCT
If No Matching Cust in ASP –
move to Next Level

All in One Account
AZ.SETTLEMENT.PRIOIRTY Level 3 AZ.AMOUNT.TYPE/

PRODUCT DATE
If No Matching Product in ASP
–move to Default
AZ.AMOUNT.TYPE/
SYSTEM (Default) PRODUCT
Any surplus move to next best
fit AZ Acct from
AZ.REPAY.ACCOUNT
Find next best fit from
SURPLUS AZ.REPAY.ACCOUNT
(Go to Level 1)
Any Surplus after Processing
all AZ Accounts
SURPLUS Credit to
REPAY.ACCOUNT
Work flow details for priority through Common Repayment account.
Example for Settlement priority through common AZ Repay Account
In the following example, Account 37834 is used as Repayment Account in following

AZ.ACCOUNTS.
LIST OF AZ ACCOUNTS USING 37834 AS REPAYMENT ACCOUNT

All AZ.ACCOUNTS belong to Customer 1003 and are account numbers 37842, 37858 and 37869.

All in One Account
Settlement priority is defined at account level (for A-35734 to process OD.PR & OD.IN)
SETTLEMENT PRIORITY DEFINED FOR THE ACCOUNT
Following over dues are there which are to be processed through common repayment settlement
priority.
OVERDUE DETAILS FOR ACCOUNT 37842

All in One Account

All in One Account
Against the total outstanding of USD 137697.46, customer remits USD 136,000.00 towards settlement
in common repayment Account.
CREDIT TO AZ COMMON REPAYAMENT ACCOUNT THROUGH TELLER
The amount paid in repayment account is appropriated as per the following on authorising the Teller
transaction.
Repayment Details Amount

Methods
LEVEL 1 Outstanding details
ASP -Account A-37842
OD.PR 127585.87
OD.IN 3370.53
LEVEL 2
ASP -Account A-37858
OD.IN 3370.53

All in One Account
LEVEL 3
ASP –Account A-37869
OD.IN 3370.53
Total 137697.46
Amount Remitted to Teller -Acct 37834 136000.00
Adjustment details:-
LEVEL 1 Adjusted towards AZ-37842 (OD.PR) 127585.87
OD.IN 3370.53
Remaining 5043.60
LEVEL 2 Adjusted towards AZ-37858 OD.IN 3370.53
Remaining 1673.07
LEVEL 3 Adjusted towards AZ-37869 OD.IN 1673.07
Remaining 0.00
Over due Details after Above transaction
AZ-37842 0.00
AZ-35585 – OD.PR 127585.87
AZ-35869 -OD.PR OD.IN 129283.33
Appropriation details for repayment made through AZ Repayment Account.
The overdue file created for account 37842 is deleted and for account 37858 the principal only is
outstanding in AZ.OVERDUES. For account 37869 AZ.OVERDUE is updated with the revised
overdue due details

All in One Account
OVERDUE DETAILS FOR ACCOUNT 37869 AFTER REPAYMENT

For AZ.ACCOUNTS which have created a PD record the above procedure is followed with the
exception of that the missed repayment amount will create during the COB a PD record for the PR, IN
and PE. The AZ.SETTLEMENT.PRIORITY rules are the same for repayment of PD records. These
can be made via TELLER, FT and direct through the AZ.ACCOUNT and will reduce the PD
balance on line. If the PR record has been moved to NAB the repayment to the REPAY.ACCOUNT will
reversal entries that have been passed to SUSPENSE
Suspension of Interest on AZ loans when PD turns NAB
For settlement through TELLER/FT

The repayment can be made through TELLER/FT as a cash or transfer transaction
The special transaction code meant for loan repayment as defined in AZ Product parameter has to be
used in TELLER/FT through a version. (In these test cases it is 76)
The system would understand from the transaction code that the remittance is subject to
settlement priority.
Remittance through AZ.ACCOUNT:
The following fields of AZ.ACCOUNT are used for remittance made directly to the AZ.ACCOUNT:
REPAY.AMT
REPAY.V.DATE
In this case also, if the transaction code passed in meant for settlement priority as defined in the
AZ.PRODUCT PARAMETER, (76) then the online settlement appropriation process as per rules
would happen.

All in One Account
LOAN REPAY
The repayment made to the AZ loan through any channel as mentioned above is appropriated as per
the rules defined in the settlement table automatically and accounting entries are raised. At that time
the online accrual rules like last day inclusive, etc. will be taken into account. The user will define the
settlement priority in AZ.SETTLEMENT.PRIORITY table.
Case 1 – Automatic Settlement per the settlement priority rules
Any COB appropriation would happen only per the rules defined in AZ.SETTLEMENT.PRIORITY
table.(As specified above in AZ.SETTLEMENT.PRIORITY)
When a payment from the borrower is processed online (using either TELLER or FT), system would
default the amounts to be appropriated based on the rules defined and should there be no user
intervention, accounting would happen based on the amounts so defaulted.
If the amount remitted were more than the aggregate dues of all the loans of the customer, the
residual amount would be credited back to the repayment account.
Backdated settlements – NO backdated payments will be allowed in AZ with PD link per

All in One Account
If underlying PD is PDO – beyond the last EVENT date in the PDAZ or last capitalisation
date in AZ, whichever is later.
Back Dated Rate Change

The change of rates beyond last capitalisation date has been a universal requirement and has been
provided for, for greater flexibility to the ultimate user.
ACCOUNTING: -
Back dated rate change will affect both the interest capitalisation and accruals. For a/c “X” –assume 2
capitalisations have taken place and accruals say has run for 10days. The amounts are as below: -
10.01.04 Capitalised @10% 1500.00

10.02.04 Capitalised @ 12% 1700.00
18.02.04 Accrual at 12% 500.00
The entries for the above would have already taken place in the following manner
“X” a/c DR. 1500.00 (Cap) 10.01.04

Re.consol.Spec 1500.00
CR
“X” a/c DR. 1700.00 10.02.04

(Cap)
Re.consol.Spec 1700.00
CR
Categ Entry –Cr 500.00 18.02.04

(accrual)
Re.consol.Spec- 500.00
Dr
Now, on 18.02.04- the rate is changed to 25% The value date of the above loan a/c –at the new rate
the interest amounts would be
Date Revised Already Difference
interest capped
@25%
10.01.04 Capitalised @10% 2300 1500.00 800
10.02.04 Capitalised @ 12% 2150 1700.00 450
18.02.04 Accrual at 12% 700 500.00 200

All in One Account
The system would pass entries ONLINE with respective value dates for the already capitalised
entries for the difference amount and would adjust the accrual as part of the COB (close of Business).
The structure of entries would as below
“X” a/c DR. 800.00 (Cap) 10.01.04
Re.consol.Spec CR 800.00 [ONLINE] Difference amount
“X” a/c DR. 450.00 (Cap) 10.02.04

Re.consol.Spec CR 450.00 [ONLINE] Difference amount
Categ Entry –Cr 200.00 (accrual) 18.02.04

Re.consol.Spec- Dr 200.00 [COB] @Difference amount
FLOW CHART:->>
BACK DATED RATE

CHANGE (beyond last capitalisation)
LOAN TYPE
ANNUITY LINEAR,
NON-Redemption
OTHERS
NO YES

All in One Account
Check INTEREST TYPE
Fixed Fixed Floating

BI key
NO
YES
Accounting for INTEREST

ADJUSTMENT
YES
Already Capitalised Interest Interest under Accrual
ONLINE AT COB
END
On the contrary if the rate of interest were lower than the earlier defined rates – the system would
pass the reversal entries to the one stated above.
SETUP
There is no specific set-up enunciated for the back dated rate change. However, the set-up regarding
the transaction codes needs to be followed as enunciated under.

All in One Account
.SETTING UP OF TRANSACTION CODES IN AZ.PRODUCT.PARAMETER
Note: - The setting up of Transaction codes is mandatory. Loan repays, loan drawdowns are
termed as events and the system permits transaction codes akin to the nature of these events.
For ex:- loan repay is a credit transaction and hence can’t take a debit transaction code and vice
versa. The exception to the above is the following events and txn codes.
Int. Dr. Cap 391 The TXN code should be set as 391 ONLY
Int. Cr. Cap 381 The TXN code should be set as 381 ONLY
Int.Corr.Txn # # A multi value field and should be multivalued to
set up txn codes 385, 395, 405 and 386. This set
up is mandatory.
The back dated and forward dated (for fixed rate type) rate changes could be affected only through “R”
schedules. Of course, if a BI key is defined the forward dated changes can be stipulated via BI key
itself followed by date.
To exemplify: -

All in One Account
Set-up a limit and attach the a/c 22007335 to the above APP.

All in One Account
AZ. ACCOUNT 22007335 IS ATTACHED TO APP RATE-CHANGE
The rate prevailing on the above a/c is 14%
The ACCOUNT.DEBIT.INTEREST or ADI record will look as below

All in One Account
ADI RECORD OF AZ. ACCOUNT 22007335
The interest amounts of USD388.89, 375.07 and 361.25 were capitalised for the dates 30th, 31st Dec
and 1st Jan.
In the a/c 22007335- a change in rate of interest of 35% (fixed) is input with effect from 2.12.2000 is
input as shown below

All in One Account
RATE CHANGE MADE TO AC NO..22007335
WHEN A RATE CHANGE IS MADE – TERM PRIORITY SHOULD BE EITHER YES OR NO
Note: - If Yes – the term of the loan a/c will be constant and any changes due to change in rate
will be adjusted to the instalments/annuity to be paid. If no. Then the instalment/annuity will be
constant and change in rate will result in period or maturity date of the loan contract being
extended.

All in One Account
TERM PRIORITY IS FLAGGED AS YES

The maturity date remains the same but the repayment amounts have been amended.
THE MATURITY DATE REMAINS THE SAME
Immunity list
If the product of underlying AZ contract has PD.LINK.TO.AZ as "" or "YES", backdated rate
change is permitted only for the current Interest period ie after last capitalisation date.
For fixed-floating type of interest rates - back dated rate change is permitted up to the last
capitalisation date ONLY.
Back Dated Principal Repayment

The model of BACK DATED PRINCIPAL REPAYMENT beyond last capitalisation date for loan
products has been introduced.
The concept of back dated “Principal” repayment is triggered in two ways (1) through AZ repayment
field and (2) using the specific txn code i.e. PRINCIPAL.TXN, in applications like TELLER or
FUNDS.TRANSFER. The code for each of the activity is set in AZ. PRODUCT.PARAMTER and
is mandatory input.

All in One Account
For the above options the “value date” holds the key. The date input in the value date field will be the
effective date of such back dated repayment.
IMMUNITY LIST
For ANNUITY and NONRED type of repayment - backdated principal repayment is permitted only for
the current interest period ie after last capitalisation date.
ACCOUNTING: -
Back dated “PRINCIPAL” repayment will affect both the interest capitalisation and accruals. For a/c
“Y” –assume 2 capitalisations have taken place and accruals say for 10days have been done. The
amounts are as below: -
10.01.04 Capitalised @10% 1500.00

10.02.04 Capitalised @ 12% 1700.00
18.02.04 Accrual at 12% 500.00
The entries for the above would have already taken place in the following manner
“X” a/c DR. 1500.00 (Cap) 10.01.04

Re.consol.Spec CR 1500.00
“X” a/c DR. 1700.00 (Cap) 10.02.04

Re.consol.Spec CR 1700.00

Re.consol.Spec- Dr 500.00
Now, on 18.02.04- a back dated PRINCIPAL repayment is made of 100000 i.e. w.e.f. 01.02.04.
Owing to this the amount of interest –at the new principal amount would be
Date Revised Already Difference

interest capped
@25%
10.01.04 Capitalised @10% on 300000 – now 2300 1500.00 800$
recast amount is 200000 –due to
(With PR @
back dated repayment.
200000)
10.02.04 Capitalised @ 12% 2150 1700.00 450#

All in One Account
18.02.04 Accrual at 12% 700 500.00 200@
The system would pass entries ONLINE with respective value dates for the already capitalised
entries for the difference amount and would adjust the accrual as part of the COB (close of Business).
The structure of entries would as below
“X” a/c DR. 800.00 (Cap) 10.01.04

Re.consol.Spec CR 800.00 [ONLINE] $Difference amount
“X” a/c DR. 450.00 (Cap) 10.02.04

Re.consol.Spec CR 450.00 [ONLINE] #Difference amount

Re.consol.Spec- Dr 200.00 [COB] @Difference amount
On the contrary if the rate of interest were lower than the earlier defined rates – the system would
pass the reversal entries to the one stated above.
BACK DATED REPAYMENT

(Beyond last capitalisation)
LOAN TYPE
ANNUITY LINEAR,
Non-redemption &
OTHERS

All in One Account
NO YES
CHECK
INTEREST TYPE
Fixed, BI key and

Fixed Floating type
YES
Accounting for INTEREST

ADJUSTMENT
YES
Already Capitalised Interest under

INTEREST ACCRUAL
AT COB
ONLINE
END
SET UP
The setting up of TXN codes is again mandatory. However, back dated repayment is not permitted for
“non-redemption” type, hence, setting up of loan repayment transaction in
AZ.PRODUCT.PARAMETER is not permitted.

All in One Account
FOR A NON REDEMPTION TYPE WHEN LOAN REPAYMENT IS INPUT”ERROR” IS RAISED
Note: - The setting up of Transaction codes is mandatory. Loan repays, loan drawdowns are
termed as events and the system permits transaction codes akin to the nature of these events. For
ex:- loan repay is a credit transaction and hence can’t take a debit transaction code and vice versa.
The exception to the above is the following events and txn codes
Int. Dr. Cap 391 The TXN code should be set as 391 ONLY
Int. Cr. Cap 381 The TXN code should be set as 381 ONLY
Int.Corr.Txn # # A multi value field and should be multivalued to set
up txn codes 385, 395, 405 and 386. This set up is
mandatory.
To illustrate
As related earlier, the process of back dated repayment can be achieved either through AZ
ACCOUNT and /or through applications like TELLER and FT using the “PRINCIPAL.TXN” code
AZ. PRODUCT.PARAMETER – LBTFLOAT is linked to AZ. ACCOUNT 35858

All in One Account
AZ. PRODUCT PARAMETER WITH TXN CODES

All in One Account
AZ.ACCOUNT 22007351

All in One Account
CATEG ENTRIES PASSED TO THE A/C 22007351 BEFORE THE BACK DATED REPAYMENT.
Deposits
Define Product Parameters (AZ.PRODUCT.PARAMETER)
AZ Deposit Products
The product parameters are defined in the AZ.PRODUCT.PARAMETER application. This
application allows for the input of product characteristics that are common to a group of deposit
accounts.
A product parameter record is required in order to use AZ.ACCOUNT.
There are two basic products available in this module, viz. FIXED and SAVINGS PLAN. The deposit
type is defined in the REPAYMENT.TYPE field of AZ.PRODUCT.PARAMETER.
Defining parameters
Each product may be allocated a specific category within the allowed range.
For the purpose of defaulting interest rate to the deposit accounts, the key of PERIODIC.INTEREST
can be specified in the Parameter. Further more, it is possible to define a method of selecting
previous, next or interpolation of interest rates. In the case of pre mature closure of deposit, the
interest for the redeemed deposit for the period for which it has run can be referred to the periodic
interest table at the time of opening the deposit or the current table.

All in One Account
It is possible to define the frequency for crediting interest (either to the Interest Liquidation account
defined in the Account record or to the deposit account itself if no liquidation account is specified), by
using the field CR.INT.FQU. It is possible to define interest credit based on Anniversary or Calendar
method under CR.INT.TYPE.
By opting Schedules as ‘Y’, the credit interest frequency will be populated from the Parameter to the
AZ deposit account.
It is not advisable to create a back dated deposit on an existing account with a balance and a different
category previously. The accrued amount in that account till that day will not get reversed out.
AZ.DEPOSIT PARAMETER OF TYPE FIXED
Maturity Process
The maturity instruction for Fixed Deposit can be defined in the Product Parameter under
MATURITY.INSTR. It is possible to define Automatic Rollover or Payment to Nominated account, so
that all accounts opened under this product will have this maturity process.

All in One Account
If the deposit account is to be rolled over for an amount different from the maturity amount, the amount
has to be specified under ROLLOVER.AMT of AZ.ACCOUNT. If the rollover amount is different from
the deposit amount (less or more), the differential amount will be adjusted in the nominated account.
If no maturity instructions are defined and if the deposit account is matured the status of the account
will be treated as Overdue and accounted under the category defined in Product Parameter under
OD.CATEGORY.
The fields ROLL.INT.CAP.FQU and ROLL.INT.PAY.FQU in AZ.ACCOUNT are used to define

interest schedules for a Fixed Deposit after a rollover has taken place by inputting the frequency in
them. The following values are permitted Dnn, Wnn and Mnn.
AZ.ACCOUNT
Early Redemption
Fixed Deposits and Savings Plan deposits can be redeemed before maturity. In the case of FIXED
type of deposit, part closure is also permitted. For early redemption of part or full amount, the eligible
interest is calculated based on the period run, by referring to the deposit, as defined in the
PERIODIC.INTEREST relating to the current period or the one relating to the date of opening of
Product Parameter. The differential interest will be collected along with the pre-closure fee defined
under Product Parameter.
These charges will be debited only if the pre-closure of the deposit is done by using the
AZ.ACCOUNT. For withdrawals made through other channels like TELLER or ATM, the system will
not recognize them as pre closure and charge the differential interest and charges. In these cases, the
pre-closure fee and differential fee are to be debited manually.
Late Payment Fee
For Savings Plan type of deposits, late payment fees can be defined in AZ PRODUCT
PARAMETER for delayed payments. The number of instalments after which the late fee has to be
reckoned also can be defined in parameter under LIAB TO PENALTY
When applying the fee the system would try to debit the REPAY.ACCOUNT. If REPAY.ACCOUNT has
insufficient funds or no REPAY.ACCOUNT is given then the system would create a FT on hold.

All in One Account
Fixed Floating Deposit Type

The flexibility of AZ has prompted in designing a new line of product called FIXED FLOATING type.
This new product that has been included in AZ.PRODUCT.PARAMETER has few distinguishing
features that separates it from the customary AZ products.
This product enables the user to define FIXED rate of interest up to a particular period and FLOATING
rate of interest for the remaining period.
For Example: - a 36-month deposit would look like this in a FIXED-FLOATING type.
Fixed and Floating rate deposit period
In AZ we already have the facility to define a percentage on the AMOUNT of deposit to attract FIXED
interest and the remaining amount to have a FLOATING rate.
But in FIXED-FLOATING type it is the PERIOD of deposit that is SPLIT into fixed rate and floating rate
and not the amount, as was the case earlier.
A combination of FIXED + BI and PI + BI is definable but not FIXED + PI. The PI +BI combination is
not permitted for customary AZ products. It is opened up to accommodate the FIXED-FLOATING type.
Features of FIXED-FLOATING
√ Initially the deposit takes fixed rate of interest for a specified period. Floating rate for the remaining
period of the deposit till maturity.
√ “R” schedule is introduced for the FIRST time in AZ deposit product-to trigger floating rate in a
FIXED-FLOATING deposit.
The Floating rate is triggered into account by way of “R” schedule at AZ.ACCOUNT level.
The “R” schedule trigger is in turn based on the input made in the field RATE.PERIOD in

All in One Account
In the above example, RATE.PERIOD input is 03M which means from the start date of the deposit up
to 3 months fixed rate (in the present case it is 5.5%) will be applied. From 3M +01day the floating
rate will be applicable which is triggered by an “R” schedule at account level populated from the

All in One Account
AZ.ACCOUNT
As the RATE.PERIOD is defined as 3M- the “R” schedule is slated for 2003/12/24 which +3M from the
start date of 2003/09/24.
The fixed and the floating rates are defaulted from the AZ.PRODUCT.PARAMETER.
User has the flexibility to change the fixed rate at the account level before authorising the record and
floating rate through INTEREST.RATE field of BASIC.INTEREST application, when necessary.
√ The RATE.KEY (Basic Interest-key) will be fixed. Change in rate can be administered by inputting a
new rate in the INTEREST.RATE field. The rate will be effective from the date appended to the BI
record ID.

All in One Account
BASIC.INTEREST
Any subsequent changes in the INTEREST.RATE field of BASIC.INTEREST key will be recorded in
the ACCOUNT.CREDIT.INTEREST (ACI) for future references.
√ “R” schedule is a MUST for fixed floating deposit and if the record is committed without an “R”
schedule it throws an error.
Field APPLICATION Description
RATE.PERIOD AZ.PRODUCT.PARAMETER Contains the no. of days

after which – it will trigger
the “R” schedule to
introduce change of rate to
floating.
If this field is input it is a
fixed-floating type. Or else it
is customary AZ product.
OVERRIDE AZ.PRODUCT.PARAMETER This field is used to store

any override. For ex., the
field RATE.PERIOD can’t
be > than the
MAXIM.TERM Field. In case
of such input the system
throws an override-, which is
stored in this field.
RATE.PERCENT AZ.PRODUCT.PARAMETER For Fixed-Floating type this

field should have value 100
(Revised
only - or else an error will be
definition
populated. For deposit types
modified if it is
other than Fixed-Floating it
fixed-floating)
can hold any value with a
maximum of 100.

All in One Account
Introduction of “R” Schedules for Deposits

“R” schedule was allowed only for AZ loans. Now it is introduced as a special feature in AZ FIXED-
FLOATING type of deposit. The insertion of “R” schedule was necessary to trigger the Floating rate of
interest in these types of deposits.
“R” schedule trigger and its frequency is based on the value input in the RATE.PERIOD field in
Changing the APP code during the life of an AZ.ACCOUNT FD.
It is possible to amend the APP using the field ROLL.AIO.PRODUCT during maturity of an FD. This
can be done during the life of the FD. It is also possible for the new APP to have a different
CATEGORY code. Once the deal has matured the new FD will inherit all of the characteristics of the
new APP. Error messages will be produced by the system if the new APP has different payment
instruction to the existing APP. This process is not available for APP with the following selected.
APP
Multi Deposits
It is possible to accept multi deposits under a single AZ.ACCOUNT i.e. the Main a/c. The multi
deposit concept has been developed for both Fixed deposits and Savings plan.
Multi Fixed deposits
For a Multi Fixed Deposit the field MULTI should be flagged as YES in
AZ.PRODUCT.PARAMETER (APP). When this product parameter is attached to an a/c it (the a/c)
will inherit all the characteristics of a Multi deposit. This is what distinguishes a multi deposit from an
ordinary AZ deposit.
Creation of Multi Fixed Deposit –Via AZ
BASIC SET-UP
The MULTI field in AZ.PRODUCT.PARAMETER (APP) should be flagged as YES

IF multi is flagged as YES – the ACCT.SYNC should also be YES. [Mandatory]
Set-upAC.AUTO.ACCOUNT application with “ID” equal to Category with which

AZ.PRODUCT.PARAMETER for multi deposits (both fixed and Savings plan) have been created.
If there is more than one category then each of the categories must be input in
AC.AUTO.ACCOUNT application.

All in One Account
In AC.AUTO.ACCOUNT application the INHERITED fields are optional. But certain fields like
interest liquidation account if input in AZ main a/c and needed to be populated at the sub a/c level then
the inherited fields should be input.
AC.AUTO.ACCOUNT
After the initial set-up, the creation of multi deposits can be either through AZ or through Non- AZ
mode like TELLER etc.
Set-up a AZ PRODUCT PARAMETER as shown below

All in One Account
Significant fields in APP:-
• The Field MULTI should be flagged as Yes
• The field PART REDEMPTION should be flagged as yes – if the particular AZ product has part
redemption as a feature. If input as “N” – then part redemption can’t be made on all those
accounts which has this AZ product parameter attached.
• For a –multi fixed deposit-the REPAYMENT TYPE field should be flagged as FIXED.
• MATURITY INSTRUCTIONS field–can be either Automatic rollover or Payment to nominated
a/c. If flagged as Automatic Rollover- then only ROLLOVER ACCOUNTNG field is opened.
• The field ROLLOVER ACCTNG can be input as either Yes or “ “. If input as Yes –the system
will do the accounting part even if roll over deposit and the principal are same. If “ “ accounting
will not happen if rollover of deposit and the principal are same. However, during roll over if
any addition or deletion to the principal is made–then accounting will happen to the extent of
such addition or deletion

All in One Account
• A new set of TXN codes relating deposits are opened up which are mandatory inputs.
Link AZ. PRODUCT. PARAMETER to account via AZ.ACCOUNT application
AZ.ACCOUNT
• The a/c so attached is the MAIN a/c and the principal will be ZERO for the same.
• In multi Fixed deposit Value date should be defined – while the maturity date is a “NO input”
when the repay type is “FIXED”
• In APP – product start and End date fields if input –then the Value dates of the AZ a/c should
fall within the dates.
• Defining Repay and Nominated a/c is mandatory.
• Calculation base should be input as “Principal”
CREATING SUB AZ A/C [Fixed]
In AZ Main a/c input the following fields: - [through teller is discussed under
separate heading]
The sub a/cs generated from the main AZ a/c or any other application will have
the AZ.PRODUCT.PARAMETER (APP) of the main a/c only- if can’t be
different or changed.
• For making a Deposit –field REPAY. AMT is input with the amount of
deposit.
• Input the Repay. V. Date and Mat. Date and commit the record.
• Maturity date is mandatory-Value date if not input will be defaulted to the
T24 date.
• The details of sub a/cs belonging to an AZ main a/c can be seen from
AZ. Active. Sub. Acc table

All in One Account
INPUT IN AZ. ACCOUNT BEING DEPOSIT AMOUNT
Sub A/c
The above inputs in the AZ Main a/c has created the sub a/c as shown in the below screen shot.
SUB A/C CREATED

All in One Account
• The customer, Category, Currency is populated from the Account.

• The amount, value and maturity dates are populated from the inputs made by us in the AZ
main a/c
The values in fields schedules, Repayment Type, Calculation Base etc is populated from application
Note:- At the time of creation of sub a/c – either through AZ main a/c or through
Non-AZ method-if the main a/c contains any DEBIT balance then creation of sub a/c
will be stalled till the debit balance is offset. To illustrate
Deposit is input for Dr. balance in Main AZ Sub a/c will be created
for amount
10000 USD –15000USD NO sub a/c will be
created the balance in
[Deposit 1]
main a/c will become
-5000 USD
11000 USD -5000 USD Sub a/c will be created
for only 6000 USD after
[Deposit 2]
adjusting the dr. balance
of –5000 USD
SCHEDULES
“I”, “N” and combined “IN” schedules can be input in case of Multi Fixed deposit. “I” schedules
frequency can be defined at APP level using CR. INT FQU field. If done this will be populated at the
AZ.ACCOUNT level. “N” schedule may be defined at the AZ main a/c level when inputting a fresh
deposit.
A new sub a/c is created whenever a deposit is made to the credit of the main AZ a/c and
consequently, the “I”,“N” and “IN” schedules will be populated at the sub a/c level. “I” schedule
capitalizes the interest and “N” schedules transfers the interest amount so capitalized to the credit of
Nominated a/c. If interest liquidation a/c is defined, the function of “N” schedules is redundant. “I” and
“N” can have different frequencies-but combined “I” and “N” will have only one single frequency. The
schedules can be viewed for each of the a/c using AZ.SCHEDULES application.
Part Redemption
THROUGH AZ MAIN A/C

At this point –before the maturity date the sub a/c created is subject to any of the following
Meaning: - Withdrawing a part of the deposited amount
either from one or more of the sub a/cs.
PART –REDEMPTION
This can be done in two ways
{Through AZ account}
(1) Either at AZ. Main a/c using the field
(a) Redemption Amount
[This is an Interactive process]
(b) Sub AZ Acct
OR
The customer can indicate his

All in One Account
choice of accounts, which need At the sub AZ acct level.

to be used for part-redemption
At main a/c level, one or more AZ sub accounts can be input
by multi-valuing the specified fields.
At sub a/c level only the amount can be drawn from that
particular AZ sub a/c.
[2] Through Non-AZ mode i.e. using Application TELLER.
[Dealt with separately]
AZ-MAIN A/C FOR PART REDEMPTION
In the above screen, shot- the AZ main a/c 22276 is input with a series of sub a/c’s with amount. The
account and amount indicates the interactive process by which the customer exercises his choice of
a/c and the amount as well. On committing the transaction, the system will deduct the amount so
drawn from the respective sub a/cs. The charges and penalty if any will be deducted either from the
redemption amount or from the principal after such redemption depending on the flag set in
CHG.FROM.RED.AMT field.
THROUGH AZ SUB A/c

In this case – (as per customer’s choice) a particular AZ sub a/c is selected and amount of part
redemption is specified in the REDEMPTION AMT field. As the part, redemption is made on the sub
a/c.
Some of the fields that go with the part-redemption process are tabulated below

All in One Account
Field Meaning
Additional Spread Based on customer group, accumulated balance etc. the spread is
calculated and populated in this field.- This is handled through
LOCAL Routines.
Chg from Red Amt It indicates whether charges are to be deducted from the amount
withdrawn or from the balance left in the sub a/c after such
withdrawal. [See help text of the field for further explanation]
Early Red int This is populated from EARLY.RED.MARGIN field of
AZ PRODUCT PARAMETER application.
Charge code, amt, date While permitting part, drawl or input of a fresh deposit – if any
charges are to be debited- then this field can be used.
If entered –Chq liq. Acct is mandatory- and the charges will be
debited to this a/c.
Pre-Closure
THROUGH AZ MAIN A/c
Meaning: - Complete closure of deposit before it attains the

maturity date. This can be either one sub a/c or all the sub a/c’s
PRE-CLOSURE
put together along with the main a/c.
OR
This can be achieved either through AZ a/c or through Non-AZ
process as Teller [Teller part is dealt with separately]
Before Maturity Closure
In AZ-, this can be accomplished either at the Main AZ a/c level or
at the Sub a/c level by flagging the field PRE.CLOSURE.IND as
“Y”. In the first case (Main AZ a/c) it amounts total closure of all
the AZ accounts while in the second case – it amounts to total
closure of that particular sub a/c only.
Main A/C

All in One Account
AZ. MAIN A/C –FOR PRE-CLOSURE
AZ. ACTIVE SUB A/C

Note: - AZ.ACTIVE.SUB.ACC application gives the list sub a/c’s that a main a/c
has.
In our present illustration – the main a/c 37524 has 3 sub a/c’s as listed above. Therefore, at the main
a/c level when the pre close indicator is set to “Y”– the system will close the entire sub a/c’s including
the main a/c.
SETTING PRE-CLOSURE INDICATOR AS ‘Y’

All in One Account
AZ. MAIN A/C IN HISTORY ON PRE-CLOSURE
NOTE: At the AZ main a/c level –the PRE.CLOSURE.IND is set to “Y” which leads to
closure of the entire sub a/c’s including the main a/c.
THROUGH AZ SUB A/C

To illustrate an existing AZ sub a/c 37526 is taken up for pre-closure. This is case of a particular sub
a/c being pre-closed.

All in One Account
AZ. SUB /AC
At the sub a/c level – the PRE CLOSURE IND field is input as “Y”
SETTING THE PRE-CLOSURE IND AS Y
The screen shot of pre-closed contract of 37526

All in One Account
AZ.SUB A/C 37524-PRE-CLOSED
Generally during pre closure of loan or deposit any charges in the grace period will be debited to the
repay account and not to the CHARGE.LIQ.ACCOUNT.
When we pre close a deposit through AZA then we apply the pre closure fee defined in APP. But if we
pre close through TELLER / FT then this pre closure fee will not be handled and that application
raising the entries will have to handle it.

All in One Account
AZ-Reversal
• In multi deposits –if a sub a/c is created through AZ.ACCOUNT application – then NO
REVERSAL is possible.
• In case the creation of AZ sub a/c is done via application like TELLER then reversal is
possible. This is done by simply reversing the underlying transaction provided events like part
redemption, accrual has not happened
Deposit Maturity
On maturity the AZ account may –either be rolled over if, the MATURITY.INSTR field in the AZ
Product Parameter application is automatic rollover
OR
Credited to Nominated a/c if the MATURITY.INSTR field in the AZ Product Parameter application is
payment to nominated account.
Multi Fixed Deposit –via Non-AZ
CREATION OF DEPOSIT/SUB A/C

Note: -TELLER application is selected for
illustration purpose.
The creation of AZ. Main a/c is a pre-requisite to the creation of sub a/c using application TELLER.
The other essentials are
• Application TELLER.TRANSACTION should be set up with the TXN code specified in the AZ
PRODUCT PARAMETER application. I.e. 494 for Deposit .Cr as shown below

All in One Account
TELLER TRANSACTION FOR AZ.DEPOSITS CR
Note: - In APP the deposit Cr is set with transaction code of 494. For the creation of AZ sub a/c in
teller application this TXN code need to be on the Cr. side to identify that the credit passed on is for
the creation of AZ sub a/c for deposit. If this TXN is not present then the system will throw an error –
TXN code XXX not in APP –Event can’t be identified.

All in One Account
TELLER INPUT-FOR CREATION OF AZ SUB A/C FOR DEPOSIT
On committing the above TELLER the system has created a sub account, a/c’s 22007346 as shown
below: -
SUB a/c –No.1

All in One Account
AZ.ACCOUNT
Multi FIXED deposit sub account creation is not possible through other applications apart from AZA
and TELLER, as we need the maturity date to be input while creation.
PART-CLOSURE
Prior to initiating the part closure of an AZ a/c through Teller, it is essential to set-up the following
• Application TELLER.TRANSACTION should be set up with the TXN code specified in the AZ
PRODUCT PARAMETER application. I.e. TXN code mentioned in field DEP. DR. PART as
shown below

All in One Account
SETTING UP OF TELLER TRANSACTION FOR PART CLOSURE
Note: How the Dep. Dr. Part txn code in APP is inscribed in
TELLER.TRANSACTION application-on the debit side as part redemption results in
DEBIT to the AZ deposit a/c
To illustrate the part closure procedure – the sub a/c i.e. 34386 is taken and a part withdrawal of 2000
using TELLER application and teller transaction of 200.

All in One Account
PART CLOSURE USING TELLER APPLICATION
After committing the same, verify

• Accounting entries –Dr. of sub a/c with the amount of redemption and Cr. to the nominated a/c
less any charges plus interest credit if any.
• See the balance in AZ sub a/c is properly accounted for after redemption.
Note: -Instead of sub a/c if main a/c is given- then it amounts to Pre-closure. In such a scenario-,
the sum total of all the sub a/c’s should be given to the exact amount. If the amount input is not
equal to the total of the sub a/c’s then error will be raised. . A suitable override “that all the a/c’s
will be closed” will be populated as a warning to the user.
PRE-CLOSURE
As recited earlier – the procedure for setting up teller transaction with the TXN code of field
DEP. DR. PRE. CLOSURE in APP should be set-up as shown below.

All in One Account
TELLER TRANSACTION FOR DEPOSIT PRE-CLOSURE
After setting up the teller transaction – Input a pre-closure transaction using teller application on AZ
sub a/c –

All in One Account
TELLER FOR PRE-CLOSURE OF DEPOSIT 22007346 (SUB A/C)
REVERSAL
Option to reverse an AZ deposit is possible only in case of use of Non-AZ application. Using the AZ
main a/c on the credit side of the teller application will create a sub a/c for the amount input. A simple
reversal of the teller transaction id will automatically reverse the AZ sub a/c so created.
Multi –Savings Plan
For a Multi Savings Deposit the field MULTI should be flagged as YES in
AZ.PRODUCT.PARAMETER (APP). When this product parameter is attached to an a/c, it (the a/c)
will inherit all the characteristics of a Multi deposit. This is what distinguishes a multi deposit from an
ordinary AZ deposit.
Creation of Multi Deposit (Savings Plan)
Basic set up

All in One Account
• The MULTI field in AZ.PRODUCT.PARAMETER (APP) should be flagged as YES
• IF multi is flagged as YES – the ACCT.SYNC should also be YES. [Mandatory]
• Set-up AC.AUTO.ACCOUNT application with “ID” equal to Category with which

AZ.PRODUCT.PARAMETER for multi deposits (both fixed and Savings plan) have been
created. If there is more than one category then each of the categories must be input in
AC.AUTO.ACCOUNT application.
• In AC.AUTO.ACCOUNT application, the INHERITED fields are optional. But certain fields
like interest liquidation account if input in AZ main a/c and needed to be populated at the sub
a/c level then the inherited fields should be input
Set-up a AZ product parameter as shown below

All in One Account
APP SET UP FOR SAVINGS PLAN

Significant fields in APP:-
• The Field MULTI should be flagged as Yes

• Field Credit Amt Multi can be either “Yes” or “ “. Input can be made only if the repayment type
is Savings Plan. “B” schedule amount is validated using the input made in Credit. Amount
field and the input in the Credit Amt. Multi- as detailed below

All in One Account
Credit. Amt. Multi- in APP Credit Amount -in Az. Account
Case (1) input as "Yes" Is Blank
Case (2) input as "Yes" Input as 5000
Case (3) left " " Input as 7000
Case (1)
Credit Amt. Multi field is Yes and Credit Amount field in AZ.ACCOUNT is blank-then the "B"
schedule amount can be input with any amount.
Case (2)
Credit Amt. Multi field is Yes- and Credit Amount field in AZ.ACCOUNT is input with say USD 5000 -
then "B" schedule amount can be credit amount (USD 5000) or multiples of credit amount (USD 10000,
15000 etc). But "B" schedule amount can't be LESS than the credit amount.
Case (3)
Credit Amt. Multi field is " " - and Credit Amount field in AZ.ACCOUNT is input as USD 7000- then
"B" schedule amount should be credit amount ONLY (i.e. USD 7000 only) and even multiples are not
permitted.
• “I” schedule is automatically populated from the AZ.PRODUCT.PARAMETER application. In
case of Savings plan the defining of “B” schedule is mandatory.
• The field PART REDEMPTION should be flagged as “N” if the REPAYMENT TYPE is Savings
plan.
• For a –multi Savings Plan-the REPAYMENT TYPE field should be flagged as SAVINGS-PLAN
• The sub a/cs generated from the main AZ a/c or any other application will have the
AZ.PRODUCT.PARAMETER (APP) of the main a/c only- if can’t be different or changed
• MATURITY INSTRUCTIONS field–can be Payment to nominated a/c-only if the repayment
type is Savings Plan.
• A new set of TXN codes relating deposits are opened up which are mandatory inputs.
Link AZ. Product. Parameter to account via AZ.ACCOUNT application

All in One Account
AZ.ACCOUNT OF SAVINGS PLAN
Feature of savings plan

In Savings Plan – whenever a “B” schedule is executed or whenever the a/c is used on the credit side
of an application i.e. teller, ft etc- the system creates a sub a/c.
Both the main as well as the sub a/cs will have a common maturity date- while in case of fixed
deposits –the main a/c doesn’t have a maturity date.
Each instalment or “B” schedule is treated as a separate fixed deposit and will have different value
dates –but will have a common maturity date.
On the defined “B” schedule dates – the system executes the “B” schedules at COB and a sub a/c will
be created by debiting the repay a/c for deposit.

All in One Account
Apart from “B” schedules direct input through other applications can be made to the credit of the AZ
main a/c- Presently this is not stopped.
Schedules like “I”, “B”, “N” and “IN” schedules can be defined at the AZ main a/c level. “B” schedules
for taking the deposits at frequent intervals called instalments, “I” schedules for capitalisation of
interest and “N” for transferring the same to the credit of the nominated a/c (to interest liquidation a/c –
if it is mentioned at a/c level)
To exemplify: -
In the above main a/c 22007367- “B” schedules have been defined from 20010102daily- that means
on the COB of 20010102 and subsequent days (frequency is daily) the system will debit the repay a/c
and create a new sub a/c as shown below
AZ SUB A/C CREATED ON B SCHEDULE FOR MAIL A/C
Enquiry on the repay a/c indicates that the “B” schedules amount have been debited at the COB
process as shown below

All in One Account
ENQUIRY STMT.ENT.BOOK OF REPAY A/C 20222
Part redemption
No part redemption is permitted in case of Savings Plan.
Pre-closure
THROUGH AZ A/C
Unlike fixed deposits pre-closure for savings plan is permitted ONLY at the AZ main a/c level.
Flagging the PRE.CLOSURE.IND field as “Y” at AZ main a/c level will perform Pre-Closure of all the
sub a/cs including the AZ main a/c.
THROUGH NON-AZ
• Pre-closure is a debit transaction on the deposit a/c.
• Hence, while forming the teller transaction the debit side of the transaction should be input
with the txn code input in field DEP. DR. PRE.CLOSURE at APP level

All in One Account
SETTING UP OF TELLER.TRANSACTION FOR PRE-CLOSURE
USING the teller transaction 300- and application teller – the sub a/c 22007368 is input on the debit
side as shown below

All in One Account
TELLER INPUT FOR PRE-CLOSURE OF DEPOSIT SUB A/C 22007368
This will push the AZ sub a/c 22007368 into history by removing it from the live file. Accounting
debiting the sub a/c and crediting the nominated will happen.
AZ. ACCOUNT HIST RECORD

All in One Account
Roll over of deposits
If the repayment type is Savings plan- then rollover of deposits is not permitted.
COLLATERAL
• The basic set-up and the applications input in establishing a collateral is detailed under the
collateral module. The screen shots indicate how a sub a/c can be attached as collateral and
the validations done when an attempt is made to draw the amount when the sub a/c is part of
the collateral.
COLLATERAL RIGHT APPLICATION

• Then in collateral in case of multi deposits the sub a/c may be inscribed as shown
COLLATERAL APPLICATIONS

All in One Account
The sub a/c 22007460 has a deposit amount of 1000 is collateralised. When the user tries to make a
part withdrawal the system will raise an override “Account 22007460, debit to collateral”
AZ DRAW IN CASE OF COLLATERAL

In any non-AZ transaction - transaction involves an AZ account but is not being done through
AZ.ACCOUNT - if the charges are debited to the AZ account itself, then the principle of AZ is
reduced to the extent of the charges. Moreover, the debit charge transaction code has to be the set up
in APP else the system would throw an error. To avoid this use the COMBINE.TXN related fields in the
TRANSACTION application to net off the amount.
Sub Account (AZ.ACCOUNT) Creation – through Clearing Credits

Presently, for AZ main accounts belonging to a AZ.PRODUCT.PARAMETER that has the multiple
deposits enabled as ‘yes’, sub accounts can be created as AZ deposits using TELLER, FUNDS
TRANSFER, AZ ACCOUNT etc. using the repay account. In the case of TELLER, it can be created by
way of cash remittance also. A development has been made for the creation of sub accounts through
the process of clearing. The sub accounts through clearing can be created either by way of direct
credit or by way of indirect credit methods.
For this purpose, the transaction codes defined in AZ.PRODUCT.PARAMETER should match with
the codes defined in the TELLER.TRANSACTION application.
In AZ.PRODUCT.PARAMETER, the first value defined in DEPOSIT.CR should be a credit

transaction to the AZ account and the rest has to be the codes relating to CHEQUE.COLLECTION.
Indirect Credit Method :
For the creation of clearing entries by way of indirect credit, ACCOUNT.PARAMETER has to be set.
After the creation of an AZ main account, when a teller transaction is input for credit to the AZ main
account, cheque collection record will be generated.

All in One Account
CHEQUE COLLECTION RECORD
When the status of the cheque is changed to Cleared, a sub account will be created with the value
date and the maturity date as input in the teller transaction. If the status is changed to Return, no sub
account would be created, but the entries generated alone will be reversed. Entries generated at the
for the clearing transactions at different status would be as tabulated below:
Cheque Status Statement Entries
Deposited Clearing suspense account Debit

Clearing suspense account Credit.
Cleared Clearing suspense account Debit

AZ sub account Credit
Returned Clearing suspense account Debit

Return suspense account Credit.
CLEARING ENTRIES – INDIRECT CREDIT
For instance; when a teller transaction is input for crediting AZ account with 25000 through clearing.

All in One Account
CHEQUE COLLECTION RECORD

When CHQ.STATUS of the CHEQUE.COLLECTION record is deposited, the entries generated
would be as follows:
ENTRIES - DEPOSITED STATUS

When the CHQ.STATUS is changed to Cleared,
ENTRIES - CLEARED STATUS

The sub account so created, will contain the VALUE.DATE and MATURITY.DATE as defined in the
TELLER and as it appears in the CHEQUE.COLLECTION record.

All in One Account
AZ SUB ACCOUNT
When the CHQ.STATUS is changed to Returned,
ENTRIES - RETURNED STATUS
Direct Credit method:
In the case of Direct Credit, instead of ACCOUNT.PARAMETER, CQ.PARAMETER should be set

and the same values should be defined in AZ.PRODUCT.PARAMETER (as in the case of indirect
credit)
CQ.PARAMETER - SET UP
Note: No values should be defined in the field DEF COLL SUSP in CQ.PARAMETER
The cheque deposit transaction code (example 94) defined here, should not be present in the
ACCOUNT.PARAMETER
The Entries that would be passed at various status changes in the CHEQUE.COLLECTION record
would be as tabulated below:
Cheque Status Statement Entries
Deposited Clearing suspense account Debit

Sub account Credit.
Cleared No entries would be generated.
Returned Sub account Debit

Return suspense account Credit.

All in One Account
In the case of direct credit, when the status is changed to returned, the sub account created when the
record is in deposited status would be automatically closed and moved to AZ.ACCOUNT.HIST file.
Referring to the above instance itself, when a teller is input for credit to AZ account, and the
CHQ.STATUS of CHEQUE COLLECTION record is Deposited, the entries generated would be
ENTRIES - DEPOSITED STATUS
When the CHQ.STATUS is changed to Cleared, no entries will be generated, as the credit has already
been passed to the sub account. When the CHQ.STATUS is changed to Returned, the entries will be
reversed.
ENTRIES - RETURNED STATUS
The sub account created, while the record is in deposited status would be closed and moved to history
records.

All in One Account
SUB ACCOUNT MOVED TO HIST
When the CHQ.STATUS of CHEQUE COLLECTION record is Deposited / Clearing, no partial

withdrawal or pre-closure of the deposit made out of the CHEQUE.COLLECTION can be made. It
gives an error.

All in One Account
ERROR - PARTIAL WITHDRAWAL- CHQ STATUS IN DEPOSITED / CLEARING
When the TELLER transaction is reversed after the creation of CHEQUE COLLECTION record / sub
account, the entries are reversed and the CHEQUE COLLECTION record and the sub account thus
created are moved to hist files.
CHQ.STATUS (cheque status) can be changed through CHEQUE.BATCH, CHEQUE.CHANGE and

CHEQUE.COLLECTION. In a similar way, the value date and exposure dates can also be changed
through the above applications. (for more details refer the user guide on CHEQUE.BATCH,
CHEQUE.CHANGE and CHEQUE.COLLECTION)
Creation of sub accounts through clearing (direct / indirect credit) can be done through multi value
TELLER also. For creating a multi value TELLER, in the TELLER.TRANSACTION side 1 should be
defined with the details that has to be multi valued. (For more details on multi value TELLER, refer to
the user guide on Multi Value TELLER).
For the sub accounts created by way of direct credit, no I schedule or N schedules should get
executed.
When the deposit is opened with a BASIC.INTEREST key or a PERIODIC.INTEREST key, the
sub account created will contain the interest rate as is applicable for the date defined in value date.
For example if the basic rate is defined as 6% for 3/2/03, 7% for 5/2/03, the sub account created with
value date will have the interest rate of 6% and the one created on 5/2/03 will have the interest rate of
7%. Similar is the case with periodic interest also. (Presently, this feature is not supported)
Credit Card
The Credit Card linked loan product has been introduced through the AZ module.
The standard credit card operations like allowing draw downs using varied channels like ATM,
member establishments, raising of Bills, getting repayment applying penalty in case of non/part
payment have all been put together under this loan product.
The concept of sub account has also been introduced to handle the different draw downs made under
Credit Card and the different interest rates governing such withdrawals.

All in One Account
The PD link to AZ has been introduced to handle the concept of “PD” when partial re-payments are
made under Credit Card.
Flow to Credit Card
Flow to Credit Card
STOCK.PARAMETER
The application presently accepts CHQ, BCHQ, DRAFT, FDR and CARD.

All in One Account
STOCK.ENTRY
The application has been built to handle stock management, and permits stocking of both numbered
and blank stocks.
STOCK REGISTER
A live file is updated with total stock available for an “ID”. The stocks are listed based on the
STOCK.PARAMETER.ID *STOCK REG.ID.
For further details on stock related matters, refer to user guide on Cheque Issue and Management.
Card.Management
Card.Type
The credit card can be defined as a card type. Some of the characteristics of the card can be defined
here. Here the types of card that is available for issue is set-up. A new card type like AMX1 can be set
up as shown in the screenshot below.
CARD.TYPE
CARD.STATUS: The application is used for defining various card statuses like Issue, Re-issue,
Scrapped etc which are hard coded as 90-Issue, 91-Re-issue, 92-Scrap and 93-Cancel.
CARD.ISSUE: This application is the first step towards issuance of card to a customer.
For detailed info on the Card management set up, please refer the user guide on card.

All in One Account
Sub- ACCOUNT in AZ
Sub ACCOUNT Set-up
The concept of multi-loans is introduced under module AZ. The concept of sub account is used in the
AZ module for creating credit card withdrawals as multiple loans under one CARD account. Each sub
account will have an AZ loan contract attached to it, which has its own principal, interest rate, charges
etc.
For creating a sub account, it is important to set up the AC.AUTO.ACCOUNT application with “ID”
equal to a valid category.
Before creating the AZ. Account it is essential to set up the AC.AUTO.ACCOUNT application with
an id equal to category with which different products in AZ.PRODUCT.PARAMETER is created.
Only the categories of those AZ product parameters having REPAYMENT TYPE field as Credit Card
and fields MULTI and ACCT.SYNC as YES need to be inscribed in the AC.AUTO.ACCOUNT.
To Exemplify
If for example 1150 is the category of the AZ product parameter for which a sub account needs to be
created, then in the AC.AUTO.ACCOUNT application a record with id equal to 1150 should be
created as shown in the screenshot below.
SUB ACCOUTN SET UP
When the AZ product parameter with the above category is attached to an a/c called AZ MAIN a/c,
any draw down made will create an AZ SUB a/c. If 5 draw downs are made then there will be 5 distinct
sub a/cs and PRINCIPAL field of the sub a/c’s inscribed with amount so drawn.
The PRINCIPAL field in AZ main account will always be ZERO and the MASTER account field of sub
account created will be populated with the AZ main account number. The drawdown procedure and
the methods of drawdown and repayment are dealt with separately.

All in One Account
Apart from the Set-up, draw down is the trigger to the creation of AZ sub a/c. Now when a draw down
is made – the system reads the APP code in a/c – looks up APP record to see if REPAYMENT.TYPE
is CREDIT.CARD, verifies that field MULTI and ACCT.SYNC as YES-then a sub a/c is created.
The Drawdown is made on the AZ MAIN account only using the drawdown field. Drawdown can also
be made through any of the applications like Teller/FT etc
For set-up and other related matters on sub account, refer to the user guide on sub-account under
Core.
Limit Set-up
Create a limit for the customer whose account will be attached to AZ. Attach the limit to the account in
the field LIMIT.REFERENCE.
Limit creation for customer 1002

All in One Account
LIMIT SETUP
Attaching LIMIT to Account:
ATTACHING LIMIT TO ACCOUNT
Make a card issue to the account:

All in One Account
Card.Status must be input as 90 for card

issue.
When Issue date is entered the expiry
date is automatically populated.
The original repay date and billing close
will be populated with the dates and will
cycle forward until the next frequency.
CARD ISSUE TO ACCOUNT 37354
It is now possible to allow the Billing Close date and the Repay date to fall on the same day after the
first cycle of the CARD.ISSUE. The validation "Bill close and Repay date should not be on the same
date" will be triggered only for the first time when the card issue is input with the Bill Close and Repay
on the same date. Otherwise it will allow the repay and bill close to be on the same date. The same
validation is to be triggered if repay date frequency is " monthy".

All in One Account
The APP is set for card type AMX1.

APP needs to be set for revolving,
Non-revolving and Ranged Rev etc.
AZ.PRODUCT.PARAMETER SETUP FOR CARD AMX1
Additional fields AZ.PRODUCT.PARAMETER
Field Name Field definition/utility Permitted Input

LOAN. DEPOSIT For CREDIT CARD it is ONLY LOAN Loan or Deposit- Only
Loan
MINIMUM.ACCOUNT For any loan or deposit if there is ANY Any valid Amount can be
restriction on the amount to be drawn in loan input.
or amount of deposit in case of deposits–then
that amount can be mentioned here. If the
Drawdown amount/ deposit amount is less
than the amount mentioned in this field then
an OVERRIDE is raised.
RATE.OF.INTEREST Rate of interest can be input – and can be Interest rate
overridden at the AZ.ACCOUNT level using

All in One Account
the INTEREST rate or DD. Int. Rate fields. indicating %age

The system first looks at DD.INT.RATE if
not found it looks at Int. Rate in AZ.Account, if
not found it will take the rate inscribed in this
field in AZ PRODUCT PARAMTER.
DRAWDOWN.TYPE As repay type is credit card, there can’t be By default, it takes 1 full
restriction on number of drawl drawdown.
MULTI This field indicates whether multi- accounts Permitted input “Y” or “N”
(i.e. SUB accounts) are permitted or not. If Y
is input then sub accounts are created. For
credit card, a “Y” in this field is a mandatory.
ACCOUNT.SYNC A mandatory input if Repayment. Type is “Y” or “N”- for credit card
Credit. Card. If “Y” then the working balance it is YES ONLY. [If the
in account and the principal field in respective previous field multi is
AZ sub-account will be same at any given YES]
point. If “N” then sync between the balances
will not take place. Input in the field is a
mandatory.
INTEREST.ONLY Is always NO- as on the given date both Y or N – N for Credit card
interest a part of the principal generated
through CI and CC schedules. For interest
only repayments –(as in case of Non-
redemption) the field Cc. Pr. Grace. Period is
used.
PD.LINK.TO.AZ If the flag is set as Y – then PD link to AZ will Values Y or N- if no then
be established. However, the trigger to PD PD will not be created.
link is established ONLY when a repayment is For credit card it is YES
attempted on the AZ main account for the CI, ONLY. If this is setup as
C and CC schedule amount generated after Y-then at account level
the REPAYMENT date. If the repayment the field Liq.mode should
made is less than what is demanded through be set as Semi
the CI, C and CC schedules –PD is created automatic.
automatically for the remaining amount.
CARD.TYPE Any valid card type can be attached. When Any valid card type may
attached – the inputs in that card type i.e. bill be entered.
close/repay date will act as the trigger for
generating CC schedules & PD link- when a
repayment is attempted.
REPAYMENT.TYPE If this field has to be Credit Card. If not the Has to be
generation of sub accounts would not be
Credit card ONLY.
possible.
APPROPRIATION.TYPE Options available (1) Proportionate (2) FIFO. 1. Proportionate

Under option (1) the repayments received is
2. FIFO
spread over different withdrawals based on
outstanding. Under option (2) it is based on For non-redemption, this
the date of withdrawal i.e. first drawn should has to be set as FIFO.
be paid first then second drawl etc.
TO ILLUSTRATE:
For example if there are 3 draws through sub

All in One Account
account
Withdrawal 1 350000
Withdrawal 2 650000
Withdrawal 3 250000
TOTAL 1250000
Appropriation Type- Proportionate

If for the CC schedule raised say 125000 and
PAID the setting off will be:
125000*(350000/1250000)=35000 for the
drawl (1) and 65000 for drawl (2) and finally
25000 for drawl (3).
Appropriation Type- FIFO
If the CC schedule raised is say 450000
350000 will be fully adjusted to FIRST
withdrawal1 and then the remaining amount of
100000 will be adjusted towards the O/s of
second withdrawal. This way it will continue
until the last drawl is met with fully.
REVOLVING.RATIO Inputs in this field indicate –the product is a Numeric input which
REVOLVING type. Input permitted is Numeric, represents as a %age
which acts as a %age of repayment that is to
be raised as a CC schedule. For ex: - if the
customer has made 3 withdrawals of say- For Non-redemption
100000, 120000 and 200000. If revolving Type this has to be set as
ratio fields has an input of 10%- then CC 100%[as the entire o/s is
schedules will be raised for (1) 10000(2) payable in one bullet
12000 & (3) 20000 on the bill close date. A payment.
CC schedule is nothing but the amount of
principal repayment to be paid by the
customer for the withdrawals made. However,
for credit card if minimum repayment clause is
set whereby–10% of the outstanding in the
entire sub accounts or the minimum
whichever is higher will be taken as CC
schedule.
To continue the above example-
O/s (1) 100000 (2) 120000 (3) 200000.
Revolving ratio is 10% and assumes if
minimum repayment amount is 50000.
Now 10% of the outstanding in all the 3 Sub
account comes to 42000-But minimum is
50000. Therefore, the CC schedule will be for
50000 distributed to individual sub accounts
based on the O/s in each of the sub-
accounts. The amount of CC schedule for
each sub account will be as below

All in One Account
In APP- if appropriation type is

“PROPORTIONATE”
(1) 100000*(50000/420000)=11905
(2) 120000*(50000/420000)=14285
(3) 200000*(50000/420000)=23810
TOTAL 50000
[Note: The process of allocation is from
the main account and not from the sub
accounts to main account]
If in APP – if appropriation type is FIFO then
the entire amount will be set off against the
FIRST outstanding till it is brought down to
ZERO- then only it will be passed to the
second, third etc.
HIGHEST.RANGE This field should be read along with the field Multi-value set where you
“Amt.Percent”. Input in this field indicates the can define the range for
product is RANGED-Revolving type. It is an the ranged revolving
associated multi value set. We can define type. Whenever any
here different %age or a flat amount for amount is mentioned in
different range of amounts. The total AMT.PERCENT field it is
outstanding is combined to arrive at the range to be taken as LOCAL
within which it falls. Amt. percent field may currency
contain either a %age or an amount, which is
For example: -
applied as the repayment subject to the
minimum repayment clause stipulated. Local currency is USD.
AME.PERCENT field is
Ranged revolving *10%
mentioned as 200000.
Highest Range 100000 AZ account is in currency
GBP. When repayment is
Amt. Percent B*100 made FIRST the
Highest Range 1000000 repayment amount will be
converted to USD and
Amt. Percent *10 will be matched with
Highest Range 5000000 AMT.PERCENT field
where amount is
Amt. Percent *20 mentioned then if it is
equal to it then it will
reconverted to GBP and
Some validations: - will be adjusted to the
balance outstanding in
GBP. If the amount is
(1) “*” Before the numeric entered in amt. Less then the required
percent is must – or else the system will deem amount mentioned in the
it as amount and will generate CC schedule field the required amount
for only10 and not 10% of the outstanding. will be taken as the base
and will be converted to
equal amount in GBP
(2) “B*100”- implies “100% of the balance in and will be adjusted to
the account”. This is because when the O/S outstanding.
in a sub account falls within this range then it
is obvious that as per the minimum class an
amount of 100000 is payable. However, if the Unless mentioned
wherever amount is

All in One Account
O/s in the account may be say 98573/- in that mentioned it should be

case CC schedule amount will be more than read as local currency
the O/s that is actually payable if we stick to and not the currency of
the concept of 100000 minimum. To obviate the account.
this-we have introduced the concept 100% of
the balance O/s or 100000.
What happens if the combined amount of O/s

doesn’t fit into any specified range
This will be decided by the type of input made
in the field Amt. Percent. For ex:
Highest Range 300000

Amt. Percent *10
Highest Range 500000
Amt. Percent 150000
Reference to the table if the total drawings of

the customer come to 250000, it falls in the
range of 300000 and the %age of repayment
will be 10% of such outstanding (subject to
Minimum Repayment clause specified)
On the contrary, if the amount of drawing in

another sub account is 500000, then as
defined, the CC schedule will be generated for
150000 flat and not any percentage because
the field contains the amount.
In another event, if the amount of principal in

the sub account is 600000 as per above,
there is no range within which it falls, hence it
will attract the percentage as specified in the
revolving ratio field which is 20% as per the
above table for generation of a CC schedule
on the sub account. [The difference between
the “Amt percent containing AMOUNT or
percentage can be gauged from the above
example.”]
Suppose in a similar case in the highest range

500000 instead of amount, a %age of 20% is
input –then if the total amount of drawings
comes to say 600000- the system will try to
match the range –since none is present, it will
automatically take the Revolving Ratio %age
of 10% as the REPAYMENT. [The difference
between the “Amt. percent containing –

All in One Account
AMOUNT OR percentage can be gauged

from the above ex;-]
CC.PR.GRACE.PERIOD Input when the AZ. Product Parameter is Non-
Redemption type.
Valid input numeric.
Input allowed is Numeric. When input it should
be read along with the frequency input for the
card. Type in APP. For ex: -
If the card. Type is say AHLP and the
frequency of bill close/repay is defined as
Monthly. Then if in app or AZ. account 3 is
input it means for 3 months the generation of
CC schedule has to be postponed and only CI
schedules will be generated on the bill close
dates, which is repayable on the repayment.
Date.
AZ.ACCOUNT
Credit Card TXN.CODES
We have built a set of TRANSACTION codes for each type of transaction that can take place in a
loan contract, i.e. drawdown; repay, loan pre-close, maturity transactions and interest capitalisation
are some of the happenings that affect the loan account.

All in One Account
CASE-1 – in a loan drawdown is made then Debit is to loan account and Credit is to the
internal/ Nostro /customer (nominated) account. To tabulate the scenario
Transaction Debit Transaction Code Transaction Credit Transaction Code
Loan Account 76 Internal/customer 51
ACCOUNT
[Loan Drawdown [This transaction
transaction] code indicates that it
is a loan drawdown
and a debit to loan
account]
CASE-2- in a Loan Repay is made then Debit is to the REPAY account and Credit is to the
Loan account
Internal/customer 1 Loan Account 915
[Loan Repay
transaction]
Note: -When the field Repayment. Type is credit card –any attempt to repay should be channelled
through – Repayment. Txn code only as pre-closure and maturity transaction codes are not likely
events of credit card type.
In APP for each of the happenings – a transaction code is inscribed so that “THE EVENT “ could be
identified.
Note:
NOTE: -If the transaction codes are not inscribed in Az. Product. Parameter (APP) then an
error message is raised.
In case if the drawls are permitted through teller/ft –then the TELLER.TRANSACTION
should contain these transaction codes in accordance with their nature of activity. The Set up is
detailed below for academic interest:-

All in One Account
[For FT –similar set up need to be done before embarking on draw down /repayment etc as done
for teller application.
TELLER TRANSACTION
Note: - (1) Transaction code 2 is the Debit side. For Loan draw down the debit is to the loan a/c, hence
transaction code 76 is mentioned on the debit side.
(2) In case the transaction involves Loan Repay – then credit is to LOAN a/c. Then the set up for loan
repay would be as follows:
TELLER.TRANSACTION (loan repay set-up)
After setting up the APP, the main AZ Account should be created by attaching an
AZ.PRODUCT.PARAMETER. The PRINCIPAL field in the AZ.MAIN account should be zero and any
withdrawals made will result in creation of a sub account with the amount as drawn.

All in One Account
AZ. ACCOUNT
Field Name Permitted Inputs Remarks

All in one Product Any one of the product parameters Selection of the APP
created i.e. indicates the type of
product for which the
(1) Revolving –ID -1250
account is created, which
(2) Ranged Revolving-ID-1350 will be governed by that
product parameter.
(3) Non-redemption- ID-1450 can
be inscribed here.
Principal Should be ZERO for main account This is because –for credit
cards, there is no upfront
disbursement and the
customer is given the
facility to draw the
amounts as and when
required Every drawl is
considered as an
individual account with
interest rates ruling on the
date.

All in One Account
Orig. Principal Every drawdown made creates a This field is on the SUB
sub-account. This field is inscribed account
with the Drawdown amount and the
principal after every repayment on
any given date is inscribed in the The input is AMOUNT in
PRINCIPAL field. In Short Orig. numeric.
Principal implies the amount
actually DRAWN and PRINCIPAL
field implies amount actually
payable after adjusting the
repayments made so far.
Value and maturity Value date can be input – within the No maturity date –
date permitted max. Back value date. because credit card
Nevertheless, NO maturity Date. process is a continuous
one until it is cancelled.
Interest Rate & penal The interest rates are mentioned in
rate the AZ. Product. Parameter.
However, user has the flexibility to
input a new interest rate. Even this
rate can be overridden if there need
be by using the field
“DD.INT.RATE”.
If penal rate is mentioned in APP
then the interest rate defined in
APP + the penal rate will be
populated in PENAL rate field
automatically. However, user has
the option to override these rates.
Repay & Nominated This field should be input with either
account internal/customer account. If this
field is blank “NO DRAWDOWN is
possible and No account entries will
be raised
Charge key It can be set to 99 because these Drill down menu for
charges are General charges. different charges available.
Drawdown- Amount After the AZ account has already A must input when
been created. Any drawdown made drawdown is made.
through any of the OFS channels
will have to be entered in this field.
After the parameter, set up like
(Sync/Multi –Yes) the input in this
field will only create a SUB-account
for the amount so drawn.
DD int rate When drawdown is made through
AZ. Account using the drawdown
amount field the user is given the
flexibility to input a new rate if
desired which will override all the
other inputs made on interest. This
new rate will be assigned to that
particular Sub AZ account. It will be
cleared after the particular

All in One Account
withdrawal, so that next withdrawal

rate can be a different or the default
one.
Apart from the regular numeric input
-This field can also be input as (1)
S-nn or (2) S+nn. Meaning a
minus spread in the first case and
a plus spread in the case 2. For
this the system will first look at the
interest rate field in AZ.ACCOUNT if
not input then it will take the rate
inscribed in APP and do the spread
of minus or plus as input in this
field.
For ex: - In APP rate is input as 15
and this field is input as S-7
(Interest rate field in AZ.ACCOUNT
is blank) then the rate of interest
applicable for that drawdown will be
8%. On the other hand if the
interest rate at AZ.ACCOUNT level
is input as 12% then the interest
rate applicable for that particular
drawdown will be 5% i.e.12% -7%
and not the difference between APP
rate and the spread
Charge. Code The appropriate record of The charge amount will be
FT.CHARGE.TYPE will be defined based on the charge code.
here. The amount will always
represented in local
currency.
Charge date The date on which charges should This charge date has to be
be taken. It has to be set as, “repay input by the user to
date only”. Whenever the charge REPAY date
date is input, a “C” schedule will be
created on the charge date in
AZ.SCHEDULE.
Chg. Liq. Acct Define the Internal/customer
account from where the charge is to
be debited online for paying to the
other Bank/ our Bank etc.
Charge immed If the FLAG is set to Y in this field, it
means that the charges specified
above will be debited online and
accounting entries will be raised.
Chq Pl Acct If the charges have to be settled
/set-off against another internal
account at the time of repayment
then specify that account here.
Schedules Should be “NO”. Because the
trigger for interest, charges and
amount to repaid are taken care

All in One Account
through CI, C and CC schedules.

New Schedules Definition
“CI” Schedules This schedule is akin to CREDIT CARD. This schedule holds the
amount of committed interest i.e. interest from the date of
drawdown to the date of repayment on the drawdown amount of
the AZ sub account. Each such account will have a separate CI
schedule and a combined CI will be populated on the AZ.MAIN
account. The generation of CI is online the FIRST time CI is
generated –after that the CI is calculated from the Repayment
date to the next Repayment date as part of the COB JOB.
“C” Schedule “C” stands for CHARGES schedule. When drawdown is made
there are certain charges attached to it, which are stored in this
schedule. Charges are to be input manually every time a
drawdown is made. Whenever repayment is made, the FIRST
appropriation will be made to the charges. This schedule is
generated ONLINE whenever charges are attached to a
drawdown. This schedule is created on the charge date input
along with the charges.
“CC” Schedule “CC”-schedule stands repayment amount calculated as a %age
on the total drawdown made, to be repaid on the repayment date.
The amount of CC schedule is arrived at keeping the repayment
type i.e. Revolving or Ranged Revolving or Non-Redemption.
Revolving Ratio If the az. account is attached to
Revolving Product type – then
the %age of Revolving ratio will be
populated from the APP.
Repay Amt If the customer wishes to make a The settlement priority and
repayment through the AZ. Account other rules like
then this field is used. appropriation etc., would
happen only if the
repayment amount is
populated in this field
along with Repay V date
as Repayment date
Repay V. Date The effective date of the above If actual payment is
repayment is input here. For Credit received after, say, 3 days
Card, the Repay date has to be and if a PD is created,
entered here- so that when if PD is then the PD will assume
created when actual funds are this date (Repay date) as
received, it will be created with this its value date
value date as REPAY date.
Cancel Last Dd Drawdown is made using the For ex: - If it is made
Drawdown Amount field. If such a through teller-then way out
drawdown is to be cancelled then to cancel the transaction is
this field is the way out and not to REVERSE the teller.
through any other mode. Nevertheless, when
drawdown is made through
Drawdown field in AZ –
Then for cancellation only
this field need to be used.
Cc. Pr. Grace. Period If the AZ. Product. Parameter is a

All in One Account
Non-redemption type- then the

period of GRACE given for
repayment of principal is populated
from the
Rate Chq. Sub Acc In put in this field as Y indicates that
any rate change will be applicable
to Not only future withdrawals but
the present withdrawals will also
have this new rate from this day
Drawdown Procedure
On the front end, drawings on AZ can be made through delivery channels like ATM, Internet, Branch
network, Point of Sale merchant network etc.
Whatever the type of drawl the entries are passed through the AZ. Account as a Drawdown which will
automatically create a SUB-Account which is a replica of the main except for the amount of drawdown,
the rate of interest etc. An AZ account should be first created and committed before making any
Drawdown.
DRAWDOWN can be made either through the field drawdown in the AZ. Main ACCOUNT or through
TELLER/FT etc. which is detailed below:
Drawdown through AZ
Open the AZ main account that has already been committed and input in the field Drawdown amount
(interest rate if required - the rate specified here will override all earlier inputs made in APP or in the
interest rate field in the AZ account.).
AZ MAIN ACCOUNT DRAWDOWN

All in One Account
When the above record is committed the system creates sub account 19950 with relevant particulars
of interest (CI Schedule) Charges (C schedule) as shown below:
AZ.SUB.ACC –19950 [MAIN ACCOUNT 16667]
Note:
1. The above screen shot indicates creation of sub account 19950 with the drawdown amount of
220000 made on the AZ Main account.
2. That the rate of interest applicable is 8.88% (as input in the DD int Rate which overrides all other
interest input elsewhere, i.e. APP, interest rate field in AZ. Account etc).
3. The system has calculated a CI of 53.52 @8.88% on 220000 from the date of drawl till the repay
date. Date of drawdown is 26th, the repay date is 27th i.e. interest for 1 day at the above rates
(leaving the LAST day. If the ACCOUNT.ACCRUAL is yes, interest will be calculated for 2
days).
Drawdown through Non AZ
If through Teller, then use of the Teller Transaction code specially designed for the Credit Card should
be used. The set up for the TXN code and the Teller transaction are detailed below:
TXN code for loan drawdown- 76

All in One Account
TXN CODE FOR LOAN DRAWDOWN
Since Loan Drawdown is a debit to loan account, this transaction needs to be inscribed on the debit
side of Teller Transaction. This is done in Teller Transaction 10 as shown below:
TELLER TRANSACTION OF LOAN DRAWDOWN
Fields Remarks
Customer, Currency, Category, All in one Are populated from the main account
product automatically.
Principal The amount that is drawn is written to this field.
Whenever repayments are made the balance

All in One Account
in this field will come down till it becomes zero.

Orig. Principal The amount of drawdown made written to this
field, which stands as a mirror to the principal
of this sub account until it is closed. Any
variance in principal due to repayment is
written to the Principal field - THIS IS A NO
INPUT field.
Interest rate, Penal rate, Charge key Are populated from the main account
Schedules, calculation base etc.
Important notes:
1. Any drawdown has to be made on the Az. Main Account only.

2. Repayments are made on the main account only, which is allocated/apportioned to the sub
accounts based on the APPROPRIATION. TYPE defined in the product parameter attached to the
account.
3. Table AZ.SETTLEMENT.PRIORITY should be set for the handling and withdrawal charges as
shown below:
4. If drawdown is made through the drawdown field in AZ Main account, cancellation can be done
using CANCEL.LAST.DD field.
Creation of the sub-account happens when drawdown is made. The drawdown can be either: (1)
through Teller/FT, or through (2) inputting the drawdown amount field in AZ.
In the FIRST case – where the drawdown is through Teller/FT, the cancellation of the drawdown
can be through REVERSAL of the Teller/FT and not through the Az. Account.

All in One Account
In the SECOND case- where drawdown has happened through input of the Drawdown amount
Field- cancellation can be done through the field CANCEL.LAST.DD in the main Az. account.
Caution:
IF the sub account created through Teller is attempted for a reversal in AZ by using
CANCEL.LAST.DD, then the last sub account created through AZ will be REVERSED.
When the Account is in PD and if a repayment has been made, then the system would have
appropriated the repayment towards outstanding in C, CI and CC schedules. Hence, cancellation
of a REPAYMENT is not possible. It has to be DONE through a PD.CAPTURE only.
Backdated draw down is now allowed in Credit card. It is now possible to allow backdated draw down
after last Bill closing date and it will create a new Sub account. The new Sub AZ will hold the draw
down amount. Draw down can be allowed only from the Main AZ account as usual and not from sub
accounts.
• The field INT.ADJ.TXN has been introduced in AZ.PRODUCT.PARAMETER, to handle
adjustment for Annuity will be allowed for Credit card also.
• Interest adjustments can be done in Main AZ Account through field INT.ADJ.AMT & by other
application like FT/TT etc using INT.ADJ.TXN code in APP. This will not be allowed for Sub AZ
Accounts directly.
• INT.ADJ.AMT field of AZ.ACCT.BAL of Main AZ Account willl contain the adjustment amount.
• INT.ADJ.TXN can be used only for CREDIT CARD with no interest liquidation account &
VALUE.DATE of the entry related to INT.ADJ.TXN should be current bank date only (Similar to
Annuity).
• When entries are raised during INT.ADJ.TXN Code, the following process shall follow
Raise entries to debit Suspense account specified in AZINTADJ and credit repay account AZ / teller
default for the INT.ADJ. The INT.ADJ.AMT should be updated in INT.ADJ.AMT field of
AZ.ACCT.BAL
• When there is regular repayment/ online repayment, the system should look at the INT.ADJ.AMT
and raise entries to settle AZINTADJ suspense account. Settling of Interest adjustment shall
happen first even before settling of any of its Sub account’s components happens. Settlement
should clear INT.ADJ.AMT field. The rest of the amount should be used for settling other
components.
• In case of failure of repayment on repay date, at PD will be created for sub-accounts only as of
now. This will be now relaxed to create PD at either Main account or at sub-account level based
on a new field in AZ.PRODUCT.PARAMETER. In case PD is to be created for main account
level, the ID of PD will be main AZ account & Original settlement account will be
the corresponding repay account. Interest adjustment amount shall be indicated as ‘IN’
Component. This shall happen during COB only if CREATE.PD.EOD is flagged to YES in

All in One Account
• No change in existing enquiries shall happen to reflect the interest adjustment amount similar to
Annuity.
• Online interest capitalisation changes have to be incorporated for Credit cards also similar to
Annuity & other loans.
Previously, backdated draw down is not allowed in Credit card. Now changes have now been made to
allow backdated draw down after last Bill closing date which will then create a new Sub account. The
new Sub AZ will hold the draw down amount. Draw downs can be allowed only from the Main AZ
account as usual and not from sub accounts.
Note on CHARGE fields in AZ account
INPUT OF CHARGES WHILE DRAWDOWN
CASE-1
o In the present case the charge date is input as 27.11.2002 i.e. that of repay date and the
charge immed is left blank- then “No Online Accounting” will take place. A “C” schedule will
be written on the AZ Schedules with date 27.11.2002. As part of the EOD job on
27.11.2002- the system will automatically raise the accounting entries for the charges
mentioned above
CASE-2
In the above case had the date been input as to-day i.e. 26.11.2002 and the charge immediately flag
is made as YES -This will trigger the accounting entries right away and will debit the stated charges
immediately to the charge liquidation account and generate the “C” schedules for information.
Once the billing close is over the system based on the input, AZ.PRODUCT.PARAMETER will
generate the CC schedules and write it into the AZ sub account as shown below.

All in One Account
AZ SCHEDULES AFTER BILL CLOSING
Note:
√ The schedules after bill close have generated a CC schedules for 90000.
√ This account is a RANGED revolving type and based on the inputs in AZ Product parameter the
CC schedule for 90000 has been generated.
√ The total amount payable by the REPAY date is:
“C” amount 600.00

“CI” amount 53.52
“CC” amount 90000.00
TOTAL 90653.52
A repayment should be attempted on the AZ Main account to trigger the PD process. If the total
amount is repaid then there is no question of PD being raised. If part amount is repaid then the system
will automatically create PD records for the amount due after adjusting the repaid amount.
The process of REPAYMENT can be made through the Repay amount field present in the AZ
MAIN account
REPAYMENT PROCESS
Out of the amount total due of 90653.52-, we have input a repayment amount of 500 on the AZ Main
a/c. The settlement will happen based on the table no.17. This will be apportioned to CHARGES first,

All in One Account
committed interest (CI) and then to the CC amount. Since the amount paid doesn’t even cover the
entire charges –the system after affecting payment has raised a PD in the following way.
Schedule Outstanding Repayment PD

received amount
“C” amount 600.00 -500.00 100.00
[Repayment
received]
“CI” amount 53.52 53.52
“CC” amount 90000.00 90000.00
TOTAL 90653.52 Balance 90153.52
PD Handling
Category Principal Interest penalty charge Withdrawal charge
Past due – month before
previous 7 5 3
Past due – previous month 8 6 4
2 1
Scheduled payment (current
month) 10 9
Remaining principal 11
None
15 14
New drawdown after close 17 16 13 12
19 18
Repayment Procedure
Repayment through AZ
Repayment through AZ account is done using fields

REPAY.AMT and REPAY.V.DATE
AZ.ACCOUNT REPAYMENT THROUGH AZ

All in One Account
The repay amount stipulated in the screen shot will be used to repay the sub a/cs. The principal field
in the Sub a/cs will be adjusted to the extent of the repayment and the CI (committed interest) will be
recalculated taking into account the repayment.
Repayment through Non AZ
Repayment may also be made through applications other than AZ like Teller; FT. Basically a set up
procedure needs to be followed for drawdown/repayment and other TXN types.
The set-up procedure in detail is tabulated under Credit Card TXN codes that may be spread to
other applications on similar lines.
As a first step towards

using the application, other AZ transaction codes and the
TELLER.TRANSACTION application (in case of FT –FT.TXN.CONDITION) should be set in
the following way.
SETTING UP TELLER.TRANSACTION FOR REPAYMENT OPTION
While inputting Teller for the repayment option, the above transaction should be used which will build
the necessary entries, and also follow the appropriation type stipulated in the

All in One Account

Uploaded by

Document Information

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

All in One Account

Uploaded by

Copyright:

Available Formats

TEMENOS T24

All in One Account

Information in this document is subject to change without notice.

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide Page 2 of 189

Account Opening procedure .............................................................................................................. 45

TEMENOS T24 User Guide Page 3 of 189

Back Dated Rate Change ............................................................................................................ 105

TEMENOS T24 User Guide Page 4 of 189

The module is linked to AZ.PRODUCT.PARAMETER application which allows you to define

The following is the general workflow:

TEMENOS T24 User Guide Page 5 of 189

A product parameter record is required in order to use AZ.ACCOUNT.

TEMENOS T24 User Guide Page 6 of 189

Debit Interest Rates

TEMENOS T24 User Guide Page 7 of 189

The fixed interest rate is input in the field INT.FIXED.RATE.

EXAMPLE FOR COMBINED INTEREST

BASIC.INTEREST @ID 1USD20001120

Draw down Amounts

TEMENOS T24 User Guide Page 8 of 189

Interest-Only Repayment Periods

TEMENOS T24 User Guide Page 9 of 189

BASIC.INTEREST @ID 1USD20001120

TEMENOS T24 User Guide Page 10 of 189

BASIC.INTEREST @ID 1USD20001120

TEMENOS T24 User Guide Page 11 of 189

• Repayment due date 31 MAR 2001

AZ.ACCOUNT and AZ.PRODUCT.PARAMETER workflow

TEMENOS T24 User Guide Page 12 of 189

Default Loan Inputs

Validation of Loan Inputs

Validation occurs either as field value restriction or override notification.

Default Schedule Inputs

When entering Schedule Inputs on AZ.ACCOUNT, if an “R” type schedule is entered in

TEMENOS T24 User Guide Page 13 of 189

Validation of Schedule Inputs

AZ.PRODUCT.PARAMETER is accessed for:

Amending Product Parameter Records

Daily compounding of Interest in Call Deposits

Compounding of interest in AZ.ACCOUNT Deposits is now possible.

The field COMPOUND.TYPE in AZ.PRODUCT.PARAMETER level is used to determine whether

TEMENOS T24 User Guide Page 14 of 189

Periodic Charges – AZ Account

ONE TIME CHARGE COLLECTION

TEMENOS T24 User Guide Page 15 of 189

SCHEDULES - DEPICTING CHARGE

TEMENOS T24 User Guide Page 16 of 189

Capitalisation rules – Partial Withdrawal / Pre-closure

TEMENOS T24 User Guide Page 17 of 189

Start date: 01-04-03

INT CAPITALISED - PARTIAL WITHDRAWAL

TEMENOS T24 User Guide Page 18 of 189

Figure 1 ELIGIBLE INT CR

Interest has already been paid for 2 days at 6.9063%.

TEMENOS T24 User Guide Page 19 of 189

REVERSAL - EXCESS INT PAID

For referring to a PERIODIC.INTEREST table for interest in AZ.PRODUCT.PARAMETER

DEFINING PERIODIC INTEREST

TEMENOS T24 User Guide Page 20 of 189

Periodic Interest Table → 01USD

Capitalisation rules – multi deposits

AZ.PRODUCT.PARAMETER - MULTI DEPOSIT

TEMENOS T24 User Guide Page 21 of 189