T3TPD - Past Dues - R12.

1 1
 The Past Dues (PD) module enables Banks to monitor over dues in contracts in
general and Accounts if specified. This course covers the dependencies,
parameters and features of the Past Due module. In T24, contracts cannot hold
over dues. Depending upon the Liquidation mode of a contract, PD will take
up the monitoring of over dues.
These dues can arise in respect of Principal, Interest, Charges, etc. But once
the over due balance is transferred to PD, Penal Interests and charges also start
adding on to the due amount. These over dues can arise in applications like
LD, MM and MG. In case of Accounts, while the over due balance remains in
the respective accounts, the overdrawn portion can additionally be recorded in
PD. PD also ages over dues into Pre-grace, Grace, etc.
Limited asset classification and provisioning functionalities are available
inside the PD module. Full fledged Provisioning functionality is handled
separately outside the PD module, to know more about provisioning, please go
through the e-learning course on Provisioning.

T3TPD - Past Dues - R12.1 2

 In T24, contract applications cannot hold overdues. When payment is due to
the Bank, depending on liquidation mode of a contract, the dues are either
debited to liquidation account when liquidation mode is set as Automatic, or
dues are taken to PD.PAYMENT.DUE application if the liquidation mode is
set as Manual. If the liquidation mode is set as Semi automatic, then the
liquidation account is debited to the extent of funds available there and the
balance overdues alone are transferred to PD.
These dues could arise while handling loans in LD, MM and MG applications
in the form of Principal, interest, commission, charges, payment protection
additional payment etc. Dues of other contract applications like Swaps,
Drawings in LC and Charges and commission of MD application are also
subjected to the same treatment. AZ loans could be optionally linked to PD.
In the case of Accounts, it is possible to record the overdrawn portion in PD
also. While the balance continues to remain in respective Account, suitable
records can be additionally created in PD module for over drawn accounts for
reporting purpose.
For all contracts, PD takes over maintaining of overdues. Penal interest rules
are set in PD for this purpose. As for Accounts, penal interest continues to be
calculated only in the respective Account set up and not at PD level.
When liquidation mode is set as Manual, repayments are to be handled only
manually in PD and T24 will not do any automatic retry of settlement account.

T3TPD - Past Dues - R12.1 3

 When dues are paid on scheduled date, status of assistance is current. If not
paid on due date, they become over due. Over dues can be managed by PD
module. PD handles aging of debts as set up in PD.PARAMETER file by
updating the over due status as and when the overdues cross the specified
number of days or when a particular number of instalments are overdue.
The first stage is Pre-grace when penalty is not even accrued. During this
period, the borrower can pay without incurring any penalty. It is possible to
skip this stage altogether if a Bank so desires and sets up PD.PARAMETER
accordingly.
In Grace status, penalties are calculated but will not be normally charged to
borrower if paid within the grace period. Once overdues cross this status and
still remain unpaid, penalties accrued during this period are also added to
overdues. Alternately, it is possible to set in PD.PARAMETER that Grace
stage penalties should not be waived. Grace stage can also be skipped if a
Bank desires so that overdues go to the next stage directly.
In Past Due Obligation stage, penalties are accrued and charged regularly.
In Non Accrual Basis stage, a Bank starts losing hope of normal recovery and
stops charging penalty though they are calculated. It is also possible to write
back what has already been charged.
If a Bank has been making provision for bad debts, it can do Financial write
off of principal using the provision. In the absence of provisioning, the
overdues can be written off by debiting current year‟s Profit and Loss head.

T3TPD - Past Dues - R12.1 4

 Asset classification and provisioning is possible for loans in LD and MG
modules, in a limited method, through PD module.
Provisioning could be done either manually or automatically.
The salient features of the provisioning function in T24 are:
1) Parameter table to capture details regarding norms for asset classification,
income recognition and applicable provision for each risk category. Any
number of classification of assets is possible.
2) Asset classification based on PD ageing, monitoring the contracts and
updating the asset class at contract level and in customer record.
3) Calculation of required provision and generating necessary accounting
entries for provisioning, at desired frequency.
4) Maintain data on written-off loans, generating necessary accounting entries
for write-off and maintaining the account balances for recovery.
5) Facility to record recoveries against written off loans and generate
necessary accounting entries.
6) Table to record reasons for write-off.
However, the Provisioning module is a better option to define provisioning for
loans. Please refer to the e-learning course on provisioning.

T3TPD - Past Dues - R12.1 5

 We need to have Customer records to refer the counterparty. We need
accounts for liquidation. Contract details have been passed over to the
Delivery system for onward communication to the counterparty. Accounting
entries are generated for interest, charges, repayments, etc.
It is possible to use the loan limit for PD also or separate limits for PD could
be created. If the loans were given without setting up limits, it is possible to
continue the same set-up also.
In case of revolving limits, separate limit products for PD could be set up in
LIMIT.PARAMETER. While the system will default the loan limit product
initially, it is possible to change to a suitable PD limit product later.
In case of non revolving limits, the system will default the Information limit
set up in LIMIT.PARAMETER which would continue.
Other Static Tables used in PD module include CURRENCY, COUNTRY,
HOLIDAY, and Interest and charge related tables.

T3TPD - Past Dues - R12.1 6

 When the system automatically moves the overdues to PD, then it defaults the
underlying product codes into the PD contracts.
When any contract is manually moved to PD through PD.CAPTURE, then
also the underlying Category codes are defaulted.
When an account balance is manually captured through PD.CAPTURE, then
the system will need a Category code to be input. It is advisable to use the
underlying category code, unless there is a need to use a different Category
code like using the PD rules of a Contract for an account.
It is possible to set different rules for accounts, and different contract
categories through PD.PARAMETER, apart from one set for system to be
used as default.

T3TPD - Past Dues - R12.1 7

 BASIC.RATE.TEXT table, and subsequently the BASIC.INTEREST table are
used to indicate the interest rate to be applied for the calculation of penalty
interest for floating rate type PD contracts.
Floating interest rates defined in BASIC.INTEREST defaulted from contracts.
Should be indicated if desired while capturing through PD.CAPTURE.

T3TPD - Past Dues - R12.1 8

 Charges and commissions are defined in FT.COMMISSION.TYPE. These are
directly applied to PD contracts and could be applied on a contract whenever a
repayment happens.
Either they could be defined in a PD contract during any repayment or could
be defaulted through PD.PARAMETER. They can also be defaulted when
sending any delivery message like chaser advices.

T3TPD - Past Dues - R12.1 9

 The Original Settlement accounts are automatically defaulted from the
underlying contract when the PD contract is created and subsequently updated.
It is a multi value field which will record different settlement accounts if the
underlying account uses different accounts for settling different kinds of
payments, example, for principal and interest.
Repayment account identifies the account to be debited with repayment
amount. Repayment account can be different from the original settlement
account. If no input is made to this field then the system will try to default an
account. If no default account is found by the system then the account in the
first multi value of ORIG.STLMNT.ACT Field will be defaulted. An override
will be given if the account is a NOSTRO.

T3TPD - Past Dues - R12.1 10

T3TPD - Past Dues - R12.1 11
 PD.ACTIVITY table is used to describe the various activities in PD. Used for
enrichment purposes throughout the Payment Due system.
In PD.ADVICES, we can specify, activity wise, application wise, product
wise, the type of advice or none to be produced.
PM.POSN.TYPE is where transaction codes and positions type pre defined.
Position type input is optional, only for activities which update PM.
PD.AMOUNT.TYPE identifies the type of amount allowed in the PD module.
There are fixed number of basic allowable types, can be further subdivided by
the users. Base types are Principal, Interest, Commission, Charges, Tax, and
additional types are Penalty Interest, Penalty Spread, etc.
How PDs deal with the overdue payment is determined by settings on
PD.PARAMETER. Different PD.PARAMETER records with different set of
rules can be created for each loan category.
If provisioning is desired through the PD module, the following tables are
used:
LN.ASSET.CLASS is used to define internal classifications of Assets based on
their quality. Example, Standard, Sub-Standard, Doubtful, Loss etc.
ASSET.CLASS.PARAMETER is used to set down conditions to classify assets
to fit into the already defined asset classes and to follow processing rules.
PD.WOF.REASON table may be used to capture various reasons for Writing
Off a contract and may use these in the PD.PAYMENT.DUE record during the
actual Write-off.
T3TPD - Past Dues - R12.1 12
 PD.ACTIVITY has a three digit user defined code which can be used to trigger
production of a specific advice in connection with a status change in a PD
record; example when it moves from Pre-grace to grace, the relevant advice is
recorded on the originating record. The id 110 is reserved for the automatic
generation of chasers advices. PD.ACTIVITY is linked to PD.PARAMETER.
In PD.ADVICES, we can specify, activity wise and application wise and if
further needed product wise, which type of advice as defined in
DE.MESSAGE, should be produced. It is possible to attach a charge also
whenever the message is produced. It is also possible to attach charges and
commissions for the messages produced.

T3TPD - Past Dues - R12.1 13

 Identifies the type of amount allowed in the Payment Due module. There are a
fixed number of basic allowable types but these may be further subdivided by
the users to allow greater control if so desired. The base types allowed are PR
for Principal; IN for Interest; CH for Charge; CO for Commission and TX for
Tax; A1to A5 are additional types as defined in the Mortgages application; PE
for Penalty interest; PS for Penalty Spread; CB for Contingent balance
(Account); CE for Capitalised penalty interest; CP for Contingent principal
(revolving credit); CS for Capitalised penalty spread; OP for Outstanding
principal.
It is possible to define extra types of up to six characters but the first two
characters have to be one of the above base types, so valid types would be
"PRSPEC" or "TXLOC". It is also possible to define types by category, the
format of which is the amount type followed by a '-' and then the category
code, example "PR-21050" or "INEXT-25000".
These amount types are used through PD.PARAMETER.
Input of PM.POSN.TYPE is optional as not all accounting activities update
PM example, accruals which take place during end of day and will be
absorbed into the account balances. To update PM the POSN.TYPE Field of
the PD record of PM.PC.PARAM must also be set up with the same value.

T3TPD - Past Dues - R12.1 14

 PD.PARAMETER settings determine the conditions for handling past due
records in PD. You can have a different PD.PARAMETER record for each
loan category, so PD processing can be different for different loan products.
Where no record is defined for the category of the loan being processed, the
Past Due module defaults to rules set in record with Company Id.
A PD.PARAMETER record with Id of Company code has to be set up first
before setting records with any other Category code. A record with Id of AC
must exist on this table if any account has to be linked to PD to control the
parameter settings for overdrawn accounts.
It is not possible to reverse the record with Company code Id, but possible to
reverse other records as long as there are no PD contracts active with that
particular Category code.
To reflect the unauthorised overdrafts in an Account, a record with Id of AC is
mandatory.
In order to write charges and commissions on the MD.DEAL that have not
been paid to PAYMENT.DUE, a record for MD is mandatory. Separate
parameter definitions may be input for each category of MD, in which case the
@Id will be input as MD-Category code.

T3TPD - Past Dues - R12.1 15

 Once a payment becomes due, the contract application stops calculating
contractual interest and hands the payment over to PD. PD charges penalty
interest, which will usually be higher than the rate on the contract.
First part of PD.PARAMETER relates to defining PL Category codes for
interest and penalty interest for current month, previous month, previous years,
and Loans write off related PL Codes for debit entries and credit entries such
as Loans Write off, past due write off debit and credit, past due adjustment
debit and credit and past due net payment.

T3TPD - Past Dues - R12.1 16

 When the status of a PD record changes to NAB, T24 stops accruing penalty
interest and spread. Bank may like to reverse the already accrued but not paid
penalties from P & L or may like to retain them. REVERSE.PL.AT.NAB Field
is used for this.
It is possible to report individual components of the Past Due record like
Principal, Interest, Charges, Commission etc. in different lines in General
ledger by setting CRF.BY.TYPE Field as Y. If this filed is left blank or flagged
No then all components of the past due record will be stored in one line as
single overdue component.
It is possible to set different accrual cycles for local and foreign currency
overdues by using ACCR.CYCLE.LOCAL and ACCR.CYCLE.FOREIGN
Fields. Accruals could be set as either daily or monthly frequencies.
PE.CAP.FREQUENCY and PS.CAP.FREQUENCY Fields can be used to
define capitalisation cycles for Penalty Interest (PE) and Penalty Spread (PS).
The amount accrued in PE and PS would then get posted to Capitalised
Interest (PD.AMOUNT.TYPE = CE) and Capitalised Spread
(PD.AMOUNT.TYPE = CS) on the dates and frequencies mentioned. If
PE.CALC.BASIS is set to include CE and CS, then penalties can be calculated
on the capitalised penal interest and spread also.
Capitalisation would be for amounts that have been accrued till yesterday and
today‟s accruals would get posted to PE and PS.

T3TPD - Past Dues - R12.1 17

 PRE.GRACE.PERIOD Field specifies the number of calendar days (999 days
maximum) for which the pre-grace period, called PRE, lasts. During this
period, penalties are neither calculated nor posted. Once this period is over and
the customer has not made any repayment, penalty interest will be calculated
on the overdue amount, from the end of this period. If set the subsequent grace
period will calculate, but not post, accruals for information purposes. The next
status if no payment is made, or written off, is past due called PDO. A contract
may go directly from PRE to PDO according to settings in the
PD.PARAMETER record for the contract type.
Where number of installments could be indicated, it is done with a prefix of P,
like P3. Maximum 99 installments could be indicated.

T3TPD - Past Dues - R12.1 18

 NAB.PERIOD.INT Field specifies the number of days after a payment becomes
overdue, the PD contract will switch to non-accrual basis and stop accruing and
posting penalty interest. Once the contract has switched status to NAB, the
system will stop accruing and posting the penalty interest due, but calculation
of the penalty interest will continue.
If this field were set to NO, change of status from PDO to NAB would not be
governed by the system but is only manually controlled. The PD record would
go through stages PRE, GRA, PDO as per parameter definition. Once the status
becomes PDO, there would be no system updation, and change of status to
NAB is only by way of user intervention in the form of a Maintenance
operation. The value in this field, if numeric, would express the number of days
after which the record status would be system changed from PDO to NAB. For
value NO in this field, NAB.PERIOD.SPREAD Field should also be NO.
SUB.PAY.SETTING Field identifies whether or not to automatically set the
status of any new subsequent overdue payments to NAB once the first overdue
payment changes status to NAB.
What this means is that if the first overdue payment has a status of NAB and a
subsequent payment becomes overdue, then an input of YES to this field will
automatically set the status of all subsequent payments to NAB. An input of NO
will mean that the second and subsequent payments will be processed like the
first, GRA to PDO and then PDO to NAB.

T3TPD - Past Dues - R12.1 19

 Customers can be classified into different contract groups like Corporate,
Private, and Large etc. Based on the contract group, various options like
frequency of sending PD advices within a particular status, blocking the
advices produced by the system on change of status, collecting charges for
sending PD advices etc. can be defined.
STATUS.CHANGE Field together with ACTIVITY.CODE Field is used to
define which advice type is sent on a change of status. When the contract is set
to the status defined in this field the associated ACTIVITY.CODE Field will
be used. The actual format of the advice depends on the contract type and
application. This is controlled by the key to PD.ADVICES.
Defines the minimum overdue amount of the PD contract, beyond which only
the PD advices will be sent. If the total overdue of the PD contract is less than
the amount defined in this field, then no advice will be sent. Example, if the
SMALL.AMOUNT is 5000 and the SMALL.AMT.CCY is USD, then for all
PD contracts having overdue value less then USD5000, the advices will not be
generated. Associated with the field SMALL.AMT.CCY.
For defining a CONTRACT.GRP code, a record for PD.PAYMENT.DUE
should be created in APPL.GEN.CONDITION.

T3TPD - Past Dues - R12.1 20

 CONTRACT.METHOD Field specifies that the interest rate for calculating
penalty interest is to be defaulted from the underlying contract. Penalty is
calculated in the same currency of the underlying contract. There are six
values which may be entered in this field.
1 uses underlying contract rate only. In case of 2 input to the
PENALTY.SPREAD Field becomes mandatory. The penalty interest and
penalty spread will be accrued separately; 3 is that input to the
MAXIMUM.LEGAL.RATE Field becomes mandatory; 4 is for use of
underlying contract rate plus penalty spread. For AC parameter record, only
allowed option is 5, meaning no penalty is calculated on the contract. If the
input is NULL, then penalty will be calculated at the PENALTY.RATE or
PENALTY.KEY plus PENALTY.SPREAD.
For parameter record with Id as MD or MD Category, the only allowed option
is Null. The PENALTY.RATE or PENALTY.KEY Field should have a value
for these records. If the underlying contract has ZERO interest rate, then the
PD record will use ZERO interest rate for the PENALTY interest calculations.
The Exception log file will be updated reflecting this. Numerical choice input
to this field is only allowed if there is no input made to the PENALTY.RATE
Field or to the PENALTY.KEY Field. In the case of variable interest rates,
underlying contract rate includes spread also. For example, a loan is input with
a BASIC.INTEREST key of 1 representing 10% plus spread of 2%.
PD.PARAMETER has penalty spread of 3%. In this case PE would be
reckoned at 12% and PS at 3%.

T3TPD - Past Dues - R12.1 21

 PENALTY.RATE Field defines the default interest rate to be used for
calculating penalty interest.
Input to this field is only allowed if there is no input made to the
PENALTY.KEY Field or to the CONTRACT.METHOD Field.
PENALTY.SPREAD Field defines the default rate to be used for calculating
penalty spread. Input is mandatory to this field if the field
CONTRACT.METHOD Field contains a value of "2” and “4”. Input is not
allowed to this field if CONTRACT.METHOD Field contains a value of "1"
,"3" or blank.
MAXIMUM.LEGAL.RATE Field defines the maximum legal interest rate
allowed by the Bank. If this field contains a value and a Payment Due contract
is created whose penalty interest is greater than this value then the system will
change the rate to be the value in this field.
MINIMUM.RATE Field defines the minimum interest rate allowed by the
Bank. If this field contains a value and a Payment Due contract is created
whose penalty interest is less than this value then the system will change the
rate to be the value in this field.

T3TPD - Past Dues - R12.1 22

 PEN.CALC.BASIS Field is used to define the basis on which penalty interest
is to be calculated.
This multi-value field specifies on which amounts the penalties will be
calculated.
A single value can be entered such as PR which would calculate penalty
interest on the Principal amounts overdue. Whereas a combined setting of PR,
IN, CO and CH in the expanded multi-values would calculate penalties on the
total sum of the Principal, Interest, Commission and Charges.
Values of
PR Principal overdue amount
IN Interest overdue amount
CO Commission overdue amount
CH Charges overdue
TX Taxes overdue
OD Overdue Principal only, same as PR
OS Outstanding Principal, overdue in PD and outstanding on underlying
contract
Values of OD and OS are for backward compatibility.

T3TPD - Past Dues - R12.1 23

 AUTO.ADJUST.SPREAD Field is used when the penalty spread on a PD is to
be calculated automatically by the system without any input in the
PENALTY.SPREAD Field. If set YES, penalty spread is calculated as
difference between value in PENALTY.RATE Field and interest rate of the
underlying contract. This spread will come into effect after the period or
number of installments specified in PE.SWITCH.PERIOD Field have been
crossed. The value in POST.GR. PS.CALC Field is used as the calculation
base for penalty spread.
If at any time the spread becomes negative, then penalty spread is truncated to
zero. Even after overdue amounts have been fully paid, penalty spread may be
required to be calculated as the difference between penalty rate and the interest
rate on the underlying contract. Consider a LD contract for USD 1m, input on
January 1, 2005, maturing on November 1, 2005. The contract has monthly
repayment schedules of principal, say USD 100,000 and interest beginning 1st
February. If the PE.SWITCH.PERIOD Field is set to 1 day in the relevant
PD.PARAMETER record, then penalty spread will be calculated from Feb 2nd
onwards on outstanding principal of USD 900,000 under the LD contract in
addition to overdues in PD . Suppose on February 5th, the entire overdues in
PD are cleared. If RESTORE.CALC Field is set to YES, all PD.BALANCES
will be cleared in the normal course. If RESTORE.CALC Field is set NULL,
the PD.BALANCE record which shows penalty spread calculations will
continue to exist, and will show these calculations on outstanding principal of
USD 900,000.

T3TPD - Past Dues - R12.1 24

 REPAYMENT.ORDER Field defines the hierarchy of types to be used when a
repayment is made by the customer. When a repayment is made by the
customer, the system will look at this hierarchy of amount types and use them
to allocate the funds across the different types.
If for example the order is PE, PS, PR etc., and the total outstanding for the
above types is 100 for PE, 200 for PS and 1000 for PR, a repayment of 150
will allocate 100 to PE, 50 to PS and nothing for PR. This would bring down
the outstanding to 0 for PE, 150 for PS and PR would remain at 1000.
Remember that this is the default by the system and it is possible by user input
to allocate the funds across different types.
FWOF.RPY.ORDER Field is used to define the hierarchy of types to be used
when the customer makes a repayment on FWOF contracts. When a repayment
is made by the customer, the system will look at this hierarchy of amount types
and use them to allocate the funds across the different types in case of FWOF
contracts. If not defined system will continue to flow by
REPAYMENT.ORDER Field.
When the liquidation mode is semi automatic, it is possible to make the system
look at the liquidation account from time to time and automatically adjust the
balance towards dues.

T3TPD - Past Dues - R12.1 25

 RETRY.FREQ Field is a frequency type field used for checking whether a PD
contract can be liquidated automatically, if there are sufficient funds in the
account, or posted as overdue in a PD contract if there are insufficient funds.
The underlying contract must be set to Semi-Automatic. If unsuccessful on the
first end of day batch it will try again on the next date generated by this field.
MIN.AUTO.PERCENT Field is used in conjunction with RETRY.FREQ Field.
It defines the amount that needs to be available in the liquidation account,
calculated as a percentage of the amount due, to enable automatic settlement to
take place. This can be either on the due date or on dates as specified in
RETRY.FREQ Field.

T3TPD - Past Dues - R12.1 26

 USE.AVBL.FUNDS Field is used to indicate whether the balance available in
the account alone is to be used to settle the past due record.
For both settings YES and NULL, two rules are common and important; Retry
would be initiated only subject to MIN.AUTO.PERCENT Field being
available in the account. For apportioning any balance in the account without
setting a minimum percentage, MIN.AUTO.PERCENT Field should contain
0%. Balance available in the account would include any undrawn LIMIT less
the LOCKED. AMOUNT on the account for the appropriate period of
LOCKING.
If this field is marked to NULL, subject to balance in the account being higher
than the MIN.AUTO.PERCENT defined, the entire component of due is
settled and for any insufficient portion the account is overdrawn. Example,
MIN.AUTO.PERCENT is set as 50% and PD has a due of PR 10,000. Balance
in the settlement account is 6,000. In this case the account would be debited by
10,000, resulting in an overdraft of 4,000, and the PD would be settled.
If this field is marked to YES, only the balance in the account would be
considered for settlement of past dues and the account would not be overdrawn
forcibly. For the same example, if the setting was YES, the account would be
debited for 6,000 being actual balance and PD settled for that amount. After
COB, PD would have a balance of 4,000, would be retried on subsequent days.
By setting MIN.AUTO.PERCENT to 0% and flagging this field to YES, any
funds available in account could be used during COB to settle PD.

T3TPD - Past Dues - R12.1 27

 REPAYMENT.METHOD Field is used for defining the order in which
attempts will be made to repay overdue amounts. When attempts are made
during the batch retry repayment processing for contracts defined as SEMI
AUTOMATIC, then the repayments will be made in the order defined here. 1
is for repayment by type irrespective of date 2 is for by date for all repayment
types 3 is for by date and then by repayment order within date.
If type 1 is defined then the amount available in the customer's account must
be greater than the MIN.AUTO.PERCENT value for the total repayment due
for each type for all dates in the order specified in REPAYMENT.ORDER.
If type 2 is defined then the amount available in the customer's account must
be greater than the MIN.AUTO.PERCENT value for the total repayment due
for all types on that date.
If type 3 is defined then the amount available in the customer's account must
be greater than the MIN.AUTO.PERCENT value for each individual type in
the order specified in REPAYMENT.ORDER by date.

T3TPD - Past Dues - R12.1 28

T3TPD - Past Dues - R12.1 29
T3TPD - Past Dues - R12.1 30
T3TPD - Past Dues - R12.1 31
 RETRY.REPAY.STATUS Field allows definition of the level of overdue
status, for which Semi automatic batch processing will attempt to make
repayments. If the current status of the underlying PD contract is worse than
the level set here, then no attempt will be made to automatically repay.
One of the following values can be defined. PRE for Pre Grace; GRA for
Grace; PDO for Payment Overdue and NAB for Non Accrual Basis. The
default level will be PRE.
If the RETRY.REPAY.STATUS Field is set to PDO, then attempts will be made
to repay contracts with a status of PRE, GRA, and PDO. No attempt will be
made to pay NAB contracts.
INTEREST.BASIS Field is where the interest basis that is used to calculate
penal interest, spread etc when a contract becomes past due, is specified. If left
blank, the interest basis of the underlying contract is applied. Used for
calculation of penalty interest and spread.
By attaching one or more records pre defined in FT.COMMISSION.TYPE to
DEFAULT.CHARGES Field, it is possible to default these into PD record to
be taken whenever a repayment takes place.

T3TPD - Past Dues - R12.1 32

 PAYMENT.ROLLOVER Field enables shifting of due dates of Overdues.
Whenever a customer makes a payment against the past due installments,
system checks the installment amounts and components to see if the repayment
amount is more than one installment amount, if so, rolls over the last past due
date suitably. Every overdue installment date is moved forward by number of
installments due repaid.
The PAYMENT.ROLLOVER Field in PD.PARAMETER accepts values
“YES” or “Null”. Once the parameter record is authorised, this field is a No-
change field.
To enable this functionality:
1. SUB.PAY.SETTING Field should have been set as Yes, by which if one PD
installment becomes NAB, then subsequent installments would become
NAB straightaway without going through ageing process
2. REPAYMENT.METHOD Field should have been set as 1, by which dues
would be adjusted by repayment type irrespective of date
3. PE & PS should be named as the first two components in the Repayment
order and should not be capitalised as CP and CS
INS.AMT.TYPES multi value Field is used to define the components that form
the installments to be collected on repayment. Can accept any payment type
like IN, PR , CH etc.

T3TPD - Past Dues - R12.1 33

 In the above instance, Payment Rollover is opted. Repayment priority for
installment is IN, PR, CH. PE & PS are defined as first two components in
repayment order.
Loan installment amount is the sum total of components in INST.AMT.TYPE
Field, namely IN, PR, CH.
If a repayment of 6000 is made, PE (150) is adjusted first, IN (1350) is
adjusted next, 4500 is adjusted in PR of Jan ‟09, leaving a balance of 500. This
amount of 500 is rolled over to Feb „09 PR, thus Feb „09 PR becomes 5500.
Similarly Jan „09 CH of 10 is rolled over to Feb „09, thus Feb „09 CH becomes
20. Rollover can happen only if the payment is equal to one installment or
more.
When rolling over the past due date from Jan „09 to Feb ‟09, the loan
installment amount of Feb „09 too gets adjusted by the excess amount of 500
over the installment amount (6000 – 5500).

T3TPD - Past Dues - R12.1 34

 When a PD contract becomes NAB, it is also possible to suspend interest
accrual in underlying LD, MG and AZ contracts.
Flagging SUSPEND.INCOME Field to YES would enable a bank to suspend
income on all dues on a loan, current and past, should the past due portion
become NAB. For records created with category codes of LD, MG or AZ
related, this field could be set as Yes.

T3TPD - Past Dues - R12.1 35

 If REVERSE.PL.AT.NAB Field were set to YES, the reversal would be
restricted to income credited to P&L from PD (PE & PS). If
SUSPEND.INCOME Field were flagged to YES, reversal of income credited
to P&L would also include the income credited from LD /MG / AZ that is yet
to be realised (IN & CO) also.
When the status of a PD contract changes from PDO to NAB, it is possible to
reverse all the accrued income by choosing YES in REVERSE.PL.AT.NAB
Field. For the purpose of reversal, total interest accrual is segregated into
current year interest accrual and previous year‟s accrual. Current year accrual
amount gets reversed with PL category as defined in CAT.OD.INT.CUR Field
while the previous year accrual amount gets reversed with PL category as
defined in CAT.OD.INT.PRV.YR Field.
Like this, in case of PENALTY SPREAD, current year accrual amount gets
reversed with CAT.OD.SPR.CUR Field and previous year‟s accrual amount
gets reversed with CAT.OD.SPR.PRV.YR Field.

T3TPD - Past Dues - R12.1 36

 If IMPACT.LIMIT Field has no value (null), only principal overdues will be
considered for limit impact.
ROUNDING.RULE Field will hold Product level rounding rule for penalty
interest calculations. Any predefined record Of EB.ROUNDING table can be
used for this purpose.
WAIVE.GRA.PE and WAIVE.GRA.PS Fields indicate whether the Penalty
interest (PE) and Penalty spread (PS) calculated need to be waived when
repayment is made during GRA status. We cannot opt to waive this if the
CONTRACT.METHOD Field had been set as 4 or 5, viz where the Penalty
spread is going to be added with Penalty interest and accrued together under
method 4 or no penalty is to be levied under method 5.

T3TPD - Past Dues - R12.1 37

T3TPD - Past Dues - R12.1 38
T3TPD - Past Dues - R12.1 39
T3TPD - Past Dues - R12.1 40
 LN.ASSET.CLASS table is used to capture the Various Asset classifications
which the user may use for provision calculation. The table also has facility to
capture the applicable provision for each risk category, write-off indicators,
Income recognition indicators among others. The table can store up to 999
asset classes.
PROV.PERC Field indicates the Percentage of provision applicable for this
asset class. Provision would be calculated on entire outstanding balance in LD,
MG and overdue principal in PD when the contract is in this Asset class.
WRITE.OFF Field indicates whether WRITE.OFF is applicable for this class
of asset. When the underlying contract is fully liquidated, then the PD contract
would be automatically written off. STATUS would be updated as FWOF in
PD and in underlying contract. When underlying contract is not fully
liquidated, system writes an exception log in PD.PROV.EXCEPTION.LOG
file and the user may manually WRITE-OFF the contract later on. If this field
is set to YES, percentage of provisioning, P&L and Internal account category
cannot be filled up.
INCOME.RECOG Field indicates whether income should be accrued for this
class of asset. If set NO system would switch from accrual basis to cash basis;
Income would be suspended, memo accruals would be posted. STATUS would
be updated as NAB in PD and underlying contracts and POST.END.DATE
would be updated as null. NULL or YES means that Income would continue to
accrue.

T3TPD - Past Dues - R12.1 41

T3TPD - Past Dues - R12.1 42
T3TPD - Past Dues - R12.1 43
 ASSET.CLASS.PARAMETER table is used to define rules and provision
applicable for different loans based on their ageing. Id of the record is
Company Code.
The time buckets based on PD ageing and related asset class definition would
be captured in this parameter table. The provision applicable for such asset
classes would also be captured. The parameter file could be modified as
required by the user.
At the desired frequency, the loan contracts in the system would be reviewed
and classified as per the ageing buckets defined. Once asset classification is
done, necessary provision amount would be calculated and accounting entries
generated.
The asset classification and related provisioning would be handled for each
contract independently.

T3TPD - Past Dues - R12.1 44

 OVERDUE.FR and OVERDUE.TO Fields are used to indicate the number of
days, the amount type needs to be overdue, to be classified as ASSET.CLASS
defined in this Multi-value set. Numbers indicate Overdue in Days.
AMT.TYPE Field describes conditions based on individual Amount elements,
like Principal, Interest, etc. Valid Key to PD.AMOUNT.TYPE. Special Key
"ALL" is valid. It is the sum of all Individual Overdue types.
If PR is 20 days due and IN is 10 days due and PE is 3 days due, ALL would
mean 33 days. Asset classes should be organised in ascending order.

T3TPD - Past Dues - R12.1 45

 PROV.PERC Field indicates the Percentage of provision applicable for the
particular asset class. Provision would be calculated by applying this provision
percentage on outstanding balance in LD, MG and overdue principal in PD.
Defaults from LN.ASSET.CLASS and could be overridden. Invalid input if
WRITE.OFF is set to "YES“.
INCOME.RECOG Field indicates whether income should be accrued for this
class of asset. If this field is set to "NO" system would switch from accrual
basis to cash basis. This can be indicated for loans having related PD and loans
of any asset class(including Standard assets) set up in
ASSET.CLASS.PARAMETER, even without related PD contracts.
PROV.EXP.CATEG Field is used to indicates the PL category to which
provision expense should be booked.
PROV.RESV.CATEG Field is used to set the internal account category to
which the provision amount should be parked. An internal account has to be
opened in local currency for this category. System shall automatically create
account for other currencies whenever needed.
Frequency at which system would do provision accounting and re-
classification of assets can be set through PROV.REVIEW.FREQ Field.

T3TPD - Past Dues - R12.1 46

T3TPD - Past Dues - R12.1 47
T3TPD - Past Dues - R12.1 48
T3TPD - Past Dues - R12.1 49
 PD.WOF.REASON is the table used to define various reasons for Writing Off
a contract and may use these in the PD.PAYMENT.DUE record during the
actual Write-off. Id of the record is two digit number. The table can store up to
99 reasons.

T3TPD - Past Dues - R12.1 50

T3TPD - Past Dues - R12.1 51
T3TPD - Past Dues - R12.1 52
 The order in which these files should be created is stored within the automated
tool for IM. For easy reference, the order sequence in the ascending build
reference order is given in the left.
The values required for population of the tables will be obtained from
information analysed within the BRADDS.
The mandatory and optional files are shown by different colour codes.
Wherever there are dependencies for filling up values in the tables in build
sequence, the dependencies are shown on the right.

T3TPD - Past Dues - R12.1 53

T3TPD - Past Dues - R12.1 54
 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, example a Mortgage
contract with an Id of MG0103100412 would have a PD record with an Id of
PDMG0103100412. PD created through the PD.CAPTURE application have a
prefix of PDPD, example PDPD0101500366. When overdues in AZ credit
card move to PD, Id created will be based on parameter settings of
AZ.PRODUCT.PARAMETER.
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.

T3TPD - Past Dues - R12.1 55

 Overdues can be captured manually through PD.CAPTURE. If loan
repayments are allowed to settle to accounts when funds are not available, they
could still be transferred to PD later using PD.CAPTURE. However, it should
be borne in mind that in such cases, the contract balance files like
LMM.ACCOUNT.BALANCES will reflect only LD, MM contract balances
and not what is transferred to PD through the Account and PD.CAPTURE
route.
The Id of the PD record created through PD.CAPTURE will be PDCA/Julian
date/Serial No, example PDCA/07236/00028. On authorisation, the record
moves to PD.PAYMENT DUE with Id with prefix of PDPD, example,
PDPD/07236/00029. If a contract number had been referenced in
PD.CAPTURE, the serial number will be in the usual format of PD followed
by contract number, like PDLD071500002.

T3TPD - Past Dues - R12.1 56

 Where a Limit is defined as non-reducing, the system is amended to allow the
LIMIT system to bypass the available amount increase for non-reducing
LIMIT records. PD application will then update the available amount as and
when payments are received. Under a revolving LD commitment, when the
liquidation account has only part of the due amount, limit is reinstated with
full due amount or part due amount depending on settings in LD application.
It should be noted that the PD contract normally adopts the LIMIT used by the
underlying application. However, if the underlying contract was a Loan that
was linked to a reducing Limit, it would be incorrect to reinstate the Limit
when the overdue amount is passed to PD.
Under these circumstances an information LIMIT will be used. However, it is
possible to change the LIMIT by using the MAINTENANCE option in
OPERATION Field in PD.PAYMENT.DUE. For account PD, there would be
no link to limits.

T3TPD - Past Dues - R12.1 57

T3TPD - Past Dues - R12.1 58
T3TPD - Past Dues - R12.1 59
T3TPD - Past Dues - R12.1 60
T3TPD - Past Dues - R12.1 61
T3TPD - Past Dues - R12.1 62
T3TPD - Past Dues - R12.1 63
T3TPD - Past Dues - R12.1 64
T3TPD - Past Dues - R12.1 65
T3TPD - Past Dues - R12.1 66
T3TPD - Past Dues - R12.1 67
T3TPD - Past Dues - R12.1 68
T3TPD - Past Dues - R12.1 69
 OPERATION Field is used to define the processing to be performed on the PD
contract.
Only one type of process may be performed at one time of which there are
four. They are MAINTENANCE, ADJUSTMENT, REPAYMENT and
SCHEDULE.
Upon input to a PD contract this is the only field which allows any input. Once
an operation to be performed has been input this field blocks any further input
and opens up the required fields depending upon the operation. Therefore to
perform another operation on the same contract, the record must be authorised
or deleted, unless of course one exits using F1.
The SCHEDULE operation is used for entering scheduled events such as rate
or spread changes and for the production of chaser advices.
The ADJUSTMENT operation is used to adjust the outstanding payment
amounts, by type, either upwards or downwards.
The MAINTENANCE operation is used to change contract details such as the
limit reference of the PD contract, the status of individual payments due on a
particular date, whether or not to net any entries across the customer's account
together, or to change the customer's portfolio.
The REPAYMENT operation is used for entering details when a customer
wishes to repay all or part of the loan.

T3TPD - Past Dues - R12.1 70

 The SCHEDULE operation allows definition of future PD events for that
contract.
Penalty rate or spread changes cannot be input for a future date.
The interest rate field and the interest spread fields are used to apply Penalty
interest.

T3TPD - Past Dues - R12.1 71

T3TPD - Past Dues - R12.1 72
T3TPD - Past Dues - R12.1 73
 The ADJUSTMENT operation is used to adjust the outstanding payment
amounts, by type, either upwards or downwards.
If the adjustment is done to Asset Types PE and PS, entries are passed to
CATEG ENTRY file if the PD is in OVERDUE status and to
RE.CONSOL.SPEC.ENTRY file, into Asset Type SP, if the repaid status is
NAB, into the respective PL category and Asset Type respectively.
If adjustment is done to any other PD.AMOUNT.TYPE, input of Liquidation
Account is mandatory. For the amount of adjustment done, STMT.ENTRY is
raised into the liquidation account mentioned.

T3TPD - Past Dues - R12.1 74

T3TPD - Past Dues - R12.1 75
T3TPD - Past Dues - R12.1 76
T3TPD - Past Dues - R12.1 77
T3TPD - Past Dues - R12.1 78
 The MAINTENANCE operation is used to change contract details such as the
limit reference of the PD contract, the status of individual payments due on a
particular date, whether or not to net any entries across the customer's account
together, or to change the customer's portfolio. The status change option is
mostly used to change payments to NAB or WOF status if the user judges
there is little chance of recovering that payment. The status of a payment can
only be made worse and similarly a recently overdue payment cannot be in a
worse situation than an older payment. Account past dues with PR overdue
types can use only this operation.

T3TPD - Past Dues - R12.1 79

T3TPD - Past Dues - R12.1 80
T3TPD - Past Dues - R12.1 81
 The REPAYMENT operation is the most important operation. All payments,
in part or in full, to loans monitored by PDs are made manually via the repay
operation. 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, PD 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.
Full Settlement is where a customer wishes to pay the full overdue amount.
Settlement with Penalties is when a customer wishes to settle the overdue
amount together with any penalties charged on the arrears.
Partial settlement is when a customer wishes to settle part of an arrear loan
Payment with any penalties charged on the arrears.

T3TPD - Past Dues - R12.1 82

T3TPD - Past Dues - R12.1 83
T3TPD - Past Dues - R12.1 84
T3TPD - Past Dues - R12.1 85
T3TPD - Past Dues - R12.1 86
T3TPD - Past Dues - R12.1 87
T3TPD - Past Dues - R12.1 88
T3TPD - Past Dues - R12.1 89
T3TPD - Past Dues - R12.1 90
T3TPD - Past Dues - R12.1 91
T3TPD - Past Dues - R12.1 92
T3TPD - Past Dues - R12.1 93
T3TPD - Past Dues - R12.1 94
T3TPD - Past Dues - R12.1 95
T3TPD - Past Dues - R12.1 96
 PROVISION.METHOD Field in LD, MG and PD applications indicates
whether asset classification should be computed Automatically or maintained
manually.
When this field is populated with NULL for new contracts or AUTO, system
computes the asset classification during the next Provision review Frequency
as set in ASSET.CLASS.PARAMETER and updates the ASSET.CLASS,
PROVISION and PROVISION.AMOUNT with new details.
When this field is populated as MANUAL, it is assumed that the user manages
the asset classification manually and the contract would be skipped for any
computation of asset classification until the field is switched back to AUTO.
When there are many contracts for a customer, the worst of Asset classification
among the contracts will be indicated in CUSTOMER record, which is for
information only.

T3TPD - Past Dues - R12.1 97

T3TPD - Past Dues - R12.1 98
T3TPD - Past Dues - R12.1 99
T3TPD - Past Dues - R12.1 100
 Automatic Financial write-off is possible only if the underlying contracts do
not have any balance, viz the entire contract has matured and moved to PD. If
the contract has some balance that has not yet fallen due for payment, the
System will raise entries in PD.PROV.EXCEPTION.LOG application. 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.
Manual repayment of contracts with FWOF status is done by choosing the
Repayment option in the PD contract. The repayment amount is apportioned
in the order mentioned in the FWOF.RPY.ORDER Field in PD.PARAMETER
and in the absence of any, then the PD repayment order is followed. For a
FWOF to happen, it is necessary that REVERSE.PL.AT.NAB Field is set as
YES, SUB.PAY.SETTING Field is set as YES, NAB.PERIOD.INT and
NAB.PERIOD.SPRD Fields are set as NO in PD.PARAMETER.

T3TPD - Past Dues - R12.1 101

T3TPD - Past Dues - R12.1 102
 Accounting entries passed for PD module are non contingent in nature.
Statement entries are passed for debit and credit to customer and internal
accounts, category entries for debit and credit to PL heads for interest,
commission and charges. Spec entries are passed during batch process for new
contracts and for repayment and closure using PD.PAYMENT.DUE.
PD module uses transactions codes defined in PD.PARAMETER and
FT.COMMISSION.TYPE.
During non-stop processing of COB, PD.CAPTURE is the only allowed
application pertaining to PD.

T3TPD - Past Dues - R12.1 103

 Outstanding Payment Due enquiry gives full particulars of Overdue items
under a PD like dues under different payment types.
Overdue items under a PD enquiry can display period wise outstanding. If PD
overdues of upto 30 days are desired, then it will display PD overdues upto 30
days of all Customers, or any chosen Customer.
Outstanding Payments due List enquiry displays Overall outstanding PDs. This
can be viewed Customer or contract wise.
The enquiry Customer Provision Summary 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.
Special entries created in PD due to overdue drawings in LC get reported
under TRANS.JOURNAL.

T3TPD - Past Dues - R12.1 104

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

T3TPD - Past Dues - R12.1 105

 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.
The key to the file is the PD.PAYMENT.DUE contract Id.

T3TPD - Past Dues - R12.1 106

 The PD.REPAYMENT file is used to store all the repayment details for a PD
contract. As all the repayment details are cleared from the PD.PAYMENT.
DUE contract once it is processed, this file is updated by the System
automatically.
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.
There is a corresponding save file PD.RATES.SAVE that stores the last
authorised version of the PD.RATES file.
EB.CONTRACT.BALANCES holds information of principal and other
amounts such as interest, accrued charges, commissions etc.
Id is PD Id itself.
Both current and historical details are maintained so that all financial
transactions can be recorded and controlled.
This is updated automatically by any transaction, either online or during the
close of business, that modifies Central reporting base details.
Information held includes currency of balance, CRB Asset types and
associated value dates, maturity dates and amount outstanding.
It also holds the consolidation key.

T3TPD - Past Dues - R12.1 107

T3TPD - Past Dues - R12.1 108
T3TPD - Past Dues - R12.1 109
T3TPD - Past Dues - R12.1 110