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.................................................................................................................................... 1
Table of Contents.................................................................................................................................... 2
Introduction.............................................................................................................................................. 4
Application Overview........................................................................................................................... 4
Setting up the System.......................................................................................................................... 4
General Setup.................................................................................................................................. 4
Application Design............................................................................................................................... 5
AZ Products...................................................................................................................................... 5
Defining parameters......................................................................................................................... 5
Debit Interest Rates.......................................................................................................................... 6
Draw down Amounts ........................................................................................................................ 7
Interest-Only Repayment Periods.................................................................................................... 8
Penalty Interest ................................................................................................................................ 8
Posting Restriction......................................................................................................................... 11
AZ.Account and AZ.Product.Parameter workflow.......................................................................... 11
Amending Product Parameter Records ......................................................................................... 13
Daily compounding of Interest in Call Deposits ............................................................................. 13
Overview of Input and Processing..................................................................................................... 14
Customer and Limit for AZ............................................................................................................. 14
Defining the AZ Loan (AZ.ACCOUNT)........................................................................................... 14
Account Opening procedure .......................................................................................................... 15
Defining Nominated and Repayment accounts.............................................................................. 15
Loan Principal and Drawdown options........................................................................................... 16
Full Drawdown................................................................................................................................ 16
Partial Drawdown........................................................................................................................... 17
Residual on Principal...................................................................................................................... 18
Defining Repayment types............................................................................................................. 19
Bullet Repayments ......................................................................................................................... 19
Multiple Repayments (Loan Schedules) ........................................................................................ 20
Defining Interest Only Periods ....................................................................................................... 23
Defining Loan Schedules Schedule Inputs ................................................................................. 24
Drawdown Schedule...................................................................................................................... 25
Repayment Schedule Annuity..................................................................................................... 26
Repayment Schedule Principal................................................................................................... 27
Repayment Schedules Interest................................................................................................... 27
TEMENOS T24 User Guide Page 2 of 189

All in One Account
Rebuilding schedules after an online repayment of annuity loan.................................................. 30
Defining Variable and Fixed rate of interest................................................................................... 30
Schedules link to Limit and ADI ..................................................................................................... 31
Reschedule Process and Term Priority.......................................................................................... 32
Loan Repayment Schedule History................................................................................................ 32
Current Date Principal increase in Annuity repayment type loans................................................. 33
When a user defines a repayment amount which is less than the interest repayment amount..... 34
Loan Account Operations............................................................................................................... 34
Redraw Process............................................................................................................................. 35
Arrears Penalty Process ............................................................................................................. 35
Loan Account Closure.................................................................................................................... 35
Minimum Maturity Date.................................................................................................................. 37
SINGLE LIMIT MULTIPLE LOANS............................................................................................. 38
User Definable Annuity Amounts ................................................................................................... 43
AZ.Overdues .................................................................................................................................. 47
Interest Received In Advance (IRA)............................................................................................... 51
Settlement Priority.......................................................................................................................... 55
Suspension of Interest on AZ loans when PD turns NAB.............................................................. 74
Back Dated Rate Change .............................................................................................................. 75
Back Dated Principal Repayment .................................................................................................. 84
Deposits ......................................................................................................................................... 91
Maturity Process............................................................................................................................. 93
Early Redemption........................................................................................................................... 93
Late Payment Fee.......................................................................................................................... 94
Fixed Floating Deposit Type .......................................................................................................... 94
Introduction of R Schedules for Deposits .................................................................................... 98
Multi Deposits................................................................................................................................. 98
Sub Account (AZ.Account) Creation through Clearing Credits................................................. 127
Periodic Charges AZ Account................................................................................................... 133
Capitalisation rules Partial Withdrawal / Pre-closure................................................................ 135
Capitalisation rules multi deposits............................................................................................. 139
AZ Product Start Date End Date.................................................................................................. 145
Early Closure Penalty using routine............................................................................................. 149
Grace period for reckoning default............................................................................................... 154
Bonus on Interest Earned on Savings.......................................................................................... 157
AZ.Reversal.................................................................................................................................. 160
Credit Card................................................................................................................................... 160

All in One Account
Introduction
Application 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.

Setting up the System
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.
1. 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.

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

All in One Account
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.

Application 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. ANNUI TY, LI NEAR and NON-
REDEMPTI ON. 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 CREDI T- 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. SAVI NGS- PLAN and FI XED. In FI XED the deposit
amount is accepted in a fixed lump sum and repaid as fixed amounts either with interest accumulated
or not. In SAVI NGS- 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

Figure 1 AZ.PRODUCT.PARAMETER

The standard T24 interest basis options are available and AZ allows for the new G basis (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 I NT.FI XED.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 @I D 1
DESCRI PTI ON Base Rate

BASIC.INTEREST @I D 1USD20001120
I NTEREST. RATE 4.5

AZ.PRODUCT.PARAMETER @I D 1
RATE. KEY 1 Base Rate
RATE. SPREAD 2.5
RATE. OPERAND ADD
RATE. PERCENT 70
I NT. FI XED. 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 I NT.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. I NSTL. I NT. ONLY is only input if the value in I NT. 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

Figure 2 Defining AZ.PRODUCT.PARAMETER

EXAMPLE


I NTEREST. RATE 4.5

RATE. SPREAD 2.5
RATE. OPERAND ADD
RATE. PERCENT 70

All in One Account

APPLY. PENALTY Y
PENAL. OPERAND ADD
PENAL. MARGI N 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. PERI OD. 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


I NTEREST. RATE 4.5


All in One Account
RATE. SPREAD 2.5
RATE. OPERAND ADD
RATE. PERCENT 70

APPLY. PENALTY Y
GRACE. PERI OD 7
PENAL. OPERAND ADD
PENAL. MARGI N 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 7
th
April 2001 will accrue interest for each day from the 31
st
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.

When opening a new AZ.ACCOUNT the first field to be input is the ALL.IN.ONE.PRODUCT value.
This is the @I D of an AZ.PRODUCT.PARAMETER record. The system accesses the relevant
AZ.PRODUCT.PARAMETER record.

All in One Account

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, I NT.ONLY and MAX.I NSTL.I NT.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 PRI NCI PAL will
be validated against the AZ.PRODUCT.PARAMETER values in MI NI MUM.AMOUNT and
MAXI MUM.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.FI XED.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.

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.


All in One Account
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.
A new field has been introduced in AZ.PRODUCT.PARAMETER level as COMPOUND. TYPE to
determine whether compounding interest functionality is required or not. This field is the frequency
field and will accept frequencies DAILY, WEEKLY and MONTHLY.

Also, a new field COMPOUND. TYPE has been introduced 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.

All in One Account
Overview of Input and 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 customers LIMIT record.

The LIMIT record is set up using the format CUSTOMER. I D. LI MI T. 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. LI MI T field in AZA can be set to N. In this case the
limit will not be reduced on the scheduled dates. If SI NGLE. LI MI T 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. LI MI T 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
LI MI T.REF value be entered. Furthermore, the LI NK.TO.LI MI T 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 NOMI NATED.ACCOUNT, is used for identifying the drawdown account to which the funds are
to be disbursed. The associated fields NOM.I NT.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.I NT.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 NOMI NATED.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.I NT.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 NOMI NATED. 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. I NT.

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. I NT 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 PRI NCI PAL. 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 FI NAL.DD.I ND 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 NOMI NATED. ACCOUNT identified for the borrower. Once the
AZ.ACCOUNT record is authorised, the draw down amount will be set up in a TELLER.DEFAULT
for manual processing.


All in One Account
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
PARTI AL & NO I NT or 3 PARTI AL & NO I NT 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 CALCULATI ON.BASI S. For more details relating to CALCULATI ON.BASI S,
please refer to Chapter 11 on Defining Loan Schedules Schedule Inputs.

First and Subsequent Partial Drawdown
The field FI NAL.DD.I ND 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.


All in One Account
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 PRI NCPAL 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 PRI NCPAL value,
the system will recognise that full drawdown has been scheduled.

Once the final drawdown is established the system will set the value in FI NAL.DD.I ND 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 PRI NCI PAL, then the user may
select the value Y in the field FI NAL.DD.I ND. 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
RESI DUAL. PRI NCI PAL.

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
Fixed Interest Rate 10%
Repayment Type LINEAR
Frequency Monthly
Term 3 Months
Calculation Base Schedule Balance

All in One Account
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 PRI NCI PLE , CURRENT BALANCE and SCHEDULE BALANCE as the
calculation base. It is not allowed for NON REDEMPTI ON 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. ANNUI TY, LI NEAR and NON-
REDEMPTI ON. 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 CREDI T- 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. SAVI NGS- PLAN and FI XED. In FI XED the deposit
amount is accepted in a fixed lump sum and repaid as fixed amount either with interest accumulated
or not. In SAVI NGS- 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.

All in One Account

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 borrowers requirements.

EXAMPLE:
For an ANNUI TY 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 ANNUI TY
to NON- REDEMPTI ON 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 ANNUI TY and the full
ANNUI TY 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 CALCULATI ON.BASE should be consistent with the REPAYMENT.TYPE.


All in One Account

Figure 5 Defining Repayment type in AZ.ACCOUNT


All in One Account

Figure 6 Defining Repayment types in AZ.ACCOUNT


All in One Account

Figure 7 Defining repayment types in AZ.ACCOUNT

Defining Interest Only Periods
The field I NT.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 I NT. ONLY is Y then a value must be entered for the field MAX. I NSTL. I NT. 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.I NSTL.I NT.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.I NSTL.I NT.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 Nor 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.FI XED.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 CALCULATI ON.BASI S 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 schedules 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 MATURI TY.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 schedules 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 MATURI TY.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 schedules 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.I NSTL.I NT.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.PRI ORI TY will be taken into
account when defining this schedule. If TERM.PRI ORI TY 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.FI XED.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.FI XED.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.
If no CHG.LIQUID.AC, REPAY.ACCOUNT (for deposits) or NOMINATED.ACCOUNT (for loans) is
defined, then an error will be given.

All in One Account
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 (new field) as per the CHARGE.CODE (existing field) and
CHARGE.DATE (existing field) as an on-line activity
The CHARGE.DATE field mentioned here should have only the process day (business date /
GLOBUS date) by default. That means for future dated charge collection the fields under Schedules
have to be used.
The existing 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 I NT. CORR. I MMED 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 I NT. CORR. I MMED in the APP is set to Next correction interest will be parked in AZ I NT ADJ
Suspense account and collected in the subsequent repayment. Next can be set only for Annuity
loans and only when ANNUI TY. ADJ UST is set to Yes
The field I NT. CORR. RTN in the APP is a Hook field that can hold a local routine to get values for the
field I NT. CORR. I MMED. 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 I NT ADJ Suspense account) collected
during the next online repayment
In case I nt Adj Amt & Correction interest component is collected during a scheduled repayment
then the same is added to Type N.
When I NT. CORR. I MMED 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.

The combination of Variable and Fixed interest may be based on a certain percentage of the
outstanding amount.

All in One Account

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

Figure 8 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.ACCOUNTwith account number and
date as its ID. The interest for AZ.ACCOUNT is calculated during End of Day, based on the
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

All in One Account
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 TERMPRI ORI TY 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 Ter m Pr i or i t y 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.

The Repayment Schedule history contains the reason for rescheduling also as Notes.

All in One Account

Figure 9 A view of AZ.SCHEDULES.HIST

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.


All in One Account
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. LI MI T 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 ANNUI TY. ADJ UST =YES
Field Ter mPr i or i t y = No
- PD Li nk t o 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.

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.


All in One Account
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.I ND 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, could handle only non-revolving type of loans. This
enhancement has been made to handle revolving type of loans also in AZ accounts.

To ensure this, a new field REDUCE. LI MI T has been introduced in AZ.PRODUCT.PARAMETER
and AZ.ACCOUNT. The value of REDUCE. LI MI T in AZ.PRODUCT.PARAMETER is populated
in AZ.ACCOUNTand 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
AZ.PRODUCT.PARAMETER would be taken into account. This field would be available for input
only when SI NGLE LI MI T is defined as yes.


All in One Account

Figure 10 AZ.PRODUCT.PARAMETER- REDUCE LIMIT NO INPUT

The default value would be null which is equivalent to yes. When the value of REDUCE. LI MI T is
defined as yes the amount withdrawn is permanently reduced from the limit. Also the related field in
LIMIT is updated.

Figure 11 LIMIT UPDATION - REDUCE.LIMIT 'YES'

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.


All in One Account

Figure 12 AZ.PRODUCT.PARAMETER - REDUCE.LIMIT 'NO'

Figure 13 LIMIT UPDATION - REDUCE.LIMIT 'NO'

Minimum Maturity Date
A new field Mi n. Mat . Dat e is introduced 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 Mi n. Mat . Dat e defined in
the AZ.ACCOUNT and moves to history during COB of the Mi n. Mat . Dat e, subject to working
balance being zero.
Past the Mi n. Mat . Dat e, the contract moves to History during the subsequent COB, again, subject to
working balance of the underlying ACCOUNT being 0 (zero).
During Pre-closure, the contract behaves as per existing functionality. I.e. moves to history online,
irrespective of the Mi n. Mat . Dat e.


All in One Account
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 SI NGLE. LI MI T in both
ACCOUNT and AZ.PRODUCT.PARAMETER applications. The value input in the field
SI NGLE. LI MI T in both the applications should be the same for the creation of AZ.ACCOUNT

Figure 14 ACCOUNT


All in One Account

Since the value of the field SI NGLE. LI MI T in ACCOUNT and AZ.PRODUCT.PARAMETER
does not match, while creating an AZ account would raise an error.

All in One Account

Figure 16 SCREENSHOT SHOWING ERROR IN AZ.ACCOUNT

It would permit creation of AZ account only when the value of SI NGLE LI MI T is same in both the
applications.

All in One Account

Figure 17 AZ.PARAMETER - SINGLE LIMIT N

Figure 18 ACCOUNT - SINGLE LIMIT N

All in One Account

Figure 19 AZ.ACCOUNT
Once an AZ ACCOUNT is created, the field SI NGLE. LI MI T is a no input / no change field in both
the ACCOUNT and AZ.PRODUCT.PARAMETER.

Figure 20 AZ.PRODUCT.PARAMETER - SINGLE LIMIT - NO INPUT FIELD

All in One Account

Figure 21 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

Figure 22 AZ.ACCOUNT WITHOUT USERDEFINED AMOUNT

All in One Account

Figure 23 AZ.SCHEDULES

Figure 24 AZ.ACCOUNT - USERDEFINED AMT < INT - ERROR


All in One Account

Figure 25 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.

Figure 26 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

All in One Account
payment is due bi-weekly. Now when the amount is defined as 1000 the maturity date is reduced to 9
December.

Figure 27 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.


All in One Account
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. LI NK. TO. AZ field as NO

Figure 28 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

Figure 29 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. LI NK. 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.

All in One Account

Figure 30 AZ.OVERDUES FILE UPDATION
As related above when the instalment becomes due the system has updated the OD. PRI NCI PAL and
the OD. I NTEREST fields as shown above.

ACCOUNTING: -

Unlike PD the system doesnt 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
AC.AUTO.ACCOUNT-) crediting the AZ. ACCOUNT or the I NTEREST LI QUI DATI ON 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. PRI NCI PAL. TXN and
OD. I NTEREST. 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 .


All in One Account

Figure 31 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 01
st
J an and the Interest payout is
scheduled on 15
th
J an is USD1000.
Let us say on 05
th
J an 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 J an to 15
th

J an 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

All in One Account
Set-up related to AZ- Interest Received in Advance
The IRA functionality for AZ Loan accounts can be activated by setting the field I RA. 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.

Figure 32 IRA.PROCESS setting at AZ.PRODUCT.PARAMETER
The Transaction code related to Interest received in advance has to be given in I nt . Cr . Cap along
with the other Interest Credit capitalisation related txn codes.

Figure 33 IRA transaction code given in Int.cr.Cap

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.


All in One Account

Figure 34 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.

Figure 35 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
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

All in One Account
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.

Figure 36 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.

Figure 37 AZ.ACCT.BAL WITH IRA Details

Figure 38 IRA AMOUNT POSTED TO SUB ACCOUNT


All in One 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.

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 *

All in One Account
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 Over due 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.

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 ie. 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.

All in One Account

The valid ID to the AZ.SETTLEMENT.PRIORITY application is: -

2. AZ Account prefixed with A
3. Customer Prefixed with C
4. AZ product parameter
5. System (Default)

SYSTEM (Default)
The settlement priority processing is as per the order given in ASP and in case the system doesnt 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.

Figure 39 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.


All in One Account
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.

Figure 40 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.

Figure 41 CUSTOMER LEVEL PRIORITY DEFINITION IN ASP (LEVEL 2)

All in One Account

To process Settlement priority at the customer level, AZ.CUSTOMER application is referred which
has list of live AZ ACCOUNTS for a Customer.

Figure 42 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.

Figure 43 PRODUCT LEVEL PRIORITY DEFINITION IN ASP (LEVEL 3)


All in One Account
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 LI NK. TO. SETT. PRI OR.

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.

Also in case settlement priority to be skipped for a particular Account / Customer/ Product, a record in
ASP can be created with LI NK. TO. SETT. PRI OR 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.

Figure 44 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


All in One Account

Priority Rules

Repayment Types

AZ.SETTLEMENT.PRIORITY
AZ.ACCOUNT

AZ.AMOUNT.TYPE/
DATE

If No Matching Account in
ASP move to Next Level

CUSTOMER
AZ.AMOUNT.TYPE/
DATE/
PRODUCT

If No Matching Cust in ASP
move to Next Level

PRODUCT

AZ.AMOUNT.TYPE/
DATE

If No Matching Product in ASP
move to Default

SYSTEM (Default)
AZ.AMOUNT.TYPE/
DATE/
PRODUCT

Any Surplus after
Settlement Process

SURPLUS

Credit to REPAY.ACCOUNT
Level 1
Level 2
Level 3
Level 4
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. LI NK. 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. LI NK. TO. AZ as
Yes.


All in One Account

Figure 45 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 TRANSACTI ON. CODE. 2 is created with code 493.

Figure 46 TELLER TRANSACTION CREATED WITH LOAN REPAY TXN CODE
To process settlement priority, an AZ Loan Account 37818 is created with repayment type as
ANNUI TY and it has following schedules due as on 22 October & 29 October.

All in One Account

Figure 47 AZ.ACCOUNT 37818 SCHEDULES FROM AZ.SCHEDULES
Since the balance in not available in the repayment account and at the product level PD. LI NK. 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

Figure 48 OVERDUE DETAILS FOR 37818

In case the PD. LI NK. 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

Figure 49 SETTLEMENT PRIORITY DEFINED FOR AN ACCOUNT (LEVEL 1)

All in One Account

Figure 50 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 29
th

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

Figure 51 OVERDUE DETAILS AFTER REPAYMENT TO AZ.ACCOUNT
In AZ.ACCOUNT , the principal is reduced to the extent of USD200,000.00

Figure 52 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

AZ.AMOUNT.TYPE/
DATE

If No Matching Account in
ASP move to Next Level

CUSTOMER
AZ.AMOUNT.TYPE/
DATE/
PRODUCT

If No Matching Cust in ASP
move to Next Level

Level 2
Level 1

All in One Account

AZ.SETTLEMENT.PRIOIRTY
PRODUCT

AZ.AMOUNT.TYPE/
DATE

If No Matching Product in ASP
move to Default

SYSTEM (Default)
AZ.AMOUNT.TYPE/
DATE/
PRODUCT

Any surplus move to next best
fit AZ Acct from
AZ.REPAY.ACCOUNT

SURPLUS

Find next best fit from
AZ.REPAY.ACCOUNT
(Go to Level 1)
Any Surplus after Processing
all AZ Accounts

SURPLUS

Credit to
REPAY.ACCOUNT

Level 3
Level 4

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.

Figure 53 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)

Figure 54 SETTLEMENT PRIORITY DEFINED FOR THE ACCOUNT
Following over dues are there which are to be processed through common repayment settlement
priority.

Figure 55 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.

Figure 58 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
Methods
Details Amount
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

Figure 59 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

Addition information
Currently Settlement priority processing is available only for Loan except NONRED repayment
type of Loans.
Settlement priority processing not allowed with back value dated entries.
In case any unauthorised changes are there for an AZ ACCOUNT, then Settlement priority cannot
be processed by repaying through that AZ ACCOUNT
Similarly settlement priority processing through common repayment account cannot be done when
one of the AZ ACCOUNT HAS unauthorised changes.
TELLER / FT transaction processed for settlement priority cannot be reversed.
Statement entries created for settlement priority contains the id of the Settlement priority record along
with the component in ADDL. TRANS. REF.
Settlement priority processing cannot be invoked during batch mode.
LOAN. REPAY transaction code should not be used in non-AZ contract related processing.
AZ transactions processed with the respective events like LOAN. PRECLOSE, OD. PRI NCI PAL. TXN
etc will not be referring the Settlement priority Application.

All in One Account
When IN component is processed through Settlement priority, then interest is calculated up to
previous day & debited to AZ account using online interest capitalization.
When PR component is processed through settlement priority and entire outstanding amount is paid
fully, then the AZ account is moved to history during end of day process.
Settlement priority will have no bearing with the current schedules, meaning the current schedules will
get executed irrespective of being paid online or not.
The ACCRUAL. TODAY field in PD.PARAMETER should be set to Y so that when we preclose the
loan the accrued amount that we read from PD will be the latest else there could be a difference when
we actually settle the PD and read the values.
In a multi company set up the REPAY. ACCOUNT should be present in the company of the
AZ.ACCOUNT

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.

Figure 60 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.

All in One Account

Figure 61 AZ.SETTLEMENT.PRIORITY
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

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: -


All in One Account
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

Categ Entry Cr 500.00
(accrual)
18.02.04
Re.consol.Spec-
Dr
500.00

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
interest
@25%
Already
capped
Difference
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

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


All in One Account
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

Check INTEREST TYPE

Fixed Fixed Floating
BI key


All in One Account

NO
YES

Accounting for INTEREST
ADJUSTMENT

YES

Already Capitalised Interest Interest under Accrual

ONLINE
END
AT COB

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

Figure 62 .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 cant 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

Figure 63 AZ.PRODUCT. PARAMETER
Set-up a limit and attach the a/c 22007335 to the above APP.

All in One Account

Figure 64 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

Figure 65 ADI RECORD OF AZ. ACCOUNT 22007335

The interest amounts of USD388.89, 375.07 and 361.25 were capitalised for the dates 30th, 31
st
Dec
and 1
st
J an.

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

Figure 66 RATE CHANGE MADE TO AC NO..22007335

Figure 67 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

Figure 68 TERM PRIORITY IS FLAGGED AS YES
The maturity date remains the same but the repayment amounts have been amended.

Figure 69 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. PRI NCI PAL. 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
interest
@25%
Already
capped
Difference
10.01.04 Capitalised @10% on 300000 now
recast amount is 200000 due to
back dated repayment.
2300
(With PR @
200000)
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

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

NO YES

All in One Account

CHECK
INTEREST TYPE

Fixed, BI key and
Fixed Floating type

YES

Accounting for INTEREST
ADJUSTMENT

YES

Already Capitalised Interest under
INTEREST ACCRUAL

SET UP
ONLINE
AT COB
END

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

Figure 70 FOR A NON REDEMPTION TYPE WHEN LOAN REPAYMENT IS INPUTERROR 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 cant 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 PRI NCI PAL. TXN code

AZ. PRODUCT.PARAMETER LBTFLOAT is linked to AZ. ACCOUNT 35858

AZ.PRODUCT.PARAMETER


All in One Account

Figure 71 AZ. PRODUCT. PARAMETER WITH TXN CODES.

All in One Account

Figure 72 AZ.ACCOUNT 22007351


All in One Account

Figure 73 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 PERI ODI C. I NTEREST
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

All in One Account
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.

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.I NT.FQU. It is possible to define interest credit based on Anniversary or Calendar
method under CR.I NT.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.

Figure 74 AZ.DEPOSIT PARAMETER OF TYPE FIXED


All in One Account
Maturity Process
The maturity instruction for Fixed Deposit can be defined in the Product Parameter under
MATURI TY.I NSTR. 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.

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.
It is now possible to define in the AZ.ACCOUNT, interest schedules for a Fixed Deposit after a
rollover has taken place by inputting the frequency in two new fields in the AZ.ACCOUNT which are
ROLL. I NT. CAP. FQU and ROLL. I NT. PAY. FQU. The following values are permitted Dnn, Wnn and
Mnn.

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 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.


All in One Account
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 LI AB 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.
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.

All in One Account
The R schedule trigger is in turn based on the input made in the newly introduced field RATE.PERI OD
in AZ.PRODUCT.PARAMETER.

Figure 76 - AZ.PRODUCT.PARAMETER

In the above example, RATE.PERI OD 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

Figure 77 - AZ.ACCOUNT

As the RATE.PERI OD 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 I NTEREST.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 I NTEREST.RATE field. The rate will be effective from the date appended to the BI
record ID.

All in One Account

Figure 78 - BASIC.INTEREST

Any subsequent changes in the I NTEREST.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.
TTS 0551371
New Fields
The following are the new fields introduced in the enhancement.

Name of New field APPLICATION Description

RATE.PERI OD


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.

OVERRI DE


A new field to store any
override. For ex., the field
RATE.PERI OD can t be >
t han t he MAXI M.TERM
Field. In case of such input
the system throws an
override-, which is stored in
this field.


All in One Account
RATE.PERCENT
( Revi sed
def i ni t i on
modi f i ed i f i t i s
f i xed- f l oat i ng)
AZ.PRODUCT.PARAMETER For Fixed-Floating type this
field should have value 100
only - or else an error will be
populated. For deposit types
other than Fixed-Floating it
can hold any value with a
maximum of 100.

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.PERI OD field in

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-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.


All in One Account
In AC.AUTO.ACCOUNT application the I NHERI TED 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.

Figure 79 -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 REDEMPTI ON should be flagged as yes if the particular AZ product has part
redemption as a feature. If input as N then part redemption cant 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.
MATURI TY I NSTRUCTI ONS fieldcan 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 madethen 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

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 cant 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
GLOBUS date.
The details of sub a/cs belonging to an AZ main a/c can be seen from

All in One Account
AZ. Active. Sub. Acc table

Figure 82 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.

Figure 83 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
[Deposit 1]
15000USD NO sub a/c will be
created the balance in
main a/c will become
-5000 USD
11000 USD
[Deposit 2]
-5000 USD Sub a/c will be created
for only 6000 USD after
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. I NT 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

PART REDEMPTION
{Through AZ account}

[This is an Interactive process]

The customer can indicate his
Meaning: - Withdrawing a part of the deposited amount
either from one or more of the sub a/cs.
This can be done in two ways
(1) Either at AZ. Main a/c using the field
(a) Redemption Amount
(b) Sub AZ Acct
OR

All in One Account
choice of accounts, which need
to be used for part-redemption
At the sub AZ acct level.
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]

Figure 84 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/cs 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 customers choice) a particular AZ sub a/c is selected and amount of part
redemption is specified in the REDEMPTI ON 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

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

All in One Account
withdrawal. [See help text of the field for further explanation]
Early Red int This is populated from EARLY. RED. MARGI N 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

PRE-CLOSURE

OR

Before Maturity Closure

Meaning: - Complete closure of deposit before it attains the
maturity date. This can be either one sub a/c or all the sub a/cs
put together along with the main a/c.

This can be achieved either through AZ a/c or through Non-AZ
process as Teller [Teller part is dealt with separately]

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. I ND 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

Figure 85 AZ. MAIN A/C FOR PRE-CLOSURE

Figure 86 AZ. ACTIVE SUB A/C
Note: - AZ.ACTIVE.SUB.ACC application gives the list sub a/cs that a main a/c
has.

In our present illustration the main a/c 37524 has 3 sub a/cs 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/cs including
the main a/c.

Figure 87 SETTING PRE-CLOSURE INDICATOR AS Y

All in One Account

Figure 88 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/cs 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

Figure 89.AZ. SUB /AC
At the sub a/c level the PRE CLOSURE I ND field is input as Y

Figure 90 SETTING THE PRE-CLOSURE IND AS Y
The screen shot of pre-closed contract of 37526

All in One Account

Figure 91 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 char ge. l i q. 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 MATURI TY I NSTR field in the AZ
Product Parameter application is automatic rollover
OR
Credited to Nominated a/c if the MATURI TY I NSTR 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

Figure 92 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 cant be identified.


All in One Account

Figure 93 TELLER INPUT-FOR CREATION OF AZ SUB A/C FOR DEPOSIT
On committing the above TELLER the system has created a sub account, a/cs 22007346 as shown
below: -

SUB a/c No.1


All in One 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

Figure 95 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

Figure 96 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/cs should be given to the exact amount. If the amount input is not
equal to the total of the sub a/cs then error will be raised. . A suitable override that all the a/cs
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

Figure 97 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

Figure 98 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

The MULTI field in AZ.PRODUCT.PARAMETER (APP) should be flagged as YES

All in One Account

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 I NHERI TED 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

Figure 99 -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 REDEMPTI ON 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 cant be different or changed
MATURI TY I NSTRUCTI ONS fieldcan 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

Figure 100 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 doesnt 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

Figure 101 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

Figure 102 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

Figure 103 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

Figure 104 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.

Figure 105 AZ. ACCOUNT HIST RECORD

Roll over of deposits
If the repayment type is Savings plan- then rollover of deposits is not permitted.


All in One Account
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.

Figure 106 COLLATERAL RIGHT APPLICATION
Then in collateral in case of multi deposits the sub a/c may be inscribed as shown

Figure 107 COLLATERAL APPLICATIONS
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


All in One Account

Figure 108 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 DEPOSI T. 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.

All in One Account

Figure 109 ACCOUNT PARAMETER - SET UP

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.

Figure 110 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.


All in One Account

Cleared

AZ sub account Credit

Returned

Return suspense account Credit.

Figure 111 CLEARING ENTRIES INDIRECT CREDIT
For instance, when a teller transaction is input for crediting AZ account with 25000 through clearing.

Figure 112 CHEQUE COLLECTION RECORD
When CHQ. STATUS of the CHEQUE.COLLECTION record is deposited, the entries generated would
be as follows:

Figure 113 ENTRIES - DEPOSITED STATUS
When the CHQ. STATUS is changed to Cleared,

Figure 114 ENTRIES - CLEARED STATUS

All in One Account
The sub account so created, will contain the VALUE. DATE and MATURI TY. DATE as defined in the
TELLER and as it appears in the CHEQUE.COLLECTION record.

Figure 115 AZ SUB ACCOUNT
When the CHQ. STATUS is changed to Returned,

Figure 116 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)

Figure 117 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:


All in One Account
Cheque Status Statement Entries

Deposited

Sub account Credit.

Cleared

No entries would be generated.

Returned

Sub account Debit
Return suspense account Credit.

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

Figure 118 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.

Figure 119 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

Figure 120 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

Figure 121 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)

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).

All in One Account

Figure 122 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.

Figure 123 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,

All in One Account
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

Represents tax
on charge.
Figure 124 AZ.SCHEDULES - TAX ON CHARGE & INTEREST
Represents tax
on 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.


All in One Account
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 LI QUI DATI ON 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 :
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.

Figure 125 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 I NT 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.

All in One Account

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.

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]


All in One Account
Figure 126 ELIGIBLE INT CR

Interest has already been paid for 2 days at 6.9063%.
[10000 x 6.9063% x 2/360 =3.84]
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.

Figure 127 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.

Figure 128 DEFINING PERIODIC INTEREST


All in One Account

As shown in the above figure, PI METHOD can contain values as Interpolate, Next & Previous.

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 I NT 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.

All in One Account

Figure 129 AZ.PRODUCT.PARAMETER - MULTI DEPOSIT

Partial withdrawal of the sub account can be done either by specifying the amount in REDEMPTI ON
AMT in sub account or by defining account . REDEMPTI ON 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

Figure 130 ACCRUAL REVERSAL
For the amount withdrawn interest at the eligible rate (contracted rate penal rate) is capitalised
immediately and credited to the nominated account.

All in One Account

Figure 131 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,
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:


All in One Account

Figure 132 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.

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.


All in One Account

Figure 133 ENQUIRY STMT.ENT.BOOK AFTER PRE-CLOSURE

Example : 5:

Interest rate 10%, eligible int.rate 6%


All in One Account
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:

Figure 134 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

Figure 135 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

Figure136 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 GLOBUS 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

Figure137-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

Figure138- 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 cant 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

Figure139-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. I D 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.ACCOUNTs 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

Figure140 PGM FILE RECORD FOR THE INTEREST CALC ROUTINE
Step 2: - Attach the routine in AZ. PRODUCT.PARAMETER application in the newly introduced 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

Figure141 ATTACHINGTHE ROUTINE TO THE AZ.PRODUCT.PARAMETER

All in One Account
The field EARLY. RED. MARGI N 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%

Figure142- 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 I NT 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

Figure143 THE EARLY REDEMPTION BEING OVERWRITTEN WITH THE ROUTINE RATE

The 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%

Figure144 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%
Figure145- 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 under this development.

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 LI AB TO PENALTY field the system will automatically calculate the
penalty for defaulted instalments once it crosses the input made in LI AB TO PENALTY field. The
calculation of penalty also starts from the day the instalments have become due hence this
development.

The field grace period is already existent in application AZ. PRODUCT. PARAMETER, for loan type
contracts. In loans this field is open for input if the field APPLY PENALTY is flagged as Yes.

AS part of this development GRACE PERI OD field has been opened up for input if the REPAYMENT
TYPE field is Savings plan. For fixed deposit type this field continues to be No input field.


All in One Account

Figure146-AZ. PRODUCT.PARAMETER FOR SAVINGS PLAN TYPE
Field GRACE. PERI OD 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 PERI OD 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 newly introduced 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 arent in tandem. For ex: - the Deposit frequency cant 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
days
Liab to
penalty
Bonus
eligible
Penalty charge Date for
penalty
10.2.04 not paid N.A. 1 NO NO 10.2.04$
11.3.04-not paid N.A. 1
(Already
defaulted
February)
NO Yes 11.3.04$

$The penalty
will be
calculated from
B schedule
date
Grace days not
applicable and
will be ignored.

Af t er t he
pr esent
devel opment

B schedule date Grace
days
Liab to
penalty

Bonus
eligible
Penalty charge Date for
penalty
10.2.04- not paid 2 0 Yes if bonus
on arrears field
in APP is
flagged as
Yes. If no
bonus is
payable.
Yes- as liab to
penalty is 0
12.2.04#- date
of B schedule
plus the Grace
days.
11.3.04- not paid 1 2 * DO * No as liab to
penalty is
permitted up to 2
instalments.
12.3.04#
#Here the
calculation of
penalty will be
B schedule

All in One Account
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 PREMI UM 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.

LI AB TO PENALTY is another field which determines whether bonus is payable or not. The field
takes a numeric and implies the no. of instalments that the customer can miss to avoid the penalty
class. However, any count to the field LI AB 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 LI AB TO PENALTY field still the bonus will be paid based on the flag set
in new field BONUS ON ARREARS. The process flow of the development is as below

AZ.PRODUCT.PARAMETER: -


All in One Account

Figure147AZ. PRODUCT. PARAMETER

New fields Permitted inputs Remarks
Bonus Cr A valid credit txn
code i.e. debit cr
marker flagged
as cr.
The txn codes are indicative of the type of transaction that
is passed through the AZ account. When ACCT. SYNC is
yes these fields are mandatory.

BONUS on
(1) Principal
(2) Interest
(3)
If the input were Principal, the bonus calculation would
be based on the principal amount.
If the input were interest, the bonus calculation would 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 LI AB 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
(2)
If flagged as yes- even if the customer misses
instalments not exceeding the input in LI AB TO
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.

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, raiseing 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 drawdowns made under
Credit Card and the different interest rates governing such withdrawals.

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


All in One Account

Flow to Credit Card

STOCK.PARAMETER
The application presently accepts CHQ, BCHQ, DRAFT, FDR and CARD.

STOCK.ENTRY
The application has been built to handle stock management. The enhancement has permitted 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.

All in One Account
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.

Figure 161CARD.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.

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.

All in One Account

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.

Figure 162 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 PRI NCI PAL field of the sub a/cs inscribed with amount so drawn.

The PRI NCI PAL 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.

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.

All in One Account
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 LI MI T. REFERENCE.

Limit creation for customer 1002

Figure 163 LIMIT SETUP

Attaching LIMIT to Account:


All in One Account

Figure 164 ATTACHING LIMIT TO ACCOUNT
Make a card issue to the 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.
Figure 165.CARD ISSUE TO ACCOUNT 37354

All in One Account
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".

The APP is set for card type AMX1.
APP needs to be set for revolving,
Non-revolving and Ranged Rev etc.
Figure 166 - AZ.PRODUCT.PARAMETER SETUP FOR CARD AMX1

In application AZ.PRODUCT.PARAMETER many new fields have been introduced which is
elaborated here under.

Field Name Field definition/utility Permitted Input
Loan. Deposit For CREDIT CARD it is ONLY LOAN

Loan or Deposit- Only
Loan
Minimum Amount For any loan or deposit if there is ANY Any valid Amount can

All in One Account
restriction on the amount to be drawn in loan
or amount of deposit in case of depositsthen
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.
be input.
Rate of Interest Rate of interest can be input and can be
overridden at the AZ.ACCOUNT level using
the INTEREST rate or DD. Int. Rate fields.
The system first looks at DD. I NT. 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.
Interest rate
indicating %age
Drawdown type As repay type is credit card, there cant be
restriction on number of drawl
By default, it takes 1
full drawdown.
Multi This field indicates whether multi- accounts
(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.
Permitted input Y or
N
Account. Sync A mandatory input if Repayment. Type is
Credit. Card. If Y then the working balance
in account and the principal field in respective
AZ sub-account will be same at any given
point. If N then sync between the balances
will not take place. Input in the field is a
mandatory.
Y or N- for credit
card it is YES ONLY.
[If the previous field
multi is YES]
Interest Only Is always NO- as on the given date both
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.
Y or N N for Credit
card
PD Link to AZ If the flag is set as Y then PD link to AZ will
be established. However, the trigger to PD
link is established ONLY when a repayment is
attempted on the AZ main account for the CI,
C and CC schedule amount generated after
the REPAYMENT date. If the repayment
made is less than what is demanded through
the CI, C and CC schedules PD is created
automatically for the remaining amount.
Values Y or N- if no
then PD will not be
created. For credit
card it is YES ONLY.
If this is setup as Y-
then at account level
the field Liq.mode
should be set as
Semi automatic.
Card Type Any valid card type can be attached. When
attached the inputs in that card type i.e. bill
close/repay date will act as the trigger for
generating CC schedules & PD link- when a
repayment is attempted.
Any valid card type
may be entered.
Repayment Type If this field has to be Credit Card. If not the
generation of sub accounts would not be
possible.
Has to be
Credit card ONLY.


All in One Account
Appropriation Type Options available (1) Proportionate (2) FIFO.
Under option (1) the repayments received is
spread over different withdrawals based on
outstanding. Under option (2) it is based on
the date of withdrawal i.e. first drawn should
be paid first then second drawl etc.
TO ILLUSTRATE:
For example if there are 3 draws through sub
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.
1. Proportionate
2. FIFO
For non-redemption,
this has to be set as
FIFO.

Revolving Ratio

Inputs in this field indicate the product is a
REVOLVING type. Input permitted is Numeric,
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-
100000, 120000 and 200000. If revolving
ratio fields has an input of 10%- then CC
schedules will be raised for (1) 10000(2)
12000 & (3) 20000 on the bill close date. A
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 whereby10% 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
Numeric input which
represents as a %age

For Non-redemption
Type this has to be set
as 100%[as the entire
o/s is payable in one
bullet payment.


All in One Account
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
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
Amt.Percent. Input in this field indicates the
product is RANGED-Revolving type. It is an
associated multi value set. We can define
here different %age or a flat amount for
different range of amounts. The total
outstanding is combined to arrive at the range
within which it falls. Amt. percent field may
contain either a %age or an amount, which is
applied as the repayment subject to the
minimum repayment clause stipulated.
Ranged revolving *10%
Highest Range 100000
Amt. Percent B*100
Amt. Percent *10
Amt. Percent *20

Some validations: -

(1) * Before the numeric entered in amt.
percent is must or else the system will deem
Multi-value set where
you can define the
range for the ranged
revolving type.
Whenever any amount
is mentioned in
Amt.Percent field it is
to be taken as LOCAL
currency
For example: -
Local currency is USD.
Amt.Percent field is
mentioned as 200000.
AZ account is in
currency GBP. When
repayment is made
FIRST the repayment
amount will be
converted to USD and
will be matched with
Amt.Percent field
where amount is
mentioned then if it is
equal to it then it will
reconverted to GBP
and will be adjusted to
the balance
outstanding in GBP. If
the amount is Less

All in One Account
it as amount and will generate CC schedule
for only10 and not 10% of the outstanding.

(2) B*100- implies 100% of the balance in
the account. This is because when the O/S
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
O/s in the account may be say 98573/- in that
case CC schedule amount will be more than
the O/s that is actually payable if we stick to
the concept of 100000 minimum. To obviate
this-we have introduced the concept 100% of
the balance O/s or 100000.

What happens if the combined amount of O/s
doesnt fit into any specified range
This will be decided by the type of input made
in the field Amt. Percent. For ex:

Amt. Percent *10
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.]
then the required
amount mentioned in
the field the required
amount will be taken
as the base and will be
converted to equal
amount in GBP and
will be adjusted to
outstanding.

Unless mentioned
wherever amount is
mentioned it should
be read as local
currency and not the
currency of the
account.

All in One Account

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
AMOUNT OR percentage can be gauged
from the above ex;-]
CC Pr Grace Period

Input when the AZ. Product Parameter is
Non-Redemption type.
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.

Valid input numeric.

Figure 167.AZ.ACCOUNT


All in One 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.

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
[Loan Drawdown
transaction]
76
[This transaction
code indicates that it
is a loan drawdown
and a debit to loan
account]
Internal/customer
ACCOUNT
51
CASE-2- in a Loan Repay is made then Debit is to the REPAY account and Credit is to the
Loan account
Internal/customer
[Loan Repay
transaction]
1 Loan Account 915

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.


All in One Account

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:-

[For FT similar set up need to be done before embarking on draw down /repayment etc as done
for teller application.

Figure 149 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:

Figure150 - TELLER.TRANSACTION (loan repay set-up)

All in One Account

After setting up the APP, the main AZ Account should be created by attaching an
AZ.PRODUCT.PARAMETER. The PRI NCI PAL 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.

Figure 171- AZ. ACCOUNT

Field Name Permitted Inputs Remarks
All in one Product Any one of the product parameters
created i.e.
(1) Revolving ID -1250
(2) Ranged Revolving-ID-1350
(3) Non-redemption- ID-1450 can
be inscribed here.
Selection of the APP
indicates the type of
product for which the
account is created, which
will be governed by that
product parameter.
Principal Should be ZERO for main account This is because for credit
cards, there is no upfront
disbursement and the
customer is given the

All in One Account
facility to draw the
amounts as and when
required Every drawl is
considered as an
individual account with
interest rates ruling on the
date.
Orig. Principal Every drawdown made creates a
sub-account. This field is inscribed
with the Drawdown amount and the
principal after every repayment on
any given date is inscribed in the
PRI NCI PAL field. In Short Orig.
Principal implies the amount
actually DRAWN and PRINCIPAL
field implies amount actually
payable after adjusting the
repayments made so far.
This field is on the SUB
account

The input is AMOUNT in
numeric.
Value and maturity
date
Value date can be input within the
permitted max. Back value date.
Nevertheless, NO maturity Date.
No maturity date
because credit card
process is a continuous
one until it is cancelled.
Interest Rate & penal
rate
The interest rates are mentioned in
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. I NT. 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
account
This field should be input with either
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
charges are General charges.
Drill down menu for
different charges available.
Drawdown- Amount After the AZ account has already
been created. Any drawdown 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.
A must input when
drawdown is made.
DD int rate When drawdown is made through
AZ. Account using the drawdown


All in One Account
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
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
FT.CHARGE.TYPE will be defined
here.
The charge amount will be
based on the charge code.
The amount will always
represented in local
currency.
Charge date The date on which charges should
be taken. It has to be set as, repay
date only. Whenever the charge
date is input, a C schedule will be
created on the charge date in
AZ.SCHEDULE.
This charge date has to be
input by the user to
REPAY date
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.


All in One Account
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
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 J OB.
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
repayment through the AZ. Account
then this field is used.
The settlement priority and
other rules like
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
repayment is input here. For Credit
Card, the Repay date has to be
entered here- so that when if PD is
created when actual funds are
received, it will be created with this
value date as REPAY date.
If actual payment is
received after, say, 3 days
and if a PD is created,
then the PD will assume
this date (Repay date) as
its value date
Cancel Last Dd Drawdown is made using the
Drawdown Amount field. If such a
drawdown is to be cancelled then
For ex: - If it is made
through teller-then way out
to cancel the transaction is

All in One Account
this field is the way out and not
through any other mode.
to REVERSE the teller.
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
Non-redemption type- then the
period of GRACE given for
repayment of principal is populated
from the AZ. Product. Parameter.

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.).


All in One Account

Figure 172 - AZ MAIN ACCOUNT DRAWDOWN

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:

Figure 173 - 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 26
th
, the repay date is 27
th
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).


All in One Account
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

Figure 174- 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:

Figure 175 - TELLER TRANSACTION OF LOAN DRAWDOWN

All in One Account

Fields Remarks
Customer, Currency, Category, All in one
product
Are populated from the main account
automatically.
Principal The amount that is drawn is written to this field.
Whenever repayments are made the balance
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
Schedules, calculation base etc.
Are populated from the main account

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 APPROPRI ATI ON. 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:

Figure 176 - AZ.SETTLEMENT.PRIORITY

4. If drawdown is made through the drawdown field in AZ Main account, cancellation can be done
using CANCEL.LAST.DD field.

All in One Account

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.

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


All in One Account
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 accounts
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 for this SAR 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
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

Figure 177 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

All in One Account
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.

Figure 178 - 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

All in One Account

Figure 179 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,
committed interest (CI) and then to the CC amount. Since the amount paid doesnt even cover the
entire charges the system after affecting payment has raised a PD in the following way.

Schedule Outstanding Repayment
received
PD
amount
C amount 600.00 -500.00
[Repayment
received]
100.00
CI amount 53.52 53.52
CC amount 90000.00 90000.00
TOTAL 90653.52 Balance 90153.52

Category Principal Interest
PD
penalty
Handling
charge Withdrawal charge
Past due month before
previous 7 5 3
Past due previous month 8 6 4
Scheduled payment (current
month) 10
Remaining principal 11
9
2 1
15 14
17 16 New drawdown after close
19 18
None
13 12
Repayment Procedure
Repayment through AZ
Repayment through AZ account is done using fields
REPAY. AMT and REPAY. V. DATE

All in One Account

Figure 180 - AZ.ACCOUNT REPAYMENT THROUGH AZ

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.

Figure 181 SETTING UP TELLER. TRANSACTION FOR REPAYMENT OPTION


All in One Account
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 AZ product parameter.

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.

Figure 182 - 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
interest from the date of
drawdown until the
repayment date.
296
[150000*8.88*8/36000]

C schedules being
charges to be collected on
REPAY date.
500.00
REVOLVING RATIO-
applied to generate CC
schedule
10% -150000*10/100@

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.

All in One Account

[@-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.

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

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

All in One Account
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.

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

All in One Account

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

All in One Account

Uploaded by

Copyright:

Available Formats

TEMENOS T24

All in One Account

You might also like