Process Repayments

This topic describes the process repayments schemes with example.

When the user makes a Securities repo deal, the user also decide on the terms of the repayment of the placement or borrowing.

The user may have your repayment schemes; for example, the user may prefer monthly repayments of interest or the repayment of the principal on maturity, and so on. Or, the user may design repayment schedules to suit the convenience of your customer. Your customer may want the repayments done daily, instead of every week, for example.

In Oracle Banking Treasury Management, the user can customize your repayment schedules for a money market product. The same schedules will, by default, apply to the deals involving the product. However, when processing a specific deal, the user can change the repayment schedule, which it inherits, from the product it involves.

Define Schedules for Repayment

Define repayment schedules for the interest or interest types of ICCB components like a tenor based charge or fee and the principal of a Securities Repo deal while defining a product.

The attributes of the schedules for a product are defined through the Product Preferences screen. The following are the attributes of a repayment schedule:

• Mode of liquidation - auto or manual. This is changed at the time of deal processing.
• Liquidation of back valued schedules upon initiation of a deal. This is changed at the time of deal processing based on requirement.

However, for a deal, the user can have:

• Only a maturity schedule for the principal and no interim schedules
• Interim schedules for the interest
• The only normal type of schedules for interest. Schedules cannot be capitalized or amortized
• No schedules for commission, charge or fees

A discussion on these attributes follows in this topic.

The Automatic Contract Update function executed as part of the SR Batch Daily routine automatically liquidates schedules that the user has marked for auto liquidation. If schedules are marked for manual liquidation, the user will have to liquidate them through the Contract Schedule Payments function.

Once the user specifies the attributes of schedules in the Product Preferences screen, the default schedules, which the user wants, applied to the deals involving the product, and are specified through the Product Schedules screen. At the time of deal processing, the user can change the schedules which have been inherited by the deal, to suit your needs.

If the Interest specified is an amount and not a rate (Special type of Interest), the user must enter this amount for the interest component. The user must specify the number of schedules for the component (interim schedules and maturity schedule). The user can give the Start Date, Frequency and Unit again or let the details inherited from the product remain.

Note:

If schedules are not defined for the product, then the borrowings or placements under it will have bullet (or balloon) schedules by default. That is, all the components is liquidated on Maturity. Since for a money market deal, the principal repaid is always at Maturity, the user need not define a schedule

Mode of Liquidation

Components of a deal are liquidated automatically or manually. In the Product Preferences screen, the user must indicate whether the mode of liquidation of repayment schedules is to be automatic.

Specify Auto liquidation if the user want the components of a deal (involving a product) to be liquidated automatically. If the user so specify, a schedule is automatically liquidated the day it falls due, during the beginning of day processing (by the Automatic Contract Update function.)

Now, consider the following situation:

• The user has indicated automatic liquidation
• The scheduled date falls on a holiday, and
• The user has specified (through the contract preferences screen), that the holiday be ignored while calculating the scheduled date.

In such a situation, a repayment falling on a holiday would be processed according to your specifications forholiday handling (in the SR Branch Parameters screen). It would be as follows:

• If the user has specified that processing has to be done (on the last working day before the holiday) for automatic events right up to the day before the next working day, the schedule falling on the holiday will be liquidated during the end of day processing on the last working day before the holiday.
• If the user has specified that processing has to be done only up to the System Date (today), then only those events scheduled for today (the last working day before the holiday) will be processed. The events falling due on holiday are processed on the next working day after the holiday, during the beginning of day processing.

In such a situation, a repayment falling on a holiday would be processed according to your specifications forholiday handling (in the SR Branch Parameters screen). It would be as follows:

• If the user has specified that processing has to be done (on the last working day before the holiday) for automatic events right up to the day before the next working day, the schedule falling on the holiday will be liquidated during the end of day processing on the last working day before the holiday.
• If the user has specified that processing has to be done only up to the System Date (today), then only those events scheduled for today (the last working day before the holiday) will be processed. The events falling due on holiday are processed on the next working day after the holiday, during the beginning of day processing.
• If a borrowing has been defined for verification of funds before automatic liquidation (through the Contract Online Preferences screen), those components whose schedule dates fall on the same day will be liquidated in the order the user has specified when defining the product.
• If the funds are insufficient, the liquidation is done to the extent of the available balance in the repayment account. The components will be liquidated in the order that the user specify. This will be reported in the Exception Report generated at the end of every day, automatically (by the Automatic Contract Update function). If the user has not specified that the funds be verified, and there are insufficient funds in the repayment account.
• The repayment account will be put into a debit balance (if the user has allowed overdraft) and the schedules for the components liquidated to the extent of the debit balance that the user has allowed for the account. The user can liquidate beyond the allowed debit balance for an account after overriding a warning message. This override will be recorded for audit trail purposes. Debit interest, as specified for the type of account (current or savings); is applied on the debit balance.
• If the repayment account has not been defined with an overdraft, the liquidation will not be processed.
• If the user specify manual liquidation for deals involving the product, then liquidation must be done manually, through the Manual Liquidation screen.

Liquidate Back Valued Schedules During Initiation

Indicate whether for a backdated deal that has schedules before today’s date; the schedules have to be liquidated when the deal is initiated. A backdated deal is one, which has an initiation date, which falls beforetoday’s date.

Liquidate Back Valued Schedules During Initiation

The user has to specify whether the payment method for the main interest is to be bearing, discounted, or true discounted. This cannot be changed at the time of processing a deal.

When the Repayment Schedule Date is a Holiday

The user has specified that repayment schedules must be generated automatically once the user indicate the frequency, number and the date of the first repayment. When the system computes the repayment dates based on these values, there is a chance that one or more schedules fall due on holiday. In such a case, the user has two choices:

• Ignore the holiday and retain the scheduled due date or
• Move it either backwards or forward, by specifying so. If the user specify that holidays are to be ignored, the scheduled dates will be fixed without taking the holidays into account. In such a case, if a scheduled date falls on a holiday, the processing of such a schedule is determined by your holiday handling specifications for automatic processes, in the Branch Parameters screen.
• If the user has specified that processing has to be done on the previous working day for automatic events right up to the day before the next working day the schedule falling on the holiday will be liquidated during end-of-day processing on the previous working day.
• If the user has specified that processing has to be done only up to the System Date, then only the events scheduled for the System Date will be processed. The events of the holiday are processed on the next working day during beginning -of-day processing.

Move Schedules Forward or Backward

A scheduled date falls on a holiday, and the user has not specified that holidays are to be ignored at the time of schedule definition. In such a case, the user must indicate the movement of the scheduled date forward or backwards to the next working day, or the previous working day, respectively. Since the scheduled date itself is moved to a working day, the payment is processed on the due date.

Move Schedule Dates Across the Month

If the user has chosen to move a schedule falling due on holiday to the next working day, or on the previous working day, and it crosses over into another month, the scheduled date is moved only if the user indicates. If not, the scheduled date will be kept in the same month.

Specify the Holiday Currency

The user can specify the country of the deal currency for which the holiday table must be checked before drawing the payment schedules related to the deal. In case a schedule falls on a holiday, and the user has specified that the schedule is moved forward or backwards, the movement happens according to the holidays in this country. By default, the currency to be checked is the deal currency. If a currency other than this is specified, the holiday table will be checked for both the currencies.

When the Repayment Schedule Date is a Holiday

The user can specify the Financial center of the deal for which the holiday table must be checked before drawing the payment schedules related to the deal. In case a schedule falls on a holiday, and the user has specified that the schedule is moved forward or backwards, the movement happens according to the holidays in this Financial center.

Cascade Schedules

The question of cascading schedules arises only if:

• The user has specified that a schedule falling due on holiday has to be moved forward or backwards
• The schedule has been defined with a definite frequency
• If the user has indicated that schedules must be cascaded, the scheduled date for the next payable schedule will depend on how the scheduled date was moved for a holiday.

The following example illustrates how this concept of cascading schedules functions:

• When the user cascade schedules, the last schedule (at maturity), however, will be liquidated on the original maturity date and will not be changed like the interim schedules. Hence, for this particular schedule, the interest calculation days may vary from those of previous schedules