All in One Account

(1)

TEMENOS T24

All in One Account

(2)

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.

(5)

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

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

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

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

Defining parameters

(6)

All in One Account

Figure 1AZ.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.

(7)

All in One Account

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

The variable interest rate is defined in terms of a RATE.KEY that is set up in BASIC.RATE.TEXT and

BASIC.INTEREST, e.g. the selection of 1-Base Rate, for a system with USD local currency, will use

the ‘1USDyyyymmdd’ rate in BASIC.INTEREST. Over and above the rate identified by the rate key, the user may then increase or decrease this ‘base rate’ by inputting a RATE.SPREAD and a RATE.OPERAND. The rate spread is the amount by which the user wishes to change the key rate, and the rate operand determines the manner in which the user wishes to either increase or decrease the key rate.

EXAMPLE FOR COMBINED INTEREST

BASIC.RATE.TEXT @ID 1

DESCRIPTION Base Rate

BASIC.INTEREST @ID 1USD20001120

INTEREST.RATE 4.5

AZ.PRODUCT.PARAMETER @ID 1

RATE.KEY 1 Base Rate RATE.SPREAD 2.5

RATE.OPERAND ADD RATE.PERCENT 70 INT.FIXED.RATE 10

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

Draw down Amounts

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

(8)

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.

(9)

All in One Account

Figure 2 Defining AZ.PRODUCT.PARAMETER

EXAMPLE

DESCRIPTION Base Rate

BASIC.INTEREST @ID 1USD20001120

INTEREST.RATE 4.5

AZ.PRODUCT.PARAMETER @ID 1

RATE.KEY 1 Base Rate

RATE.SPREAD 2.5

(10)

All in One Account

APPLY.PENALTY Y

PENAL.OPERAND ADD

PENAL.MARGIN 5

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

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

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

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

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

EXAMPLE

(11)

All in One Account RATE.SPREAD 2.5 RATE.OPERAND ADD RATE.PERCENT 70 INT.FIXED.RATE 10 APPLY.PENALTY Y GRACE.PERIOD 7 PENAL.OPERAND ADD PENAL.MARGIN 5 PENAL.RATE 12.90 PENALTY.ON 1 Arrears

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

• Repayment due date 31 MAR 2001 • Repayment amount USD5000.00

• Bank Date 7 APR 2001

• Total Arrears amount USD5000.00 • Interest Basis A 360/360

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

Posting Restriction

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

AZ.Account and AZ.Product.Parameter workflow

AZ.PRODUCT.PARAMETER contains control and default value parameters.

AZ.ACCOUNT fields belong to two logical groups, viz. Loan Inputs and Schedule Inputs.

(12)

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.

(13)

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.

(14)

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

(15)

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

(16)

All in One Account

TELLER

the correct transaction code needs to be used on the side where AZ.ACCOUNT is populated is to identify the correct transaction.

It is now possible when performing a part redemption on an AZ.ACCOUNT Fixed Deposit through

TELLER

to specify if a TELLER.DEFAULT record is to be created or not. This must be stipulated in the AZ..PRODUCT.PARAMETER in field CREATE.TD.FOR.INT.

If this value is YES then a

TELLER.DEFAULT record will be created when a TELLER transaction is

processed debiting an AZ.ACCOUNT Fixed Deposit. This will only be created when no nominated/interest liquidation is specified on the AZ.ACCOUNT.

If the field CREATE.TD.FOR.INT is NULL the interest will be credited to the credit side account irrespective of it being the till account.

Loan Principal and Drawdown options

The value of the loan is defined in the field PRINCIPAL. Depending on the value selected in the

AZ.PRODUCT.PARAMETER

field DRAWDOWN.TYPE, the loan amount may be disbursed either as one full drawdown amount or as multiple partial drawdown amounts.

Full Drawdown

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

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

(17)

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

(18)

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:

(19)

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 NON-REDEMPTION. The loan type is defined in the REPAYMENT.TYPE field. For a description of these loan products refer to the User Guide for MORTGAGES.

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

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

There are two deposit products available, viz. SAVINGS-PLAN and FIXED. In FIXED the deposit amount is accepted in a fixed lump sum and repaid as fixed amount either with interest accumulated 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

(20)

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.

(21)

All in One Account

(22)

All in One Account

(23)

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.

(24)

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.

(25)

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.

(26)

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.

(27)

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.

(28)

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.

(29)

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.

(30)

All in One Account

Charges cannot be capitalised One-time Charge Collection:

This is for collecting a one-time charge as defined in AZ account.

·As and when charge details are filled in the relevant fields and authorised, one time charge will be collected from the CHG.LIQUID.AC (new field) as per the CHARGE.CODE (existing field) and CHARGE.DATE (existing field) as an on-line activity

The CHARGE.DATE field mentioned here should have only the process day (business date / GLOBUS date) by default. That means for future dated charge collection the fields under Schedules have to be used.

The existing charge fields CHARGE.CODE and CHARGE.DATE are active at present only for pre-closure.

Rebuilding schedules after an online repayment of annuity loan

When 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”

(31)

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

(32)

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 will be taken into account, for automatic rescheduling.

Loan Repayment Schedule History

Changes in Principal amount, Rate of interest, Term, or Frequency may result in Re scheduling, based on the value of Term Priority opted by the user, in AZ.ACCOUNT.

(33)

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.

(34)

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

(35)

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

(36)

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.

(37)

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.

(38)

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

(39)

All in One Account

Since the value of the field SINGLE.LIMIT in ACCOUNT and

AZ.PRODUCT.PARAMETER

does not match, while creating an AZ account would raise an error.

(40)

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.

(41)

All in One Account

(42)

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.

(43)

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.

(44)

All in One Account

(45)

All in One Account

(46)

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.

(47)

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.

(48)

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 “I” 17.09.03- DAILY “N” 17.09.03- DAILY

(49)

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.03- the system realises that the instalment could not be recovered and that it has to update the overdues file. This is in case of Grace Period field being Null. In case the grace period field in AZ.

PRODUCT.PARAMETER

(APP) is taken in to a/c and the AZ. OVERDUES file is updated after the expiry of the GRACE period with the date on which it was originally due. To continue the present example if the Grace period in APP is given as 01C –then the system would have written the AZ.

OVERDUES file only on 18.09.03 and not on 17.09.03 as was the case at present.

(50)

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 .

(51)

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.

(52)

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.

(53)

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.

(54)

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.

(55)

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

All in One Account

TEMENOS T24