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

TEMENOS T24 User Guide

Page 3 of 189

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

TEMENOS T24 User Guide

Page 4 of 189

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. ANNUITY, LINEAR and NONREDEMPTION. The loan type is defined in the REPAYMENT.TYPE field. For a description of these loan products refer to the User Guide on MORTGAGES.

A fourth REPAYMENT.TYPE option, ‘OTHERS’, is available. This repayment type does not adhere to the repayment rules of the other three products and enables you to define a loan with irregular repayments.

The fifth REPAYMENT.TYPE option is ‘CREDIT-CARD’. This type offers many features that are similar to a loan issued using credit cards. This does not offer all the features of a credit card.

There are two deposit products available, viz. SAVINGS-PLAN and FIXED. In FIXED the deposit amount is accepted in a fixed lump sum and repaid as fixed amounts either with interest accumulated or not. In SAVINGS-PLAN the deposit amount is accepted in a periodic basis and the principal is increased in a recurring manner till the end of a fixed term.

Defining parameters Each product may be allocated a specific category within the allowed range.

TEMENOS T24 User Guide

Page 5 of 189

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.

TEMENOS T24 User Guide

Page 6 of 189

All in One Account

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

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

EXAMPLE FOR COMBINED INTEREST

BASIC.RATE.TEXT

BASIC.INTEREST

AZ.PRODUCT.PARAMETER

@ID

1

DESCRIPTION

Base Rate

@ID

1USD20001120

INTEREST.RATE

4.5

@ID

1

RATE.KEY

1 Base Rate

RATE.SPREAD

2.5

RATE.OPERAND

ADD

RATE.PERCENT

70

INT.FIXED.RATE

10

For the above loan product a variable interest rate of 7% (4.5 + 2.5) will be applied to 70% of the balance and a fixed interest rate of 10% percent will be applied to 30% of the balance. This is an effective rate of 7.90% ((7*70%)+(10*30%)).

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

TEMENOS T24 User Guide

Page 7 of 189

All in One Account

Interest-Only Repayment Periods The field INT.ONLY allows the user to restrict the option of Interest-Only repayment periods during the term of the loan. If the value of this field is “N”, no Interest-Only periods may be applied in the loan account. If the value is “Y”, Interest-Only periods are optional in the loan account.

The field MAX.INSTL.INT.ONLY is only input if the value in INT.ONLY is “Y”. This value is the total period of time that the interest only repayment could be defined for a loan during the lifetime of a loan account.

Penalty Interest Penalty interest is the debit interest that is calculated on the value identified in the field PENALTY.ON, e.g. “1-Arrears” balance, of a loan account.

The user is able to flag whether or not penalty interest is to be applied for specific products. If the field APPLY.PENALTY is set to ‘N”, all loan accounts of this product will not have automatic calculation of penalty interest once the loan account is deemed to be in arrears.

The penalty interest rate is the result of taking the effective debit interest rate and applying a margin in terms of the operand instruction.

TEMENOS T24 User Guide

Page 8 of 189

All in One Account

Figure 2 Defining AZ.PRODUCT.PARAMETER

EXAMPLE

BASIC.RATE.TEXT

BASIC.INTEREST

AZ.PRODUCT.PARAMETER

TEMENOS T24 User Guide

@ID

1

DESCRIPTION

Base Rate

@ID

1USD20001120

INTEREST.RATE

4.5

@ID

1

RATE.KEY

1 Base Rate

RATE.SPREAD

2.5

RATE.OPERAND

ADD

RATE.PERCENT

70

INT.FIXED.RATE

10

Page 9 of 189

All in One Account

APPLY.PENALTY

Y

PENAL.OPERAND

ADD

PENAL.MARGIN

5

For the above loan product a variable interest rate of 7% (4.5 + 2.5) and the fixed interest rate of 10% percent determine an effective rate of 7.90% ((7*70%)+(10*30%)).

The penalty interest rate is thus the effective rate of 7.90% added to the penalty margin of 5, resulting in a penalty rate of 12.90%. Thus debit interest will be calculated at 7.90% on the specified loan account balance and penalty interest of 12.90% will be calculated on the arrears balance. The penalty rate is calculated by the system and defaulted to the no input field, PENAL.RATE. (Please Refer Figure 2). This penal rate defined in a Product Parameter is defaulted to the AZ accounts opened under that product. However, at account level it can be modified.

The user is able to define a number of days grace period, during which the borrower may make a late repayment, after due date, and during which the loan account will not be deemed to be in arrears. The number of days grace is entered in the field GRACE.PERIOD. This field provides information for the activation of two processes, viz. Penalty Interest and Arrears Management activation.

Grace Period & Penalty-Interest: If no repayment is received on the due date, the system will wait the number of days defined in the grace period, before it accrues penalty interest. If the repayment is made during the grace period no penalty interest will be accrued. If the repayment is not made, interest will be backdated to the due date and accrued for each day during the grace period. Penalty interest will be accrued each day thereon, while the account is in arrears.

Grace Period & Arrears Management: Any local Arrears Management application must be set up to check the grace period before it initiates arrears processes, e.g. spooling letters of demand, raising arrears charges etc. Where relevant, the arrears process should be set up to backdate to the due date, e.g. ageing of arrears.

EXAMPLE

BASIC.RATE.TEXT

BASIC.INTEREST

AZ.PRODUCT.PARAMETER

TEMENOS T24 User Guide

@ID

1

DESCRIPTION

Base Rate

@ID

1USD20001120

INTEREST.RATE

4.5

@ID

1

RATE.KEY

1 Base Rate

Page 10 of 189

All in One Account

RATE.SPREAD

2.5

RATE.OPERAND

ADD

RATE.PERCENT

70

INT.FIXED.RATE

10

APPLY.PENALTY

Y 7

GRACE.PERIOD PENAL.OPERAND

ADD

PENAL.MARGIN

5

PENAL.RATE

12.90

PENALTY.ON

1 Arrears

If an AZ.ACCOUNT loan is set up using the above loan product with the following conditions being in effect: •

Repayment due date

31 MAR 2001

•

Repayment amount

USD5000.00

•

Bank Date

7 APR 2001

•

Total Arrears amount

USD5000.00

•

Interest Basis

A 360/360

The EOD process on the 7th April 2001 will accrue interest for each day from the 31st of March, viz. USD5000*12.90%*1/360 = USD 1.79 per day.

Posting Restriction Posting restrictions can be used in All in One Product, for restricting certain features, for a particular product. For example, accounts opened under a product that has a posting restriction on debit transaction, will not have the facility of Redraw.

AZ.Account and AZ.Product.Parameter workflow AZ.PRODUCT.PARAMETER contains control and default value parameters. AZ.ACCOUNT fields belong to two logical groups, viz. Loan Inputs and Schedule Inputs. When opening a new AZ.ACCOUNT the first field to be input is the ALL.IN.ONE.PRODUCT value. This is the @ID of an AZ.PRODUCT.PARAMETER record. The system accesses the relevant AZ.PRODUCT.PARAMETER record.

TEMENOS T24 User Guide

Page 11 of 189

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, INT.ONLY and MAX.INSTL.INT.ONLY.

The values of these fields may be overwritten with new values at AZ.ACCOUNT level, thus providing for individual attributes for each loan, if required.

Validation of Loan Inputs Other fields will not be populated with default values, but the values input will be validated against control values on the AZ.PRODUCT.PARAMETER record, e.g. the value input in PRINCIPAL will be validated against the AZ.PRODUCT.PARAMETER values in MINIMUM.AMOUNT and MAXIMUM.AMOUNT.

Validation occurs either as field value restriction or override notification.

Default Schedule Inputs When entering Schedule Inputs on AZ.ACCOUNT, if an “R” type schedule is entered in TYPE.OF.SCHDLE, the interest rate values will be defaulted from the opened AZ.PRODUCT.PARAMETER record, viz. fields RATE.SCH.KEY, RATE.SCH.SPREAD, RATE.SCH.OPERND, RATE.SCH.PERCNT and SCH.FIXED.RATE.

The values of these fields may be overwritten with new values at AZ.ACCOUNT level, thus providing for individual attributes for each loan schedule, if required.

For certain REPAYMENT.TYPE in AZ.ACCOUNT at the inception of a new loan account, the user is not required to input an “R” schedule if the default AZ.PRODUCT.PARAMETER record values are to be used. In this case the default values will be defaulted when the system automatically generates an “R” schedule in AZ.SCHEDULES.

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.

TEMENOS T24 User Guide

Page 12 of 189

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.

Figure 3 AZ.PRODUCT.PARAMETER 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.

TEMENOS T24 User Guide

Page 13 of 189

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 customer’s LIMIT record. The LIMIT record is set up using the format “CUSTOMER.ID”. “LIMIT.REFERENCE.ID”. “Sequence Number”, e.g. 100138.900.01.

The values of Repayment amount, Frequency and Repayment Date are populated to the respective fields of the Limit record from the schedule of AZ.ACCOUNT for the purpose of reducing the Limit on the repayment dates. The system will compare the reduced limit (current Limit) amount with the Working Balance of the loan account, to arrive at the arrears. Redraw from the loan account will be permitted up to the Reduced Limit amount and any excess Redraw will bring an Override message. This provides non-revolving limit functionality.

If a revolving limit is required then the REDUCE.LIMIT field in AZA can be set to ‘N’. In this case the limit will not be reduced on the scheduled dates. If SINGLE.LIMIT in the ACCOUNT is set to ‘N’, i.e., more than one AZA shares the same limit, then all the AZA should have the REDUCE.LIMIT set to be the same.

Defining the AZ Loan (AZ.ACCOUNT) AZ.ACCOUNT fields belong to two logical groups, viz. Loan Inputs and Schedule Inputs. Loan Inputs are the parameters that define the basic conditions of the loan contract. The Loan Inputs are defined at the inception of the loan, with values either defaulted from / or controlled against AZ.PRODUCT.PARAMETER values. Certain Loan Inputs may be changed during the term of the loan also like change in rate of interest etc....

Schedule Inputs are the parameters that define the schedule of repayments that govern the management of the loan until maturity date. The Schedule Inputs may be fully or partially defined at the inception of the loan. They may also be explicitly defined by the user or, where permissible, be left for the system to be automatically defined. Additional Schedule Inputs may be added to the loan or amended after the inception of the loan, subject to stringent validation and control depending on the activity that has taken place on the loan prior to the amendment. Amendments to Schedule Inputs are explained in detail in the sections “Defining Loan Schedules – Schedule Inputs” and “Loan Variations”

It is not possible to create a back dated contract beyond the last capitalisation date of the account.

TEMENOS T24 User Guide

Page 14 of 189

All in One Account

Account Opening procedure Using AZ.ACCOUNT, the loan account is set up in ACCOUNT. The ACCOUNT record must be defined before the loan can be set up in AZ.ACCOUNT.

Using the ID of the corresponding ACCOUNT, the AZ.ACCOUNT has to be opened.

When setting up the customer account in ACCOUNT, AZ.ACCOUNT requires that the relevant LIMIT.REF value be entered. Furthermore, the LINK.TO.LIMIT field should not be entered as YES, as this may create an ADI record that may not be consistent with the existing ADI record of All in One account, which has the reducing limit concept.

Defining Nominated and Repayment accounts AZ.ACCOUNT allows for the loan account to be linked to non-loan accounts for the purpose of disbursing the loan funds and / or receiving electronic payments. The field NOMINATED.ACCOUNT, is used for identifying the drawdown account to which the funds are to be disbursed. The associated fields NOM.INT.BANK, NOM.BEN.BANK and NOM.BEN.ACCT are used to provide further information for external nominated accounts at other financial institutions.

The field REPAY.ACCOUNT is used for identifying the repayment account from which loan repayments are to be received. If a valid account is defined under REPAY.ACCOUNT then the system will take care of transferring the repayments on the COB of scheduled dates, if funds are available. The associated fields REP.INT.BANK, REP.BEN.BANK and REP.BEN.ACCT are used to provide further information for external repayment accounts at other financial institutions. Debiting the Nostro account defined under REPAY.STO.ACCOUNT enables standing order generation. Based on the days defined under DAYS.BEF.EVENT MT 104 message will be generated to the external bank.

The accounts identified for NOMINATED.ACCOUNT and REPAY.ACCOUNT may be internal customer accounts, Nostro accounts or internal clearing accounts. Where the account is an external account at another financial institution the account must be an internal clearing account.

AZ.ACCOUNT will post transactions to the nominated and repayment accounts as the relevant events are triggered. The application used to process the transactions to / from external accounts at other financial institutions must be set up to post the necessary debits and credits against the internal clearing accounts. The same application must be set up to retrieve the associated information in the fields XXX.INT.BANK, XXX.BEN.BANK and XXX.BEN.ACCT for passing on to the clearing system for the external account at another financial institution.

In loan or deposit products if NOMINATED.ACCOUNT or REPAY.ACCOUNT is not defined then

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

TEMENOS T24 User Guide

Page 15 of 189

All in One Account

TELLER the correct transaction code needs to be used on the side where AZ.ACCOUNT is populated is to identify the correct transaction. It is now possible when performing a part redemption on an AZ.ACCOUNT Fixed Deposit through TELLER to specify if a TELLER.DEFAULT record is to be created or not. This must be stipulated in the AZ..PRODUCT.PARAMETER in field CREATE.TD.FOR.INT.

Figure 4 AZ.PRODUCT.PARAMETER If this value is YES then a TELLER.DEFAULT record will be created when a TELLER transaction is processed debiting an AZ.ACCOUNT Fixed Deposit. This will only be created when no nominated/interest liquidation is specified on the AZ.ACCOUNT. If the field CREATE.TD.FOR.INT is NULL the interest will be credited to the credit side account irrespective of it being the till account.

Loan Principal and Drawdown options The value of the loan is defined in the field PRINCIPAL. Depending on the value selected in the AZ.PRODUCT.PARAMETER field DRAWDOWN.TYPE, the loan amount may be disbursed either as one full drawdown amount or as multiple partial drawdown amounts.

Full Drawdown If the value selected in the field DRAWDOWN.TYPE on the AZ.PRODUCT.PARAMETER record is “1 FULL DRAWDOWN” then the user may only enter the full loan amount, i.e. the Principal, in the field DRAWDOWN.AMOUNT.

When this value is entered the user is required to enter the drawdown date in the field AMOUNT.V.DATE. When the record is committed the field FINAL.DD.IND will be auto populated with the value “Y”, and this field will be a No Input field.

If this field is entered the AMOUNT.V.DATE must be equal to the loan VALUE.DATE. This field should only be entered when there is no NOMINATED.ACCOUNT identified for the borrower. Once the AZ.ACCOUNT record is authorised, the draw down amount will be set up in a TELLER.DEFAULT for manual processing.

TEMENOS T24 User Guide

Page 16 of 189

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 PARTIAL & NO INT” or “3 PARTIAL & NO INT” then the user may enter an amount less than or equal to the loan amount, in the field DRAWDOWN.AMOUNT.

When this value is entered the user is required to enter the drawdown date in the field AMOUNT.V.DATE.

The same rules apply in respect of “B” type schedules and nominated accounts, for Partial drawdown amounts as do for Full drawdowns.

If a schedule has to be defined during the Partial drawdown period, ‘SCHEDULED BALANCE’ is to be opted under the field CALCULATION.BASIS. For more details relating to CALCULATION.BASIS, please refer to Chapter 11 on ‘Defining Loan Schedules – Schedule Inputs’.

First and Subsequent Partial Drawdown The field FINAL.DD.IND will be an input field with no value. The user selects the option “N” to indicate that only a partial drawdown has been made. If the user sets up “B” schedules, the value in the field will remain empty.

TEMENOS T24 User Guide

Page 17 of 189

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 PRINCPAL amount the system will recognise that full drawdown has taken place. Similarly, if the user is using “B” type schedules to set up the drawdown, once the total value of all the drawdown amounts and “B” schedule amounts is equal to the PRINCPAL value, the system will recognise that full drawdown has been scheduled.

Once the final drawdown is established the system will set the value in FINAL.DD.IND to “Y” and the field will become a No Input field.

If, when entering a partial drawdown amount, the user decides that adequate funds have been drawn for the loan, i.e. the total of all drawdown amounts is less than the PRINCIPAL, then the user may select the value “Y” in the field FINAL.DD.IND. This will have the effect of manually forcing a final drawdown. When the record is committed, the loan amount PRINCIPAL will be reduced to an amount equal to the value of the total drawdown amounts.

Residual on Principal The loan product may allow the borrower to pay a portion of the principal amount as a lump sum on maturity of the loan. This amount is the residual and the value is entered in the field RESIDUAL.PRINCIPAL.

Once the Residual Principal is defined, it cannot be changed subsequently.

While calculating the repayment schedule for Principal portion, the Residual portion will be excluded and the schedule will be defined for the remaining amount as per the frequency. The Residual Principal will be defined for repayment on the maturity date. Interest is calculated on the full balance including the Residual principal. A repayment that includes a portion of the interest repayment will include the interest calculated on the residual balance.

(The payment of Residual Principal at the maturity date is called as Balloon Repayment)

EXAMPLE For a loan with the following attributes: •

Principal

USD100,000.00

•

Residual Principal

USD25,000.00

•

Fixed Interest Rate

10%

•

Repayment Type

LINEAR

•

Frequency

Monthly

•

Term

3 Months

•

Calculation Base

Schedule Balance

TEMENOS T24 User Guide

Page 18 of 189

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) 2. USD 25,000.00 Principal + USD 625.00 Interest (USD 75,000.00 * 10% * 30 / 360) 3. USD 25,000.00 Principal + USD 416.67 Interest (USD 50,000.00 * 10% * 30 / 360)

On maturity date the borrower will repay the residual balance of USD 25,000.00.

This is allowed only for ‘PRINCIPLE’, CURRENT BALANCE and ‘SCHEDULE BALANCE’ as the calculation base. It is not allowed for NON REDEMPTION and OTHER types of loan. As in OTHER type of loan the system will ask for the P schedule amount to be input. The drawdown amount should be greater than the residual amount.

Defining Repayment types AZ.ACCOUNT allows the user to define loans with multiple repayments or with a single bullet repayment on maturity.

There are three basic loan products available in this module, viz. ANNUITY, LINEAR and NONREDEMPTION. The loan type is defined in the REPAYMENT.TYPE field. For a description of these loan products refer to the User Guide for MORTGAGES.

A fourth REPAYMENT.TYPE option, ‘OTHERS’, is available. This repayment type does not adhere to the repayment rules of the other three products and enables you to define a loan with irregular repayments.

The fifth REPAYMENT.TYPE option is ‘CREDIT-CARD’. This type offers many features that are similar to a loan issued using credit cards. This does not offer all the features of a credit card.

There are two deposit products available, viz. SAVINGS-PLAN and FIXED. In FIXED the deposit amount is accepted in a fixed lump sum and repaid as fixed amount either with interest accumulated or not. In SAVINGS-PLAN the deposit amount is accepted in a periodic basis and the principal is increased in a recurring manner till the end of a fixed term.

Bullet Repayments The repayment of a loan in a single bullet payment on maturity, by definition, means that no repayment schedule is required. In order to define a bullet repayment type loan, the value “N” is selected in the field SCHEDULES.

TEMENOS T24 User Guide

Page 19 of 189

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 borrower’s requirements.

EXAMPLE: For an ANNUITY loan with multiple partial drawdown amounts, where the final drawdown will take place at an unknown date in the future, the loan REPAYMENT.TYPE may be changed from “ANNUITY” to “NON-REDEMPTION” for the initial loan set up. In this scenario the loan will be set up for Interest only repayments on the known partial drawdown balance, with the full principal repayment due on maturity. As each subsequent partial drawdown is made, the Interest only repayment will increase. Once the final drawdown is made the user changes the REPAYMENT.TYPE to “ANNUITY” and the full ANNUITY schedule is defined.

When entering Schedule Inputs to define the loan schedules, the REPAYMENT.TYPE selected will initiate specific Schedule Input validations.

The value selected in CALCULATION.BASE should be consistent with the REPAYMENT.TYPE.

TEMENOS T24 User Guide

Page 20 of 189

All in One Account

Figure 5 Defining Repayment type in AZ.ACCOUNT

TEMENOS T24 User Guide

Page 21 of 189

All in One Account

Figure 6 Defining Repayment types in AZ.ACCOUNT

TEMENOS T24 User Guide

Page 22 of 189

All in One Account

Figure 7 Defining repayment types in AZ.ACCOUNT

Defining Interest Only Periods The field INT.ONLY allows the user to restrict the option of Interest-Only repayment periods during the term of the loan. If the value of this field is “N”, no Interest-Only periods may be applied in the loan account. If the value is “Y”, Interest-Only periods are optional in the loan account.

A default value is populated to this field from AZ.PRODUCT.PARAMETER. The user has the option of changing the value and will receive an override notification message when committing the record if the value entered is different to the value on AZ.PRODUCT.PARAMETER. If it is required that user be prevented from changing the default this restriction must be defined during system set up.

If the value in INT.ONLY is “Y” then a value must be entered for the field MAX.INSTL.INT.ONLY. This value is the total period of time that the interest only repayment could be defined for a loan during the lifetime of a loan account.

TEMENOS T24 User Guide

Page 23 of 189

All in One Account

The input value may be entered as a number of days or a number of periods, where a period is the time between the repayment due dates, in other words, the number of instalments.

These fields define the scope of Interest Only repayment periods for the loan at AZ.ACCOUNT level. There is no definition determining the number of times that Interest Only repayment periods can be defined during the term of the loan, nor the duration of any individual Interest Only repayment period, provided the total of all periods is within the maximum number of periods defined in MAX.INSTL.INT.ONLY.

The determination of when an Interest Only repayment period will be applied, and the duration thereof, is defined when entering the Schedule Inputs.

In the case of AZ loans with repayment type as ‘Non Redemption’, validations with respect to MAX.INSTL.INT.ONLY will not be done.

Defining Loan Schedules – Schedule Inputs The loan schedules are predominantly concerned with defining the components and time periods that are to be used in calculating the repayment amount due on the loan until the due date. The exception is the “B” schedule, which is concerned with the disbursement of the loan funds. The types of schedules entered will be governed by the value input in the REPAYMENT.TYPE field.

The Schedule Inputs are the macro level definitions that are passed to the AZ.SCHEDULES application where each repayment will be calculated for each repayment due date.

If the value in the SCHEDULES field is “Y” then a minimum of one schedule type will be mandatory. The REPAYMENT.TYPE value will also determine which schedule types may be mandatory. In some circumstances an “I” “N”or “P” schedule type need not be entered as the system will determine from the REPAYMENT.TYPE that the schedule is required and use the AZ.PRODUCT.PARAMETER default values to generate the necessary schedule.

Multiple Schedule Inputs may be entered. Entering the relevant value in the field TYPE.OF.SCHEDULE, for each multi-value, identifies the schedule being defined.

Each multi-value is made up of a group of associated fields, viz.

•

TYPE.OF.SCHEDULE

•

AMT.PERCENT

•

AMOUNT

•

FREQUENCY

•

NUMBER

TEMENOS T24 User Guide

Page 24 of 189

All in One Account

•

RATE.SCH.KEY

•

RATE.SCH.SPREAD

•

RATE.SCH.OPERND

•

RATE.SCH.PERCNT

•

SCH.FIXED.RATE

Depending on the REPAYMENT.TYPE and TYPE.OF.SCHEDULE input in some of these fields is mandatory, certain combinations of input are required and certain fields will be blocked from any input.

The AZ.SCHEDULES record stores the values of draw downs made so far, under the field NEW.AMOUNT, with corresponding dates.

The field CALCULATION.BASIS defines the basis for calculation of repayment amount for the term of the loan or for recalculation for the remaining term.

If 'Principal' is defined here, entire Principal amount will be taken into account, for deriving the repayment amount and interest calculations, irrespective of the amount of Principal drawn.

If 'Schedule' is defined, the amount drawn down till date will be taken into account for repayment amount and interest calculation purposes.

In Loans if SCHEDULES is set to 'N' then allowed value is 'Principal' or 'Schedule Balance'. In Deposits if it is of FIXED type then allowed value is 'Principal' else 'Schedule balance'.

If a repayment or an instalment is made online and a schedule exists for that day then the schedule will still execute during COB, e.g., if the B schedule is paid online the one in COB will still continue to execute.

Drawdown Schedule TYPE.OF.SCHEDULE = “B”

This type is used for effecting loan drawdown amounts on pre-defined dates. On the specified dates the system will transfer the drawdown amount to the credit of the nominated account. This type of schedule will only be allowed if a nominated account was defined in the Loan Inputs. The nominated account is required to enable the system to carry out the credit on the defined future date.

The associated fields entered for a “B” Schedule are AMOUNT and FREQUENCY.

TEMENOS T24 User Guide

Page 25 of 189

All in One Account

AMOUNT is the value of the drawdown and is validated to ensure that the total value of the amounts specified in all B schedules and the Drawdown amounts made to-date, do not exceed the Principal.

FREQUENCY is entered as a date only and identifies the date when the drawdown is to be affected. The drawdown will be processed at start of day on the specified date.

Multiple schedules may be entered for loans permitting multiple partial drawdown amounts.

Repayment Schedule – Annuity TYPE.OF.SCHEDULE = “A”

This schedule is allowed only for loans with an “Annuity” REPAYMENT.TYPE and is mandatory. This schedule will generate a repayment amount that remains constant through the term of the loan. During the period of the annuity schedule the interest portion of the repayment will reduce and the principal portion will increase.

In the case of a loan with only one “A” type schedule the loan balance after the last repayment due date will be zero, where there is no residual defined. In the case of a residual amount being defined the loan balance after the last repayment due date will be the residual amount.

Multiple schedules may be input for different periods during the term of the loan. Where multiple “A” schedules are defined, it is necessary for at least one “A” type schedule to be input, which includes the maturity date and brings the loan balance to zero (or the residual amount).

The associated fields entered for an “A” type schedule are FREQUENCY and NUMBER.

FREQUENCY may be entered as a date, where only one period is identified, viz. the final maturity repayment. In most cases date and frequency will be entered. The date portion identifies the date when the first annuity repayment is due. The frequency portion identifies the duration between repayment periods and determines the date on which repayment will be due. The system will process the repayment at end of day on the due date.

NUMBER is the number of repayment periods (instalments), for which the “A” type schedule applies from the schedule’s first repayment due date, and is an optional input. This value will generally only be entered when multiple “A” type schedules are input. The total number of periods and the frequency must coincide with the Loan Input MATURITY.DATE.

Annuity repayment schedule with amount as zero can be used for defining repayment holiday (Zero Repayment) period for the loan account for a fixed period.

TEMENOS T24 User Guide

Page 26 of 189

All in One Account

Repayment Schedule – Principal TYPE.OF.SCHEDULE = “P”

This schedule is used to define the amounts and due dates for the repayment of the principal portions of the loan.

This schedule is not permitted with “ANNUITY” REPAYMENT.TYPE loans.

The associated fields entered for a “P” type schedule are FREQUENCY and NUMBER.

FREQUENCY may be entered as a date, where only one period is identified, viz. the final maturity repayment. In most cases date and frequency will be entered. The date portion identifies the date when the first principal repayment is due. The frequency portion identifies the duration between repayment periods and determines the date on which repayment will be due. The system will process the repayment at Close of Business on the due date.

NUMBER is the number of repayment periods (instalments), for which the “P” type schedule applies from the schedule’s first repayment due date, and is an optional input. This value will generally only be entered when multiple “P” type schedules are input. The total number of periods and the frequency must coincide with the Loan Input MATURITY.DATE.

In the case of ‘OTHER’ type of Repayment method, AMOUNT field is used for specifying the amount of Principal Repayment. The system ensures that the sum of the amount entered on various dates, is equal to the Principal amount.

Repayment Schedules – Interest Interest Only Schedule TYPE.OF.SCHEDULE = “I” and “N”

These schedules are used to define the due dates for the interest capitalisation and interest collection.

Since ‘I’ schedule is only for the purpose of capitalising, the interest arrears processing will not happen based on this. Whereas in the case of ‘N’ schedule, since interest payment is expected from the customer, arrears processing and penal interest will happen based on account balance.

In the case of ‘I’ schedules, the system increases the banded amount of ADI and increases the limit to the extent of ‘I’ schedule amount to avoid penalty. For ‘N’ type, the ADI band and limit are reduced to the extent of ‘N’ schedule amount for arrears and penalty calculation.

TEMENOS T24 User Guide

Page 27 of 189

All in One Account

By defining ‘I’ schedules and ‘N’ schedules with different frequencies, interest compounding can be achieved. For example, if ‘I’ schedule is defined monthly and ‘N’ schedule is defined once in three months, the interest gets compounded on monthly basis for 3 months.

The associated fields entered for an “I” type and “N” type schedules are FREQUENCY and NUMBER.

FREQUENCY may be entered as a date only, to indicate the start of an interest repayment period. The date portion identifies the date when the first interest repayment is due for the particular schedule. The frequency portion identifies the duration between repayment periods and determines the date on which interest repayment will be due. The system will process the repayment at Close of Business on the due date.

NUMBER is the number of repayment periods (instalments), for which the “I”/ “N” schedule applies from the schedule’s first repayment due date, and is an optional input. This value will generally only be entered when multiple “I” type / “N” type schedules are input.

The total period of all “NI” type schedules are validated against MAX.INSTL.INT.ONLY defined in the Loan Inputs for the loan and an override message is generated if the total period exceeds the maximum.

In the case of ‘I’ and ‘N’ type schedules amount should not be entered.

Interest Rate Schedule TYPE.OF.SCHEDULE = “R”

This schedule is used for effecting Interest Rate revision on specified dates. When used at the inception of a new loan the schedule is used to provide the user with the opportunity override the default rates of the AZ.PRODUCT.PARAMETER record and to define interest rates specific to the loan being set up.

When used to amend an active loan the Loan Input value in TERM.PRIORITY will be taken into account when defining this schedule. If TERM.PRIORITY is defined as Y then, the maturity date will be retained and the change will be effected on the Repayment amount. If defined as N then the maturity date will be changed and the repayment amount will remain the same. Based on the value given for RECALC.CURR.AMOUNT, the changes will be effected in the current repayment period or the next one.

The schedule provides for the revision of the variable interest rate, the fixed interest rate and the ratio of the application of variable to fixed interest calculation on the outstanding balance.

The associated fields entered for an “I” type schedule are FREQUENCY, RATE.SCH.KEY, RATE.SCH.SPREAD, RATE.SCH.OPERND, RATE.SCH.PERCNT, and SCH.FIXED.RATE.

TEMENOS T24 User Guide

Page 28 of 189

All in One Account

FREQUENCY is mandatory and entered as a date only. The date identifies the date when the rate revision will take effect. The system will process the rate change at start of day on the effective date.

For RATE.SCH.KEY, RATE.SCH.SPREAD, RATE.SCH.OPERND, RATE.SCH.PERCNT, and SCH.FIXED.RATE the values are input in accordance with the rules explained in the AZ.PRODUCT.PARAMETER section, ‘Debit Interest Rates’, above.

EXAMPLE Example of an R type schedule:

Type of Schedule:

R

Frequency

20010522

Rate Sch Key:

1

Rate Sch Spread:

6

Rate Sch Operand:

Add

Rate Sch Percent:

60

Sch Fixed Rate:

15

As per the above R schedule, a rate revision will happen on 22-05-2001, with 60% of the outstanding amount by a variable interest (key1 and spread 6 on Basic Interest) and 40% of the outstanding amount by fixed interest 15%.

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

TEMENOS T24 User Guide

Page 29 of 189

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

Rebuilding schedules after an online repayment of annuity loan When INT.CORR.IMMED in the APP is set to “Current” correction interest on account of any backdated event (eg: drawdown, rate change, principal settlement) will be recovered immediately When INT.CORR.IMMED in the APP is set to “Next” correction interest will be parked in AZ INT ADJ Suspense account and collected in the subsequent repayment. “Next” can be set only for Annuity loans and only when ANNUITY.ADJUST is set to “Yes ” The field INT.CORR.RTN in the APP is a Hook field that can hold a local routine to get values for the field INT.CORR.IMMED. The local routine should be specified in EB.API application. AZ.SCHEDULES: “Online Amt “ in the schedules gets updated with N

- Interest component collected

P

- Principal component collected

I

- Int Adj Amt (on account of reversal of an online repayment) to be collected

S

- Correction interest (on account of backdated drawdown) to be collected

R - Int Adj Amt & Correction interest (parked in AZ INT ADJ Suspense account) collected during the next online repayment In case Int Adj Amt & Correction interest component is collected during a scheduled repayment then the same is added to “Type N”. When INT.CORR.IMMED is set to “Current” then Correction Interest collected is added to “N”

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

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

TEMENOS T24 User Guide

Page 30 of 189

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

TEMENOS T24 User Guide

Page 31 of 189

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 TERM PRIORITY as per requirement:

•

Change in Principal amount (Increase)

•

Change in Rate of interest

•

Change in Frequency

•

Change in Term

AZ.SCHEDULE record will contain the current values of the schedule attributes. In the case of change in Basic Interest attached to a loan account through an interest key, the system automatically reschedules the repayment. The field relating to reschedule notice period in Product Parameter, defines the number of days after which the reschedule will be effective, in the case of change in the Basic Interest rate attached to the account through a key. An option is available to specify whether the change has to be applied for the existing loans also or not.

The value for Term Priority defined in AZ.PRODUCT.PARAMETER account, for automatic rescheduling.

will be taken into

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

TEMENOS T24 User Guide

Page 32 of 189

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.

TEMENOS T24 User Guide

Page 33 of 189

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.LIMIT in AZ is set as 'NO' ACCT.SYNC is equal to “YES”

•

Interest adjustment allowed only for TODAY To differentiate between drawdown and Current Date Principal increase, LOCAL.TABLE and LOCAL.REF.TABLE to be set for updating LOCAL.REF field of STMT.ENTRY

When a user defines a repayment amount which is less than the interest repayment amount.

When the user makes a online advance repayment through TELLER or FT applications then on committing the TELLER or FT record, a local Post Auth Routine will be called from the version. Calling of this routine is dependent on the availability of Post Auth API in the VERSION/VERSION.CONTROL. This routine will be used to redefine the schedule in the AZ.ACCOUNT record. The APP should be established as follows:AZ.PRODUCT.PARAMETER – Annuity Type Field ANNUITY.ADJUST = YES Field Term Priority = No -

PD Link to AZ = YES (For PD Creation)

The redefining of schedule through this routine will happen using the following logic. A new local reference field (MAX.RO.INST) will be defined in the APP which will hold the value of maximum number of repayment rollovers.

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

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.

TEMENOS T24 User Guide

Page 34 of 189

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.IND of AZ.ACCOUNT is used for opting pre-closure of a loan account. If 'Y' is defined here, the system will inform the users the total amount due in the account, inclusive of interest. Based on these details, decision can be made to proceed further in closing the account or not.

In the normal course, if there is no debit balance in the loan account on maturity date, then the loan is treated as closed. If debit balance in the loan account continues even after the maturity date, then the penalty will be charged on the outstanding debit balance as per the interest defined in AZ.ACCOUNT.

Pre-closure charges for loan account will be charged based on the charge code defined in the corresponding Product Parameter.

When a loan is preclosured in AZ.ACCOUNT all the files will be moved to history online, whereas if the preclosure is done from TELLER / FT all the AZ related files will be moved to history only during COB. Non Reducing Limits – AZ ACCOUNTS

AZ account which is based on the account module, 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.LIMIT has been introduced in AZ.PRODUCT.PARAMETER and AZ.ACCOUNT. The value of REDUCE. LIMIT 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 SINGLE LIMIT is defined as ‘yes’.

TEMENOS T24 User Guide

Page 35 of 189

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

TEMENOS T24 User Guide

Page 36 of 189

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

TEMENOS T24 User Guide

Page 37 of 189

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 SINGLE.LIMIT in both ACCOUNT and AZ.PRODUCT.PARAMETER applications. The value input in the field SINGLE.LIMIT in both the applications should be the same for the creation of AZ.ACCOUNT

Figure 14 ACCOUNT

TEMENOS T24 User Guide

Page 38 of 189

All in One Account

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

TEMENOS T24 User Guide

Page 39 of 189

All in One Account

Figure 16 SCREENSHOT SHOWING ERROR IN AZ.ACCOUNT

It would permit creation of AZ account only when the value of SINGLE LIMIT is same in both the applications.

TEMENOS T24 User Guide

Page 40 of 189

All in One Account

Figure 17 AZ.PARAMETER - SINGLE LIMIT N

Figure 18 ACCOUNT - SINGLE LIMIT N TEMENOS T24 User Guide

Page 41 of 189

All in One Account

Figure 19 AZ.ACCOUNT Once an AZ ACCOUNT is created, the field SINGLE.LIMIT is a no input / no change field in both the ACCOUNT and AZ.PRODUCT.PARAMETER.

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

TEMENOS T24 User Guide

Page 42 of 189

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.

TEMENOS T24 User Guide

Page 43 of 189

All in One Account

Figure 22 AZ.ACCOUNT WITHOUT USERDEFINED AMOUNT

TEMENOS T24 User Guide

Page 44 of 189

All in One Account

Figure 23 AZ.SCHEDULES

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

TEMENOS T24 User Guide

Page 45 of 189

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

TEMENOS T24 User Guide

Page 46 of 189

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.

TEMENOS T24 User Guide

Page 47 of 189

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

TEMENOS T24 User Guide

“I”

17.09.03- DAILY

“N”

17.09.03- DAILY

Page 48 of 189

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.LINK.TO. AZ is set as “NO”.

The first “P”, “I” and “N” are due on 17.9.03 (it can be on different dates also). On the EOD of 17.9.03the 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.

TEMENOS T24 User Guide

Page 49 of 189

All in One Account

Figure 30 AZ.OVERDUES FILE UPDATION As related above when the instalment becomes due the system has updated the OD.PRINCIPAL and the OD. INTEREST fields as shown above.

ACCOUNTING: -

Unlike PD the system doesn’t raise any entry for the AZ. OVERDUES except for the interest portion. For the interest amount a sub a/c is created and debited (based on the set up made in AC.AUTO.ACCOUNT-) crediting the AZ. ACCOUNT or the INTEREST LIQUIDATION ACCOUNT as the case may be. For one main a/c there is only one sub a/c created to which interest entries are passed through. The principal amount in AZ. ACCOUNT will remain intact till the payment is affected.

The overdues can be settled through TELLER/FT applications using the OD.PRINCIPAL.TXN and OD.INTEREST.TXN codes as defined in the AZ. PRODUCT. PARAMETER .Any excess remittance over and above the dues or over and above the total outstanding will be credited back to the repayment account.

In continuation, if the subsequent instalments were not paid the system would multivalue the AZ. OVERDUES live file and write the overdues as shown below .

TEMENOS T24 User Guide

Page 50 of 189

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 01st Jan and the Interest payout is scheduled on 15th Jan is USD1000. Let us say on 05th Jan customer remits the Interest amount of USD 1000 to the AZ Account. Because of the advance Interest Received to the AZ account, the Outstanding Principal from 05th Jan to 15th Jan is reduced to USD 9,000 and actual interest will be calculated using this balance.

Hence instead of posting the interest received before the interest scheduled date (IRA) to the AZ Account, now facility is available to credit it to a Sub Account and on the interest schedule date- the amount is taken from Sub Account and posted to AZ account automatically.

IRA facility is available to all AZ Loan repayment types except Annuity & Credit Card

TEMENOS T24 User Guide

Page 51 of 189

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 IRA.PROCESS in AZ.PRODUCT..PARAMETER as “Yes”. The ACCT.SYNC should also be set to “Yes” so that the any debit or credit to AZ Account is validated against the appropriate events related to AZ Contract.

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

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.

TEMENOS T24 User Guide

Page 52 of 189

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 TEMENOS T24 User Guide

Page 53 of 189

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

TEMENOS T24 User Guide

Page 54 of 189

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

TEMENOS T24 User Guide

- Overdue Principal *

Page 55 of 189

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.

TEMENOS T24 User Guide

Page 56 of 189

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 doesn’t find the matching record in Account, Customer or product levels then settlement priority is based default “SYSTEM” record. Hence, ‘SYSTEM” record has to be defined before defining any record in AZ.SETTLEMENT.PRIORITY and also once created cannot be reversed.

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.

TEMENOS T24 User Guide

Page 57 of 189

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) TEMENOS T24 User Guide

Page 58 of 189

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)

TEMENOS T24 User Guide

Page 59 of 189

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 LINK.TO.SETT.PRIOR.

An Account record can be linked to an existing Account & not to any Customer / Product record in ASP. This hold same for customer & product linkage.

Also in case settlement priority to be skipped for a particular Account / Customer/ Product, a record in ASP can be created with LINK.TO.SETT.PRIOR set to ‘NONE’.

In the below mentioned example for account 35858 settlement priority is set to “None”, because of which any remittances made to this AZ ACCOUNT using LOAN.REPAY transaction code through TELLER / FT/ DC is moved to its Repayment Account and not adjusted towards any of the Loan components.

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

TEMENOS T24 User Guide

Page 60 of 189

All in One Account

Repayment Types

Priority Rules

AZ.SETTLEMENT.PRIORITY

Level 1

AZ.AMOUNT.TYPE/ DATE

AZ.ACCOUNT If No Matching Account in ASP –move to Next Level

AZ.AMOUNT.TYPE/ AZ.SETTLEMENT.PRIORITY

Level 2

DATE/ PRODUCT

CUSTOMER If No Matching Cust in ASP– move to Next Level

AZ.SETTLEMENT.PRIORITY

Level 3

AZ.AMOUNT.TYPE/ DATE

PRODUCT If No Matching Product in ASP –move to Default

AZ.AMOUNT.TYPE/ AZ.SETTLEMENT.PRIORITY

Level 4

DATE/ PRODUCT

SYSTEM (Default) Any Surplus after Settlement Process

Credit to REPAY.ACCOUNT

SURPLUS

Work flow of Settlement processing for an AZ Account. Example for settlement through AZ ACCOUNT AZ Product with repayment type as Annuity is created with PD.LINK.TO.AZ as No’ so to create overdue records in case of default in repayment. The LOAN.REPAY transaction code ’493’ is added to process settlement priority. To create PD record instead of Overdues, set the PD.LINK.TO.AZ as ‘Yes’.

TEMENOS T24 User Guide

Page 61 of 189

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 TRANSACTION.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 ANNUITY and it has following schedules due as on 22 October & 29 October.

TEMENOS T24 User Guide

Page 62 of 189

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.LINK.TO.AZ set to “No”- AZ.OVERDUE file is updated for the AZ Account with following details and sub account (xxxxx) is debited towards overdue interest of USD 833.33.

TEMENOS T24 User Guide

Page 63 of 189

All in One Account

Figure 48 OVERDUE DETAILS FOR 37818

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

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

TEMENOS T24 User Guide

Page 64 of 189

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 29th October & overdue file is updated accordingly.

Repayment Methods

OD.PR & Date

Details Amount Remitted

200,000.00

22 Oct

168413.80

b

31586.20

c

Remaining Amount OD.PR & Date

Amount

(a-b)

19 Oct

164396.21

Outstanding after adjustment - OD.PR

132810.01

a

d (d-c)

Over due file after update OD.PR

14 Feb

132810.01

OD.IN

07 Feb & 14 Feb (Sub Acct 36122)

Total Outstanding Settlement priority processing – break up details

TEMENOS T24 User Guide

Page 65 of 189

6895.89

139705.90

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

TEMENOS T24 User Guide

Page 66 of 189

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

Level 1

AZ.ACCOUNT

AZ.AMOUNT.TYPE/ DATE

If No Matching Account in ASP –move to Next Level AZ.AMOUNT.TYPE/ AZ.SETTLEMENT.PRIORITY

Level 2

PRODUCT

CUSTOMER If No Matching Cust in ASP – move to Next Level

TEMENOS T24 User Guide

DATE/

Page 67 of 189

All in One Account

AZ.SETTLEMENT.PRIOIRTY

Level 3

AZ.AMOUNT.TYPE/ DATE

PRODUCT If No Matching Product in ASP –move to Default

AZ.AMOUNT.TYPE/ AZ.SETTLEMENT.PRIORITY

Level 4

DATE/ PRODUCT

SYSTEM (Default) Any surplus move to next best fit AZ Acct from AZ.REPAY.ACCOUNT

Find next best fit from AZ.REPAY.ACCOUNT

SURPLUS

(Go to Level 1) Any Surplus after Processing all AZ Accounts

Credit to

SURPLUS

REPAY.ACCOUNT

Work flow details for priority through Common Repayment account. Example for Settlement priority through common AZ Repay Account In the following example, Account 37834 is used as Repayment Account in following AZ

ACCOUNTS.

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.

TEMENOS T24 User Guide

Page 68 of 189

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

TEMENOS T24 User Guide

Page 69 of 189

All in One Account

Figure 56 OVERDUE DETAILS FOR ACCOUNT 37858

Figure 57 OVERDUE DETAILS FOR ACCOUNT 37869

TEMENOS T24 User Guide

Page 70 of 189

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

LEVEL 1

Outstanding details

ASP -Account

A-37842 OD.PR

Amount

127585.87

OD.IN

3370.53

LEVEL 2 ASP -Account

A-37858 OD.IN

TEMENOS T24 User Guide

3370.53

Page 71 of 189

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)

LEVEL 2

LEVEL 3

127585.87

OD.IN

3370.53

Remaining

5043.60

Adjusted towards AZ-37858 OD.IN

3370.53

Remaining

1673.07

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

TEMENOS T24 User Guide

Page 72 of 189

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.PRINCIPAL.TXN etc will not be referring the Settlement priority Application. TEMENOS T24 User Guide

Page 73 of 189

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.

TEMENOS T24 User Guide

Page 74 of 189

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

TEMENOS T24 User Guide

Page 75 of 189

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)

Re.consol.Spec CR

1500.00

“X” a/c DR.

1700.00 (Cap)

Re.consol.Spec CR

1700.00

Categ Entry –Cr

500.00 (accrual)

Re.consol.SpecDr

500.00

10.01.04

10.02.04

18.02.04

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

TEMENOS T24 User Guide

Page 76 of 189

All in One Account

Categ Entry –Cr

200.00

(accrual)

Re.consol.Spec- Dr

200.00 [COB]

18.02.04 @Difference amount

FLOW CHART:->>

BACK DATED RATE CHANGE (beyond last capitalisation)

LOAN TYPE

ANNUITY

LINEAR, NON-Redemption OTHERS

NO YES

Check

Fixed

Fixed Floating

BI key

TEMENOS T24 User Guide

INTEREST TYPE

Page 77 of 189

All in One Account

NO YES

Accounting for INTEREST ADJUSTMENT

YES

Already Capitalised Interest

Interest under Accrual

ONLINE

AT COB END

On the contrary if the rate of interest were lower than the earlier defined rates – the system would pass the reversal entries to the one stated above.

SETUP There is no specific set-up enunciated for the back dated rate change. However, the set-up regarding the transaction codes needs to be followed as enunciated under.

TEMENOS T24 User Guide

Page 78 of 189

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 can’t take a debit transaction code and vice versa. The exception to the above is the following events and txn codes. Int. Dr. Cap

391

The TXN code should be set as 391 ONLY

Int. Cr. Cap

381

The TXN code should be set as 381 ONLY

Int.Corr.Txn

#

# A multi value field and should be multivalued to set up txn codes 385, 395, 405 and 386. This set up is mandatory.

The back dated and forward dated (for fixed rate type) rate changes could be affected only through “R” schedules. Of course, if a BI key is defined the forward dated changes can be stipulated via BI key itself followed by date.

To exemplify: -

TEMENOS T24 User Guide

Page 79 of 189

All in One Account

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

TEMENOS T24 User Guide

Page 80 of 189

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

TEMENOS T24 User Guide

Page 81 of 189

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, 31st Dec and 1st Jan.

In the a/c 22007335- a change in rate of interest of 35% (fixed) is input with effect from 2.12.2000 is input as shown below

TEMENOS T24 User Guide

Page 82 of 189

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.

TEMENOS T24 User Guide

Page 83 of 189

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. PRINCIPAL.TXN., in applications like TELLER or FUNDS.TRANSFER. The code for each of the activity is set in AZ. PRODUCT.PARAMTER and is mandatory input.

TEMENOS T24 User Guide

Page 84 of 189

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)

Re.consol.Spec CR

1500.00

“X” a/c DR.

1700.00 (Cap)

Re.consol.Spec CR

1700.00

Categ Entry –Cr

500.00

Re.consol.Spec- Dr

500.00

10.01.04

10.02.04

(accrual)

18.02.04

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

Capitalised @10% on 300000 – now recast amount is 200000 –due to back dated repayment.

2300

1500.00

800$

10.02.04

Capitalised @ 12%

2150

1700.00

450#

18.02.04

Accrual at 12%

700

500.00

200@

10.01.04

TEMENOS T24 User Guide

Page 85 of 189

(With PR @ 200000)

All in One Account

The system would pass entries ONLINE with respective value dates for the already capitalised entries for the difference amount and would adjust the accrual as part of the COB (close of Business). The structure of entries would as below

“X” a/c DR.

800.00 (Cap)

10.01.04

Re.consol.Spec CR

800.00 [ONLINE]

$Difference amount

“X” a/c DR.

450.00 (Cap)

10.02.04

Re.consol.Spec CR

450.00 [ONLINE]

#Difference amount

Categ Entry –Cr

200.00

18.02.04

Re.consol.Spec- Dr

200.00 [COB]

(accrual)

@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

TEMENOS T24 User Guide

Page 86 of 189

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

AT COB

ONLINE END

SET UP

The setting up of TXN codes is again mandatory. However, back dated repayment is not permitted for “non-redemption” type, hence, setting up of loan repayment transaction in AZ. PRODUCT.

PARAMETER is not permitted.

TEMENOS T24 User Guide

Page 87 of 189

All in One Account

Figure 70 FOR A NON REDEMPTION TYPE WHEN LOAN REPAYMENT IS INPUT”ERROR” IS RAISED

Note: - The setting up of Transaction codes is mandatory. Loan repays, loan drawdowns are termed as events and the system permits transaction codes akin to the nature of these events. For ex:- loan repay is a credit transaction and hence can’t take a debit transaction code and vice versa. The exception to the above is the following events and txn codes

Int. Dr. Cap

391

The TXN code should be set as 391 ONLY

Int. Cr. Cap

381

The TXN code should be set as 381 ONLY

Int.Corr.Txn

#

# A multi value field and should be multivalued to set up txn codes 385, 395, 405 and 386. This set up is mandatory.

To illustrate

As related earlier, the process of back dated repayment can be achieved either through AZ ACCOUNT and /or through applications like TELLER and FT using the “PRINCIPAL.TXN” code

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

TEMENOS T24 User Guide

Page 88 of 189

All in One Account

Figure 71 AZ. PRODUCT. PARAMETER WITH TXN CODES.

TEMENOS T24 User Guide

Page 89 of 189

All in One Account

Figure 72 AZ.ACCOUNT 22007351

TEMENOS T24 User Guide

Page 90 of 189

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 PERIODIC.INTEREST can be specified in the Parameter. Further more, it is possible to define a method of selecting previous, next or interpolation of interest rates. In the case of pre mature closure of deposit, the interest for the

TEMENOS T24 User Guide

Page 91 of 189

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

By opting Schedules as ‘Y’, the credit interest frequency will be populated from the Parameter to the AZ deposit account.

It is not advisable to create a back dated deposit on an existing account with a balance and a different category previously. The accrued amount in that account till that day will not get reversed out.

Figure 74 AZ.DEPOSIT PARAMETER OF TYPE FIXED

TEMENOS T24 User Guide

Page 92 of 189

All in One Account

Maturity Process The maturity instruction for Fixed Deposit can be defined in the Product Parameter under MATURITY.INSTR. It is possible to define Automatic Rollover or Payment to Nominated account, so that all accounts opened under this product will have this maturity process.

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.INT.CAP.FQU and ROLL.INT.PAY.FQU. The following values are permitted Dnn, Wnn and Mnn.

Figure 75 – AZ.ACCOUNT

Early Redemption Fixed Deposits and Savings Plan deposits can be redeemed before maturity. In the case of FIXED type of deposit, part closure is also permitted. For early redemption of part or full amount, the eligible interest is calculated based on the period run, by referring to the 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.

TEMENOS T24 User Guide

Page 93 of 189

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 LIAB TO PENALTY

When applying the fee the system would try to debit the REPAY.ACCOUNT. If REPAY.ACCOUNT has insufficient funds or no REPAY.ACCOUNT is given then the system would create a FT on hold.

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.

TEMENOS T24 User Guide

Page 94 of 189

All in One Account

The “R” schedule trigger is in turn based on the input made in the newly introduced field RATE.PERIOD in AZ.PRODUCT.PARAMETER.

Figure 76 - AZ.PRODUCT.PARAMETER

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

TEMENOS T24 User Guide

Page 95 of 189

All in One Account

Figure 77 - AZ.ACCOUNT

As the RATE.PERIOD is defined as 3M- the “R” schedule is slated for 2003/12/24 which +3M from the start date of 2003/09/24.

The fixed and the floating rates are defaulted from the AZ.PRODUCT.PARAMETER. User has the flexibility to change the fixed rate at the account level before authorising the record and floating rate through INTEREST.RATE field of BASIC.INTEREST application, when necessary. √

The RATE.KEY (Basic Interest-key) will be fixed. Change in rate can be administered by inputting a new rate in the INTEREST.RATE field. The rate will be effective from the date appended to the BI record ID.

TEMENOS T24 User Guide

Page 96 of 189

All in One Account

Figure 78 - BASIC.INTEREST

Any subsequent changes in the INTEREST.RATE field of BASIC.INTEREST key will be recorded in the

ACCOUNT.CREDIT.INTEREST (ACI) for future references. √

“R” schedule is a MUST for fixed floating deposit and if the record is committed without an “R” schedule it throws an error. TTS 0551371

New Fields The following are the new fields introduced in the enhancement.

Name of New field

APPLICATION

Description

RATE.PERIOD

AZ.PRODUCT.PARAMETER

Contains the no. of days after which – it will trigger the “R” schedule to introduce change of rate to floating. If this field is input it is a fixed-floating type. Or else it is customary AZ product.

OVERRIDE

AZ.PRODUCT.PARAMETER

A new field to store any override. For ex., the field RATE.PERIOD can’t be > than the MAXIM.TERM Field. In case of such input the system throws an override-, which is stored in this field.

TEMENOS T24 User Guide

Page 97 of 189

All in One Account

RATE.PERCENT

AZ.PRODUCT.PARAMETER

(Revised definition modified if it is fixed-floating)

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 FIXEDFLOATING type of deposit. The insertion of “R” schedule was necessary to trigger the Floating rate of interest in these types of deposits.

“R” schedule trigger and its frequency is based on the value input in the RATE.PERIOD field in

AZ.PRODUCT.PARAMETER.

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]

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.

Set-up

If there is more than one category then each of the categories must be input in AC.AUTO.ACCOUNT application.

TEMENOS T24 User Guide

Page 98 of 189

All in One Account

In AC.AUTO.ACCOUNT application the INHERITED fields are optional. But certain fields like interest liquidation account if input in AZ main a/c and needed to be populated at the sub a/c level then the inherited fields should be input.

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

TEMENOS T24 User Guide

Page 99 of 189

All in One Account

Figure 80 AZ.PRODUCT.PARAMETER Significant fields in APP:•

The Field MULTI should be flagged as Yes

•

The field PART REDEMPTION should be flagged as yes – if the particular AZ product has part redemption as a feature. If input as “N” – then part redemption can’t be made on all those accounts which has this AZ product parameter attached.

•

For a –multi fixed deposit-the REPAYMENT TYPE field should be flagged as FIXED.

•

MATURITY INSTRUCTIONS field–can be either Automatic rollover or Payment to nominated a/c. If flagged as Automatic Rollover- then only ROLLOVER ACCOUNTNG field is opened.

•

The field ROLLOVER ACCTNG can be input as either Yes or “ “. If input as Yes –the system will do the accounting part even if roll over deposit and the principal are same. If “ “ accounting will not happen if rollover of deposit and the principal are same. However, during roll over if any addition or deletion to the principal is made–then accounting will happen to the extent of such addition or deletion

TEMENOS T24 User Guide

Page 100 of 189

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

Figure 81 AZ.ACCOUNT •

The a/c so attached is the MAIN a/c and the principal will be ZERO for the same.

•

In multi Fixed deposit Value date should be defined – while the maturity date is a “NO input” when the repay type is “FIXED”

•

In APP – product start and End date fields if input –then the Value dates of the AZ a/c should fall within the dates.

•

Defining Repay and Nominated a/c is mandatory.

•

Calculation base should be input as “Principal”

CREATING SUB AZ A/C [Fixed] In AZ Main a/c input the following fields: - [through teller is discussed under separate heading] The sub a/cs generated from the main AZ a/c or any other application will have the AZ.PRODUCT.PARAMETER (APP) of the main a/c only- if can’t be different or changed. •

For making a Deposit –field REPAY. AMT is input with the amount of deposit.

•

Input the Repay. V. Date and Mat. Date and commit the record.

•

Maturity date is mandatory-Value date if not input will be defaulted to the GLOBUS date.

•

The details of sub a/cs belonging to an AZ main a/c can be seen from

TEMENOS T24 User Guide

Page 101 of 189

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

TEMENOS T24 User Guide

Page 102 of 189

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 AZ.PRODUCT.PARAMETER.

Note:- At the time of creation of sub a/c – either through AZ main a/c or through Non-AZ method-if the main a/c contains any DEBIT balance then creation of sub a/c will be stalled till the debit balance is offset. To illustrate Deposit is input for

Dr. balance in Main AZ

Sub a/c will be created for amount

10000 USD

–15000USD

NO sub a/c will be created the balance in main a/c will become

[Deposit 1]

-5000 USD 11000 USD

-5000 USD

[Deposit 2]

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. INT FQU field. If done this will be populated at the AZ.ACCOUNT level. “N” schedule may be defined at the AZ main a/c level when inputting a fresh deposit.

A new sub a/c is created whenever a deposit is made to the credit of the main AZ a/c and consequently, the “I”,“N” and “IN” schedules will be populated at the sub a/c level. “I” schedule capitalizes the interest and “N” schedules transfers the interest amount so capitalized to the credit of Nominated a/c. If interest liquidation a/c is defined, the function of “N” schedules is redundant. “I” and “N” can have different frequencies-but combined “I” and “N” will have only one single frequency. The schedules can be viewed for each of the a/c using AZ.SCHEDULES application. Part Redemption THROUGH AZ MAIN A/C At this point –before the maturity date the sub a/c created is subject to any of the following

PART –REDEMPTION {Through AZ account}

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

[This is an Interactive process]

(b) Sub AZ Acct The customer can indicate his

TEMENOS T24 User Guide

OR

Page 103 of 189

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/c’s with amount. The account and amount indicates the interactive process by which the customer exercises his choice of a/c and the amount as well. On committing the transaction, the system will deduct the amount so drawn from the respective sub a/cs. The charges and penalty if any will be deducted either from the redemption amount or from the principal after such redemption depending on the flag set in CHG.FROM.RED.AMT field.

THROUGH AZ SUB A/c In this case – (as per customer’s choice) a particular AZ sub a/c is selected and amount of part redemption is specified in the REDEMPTION AMT field. As the part, redemption is made on the sub a/c.

Some of the fields that go with the part-redemption process are tabulated below

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

TEMENOS T24 User Guide

Page 104 of 189

All in One Account

withdrawal. [See help text of the field for further explanation] Early Red int

This is populated from EARLY.RED.MARGIN field of

AZ PRODUCT PARAMETER application. Charge code, amt, date

While permitting part, drawl or input of a fresh deposit – if any charges are to be debited- then this field can be used. If entered –Chq liq. Acct is mandatory- and the charges will be debited to this a/c.

Pre-Closure THROUGH AZ MAIN A/c

PRE-CLOSURE

OR

Meaning: - Complete closure of deposit before it attains the maturity date. This can be either one sub a/c or all the sub a/c’s 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]

Before Maturity Closure In AZ-, this can be accomplished either at the Main AZ a/c level or at the Sub a/c level by flagging the field PRE.CLOSURE.IND as “Y”. In the first case (Main AZ a/c) it amounts total closure of all the AZ accounts while in the second case – it amounts to total closure of that particular sub a/c only.

Main A/C

TEMENOS T24 User Guide

Page 105 of 189

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/c’s that a main a/c has.

In our present illustration – the main a/c 37524 has 3 sub a/c’s as listed above. Therefore, at the main a/c level when the pre close indicator is set to “Y”– the system will close the entire sub a/c’s including the main a/c.

Figure 87 –SETTING PRE-CLOSURE INDICATOR AS ‘Y’

TEMENOS T24 User Guide

Page 106 of 189

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/c’s including the main a/c.

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

TEMENOS T24 User Guide

Page 107 of 189

All in One Account

Figure 89.AZ. SUB /AC At the sub a/c level – the PRE CLOSURE IND field is input as “Y”

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

TEMENOS T24 User Guide

Page 108 of 189

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 charge.liq.account.

When we pre close a deposit through AZA then we apply the pre closure fee defined in APP. But if we pre close through TELLER / FT then this pre closure fee will not be handled and that application raising the entries will have to handle it.

TEMENOS T24 User Guide

Page 109 of 189

All in One Account

AZ-Reversal •

In multi deposits –if a sub a/c is created through AZ.ACCOUNT application – then NO REVERSAL is possible.

•

In case the creation of AZ sub a/c is done via application like TELLER then reversal is possible. This is done by simply reversing the underlying transaction provided events like part redemption, accrual has not happened

Deposit Maturity On maturity the AZ account may –either be rolled over if, the MATURITY INSTR field in the AZ Product Parameter application is automatic rollover OR Credited to Nominated a/c if the MATURITY INSTR field in the AZ Product Parameter application is payment to nominated account. Multi Fixed Deposit –via Non-AZ CREATION OF DEPOSIT/SUB A/C Note: -TELLER application is selected for illustration purpose.

The creation of AZ. Main a/c is a pre-requisite to the creation of sub a/c using application TELLER. The other essentials are •

Application TELLER.TRANSACTION should be set up with the TXN code specified in the AZ PRODUCT PARAMETER application. I.e. 494 for Deposit .Cr as shown below

TEMENOS T24 User Guide

Page 110 of 189

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 can’t be identified.

TEMENOS T24 User Guide

Page 111 of 189

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/c’s 22007346 as shown below: -

SUB a/c –No.1

TEMENOS T24 User Guide

Page 112 of 189

All in One Account

Figure 94 AZ.ACCOUNT

Multi FIXED deposit sub account creation is not possible through other applications apart from AZA and TELLER, as we need the maturity date to be input while creation. PART-CLOSURE Prior to initiating the part closure of an AZ a/c through Teller, it is essential to set-up the following •

Application TELLER.TRANSACTION should be set up with the TXN code specified in the AZ PRODUCT PARAMETER application. I.e. TXN code mentioned in field DEP. DR. PART as shown below

TEMENOS T24 User Guide

Page 113 of 189

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.

TEMENOS T24 User Guide

Page 114 of 189

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/c’s should be given to the exact amount. If the amount input is not equal to the total of the sub a/c’s then error will be raised. . A suitable override “that all the a/c’s will be closed” will be populated as a warning to the user.

PRE-CLOSURE As recited earlier – the procedure for setting up teller transaction with the TXN code of field DEP. DR. PRE. CLOSURE in APP should be set-up as shown below.

TEMENOS T24 User Guide

Page 115 of 189

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 –

TEMENOS T24 User Guide

Page 116 of 189

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

TEMENOS T24 User Guide

Page 117 of 189

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 INHERITED fields are optional. But certain fields like interest liquidation account if input in AZ main a/c and needed to be populated at the sub a/c level then the inherited fields should be input

Set-up a AZ product parameter as shown below

TEMENOS T24 User Guide

Page 118 of 189

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

TEMENOS T24 User Guide

Page 119 of 189

All in One Account

Credit. Amt. Multi- in APP

Credit Amount -in Az. Account

Case (1) input as "Yes"

Is Blank

Case (2) input as "Yes"

Input as 5000

Case (3) left " "

Input as 7000

Case (1) Credit Amt. Multi field is Yes and Credit Amount field in AZ.Account is blank-then the "B" schedule amount can be input with any amount. Case (2) Credit Amt. Multi field is Yes- and Credit Amount field in AZ.Account is input with say USD 5000 -then "B" schedule amount can be credit amount (USD 5000) or multiples of credit amount (USD 10000, 15000 etc). But "B" schedule amount can't be LESS than the credit amount. Case (3) Credit Amt. Multi field is " " - and Credit Amount field in AZ. account is input as USD 7000- then "B" schedule amount should be credit amount ONLY (i.e. USD 7000 only) and even multiples are not permitted. •

“I” schedule is automatically populated from the AZ.PRODUCT.PARAMETER application. In case of Savings plan the defining of “B” schedule is mandatory.

•

The field PART REDEMPTION should be flagged as “N” if the REPAYMENT TYPE is Savings plan.

•

For a –multi Savings Plan-the REPAYMENT TYPE field should be flagged as SAVINGS-PLAN

•

The sub a/cs generated from the main AZ a/c or any other application will have the AZ.PRODUCT.PARAMETER (APP) of the main a/c only- if can’t be different or changed

•

MATURITY INSTRUCTIONS field–can be Payment to nominated a/c-only if the repayment type is Savings Plan.

•

A new set of TXN codes relating deposits are opened up which are mandatory inputs.

Link AZ. Product. Parameter to account via AZ.ACCOUNT application

TEMENOS T24 User Guide

Page 120 of 189

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 doesn’t have a maturity date.

Each instalment or “B” schedule is treated as a separate fixed deposit and will have different value dates –but will have a common maturity date.

On the defined “B” schedule dates – the system executes the “B” schedules at COB and a sub a/c will be created by debiting the repay a/c for deposit.

TEMENOS T24 User Guide

Page 121 of 189

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

TEMENOS T24 User Guide

Page 122 of 189

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

TEMENOS T24 User Guide

Page 123 of 189

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

TEMENOS T24 User Guide

Page 124 of 189

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.

TEMENOS T24 User Guide

Page 125 of 189

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”

TEMENOS T24 User Guide

Page 126 of 189

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 DEPOSIT.CR should be a credit transaction to the AZ account and the rest has to be the codes relating to CHEQUE.COLLECTION.

Indirect Credit Method :

For the creation of clearing entries by way of indirect credit, ACCOUNT.PARAMETER has to be set.

TEMENOS T24 User Guide

Page 127 of 189

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

Deposited

Statement Entries Clearing suspense account Debit Clearing suspense account Credit.

TEMENOS T24 User Guide

Page 128 of 189

All in One Account

Cleared

Clearing suspense account Debit AZ sub account Credit

Returned

Clearing suspense account Debit 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 TEMENOS T24 User Guide

Page 129 of 189

All in One Account

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

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:

TEMENOS T24 User Guide

Page 130 of 189

All in One Account

Cheque Status

Deposited

Statement Entries Clearing suspense account Debit 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.

TEMENOS T24 User Guide

Page 131 of 189

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.

TEMENOS T24 User Guide

Page 132 of 189

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). TEMENOS T24 User Guide

Page 133 of 189

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,

TEMENOS T24 User Guide

Page 134 of 189

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

Generally is not advisable to define the charge liq account as the AZ.ACCOUNT in any application.

In AZ SCHEDULES the TYPE.C amount shown in only notional it can vary at the actual time of collection of charges.

Capitalisation rules – Partial Withdrawal / Pre-closure

Based on their conventions / requirement, banks permit partial withdrawal or pre-closure of deposits accepted by them. Previously, in the application, AZ.ACCOUNT, on making a partial withdrawal from the deposit, charges and penal interest were either reduced from the principal amount or from the withdrawal amount as defined in AZ.PRODUCT.PARAMETER and the total interest payment was made on the maturity date.

TEMENOS T24 User Guide

Page 135 of 189

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 LIQUIDATION ACCOUNT is made mandatory when a charge code is defined AZ.PRODUCT.PARAMETER. While making a partial withdrawal the entries pertaining to charges would be routed through the liquidation account.

Example 1 : 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 INT in AZ.ACCOUNT is defined with a rate different from the one defined in AZ.PRODUCT.PARAMETER, the rate defined in the AZ account will be taken as the penal interest. TEMENOS T24 User Guide

Page 136 of 189

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]

TEMENOS T24 User Guide

Page 137 of 189

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

TEMENOS T24 User Guide

Page 138 of 189

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 INT would populate the difference between the contracted rate and the eligible interest rate. (For more details, refer to the user guide on PERIODIC INTEREST ).

The rules for capitalisation of interest online, reversal of accrual interest, if any or adjustment of interest already paid would be as explained in Examples 1 & 2.

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

TEMENOS T24 User Guide

Page 139 of 189

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 REDEMPTION AMT in sub account or by defining account.REDEMPTION AMT and SUB AZ ACCT in the main Whenever a partial withdrawal is made defining the interest to be paid at maturity,

The principal is reduced by the withdrawn amount.

Interest accrued for the withdrawn amount till the date of withdrawal is reversed

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.

TEMENOS T24 User Guide

Page 140 of 189

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:

TEMENOS T24 User Guide

Page 141 of 189

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.

TEMENOS T24 User Guide

Page 142 of 189

All in One Account

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

Example : 5:

Interest rate – 10%, eligible int.rate – 6%

TEMENOS T24 User Guide

Page 143 of 189

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.

TEMENOS T24 User Guide

Page 144 of 189

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.

TEMENOS T24 User Guide

Page 145 of 189

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.

TEMENOS T24 User Guide

Page 146 of 189

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.

TEMENOS T24 User Guide

Page 147 of 189

All in One Account

•

The end date is essential in the sense after the date “NO NEW” accounts will be accepted – but the accounts input within the start and end dates will continue to exist.

Note: - In case of Multi-deposits there is a differential treatment in respect of Fixed and Savings plan Fixed: - In case of Fixed deposits –every sub a/c is a new a/c and any effort to open a new sub a/c with a value date beyond the product start and end date – should be blocked by raising an error. Savings Plan:- In case of Savings plan- for enabling frequent deposits “B” schedules are defined. Whenever, the “B” schedules are executed a sub a/c is created which is part of main savings plan. Therefore, in case of savings plan the creation of sub a/c even if the date of “B” schedules is beyond the product end date should be permitted. A fresh AZ a/c after the product end date should however be blocked •

Both the start date and end date of a product can be backdated as well as forward dated. Even in case both the dates i.e. start and end dates are backdated the validation that “product end date can’t be less than the start date” is substantiated.

•

The opening of an a/c under the product is permitted if (1) The value date of the a/c is on or after the start date and earlier to the end date. (2) Suitable error conditions will be stimulated (see screen shots above) both in the case of value date is EARLIER to the product start date and LATTER than the product end date.

CAUTION: - (1) If the Prod. End. Date field is blank- the product is valid forever and validations akin if a date is specified will not happen. (2) If the product start and end date are left blank, none of the above validations will happen and the product will be treated as a normal one- with life forever.

PASS BOOK LAY OUT- for AZ a/cs

The evolving of different passbook layouts also concerns All in One Account (AZ) i.e. to print passbook in lieu of deposit receipts. The nomenclature for using different layouts in an AZ environment is explained below •

Set-up a new passbook layout-using TELLER. PASSBOOK application as explained under teller.

•

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

TEMENOS T24 User Guide

Page 148 of 189

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.ID – then the a/c so attached to the product parameter must have the passbook field in a/c flagged as yes.

•

TELLER.PASSBOOK.REPRINT application is used to reprint the entries for a particular AZ main a/c by giving a range of dates.

NON-STOP- PHASE 1 New AZ.ACCOUNT’s and amendments to (LOAN, FIXED DEPOSIT, SAVINGS PLAN) contracts can be input during COB. No amendment of contracts input prior to COB would be allowed.

Early Closure Penalty using routine The concept of attaching a routine to the PI key was evolved in AZ. In AZ, the penal rates are applicable in case of either part or pre closure of a deposit. The penal rate applicable under such circumstances is defaulted from the AZ.PRODUCT.PARAMETER. However, the penal rate so defaulted can be altered at the account level.

Altering the penal rate every time a part redemption or pre-closure it time consuming. Hence, a set of input parameters defining the rate of penalty applicable in different scenarios can be defined and attached as a routine as shown below.

Step 1: - Create a sub routine and create an id in PGM.FILE as shown below.

TEMENOS T24 User Guide

Page 149 of 189

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

TEMENOS T24 User Guide

Page 150 of 189

All in One Account

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

IF DAYS LE 1 THEN INTEREST.RATE =3 IF DAYS GT 1 AND DAYS LE 2 THEN INTEREST.RATE=2 IF DAYS GT 2 THEN INTEREST.RATE =1

The input parameters imply, if the deposit has run for less than one day before it is ordered for preclose 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 INT field rate will be overwritten with the value inscribed in the routine- as shown below

Note: - this can be viewed by putting the record in INAU

TEMENOS T24 User Guide

Page 151 of 189

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%

TEMENOS T24 User Guide

Page 152 of 189

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

TEMENOS T24 User Guide

Page 153 of 189

All in One Account

Sub a/c No Note Penalty populated as 1%

is

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

TEMENOS T24 User Guide

Page 154 of 189

All in One Account

Figure146-AZ. PRODUCT.PARAMETER FOR SAVINGS PLAN TYPE Field GRACE. PERIOD can take any of the following values (1) nnC (2) nnW or (3) Mont. End

To illustrate: -

If the instalment is due on say 10.3.04 if the GRACE PERIOD field is

(1) 05C – the customer will have the option to pay the instalment on or before 15.03.04 before the instalment is considered as defaulted. “C” stands for Calendar days. (2) 02W – the customer will have the option to pay the instalment on or before 12.03.04 (2 working days –not weeks) before the instalment is considered as defaulted. (3) Month. End- here the customer can pay the instalment before the month end i.e. 31.3.04 failing which the instalment will be termed as defaulted. (4) The newly introduced option of Month. End is available for input in case of loans also.

Cross Validations: -

TEMENOS T24 User Guide

Page 155 of 189

All in One Account

In case of deposits input in Grace. Period is based on the CR. DEP. FEQ field which is trigger for the generating the instalment frequency i.e. B schedules. Enough logic has been build to raise an error if the deposit frequency and the Grace days aren’t in tandem. For ex: - the Deposit frequency can’t be weekly –with grace period flagged as Month. End. Similarly, the grace cannot be 03C when the deposit frequency is daily.

In CR.DEP.FEQ field the value “w01” indicates week01 and not working days. Penalty Calculations: -

EARLIER B schedule date

Grace days

Liab penalty

10.2.04 –not paid

N.A.

11.3.04-not paid

N.A.

to

Bonus eligible

Penalty charge

Date penalty

1

NO

NO

10.2.04$

1

NO

Yes

11.3.04$

for

(Already defaulted February) $The penalty will be calculated from “B” schedule date Grace days not applicable and will be ignored.

After the present development B schedule date

Grace days

Liab penalty

10.2.04- not paid

2

0

11.3.04- not paid

1

2

to

Bonus eligible

Penalty charge

Date penalty

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.

No – as liab to penalty is permitted up to 2 instalments.

12.3.04#

* DO *

for

#Here the calculation of penalty will be “B” schedule

TEMENOS T24 User Guide

Page 156 of 189

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 PREMIUM is input with either a charge or a commission code, which determines the amount of “Bonus” payable. The field can be input only if the REPAYMENT TYPE is Savings plan.

LATE PAYMENT FEE field implies the amount of charge that will be levied in case a customer misses an instalment.

LIAB TO PENALTY is another field which determines whether bonus is payable or not. The field takes a numeric and implies the no. of instalments that the customer can miss to avoid the penalty class. However, any count to the field LIAB TO PENALTY would automatically stop the payment of bonus to the customer. When the customer crosses the input in liab to penalty field – the late payment fee is applied.

The proposed functionality aims at (1) An option to pay “Bonus” on principal or interest earned (2) Even if there is a count on LIAB TO PENALTY field still the bonus will be paid based on the flag set in new field BONUS ON ARREARS. The process flow of the development is as below

AZ.PRODUCT.PARAMETER: -

TEMENOS T24 User Guide

Page 157 of 189

All in One Account

Figure147AZ. PRODUCT. PARAMETER

New fields Bonus Cr

BONUS on

Permitted inputs

Remarks

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.

(1) Principal

If the input were “Principal”, the bonus calculation would be based on the principal amount.

(2) Interest (3) “ “

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

TEMENOS T24 User Guide

Page 158 of 189

All in One Account

Option (1)

Option (2)

Option (3)

Bonus %

Principal

Interest

““

10%

100000

2000

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

This field is to be read with the field “Bonus on Arrears”. If flagged as Yes – the system will pay interest even if there is default in payment of instalment not exceeding the input in LIAB TO PENALTY field.

If “ “ is input in the field BONUS ON ARREARS then any missed instalment would result in non-payment of bonus. Note: - in case FT. commission. Type the minimum and maximum amount will be the deciding factor Bonus on Arrears

(1) Yes (2) “ “

If flagged as “yes”- even if the customer misses instalments not exceeding the input in LIAB 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

TEMENOS T24 User Guide

Page 159 of 189

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

TEMENOS T24 User Guide

Page 160 of 189

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”. STOCK.PARAMETER.ID *STOCK REG.ID.

TEMENOS T24 User Guide

Page 161 of 189

The stocks are listed based on the

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.

TEMENOS T24 User Guide

Page 162 of 189

All in One Account

Only the categories of those AZ product parameters having REPAYMENT TYPE field as Credit Card MULTI AND ACCT.SYNC AS YES need to be inscribed in the and fields 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 PRINCIPAL field of the sub a/c’s inscribed with amount so drawn.

The PRINCIPAL field in AZ main account will always be ZERO and the MASTER account field of sub account created will be populated with the AZ main account number. The drawdown procedure and the methods of drawdown and repayment are dealt with separately.

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.

TEMENOS T24 User Guide

Page 163 of 189

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

Limit creation for customer 1002

Figure 163 LIMIT SETUP

Attaching LIMIT to Account:

TEMENOS T24 User Guide

Page 164 of 189

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

TEMENOS T24 User Guide

Page 165 of 189

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

TEMENOS T24 User Guide

Page 166 of 189

All in One Account

restriction on the amount to be drawn in loan or amount of deposit in case of deposits–then that amount can be mentioned here. If the Drawdown amount/ deposit amount is less than the amount mentioned in this field then an OVERRIDE is raised.

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.INT.RATE if not found it looks at Int. Rate in AZ.Account, if not found it will take the rate inscribed in this field in AZ PRODUCT PARAMTER.

Interest rate indicating %age

Drawdown type

As repay type is credit card, there can’t 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 Nonredemption) 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 Ythen 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

TEMENOS T24 User Guide

Page 167 of 189

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.

1. Proportionate 2. FIFO For non-redemption, this has to be set as FIFO.

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. 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 say100000, 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 whereby–10% of the outstanding in the entire sub accounts or the minimum whichever is higher will be taken as CC schedule. To continue the above exampleO/s (1) 100000 (2) 120000 (3) 200000. Revolving ratio is 10% and assumes if

TEMENOS T24 User Guide

Page 168 of 189

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

Highest Range

1000000

Amt. Percent

*10

Highest Range

5000000

Amt. Percent

*20

Some validations: -

(1) “*” Before the numeric entered in amt. percent is must – or else the system will deem

TEMENOS T24 User Guide

Page 169 of 189

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 doesn’t fit into any specified range This will be decided by the type of input made in the field Amt. Percent. For ex:

Highest Range

300000

Amt. Percent

*10

Highest Range

500000

Amt. Percent

150000

Reference to the table if the total drawings of the customer come to 250000, it falls in the range of 300000 and the %age of repayment will be 10% of such outstanding (subject to Minimum Repayment clause specified)

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

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

TEMENOS T24 User Guide

Page 170 of 189

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.

Figure 167.AZ.ACCOUNT

TEMENOS T24 User Guide

Page 171 of 189

Valid input numeric.

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

76

51

[Loan Drawdown transaction]

[This transaction code indicates that it is a loan drawdown and a debit to loan account]

Internal/customer ACCOUNT

CASE-2- in a Loan Repay is made then Debit is to the REPAY account and Credit is to the Loan account Internal/customer

1

Loan Account

915

[Loan Repay transaction]

Note: -When the field Repayment. Type is credit card –any attempt to repay should be channelled through – Repayment. Txn code only as pre-closure and maturity transaction codes are not likely events of credit card type.

In APP for each of the happenings – a transaction code is inscribed so that “THE EVENT “ could be identified.

Figure 148 AZ.PRODUCT.PARAMETER

TEMENOS T24 User Guide

Page 172 of 189

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) TEMENOS T24 User Guide

Page 173 of 189

All in One Account

After setting up the APP, the main AZ Account should be created by attaching an AZ.PRODUCT.PARAMETER. The PRINCIPAL field in the AZ.MAIN account should be zero and any withdrawals made will result in creation of a sub account with the amount as drawn.

Figure 171- AZ. ACCOUNT Field Name

Permitted Inputs

Remarks

All in one Product

Any one of the product parameters created i.e.

Selection of the APP indicates the type of product for which the account is created, which will be governed by that product parameter.

(1) Revolving –ID -1250 (2) Ranged Revolving-ID-1350 (3) Non-redemption- ID-1450 can be inscribed here. Principal

TEMENOS T24 User Guide

Should be ZERO for main account

Page 174 of 189

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

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.INT.RATE”.

Orig. Principal

The input is AMOUNT in numeric.

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

TEMENOS T24 User Guide

Page 175 of 189

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.

TEMENOS T24 User Guide

Page 176 of 189

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

“C” Schedule

“C” stands for CHARGES schedule. When drawdown is made there are certain charges attached to it, which are stored in this schedule. Charges are to be input manually every time a drawdown is made. Whenever repayment is made, the FIRST appropriation will be made to the charges. This schedule is generated ONLINE whenever charges are attached to a drawdown. This schedule is created on the charge date input along with the charges.

“CC” Schedule

“CC”-schedule stands repayment amount calculated as a %age on the total drawdown made, to be repaid on the repayment date. The amount of CC schedule is arrived at keeping the repayment type i.e. Revolving or Ranged Revolving or Non-Redemption.

Revolving Ratio

If the az. account is attached to Revolving Product type – then the %age of Revolving ratio will be populated from the APP.

Repay Amt

If the customer wishes to make a 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

TEMENOS T24 User Guide

Page 177 of 189

All in One Account

this field is the way out and not through any other mode.

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

to REVERSE the teller. Nevertheless, when drawdown is made through Drawdown field in AZ – Then for cancellation only this field need to be used.

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

TEMENOS T24 User Guide

Page 178 of 189

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 26th, the repay date is 27th i.e. interest for 1 day at the above rates (leaving the LAST day. If the ACCOUNT.ACCRUAL is yes, interest will be calculated for 2 days).

TEMENOS T24 User Guide

Page 179 of 189

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

TEMENOS T24 User Guide

Page 180 of 189

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 APPROPRIATION. TYPE defined in the product parameter attached to the account. 3. Table AZ.SETTLEMENT.PRIORITY should be set for the handling and withdrawal charges as shown below:

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. TEMENOS T24 User Guide

Page 181 of 189

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

TEMENOS T24 User Guide

Page 182 of 189

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 account’s components happens. Settlement should clear INT.ADJ.AMT field. The rest of the amount should be used for settling other components.

•

In case of failure of repayment on repay date, at PD will be created for sub-accounts only as of now. This will be now relaxed 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 AZ.PRODUCT.PARAMETER.

•

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

TEMENOS T24 User Guide

Page 183 of 189

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

TEMENOS T24 User Guide

Page 184 of 189

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 doesn’t 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

100.00

[Repayment received] “CI” amount

53.52

53.52

“CC” amount

90000.00

90000.00

TOTAL

Principal

Category Past due previous

–

month

Balance

90653.52

Interest

PD penalty

5

3

Past due – previous month

8

6

4

Scheduled month)

10

9

Withdrawal charge

2

1

13

12

(current

Remaining principal

New drawdown after close

11 15

14

17

16

19

18

Repayment Procedure Repayment through AZ Repayment through AZ account is done using fields REPAY.AMT and REPAY.V.DATE TEMENOS T24 User Guide

Handling charge

before 7

payment

90153.52

Page 185 of 189

None

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

TEMENOS T24 User Guide

Page 186 of 189

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

“C” schedules –being charges to be collected on REPAY date.

500.00

REVOLVING RATIOapplied to generate “CC” schedule

10% -150000*10/100@

Minimum Repayment

TEMENOS T24 User Guide

[150000*8.88*8/36000]

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.

Page 187 of 189

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 TOTAL DUE

15000.00 15796.00

Apart from the set-up the trigger to PD is when a payment is attempted on the account. For example, on or after the repay date if payment is received, for say 6500, then based on the AZ.SETTLEMENT.PRIORITY (which is explained separately) the amount will be adjusted towards “C” for 500.00 and “CI” for 296 and the balance to “CC” schedule. This payment leaves a balance of 9296, which is automatically moved to PD.

AZ.SETTLEMENT.PRIORITY This application is used to distinguish between charges input during the drawdown in AZ as to which is part of withdrawal charges and which fall under the Handling fee.

A brief description of how the AZ. SETTLEMENT.PRIORITY works is shown below:

WHENEVER PAYMENT IS RECEIVED

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

TEMENOS T24 User Guide

Page 188 of 189

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

PD- past due created on 25.10.02

12000.00

PD- past due created on 25.12.02 Current Month repayment-25.1.03

(4) 8000.00

Interest

PD Penalty

850.00

650.00

125.26

(3)

350.00

141.26

(2)

(1)

(6) 14000.00

650.00

(5) 755.00

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

23874.74

-141.26

23733.48

SECOND adjustment should towards PD Penalty interest

be

-650.00

23083.48

-350.00

22733.48

THIRD adjustment towards Interest

be

-850.00

21883.48

-650.00

21233.48

-12000.00

9233.48

-8000.00

1233.48

Now the remaining amount is adjusted for the current O/s

-755.00

478.48

After adjusting -478.48 towards principal the balance principal

-478.48

should

FOURTH adjustment should towards the PD principal.

will be adjusted repayment amount.

TEMENOS T24 User Guide

in

the

be

(Interest is adjusted)

next

Page 189 of 189

Charges

0.00