Introduction to Past Due

• PD deals with overdue payment and is determined by the settings on PD.PARAMETER. The bank can have a PD.PARAMETER record for each loan category, so PD processing can be different for various products.

  For example, overdue processing cycle usually differs when dealing with an overdue mortgage and an overdue money market trade. The PD module defaults to the COMPANY settings, when no record is defined for the category of product being processed.

• A record with an ID equivalent to the COMPANY ID has to exist on the PD.PARAMETER file, to allow standard PD processing. If Account (AC) module 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 control how the PD processing continues.
• The Pen Calc Basis and Ps Calc Basis attributes are used to decide the elements of the loan, on which the penalties are calculated.

  For example, the PE type penalty calculation can be based on the outstanding PR element, and PR element and 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 (overdue amount only) or OS (the total of overdue and the current loan outstanding).

  The former is all the overdue elements, which implies, all outstanding are used in the penalty calculation; the latter is a more punitive penalty as it calculates on both overdue and current outstanding (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 when the system is online, that is, these cannot be input or amended once COB has started, even if NS (Non Stop Processing) is installed.
• A payment in past due may pass through the following statuses in its life:

  CUR → PRE → GRA → PDO → NAB → WOF

Status	Description	Processing
CUR	Current	This is the status of a past due payment when it is fully up to date , that is, 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 is not 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.

• The Enable RFR field is used to enable the RFR functionality for the overdue contract when the underlying loan contract is a RFR contract.

Risk-Free rates (RFRs) are alternative rates for Interbank Offered Rate (IBOR) and are replacing the IBORs. For IBORs, the interest rate is fixed for the term at the beginning of the period. Whereas RFRs are overnight and backward-looking rates derived from actual market data for a given business day. These rates are published on each business day with a delay (that is, a rate published for the current business day is effective for the previous business day). These rates do not have a term structure and a credit risk element. Each major currency has its alternate RFRs as listed below.

The PERIODIC.INTEREST table stores RFRs in the RFR Rate field. Banks can set up RFRs for different currencies using this key entered in the RFR Rate field or create an alternative key in this table. The overnight RFRs are published as a single rate with no bid or offer options.

Market Convention

The LD.LOANS.AND.DEPOSITS and PD.PAYMENT.DUE applications follow the lookback market convention to identify the interest rates based on the defined lookback days.

In the look back market convention, for every day in the current interest period, the RFR rate from N business days earlier is used.

An illustration with two business days [N = two days] is shown below:

RFR supports the following lookback types:

• Narrow [Without Observation Shift] - Applies the original interest period’s day weightage to the lookback rate used for the current day. For example if Wednesday’s rate is used for Friday, this type applies Friday’s weight, three days, to Wednesday’s rate. For example, consider an RFR contract is booked with lookback days as two on Friday. This type uses Wednesday’s rate to calculate the interest rate on Friday. However, it applies the Friday’s weight, that is, three days (considering Saturday and Sunday as holidays) to the Wednesday’s rate to calculate the interest amount for Friday.
• Observation Shift - Applies the original day weightage of the lookback rate, that is, if Wednesday’s rate is used for Friday, then this type applies Wednesday’s own weight, one day, and does not use Friday’s day count. For example, consider an RFR contract is booked with lookback days as two on Friday. This type uses Wednesday’s rate to calculate the interest rate on Friday. However, it applies Wednesday’s own weight, that is, one day and does not use Friday’s day count for calculating the interest rate.

RFR Interest Calculation Methods

The Loans and Deposits module offers banks the flexibility to use the following interest calculation methods for RFR contracts. The Past Due module also supports these interest calculation methods. When overdue payment is moved to PD, it uses the rates from the underlying RFR loan contract for penalty interest calculations.

Compound Average Calculation Method

RFRs support the compounding average calculation method where rates are compounded every day to arrive at a final rate to determine the payment for a particular interest period. This method is accurate for the scenarios where the principal amount remains unchanged during the interest period. The formula calculate the average RFR compounded rate is,

Where,

• n is the number of calendar days from (and including) the start date to (but excluding) the end date
• d is the number of business days in the same period
• b is the market convention of quoting number of days in a year
• ri is the applicable overnight rate in respect of business day i
• ai is the number of calendar days in the period for which rate ri applies

Simple Average Calculation Method

RFRs support the simple average calculation method every day to arrive at a final rate to determine the payment for a particular interest period. This method is accurate for the scenarios where the principal amount remains unchanged during the interest period. The formula to calculate the simple average RFR rate is,

Where,

• db is the number of business days in the interest period.
• de is the number of calendar days in the interest period
• ri is the rate applicable on the business day i
• ni is the number of calendar days in the period for which rate ri applies
• N is the market convention of quoting number of days in a year.
• i is the series of ordinal numbers representing each business day in the period.

Amount Calculation Method

RFRs support the amount calculation method. In this method, the contract balance must be compounded daily instead of rates. The Loans and Deposits module uses the daily RFRs published by the central banks (no rate formula is applied). Use the identified RFR rate on the compounded balance (sum of the outstanding principal and the unpaid accrued amount) to calculate the daily interest accrual.

This accrual calculation method is more accurate when the principal amount changes during the interest period.

The PD.RFR.PARAMETER parameter table processes the overdue payments for RFR contracts.

• PD RFR deals with overdue payments, and it is determined by the PD.RFR.PARAMETER settings. It is possible to configure PD.RFR.PARAMETER for each loan category to have a different PD processing for various products. When no record is defined for the category of product and when processed, the PD module defaults to the COMPANY settings.
• For each RFR interest calculation method, banks can define a separate configuration for calculation basis and spread treatment.
• The RFR Pen Calc Basis and RFR Ps Calc Basis attributes decide on the elements of the loan, for which the penalties are calculated.
• RFR contracts support spread inclusive and spread exclusive spread treatments and the RFR Spread Treatment field configures spread treatment.
• Rfr Penalty Spread is the default spread rate to calculate the penalty spread accrual amount and banks can configure the different rates for different RFR Spread Treatment.

• 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 can be invoked by setting Status Change to YES in PD.PARAMETER.
• The PD.PARAMETER contains the time settings that determine when a payment moves from PRE to GRA, from GRA to PDO and from PDO to NAB, and may be defined as a number of days or as a number of payments. In case the change of status from PDO to NAB is not to be automated and controlled only manually, NO may be input in Nab Period Int and Nab Period Spread.
• In this case, the status of the PD is retained as PDO till such time the record is manually maintained to NAB.

  

• Once a payment becomes due, the loan module stops calculating contractual interest and hands the payment over to PD. PD charges penalty interest, which is usually higher than the rate on the contract. On PD.PARAMETER the user can define:
  • Penalty calculation rules
  • The amount used as the base to calculate penalty. Any combination of the amounts overdue may be used to calculate the penalty, for example, 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 for an amount defined via Ps Calc Basis on PD.PARAMETER, with the outstanding amount as the default.
• The 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 is automatically calculated by the system, by setting the Auto Adj Spread to YES. In such cases, the Penalty Spread attribute cannot be input.
• The penalty spread is then 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 takes precedence over the rate in Penalty Rate at the PD.PARAMETER level.
• The calculation of spread begins when the number of days or number of instalments stipulated in Pe Switch Period has been crossed. The basis for calculation of penalty spread is on the base specified in Post Gr Ps Calc. If it is required that penalty spread calculations continue even after all past dues are cleared, Restore Calc should have a null value.

Penalty Interest Calculation Details for RFR Contracts

For Non RFR contracts, the rate from an underlying LD contract (where a periodic interest key and spread is defined) includes rates applicable for the key and the spread on the loan deal, and this rate is treated as a penalty interest rate. Users may define only the penalty spread in PD.PARAMETER as Penalty Spread (PS) component. However, for RFR contracts, the penalty interest rate depends on the spread treatment of the underlying RFR loan contract.

• For Spread Inclusive Type contracts, the penalty interest rate includes the rates applicable for periodic interest key and the spread on the deal. The value specified in RFR Penalty Spread of PD.RFR.PARAMETER is treated as a penalty spread.
• For Spread Exclusive Type contracts, the applicable periodic interest key rate is treated as the penalty interest rate. The penalty spread includes the spread defined on the loan deal and RFR Penalty Spread, which is defined in PD.RFR.PARAMETER.
• Penalty interest is calculated with the above calculated penalty interest rate for an amount defined in RFR Pen Calc Basis of PD.RFR.PARAMETER.
• Penalty spread is calculated with the above calculated penalty spread rate for an amount defined in RFR Ps Calc Basis of PD.RFR.PARAMETER.
• Existing Contract Method field functionality is not applicable for RFR contracts. PD uses the RFR Penalty Spread field in PD.RFR.PARAMETER table to achieve existing contract method functionality. If the RFR Penalty Spread is specified, the system treats it as the default penalty spread and if no value is specified, the penalty spread is considered as zero.

• Two PD.AMOUNT.TYPE values, namely WE and WS needs to be added for waiver of penalty interest and spread respectively.
  

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

  

• The Waive Gra Pe and Waive Gra Ps attributes in PD.PARAMETER and PD.PAYMENT.DUE when flagged to YES, waives penalty interest or spread amount calculated during grace period instead of imposing it. The attributes cannot have different values, that is, one of them set to YES and the other left Null.
• The value from the parameter record gets defaulted to the underlying contract where the values can be changed, if required.
  

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

• Capitalisation is permitted for both Penalty Income (PE) and Penalty Spread (PS) with frequencies set in numbers of months.
• The user can specify the Pe Cap Freq and Ps Cap Freq attributes in the each parameter record of the PD.PARAMETER table. This enables the user to capitalize the interest at different frequencies for different types of past dues if required. These Pe Cap Freq and Ps Cap Freq attributes specify the date and frequency of the next accrual and is rolled over to the next effective date during the Close of Business on the capitalization date.
• For PD contracts that are linked to LIVE RFR loan contracts, PD capitalization frequency is the same as the underlying loan interest schedule. If the underlying RFR contract is matured, PD contracts follow the capitalization frequency defined in the Pe Cap Freq and Ps Cap Freq attribute from the PD.PARAMETER table.
• The attribute validations are similar to other Temenos Transact frequencies like:
  • Eight numeric standard date characters followed by a five alphanumeric frequency.
  • Date input must be equal to or greater than today.
  • The frequency should be specified in number of months.
• The dates and frequencies in Pe Cap Freq and Ps Cap Freq should match. Two separate attributes are provided so as to facilitate having capitalisation on either component and not on the other, if so desired.
• On capitalisation the amount types created are CE (Capitalised Penalty Interest) and CS (Capitalised Penalty Spread).

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.

It is possible to suspend income on the associated LD or MG or AZ deal should the past due become NAB. Suspension of income includes interest and commission on the LD and interest only on MG or 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.

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

• A contract may have several payments outstanding. Each payment has a principal and/or an interest portion, and can also have associated amounts of penalty, tax, charges, etc. When the client makes a payment, this may not cover the full overdue amount.
• The user 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) are 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 is 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, that is, the oldest repayments are paid first.
• Repayment order as recorded in Repayment Order attribute, defines the hierarchy of amount types to be used to allocate by the system, when a repayment is made by the customer.
• The Repayment Method on PD.PARAMETER defines the type of repayment processing; following three methods are available:
  • Repayment by type irrespective of date - total repayment due for each type for all dates as specified in the Repayment Order with Min Auto Percent processing taking place should be available in the account to cover the calculated amount (or a defined percentage of it).
  • Total outstanding by date - total repayment for a given repayment date in chronological order with Min Auto Percent processing taking place, repayment only takes place if there are funds available to cover the whole amount overdue for that date (or a defined percentage of it).
  • By date (repayment will take place in chronological order) and then by repayment order for each date - repayment will stop when no funds are available to cover an amount type for a given date (or a defined percentage of it, that is, partial repayment of the debt for a given date can take place).
• If the requirement is to use the available funds in the Original Settlement Account for appropriation and not overdraw, Use Avbl Funds has to be flagged to YES. If the liquidation account has a value defined in Locked Amount attribute in account, such amount for the respective period is reckoned while deriving the amount available for retry.
• The PD Close of Business processing can attempt repayment up to NAB status, and process multiple PD.BALANCES records.
• Retry Repay Status on PD.PARAMETER is used to define the PD status up to which repayments are attempted.

  

• The COB retry also covers PDPD (PD deals without underlying contracts) contracts. However, should the user prefer to avoid retry for a particular contract, Prevent Retry attribute in the PD contract may be flagged YES through Maintenance operation.

The other attributes of PD.PARAMETER allow the user to specify the category and transaction codes used for reporting PD amounts.

• For the account to be linked to PD, the Ac Cp Categ Fr, Ac Cp Categ To, Ac Cb Categ Fr, Ac Cb Categ To, and Ac Od Days attributes need to be defined in this parameter record. The first two attributes form a multi-valued set and they are used to define the revolving credit account categories to be linked to PD. The next two attributes define the account category range for linking overdrawn accounts into PD. The Ac Od Days attribute defines the number of days from which the overdrawn account gets linked to PD.
• For any other parameter record, no inputs are allowed into the above-mentioned attributes. If there were no AC parameter record, then accounts are not linked to PD at all.
• No penalty can be calculated on the account PD - allowing only the contract method 5 in the Contract Method attribute of the AC parameter record ensures this.
• Separate parameter records can also be set-up for the account categories input in the relevant attributes in AC parameter record. These records also don’t accept penalty calculation.
• For any other account not within the category of CB and CP ranges mentioned above, PD is written for the unauthorised overdraft portion on the day such account is overdrawn. For an account with no limit any debit balance is construed as unauthorised and for one with limit, the drawings in excess of limit are considered as unauthorised.

A set of accounting entries are raised with asset type OVERDUEPR (Debit) and CONTRAAC (Credit) asset types for such unauthorised portion. The actual balance in the account is retained in ACCOUNT application. The user may read DEBIT and CONTRAAC asset types in one line and OVERDUEPR in another to report authorised and unauthorised overdraft in different lines.

Past Due deals with the overdue payment, which is determined in the PD.PARAMETER application. The user can have a PD.PARAMETER record for each loan category, so PD processing can be different for various products. For example, the overdue processing cycle usually differs when dealing with an overdue Mortgage and an overdue Money Market trade. The PD module defaults to the company settings, where no record is defined for the category of product being processed.

Penalties can be processed based on several key settings. After the relevant PD.PARAMETER record has been used, the settings within that record controls how the PD processing continues.

These files can only be maintained online, that is, it cannot be input or amended once COB has started, even if NS (Non Stop Processing) is installed.

This table is used for Waiver of penalty interest and spread respectively.