11. Automatic Processing

his chapter contains the following section:

11.1 Automatic Events in the Life Cycle of a Loan

The following are the various events in the life cycle of a loan that could be carried out automatically:

The Automatic Contract Update function should be executed at least twice during the day:

As part of pre-EOTI programs executed during TI (Transaction Input), before marking EOTI (End of Transaction Input) for the day, the following processing is done during Pre-EOTI:

11.2 Specifying Branch Parameters

A set of rules that govern the loans that you disburse in a particular branch (of your branch) are defined through the Branch Parameters screen.

You can invoke the ‘Branch Parameters Detail’ screen by typing ‘OLDBRMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

 

This section contains the following topics:

11.2.1 Processing for Holidays

Automatic processing like accruals, scheduled repayment, generation of billing advices or delinquency notices, and so on, falling due on a holiday is processed either on the last working day before the holiday, or on the first working day after it. The definition for this should be as follows:

11.2.1.1 Process till System Date

If you specify that processing of automatic events should be done upto the System Date, automatic events scheduled till (inclusive of) the current system date are processed.

Example

Assume today is 20 October 1997, and 21 October 1997 and 22 October 1997 are holidays. If you click this field, during the Automatic Batch Update function run only the events scheduled for 20 October 1997 are processed.

The events scheduled for the holidays, that is, 21 October 1997 and 22 October 1997 are processed during the Automatic Contract Update function run during beginning of day operations on 23 October 1997.

11.2.1.2 Process till next working day - 1

This specification means that events scheduled for a holiday should be processed on the last working day before the holiday.

If you indicate this, all the events that fall on a day between the current system date and the next working day are processed.

Example

Assume that today is 20 October 1997, and 21 October 1997 and 22 October 1997 are holidays. If you click this field, during the Automatic Batch Update function run at EOD on 20th October 1997, all the events scheduled that are scheduled for 21st and 22nd October 1997 are also be processed.

11.2.2 Specifying the Tax Basis

On a loan, you may have to pay tax on interest you earn. The tax can be paid on the basis of the following:

For your branch, you can specify the amount on which tax has to be applied, in Branch Parameters screen.

Example

You have the following tax slab for levying tax on interest earned:

Now, you have a loan, which starts on 1 January 1998 and ends on 31 March 1998. It has a fortnightly interest liquidation schedule and at each schedule, USD 200 is liquidated.

Tax on schedule amount

If you indicate that the tax basis is to be the schedule amount, every time the schedule is liquidated, you have to pay 3% tax on USD 200, the schedule amount (USD 200 falls into the first slab). USD 6 have to be paid every time an interest schedule of USD 200 is liquidated.

Tax on liquidated amount

If you indicate that the tax basis is to be the liquidated amount, then the tax is calculated on USD 1,200, the total interest that is liquidated for the loan at Maturity. This falls into the second slab and hence 4% is applied on USD 1,200. This works out to USD 48, and is spread out over the six schedules. That is, you will have to pay USD 8, as tax, every time an interest schedule of USD 200 is liquidated.

11.2.3 Setting the Accrual Level

To recall, at the time of creating a product, you specify

A loan inherits the accrual frequency defined for the product associated with it.

Since the accounts (the accrual account and the income account) are defined for a product, the accrual entries for all loans involving the product are passed to the same accounts.

These entries can be passed in two ways:

The idea of generating a single entry for all loans involving a product is to reduce the number of entries and thus, the processing time. The details of entries passed for each loan is available in the Accrual Control Journal, a report that should be generated after the accruals have been made.

Whether interest accrual entries are passed as a single consolidated entry for a product, or as an individual entry for each loan, should be specified for a branch.

Note

This specification is applicable only for automatic periodic accrual entries. When there is an accrual necessitated by a payment or a change in the terms of a loan, the entries will be for the specific loan affected by the change.

Example

You have created a product for ‘Short Term Loans with Individuals’. The product has the following characteristics:

The accounting entries during interest accrual (defined for the event ACCR) are as follows:

Accounting RoleAccounting HeadAmount ItemDr/Cr

ContractTenorInterest

Contract 1 3 months USD 300

The accounts into which the accrual entries should be passed for each of these contracts are the same, as they are linked to the same product.

Accrual entries level - Product

If you indicate that the automatic interest accrual process should pass accrual entries at the product level, a single accrual entry will be passed for all the loans.

Accrual entries level - Contract

If you indicate that the automatic interest accrual process should pass accrual entries at the contract level, three accounting entries for the loans are passed, for each loan.

11.2.4 Setting the Residual Amount for Force Liquidation

The value that you specify (as the residual amount) indicates the limit for the residual balance when a loan with zero principal balance but with other outstanding components can be marked off as liquidated.

The residual amount (interest or fees) will be checked against the amount that you specify. The loan is liquidated only if the pending components are individually less than, or equal to, the amount specified.

Note

The amount that you specify as the residual amount is expressed in the local currency. For loans in foreign currencies, the standard exchange rate will be picked up from the Ex­change Rate Table. The exchange rate that is used for conversion is defined for the prod­uct the loan involves.

While automatically liquidating the loan, the outstanding amounts are reversed to the accounts to which the accruals have been booked. These amounts are however retained in the corresponding fields for information purposes.

The following are the maximum limits accepted:

Enter “0” if you do not wish to allow residual amounts. This means that all the components should have zero balances for the loan to be marked as liquidated.

11.2.5 Auto Authorization

Select this check box to indicate authorization can be carried out automatically.

11.2.6 Transaction Code for Force Liquidation

This is the transaction code for the accounting entries to be passed when the residual amount is liquidated.

11.2.7 Reversal Suspense GL

You can maintain the Reversal Suspense GL for the reversal and reposting of accounting entries.

The system reverses and reposts the accounting entries which are posted to the customer account prior to the amendment of the counterparty of the contract to the Reverse Suspense GL you maintain here.

Note

As part of customer amendment, you have to manually change the credit line applicable for the new counterparty. The system does the Limit validation and utilization under the new customer as part of save of amendment. The Customer change is done through CAMD at the commitment level.

11.2.8 Indicating your Specifications for the different ‘Rates’

You may need to print the Customer Effective Loan Rate, the Annual Effective Loan Rate, or the Effective Rate of interest in advices sent to the customer and also in central bank reports. For the system to compute these rates and print them on advices and reports you need to enable these options as a branch level preference.

If you enable any of these options you also need to specify the denominator basis which is to be used in the computation formula.

The options available are:

Note

Ensure that you enable these options in the Loans Product Preferences screen as well.

For details examples on how the rates are calculated you can refer to the Defining attributes specific to a Loans product chapter of this manual.

Specifying Auto Liquidation of Delinquent Contracts

For the loans that have been defined for auto liquidation, you can specify whether the system should liquidate delinquent contracts also.

If you specify auto liquidation for delinquent contracts, the system generates delinquency records for overdue schedules.

However, if you do not opt for auto liquidation of delinquent contracts, the system does not liquidate such contracts.

REVN of Liquidated Contracts

Select this check box to indicate that rate revision should be applied for liquidated contracts. Rate revision is applicable only for floating automatic and floating periodic auto type of loans.

Note

Auto adjustment happens only when the ‘Overpayment & Auto Schedule Adjustment’ check box is selected for the product.

11.2.8.1 Rate Revision / Rate Fixing / Rate Changes

You can do rate revision for liquidated contracts / liquidated schedules. This can be done by selecting the ‘REVN of Liquidated Contracts’ option in ‘Loans and Deposits – Branch Parameters’ screen.

For floating periodic auto type of loans, based on the rate changed for a rate code, the status of the revision schedule is updated as ‘REPICK’, provided that the effective date is less than or equal to the revision schedule maintained for that contract.

During the life cycle of a floating periodic auto loan, a contract can be linked to any rate code and it can be changed through a VAMI (Value Dated Amendment). After the rate code change, if the rate for the previous rate code is changed, then the interest is re-computed provided the effective date (for which the rate is being changed) of the rate code is less than or equal to the revision schedule date. This is applicable for liquidated schedules and liquidated contracts.

Only the schedule for which the rate revision is not applied is allowed for deletion. This is applicable despite the latest version of the contract is not floating periodic auto or floating auto.

In the batch if a rate revision impacts a schedule which is liquidated, then the schedules are adjusted automatically based on the net amount paid (Amount paid-Amount refunded-Amount reversed). The IRR is recomputed, if discount accrual is applicable for the product.

If a rate revision impacts a liquidated contract, then the schedules are built based on the net interest paid (Amount paid-refund amount-amount reversed).

Example

Consider a loan of 200,000 USD was given to AIRBUS on December 01,2007 with principal payment on every first of the month. The maturity date of the loan was 01-Feb-2008, Last payment was done on 01-Feb-2008 and the current scenario is depicted below.

Schedule date

Amount Due(USD)

Amount Settled (USD)

1-Jan-08

10,000.00

10,000.00

1-Feb-08

10,000.00

10,000.00

The contract status is now liquidated and the rate for the underlying rate code is changed for the effective date of 15-Dec-2007 such that amount due for the interest gets changed. As a result of the rate change, the system adjusts the liquidated schedules automatically. The scenario after the VAMI is depicted below

Schedule date

Amount Due(USD)

Amount Settled(USD)

1-Jan-08

11,000.00

11,000.00

1-Feb-08

11,000.00

9,000.00

 

Rate change for Liquidated Schedules

Consider a loan of 200,000 USD given to AIRBUS on December 01,2007 with principal payment on every first of the month. The maturity date of the loan be 01-Mar-2008, Last payment was done on 01-Feb-2008 and the current scenario is depicted below.

Schedule date

Amount Due(USD)

Amount Settled (USD)

1-Jan-08

10,000.00

10,000.00

1-Feb-08

10,000.00

10,000.00

1-Mar-08

10,000.00

0.00

Current System date is 15-Feb-08 and now a back valued VAMI with a value date as 15-Dec-2007 is done to increase the rate such that amount due for the interest gets changed. As a result of the VAMI the amount settled is adjusted automatically. The scenario after the VAMI is depicted below

11.3 Initiating the Automatic Contract Update Function

Schedule date

Amount Due(USD)

Amount Settled(USD)

1-Jan-08

11,000.00

11,000.00

1-Feb-08

11,000.00

9,000.00

1-Mar-08

11,000.00

0.00

For any event involving accounts in a foreign currency, this function uses the conversion rate in the Currency table for converting the amount to the local currency.

Note

Ensure that you update the conversion rates in the Currency table with the rates for the day before you execute the Automatic Contract Update function.

11.3.1 Processing during Beginning of Day

All the automatic events scheduled for the day, except the accrual of ICCF components, will be carried out when the function is executed during the beginning of day operations.

In addition, all the activities scheduled for the holidays will be carried out if the current system date follows a holiday(s) and you have specified that events falling on holidays should be processed on the immediate working day succeeding a holiday.

11.3.2 Processing during End of Day

When the function is executed during end of day activities, the processing will be for:

If an event, scheduled to be automatically carried out, is not executed for some reason, it will be reported in the Exception Report generated by the function. Examples of such events could be the non-availability of funds in a payment account, the non-availability of funds in a commitment or a deposit to which a loan is linked, and so on. The details of an event that could not be initiated, along with the reason, will be reported in the Exception Report.

11.3.3 Processing for Holidays

Any automatic event that is scheduled for a holiday will be processed as per your specifications in the Branch Parameters table:

If you have specified that processing has to be done on the last working day (before a holiday) for automatic events that fall due on holidays, the events falling on the holiday will be processed during end of day on the last working day before the holiday.

If you have specified that processing has to be done only up to the System Date (today), then only the events scheduled for the system date (the last working day before the holiday) will be processed. The events that fall due on the holiday will be processed on the working day after the holiday, during beginning of day processing.

Example

The current system date is 30 October 1998. A repayment schedule for a loan falls due on 31 October 1998. This is a holiday.

If you specified that processing has to be done today (the last working day before the holiday) for automatic events right up to the day before the next working day, the schedule liquidation (for events falling on 31 October 1998) will be done on 31 October during end of day processing.

If you have specified that processing has to be done only up to the System Date (today), then only the events scheduled for 30 October, will be processed on that day. The liquidation scheduled for the holiday (31 October), will be done during beginning of day processing on 1 November.

11.4 Initiating a Future Value Dated Contract

A ‘future dated’ loan is one that has a Value Date that is later than the date on which it is booked. The Automatic Contract Update function initiates the loan on the Value Date of the loan.

If there were holiday(s) preceding today, future dated loans that were dated for the holiday(s) will also be initiated if you have specified that events falling on a holiday should be processed on the next working day.

All the initiation related entries specified for the product, that the loan involves, are passed automatically. If currency conversions are involved, the conversion rates as of today are picked up from the Currency Table.

If the loan is linked to a commitment, the commitment utilization is updated. In addition, the contingent entries passed when the commitment was initiated is reversed to the extent of the loan amount linked. If the available balance in the commitment is not enough to cover the entire loan amount linked, the loan is not initiated. This is reported in the Exception Report.

For future dated contracts that fall due today, if there is a rate change today, the interest amounts are recalculated for the schedules.

11.5 Processing an Automatic Repayment

For loans that have been defined with automatic liquidation of repayments, the liquidation is carried out by the Automatic Contract Update function.

The schedule is automatically liquidated on the day it falls due, during beginning of day processing.

Now, if you have indicated automatic liquidation, the schedule date falls on a holiday, and you have specified that the holiday be ignored (through the Contract Preferences screen), the liquidation falling due on the holiday, would depend on your holiday handling specifications in the Branch Parameters screen:

If a loan has been defined for verification of funds before automatic liquidation, the components whose schedule dates fall on the same day will be liquidated in the order that you specified while defining the product.

If the funds are insufficient, the liquidation will be done to the extent of the available balance in the repayment account, again, following the order of liquidation of components specified by you. If this is so, it 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 are to be verified, and the funds are insufficient:

The liquidation order is helpful when you want to liquidate the dues in a certain order: say interest (or interest type of components) first, and then the principal.

Example

You can indicate that the repayment schedules for the principal have to be liquidated automatically, if you are sure that your customer can repay the schedules on time.

Another scenario where you could define automatic schedules could be when the interest earned from a deposit services your customer’s loan.

You can opt for manual liquidation of schedules.

If a loan has been defined with Floating interest, and an interest revision falls due today, the revised rate is applied before the repayment is processed.

11.5.1 Advices Generated for a Repayment

Advices are generated by the Automatic Contract Update function during beginning of day processing. While defining a product you may have specified that an advice is to be generated to intimate the customer every time a payment has been liquidated. This applies to all loans involving the product (refer chapter on product definition).

However, for a particular loan, you can suppress this advice.

If a repayment advice has been specified for a loan, it is generated by the Automatic Contract Update function when you run it at the beginning of day.

11.6 Generation of Billing Advices and Delinquency Notic­es

A billing notice or advice can be generated, for the benefit of a customer, as a reminder that a payment is due. When defining a product, you can specify the number of working days before the repayment date when a billing notice is to be generated.

The notice is generated as part of the Automatic Contract Update function when you run it at the beginning of day. The billing advice is generated for the mail medium. This notice is generated for repayment of all components.

If you have specified that a notice is to be generated on a certain day and it happens to be a holiday, then the notice is generated depending on your holiday handling specifications in the Branch Parameters screen.

Example

Assume that while entering into a contract with Ms Yvonne Cousteau, you specified 10 days here. If today is 20 June 1997, and 21 June 1997 is a holiday, the notices are generated for payments due on 30 June 1997, during BOD on 20 June 1997.

The notices meant for 1 July 1997 are generated, during end of day processing, on 20 June 1997 if you have specified that all automatic processes falling due right up to the next working date are to be processed on the System Date (today’s date).

If not, the notices meant for 1 July, are generated during beginning of day processing, on the working day immediately after the holiday, that is, 22 June.

A delinquency notice is generated to be sent to a customer when a payment is pending. The Automatic Contract Update function generates the delinquency notice if you have specified one for a loan, during BOD processing. If it falls due on a holiday, its generation depends upon your holiday handling specifications in the Branch Parameters screen.

11.7 Automatic Rollover of a Loan

A ‘Rollover’ is a renewal of a loan. For a loan to be rolled over it:

If you have specified automatic liquidation and automatic rollover for a loan, the old loan is liquidated and a new one initiated on the Maturity Date of the loan during the BOD (Beginning Of Day) run of the Automatic Contract Update function.

If the Maturity Date falls on a holiday, the liquidation and the rollover are processed as per your holiday handling specifications in the Branch Parameters screen.

If you have defined that the loan be liquidated manually, you cannot roll it over automatically.

When a loan is rolled over or renewed for the interest, commission, charge or fee components, it can assume the following attributes:

You can specify this at the time of processing the original loan.

This section contains the following topics:

11.7.1 Advices for Rollover

When creating a product, you can opt to generate an advice that would intimate your customer that a loan (involving her) is rolled over. This specification applies to all loans involving the product (refer chapter on product definition).

However, for a particular loan, you can suppress this advice. If an advice for renewal of the loan has been specified, it is generated during BOD processing.

11.7.2 Automatic Status Changes

A loan that is yet to reach a repayment date, or on which repayments are being made regularly, will be considered as having an ‘Active’ status. When a repayment is not done on the schedule date, you may want to do an aging analysis of the loan.

11.7.3 Defining Status Codes for a Product

You can do aging analysis by changing the status of a loan on which payment(s) are defaulted. At any time, you can generate reports of loans, with details of aging, to facilitate the follow up process for repayment.

11.7.4 Changing the Status of a Loan

Apart from the Active status that is allotted automatically to a loan on its initiation, a loan on which one or more payments have not been made on the schedule date can pass through more than one status. You can define the attributes for each status code. These are:

The statuses are user-defined. That is, you can define the various statuses for a product and a loan according to your needs.

For more information about maintaining status derivation rules, refer to Product Definition User Manual.

Example

You could define the following status for the product, Short Term Loans with Individuals:

Normal - This is when repayments on a loan are done as per schedule.

Past Due Obligation (PDO) - This is when repayments on a loan have been stopped but the accruals on the accruable components are still being done (There is still a chance of repayment of the loan).

Non-accrual basis (NAB) - When the loan acquires this status all accruals for the loan are stopped (The chances of repayment diminish further).

Write-off (WO) - This is when the loan is written off and all accrual entries are reversed.

Status

Sequence

PDO

1

NAB

2

WO

3

 

You want a loan under this product to move from status to status in the order in which they are mentioned here. For such a condition, you can indicate the number of days after which each component should move to the status being defined (these can differ for a maturity schedule and an interim schedule).

According to the number of days of default defined for each component, a loan is first moved to PDO from Active status, then to NAB and lastly to WO status.

You can classify a status as adverse thereby indicating whether a contract is itself delinquent or marked for adverse status by virtue of other contract(s) of the same customer having gone into default. You can also indicate the change of GL, if any, when a component comes to a particular status, and the messages to be generated at each status change.

11.7.5 Automatic Status Change

A ‘forward’ status change is one in which the status changes from one to the next. In our example, the movement from Active to PDO, PDO to NAB, and NAB to Write Off are all forward changes.

A ‘reverse’ status change is one in which the status changes from one to the previous. Such a situation arises when a payment is made on a loan with a status other than Active.

If you specify that reverse changes have to be carried out automatically, the status is changed when a payment is made on a loan with a status other than Active.

If you specify that reverse changes should not be automatic, the status remains unchanged even if a repayment is made on the loan. The status has to be changed by you through the Contract Processing function.

A reverse change may also become necessary when the number of days of default is increased for a product.

If you specify that forward changes or reverse changes have to be carried out automatically, the status changes are carried out by the Automatic Contract Update function when it is run during the Beginning of Day processes on the day the change falls due.

If the day on which the forward or reverse status change is due happens to be a holiday, then, the processing depends upon your specifications in the Branch Parameters screen.

If you specify that the forward or reverse changes should not be carried out automatically, the status remains unchanged till you specifically change it for a loan, through the Contract Processing function.

At the time of processing a loan, you can change the automatic mode of status change you have specified for the product to the manual mode, or vice-versa. However, this applies to all status.

Indicating Transfer schedule preferences

You have to indicate whether the entries for the past schedules or the future interest schedules have to be transferred to the new GLs for each component.

Past schedules enable the transfer of all past-due schedules (including principal and accruals) to be transferred to new GLs rather than transferring only the schedule that is affected by the current status.

Future schedules enable the transfer of only the principal schedules due in the future to the designated GL.

11.8 Advices to be Generated for a Status Change

You can specify whether an advice has to be generated to inform the customer about the status change of the loan. You can also specify the kind of advices to be generated.

You can generate advices when the loan components move forward from one status to the next, to notify the customer of the status change and possibly urge him to make the payments to liquidate the schedules, which are aging. The advices are generated during beginning of day processing when a status change takes place.

You can choose from a pick-list of messages the specific advice or message that you want sent to the customer when a loan moves automatically (forward) into the status you are defining. These messages or advices are maintained by the messaging sub-system of Oracle Lending.

11.9 Accrual of ICCF Components

When you are defining the interest, commission, charge or fee components (ICCF components) for a loan product, you should also specify whether accruals have to be done for the accruable ICCF components. You can specify this through the Product ICCF Details screen.

If accruals should be done, the frequency of accrual should also be specified for a product (through the Product Preferences screen), at the time of product definition.

For all loans for which accruals fall due today, the Automatic Contract Update function passes the accrual entries. Accrual of interest, commission, charge or fee is done during the end of day processing of the Automatic Contract Update function.

In some cases, if an event occurs in between two scheduled accruals, accrual entries are passed for that event, immediately.

Example

The last accrual date for Ms Yvonne Cousteau’s loan was 31 March 1998 and the next one is due on 30 April 1998. Now, if a manual liquidation is done on 15 April 1998, the accrual entries are passed immediately by the system.

If a schedules accrual falls on a holiday, the accruals are done as per your holiday handling specifications for automatic processes, in the Branch Parameters screen.

The accrual and income accounts will be picked up based on your definition in the Chart of Accounts.

An Accrual Control Journal is generated by the Automatic Contract Update function, reporting the details of the accruals performed.

For a loan on which there is a default in payment, you can specify that aging analysis should be done. This analysis involves the change of status of a loan. When the status is changed, you can also specify that the accruals on the loan should be stopped. For such loans, the accrual entries are not passed; they are only calculated and reported in the Accrual Control Journal under ‘Memo Accruals.’

Processing of interest based on interest period basis

During periodic accruals for a contract, interest accruals also depend on the interest period basis defined for the contract. The interest period basis determines whether the interest calculation for schedules takes into account the schedule start dates or the end dates, or both, or whether it excludes both. The following considerations would be applicable:

For details about the interest period basis, refer the chapters Defining a Product and Disbursing a Loan in this User Manual.

11.9.1 The Memo Accrual Function

The memo accrual function will give you the latest accrual amounts for all components of a live contract without actually passing the accrual entries. The memo accrual function generates the Memo Accrual Control Journal that reports the accrued amounts for the various components of the contract (like interest, commission, charge or fee) that are due on each loan as of the current system date.

11.9.2 Contents of the Accrual Control Journal

The accrual control journal, or report as it is referred to in Oracle Lending, lists the loans for which accrual entries were passed as of the current date.

You can opt to run the Accrual Contract Journal in two ways:

Actual

The actual accrual report contain the details of the actual accrual entries that were passed as of the date you have indicated.

Memo

To recall, the Memo Commission Accrual function automatically accrues the components of the active Loans. The function neither generates any accounting entries nor does it mark the loans as accrued.

This report merely computes the accrual amount as it would be computed for a regular accrual and reports the accrued figures. It does not pass accounting entries for the same.

11.10 Interest Rate Revision on a Loan

The type of interest that is applicable on a loan depends on the definition of the product that it involves. If floating interest rates are applicable for a product, the frequency at which the changing interest rates should be applied on contracts involving it is also defined for the product.

The Interest Rate Type of a product can be one of the following: fixed, floating, zero or special.

The floating interest rates are defined through the Floating Rate Definition screen. A Rate Code identifies a set of rates defined for a combination of Currency, Amount Limit (optional) and Effective Date. When processing a loan, you should link it to the floating rate table by indicating the Rate Code. The rates defined for the Rate Code is applied on the deposit (or in other words, the contract).

The rates will be applied to a contract depending on whether it has been defined with Auto Refresh or Periodic Refresh.

The changes in floating rate can be applied on a contract in two ways. In one method called the Auto Refresh method, all the rate changes during the liquidation or accrual period will be considered. In the other method called the Periodic Refresh method, the rates as of a specific frequency or date is applied.

The following example will illustrate this point.

Example

Tenor: The Start Date of the contract is 1 October 1997 and the End Date 30 November 1997.

The contract has a floating rate and the rates in the floating rate table change in the following manner:

Date

Rate

1 October 1997

12%

12 October 1997

11.5%

25 October 1997

11%

15 November 1997

12%

30 November 1997

12.5%

 

Liquidation Frequency: Monthly

If the contract is defined with Auto Refresh, the liquidation on 30 October considers all the rate changes that were done between 1 October and 30 October. The rates are applied for the number of days for which they remained unchanged in the rate table, as follows:

From

To

Rate

1 October 1

1 October

12%

12 October

24 October

11.5%

25 October

30 October

11%

For a contract with Periodic Refresh, the rates prevailing on the refresh dates are used for accruals and liquidation. If the contract is defined with Periodic Refresh and the refresh dates are defined as the 15 October, 1 November, 15 November and 30 November, the rate applied for the liquidation on 30 October will be as follows:

From

To

Rate

1 October 1

14 October

12%

15 October

30 October

11.5%

The Automatic Contract Update does the interest accruals for those loans for which a rate revision becomes due today, whatever the way they have to be applied - every time the rate changes, or periodically.

11.11 Value Dated Changes

Value Dated Changes are changes to a contract that come into effect on a specific date called the Value Date. Additional disbursements (increase in the principal), a change of interest, commission or fee rate, collection of additional fees, and so on, are examples of the value-dated changes that can be made to a contract.

Such changes indicated for a loan (through the Value Dated Changes Screen), falling due today (that is, the Value Date is today’s date), are executed by the Automatic Contract Update function during beginning of day. All the necessary accounting entries are passed and advices specified for the event are generated.

If the Value Dated change is in the rate or amount of any accruable component, the accruals are done for the loan with the old rate or amount as of the previous day (yesterday).

If the Maturity Date of a loan has been changed so that the contract matures today, the loan will be liquidated provided all the prerequisites for such liquidation are met.

11.11.1 Advices generated for Value Dated Changes

When creating a product, you can specify the advices that are to be generated when a value dated change is made on contracts involving the product. For a loan involving the product, you can suppress these advices, if you do not want them generated.

For example, if you have so specified:

The Automatic Contract Update function generates the advices you have specified for the loan during the beginning of day processes. If the value dated change falls on a holiday, it’s processing and the generation of the advice will be done as per your holiday handling specifications in the Branch Parameters screen.

11.12 OL - OFSAA Integration

The integration between OL module and OFSAA enables you transfer data from OL module to OFSAA. The transfer of data from OL to OFSAA is performed using staging table.

The following data is transferred in OBCL staging table:

For more information on integration process, refer to the Oracle FCUBS - OFSAA Integration User Guide.

11.12.1 Maintaining Batch Programs

You need to maintain the batch program ‘OLXTRACT’ using ‘Mandatory Batch Program Maintenance’ (EIDMANPE) screen. This batch extracts the data from Oracle FLEXCUBE during end of financial input (EOFI) stage. You also need to maintain the extraction routine.

For further details on the maintenances in FLEXCUBE Information Server, refer FLEXCUBE Information Server user manual