Past Due Processing

TEMENOS T24
Past Due Processing
User Guide
No part of this document may be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without the express written permission of TEMENOS Holdings NV.
Copyright 2005 TEMENOS Holdings NV. All rights reserved.

Past Due Processing
Table of Contents
Overview.................................................................................................................................................. 5
Setup ....................................................................................................................................................... 6
Setting processing rules - PD.PARAMETER ....................................................................................... 6
Application Design ............................................................................................................................... 7
Lifecycle rules................................................................................................................................... 7
Penalty interest details ................................................................................................................. 9
Waiving option for the Grace period penalty interest .............................................................. 10
Interest basis .............................................................................................................................. 14
Suspension of Income in Underlying Deal ................................................................................. 14
Any amount to hit limit ................................................................................................................ 15
Repayment order ........................................................................................................................ 15
Accounting Rules ........................................................................................................................ 18
AC Parameter Set-up ................................................................................................................. 18
Deal/Transaction Processing ................................................................................................................ 19
Processing a loan - PD.PAYMENT.DUE ........................................................................................... 19
Automatic processing ..................................................................................................................... 19
Operation - Schedule ..................................................................................................................... 20
Operation – Repay ......................................................................................................................... 21
Operation - Maintenance ................................................................................................................ 23
Operation – Adjustment.................................................................................................................. 24
PD.PAYMENT.DUE Rounding ....................................................................................................... 25
PD accrual options ......................................................................................................................... 25
ASSET CLASSIFICATION AND PROVISIONING ......................................................................... 26
PD.CAPTURE ................................................................................................................................ 26
Settlement based on instalment definitions ................................................................................... 29
Interest Capitalisation ........................................................................................................................ 34
Accounting ...................................................................................................................................... 35
Adjustment during migration .......................................................................................................... 35
Supporting PD Applications ............................................................................................................... 36
PD.AMOUNT.TYPE ....................................................................................................................... 36
PD.SCHEDULE.TYPE ................................................................................................................... 37
Rate Change (RC) ...................................................................................................................... 38
Spread Change (SC) .................................................................................................................. 38
Chaser Advice (CH) .................................................................................................................... 38
Links to other applications ................................................................................................................. 38
TEMENOS T24 User Guide

Page 2 of 92
Past Due Processing
Moving PD outstanding to another Branch .................................................................................... 38

Pre-requisites.............................................................................................................................. 39
Asset quality and provisioning ........................................................................................................... 40
Set up for provisioning.................................................................................................................... 41
ASSET.CLASS.PARAMETER .................................................................................................... 41
Repayment of written off contracts .................................................................................................... 65
Reasons for write off ...................................................................................................................... 71
Manual maintenance of asset class ............................................................................................... 72
Balances files.............................................................................................................................. 74
Income recognition ......................................................................................................................... 76
Reversal entries for income ........................................................................................................ 77
Accounting for Provisioning ............................................................................................................... 77
Accounting for financial Write-off ....................................................................................................... 79
Delivery.................................................................................................................................................. 80
PD.ACTIVITY ..................................................................................................................................... 80
PD.ADVICES ..................................................................................................................................... 80
Enquiries................................................................................................................................................ 81
Limits ..................................................................................................................................................... 82
Limit Update Events ........................................................................................................................... 82
Note on Reducing Limits .................................................................................................................... 83
Note on Accounts............................................................................................................................... 83
Reports .................................................................................................................................................. 83
Position Management ........................................................................................................................ 83
PD.AMOUNT.TYPE ....................................................................................................................... 83
PM.POSN.TYPE ............................................................................................................................ 84
PM.PC.PARAM .............................................................................................................................. 84
Reporting ........................................................................................................................................ 85
RE.STAT.REP.LINE ................................................................................................................... 85
Close of Business Services ................................................................................................................... 86
Automatic Pay-off of PD..................................................................................................................... 88
Capture Payment ........................................................................................................................... 88
Processing Payments..................................................................................................................... 88
Overdue Overdrafts ........................................................................................................................ 88
Past Due Tables ............................................................................................................................. 89
PD.BALANCES........................................................................................................................... 89
PD.RATES .................................................................................................................................. 90

Page 3 of 92
Past Due Processing
PD.REPAYMENT ....................................................................................................................... 91

Page 4 of 92
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.
SEMI-AUTOMATIC 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.

Page 5 of 92
Past Due Processing
Setup
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.

Page 6 of 92
Past Due Processing
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.
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

Page 7 of 92
Past Due Processing
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

Page 8 of 92
Past Due Processing
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.PARAMETER you can define:
• 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.SPREAD RATE 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.SPREAD to YES. In such cases, the field PENALTY.SPREAD cannot 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.RATE at the
contract level, it will take precedence over the rate in PENALTY.RATE at 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

Page 9 of 92
Past Due Processing
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
PD.AMOUNT.TYPE

Page 10 of 92
Past Due Processing
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.

Page 11 of 92
Past Due Processing
PD.PARAMETER file
The value from the parameter record gets defaulted to the underlying contract where the values can
be changed, if required.

Page 12 of 92
Past Due Processing

Page 13 of 92
Past Due Processing
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.

Page 14 of 92
Past Due Processing
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.

Page 15 of 92
Past Due Processing
RETRY.REPAY.STATUS on PD.PARAMETER is used to define the PD status up to which

repayments will be attempted.
PD.PARAMETER FILE

Page 16 of 92
Past Due Processing
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.

Page 17 of 92
Past Due Processing
Accounting Rules
The other fields on PD.PARAMETER allow you to specify the CATEGORY and TRANSACTION
codes used for reporting PD amounts.
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.

Page 18 of 92
Past Due Processing
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.
Deal/Transaction Processing
Processing a loan - PD.PAYMENT.DUE
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.
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.

Page 19 of 92
Past Due Processing
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.

Page 20 of 92
Past Due Processing
PD.PAYMENT.DUE Record
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.

Page 21 of 92
Past Due Processing
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.

Page 22 of 92
Past Due Processing
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:

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

Page 23 of 92
Past Due Processing
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.PAYMENT.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.
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.

Page 24 of 92
Past Due Processing
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.PAYMENT.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.

Page 25 of 92
Past Due Processing
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 PROVISION is meant to
input the percentage provision made on the contract. The values held in these two fields are meant for
information purposes only.
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.

Page 26 of 92
Past Due Processing
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”.
PD.CAPTURE.EXIST Record

Page 27 of 92
Past Due Processing
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.

Page 28 of 92
Past Due Processing
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.
PD.PARAMETER file
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.

Page 29 of 92
Past Due Processing
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.

Page 30 of 92
Past Due Processing

Page 31 of 92
Past Due Processing
Screenshots of the first two PD.BALANCES records are as shown.
PD.BALANCES records
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.

Page 32 of 92
Past Due Processing
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.

Page 33 of 92
Past Due Processing
PD.BALANCES records
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.

Page 34 of 92
Past Due Processing
• 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.FREQ and PS.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.
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:

Page 35 of 92
Past Due Processing
• 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:

Page 36 of 92
Past Due Processing
PD Amount Types
Both CP and CB are off-Balance sheet items.
PD.AMOUNT.TYPE Input Record
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:

Page 37 of 92
Past Due Processing
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.
Chaser Advice (CH)
PD.SCHEDULE.TYPE Input
Used to define the schedule for Chaser advice production.
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.

Page 38 of 92
Past Due Processing
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 this should have the routine

PD.COMPANY.CHG.VAL in field CONT.MOVE.CHK.RTN as shown below:
Routine for PD contract movement
The application EB.COMPANY.CHANGE is used to affect the transfer, which is limited to PDPD
type contracts.

Page 39 of 92
Past Due Processing
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.
Moving PD contract to another branch
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:

Page 40 of 92
Past Due Processing
• Parameter table to capture the details regarding norms for asset classification, income recognition
and applicable provision for each risk category etc.
• Asset classification based on PD ageing, monitoring the contracts and updating the asset class at
contract level and in customer record.
• Calculation of required provision and generating necessary accounting entries for provisioning, at
desired frequency.
• 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.
• Facility to record recoveries against written off loans and generate necessary accounting entries.
• 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.PARAMETER file, 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:
1. The categories of loans for which provisioning is required (at present only LD and MG
categories are allowed).

Page 41 of 92
Past Due Processing
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.TYPE that 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:

Page 42 of 92
Past Due Processing

Page 43 of 92
Past Due Processing
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.

Page 44 of 92
Past Due Processing
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 1st, the PD contract will not be classified
as substandard until an interest payment also becomes overdue. Say an interest payment falls due on
January 10th, then the contract will be classified as substandard during close of business (COB)
processing on January 10th, 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.PARAMETER records must
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).

Page 45 of 92
Past Due Processing
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.
1. 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.
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

Page 46 of 92
Past Due Processing
The schedules defined for the contracts are as follows (PI – principal and interest schedules
simultaneously):
LD0726300002 LD0726300003 LD0726300004 LD0726300005 MG0726300001 MG0726300002

20-Sep-07 PI -100000 PI -100000 PI -84,462.98
21-Sep-07 PI –100000 PI -100000 PI -84,486.38
22-Sep-07 PI -100000 PI -100000
23-Sep-07 PI –100000 PI -100000
24-Sep-07 PI -100000 PI -100000
25-Sep-07 PI- 700000 PI –800000 PI -100000
26-Sep-07 PI -100000
27-Sep-07 PI -100000 PI -84,462.98
28-Sep-07 PI -100000 PI -84,486.38
With the parameter settings as shown earlier, after a COB is run on September 20th, 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.
PI Schedule Contracts
The LD principal outstanding after the PI schedule of 100,000 on September 20th is 900,000. A
30% provision (270,000) has been made on 900,000 under asset class 2.

Page 47 of 92
Past Due Processing
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
The instalment of 84,462.98 that was paid on September 20th 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.

Page 48 of 92
Past Due Processing
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 20th. 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.

Page 49 of 92
Past Due Processing
LD/MG Contracts
The screen shot below shows the list of internal accounts that have been credited for the various
contracts during COB on September 20th. 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.

Page 50 of 92
Past Due Processing
The corresponding debits have been shown in the CATEG entry statement (P&L account).
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.

Page 51 of 92
Past Due Processing
Customer Record, Asset Class SUBSTANDARD
The following screenshots show the position as on September 24th (September 22nd and 23rd 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 22nd. LD0726300004, LD0726300005 and MG0726300002 had PI schedules which
became overdue during COB on September 21st. 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:

Page 52 of 92
Past Due Processing
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 DOUBTFUL status

Page 53 of 92
Past Due Processing
LD072630004 and LD072630005 had a PI schedule of 100,000 each moving to PD on September 21st
and 23rd, bringing the outstanding principal under each of these contracts to 600,000.
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 21st.
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,314.8(688,736.10)

Page 54 of 92
Past Due Processing
MG Contract in DOUBTFUL status
The provision for MG072630001 has been made @ 75% of the outstanding principal of
918,569.18(688,926.10).
The PD component of the LD and MG contracts are shown below:
PD component of LD and MG contracts
Provision = 75% of overdue principal of 200,000 = 150,000

Page 55 of 92
Past Due Processing
Provision = 75% of overdue principal of 200,000 = 150,000
Provision = 75% of outstanding principal of 200,000 = 150,000

Page 56 of 92
Past Due Processing
Provision = 75% of outstanding principal of 200,000 = 150,000
Provision = 75% of principal overdue of 81,685.2 = 61,263.9

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

Page 58 of 92
Past Due Processing
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:

Page 59 of 92
Past Due Processing
Customer record updated with DOUBTFUL asset class
After running the COB on September 24th, the asset classes of the individual contracts remain the
same (September 25th 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:

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

Page 61 of 92
Past Due Processing
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.
During the COB process on September 25th, the LD contract LD0726300002 matures and the whole
principal amount becomes past due. The PD record for this contract was created on September 20th.
Therefore it reaches the sixth day of past due on September 25th 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.

Page 62 of 92
Past Due Processing
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.

Page 63 of 92
Past Due Processing
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.
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 LD0726300003

Page 64 of 92
Past Due Processing
Entry PDMG0726300001
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.PARAMETER record 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

Page 65 of 92
Past Due Processing
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:

Page 66 of 92
Past Due Processing

Page 67 of 92
Past Due Processing

Page 68 of 92
Past Due Processing

Page 69 of 92
Past Due Processing

Page 70 of 92
Past Due Processing
Repayment
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.
Write off status

Page 71 of 92
Past Due Processing
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 21st 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.REASONS table
has been defined as ‘Industry in Negative List’

Page 72 of 92
Past Due Processing
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 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.#
Change asset class in MG contract

Page 73 of 92
Past Due Processing
Balances files
LN.PROV.BALANCES is a table maintained by the system which contract-wise provisioning for

every customer. The following screenshots show the table on September 21st and September 24th for
the customer David Brown Limited.
LN.PROV.BALANCES as on September 21st:
LN.PROV.BALANCES as on September 24th:

Page 74 of 92
Past Due Processing
LN.PROV.BALANCES.DETAILS is 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 20th, when the asset was classified as
Substandard. On September 21st, 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.

Page 75 of 92
Past Due Processing
LN.PROV.BALANCES DETAILS table
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.BALANCES would 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:

Page 76 of 92
Past Due Processing
Reversal entries for income
Dr P&L Category 51001 (amount of OVERDUEIN)

CR PD…51001SP (consol key for reversal of interest accrued and overdue)
Dr P&L Category 51001 (amount of accrual under the LD for the current interest
period to date)
Cr LD….51001SP (consol key for suspension of income under LD)
Dr P&L Category 51000 (penal interest accrued to date)

Cr PD….510000SP (consol key for suspension of income under PD)
Memo entries to be passed for subsequent accruals after reaching NAB status
Dr LD….51001 (consol key for accrual of income under LD)

Cr LD….51001SP (consol key for suspension of income under LD)
Dr PD….51000 (consol key for accrual of penal interest under PD)

Cr PD….51000SP (consol key for suspension of penal interest under PD)
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 write-back of
provision.
The provision entries would be as under:
First review date
Dr P/L Category for

provision expense (indicated in
ASSET.CLASS.PARAMETER for the asset class).
Cr Internal account for provision reserve (category indicated in
ASSET.CLASS.PARAMETER for the asset class). For foreign
currency loans system would automatically create internal accounts
in the currency required.

Page 77 of 92
Past Due Processing
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.PARAMETER for the asset class).
ASSET.CLASS.PARAMETER for 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

Dr Internal account for provision reserve (category indicated in
ASSET.CLASS.PARAMETER for the asset class). Transaction
code would be write-back.
Cr P/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

Dr ASSET.CLASS.PARAMETER for substandard asset class), for
amount ‘X’.
ASSET.CLASS.PARAMETER for doubtful asset class), for
amount ‘X’.
Dr P/L category for provision expense (category indicated in

amount ‘X’.
Cr P/L category for provision expense(category indicated in
ASSET.CLASS.PARAMETER for substandard asset class), for
amount ‘X’.
Dr P&L category for provision expense (category indicated in

amount ‘X-Y’.

Page 78 of 92
Past Due Processing
amount ‘X-Y’.
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.
Cr Loan Asset Account
In case a loan is written for which 100% provision has not been made, accounting would be as under:
Dr P/L Category for provision expense (indicated in
ASSET.CLASS.PARAMETER for the 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.
Cr Internal account for provision indicated in
prior to Write off class. The amount for which entry would be raised
would be equal to the extent of provision made so far
Dr Internal account for provision indicated in
prior to Write off class. The amount for which entry would be raised
would be equal to entire loan outstanding.
Cr Loan 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.PARAMETER for the
asset class prior to write off.

Page 79 of 92
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.ACTIVITY Code Input
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 CATEGORY
code, e.g. 110, 110-MM or 110-MM-21050.

Page 80 of 92
Past Due Processing
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.
PD.ADVICES Record
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:

Page 81 of 92
Past Due Processing
Enquiry CUSTOMER.PROVISION
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.PARAMETER and LIMIT.REFERENCE applications, 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

• Receipt of Principal – The outstanding amount is reduced by the amount received
• Reduction of Principal – The outstanding amount is reduced by the reduction
• Write off of contract - The outstanding amount is reduced to zero

Page 82 of 92
Past Due Processing
By setting the field IMPACT.LIMIT in PD.PARAMETER to 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 re-instate 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.
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.REFERENCE and PM.ENQ.PARAM as 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.

Page 83 of 92
Past Due Processing
To update PM the POSN.TYPE field of the PD record of PM.PC.PARAM must 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.
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

Page 84 of 92
Past Due Processing
In this case the accounts related position class generated for PAM would 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.
RE.STAT.REP.LINE Record

Page 85 of 92
Past Due Processing
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 record must 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.
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

Page 86 of 92
Past Due Processing
• Processing of any static changes

• Semi automatic payments processing
PD.END.OF.DAY Batch Entry Screen

Page 87 of 92
Past Due Processing
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.
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.

Page 88 of 92
Past Due Processing
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.BALANCES file 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.

Page 89 of 92
Past Due Processing
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.DUE file, 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.

Page 90 of 92
Past Due Processing
PD.RATES Record
PD.REPAYMENT
The PD.REPAYMENT file 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.DUE contract 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.

Page 91 of 92
Past Due Processing
PD Repayment Record

Page 92 of 92

Past Due Processing

Uploaded by

Copyright:

Available Formats

You might also like

Past Due Processing

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Past Due Processing

Uploaded by

Copyright:

Available Formats

TEMENOS T24

Past Due Processing

Copyright 2005 TEMENOS Holdings NV. All rights reserved.

TEMENOS T24 User Guide

Moving PD outstanding to another Branch .................................................................................... 38

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Liquidation Mode Values

TEMENOS T24 User Guide

Where AC is linked to PD then the PD.PARAMETER record AC must also exist.

TEMENOS T24 User Guide

PD Payment Life Cycle

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Penalty interest details

The amount used to calculate penalty spread for CONTRACT.METHOD 2 is configurable.

CONTRACT.METHOD 4 accrues penalty interest and penalty spread together.

The amount used is defined via PEN.CALC.BASIS on PD.PARAMETER,. PD.BALANCES records

TEMENOS T24 User Guide

Waiving option for the Grace period penalty interest

TEMENOS T24 User Guide

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

The two fields WAIVE.GRA.PE & WAIVE.GRA.PS in PD.PARAMETER and PD.PAYMENT.DUE

TEMENOS T24 User Guide

TEMENOS T24 User Guide

TEMENOS T24 User Guide

Suspension of Income in Underlying Deal

TEMENOS T24 User Guide

Any amount to hit limit

REPAYMENT.METHOD on PD.PARAMETER defines the type of repayment processing; three

1. Repayment order by type as defined in REPAYMENT.ORDER, the current default

TEMENOS T24 User Guide

RETRY.REPAY.STATUS on PD.PARAMETER is used to define the PD status up to which

TEMENOS T24 User Guide

PD.PARAMETER File (CONT)

TEMENOS T24 User Guide

PD.PARAMETER File specifying Category and Transaction Codes

For the account to be linked to PD, the fields AC.CP.CATEG.FR, AC.CP.CATEG.TO,

TEMENOS T24 User Guide

• Whether interest should be calculated, accrued and posted.

TEMENOS T24 User Guide

• Penalty rate or spread changes to be input for a future date.

TEMENOS T24 User Guide

TEMENOS T24 User Guide

PD.PARAMETER contains a hierarchy of types of outstanding payments. Separate records can be

• Outstanding Penalty Interest

TEMENOS T24 User Guide

1. To change the way the exposure of the overdue is reported, by changing:

TEMENOS T24 User Guide

TEMENOS T24 User Guide

If adjustment is done to any other PD.AMOUNT.TYPE, input of ‘Liquidation Account’ is mandatory.

PD.PAYMENT.DUE Adjustment Screen

TEMENOS T24 User Guide

ASSET CLASSIFICATION AND PROVISIONING

PD.CAPTURE is an application that allows loans already in arrears to be monitored by PDs.

• For take-over of loans already in arrears in new implementations of Past Due.

If the PD.PAYMENT.DUE contracts to be raised/updated has an underlying loan contract on the

TEMENOS T24 User Guide

TEMENOS T24 User Guide