07.1 Past Due Processing

Past Due Processing - User Guide R16 AMR May 2016

©2016 Temenos Headquarters SA - All rights reserved. Warning: This document is protected by copyright law and international treaties. Unauthorised reproduction of this document, or any portion of it, may result in severe and criminal penalties, and will be prosecuted to the maximum extent possible under law.

Table of Contents Introduction

3

Purpose of this Guide Intended Audience

3 3

Past Due Processing Overview

4

Past Due Processing Configuration

5

Setting processing rules - PD.PARAMETER Application Design Past Due Processing Deal Processing Overview

5 5 15 15

Processing a loan - PD.PAYMENT.DUE Interest Capitalisation Supporting PD Applications

16 28 29

Links to other applications

32

Asset quality and provisioning

34

Example of Provisioning

39

Repayment of written off contracts

54

Past Due Processing Accounting

65

Income Recognition

66

Accounting for Provisioning

67

Accounting for financial Write-off

68

Past Due Processing Enquiries and Reports

69

Enquiries Reports

69 69

Past Due Processing Delivery PD.ACTIVITY PD.ADVICES

72 72 72

Past Due Processing Limits

74

Limit Update Events Note on Reducing Limits Note on Accounts

74 74 74

Past Due Processing Services Close of Business Services Automatic Pay-off of PD

75 75 76

Past Due Processing - User Guide - R16 AMR - Page 2 of 79

Introduction Purpose of this Guide This user guide describes monitoring and controlling overdue loan payments. It also explains the processing of a loan, asset quality and provisioning, income recognition, and account for provisioning.

Intended Audience This user guide is intended to the following users / user roles: Role

Description

Credit Officer

Handles Credit appraisal, Sanctioning of limits, Disbursal and Servicing of Loans

Credit Manager

Handles the entire Credit sanction process, including consistent application of credit policy and periodic credit reviews of existing customers

Payments Officer

Process transactions which involve Inward and Outward Remittances, Clears Operations and Cheque collection

Payments Supervisor

Authorises remittances, clears and cheque collection transactions and ensure adequate controls and risk processes are followed

Past Due Processing - User Guide - R16 AMR - Page 3 of 79

Past Due Processing Overview The Past Due Processing module allows users to monitor and control overdue loan payments. Payments to Loans monitored by the PD module are only made where funds are available.  If payment is not made, the contract becomes ‘overdue’ and can be monitored and processed accordingly. Whether a loan is monitored by the Past Due module or not is determined by a flag set on the contract, the LIQUIDATION.MODE may have one of the following values: MANUAL

The underlying contract will always pass the debit to Past Due for control, regardless of the availability of funds.

SEMIAUTOMATIC

The underlying contract will utilise funds that are available on the specified account but if there are insufficient funds then the debit is passed to Past Due for control.

AUTOMATIC

The underlying contract will not invoke Past Due processing and the due amounts are debited to the specified account as per the application rules. Liquidation Mode Values

USE.AVBL.FUNDS is a field available in PD.PARAMETER, which, when activated, will use any funds available in the respective liquidation account to settle the payment due partially and create a PD for the shortfall. Contracts input via the following T24 modules can currently be monitored by the Past Due module: •          Swaps •          Money Market •          Mortgages •          Loans and Deposits •          Accounts Where a loan is monitored by PDs, and a payment is not made on its due date, that payment becomes ‘overdue’.  Overdue payments go through a T24 debt ageing process - the PD module performs different actions as the payment becomes more and more overdue.  PDs will: •             Accrue, charge and post penalty interest •             Send chaser advices for the overdue amounts •             Report the loan according to the age of the debt PD processing is at payment level.  Each payment can travel through the PD debt cycle independently.

Past Due Processing - User Guide - R16 AMR - Page 4 of 79

Past Due Processing Configuration Setting processing rules - PD.PARAMETER How PDs deal with the overdue payment is determined by the settings on PD.PARAMETER.  You can have a PD.PARAMETER record for each loan category, so PD processing can be different for the various products. For example the overdue processing cycle will usually differ when dealing with an overdue Mortgage and an overdue Money Market trade. Where no record is defined for the category of product being processed, the Past Due module defaults to the company settings. A record with an id equivalent to the company id must exist on the PD.PARAMETER file to allow standard PD processing. Where AC is linked to PD then the PD.PARAMETER record AC must also exist. Penalties can be processed based on several key settings. After the relevant PD.PARAMETER record has been used the settings within that record will control how the PD processing continues. The PEN.CALC.BASIS and PS.CALC.BASIS fields are used to decide what the penalties are calculated on. For example the penalty PE type can be based on the outstanding PR element, the IN element or several combinations depending on the bank rules or client agreement. As well as individual elements there are logical groups such as OD (this is the overdue amount only) or OS (this is the total of the overdue and the current loan outstanding). The former is all the overdue elements meaning all outstandings are used in the penalty calculation; the latter is a more punitive penalty as it calculates on both overdue and current outstandings (this is sometimes used where a discount rate is applied for current loans but on any overdue the discount is forfeited). These files can only be maintained online i.e. cannot be input or amended once COB has started, even if NS (Non Stop Processing) is installed.

Application Design Lifecycle rules A payment in PD may pass through the following statuses in its ‘life’: CUR → PRE → GRA → PDO → NAB → WOF  Status

Processing

CUR

Current

This is the status of a past due payment when it is fully up to date (i.e.) there is nothing outstanding

PRE

Pre Grace

No penalties are applied whilst the payment is in Pre-Grace. Penalties are neither calculated, accrued nor posted

GRA

Grace

The payment has not been overdue for long. During the grace period the penalty is calculated for information purposes but no accruals are posted. Depending on parameter settings a payment made during the grace period may have the calculated penalty waived or imposed.

PDO

Past Due Obligation

The payment is now definitely overdue. The penalty interest is calculated, accrued and posted.

NAB

Non Accrual Basis

The payment has been overdue for some time and the bank is unlikely that it will receive payment. Hence penalty interest accruals cease, though the calculations continue.

WOF

Write off

The past due payment will not be received and so is written off from the bank’s books

FWOF Financial write off

If this option is chosen, then not only the past dues but also the amount in the underlying parent contract is written off. PD Payment Life Cycle

When a payment falls due, it is initially in PRE grace.  It progresses to GRA, then to PDO and then to NAB. The payment can become CUR through full payment or WOF if the bank decides to manually write off the payment.

Past Due Processing - User Guide - R16 AMR - Page 5 of 79

It is possible to improve the status from NAB to PDO on account of partial payment that clears off the NAB portion of the dues or by redefining the NAB.PERIOD.INT and NAB.PERIOD.SPREAD days. This functionality could be invoked by flagging CHANGE.STATUS to 'YES' in PD.PARAMETER. PD.PARAMETER contains the time settings that determine when a payment moves from PRE to GRA, from GRA to PDO and from PDO to NAB, and may be defined as a number of days or as a number of payments. In case the change of status from PDO to NAB is not to be automated and controlled only manually, 'NO' may be input in NAB.PERIOD.INT and NAB.PERIOD.SPREAD. In this case status of the PD would be retained as PDO till such time the record is manually maintained to NAB.

PD.PARAMETER file

Penalty interest details Once a payment becomes ‘due’, the loan module stops calculating contractual interest and hands the payment over to PDs.  PDs charge ‘penalty’ interest, which will usually be higher than the rate on the contract.  On PD.PARAMETERyou can define:

Past Due Processing - User Guide - R16 AMR - Page 6 of 79

•          Penalty calculation rules, e.g. the amount used to calculate penalty. Any combination of the amounts overdue may be used to calculate the penalty, e.g. principal portion of the payment due, the total principal outstanding on the contract, charges, interest, etc. •          Default penalty rates, both fixed and floating •          Maximum and minimum penalty rates The amount used to calculate penalty spread for CONTRACT.METHOD 2 is configurable.  CONTRACT.METHOD 2 accrues penalty interest and penalty spread separately. Penalty interest is calculated at the underlying contract rate for an amount defined via PEN.CALC.BASIS on PD.PARAMETER. Penalty spread is calculated at the PENALTY.SPREADRATE for an amount defined via PS.CALC.BASIS on PD.PARAMETER, with the outstanding amount as the default. CONTRACT.METHOD 4 accrues penalty interest and penalty spread together. The rate used is the underlying contract rate plus the PENALTY.SPREAD defined on PD.PARAMETER. The amount used is defined via PEN.CALC.BASIS on PD.PARAMETER,. PD.BALANCES records show the spread component of the rate used in PENALTY.SPREAD. The rate from an underlying LD contract (where a key and spread is defined) includes rates applicable for the respective BASIC.INTEREST key plus the spread on the deal. Hence, the user may define only the penalty spread in PD.PARAMETER as PS. It is possible to stipulate that the penalty spread will be automatically calculated by the system, by setting the AUTO.ADJ.SPREADto YES. In such cases, the field PENALTY.SPREADcannot be input.  The penalty spread will then be calculated by the system as the difference between the rate in PENALTY.RATE and the rate of the underlying contract. If there is a value in PENALTY.RATEat the contract level, it will take precedence over the rate in PENALTY.RATEat the PD.PARAMETER level. The calculation of spread will begin when the number of days/number of instalments stipulated in PE.SWITCH.PERIOD has been crossed. The basis for calculation of penalty spread will be on the base specified in POST.GR.PS.CALC. If it is required that penalty spread calculations continue even after all past dues are cleared, RESTORE.CALC should have a null value.

Waiving option for the Grace period penalty interest Two PD.AMOUNT.TYPES WE and WS may need to be added for Waiver of penalty interest and spread respectively.

PD.AMOUNT.TYPE

Past Due Processing - User Guide - R16 AMR - Page 7 of 79

PD.AMOUNT.TYPE These amount types need to be added to the PD.PARAMETER record as below.

PD.PARAMTER file The two fields WAIVE.GRA.PE & WAIVE.GRA.PS in PD.PARAMETER and PD.PAYMENT.DUE when flagged to “Yes”, will waive penalty Interest/spread amount calculated during grace period instead of imposing it. The fields cannot have different values i.e. one of them set to YES and the other left Null.

Past Due Processing - User Guide - R16 AMR - Page 8 of 79

PD.PARAMETER file The value from the parameter record gets defaulted to the underlying contract where the values can be changed, if required.

Past Due Processing - User Guide - R16 AMR - Page 9 of 79

Past Due Processing - User Guide - R16 AMR - Page 10 of 79

PD.PAYMENT.DUE record The waived penalty interest (and tax if any) will be shown under WE and the waived penalty spread amount (and tax if any) will be shown under the WS component. When the contract moves to post grace period, it is not be possible to waive PE/PS by using these fields. However Adjustment operation can be done so that the penalty interest (PE) and penalty spread (PS) can be adjusted to 0. In the event of partial repayment during grace period, PE/PS can still be waived using new fields. When PD moves from grace period to PDO/NAB, PE/PS would be calculated from the start of the grace period on current outstanding overdue amount and not from the partial repayment date.

Interest basis The interest basis (366/360, 366/360 etc) for calculation of penalty charges, spread etc may be different from that used in the underlying contract. The new basis that the system has to use when a contract moves from its respective application to PD, can be stipulated in INTEREST.BASIS in PD.PARAMETER. If left blank, the basis used in the underlying contract is continued.

Suspension of Income in Underlying Deal It is possible to suspend income on the associated LD/MG/AZ deal should the past due become NAB. Suspension of income includes interest and commission on the LD and interest only on MG/AZ. This functionality is invoked by flagging SUSPEND.INCOME in the respective PD.PARAMETER. Such suspension of income can be triggered for selective PD.PARAMETER records if so desired.

Any amount to hit limit In the SYSTEM record of PD.PARAMETER, if the field IMPACT.LIMIT is set to YES, then all overdue amounts that flow from the parent application to PD, will hit the customer’s limit. That is, apart from the overdue principal, other past due amount like interest, charges, fees and commission will also hit the limit. However, accruals on the PD contract itself like penalty spread and charges will not affect the customer limit.

Repayment order Typically, a contract may have several payments outstanding.  Each payment will have a principal and an interest portion, and could also have associated amounts of penalty, tax, charges, etc.  When the client makes a payment, this may not cover the full overdue amount. You can specify on PD.PARAMETER the order in which the outstanding amounts are repaid by default.  All amounts of a ‘type’ (for instance, PR is the Principal ‘type’) will be paid together, and paid in reverse date order.  That is, if PR is defined in PD.PARAMETER as the first type to be paid, and the client pays enough to cover half the principal outstanding, the youngest principal payment will be paid off first, and so on until the entire repayment amount is used up.  It is possible to repay both on line and via Close of Business Semi-automatic processing in chronological order i.e. the oldest repayments are paid first. REPAYMENT.METHOD on PD.PARAMETER defines the type of repayment processing; three methods of repayment are available. 1.    Repayment order by type as defined in REPAYMENT.ORDER, the current default 2.    Total outstanding by date, total repayment for a given repayment date in chronological order with MIN.AUTO.PERCENT processing taking place, repayment will only take place if there are funds available to cover the whole amount overdue for that date (or a defined percentage of it) 3.    Repayment order by date, repayment will take place in chronological order, and by repayment order for each date, repayment will stop when no funds are available to cover an amount type for a given date, i.e. partial repayment of the debt for a given date can take place. If the requirement is to use the available funds in the ORIG.STLMNT.ACT for appropriation and not overdraw, USE.AVBL.FUNDS may be flagged to 'YES'.  Should the liquidation account have a value defined in LOCKED.AMOUNT field in ACCOUNT, such amount for the respective period would be reckoned while deriving the amount available for retry. The PD Close of Business processing can attempt repayment up to NAB status, and process multiple PD.BALANCES records. RETRY.REPAY.STATUS on PD.PARAMETER is used to define the PD status up to which repayments will be attempted.

Past Due Processing - User Guide - R16 AMR - Page 11 of 79

PD.PARAMETER FILE

Past Due Processing - User Guide - R16 AMR - Page 12 of 79

PD.PARAMETER File (CONT) The COB retry also covers PDPD (PD deals without underlying contracts) contracts. However, should the user desire to avoid retry for a particular contract, PREVENT.RETRY field in the PD contract may be flagged YES through Maintenance operation.

Accounting Rules The other fields on PD.PARAMETER allow you to specify the CATEGORY and TRANSACTION codes used for reporting PD amounts.

Past Due Processing - User Guide - R16 AMR - Page 13 of 79

PD.PARAMETER File specifying Category and Transaction Codes

AC Parameter Set-up For the account to be linked to PD, the fields AC.CP.CATEG.FR, AC.CP.CATEG.TO, AC.CB.CATEG.FR, AC.CB.CATEG.TO, AC.OD.DAYS need to be defined in this parameter record. The first two fields form a multivalue set and they are used to define the revolving credit account categories to be linked to PD. The next two fields define the account category range for linking overdrawn accounts into PD. The field AC.OD.DAYS field defines the number of days from which the overdrawn account would be linked to PD. For any other parameter record, no inputs are allowed into the above-mentioned fields. If there were no ‘AC’ parameter record, then accounts would not be linked to PD at all. No penalty could be calculated on the account PD. allowing only the contract method ‘5’ in the field CONTRACT.METHOD of the ‘AC’ parameter record ensures this. Separate parameter records could also be set-up for the account categories input in the relevant fields in ‘AC’ parameter record. These records also don’t accept penalty calculation. For any other account not within the category of CB and CP ranges mentioned above, PD would be written for the unauthorised overdraft portion on the day such account is overdrawn. For an account with no limit any debit balance would be construed as unauthorised and for one with limit, the drawings in excess of limit would be considered as unauthorised. A set of accounting entries would be raised with ASSET.TYPE OVERDUEPR (Debit) and CONTRAAC (Credit) for such unauthorised portion. The actual balance in the account would be retained in ACCOUNT application. The user may read DEBIT and CONTRAAC ASSET.TYPES in one line and OVERDUEPR in another in order to report authorised and unauthorised overdraft in different lines.

Past Due Processing - User Guide - R16 AMR - Page 14 of 79

Past Due Processing Deal Processing Overview If a loan is monitored by the Past Due module and a payment occurs, it is processed by the contract as usual.  However, instead of debiting the repayment account (which may not have funds), the contract debits the G/L for overdue payment.  The payment is handed to PDs.  Payments may also be monitored by PDs where they have been input via PD.CAPTURE, which is described later in this chapter. l

Processing a loan - PD.PAYMENT.DUE

l

Links to other applications

l

Asset quality and provisioning

l

Example of Provisioning

l

Repayment of written off contracts

Past Due Processing - User Guide - R16 AMR - Page 15 of 79

Processing a loan - PD.PAYMENT.DUE A new PD Contract is made in the application PD.PAYMENT.DUE, which contains all payments which have fallen due and not yet been fully repaid.  ‘PD’ plus the original contract id identify a contract, e.g. a Mortgage contract with an Id of MG0103100412 would have a PD record with an Id of PDMG0103100412. (Contracts created through the PD.CAPTURE application have a prefix of “PDPD”, e.g. PDPD0101500366.) The file holds details about the underlying contract as well as all the outstanding payments due.  For each overdue payment, the PD contract records the date the payment fell due, and the amounts currently owed for each ‘amount type’.  Initially, the payment is made up of Principal and Interest, but other amounts may be added - for instance as penalty interest is earned, a penalty amount will be added to the payment.  Valid amount types are stored on PD.AMOUNT.TYPE, which is described later in this chapter.

Automatic processing As a payment ‘ages’ - as it becomes more and more overdue - PDs will automatically change the status of the payment according to the dates set in PD.PARAMETER.  The status of the payment determines the penalty interest processing.  PDs check the rules set in PD.PARAMETER to determine: •           Whether interest should be calculated, accrued and posted. •           The basis for calculating penalty interest. The basic penalty interest and the penalty spread for each payment is recorded as additional amounts on the PD contract record in PD.PAYMENT.DUE.  The status of the payment can also trigger chaser advices.  Flags in PD.PARAMETER determine whether an advice is sent on change of status from GRA to PDO and from PDO to NAB.  The advice is a free-format 1600 message.  There is one PD.PAYMENT.DUE record for the entire contract, but within the record each payment is monitored separately.  Each payment can have a different status, and will accrue interest and trigger advices independently of the other payments.  There is also a field that holds the overdue status for the whole contract, which is always set to the status of the ‘worst’ payment.  Hence if there are two payments outstanding on a contract, one in GRA and one in PDO, the contract status is PDO.  This contract status is recorded on both the PD.PAYMENT.DUE record and the original contract record, so it can be included in all reports and enquiries.  In addition to automatic processing, some overdue processing is controlled by input to the PD contract.  The action PDs performs as a result of PD.PAYMENT.DUE changes is determined by the contents of the ‘operation’ field.  Different operations require different fields to be filled in.  PDs will automatically input-protect the fields that are not required for the operation being performed.

Operation - Schedule The ‘Schedule’ operation allows definition of future PD events for that contract: •             Penalty rate or spread changes to be input for a future date. •             Regular chaser advice to be scheduled on a set frequency - e.g. every week.

Past Due Processing - User Guide - R16 AMR - Page 16 of 79

The other OPERATION codes allow manual changes to the overdue processing for the contract; these changes take effect immediately.

Operation – Repay The most important operation is Repay.  All payments to loans monitored by PDs are made manually via the repay operation.

Past Due Processing - User Guide - R16 AMR - Page 17 of 79

PD.PAYMENT.DUE.REPAY Record PD.PARAMETER contains a hierarchy of types of outstanding payments.  Separate records can be set up for different categories, so the repayment order can be different for each product. For example the following order could be set up for a given loan category: •          Outstanding Penalty Interest •          Outstanding Interest •          Outstanding Principal The implication of the hierarchy is that before any outstanding principal can be repaid, all the penalty interest, then all overdue interest must be repaid across the whole set of individual overdue payments for the loan. The system automatically uses these rules to allocate any repayment against the various types of outstanding from when the payment is input.  However, the user can override this default repayment order.  If this occurs, the user is presented with standard overrides before the payment is finally committed. When repayment is made, the REPAYMENT.ACCT will be the default repayment ACCOUNT that is the original settlement ACCOUNT nominated on the underlying loan contract. This ACCOUNT may be amended at the time of any repayment input, or during contract maintenance. Each payment receipt is recorded in the history of the Past Due application to provide a full audit trail.  There is also a separate file, PD.REPAYMENT, which holds details of each repayment made for each contract.  This file is described later in this chapter For a given contract, there may be many payments outstanding, each made up of different amount types.  All outstanding amounts for the contract can be paid, or partial repayment can be made.  Where part payment is made, PDs matches the money available against the outstanding amounts according to the order specified on the PD.PARAMETER record, to determine which amounts should be paid off and which should be left unpaid.

Operation - Maintenance The MAINTENANCE operation has several uses: 1.      To change the way the exposure of the overdue is reported, by changing:

Past Due Processing - User Guide - R16 AMR - Page 18 of 79

•          The LIMIT.REFERENCE •          The PORTFOLIO.NO 2.       To determine accounting rules: •          Whether accounting entries are netted over the client account. •          Whether the default settlement account is used. 3.      To change the status of individual payments. 4.       To change the value of the penalty waiver fields. The status change option is mostly used to change payments to NAB (Non Accrual Basis) or WOF (Written Off) status if the user judges that there is little chance of recovering that payment.  Hence the status of a payment can only be made ‘worse’ - i.e. you can change a payment from GRA to PDO, or from GRA to WOF, but you cannot change a PDO payment back to GRA.  Similarly, a recently overdue payment cannot be in a ‘worse’ status than an older payment.  For example, a loan has two payments overdue - one 2 months overdue, and in PDO, and one 1 month overdue, in GRA.  If you choose to write off one payment, it will be the older, PDO payment.  T24 will not let you put the GRA payment into WOF until the PDO payment has been written off.  Another option that can be chosen is FWOF (financial write-off). Unlike the WOF option, which is used to write off only past dues of a contract (after which the PD contract returns to CUR status), FWOF is used to completely write off a contract (the past dues contract as well the contract from the underlying application). Therefore, if there is an underlying contract for a PD, it first has to be moved to past due for an FWOF operation to be done. After the PD is in FWOF status, all calculations in the PD contract for penalty interest/spread will be frozen, but will continue to be shown in the PD contract till the user decides to move the contract to history. For this purpose, he can use the field MOVE.TO.HIS.

PD.PAYMNET.DUE WOF record

Operation – Adjustment The ADJUSTMENT operation is used to adjust the outstanding payment amounts, by type, either upwards or downwards or to zero.

Past Due Processing - User Guide - R16 AMR - Page 19 of 79

If the adjustment is done to Asset Types PE and PS, entries are passed to CATEG ENTRY file if the PD is in OVERDUE status and to RE.CONSOL.SPEC.ENTRY file (into Asset Type SP) if the repaid status is NAB, into the respective PL category and Asset Type respectively. If adjustment is done to any other PD.AMOUNT.TYPE, input of ‘Liquidation Account’ is mandatory. For the amount of adjustment done, STMT.ENTRY is raised into the liquidation account mentioned.

PD.PAYMNET.DUE Adjustment Screen

PD.PAYMENT.DUE Rounding The option to override the system setup for currency amount rounding can be set specifically for PD. This is done first in PD.PARAMETER, which is then used to default into both PD.CAPTURE and PD.REPAYMENT.DUE level is provided by use of field ROUNDING.RULE this links to the system table EB.ROUNDING.RULE where various user defined rules can be preset. Although defaulted from PD.PARAMETER, both PD.CAPTURE and PD.REPAYMENT.DUE can be set individually. The field name is ROUNDING.RULE on all three files for consistency. Rounding is performed on the interest & charge accounting in PD.

PD accrual options The normal accrual calculations used in PD can be overridden by user-defined rules, which are defined in EB.ACCRUAL.PARAM this is done by use of the field ACCRUAL.PARAM on both PD.CAPTURE and PD.PAYMENT.DUE. Since amendments to accrual calculation methods are unique to each bank and somewhat rare there is little point is showing an example specific to PD other than to direct the reader to the User Guide section on EB.ACCRUAL.PARAM itself.

ASSET CLASSIFICATION AND PROVISIONING The field ASSET.CLASS is used to input the classification of the underlying contract (e.g) standard, sub-standard etc. The classification is user defined and user input. The field PROVISIONis meant to input the percentage provision made on the contract. The values held in these two fields are meant for information purposes only.

Past Due Processing - User Guide - R16 AMR - Page 20 of 79

PD.CAPTURE PD.CAPTURE is an application that allows loans already in arrears to be monitored by PDs. It is used: •          For take-over of loans already in arrears in new implementations of Past Due. •          For manual capture of due amounts where the loan has not been monitored by Past Due from the start. It enables the user to manually create or update PD.PAYMENT.DUE contracts for back-valued overdue payments. Another feature is that it is not necessary for an underlying loan contract to be present on the T24 system in order to raise PD.PAYMENT.DUE contracts. Thus, due amounts on accounts can be processed by Past Due. If the PD.PAYMENT.DUE contracts to be raised/updated has an underlying loan contract on the system, then the CONTRACT.NUMBER field on PD.CAPTURE must contain the relevant loan Id. Once this is entered certain information will be defaulted from the underlying loan and the user then has to enter details of the overdue payment. If the PD.PAYMENT.DUE contract to be raised does not have an underlying loan contract on the system then the CONTRACT.NUMBER field on PD.CAPTURE must contain a value of “NEW”. The user will then have to enter certain information about the PD to be raised as well as details of the overdue payment. The PD.PAYMENT.DUE contract raised will have an Id with a prefix of “PDPD” and the actual Id will be held in the field NEXT.PD.ID on the PD.CAPTURE file. The only accounts that can be captured using PD.CAPTURE are those whose category is mentioned in AZ.PRODUCT.PARAMETER as a loan type. NOTE : If a PD.PAYMENT.DUE contract raised by PD.CAPTURE with the prefix of “PDPD” in it’s Id needs to be updated using PD.CAPTURE then the CONTRACT.NUMBER field should contain the “PDPD” Id and not “NEW”.

Past Due Processing - User Guide - R16 AMR - Page 21 of 79

PD.CAPTURE.EXIST Record

Past Due Processing - User Guide - R16 AMR - Page 22 of 79

PD.CAPTURE NEW Record There is no need for the penalty interest amount to be provided as it will be calculated from the information stored, as per the current processing by the Past Due module. If the PD.CAPTURE entry makes an update to an existing PD.PAYMENT.DUE contract and the value date entered is one already present on the contract then any new payment types due will be appended to the existing types. However, if any of the new types already exist on the PD.PAYMENT.DUE contract then the new amount due will be added to the existing amount. The amount entered in the OUTSTANDING.BAL field will be used to calculate the penalty interest and/or penalty spread depending on how the relevant PD.PARAMETER record has been set up. Any new entries through PD.CAPTURE may affect the status of overdue items already present depending again on how the relevant PD.PARAMETER record is set up. It is important that the Bank populates the BASIC.INTEREST table with the correct interest rates for all the back-valued events. The Penalty Interest will be calculated depending on how the relevant PD.PARAMETER record is set up. Where the rate calculated by the system does not correlate with the rate at the time of the take-over process, it is possible to change this rate by performing a rate change (RC) type schedule once the PD.PAYMENT.DUE contract is created.

Settlement based on instalment definitions The field PAYMENT.ROLLOVER in PD.PARAMETER which will accept a value only based on the below conditions. Once the parameter record is authorised, this field is a No-change field. a)

Sub pay setting should be set as Yes.

b)

Repayment method should be 1.

c)

Penalty capitalization not allowed.

d)

PE & PS should be the first two components in the Repayment order.

To capture the instalment components (PR, IN and CH etc), use the multi-value field INS.AMT.TYPES in PD.PARAMETER.

Past Due Processing - User Guide - R16 AMR - Page 23 of 79

Multi value fields in the PD.PAYMENT.DUE store the instalment due amount with due effective date. During the due creation process, the system will update instalment due amount fields in the PD record based on the instalment definitions in the PD.PARAMETER. On repayment process, the instalment amount set of fields will be nullified/ reduced accordingly.

In case the repayment is equal to or more than one instalment, the system will rollover the residual balances to the next due date and the oldest overdue instalment date is moved forward. If the repayment is on the last due record; then no rollover will happen even though user has repaid the equivalent of instalment amount. The system will update the exception file PD.ROLLOVER.DETAILS with residual balances amount in PD to intimate the user for further action. This file can be viewed only from the jbase prompt.    llustration: In the example shown, annuity schedules have become overdue for payment.  A screenshot of the PD record is as shown.

Past Due Processing - User Guide - R16 AMR - Page 24 of 79

Screenshots of the first two PD.BALANCES records are as shown.

Past Due Processing - User Guide - R16 AMR - Page 25 of 79

Suppose a repayment of 10000.00 is input. This repayment is enough to fully repay the first due record and part amount of the second due record. After the repayment, the PD record is updated as shown.

Past Due Processing - User Guide - R16 AMR - Page 26 of 79

The oldest due record (in this case, the record due on 01 Dec) is fully repaid and the PD.BALANCES record moves to history. The balances rollover to the next PD.BALANCES record of 08 Dec and the accruals will then be based on the new balance amounts.

Past Due Processing - User Guide - R16 AMR - Page 27 of 79

Interest Capitalisation Capitalisation is permitted for both Penalty Income (PE) and Penalty Spread (PS) with frequencies set in numbers of months. The fields, PE.CAP.FREQ and PS.CAP.FREQ can be entered on the PD.PARAMETER table and values can be input in each parameter record. This would enable the user to capitalise interest at different frequencies for different types of Past dues if so desired. This field would specify the date and frequency of the next accrual and would be rolled over to the next effective date during Close of Business on the capitalisation date. The field validations are similar to other T24 frequencies like: •          8 numeric standard date characters followed by a 5 alphanumeric frequency. •          Date input must be equal to or greater than today. •          The frequency should be specified in number of months. The dates and frequencies in PE.CAP.FREQandPS.CAP.FREQ should match. Two separate fields are provided so as to facilitate having capitalisation on either component and not on the other, if so desired.

Past Due Processing - User Guide - R16 AMR - Page 28 of 79

Accounting ASSET.TYPES called CE (Capitalised Penalty Income) and CS (Capitalised Spread) are used to categorise the different types. On the Capitalisation date, the amounts that have been accrued in PE and PS would get posted to CE and CS (Credit into Asset Types PE and PS and Debit to CE and CS). Should the user desire to charge Penalty interest (and Spread) on the capitalised interest also, CE and CS may be included in the PEN.CALC.BASIS and PS.CALC.BASIS. Capitalisation would be for amounts that have been accrued till yesterday and today’s accruals would get posted to PE and PS as per standard T24 functionality. Based on the repaid status on the PD record, movement entries would be raised for CE and CS also, in line with other ASSET.TYPES. While the PD is in OVERDUE status, the CE and CS would be kept in OVERDUECE and OVERDUECS respectively. On change of PD status to NAB, movement entries would be raised by the system and the balances would be moved to NABCE and NABCS. Effectively, since individual balances are maintained separately, it is possible to report capitalised interest and accrued interest in different lines in the General Ledger of the bank. In the RE.CONTRACT.BALANCES file also, CE and CS values are captured separately. When the PD changes status from OVERDUE to NAB, the reversal of interest (if so set up in the Parameter) from P&L will be for the balance in PE and CE (PS and CS). The balance in CE will be moved to NABCE and the accrual (PE) will be moved to respective SP Asset Type in line with existing T24 functionality. If the CRF.BY.TYPE is set to ‘NO’ in the SYSTEM record of the PD.PARAMETER, CE and CS would be clubbed together with other dues and stored under OVERDUEDB or NABDB depending on the repaid status of the PD.  On the capitalisation date, balances in PE and PS would get moved to OVERDUEDB or NABDB instead of CE and CS.

Adjustment during migration At the time of migration onto T24 , the bank may have existing CE and CS balances for various PD records. These balances cannot be taken over as Principle (PR) or Interest (IN) dues and they have to be built by accruals in T24. Based on the value dates of the balances, PE and PS values will be accrued in T24. The bank may have to do the following adjustments after creation of PD record: •          Since first capitalisation in T24 would happen only subsequently, the values of CE and CS would be stored in PE and PS respectively till the next CAP date. •          On the next CAP date the balances in PE and PS would get transferred to CE and CS by movement entries raised in T24 •          The value of CE calculated after first COB would be less than the CE value that was intended to be taken-over. This is because capitalisation in T24 would be effective the date mentioned in the Parameter and hence, if capitalised interest were also to be part of penalty calculation, the amount calculated in T24 would be less to this extent. Hence, after take-over is complete, the PD record should be manually ‘A’djusted to increase the PE portion to the extent that it has accrued less. On the next capitalisation date, the entire amount in PE would get moved to CE. •          This phenomenon would continue for one more frequency. On the first working day in T24 , there is no existing CE (this will get built only on the first CAP date) and hence the accruals will be on the ‘due base’ less the CE portion. So the bank may have to do a similar ‘A’djustment on the first CAP date also in order to prop up the interest to the right figure. Else, such amount could be calculated in the beginning itself and PE amount adjusted immediately after reconciling the take-over balances. •          Similar adjustment may have to be done for Penalty Spread (PS) also, if need be. •          Effective the first CAP date, the accruals and capitalisation will happen in the manner defined.

Supporting PD Applications PD.AMOUNT.TYPE This file defines the different payment amount types allowed in the PD module. It contains a description used for enrichment purposes as well as defining the debit and credit TRANSACTION codes for the types. A TAX code may also be input as well as a position type for Position Management. The following types are allowed:

Past Due Processing - User Guide - R16 AMR - Page 29 of 79

Both CP and CB are off-Balance sheet items.

PD.SCHEDULE.TYPE This file defines the schedule types permitted for the PD contract. It contains a description field for enrichment purposes and in the future may allow a charge or commission to be levied when a schedule is processed. Currently the main schedule types allowed are:

Rate Change (RC) Is used to define the change in rate scheduling. Currently back valued and current date revaluations are allowed. Future rate change definitions may be allowed in later enhancements to the PD module.

Spread Change (SC) Is used to define the schedule for a spread change. Again, this can be current valued or back valued. However, it cannot be forward valued.

Past Due Processing - User Guide - R16 AMR - Page 30 of 79

Chaser Advice (CH)

Used to define the schedule for Chaser advice production.

Past Due Processing - User Guide - R16 AMR - Page 31 of 79

Links to other applications Moving PD outstanding to another Branch It is possible, provided the system has been configured correctly to move outstanding contracts from one branch to another where multibook processing is installed.

Pre-requisites Add in COMPANY record for all the Branches (including the Lead Branch) field PGM.AUTO.ID as ‘EB.COMPANY.CHANGE” Create a new record with ID Start No in AUTO.ID.START for EB.COMPANY.CHANGE Create STANDARD.MAPPING record PD .PAYMENT.DUE CONT.MOVE.CHK.RTN as shown below:

this

should

have

the

routine

PD.COMPANY.CHG.VAL

in

field

Routine for PD contract movement The application EB.COMPANY.CHANGE is used to affect the transfer, which is limited to PDPD type contracts. After the contract has correctly validated and the cob processed have run the account, crf and overdue record will be transferred across to the specified company.

Past Due Processing - User Guide - R16 AMR - Page 32 of 79

Moving PD contract to another branch

Past Due Processing - User Guide - R16 AMR - Page 33 of 79

Asset quality and provisioning Banks value loans at historical cost (face value of the loan as noted in the loan contract) and make periodical adjustments to the loan value depending on risk perception. Banks and regulators in many countries use delinquency as the main benchmark, measured as number of days or months loan payments or past due for loan classification.  Though loans are classified into various categories to reflect the risk involved, at a higher level, loans are broadly classified as Performing or Non-Performing assets. The notion of non-performing loans or assets is used to determine the asset quality of a bank.  Loan classification has a direct bearing on a bank’s income statement. The process of provisioning involves taking a charge against the bank’s income as a provision for future default. Correspondingly a provision is created as a liability in the bank’s balance sheet against the loan asset.  The salient features of the provisioning function in T24 are: l

Parameter table to capture the details regarding norms for asset classification, income recognition and applicable provision for each risk category etc.

l

Asset classification based on PD ageing, monitoring the contracts and updating the asset class at contract level and in customer record.

l

Calculation of required provision and generating necessary accounting entries for provisioning, at desired frequency.

l

Maintain data on written-off loans. This would mean generating necessary accounting entries at the time of write-off and maintaining the account balances for recovery. 

l

Facility to record recoveries against written off loans and generate necessary accounting entries.

l

Table to record reasons for write-off.

Set up for provisioning LN.ASSET.CLASS is the application where the customer defines the various internal classifications used. The ID of the record is numeric and the description of the numeric ID is given in the DESCRIPTION field.  For any asset class to be entered in the ASSET.CLASS.PARAMETERfile, it first has to be defined in the LN.ASSET.CLASS table. The other details that are provided in this table are the provision percentage, the provision expenses category in the P&L to be debited, the provision reserve category to be credited, whether income is to be recognized and whether write off is allowed for that particular class. These details are defaulted into ASSET.CLASS.PARAMETER table when this particular class is entered.

Screen shot of LN.ASSET.CLASS record for Substandard Assets

ASSET.CLASS.PARAMETER This is the file that describes the criteria for classification of loans into various asset classes. The main aspects dealt with in this file are:

Past Due Processing - User Guide - R16 AMR - Page 34 of 79

1. The categories of loans for which provisioning is required (at present only LD and MG categories are allowed). 2. The period of overdues that would render a loan eligible to be classified under a particular asset class. Though provisioning is generally done for loans that have past dues, some banks are required as per prudential norms to provide against standard assets too. This facility is also available in the provisioning module. 3. The PD.AMOUNT.TYPEthat would be considered in calculating the number of days overdue. Operands are provided to monitor these amount types either singly or in combination. 4. The provision percentage for each asset class. 5. The recognition or otherwise, of income from loans falling under each asset class. 6. The P&L category to be used for debiting the provision under each asset class. 7. The internal account for crediting the provision under each asset class. 8. The frequency of provisioning. A screenshot of the ASSET.CLASS.PARAMETER table is given below:

Past Due Processing - User Guide - R16 AMR - Page 35 of 79

Past Due Processing - User Guide - R16 AMR - Page 36 of 79

ASSET.CLASS.PARAMETER Table The categories of LD and MG that are to be considered for provisioning are mentioned in the ‘Application’ multivalue. It is possible to define individual categories and also ranges of categories in the CATEG.FR and CATEG.TO fields. In the example above, for LD, the category 21050 and the category range 21050 to 21056 are to be considered for provisioning. Whatever categories are defined for LD and MG applications need to be defined for PD also. Thereafter, the asset classes are to be defined along with the criteria that would make a contract eligible to be placed in that particular asset class. The criteria are to be mentioned in terms of number of days overdue of any amount type in the PD contract. Provisions may also be made on assets that do not have overdues. For example, for the asset class STANDARD, the fields AMT.TYPE and DECISION have been left blank. However, a provision of 5% has been stipulated in the PROV.PERC field. Therefore, assets that do not have any overdues will also be provided for @ 5%. It is possible to define complex combinations of these amount types with the DECISION and OPERAND fields. In the screenshot above, a PD contract with ‘PR’ and ‘IN’ component overdue for a minimum of 1 and a maximum period of 2 days will be classified as a substandard asset (asset class 2). For example, if a principal payment becomes overdue on January 1 st, the PD contract will not be classified as substandard until an interest payment also becomes overdue. Say an interest payment falls due on January 10 th , then the contract will be classified as sub-

Past Due Processing - User Guide - R16 AMR - Page 37 of 79

standard during close of business (COB) processing on January 10 th, when the condition of both principal and interest being overdue for at least a day, is met. The other important information that should be defined with every asset classification is: 1. PROV. PERC – the percentage of provision that is to be applied to the asset at every provision date. 2. PROV.RESV.CATEG – this will contain the internal category to be used for crediting the provision reserve. This category will have to be defined before the ASSET.CLASS.PARAMETER is set up. An internal account in local currency under the same category will also need to be opened. For contracts in foreign currencies, the system will open internal accounts in these currencies. 3. PROV.EXP.CATEG – this field will contain the P&L category that should be debited when a provision is made. 4. WRITE.OFF – if the asset needs to be written off completely from the books, this field should be set to ‘YES’. Only the worst asset class (last multivalue of classification) will allow the value ‘YES’. Once an asset reaches this class, the loan asset will be credited and the corresponding provision account will be debited. 5. INCOME.RECOG – setting this field to ‘NO’ would result in the contract being marked as a NAB (non-accrual basis) contract. Income will thereafter be accounted for only on a memo basis. Any income which had been previously recognized will now be reversed. Income henceforth will be recognized only on a cash basis. In the final category (WRITE-OFF), no provision percentage should be specified, as the WRITE.OFF field being set to YES means that the asset will have to be completely written off from the books. The following points have to be noted while setting up the ASSET.CLASS.PARAMETER table: For the product categories included in the parameter table, separate PD.PARAMETERrecordsmust exist. The SUSPEND.INCOME field in SYSTEM record of PD.PARAMETER should have as input, all the applications specified in ASSET.CLASS.PARAMETER (currently LD and MG). The REVERSE.PL.AT.NAB field for all the relevant PD.PARAMETER records should be set to ‘YES’. The fields NAB.PERIOD.INT and NAB.PERIOD.SPREAD will have to be set to ‘NO’, care must be taken when using a range of categories, all inclusive categories must follow this rule. Once the ASSET.CLASS.PARAMETER table is set up, the status of a contract will move to NAB if that particular contract falls into an asset class where INCOME.RECOG is set to ‘NO’. For all contracts that belong to categories mentioned in the ASSET.CLASS.PARAMETER, accrual/non-accrual income will be decided by ASSET.CLASS.PARAMETER and not by PD.PARAMETER. Once included, a category in ASSET.CLASS.PARAMETER cannot be deleted. When defining the various asset classes, the best asset class should be defined first and then progressively downwards till the write off class. Classification is done at individual contract level, and is calculated on the outstanding principal in the contract, both in the PD and the underlying contract. Based on the classification in the PD contract, the underlying contract will also be updated with the same asset class. In case of a customer with multiple loans, there may be a situation where each of these loans has a different classification. In this case, the CUSTOMER record for that particular customer will be updated with the worst classification amongst all the assets.

Past Due Processing - User Guide - R16 AMR - Page 38 of 79

Example of Provisioning Consider the following contracts input for David Brown Limited: CONTRACT

CCY

CATEGORY

VAL DT

MAT DT

AMOUNT

LD0726300001

USD

21053

1-Sep-07

5-Oct-07

1000000

LD0726300002

USD

21053

1-Sep-07

25-Sep-07

1000000

LD0726300003

EUR

21056

1-Sep-07

5-Oct-07

1000000

LD0726300004

USD

21053

1-Sep-07

5-Oct-07

1000000

LD0726300005

EUR

21056

1-Sep-07

5-Oct-07

1000000

MG0726300001

USD

25011

10-Sep-07

6-Dec-07

1000000

MG0726300002

EUR

25012

10-Sep-07

6-Dec-07

1000000

The schedules defined for the contracts are as follows (PI – principal and interest schedules simultaneously): LD0726300002 20-Sep-07 PI -100000

LD0726300003

PI -84,462.98 PI –100000

PI -100000

PI –100000

PI -100000

PI –800000

PI -100000

PI -84,486.38

PI -100000

27-Sep-07 28-Sep-07

MG0726300002

PI -100000

25-Sep-07 PI- 700000 26-Sep-07

MG0726300001

PI -100000

23-Sep-07 24-Sep-07 PI -100000

LD0726300005

PI -100000

21-Sep-07 22-Sep-07 PI -100000

LD0726300004

PI -100000

PI -84,462.98

PI -100000

PI -84,486.38

With the parameter settings as shown earlier, after a COB is run on September 20 th, the asset classification would look as under: 1.      PI schedules are overdue for LD0726300002, LD0726300003 and MG0726300001.These contracts will be classified as substandard as they have been overdue for a day and thus satisfy the condition for asset class 2. Therefore a 30% provision has been made on the outstanding principal in the underlying contract as well as in the PD component. Screen shots of these contracts are given below.

Past Due Processing - User Guide - R16 AMR - Page 39 of 79

PI Schedule Contracts The LD principal outstanding after the PI schedule of 100,000 on September 20 th is 900,000. A 30% provision (270,000) has been made on 900,000 under asset class 2.

PI Schedule Contracts The PD above has a provision of 30% on the PR component overdue of 100,000. The field PROVISION.METHOD is set to ‘AUTO’, which indicates that provisioning for this contract will be controlled automatically by the settings in ASSET.CLASS.PARAMETER. This field is user inputtable and can be set to MANUAL, which will enable the user to revise the asset classification upwards or downward manually. A fuller explanation follows in the section on MANUAL MAINTENANCE OF ASSET CLASS.

MG Contract September 20 th

The instalment of 84,462.98 that was paid on for MG0726300001 had a principal component of 81,685.2, leaving an outstanding principal of 918,314.8 in the MG contract. 30% provision on this works out to 275,494.44.

Past Due Processing - User Guide - R16 AMR - Page 40 of 79

PDMG Contract A 30% provision has been made on the PR component of the PDMG contract (81685.2), which works out to 24,505.56. 2.      The contracts LD0726300001, LD0726300004, LD0726300005 and LD0726300002 have no overdues as on September 20 th. Therefore they have been classified as standard assets. However, a 5% provision has been made for these contracts according to the stipulations in the ASSET.CLASS.PARAMETER.

Past Due Processing - User Guide - R16 AMR - Page 41 of 79

The screen shot below shows the list of internal accounts that have been credited for the various contracts during COB on September 20 th. Internal account USD –11060-0001 has been used for crediting provisions for standard assets (asset class 1) and USD-11061-00001 for substandard assets (asset class 2). These internal accounts have been specified in ASSET.CLASS.PARAMETER.

The corresponding debits have been shown in the CATEG entry statement (P&L account).

Past Due Processing - User Guide - R16 AMR - Page 42 of 79

PL.CATEGORY 51050 has been debited for provision on standard assets (Asset Class 1) and 51051 for substandard assets (Asset Class 2). These categories have been specified in the ASSET.CLASS.PARAMETER. The customer record has been updated with the worst asset class of all the contracts belonging to him. In this case, it is Substandard.

Customer Record Asset Class SUBSTANDARD The following screenshots show the position as on September 24 th (September 22 nd and 23 rd being holidays).  LD0726300002, LD0726300003 and MG LD726300001 have remained in substandard status for more than 2 days on September 22nd and therefore get classified as doubtful with effect September 22 nd.  LD0726300004, LD0726300005 and MG0726300002 had PI schedules which became overdue during COB on September 21 st. These would have been classified as doubtful with effect September 23rd. LD07266300001 being a bullet contract with no schedules and no overdues, continues to be a standard asset:

Past Due Processing - User Guide - R16 AMR - Page 43 of 79

Bullet contract All the other LD have moved to doubtful status:

LD Contract in Doubtful Status LD072630002 had another PI schedule of 100,000 move to PD on September 22nd, such that the outstanding amount in the LD is 800,000. As this contract is now in doubtful status, the provisioning has been done for 600,000(75% of 800,000), as per the settings in ASSET.CLASS.PARAMETER  The same is the case with LD072630003:

LD Contract in DOUNTFUL status LD072630004 and LD072630005 had a PI schedule of 100,000 each moving to PD on September 21 st and 23rd, bringing the outstanding principal under each of these contracts to 600,000.

Past Due Processing - User Guide - R16 AMR - Page 44 of 79

 LD Contracts in DOUBTFUL status As regards the MG contracts, though MG0726300001 still has only one principal overdue, it has crossed the 2day period for substandard assets and is classified as doubtful with effect September 22nd. So also, MG0726300002 has a PI schedule which becomes overdue on September 21 st. Therefore this contract also gets classified as doubtful with effect September 23rd.

MG Contract in Doubtful Status The provision for MG072630001 has been made @ 75% of the outstanding principal of 918,569.18(688,926.10).

Past Due Processing - User Guide - R16 AMR - Page 45 of 79

The PD component of the LD and MG contracts are shown below:

Provision = 75% of overdue principal of 200,000 = 150,000

Provision = 75% of overdue principal of 200,000 = 150,000

Past Due Processing - User Guide - R16 AMR - Page 46 of 79

Provision = 75% of outstanding principal of 200,000 = 150,000

Provision = 75% of outstanding principal of 200,000 = 150,000

Past Due Processing - User Guide - R16 AMR - Page 47 of 79

Provision = 75% of principal overdue of 81,685.2 = 61,263.90

Provision = 75% of principal overdue of  81,430.82 = 61,073.12 The statement entries crediting the provision reserve have been given below:

Past Due Processing - User Guide - R16 AMR - Page 48 of 79

In the case of each of the contracts above, when the asset class has changed from substandard to doubtful, the provision made in the substandard provision account (11060) has been debited and credited to the doubtful provision account (11061). Thereafter, the incremental provision required for the doubtful assets have been credited to 11061. The categ entries corresponding to the debit statement entries are given below:

The CUSTOMER record has also been updated with the doubtful asset class:

Past Due Processing - User Guide - R16 AMR - Page 49 of 79

After running the COB on September 24th, the asset classes of the individual contracts remain the same (September 25 th being the last day for remaining in DOUBTFUL class). However, in the case of LD0726300002 and LD0726300003, another PI schedule of 100,000 each has fallen due, decreasing the PR amount outstanding under LD and increasing the PR outstanding under PD. The screenshots look as under:

The provision under each of the above LDs has moved from 600,000 on September 24th to 525,000 on September 25 th. This represents 75% of the new outstanding amount of 700,000. The screenshots of the related PDs are shown under:

Past Due Processing - User Guide - R16 AMR - Page 50 of 79

To reflect the inter-se adjustment of provision between LD and PD, the following statement entries have been passed:

 The internal accounts USD-11062-0001 and EUR-11062-001 have been debited with an amount of 75,000 (previous provision of 600,000 under LD less the current provision of 525,000) with LD transaction reference and credited to the same internal accounts with PD transaction references.

So also, an adjustment is made in the categ entry between LD and PD.

Past Due Processing - User Guide - R16 AMR - Page 51 of 79

During the COB process on September 25 th, the LD contract LD0726300002 matures and the whole principal amount becomes past due. The PD record for this contract was created on September 20 th. Therefore it reaches the sixth day of past due on September 25 th and thus satisfies the condition for Write-Off according to the ASSET.CLASS.PARAMETER. The screenshot of the LD0726300002 contract shows the asset class as Write-off and the Provision Percentage as 100%. However, the provision amount is shown as zero. This is because the entire principal has become PD and the provisioning is made under the PD contract.

As the provisioning has to be first shifted from LD (which now has nil balance) to the PD, first of all the provisioning that has been made under LD (525,000) is first reversed out by debiting the internal account USD110620001 and crediting the P&L Category 51052.

Before a write off is done, full provisioning (if it has not been done already) has to be done in the doubtful asset category. For PDLD0726300002, an amount of 225,000 had been made provided for, previously. Now the remaining 775,000 (1,000,000 – 225,0000) will have to be provided for in the doubtful category. The statement entry for USD110620001 and the category entry for P&L category 51052 are shown below.

The write off is affected by debiting the provision account USD110620001 and crediting the loan account for 1,000,000. The statement entries are shown below.

Past Due Processing - User Guide - R16 AMR - Page 52 of 79

The RE.CONSOL.SPEC.ENTRY which shows the asset being credited is shown below:

Apart from LD0726300002, LD0726300003 and MG0726300001 also qualify for write-off according to the setting in ASSET.CLASS.PARAMETER. However these two contracts have not matured (i.e) a portion of outstanding amount is in the LD/MG contract and the rest in the PD module. Unless the underlying contract has a zero balance, automatic write-off will not be done by the system. Instead it will raise entries in a file PD.PROV.EXCEPTION.LOG. In such a case, the user will have to manually liquidate the underlying contract completely and the write off will be done by the system during the subsequent COB.The entries for LD0726300003 and MG0726300001 are shown below:

Entry LD072600003

Entry PDMG0726300001

Past Due Processing - User Guide - R16 AMR - Page 53 of 79

Repayment of written off contracts Manual repayment of contracts with FWOF status is done by choosing the ‘Repayment’ option in the field OPERATION in the PD contract. When the repayment amount is entered in TOT.REPAY.AMT, it is apportioned in the order mentioned in the FWOF.RPY.ORDER multivalue field given in the PD.PARAMETERrecord that appears in the PARAMETER.RECORD field in the PD contract. In the case of PDLD0726300002 the PD.PARAMETER record shows the order as follows:

PD Parameter Record An amount of 1,000,000 is repaid on the contract PDLD0726300002. This has been apportioned first towards the interest component (IN) of 6,416.66 and then principal component (PR) of 993,583.34. The screenshot of the repayment is shown below:

Past Due Processing - User Guide - R16 AMR - Page 54 of 79

Past Due Processing - User Guide - R16 AMR - Page 55 of 79

Past Due Processing - User Guide - R16 AMR - Page 56 of 79

Past Due Processing - User Guide - R16 AMR - Page 57 of 79

Past Due Processing - User Guide - R16 AMR - Page 58 of 79

Repayment

Past Due Processing - User Guide - R16 AMR - Page 59 of 79

Reasons for write off The user may want to record the reasons for writing off a loan when he does it manually. For this purpose, he can define reasons in a table called PD.WOF.REASONS. The reason can be mentioned in the PD record at the time of manually maintaining the asset class to write-off status.

Manual maintenance of asset class Apart from the change of asset classification that happens during COB, the user is given the option to change the asset classification online at contract level. The fields ASSET.CLASS, PROVISION and PROVISION.METHOD are inputtable fields, both at PD and LD/MG contract level. For contracts which have a past due component, the change will have to be done first in the PD contract, and then in the underlying LD/MG contract. For example, on September 21 st MG0726300001 was a substandard asset with a PD component. It may be decided to downgrade this asset manually to Doubtful status. In this case, if the manual downgrade is first attempted in the MG contract, the following error message will be displayed.

Downgrade error message The above error message shows that as the PDMG0726300001 still has an asset class of Substandard, the asset class in the MG cannot be changed to Doubtful. Therefore, the asset class has to be changed first in the PDMG contract. This is done by choosing ‘Maintenance’ in the field OPERATION. Thereafter, the field PROVISION.METHOD has to be set to ‘MANUAL’. Now the user can effect the desired change:

Set the Provision Method field to MANUAL In the above PD contract, the ASSET.CLASS has been changed to 3 (Doubtful). The PROVISION has also been changed to 90%. The PROVISION.AMOUNT has been changed online to 73,516.68 from 24,505.56 earlier. The WOF.REASON has been given as ‘3’ which in the PD.WOF.REASONStablehas been defined as ‘Industry in Negative List’ The statement entries and P& L entries are shown below. As the class of the asset has changed, the earlier entries that were passed for the previous class need to be reversed. The statement entries show that for PDMG0726300001 the previous credit to USD-11061-0001 (the internal account for substandard assets) has been debited with 24,505.56 and USD-11062-0001 (internal account for doubtful assets) has been credited with 24,505.56. Similarly, the P&L category for substandard assets (51051) has been credited with 24,505.56, and the P&L category for

Past Due Processing - User Guide - R16 AMR - Page 60 of 79

doubtful assets (51052) has been debited with 24,505.56. Thereafter, provision has been created for the incremental amount of 49011.12 (73516.68 – 24505.56) by debiting category 51052 and crediting internal account USD-11062-0001.

After the asset class has been changed, in the PD, the asset class can be changed to the same in the underlying MG contract. If it is not done online by the user, it will be done during COB by the system. In this particular case, the asset class in MG0726300001 has been changed to Doubtful and provision has been made at 90% of the underlying MG amount of 918314.8.#

Changes asset class in MG contract

Balances files LN.PROV.BALANCESis a table maintained by the system which contract-wise provisioning for every customer. The following screenshots show the table on September 21 st and September 24th for the customer David Brown Limited. LN.PROV.BALANCES as on September 21 st:

Past Due Processing - User Guide - R16 AMR - Page 61 of 79

LN.PROV.BALANCES as on September 24th

Past Due Processing - User Guide - R16 AMR - Page 62 of 79

LN.PROV.BALANCES.DETAILSis a table maintained by the system that shows the movement of an asset from one asset class to another. The screenshot below shows the status of LD0726300002 for which a provision of 270,000 was made on September 20 th, when the asset was classified as Substandard. On September 21 st, the asset became Doubtful as a result of which 75% of the outstanding principal balance of 800,000 had to be provided for. Hence, an extra amount of 330,000 has been provided, bringing the total to 600,000.

Past Due Processing - User Guide - R16 AMR - Page 63 of 79

LN.PROV.BALANCES DETAILS table

Past Due Processing - User Guide - R16 AMR - Page 64 of 79

Past Due Processing Accounting l

Income Recognition

l

Accounting for Provisioning

l

Accounting for financial Write-off

Past Due Processing - User Guide - R16 AMR - Page 65 of 79

Income Recognition For contracts with product category defined in ASSET.CLASS.PARAMETER, decision on whether income should be recognized or not would be governed by settings in ASSET.CLASS.PARAMETER.  For such contracts, once the asset class has been determined by the system, income recognition would be depend on the setting of the INCOME.RECOG field for that particular asset class. The allowed values in this field are YES (continue recognition of income) or NO (stop recognition of income). For such contracts when PD is created POST.END.DATE in PD.BALANCESwould be left NULL. When the contract reaches an asset class for which income should not be recognized (INCOME.RECOG = NO), system would update the record status to NAB. The parent LD or MG contract status would also be updated as NAB, which would trigger suspension of income (memo accruals) for both PD and parent LD or MG contract. Any accrual of income that had taken place thus far would also be reversed out.  Let us say that an LD contract with a PD has moved from accrual to non-accrual basis based on the setting in ASSET.CLASS.PARAMETER. The PD contract has OVERDUEIN (overdue interest) and OVERDUEPR (overdue principal) components. Assume that LD accrues income under the category 51001 and the PD accrues income (penal interest) under category 51000. The accounting entries that would take place on suspension of income would be as follows:

Reversal entries for income Dr P&L Category 51001 (amount of OVERDUEIN) CRPD…51001SP (consol key for reversal of interest accrued and overdue) DrP&L Category 51001 (amount of accrual under the LD for the current interest period to date) CrLD….51001SP (consol key for suspension of income under LD) DrP&L Category 51000 (penal interest accrued to date) CrPD….510000SP (consol key for suspension of income under PD) Memo entries to be passed for subsequent accruals after reaching NAB status DrLD….51001 (consol key for accrual of income under LD) CrLD….51001SP (consol key for suspension of income under LD) DrPD….51000 (consol key for accrual of penal interest under PD) CrPD….51000SP (consol key for suspension of  penal interest under PD)

Past Due Processing - User Guide - R16 AMR - Page 66 of 79

Accounting for Provisioning The provision amount required would be calculated by the system for each contract after the asset class is determined. Provisioning entries would be passed only for the incremental amount if the required provision is higher (and the asset continues to have the same asset class as of the previous review). If the required provision were lower than the amount already provided for, there would be a writeback of provision. The provision entries would be as under: First review date DrP/L Category for provision expense (indicated in ASSET.CLASS.PARAMETERfor the asset class). CrInternal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfor the asset class). For foreign currency loans system would automatically create internal accounts in the currency required. Subsequent Review Date If provision required is more than the amount so far provided, entries would be passed for an incremental amount i.e. difference between the provision now required and that provided so far Dr P/L Category for provision expense (indicated in ASSET.CLASS.PARAMETERfor the asset class). CrInternal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfor the asset class). For foreign currency loans system would automatically create internal accounts in the currency required. If provision required is less than the amount so far provided DrInternal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfor the asset class). Transaction code would be write-back. CrP/L Category for provision expense (indicated in ASSET.CLASS.PARAMETER for the asset class). Transaction code would be write-back. When an asset moves from one asset class to another, the entries passed for the previous asset class will be passed into the new asset class, and then incremental entries for the new asset class are passed.  Take for example, an asset that was Substandard with ‘X’ amount of provision having been made.  To this asset now moves to Doubtful asset class with amount ‘Y’ provision to be made, ‘Y’ being more than ‘X’. Then the following entries would be passed Internal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfor substandard asset class), for amount ‘X’. Dr CrInternal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfordoubtful asset class), for amount ‘X’. DrP/L category for provision expense (category indicated in ASSET.CLASS.PARAMETERfor doubtful asset class), for amount ‘X’. CrP/L category for provision expense(category indicated in ASSET.CLASS.PARAMETERfor substandard asset class), for amount ‘X’. DrP&L category for provision expense (category indicated in ASSET.CLASS.PARAMETERfordoubtful asset class), for amount ‘X-Y’. CrInternal account for provision reserve (category indicated in ASSET.CLASS.PARAMETERfor doubtful asset class), for amount ‘X-Y’.

Past Due Processing - User Guide - R16 AMR - Page 67 of 79

Accounting for financial Write-off In case a loan is financially written off for which 100% provision has been made, accounting would be as under: Dr Internal account for provision indicated in ASSET.CLASS.PARAMETER. The asset class would be the one prior to Write off class. CrLoan Asset Account In case a loan is written for which 100% provision has not been made, accounting would be as under: DrP/L Category for provision expense (indicated in ASSET.CLASS.PARAMETERforthe asset class prior to write off) The amount for which entry would be raised would be equal to the difference between the loan amounts outstanding and provision made so far. CrInternal account for provision indicated in ASSET.CLASS.PARAMETER. The asset class would be the one prior to Write off class. The amount for which entry would be raised would be equal to the extent of provision made so far DrInternal account for provision indicated in ASSET.CLASS.PARAMETER. The asset class would be the one prior to Write off class. The amount for which entry would be raised would be equal to entire loan outstanding. CrLoan Asset account for the entire loan outstanding If income were not being recognised prior to financial write off, then all memo accruals held in the system would also be reversed out.  If income were recognised prior to financial write off then accrual entries posted with respect to PE and PS would be reversed out. IN component that had moved to PD would be written off into WOF category indicated in PD.PARAMETER. Effectively, after financial write off there would be no evidence of transaction in the books of accounts except that information on outstanding balance would be held in the system for collection purpose. When amounts are recovered against a loan that is financially written off, the accounting would be as under: Dr Repayment Account as indicated in PD contract Cr P/L category indicated in ASSET.CLASS.PARAMETERforthe asset class prior to write off.

Past Due Processing - User Guide - R16 AMR - Page 68 of 79

Past Due Processing Enquiries and Reports Enquiries The enquiry CUSTOMER.PROVISION gives customer-wise provision details. The details are given grouped according to currency and show the outstanding principal under individual contracts, the asset class, percentage provision and the provision amount per contract. Given below is an example:

Reports Position Management To activate the Position Management (PM) interface for PD refer to the PM section of the User Guide. The definition of which PD data is used in Position Management enquiries takes place using the standard PM tables, namely PM.POSN.REFERENCEand PM.ENQ.PARAMas described in the Position Management section. The following tables for PD need to be in place:

PD.AMOUNT.TYPE The field PM.TYPE defines a generic position type for each amount type. Input is optional as not all accounting activities update PM, for example accruals that take place during Close of Business and will be absorbed into PM via the ACCOUNT balances. To update PM the POSN.TYPE field of the PD record of PM.PC.PARAMmust also be set up with the same value. The possibility exists to group different amount types by defining the same PM.TYPE or to split them. For example the different interest types could be grouped together.

Past Due Processing - User Guide - R16 AMR - Page 69 of 79

PM.POSN.TYPE Defines a series of generic 3 character position types. This table is currently only used for the PD module but is intended to be more widely used as new modules have interfaces to PM developed. An example of a position type would be PAM, Principal at maturity. The position class generated for PD would be PDPAM.

PM.PC.PARAM Defines which of the generic position types are applicable to a module. There will be one record per module (currently PD). If the type is not defined here then no update to PM will take place. Each position type defined can have an associated character that is used to identify any ACCOUNT related movements that are generated.

PM.PC.PARAMETER Record In this case the accounts related position class generated for PAMwould be PDxxM where xx depends on the set up of PM.AC.PARAM.

Reporting RE.STAT.REP.LINE It is possible to define consolidation parameters independently for past dues. For this purpose, CONSOLIDATE.COND will recognize PD.PAYMENT.DUE as a valid application. This will enable the user to pick up components from the PD template to form part of the consol key as in any other application. As and when these components undergo changes, the PD key would get re-generated with the new values. Lines may be set up to show movements from current to overdue status, where a grace period or overdue penalty charges may be accrued, and also to show movements to Non-Accruals. These lines can be further broken down into the constituent parts of a PD to show movements of Principal, Interest, Charges, Commission, Tax and Mortgage Additional Payments where appropriate. Example 1: Producing CRB entries showing full PD amounts To set up a line to show the total PD's, for example all movements in overdue status, a record in application RE.STAT.REP.LINE must be set up, where the ASSET.APPLIC.ID is set to PD and the ASSET.TYPE is set to OVERDUEDB.

Past Due Processing - User Guide - R16 AMR - Page 70 of 79

RE.STAT.REP.LINE With this set up the RE.STAT.LINE.BAL record should catch all the movements to PD. This produces a file on the RE.STAT.LINE.BAL record. Example 2: Producing CRB entries showing PD amounts broken down into constituent parts. To instruct T24 to divide PD amounts by constituent parts at CRB, field CRF.BY.TYPE should be flagged to ‘yes’. Once this has been done, an RE.STAT.REP.LINE recordmust be set up, with the ASSET.APPLIC.ID set to PD.  In field ASSET.TYPE, the field can be set up to OVERDUEXX where XX can be one of the following: PD Component Parts With these lines set up, and the flag in PD.PARAMETER, CRF.BY.TYPE set to Y; the component parts of PD should be separated out in separate lines.

Past Due Processing - User Guide - R16 AMR - Page 71 of 79

Past Due Processing Delivery Chaser advices may be produced at regular intervals: •         On any status change, as defined in PD.PARAMETER •          On a frequency defined in PD.PAYMENT due, operation SCHEDULE •          On a regular frequency based on RA type schedule. •          On a frequency with different advices (first reminder, second reminder, etc) with different charges for the advices. •          On different frequencies for different customer groups as defined in PD.PAYMENT.DUE record of APPL.GEN.CONDITION. •          Advices may also be suppressed depending on the total overdue amount being less than the parameter amount.

PD.ACTIVITY This file is used to control the output of delivery messages. A number of different activity types may be defined on PD.PARAMETER according to the new status of the payment. In addition there is another type of activity that is used when a chaser is scheduled. This type is 110 for Chaser advices. The file allows a simple description to be input for system enrichment purposes as well as a handoff routine to produce additional information.

PD.ADVICES This file controls the output of delivery messages for an activity defined on the PD.ACTIVITY file. The file Ids is constructed from the activity type and optionally the product code and the CATEGORYcode, e.g. 110, 110-MM or 110-MM-21050. A charge may be levied on a PD advice.  A PD advice can be linked to another defined PD advice and it also allows the user to define multiple message types, print formats and deal slips.

Past Due Processing - User Guide - R16 AMR - Page 72 of 79

Past Due Processing - User Guide - R16 AMR - Page 73 of 79

Past Due Processing Limits An important feature of the Past Due processing will be to ensure that the system reflects that there is still an overdue amount present. Where a LIMIT is defined as non-reducing, and repayment of principal is made, the LIMIT system would normally re-instate the available amount. In the cases where manual payment is requested, the LIMIT system must not increase the available amount until the payment is received. To process this situation correctly, the system is amended to allow the LIMIT system to bypass the available amount increase for non-reducing LIMIT records. The PD application will then update the available amount as and when payments are received. The overdue principal amount is recorded separately in the LIMIT system. By using the LIMIT.PARAMETERand LIMIT.REFERENCEapplications, a separate reference can be allocated for overdue items for ease of reporting the exposure to such items. Alternately, the original LIMIT.REFERENCE can be defaulted.

Limit Update Events l

Receipt of Principal – The outstanding amount is reduced by the amount received

l

Reduction of Principal – The outstanding amount is reduced by the reduction

l

Write off of contract - The outstanding amount is reduced to zero

By setting the field IMPACT.LIMIT in PD.PARAMETERto YES, the customer’s limit will be hit by all overdue amounts (besides principal) that flow from the parent application like overdue interest, charges, commission etc. However, amounts accruing on the PD contract like penal interest and spread will not affect limits. If this field is set to NULL, the customer’s limit would be updated only by the limit update events mentioned above.

Note on Reducing Limits It should be noted that the PD contract normally adopts the LIMIT used by the underlying application. However, there are certain situations where this is not desirable. For example if the underlying contract were a Loan that was linked to a reducing Limit, it would be incorrect to reinstate the Limit when the overdue amount is passed to PD. Under these circumstances an information LIMIT will be used. However, it is possible to change the LIMIT by using the MAINTENANCE option in PD.PAYMENT.DUE.

Note on Accounts For account PD, there would be no link to limits.

Past Due Processing - User Guide - R16 AMR - Page 74 of 79

Past Due Processing Services Close of Business Services The T24 Past Due module includes Close of Business procedures, which will process all the PD contracts, which are still overdue. If NS (Non Stop Processing) is installed for PD, input and processing of new contracts are allowed, provided they are not forward dated, i.e., any amendments or manipulation of old contracts as well as input of forward contracts are rejected. The Close of Business process includes: •          Processing of unauthorised contracts •          Processing of any schedules due •          Performance of penalty interest accruals •          Writing liquidated contracts to history •          Processing of any static changes •          Semi automatic payments processing

Past Due Processing - User Guide - R16 AMR - Page 75 of 79

PD.END.OF.DAY Batch Entry Screen

Automatic Pay-off of PD Capture Payment Automatic pay-off of PD on-line can now be handled. The THEIR.REFERENCE field in the statement entry triggers this. When there is a credit entry for an account and the THEIR.REFERENCE field has been populated with the account number or the contract number, then the account to which the credit is being made is checked against the repayment account.

Past Due Processing - User Guide - R16 AMR - Page 76 of 79

If yes, then the PD.ONLINE.PAYMENT file gets updated with the relevant details from the entry along with the account number to which the credit is going. This happens when the entry is unauthorised. During the authorisation of the credit transaction, if there are no on-balance sheet items in the PD, the PD gets repaid for the credit amount. If the PD contains any on-balance sheet item, during the input stage itself, the account to which the credit goes is changed to a suspense account which is defined in the PDREPAY record in ACCOUNT.CLASS file. Deletions and reversals of that particular entry that have the details updated in the PD.ONLINE.PAYMENT file are only updated. For those PDs that have got repaid on-line, would not be updated when the entry gets reversed. A PD.CAPTURE is the solution for bringing back the PD.

Processing Payments During the Close of Business, if there were PD.ONLINE.PAYMENT records, they would be read and processed. A single PD.ONLINE.PAYMENT file might contain multiple sets of payments to be processed. They are processed in order of their value dates and settled taken into account the REPAYMENT.ORDER set-up in the respective parameter record. After the settling the PD if any funds are available in the PD.ONLINE.PAYMENT file, the amount is paid back to the original account, which has been recorded in the online payment file.

Overdue Overdrafts Accounts that are overdrawn can also be linked to PD. This is controlled by the category ranges specified in the ‘AC’ parameter table and also by the number of days from when the account has gone overdrawn should be reported as Overdue. The PD created would be a contingent PD with the amount type as ‘CB’ meaning contingent Balance. All accounts that are attached to limit or not; when overdrawn, could be taken to PD. In a simple unauthorised overdraft, the PD gets created for the account that has been overdrawn with the ID as PDACXXXXX where XXXXX is the account number. The amount taken into PD is the overdrawn amount in this case. For the multiple accounts that are attached to limit, which exceed the limit either individually or together can also be linked to PD. In that case, PDs are created for those accounts in that group that has a debit balance. The amount that is taken into PD as CB amount is the debit balance and not the excess amount. When the account goes to a credit balance; or if their limit is increased and as a result of which the account is no more overdrawn, the PD also gets cleared. This is handled as a repayment of the overdue amount in PD. When the overdrawn amount increases due to some reason, then the PD associated would get updated with the relevant amount.

Past Due Tables PD.BALANCES The PD.BALANCESfile is used to record all the financial movement and balance details with the PD module and is the main calculation base for the penalty accruals. It is keyed by contract number and due date e.g. PDLD9603100059-19960331. This file is a type L (live) file and does not allow any user updates. The corresponding save file PD.BALANCES.SAVE and the history file PD.BALANCES.HIST are copies of the data held in the PD.BALANCES file in various stages. The save file stores the last authorised version of the balances record, whereas the history file is updated with the data held in the PD.BALANCES file when that particular record has been fully processed, as in all outstanding amounts repaid or if the whole record is written off.

Past Due Processing - User Guide - R16 AMR - Page 77 of 79

PD Contract Balances Screen. 

PD.RATES This file, PD.RATES is used to keep track of the penalty rate and spread changes that may take place over the lifetime of a PD contract. Each time a rate or spread change is made using the SCHEDULE operation on the PD.PAYMENT.DUEfile, then this file is updated with the new value. It is a type L (live) file and does not allow any user updates.  The key to the file is the PD.PAYMENT.DUE contract ID There is a corresponding save file PD.RATES.SAVE that stores the last authorised version of the PD.RATES file.

Past Due Processing - User Guide - R16 AMR - Page 78 of 79

 PD.RATES Record

PD.REPAYMENT The PD.REPAYMENTfile is used to store all the repayment details for a PD contract. It is needed due to the fact that all the repayment details are cleared from the PD.PAYMENT.DUE contract once it is processed. It is a type L (live) file and does not allow any user updates. The key to the file is the PD.PAYMENT.DUEcontract ID, repayment date and the sequence number within the repayment date in case there is more than one repayment on a given date. An example key would be PDMG/00311/00002-20001222-001.

Past Due Processing - User Guide - R16 AMR - Page 79 of 79