5. Processing Repayments

When you make a Murabaha Money Market deal, you also decide on the terms of the repayment of the placement or borrowing. You may have your own repayment schemes; for example, you may prefer monthly repayments of profit or the repayment of the principal on maturity, and so on. Or, you 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 FLEXCUBE, you can customize your repayment schedules for a Murabaha Money Market product. The same schedules will, by default, apply to the deals involving the product. However, when processing a specific deal, you can change the repayment schedule, which it inherits, from the product it involves.

This chapter contains the following sections:

5.1 Defining Schedules for a Product

You can define repayment schedules for the profit or profit type of ICCF components like a tenor based charge or fee and the principal of a Murabaha Money Market deal, while defining a product.

The attributes of the schedules for a product are defined through the ‘Murabaha Money Market - Preferences’ screen. The following are the attributes of a repayment schedule:

However, for a deal, you can have:

A discussion on these attributes follows in this chapter.

The automatic contract update function executed as part of the MMM Batch Daily routine automatically liquidates schedules that you have marked for auto liquidation. If schedules are marked for manual liquidation, you will have to liquidate them through the contract schedule payments function.

Once you specify the attributes of schedules in the ‘Murabaha Money Market - Preferences’ screen, the default schedules, which you want applied to the deals involving the product, are specified through the Product Schedules screen.

At the time of deal processing you can change the schedules which have been inherited by the deal, to suit your needs.

If the profit specified is an amount and not a rate (Special type of Profit), you should enter this amount for the profit component. You should specify the number of schedules for the component (interim schedules and maturity schedule). You can give the Start Date, Frequency and Unit afresh 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 will be liqui­dated on maturity.

Since for a Murabaha money market deal, the principal is always repaid at Maturity, you need not define a schedule. By default, the principal will have a bullet schedule.

5.2 Product Schedule Preferences

This section contains the following topics:

5.2.1 Setting Product Schedule Preferences

You should define the attributes of the schedules for a product through the Product Preferences screen. To invoke the Product Preferences Screen, click ‘Preference’ button in the ‘Product Definition’ screen.

5.2.2 Specifying the Mode of Liquidation

Components of a deal can be liquidated automatically or manually. In the Product Preferences screen you should indicate whether the mode of liquidation of repayment schedules is to be automatic.

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

Now, consider the following situation:

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

If a borrowing has been defined for verification of funds before automatic liquidation (through the Contract On-line Preferences screen), those components whose schedule dates fall on the same day will be liquidated in the order you have 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 you specify. This will be reported in the Exception Report generated at the end of every day, automatically (by the Automatic Contract Update function).

If you have not specified that the funds be verified, and there are insufficient funds in the repayment account:

If you specify manual liquidation for deals involving the product, then you will have to do the liquidation manually, through the Manual Liquidation screen.

5.2.3 Liquidating Back Valued Schedules during Initiation

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

For example, seals can be initiated as of today, as of a date in the future or as of a date in the past.

Suppose that today’s date is October 15. You initiate today a borrowing of 15,000 USD with the Value Date (the date on which the deal comes into effect) as September 15. The system will pass accounting entries for initiation as of September 15.

But if there had been a profit payment schedule for September 30, for 500 USD, then if you specify that back values schedules should be liquidated, you can make the system pass accounting entries to liquidate this schedule also when the borrowing is initiated.

If you specify that back dated schedules are not to be liquidated then only accrual entries will be passed till today.

NoteT

he entries associated with each event (initiation and liquidation in this case) will be passed only if they have been defined for the product. Further, the accounts used will be the ones defined for each entry.

5.2.4 Specifying the Payment Method

You have to specify whether the payment method for the main profit is to be bearing, discounted, or true discounted. This cannot be changed at the time of processing a deal.

Bearing

The profit is liquidated on schedule payment date(s).

Discounted

In this profit payment method, the profit is deducted at the time of initiating the deal.

True Discounted

In this profit payment method, the profit is calculated on the principal in a manner differing slightly from the ‘Discounted’ method. The profit rate is applied on the Principal instead of the Nominal, as it is done in the ‘Discounted’ method.

To go to the ‘Product Default Schedules’ screen, click on the ‘Schedules’ button in the Product Preferences screen.

5.2.5 Indicating the Schedule Type

You can define schedules for each component for the product through the ‘Product Default Schedules’ screen. This involves specifying the reference date, the frequency, the month and date for each component. You can invoke the screen by clicking on the ‘Schedules’ button in the Product Preferences screen.

5.3 Features of the Product Default Schedules Screen

When creating a product in the ‘Product Default Schedules’ screen, you can define schedules for all deal components. This involves specifying the reference date, the month and the date for each component. All deals, involving the product, will acquire these attributes.

This section contains the following topics:

5.3.1 Specifying the Component

You can define different repayment schedules for the different components according to your needs. First of all, you should specify the component for which you want to define the schedule. All components − the principal and any other component depending upon your ICCF definition for the deal − are available in the form of an option list. You will have to define schedules for each of them.

When defining repayment schedules for specific deals, the amounts for components like profit, commission, and fee will be calculated by the system automatically, depending on the repayment date and amount of the principal. However, for deals with special profit, you will also have to provide the profit amount.

5.3.2 Setting the Reference Date

You should indicate in this screen whether the dates of repayment schedules should be calculated based on the Value Date (date of initiation of the deal) of the deal involving the product, or a Calendar Date.

If you specify that the Reference is the Value Date (date of initiation of the finance), the dates for schedule repayments will be based on this date and the Frequency.

If the Reference is specified as the Calendar Date, the dates for schedule repayments will be based on the Start Date (specified by you), the Month and the Frequency. The following example illustrates this concept.

If Reference is set to Value Date (deal initiation date), you need to specify only the Frequency (monthly, quarterly and so on) and the unit of frequency (if you specify the frequency as weekly and the unit as 1, it means once a week). The system will set the schedule according to the Frequency and Unit of Frequency you have specified, beginning on the Value Date.

5.3.3 Specifying the Frequency of Schedules

For a periodic schedule, you can indicate the frequency of repayment for each component. This could be:

By default, the frequency will be Bullet, meaning all the repayments will be made on maturity. If the frequency is defined as Bullet, you cannot enter a value into the subsequent fields.

5.3.4 Specifying the Frequency Unit

You can specify the number of units for the frequency you have set for a particular component.

5.3.5 Specifying the Start Date

If you have set the Reference as Calendar Date, and the frequency as weekly, quarterly, half-yearly or annual, indicate the month in which the first schedule falls due.

If you have set the Reference as Calendar Date, you should indicate the date on which the schedule should fall due. Specify 31 to indicate that the schedule should fall due on the last day of the month (that is, 31 for months with 31 days, 30 for months with 30 days and 28 or 29, for February).

The schedule repayment dates will be computed using the Frequency, (Start) Month and the (Start) Date.

A schedule date:

5.4 Defining Repayment Schedules

The payment schedules defined for a Murabaha product will apply to all deals involving the product. When you process a deal in the Contract Schedules screen, the details defined for the product (which the deal involves) will be displayed. You can change the schedules that a deal acquires when processing it in the Contract Schedules screen.

You can redo the schedules defined for the product, by clicking ’Schedules’ button in this screen. The schedules that have not been liquidated and which fall due on the current system date, or later than the current system date, will be erased and you can go on to define the new repayment schedules.

The attributes of the schedules inherited from the product can be changed for a deal through the Contract Preferences screen.

5.5 Setting Deal Schedule Preferences

Schedule preferences are the attributes of the repayment schedules defined for the deal.

The attributes that have been defined for the product are inherited by all deals involving the product. Some of these attributes can be changed. They are:

Through a set of fields in the Contract Preferences screen, you can specify the following additional set of schedule-related attributes for the deal:

The Contract On-line screens are available under ‘Islamic Money Market’ in the Application Browser.

5.5.0.1 Specifying the Contract Preferences

Although schedules are inherited by a deal from the product, through the Contract Preferences screen, you can to define your own schedules for a deal.

A schedule date:

5.5.1 Liquidating Back Valued Schedules

If you have specified, while defining the product, that a back-dated deal with repayment schedules prior to today’s date, the schedules have to be liquidated when the deal is initiated, the same will apply to the deal you are entering.

However, through this screen, you can choose not to liquidate back valued schedules.

5.5.1.1 When the Repayment Schedule Date is a Holiday

You have specified that repayment schedules should be generated automatically once you indicate the frequency, number and the date of 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 a holiday. In such a case, you have two choices:

If you specify that holidays are to be ignored, the schedule dates will be fixed without taking the holidays into account. In such a case, if a schedule 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:

For example, a daily profit repayment schedule date for Cavillieri and Barrett Finance Corporation’s borrowing of USD 100,000 (for one week at 16% profit) falls on October 31, a holiday.

If you have said Ignore Holidays by clicking this field, the schedule date will remain on October 31 when the schedules are fixed. The processing of this is determined by your holiday handling specifications in the Branch Parameters screen:

If you specified that processing has to be done today (on System date) for automatic events up to the day before the next working day, then, on October 30 itself, the schedule of October 31 will be liquidated during the EOD run of the Automatic Contract Update function.

If you have specified that processing has to be done only up to the System Date, then, on October 30, only the events scheduled for that date will be processed. This means that since the schedule date is October 31, which is a holiday, the schedule will be processed on 1 November (the next working day), during the BOD run of the Automatic Contract Update function.

5.5.1.2 Moving Schedules Forward or Backward

A schedule date falls on a holiday and you have not specified that holidays are to be ignored at the time of schedule definition. In such a case, you should indicate the movement of the schedule date forward or backward to the next working day, or the previous working day, respectively. Since the schedule date itself is moved to a working day, the payment will be processed on the day it falls due, as of that day.

For example, for a borrowing, you have defined weekly schedules falling due on the following dates:

April 7 is a holiday. You have the following options in fixing the date for that schedule:

You can ignore the holiday. The schedule date will still be on April 7, despite the holiday. The liquidation of the schedule will be done as per your specifications in the Branch Parameters screen.

You can move the schedule date forward to the next working day, which happens to be April 8. The schedule will be liquidated during Beginning of Day (BOD) processes on this date, as it is a working day. The across-the-month movement discussed subsequently comes into the picture here.

You can move the schedule date backward. The schedule date will be April 6, the last working day before the holiday. The schedule will be liquidated during BOD processes on this date, as it is a working day.

5.5.1.3 Moving Schedule Dates across the Month

If you have chosen to move a schedule falling due on a holiday to the next working day, or on the previous working day, and it crosses over into another month, the schedule date will be moved only if you so indicate. If not, the schedule date will be kept in the same month.

5.5.1.4 Specifying the Holiday Currency

You can specify the country of the deal currency for which the holiday table should be checked before drawing the payment schedules related to the deal. In case a schedule falls on a holiday and you have specified that the schedule be moved forward or backward, 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.

5.5.1.5 Specifying the Mode of Liquidation

When creating a product, you specify the mode of liquidation - whether automatic or manual. Your specifications will apply to all deals involving the product.

Through the Contract Preferences screen, you can change the mode of liquidation for the deal that you are processing, from automatic to manual, or vice-versa.

5.5.1.6 Cascading Schedules

The question of cascading schedules arises only if:

If you have indicated that schedules should be cascaded, the schedule date for the next payable schedule will depend on how the schedule date was moved for a holiday. The following example illustrates how this concept of cascading schedules functions:

When you 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 profit calculation days may vary from those of previous schedules, as the case may be.

5.5.1.7 Ascertaining the Availability of Funds

When the customer’s repayment account is debited automatically by the system, you can specify that the availability of funds for liquidation of the various components of a borrowing has to be ascertained before the liquidation is done.

This feature is of significance when:

If the availability of funds has to be ascertained:

If availability of funds need not be ascertained and the liquidation results in the account going into a debit balance:

Borrowings with payments, which have not been processed, due to non-availability of funds, will appear in the Exception Report generated by the Automatic Contract Update function for the day.

Note

For the final principal payment on maturity, the availability of funds in the payment account will always be verified.

5.6 Invoking the Contract Schedules Screen

When you are in the Contract On-line screens, you will see sections in the screen saying Preferences, Schedules and Rollover and so on. When you click on any of these, the respective section, the screen will be displayed. To go to the Contract Schedules screen, click on ‘Schedules’.

5.7 Revision and Repayment Schedules

In the Contract Schedules screen, you can define two types of schedules:

This section contains the following topics:

5.7.1 Profit Rate Revision Schedule

A Floating Rate Table - that contains the market rates for the day − is maintained in the ICCF sub-system so that the latest rates can be applied to deals.

The market rates vary on a daily basis and are maintained in this table. The rates can be applied either every time they change or at periodic intervals. Usually, for Murabaha Money Market deals, floating rates are applied, that is, the latest market rate is applied (see the section on Specifying Rate Code Usage in the chapter ‘Processing Profit, Charge and Fee’). You can also apply these rates on a periodic basis so that you are in tune with the market rates (as opposed to fixed profit rates which remain the same for the entire period of the deal), and at the same time you do not have to apply the market rates on a daily basis.

You can specify whether the latest market rates have to be applied every time they change, or if they have to be applied periodically, by defining an attribute called the Rate Code Usage through the ‘Product ICCF Details’ screen for a floating profit type. If you specify ‘auto’ rate code usage, all the rate changes made during the liquidation or accrual period will be considered. If you specify ‘periodic’ rate code usage, the rates will be periodically refreshed and the rates as of a specific frequency, or date, will be applied.

For a deal that has been defined with Periodic Profit that has to be applied at periodic intervals, you can specify the following:

5.7.2 Specifying the Rate Revision Frequency

In the IMM Contract Schedules screen, select the component, for which the Rate Revision frequency has to be, defined (say PROFIT1). Check the ‘Rev box’ (Revision Box) to indicate that it is a rate revision schedule. Next, enter your specifications in the frequency (it could be daily, weekly, and so on), the number, and unit fields. Also give the Start Date on which the first revision has to take place.

For example, if you specify the frequency, as weekly, the revision will take place every week beginning on the Start Date that you have specified.

5.7.2.1 Rate Revision Dates

Revision frequency has to be defined (say PROFIT1). Check the ‘Rev box’ (Revision box) to indicate that it is a rate revision schedule.

Then, instead of specifying the other schedule details like the frequency, the number and unit, indicate the date in the Start Date field. The rate revision will be done on that date.

For example, a borrowing of USD 200,000 by Cavillieri and Barrett Finance Corporation has been initiated on December 10 and is to be repaid at Maturity on December 16. It has been defined with rate revisions and they are to be performed on the dates December 12, December 14 and December 16.

Select the component, INT1, indicate rate revision by checking the Rev box and give the date in the Start Date field as December 12. Then select the same component, INT1 and specify the date as December 14. Repeat the process for the same component for December 16.

The rates applicable on the specified dates will be applied on the borrowing at the time of calculating profit.

5.7.2.2 Repayment Schedule

For a repayment schedule, the amount of repayment needs to be specified only for the Principal. The profit, commission and fee components will be calculated by the system automatically, depending on the repayment date and amount of the principal. However, if the profit type is Special, you should specify the profit amount. Similarly, if the deal has been defined with any other fixed amount component, you will have to enter an amount for this.

The repayment schedules for the components of the deal will be those defined for the product it involves. You can change the schedules for a deal when processing it.

5.7.2.3 Profit Repayment Schedules as Different from Rate Revision Schedules

For a deal on which floating profit has to be applied at periodic intervals, you may have to define both the following:

The following example shows how this is achieved.

For example, you have a deal where for the component profit; you have to define a profit rate revision schedule for revisions every week as well as a fortnightly profit repayment schedule. The Start Date of the deal is October 1, 1997 and the End Date is October 31, 1997.

The deal has been defined with a periodic rate and the rates in the floating rate table change in the following manner:

Date

Rate

October 1, 1997

12

October 12, 1997

11.5

October 25, 1997

11

November 15, 1997

12

November 30, 1997

12.5

Defining a frequency based rate revision schedule

To define a schedule with periodic rate code usage, through the Contract Schedules screen, mark the component as a revision schedule (by checking the Rev box) and specify the component, say PROFIT, from the picklist. Give the frequency at which the profit rate has to be refreshed, say weekly. Give the Start Date, say October 8. The first revision will happen on this day, and every week from then on. Save the inputs.

Defining a date based rate revision schedule

If you were to define specific dates − October 7, October 15 and October 23 − for the rate revision to happen, then, through the Contract Schedules screen, mark the component as a revision schedule (by checking the Rev box) and specify the component, say PROFIT, from the picklist. Specify the date on which the rate revision is to be done, in the Start Date field, as October 7. Similarly, define the other dates, but by picking up the same component PROFIT from the picklist each time.

Defining a repayment schedule for the same component

Now to define a repayment schedule for the same component, PROFIT, do not check the Rev box. Choose the same component profit from the picklist. Now draw up a repayment schedule for this component. Give a value in the Start Date field, say October 15, 1997. The first profit liquidation will be done on this date.

In the frequency field enter ‘monthly’ and in the unit field specify ‘2’. This means the profit repayments will be done every fortnight beginning October 15.

That is, for a deal defined with frequency-based periodic rates, the rates prevailing on the refresh dates will be used for accruals and liquidation. In the deal we are discussing, with the refresh frequency defined as weekly and the Start Date as October 15, the rate applied for the profit liquidation on October 15 will be as follows:

From

To

Rate

October 1

October 8

12

October 9

October 15

11.5

For a deal with Periodic rate code usage (date based), the rates prevailing on the specific refresh dates will be used for accruals and liquidation. Shown below are the rates applicable on the specified revision dates.

Revision Date

Rate Applicable

October 7

12

October 15

11.5

October 23

11.5

In the deal we are discussing, the rates applied for the profit liquidation on October 15 will be as follows:

From

To

Rate

October 1

October 7

12

October 8

October 14

12

October 15

 

11.5

5.7.2.4 Specifying Schedules for a Deal with a Fixed Profit Rate

For components of deals with a fixed rate of profit, you will not have to define profit rate revision schedules. That is, you will have to keep the ‘Rev’ box unchecked while you define the schedules for each component.

The schedules defined for each component at the time of product definition apply to the deal. However, you can change the frequency, number, unit and the start date to suit the specific requirements of the deal that you are processing. You will have to specify the amount only if the schedule being defined involves the principal component or a special profit. But in the case of Murabaha Money Market deals, the principal is usually repaid at Maturity and rarely has repayment schedules.

The amount for profit, commission and fee components (if they are rates) will be calculated by the system automatically, depending on the start date, number of schedules, frequency and repayment amount of the principal. However, an amount can be entered here for profit only if the Profit Calculation Method has been defined as Special. The fee amount can be input only if it is a flat fee.

For finance, you can define repayment schedules that:

Now, if you want to define schedules that fall due at regular intervals, all you have to do is, for a component, specify the start date, the frequency, the unit and the principal amount. Since you would have already registered the Maturity Date of the finance (for a fixed maturity type), in the Contract Details screen, the schedules would automatically be spread out into equal intervals.

Based on this information, the system calculates the dates on which the repayments or profit revisions fall due.

For example, consider the following details for a deal:

A borrowing of USD 100,000 comes into effect on January 1, 1998 and matures on October 31, 1998. Suppose you want to have 10 monthly schedules for principal repayment, you have to specify the Start Date as January 31, 1998, the frequency as monthly, the unit as 1, and the principal amount as 10,000. The schedules would be spread out over 10 months and would fall due every month-end.

Now, you have a 15 month borrowing beginning January 1, 1998 and ending March 31, 1999. Suppose, you want to define four quarterly schedules and three monthly schedules for profit repayment of this finance, these are irregular schedules and the ‘Number’ field assumes importance here.

Here, for the component profit, you have to give the Start Date as March 31, 1998, the frequency as quarterly and the unit as 1. The number of such schedules will be four. Hence your quarterly schedule dates will be calculated as:

You have to specify for the same component − the profit - the Start date as January 31, 1999, the frequency as monthly, the unit as 1, and the number as ‘3’, if you want to fix three monthly repayment schedules after December 31, 1998. They will be calculated as falling due on:

5.8 Redefining Schedules

Repayments that are scheduled for a date later than today can be redefined. This redefinition can be done even after the deal has come into effect and a few schedules have been liquidated.

However, schedules with a date earlier than today’s date that are yet to be liquidated cannot be rescheduled. You have to liquidate them through the Manual Liquidation function. Aging analysis and compensation processing will be done on such overdue schedules if they are borrowings.

The redefinition of schedules will be done automatically on the following occasions:

There may be some situations wherein you would want to redefine the schedules, that is; you may want to change the payment dates or amounts. In such cases, you can change the schedules by invoking the Contract Input screen and going to the Schedule Redefinition screen by clicking ‘Revision Details’ button. If you click the redefinition button on the schedules screen, all the schedules with today’s date or a date in the future will be erased and you will be allowed to enter a new set of schedules.

To redefine a schedule for only one component, highlight the schedule make the changes and click add button. If the schedules have already been authorized then you will have to make the changes through the Modify function.

After making the changes, you can save the redefined schedules by clicking add button. To delete a schedule (before authorization) click delete button.

5.8.1 Authorizing a Redefined Schedule

A redefined schedule has to be authorized before it can be used.

5.9 Viewing Schedule Details

When you click ’Schedules’ tab on the ‘Contract On-line Schedule Definition’ screen, you will see the ‘Payment Schedule Details’ screen. Here you can view the details of the schedules for a particular deal.

In this screen you can see the following details for the component:

5.10 Viewing Revision Schedule Details

When you click ’Revision Details’ button in the Contract On-line Schedule Definition screen, you will see the ‘Revision Schedule Details’ screen. Here you can view the details of the revision schedules for a particular deal.

In this screen you can see the following details for the component:

5.11 Making Manual Payments

The various components in a deal can be liquidated either automatically or manually. The mode of liquidation of each component is specified at the time of defining a product and then again, at the time of deal processing. An automatic liquidation is done on schedule payment days by the Automatic Contract Update program.

Even if you have defined a deal with automatic liquidation, you can liquidate it manually a day before the schedule date. However, payment will not be allowed if the Rollover Instruction Status for the contract is ‘Complete’.

5.12 Invoking the Contract Schedule Payments Screen

You can invoke ‘Islamic Money Market Payment Input’ screen by typing ‘MCDPAMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. The screen is displayed below.

5.13 Features of the Contract Schedule Payments Screen

You can do the following operations the manual payments function:

The manual payments made through this function can be:

The value date you have entered will be used for all the entries generated by the system.

5.13.1 Input of Manual Payments

Once you enter the deal reference number in the ‘Murabaha Money Market Schedule Payment’ screen, you will see the following details displayed on the screen:

The Value Date here is the date on which the liquidation entries will be passed. When you enter a Value Date in this screen, if there are any payments due on that date, they will be displayed and you can liquidate them.

If there are no schedules due on that date, the schedule becomes a prepayment. But this is only if the Value Date is not a back valued date. You can have a back valued date but it cannot be earlier than the last schedule that was due. (You can also liquidate back valued schedules by entering a Limit amount).

If the Value Date is today or a date in the future, the prepayment is processed.

The Payment Limit Date or Amount of the payment should be given at the time of payment. If you have given a payment limit date, the system shows all the components, which are due till the limit date. If you have given the amount limit in the Amount field, it shows all the schedules for the limit amount.

For example, for a particular deal, there are two profit schedules pending on Cavillieri and Barrett Finance Corporation’s borrowing − one on October 1, 1997 and the other on October 15, 1997. The third schedule is due on October 30, 1997.

If you give the Limit date as October 25, (today’s date) the system will show you the amounts due for the profit component on the schedule dates of 1 October, and October 15.

If you give the limit date as November 1, 1997, the system will show you the schedules falling on October 1, October 15 and October 30, and you can liquidate them accordingly.

Since today’s date is October 25, if you liquidate the schedule due on October 30, it amounts to a pre-payment. You can charge a prepayment compensation rate or an amount, which you enter in this screen.

Note

While the Prepayment Limit Date is used to pick up the schedules pending as of that date, the Value Date is taken into account by the system for passing accounting entries.

Alternatively, the system picks up a schedule according to the amount being paid. You will see the next schedule, which is due, within the limit of this amount. If the amount being paid is more than the total amount payable for the next schedule, the next schedule will be considered. The total amount due for these schedules is displayed.

For example, consider the following details:

System date: June 1:

Payment schedules for a deal are as follows:

Sch Date

June 30

July 31

August 30

Principal

1000

1000

1000

Profit

100

100

100

Commission

50

50

50

Fee

20

20

20

For the above schedule, if a prepayment is made as of an amount, the system validates it in the following manner:

Suppose the amount paid is USD 1000. The next available schedule is as of June 30 and the total amount due is USD 1170. This schedule will be picked up for processing and you can make the payments.

If the amount paid is USD 1170, which is equal to the schedule amount of June 30, again only the schedule for June 30 will be picked up for processing.

If the amount paid is USD 1270, which is more than the amount due for the schedule of June 30, the schedule of July 31 will be picked up by the system for processing. After completely liquidating the schedule of June 30, you can liquidate the profit schedule as of July 31, which is the next schedule.

If the amount paid is USD 1300, the schedule for July 31 will be picked up for processing. The complete schedule of June 30 can be liquidated along with the profit component of July31. The remaining USD 30 can be used to partially liquidate the commission component for July 31.

You have to enter in the Amount Paid field the actual amount being paid. This amount can either be allocated to the various components manually, by entering the break up of the amount against the various components, or automatically by clicking the ‘Allocate’ button.

The automatic allocation is done based on the Liquidation order you have defined for the product. If you have not specified the order of liquidation for the principal and the profit type of components, the amount will be allocated for liquidation in the following order:

Note

If a payment that covers both past and future schedules is made, the system will force you to pay out the past schedules before the future schedules are paid.

If an ICCF component is based on the outstanding principal you will not be able to make a payment where the amount is more than what is due for the component as of the system date.

5.14 Navigating to Other Screens

In the Contract Schedule payment screen, you have a set of icons using which you can use as following:

Buttons

Descriptions

Settlement

Click to go to the ‘Settlement Message Details’ screen

Advices

Click to see the ‘Advices’ screen. You can suppress advices using this screen.

Events

Click to view the ‘Events ‘screen

Tax

Click to see the ‘Tax Details’ screen

Breakup

Click to view the ‘Schedule Breakup’ screen

5.15 Paying Tax

When there are taxes charged on the profit, principal and so on, the payment of the component will always include the corresponding tax amount. If the payment does not include the full amount due, the proportional tax amount must be liquidated. You should input the total amount to be applied to the component. The system then calculates the corresponding tax amount (based on the tax rate) and distributes the amount paid between the component and the tax.

Total tax is always calculated on the full schedule. Therefore, if there is a rounding difference, it will be adjusted in the last liquidation.

5.16 Settlements Screen Details

5.16.1 Maintaining the Settlements Screen

When the deal and the accounts for payment are in different currencies, you may enter the Foreign Exchange rate for conversion in the Settlements screen. If the customer account for a component was expressly not defined at the time of deal input, you will have to specify an account at the time of payment, through the Settlements screen.

The payment accounts can also be changed for the various components at the time of payment. The new payment accounts will only be used for that particular session of the manual payment function.

For example, you have named an account A1 for a particular component at the time of deal input, but during manual payment you wish to change it to A2. Once this particular payment is carried out, the system will show the default account as A1 for that component. A2 will be used only for the session that you have specified for manual payment.

To invoke the Settlements service from the payments function, click ‘Settlement’ button in the ‘Contract Schedule Payments’ screen.

In this screen,

5.16.2 Furnishing the ERI Value in Messages

SWIFT messages (MT 100/MT 202) generated towards settlement can furnish the value of the settlement amount in both the settlement account currency, and an ‘ERI’ currency. If you opt to furnish the ERI value of the amount, you have to enter the following in the Settlement Message Details screen:

The system defaults to the ERI currency specified for the customer and currency combination. You can change the default ERI currency. The ERI amount that you specify will be validated against the Tolerance Limit specified for the ERI currency.

For example, on January 1, 1999, eleven countries that are part of the European Union embarked on the first phase of economic integration, called the ‘Economic and Monetary Union’ (EMU). The EMU ushered in a new, single European currency: the Euro (EUR). You can handle the Euro, in Oracle FLEXCUBE, by capturing information such as the ERI information in this screen.

For further details on the manner in which Oracle FLEXCUBE handles the Euro, please refer to the chapter ‘Handling the Euro’ in the user manual of the Core Services module.

5.16.3 Suppressing Messages

Settlement messages, defined for components that fall due, will be generated automatically when you execute the Settlement Generation function at the end of day. You can suppress the generation of the settlement message, defined for a component, by clearing the check-box in the ‘Gen Message’ field in the Contract ‘Settlement Message Details’ screen.

5.16.4 Viewing the Schedule Breakup Details

In the Schedule Payments screen, you will see a row of icons. Click ’BreakUp’ to view the Schedule Breakup screen.

You will see the following in this screen:

5.16.5 Schedule Payment Component

In this screen you can see the schedules being paid on account of this particular payment for which you are doing manual liquidation. The component getting paid is displayed.

5.16.6 Schedule Payment Due Date

The due date of the component being liquidated is displayed.

For example, consider the borrowing by Cavillieri and Barrett Finance Corporation. A Profit payment of USD 10,000 was due on October 1, 1997. Another payment of USD 15000 was due on October 15, 1997.

Now, the bank repays USD 12500 on October 20, 1997. Since there was no schedule due on this date, you decide to do a manual payment.

Now, since you have indicated the amount paid as USD 12500 in an earlier field in this screen, the system will display against the October 1 schedule as USD 10000 in the Amount Paid column.

Against the October 15 schedule, you the system will display the amount as USD 2500 in this column. You can also see the Amounts, which are due on a particular date.

Component

Due Date

Basis Amount

Amount Paid

Profit

October 1

10000

10000

 

October 15

15000

2500

5.16.7 Basis Amount

The amount outstanding for the component being liquidated is displayed here.

5.16.8 Schedule payment Amount Paid

You can see here the amount paid for the component as of the value date (the current system date).

5.17 Deleting Manual Payments

Payments made using the manual payments function can be deleted before the payment is authorized.

All the entries passed during the payment will also be deleted. All the schedules will be restored to the original status. In short, the prepayment status of the deal will be restored.

From the Application toolbar, choose Delete or click ‘Delete’ icon in the toolbar. You will be prompted to confirm the deletion. Once you confirm it, all the entries that have been saved but not authorized, will be deleted.

5.18 Reversing Manual Payments

You can reverse authorized manual payments. The system makes the following validations before reversing a payment:

In the contract view screen, to reverse a payment, you have to invoke the manual payments function and specify the contract reference number. You have to enter the ‘Amount Paid’. You have to click on ‘Reverse’ in the Processing sub-menu of the Application toolbar.

If the payment involves accounts in different currencies, the conversion rates to be used for reversal will be picked up from the deal as specified during contract input.

If a new payment account was specified for a component during the input of the payment, the reversal will be done to the new account. If the new account is in a currency different from that of the deal and a conversion rate was specified, the rate from the payments function will be used for the reversal.

The reversal of a payment may sometimes entail a change in the status of a borrowing. If the borrowing is set for automatic status change, this change will be made by the system automatically.

Automatic payments made by the Automatic Contract Update program can also be reversed through the manual payments function.

Reversal of payment will not be allowed if the Rollover Instruction Status of the contract is ‘Complete’.

5.19 Authorizing Manual Payments

You have to invoke this function from the Application Browser. You should enter the Reference number, the value date of the payment and the amount paid. The payment details are displayed along with the overrides and authorization is sought. If you choose not to authorize the manual payment, the authorization screen is dismissed.