6. Automatic Processes

6.1 Introduction

Certain processes that are initiated either at Beginning of Day (BOD) or End of Day (EOD), execute certain events on the days they fall due. The Batch processes that are applicable to Funds Transfers are discussed in this chapter. They are:

This chapter contains the following sections:

6.2 Autobook Function

The autobook function handles the processing of future valued contracts. A future valued contract is one that has been stored with a value date in the future and may have rate pickup specifications as of the day you defined for the contract.

The values that you enter in the ‘rate as of’, ‘message as of’ and ‘accounting as of’ fields will drive the processing of a future dated contract. All authorized contracts that are due for initiation as of a particular day are picked up and processed by this batch processing function at EOD or BOD as the case may be.

If you have specified that the contract requires a rate update on a particular day then the rate as of that day is picked up from the exchange rate table and applied to the transfer amount and to the other components of the transfer.

However, if you have specified that the rate of the day must be applied to the transfer amount only after the rate refresh program for the day has been run, then the Autobook function will just mark these contracts as ‘to be processed by the Rate Update Function’. The Rate Update function will process transfers that require a rate update after the rate refresh process has been run and authorized.

The Autobook function will also automatically pass Accounting Entries for all Contracts processed by it. These Accounting Entries will bear the date of the transfer i.e., the value date of the transfer. Based on the specifications you make in the ‘Message as of’ field’, settlement messages and advices will be generated.

The Auto book function posts accounting entries for a contract that it processes based on the option set in the Accounting As Of specification in the contract details. If accounting is indicated as of ‘Message Date’, the relevant accounting entries are passed before the messages are generated, on the date of message generation.

For contracts involving products for which the Allow Messaging Before Accounting option has been set, the messages are indicated to be generated on the booking date, and the accounting could be indicated either on the message generation date (that is, on the booking date) after the generation of messages, or on the debit value date of the contract, depending on the specification made in the Accounting As Of field.

In a nut shell the main functions of ‘Autobook’ is to:

All transfers that have been processed by the Autobook Function will be marked as ‘Liquidated’ once the accounting entries for the transfers have been passed.

The Over ride overdraft check box has to be checked at the contract level which is defaulted from the product level for all the FT transactions which exceeds the amount available in the account, However if the same is not checked, then the contract will not be liquidated and will remain active.

6.3 Update Rate

This section contains the following topics:

6.3.1 Rate Update Function

When you create an FT product and define preferences for it, you can also specify the time at which the exchange rates need to be picked up for contracts involving this product.

Exchange rates are maintained by the Head Office and propagated to the branches. Rates may either be maintained by individual branches or can be input by the HO and propagated to all branches. Once the HO authorizes the exchange rate record, it becomes applicable to all other branches.

You can specify ‘After Rate Refresh' for the field, ‘Rate Type’at the Product Preferences screen

If you specify 'After Rate Refresh' then the contract will be put on hold. No accounting entries will be passed, neither will any messages be generated. Such a contract will not be processed until the rate refresh process for the day has been run.

You can perform further operations on a contract whose rate pick up is defined as 'After Rate Refresh' only by means of the rate update function.

The applicable exchange rates will be picked up and applied to the transfer amount on a day that you can specify. The Rate pick up code that you define for a contract basically signifies the date or day on which the standard rate (after rate refresh) needs to be picked up and applied to the transfer amount.

This date can be as of:

Note

If the Rate Pick Up code is of Spot date and Value date, then the BOD batch of the corre­sponding day will do the liquidation as per the rate pickup code at BOD.

To sum it up, the rate update function can be used to process:

6.3.2 Invoking Rate Update Function

From the Application Browser choose EOC Operations. Thereafter, choose Intraday Batch, and from the LOV of function ID choose the Rate Update (FTRTUPDT) under it.

When you invoke this function, the system gives the message as ‘The rates have been refreshed and sent to the host. Do you want to continue’.

Click on ‘Yes’ in the message box to indicate that the rates have been refreshed. Thereafter, you can proceed with the rate update function.

Once the rate update function is completed successfully, the applicable contracts will be updated with the event ‘RATE’ and the latest rate will be applied and the contract will be liquidated.

6.3.3 Processing Contract with Rate Update

All the contracts which have been booked as cross currency and the rate refresh checked remain as active. Invoke the Rate refresh batch and run the same. Once the rate refresh batch is run, then those contracts are updated with the latest rate and the contract is liquidated.

You can update the rates of an unauthorized contract. However the status of the contract remain as unauthorized.

Thereafter, the necessary accounting entries and messages are passed for the transfer in accordance with the specifications you made in the ‘Message As Of’ field of the contract main screen.

If there are contracts for which a rate update is due and exchange rates for the day have been refreshed; however but the rate update function is not invoked, then the Autobook function automatically picks up those contracts and processes them with the refreshed rates.

For example,

Let us assume that a customer of your bank requests you to initiate a transfer on his behalf on 23 March 1999 (Booking date). Assume that for the contract you had specified 30 March 1999 (Value date) in the ‘Rate as of’ and ‘Message as of’ fields. Assume that you had specified that the rates to be used for the contract are to be picked up from the currency table, after the rates have been refreshed (Standard rate - ‘after rate refresh’).

On 23 March 1999 (the day on which you enter the contract), the contract will not be processed, no Accounting Entries will be passed nor will any messages be generated.

On the 30 March 1999, when you invoke the Rate Update function; the system will ensure that the rates have been refreshed before it allows you to update the contract with the refreshed rates.

Since the Message and Rate is as of ‘Value date’, accounting entries and messages will be generated on 30 March 1999.

6.4 Referral Queue

This section contains the following topics:

6.4.1 Referral Queue Function

Referral refers to the process of handling transactions hitting the customer’s account which forces the account to exceed the overdraft limit on the account.

The referral function works on a three tier process. The “Referral required” flag should be checked at “Account Class” level. The “referral required” field at the customer account class level will be defaulted to the customer Account level. In case the account is marked for referral, transactions resulting the account to go into overdraft, then the same transaction would be sent to referral queue. For accounts not marked for referral, normal Flexcube transaction processing would be done. At the FT product level, referral required flag is provided. For the corresponding account class, customer account and product, if the transaction is resulting into the account going into overdraft, then the transaction will be sent to the referral queue.

Note

6.4.2 Invoking Referral Queue Function

From the application browser, choose Function Inputs under EOC operations. Maintain the Referral batch CSREFQPR for the respective branch and EOC group under Transaction Input.

Thereafter, from the application browser, select the Intra Day Batch from EOC Operations. Select the referral batch (CSREFQPR) from the LOV Function ID and run the batch.

6.4.3 Processing Contract with Referral Queue Function

When a FT contract is booked with the product which is checked as “Referral required”, for the customer whom the “Referral required” is checked and of the account class where “Referral required” is checked, then the same transaction is booked with the status as active and only the BOOK event fired.

However during the EOD process, the FTAUTO, BOD batch picks up all the transactions marked for referral and puts them under “Unposted” in the referral queue.

From the Application browser, select Customer accounts and under that Customer accounts Maintenance. Select Function ID STDREFQU (Referral Queue) to view all the transactions which have been updated by the batch process as Unposted. The same can be viewed each customer account wise.

Once the BOD process is completed, then you have to manually unlock the record customer wise and select each transaction as Pay flag / Unpay Flag. When you select the transaction as Pay Flag, it means you have accepted that transaction and the over draft facility can be used. However in case you select the Unpay flag for the transaction, then the transaction is rejected. Once this is done you have to save the record.

Note

The fields Pay Posted and Unpay Posted field can be used to do bulk postings.

 

Once the record is saved, the intraday batch CSREFQPR should be run. This batch processes all the contracts where the Pay Flag has been checked. INIT is fired for all the selected transactions. It also rejects all the contracts where the ‘Unpay’ field has been checked.

On unpay, the transaction will be reversed.

The process to check the account statistics of a customer account is given below:

If all the above conditions are met and the values exist, the system will populate the records during the BOD operations in the account period statistics/financial statistics table.

6.5 Notifying Reversal of Payment

You can view a notification when the contract status changes to ‘V’ through the external system’.

Cases in which the contract is booked in the application (through any source), if payment processing fails and further operation is not possible which is equivalent to reversal/ reject status, then a reversal notification is generated with the reason as failure. Currently, in the FT module, failure reasons are not captured at contract level. However, while generating notifications, the system captures the failure reason and is included in the notification.

Going forward, the system generates FT transaction failure log report at EOD from the FT module covering all the contracts that have failed during the same processing date with the error log. The report contains details regarding the following parameters:

6.6 Notifications for Split Events

You can view the notification for successful processing of the ‘INIT’ event through the external system’. You can also view the notification for successful processing of the ‘LIQD’ event through the external system.

In case of split event processing, where debit and credit leg has different value dates, notifications will be generated for both debit as well as credit leg of payment processing. Notifications for both events are generated only when there is a split processing event, else notification is generated for successful processing of ‘LIQD’ event.