8. Automatic Processing

While discussing the various events in the life cycle of a deal, we have referred to the Automatic Contract Update function that carries out these events. In this chapter, we shall discuss the features of this function.

The Automatic Contract Update function should executed at least twice during the day, once before you begin transaction related activities for the day (that is, as a part of the beginning of day activities) and once after you have finished all the transaction related activities for the day.

If any transaction related activities are carried out after the function has been run as part of End-of-Day (EOD) activities, you have to execute it again so that the processing that may be necessitated by the transaction related activity is carried out.

This chapter contains the following sections:

8.1 Automatic Events in the Life Cycle of a Deal

The following are the various events in the life cycle of a deal that could be carried out automatically. They can be grouped into automatic events that take place Beginning-of-Day (BOD) and those that take place End-of-Day (EOD).

This section contains the following topics:

8.1.1 Beginning of Day Processes:

8.1.2 End of Day Processes:

You would have noticed that some activities that can be carried out automatically would be done so only on a specific instruction from you. The following are such activities:

8.2 Specifying Branch Parameters

A set of rules that govern the deals that a particular branch (of your bank) enters into are defined through the Branch Parameters screen.

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 will be processed.

Assume today is October 20, 1997, and October 21, 1997 and 22 October 1997 are holidays. If you specify that processing has to be done till the system date, during the Automatic Batch Update function run, the system will process only the events scheduled for October 20, 1997.

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

Next Working Day - 1

You can indicate whether events should be processed till the day before the next working day, when the Automatic Batch Update function is run. If you do so, all the events that fall on days between the current system date and the next working date will be processed.

Assume that today is October 20, 1997, and October 21, 1997 and October 22, 1997 are holidays. If you specify that processing has to be done till the day before the next working day, when you run the Automatic Batch Update function during end of day processing on October 20, 1997, all the events scheduled for October 21, 1997 and October 22, 1997 will be processed.

Tax Basis

On a deal, you may have to pay tax to the Government on the profit earned. 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 the Branch Parameters screen. The following example illustrates how this works.

Accrual Level

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

A Murabaha MM deal will inherit 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 deals involving the product will be passed to the same accounts.

These entries can be passed in two ways:

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

Whether profit accrual entries are passed as a single consolidated entry for a product, or as an individual entry for each deal, 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 deal, the entries will be for the specific deals affected by the change.

Residual Amount

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

The residual amount (profit, commission, or fees) will be checked against the amount that you specify. The placement will be 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 local currency. For placements in foreign currencies, the standard exchange rate will be picked up from the Exchange Rate Table. The exchange rate that is used for conversion is defined for the product the deal involves.

While automatically liquidating the placement, the outstanding amounts will be 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 placement to be marked as liquidated.

When this amount is increased or decreased, all placement meeting the conditions will be liquidated during the next Automatic Batch Update.

Residual TXN Cd

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

User Ref. No. in Messages

If this option is checked then the user reference number will be used instead of the contract reference number in the following messages.

8.2.1 Confirmation Messages

SWIFT

Mail

8.2.2 Account Statement

If the ‘User Ref No. in messages’ option is checked in the ‘MM Branch Parameter’ screen then in the Field 61(statement line) the user ref no would be populated in sub field 8 account servicing institution's ref no. If it is left unchecked, then it will be picked up from the child contract reference number.

8.3 Invoking the Batch Process

Batches are run automatically. In the mandatory programs, all batches whichever are required will be maintained in sequence and that is triggered automatically as based on the maintenance in the ‘Mandatory Batch Program Maintenance’ screen. You can invoke this screen by typing ‘ ‘EIDMANPE’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Module

Choose the module code from the adjoining option list.

Function Identification

Choose the function ID of batch that you wish to run. The adjoining option list displays all batch processes available for the module. Select the appropriate one.

You can configure the batch to be run at various stages of day like EOD, EOTI and so on.

For further details about this screen, refer the chapter ‘Setting- up Mandatory Programs for EOD’ in the AEOD User Manual.

8.4 Initiating the Automatic Contract Update Function

For any event involving accounts in a foreign currency, this function will use the conversion rate in the Currency table for converting the amount to 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.

This section contains the following topics:

8.4.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 Automatic Contract Update 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 the holiday.

8.4.2 Processing During End of Day

When the function is executed during end of day activities, the processing will be carried out 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, non-availability of funds in a commitment or a deposit to which a deal 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.

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

8.5 Initiating a Future Value Dated Deal

A ‘future dated’ deal is one that has a Value Date that is later than the date on which it is booked. The Automatic Contract Update function will initiate the deal on the Value Date of the deal during BOD processing.

If there were holiday(s) preceding today, future dated deals 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 deal involves, will be passed automatically. If currency conversions are involved, the conversion rates as of today will be picked up from the Currency Table.

If for some reason, a deal scheduled for initiation today is not initiated, it will be reported in the Exception Report generated during EOD processing.

For a future dated deal falling due today, if there is also a rate change today, the profit amounts are also recalculated for the schedules.

8.6 Processing an Automatic Repayment

For deals that have been defined with automatic liquidation of repayments, the liquidation will be carried out by the Automatic Contract Update function. It could be an interim repayment schedule liquidation or a maturity schedule liquidation.

The schedule, whether an interim schedule or a maturity schedule, will be 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 placement has been defined for verification of funds before automatic liquidation, the components for which the 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 profit (or profit type of components) first and then the principal.

If the deal has been defined with Floating profit, and a profit revision falls due today, the revised rate will be applied before the repayment is processed.

8.6.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 will apply to all deals involving the product (refer chapter on product definition). However, for a particular deal, you can suppress this advice.

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

8.7 Generation of Billing Advices

A billing notice or advice can be generated, for the benefit of the customer, as a reminder that a payment on a placement 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 will be 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:

If the number of days is increased, the system checks for deal with a payment date between the old and the new number of days and will send a billing notice.

If the number of days is decreased, the system will check to see if a notice has been sent already, to avoid duplication. If not, it will send the notice.

8.8 Automatic Rollover of a Deal

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

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

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

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

When a deal is rolled over or renewed for the profit, commission, charge or fee components, it can assume the attributes of the:

You can specify this at the time of deal processing (of the old deal).

This section contains the following topics:

8.8.1 Advices for Rollover

When creating a product, you can opt to generate an advice that you would intimate your customer that a deal (involving her) has been rolled over or renewed. This specification will apply to all deals involving the product (refer chapter on product definition).

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

8.8.2 Automatic Status Changes

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

If you have specified status and indicate that they be changed automatically, then the status change will be done during BOD processing on the day the aging is due.

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

For example, you could define the following status for the product, Three month Placements:

You want a placement 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 placement will first be moved to PDO from Active status, then to NAB and lastly to WRO status.

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.

8.8.3 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 placement with a status other than Active.

If you specify that reverse changes have to be carried out automatically, the status will be changed when a payment is made on a placement 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 placement. 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 will be carried out by the Automatic Contract Update function when it is run either during 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 placement, through the Contract Processing function.

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

8.8.4 Advices to be Generated for a Status Change

You can specify that an advice is to be generated to inform the customer about the status change of the placement. You can also specify the kind of advices to be generated.

You can generate advices when the placement 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 that are aging. The advice will be generated during beginning of day when an automatic status change happens.

8.9 Accrual of ICCF Components

When you are defining the profit, commission, charge or fee components (ICCF components) for a Murabaha MM 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 the product (through the Product Preferences screen), at the time of product definition.

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

In some cases, for example, if a manual liquidation is done, the accrual entries will be passed immediately by the system. If this falls on a holiday, the accruals will be 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 placement 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 deal. When the status is changed, you can also specify that the accruals on the deal should be stopped. For such deals, the accrual entries will not be passed; they will only be calculated and reported in the Accrual Control Journal under ‘Memo Accruals’.

This section contains the following topics:

8.9.1 Contents of the Accrual Control Journal

The memo accrual function will give you the latest accrual amounts for all components of a live deal 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 deal, (like profit, commission, charge or fee) that are due on each deal as of the current system date.

8.9.2 Intra Day Accruals

The Intra Day Accruals is a batch process that computes accruals for different kinds of investments made by funds. This batch includes processing of fixed asset depreciation. The intraday accruals / depreciation are performed only for those products for which accruals / depreciation cycle is due for the day. In case of inter-fund subscriptions, the system does not calculate the profit for the investing fund.

This is an intra day process that is applicable only to fund branches.

Intra Day Accruals work in line with the normal end of day accruals. Intra day accrual will process in the same manner as an End of Day (EOD) batch. However, there are some exceptions as listed below:

8.10 Profit Rate Revision on a Deal

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

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

The floating profit 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 deal, you link it to the floating rate table by indicating the Rate Code. The rates defined for the Rate Code will be applied on the deal (or in other words, the contract).

The rates will be applied to a deal depending on whether it has been defined with:

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

If a fixed profit rate or amount for a deal which has been changed through the Value Dated Changes function falls due today, then the change is effected during BOD processing.

8.11 Value Dated Changes

Value Dated Changes are changes to a deal that come into effect on a specific date called the Value Date. Examples of value-dated changes are changes in profit, charge, or fee amounts; collections of additional fees; and so on.

Such changes indicated for a deal (through the Value Dated Changes function), falling due today (that is, if the Value Date is today’s date), are executed by the Automatic Contract Update function during beginning of day. All the necessary accounting entries will be 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 deal with the old rate or amount as of the previous day (yesterday).

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

Note

Any Value Dated Change done during the course of the day with the Value Date as today will, however, be processed during the EOD processing.

8.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 deal involving the product, you can suppress these advices, if you do not want them generated.

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

For example, if you have so specified:

8.12 Triggering the Year-end Batch Process for Collecting Contract-Wise Data

The year-end batch process can be triggered to collect data pertaining to the unrealized income booked for each contract during the year. You will be allowed to trigger this process only if you have enabled the Track PY PnL Adjustment option for your branch through the Preferences section of the Branch Parameters screen. During liquidation the information that is collected using the batch process is used to post adjustment entries to the previous year adjustment GL.

You must ensure that you execute this batch process prior to executing the Year-end P and L balance transfer batch. The balances pertaining to the unrealized income booked for each contract during the year will be stored at the Contract, Component and Status level. If a contract spans over multiple years, the accrual balances will reflect the total accrual balance for all previous years.

For example. the status of two contracts entered in the System is as follows:

Contract Ref Number Component Amount accrued after liquidation
C1 LDML-INT USD 100
C2 LDML-INT USD 100

During the next year, C1 is liquidated and C2 is not liquidated. After liquidation, C1 has accrued USD 50 and C2 has accrued USD 100.

As a result, the details reflected after running the year-end data collection batch will be as follows.

Contract Ref number Component Amt accrued after liquidation
C1 LDML-INT USD 50
C2 LDML-INT USD 200

While liquidating a contract/schedule the system liquidates the unrealized accruals for the previous year before liquidating the unrealized accruals for the current year.

For discounted Murabaha MM contracts, the transfer of balance from the unrealized GL to the realized income/expense GL is performed only during maturity of the contract.

8.13 Commodity Upload

Oracle FLEXCUBE allows you to upload commodity while performing a commodity tracking operation.

Specify the module code and source code. The system will upload the unprocessed data and validates them. After validation, it posts the entries into the contract table. You can verify the uploaded data in Oracle FLEXCUBE by accessing ‘Commodity Tracking’ screen.