3. Maintaining Parameters for Integrated Liquidity Management

3.1 Introduction

You need to maintain certain parameters before you define account structures for integrated liquidity management process. They are:

This chapter contains the following sections:

3.2 Maintaining Account Classes

You can use the Account Class feature in Oracle FLEXCUBE to create a set of accounts which have the same characteristics. You can invoke the ‘Account Class Maintenance’ screen by typing ‘STDACCLS’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button. Click on the ‘Preferences’ button in the ‘Account Class Maintenance’ screen to invoke the ‘Preferences’ screen.

You are required to input the following details in this screen:

Integrated LM

Check this option to indicate that accounts created under this Account Class should be part of an ILM Structure. If the option is checked, the system creates system accounts (internal accounts) for each account that is linked in a pool/sweep structure and tracks the balances on both the actual accounts as well as these system accounts. It also calculates interest on these system accounts.

Note

Interest on accounts that are not part of an account structure are calculated on the actual customer account.

3.3 Customer Spreads

This section contains the following topics:

3.3.1 Maintaining Customer Spreads

For a given customer and currency pair, you can define buy and sell spreads in different tenors (in days). The system defaults the spread to zero if you have not maintained any spread for a customer.

You can maintain spreads for a customer in the ‘Customer Currency Spread Maintenance’ screen. You can invoke the ‘Customer Currency Spread Maintenance’ screen by typing ‘CYDCUSPR’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

3.3.2 Maintaining SDEs

In order to calculate interest, Oracle FLEXCUBE uses components called ‘data elements’ that provide the required data.

System Data Elements (SDEs) are values such as the balance in an account or the number of transactions in a day. This information is constantly updated in the system and is readily available for computation of interest. These values can only be picked up by the system while applying interest. User cannot indicate what the value of an SDE should be.

The following SDEs will be used in IC Processing:

SDE (System Data Elements) Description
ILBD_ULT_DR_BAL Captures the book dated Debit balance of the pool header in this Data element during the IC calculation process
ILBD_ULT_CR_BAL System populates the book dated Credit balance of the pool header in this data element during the IC calculation process
ILVD_ULT_DR_BAL System populates the value dated Debit balance of the pool header in this data element during the IC calculation process
ILVD_ULT_CR_BAL System populates the value dated Credit balance of the pool header in this variable during the IC calculation process
ILBD_CP_DR_CONT This data element captures the Compensated contribution of the book dated Debit balance
ILBD_CP_CR_CONT This data element captures the Compensated contribution of the book dated Credit balance
ILVD_CP_DR_CONT This data element captures the Compensated contribution of the value dated Debit balance
ILVD_CP_CR_CONT This data element captures the Compensated contribution of the value dated Credit balance
ILBD_NCP_DR_­CONT This data element captures the Non Compensated contribution of the book dated Debit balance
ILBD_NCP_CR_­CONT This data element captures the Non Compensated contribution of the book dated Credit balance
ILVD_NCP_DR_­CONT This data element captures the Non Compensated contribution of the value dated Debit balance
ILVD_NCP_CR_­CONT This data element captures the Non Compensated contribution of the value dated Credit balance
IL_DR_EFF_RATE This data elements represents the effective Debit interest rate
IL_CR_EFF_RATE This data elements represents the effective Credit interest rate

3.3.3 Maintaining UDEs

User Data Elements (UDEs) are elements (such as Interest or Tax rate) the values for which are provided by the User. The following User Data Elements (UDE) can be specified in IC Rule Maintenance:

3.4 Interest & Charges Rules

This section contains the following topics:

3.4.1 Creating Interest & Charges Rules

You can use the SDEs and UDEs that you have previously defined to create formula to be used by the system for interest calculations in the ‘Interest & Charges Rule Maintenance’ screen. You can invoke the ‘Interest & Charges Rule Maintenance’ screen by typing ‘ICDRLMNT’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You are required to input the following detail in this screen:

Integrated LM

Choose this option if you want to use the product for Integrated Liquidity Management processing.

Integrated LM Type

Specify the type of System Account to which the product ought to be linked. It can be:

Refer the chapter ‘Annexure B – IC Rule Set-up’ in this User Manual for suggested IC rules.

3.4.2 Creating Interest & Charges Products

You can invoke the ‘Interest And Charges – Interest Product Preferences’ screen by clicking ‘Preferences’ button on the ‘Interest And Charges Product Maintenance’ screen. You can invoke the latter by ‘typing ‘ICDPRMNT’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can input the following details in this screen:

Integrated LM

Choose this option if you want to use the product for Integrated Liquidity Management processing.

Integrated LM Type

Specify the type of System Account to which the product ought to be linked. It can be:

Refer the chapter ‘Annexure A - Accounting Entries’ in this User Manual for suggested IC products.

3.5 Customers

This section contains the following topics:

3.5.1 Maintaining Customers

You can invoke the ‘Customer Maintenance’ screen by typing ‘STDCIF’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Apart from serving as a means to collect basic information about a customer, the ‘Customer Information Maintenance’ screen also reflects the hierarchy existing between a Parent company and its various subsidiaries. The subsidiaries take on the Customer Number of the parent company as their Liability number.

3.5.2 Maintaining IC Special Conditions for Customer Accounts

The ‘Customer Accounts Maintenance’ screen is used to create accounts for a given Customer using the desired account class and currency combination. You can invoke the ‘Customer Accounts Maintenance’ screen by typing ‘STDCUSAC’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

Click ‘Interest’ button in ‘Customer Account Maintenance’ screen to invoke ‘IC Special Conditions Maintenance’ sub-screen, where you can maintain IC special conditions for ILM accounts.

3.5.2.1 IC Special Conditions

The system displays the following fields on the basis of your choice in the IC Rule and IC Product screens.

Integrated LM

The system defaults the value specified in the product screen from based on product selected from the option list.

Integrated LM Type

The system displays the value on the basis of your choice in the IC Rule and IC Product screens.

3.6 Product Event Class & Accounting Entries

This section contains the following topics:

3.6.1 Maintaining Product Event Class & Accounting Entries

When you define an Events Class, you choose, first of all, the set of events that would belong to the class. Events are, usually, unique to a module.

The events that you would like to include in an Events Class can be identified through the ‘Events Accounting Entries and Advices Class Maintenance’ screen. This screen is invoked from the Application Browser.

You can invoke the ‘Events Class Maintenance’ screen by typing ‘CSDACTCL’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can maintain the following details in this screen:

Class Code

An Events Class is identified with a unique Code and a Description. This indicates the name of the event class to which the events for ILM processing will be linked.

Description

You need to enter a brief description for the class code.

Module

Events are, usually, unique to a module. Specify the module as IL to define the events for Liquidity Management module.

Events Description

Once you specify the class code and module, click on add icon. The system will display the events associated with the Integrated Liquidity Management module.

The following events are available for the integrated liquidity management module:

3.6.2 Defining Accounting Entries for Event

You can indicate the accounting entries that should be passed at an event in the Accounting Entries section of the ‘Events Class’ screen. This section is invoked by clicking the ’Accounting Entries’ button.

As part of the Accounting Entry details of an event, you should specify the following details:

Accounting Role

If accounting entries are to be passed for an event, you have to indicate the different Accounting Roles. At an event in the life cycle of a deal, involving a product to which you associate the class, the appropriate entries will be passed under the specified Accounting Roles.

The adjoining option list displays a list of all the available accounting roles.

Amount Tag

The amount (i.e. the available balance, booking dated balance etc.) that is to be posted for an event, is referred to as the Amount Item. The tag associated with an Amount Item is the Amount Tag.

The adjoining option list displays a list of the amount tags that are maintained in the system. You can choose a tag by double clicking on it.

Debit/Credit

You have already specified the type of account to which an entry should be passed, and the tag which identifies the amount (available balance, booking dated balance etc.) that should be passed. In this field, you must indicate if the amount is to be debited from credited to the specified account. Choose the Debit or Credit indicator.

Transaction Codes

Every accounting entry in Oracle FLEXCUBE involves a Transaction Code that describes the nature of the entry. This code and its description will identify the original sweep book, reverse booking and their corresponding reversals. The Transaction Code for both legs of the transaction would be the same.

The table below illustrates the accounting entries for each event that you need to set up for the liquidity management module.

Event Debit/Credit Indicator Accounting Role Amount Tag
SWBK DR CHILD CR_CONT
SWBK CR PARENT CR_CONT
SWBK CR CHILD DR_CONT
SWBK DR PARENT DR_CONT
RVSW DR PARENT CR_CONT
RVSW CR CHILD CR_CONT
RVSW DR CHILD DR_CONT
RVSW CR PARENT DR_CONT

Refer to the Modularity User Manual for further information on setting up accounting details.

3.6.3 Associating Branch to Event Class

After you define the accounting entries that need to be passed for a set of events, you need to associate the event accounting entries to the branches of your bank.

You can invoke the ‘ILM Branch Parameter Maintenance’ screen by typing ‘ILDBRPRM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You are required to input the following details:

Event Class

Choose the event class that you wish to associate to the branch.

Multi branch ILM structure

Check this option to indicate that multi-branch ILM structure is applicable for this branch. In case you wish to modify the option by un-checking it, the system allows it only if there are no existing active groups for the multi-branch.

Job Frequency Min

Specify the frequency for the processing of MBCC Jobs for a branch. The default value of Jobs Frequency is 30.

3.7 Group Code Maintenance

This section contains the following topics:

3.7.1 Maintaining Group Code

In Oracle FLEXCUBE, you can bring together several accounts to form a ‘Group’ for ILM processing. You can then link this group code to the Header Account maintained as part of Account Structure. In Oracle FLEXCUBE, group codes allow you to uniquely identify a given account structure for ILM processing.

You can invoke the ‘Integrated Liquidity Management Group Code Maintenance’ screen by typing ‘ILDGRPCD’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can input the following details in this screen:

Group Code and Description

Enter a unique code to identify the group code in the system. Enter a brief description.

Effective Date

Specify the date from which the group will become active in the system. You will not be allowed to input Back Valued Dates (BVT) here.

Sweep Basis

You need to indicate if the sweep should be performed on Book Dated balance or Value Dated Balance for the entire structure falling under the group. If BVT support is required, it must have ‘Value Dated’ option.

Pool Benefit

If you select this option, interest re-allocation is carried out for the child accounts involved in the group.

Reverse Sweep

Indicate whether reverse sweeps should be performed during BOD batch.

BVT Applicable

Specify if BVT processing is applicable for a group

BVT Unit

Indicate the unit the system should consider while calculating the BVT date. This can be Days/Months

BVT Duration

This indicates the number of BVT units allowed as back period from today’s date while calculating BVT date.

For instance, to indicate 30 Days input ‘Days’ as BVT Unit and ‘30’ in the BVT Duration fields. Similarly, to indicate 2 months, the BVT Unit should be ‘Months’ and the BVT Duration ‘2’.

Note

3.7.2 A Note on Back Valued Transactions

The system rebooks the sweeps (in case of physical pooling) and adjusts the interest amount that had been accrued and settled in the accounts when you input a transaction with a back value date. In case of a change in the Account Structure in the interim between the Back Value Transaction (BVT) date and current date, the system uses the account structure existing on the execution days.

The following points need to be kept in mind for BVT Processing:

The system follows the following process for replaying sweeps:

  1. It omits BOD processing for the least back value date only and continues till the current processing date. It then identifies the value dated balance of the current processing date for the corresponding System Account and carries out the EOD processing.
  2. For a particular Effective Date, it calculates Sweep Amount for the corresponding System Accounts.
  3. It fetches the entry posted for the BVT date from the Sweep Log and compares it with the Sweep Amount that has been calculated currently.
  4. If the Sweep Amounts are equal, no entry is posted.
  5. If the Sweep Amounts are different, it reverses the entry that was posted for the BVT date (SWBK) and the corresponding entry that was used during BOD to reverse the entry above
    Reverse sweep booking (RSBK)
  6. Reversal of Reverse Sweep (RSWR) entry gets posted during reversal of RVSW.
  7. It inputs a new entry whose booking date is the processing date of the BVT and whose value date is the BVT date. This entry is entered into the Daily Log.
  8. It then updates the post sweep balances for a combination of Account + Effective Date + System Account.

Note

Every time a physical sweep is executed, the system stores the credit balance and the un­used OD limit in the Parent Account before and after the sweep.

3.8 Third Party Accounts

3.8.1 Maintaining Third Party Accounts

A Third Party Account is an account which is located in another bank which is not part of your bank, but is part of the Liquidity Management Account Structure maintained with your bank. The funds can be moved from or to the Third Party accounts. To establish a relationship between the accounts in Oracle FLEXCUBE and the third party accounts, you first need to maintain a mirror account of such accounts as normal CASA accounts in Oracle FLEXCUBE and then capture the parameters of the Third Party Accounts in the ‘Mirror Accounts Maintenance’ Screen.

The Mirror accounts can be created at your branch in the country where the Third Party Account is located/your branch in the country where the Header account of the Group is located. The funds to be moved to/from the Third Party Account will be routed through this CASA account.

The Mirror Account will be used to capture parameters for message generation. The balance information obtained from the Third Party Bank will be stored in the Mirror Account.

The Third Party Account details are maintained in the ‘Mirror Accounts Maintenance’ screen. You can invoke the ‘Mirror Accounts Maintenance’ screen by typing ‘ILDMIRAC’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You need to maintain the following parameters in this screen:

Mirror A/c

This indicates the account number in Oracle FLEXCUBE.

External A/c

You need to indicate the account number in the third party bank.

Currency

The system defaults the account currency.

Technical A/c

This indicates the CASA account linked to the mirror account.

Location

This indicates the location of the third party bank.

BIC

Indicate the BIC Code of the third party bank.

Route Code

Specify the route code based on which the system will pick up the settlement instructions from ARC settlement instructions maintenance for third party accounts, for the generation of payment messages.

Account Current Balance

The system will display the balance of the external account sent by the last MT 942 message.

Balance Update On

The system displays the date on which the last MT942 message was received.

Start Time MT920

Here, indicate the time at which the first MT920 message for a day should be generated.

End Time MT920

You need to specify the time at which the last MT920 message for a day should be generated.

MT920 Generation Frequency

Here you need to indicate the interval (in hours) at which MT920 should be generated.

Dr/(Dr and Cr) Floor Limit

Specify the debit floor limit of the account. If the credit floor limit is not separately specified, this will indicate both the debit and the credit floor limits.

This value indicates 34F tag value of MT920.

Cr Floor Limit

Specify the credit floor limit of the account. This value indicates 34F tag value of MT920.

Cutoff Time MT101

You need to indicate the time at which MT101 should be generated for sweeping in funds from the Third Party Account.

Cutoff Time MT103

You need to indicate the time at which MT103 should be generated for sweeping out funds from the Parent Account.

3.9 Account Structures

This section contains the following topics:

3.9.1 Maintaining Account Structures

In Oracle FLEXCUBE, you can define a structure for the various accounts participating in the ILM process and set up a hierarchy for the accounts - establish the relationships or links among the accounts that are to be part of the Group.

You need to define the account structure and the hierarchy for ILM processing in the ‘Account Structure Maintenance’ screen. You can invoke the ‘Account Structure Maintenance’ screen by typing ‘ILDSWEEP’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

You can define the following parameters as part of maintaining the account structure for ILM processing:

3.9.2 Indicating Account Details

Specify the following details.

Third Party Account

If the account that you have specified is a mirror account of an account held with another bank, you need to indicate it by selecting this option. If you select this option, the system will allow you to select the Technical CASA account that is linked as part of Third Party Accounts Maintenance.

Account

First, you need to specify the account (main or affiliate account) which has to be part of the account structure.

Account Type

You need to indicate whether the account that you have specified is a main account or secondary account. The account type defines the relationship between the accounts.

You will not be able to link the accounts at the same level in an account structure.

If you de-link a parent account from a structure or link it to another parent in the same structure, the associated child accounts linked to it will also follow the parent account.

Effective Date

You need to indicate the date from which the account structure is available in the system for ILM processing. However, if Intraday Sweep Batch is run for the branch for any group, you cannot change the structure on the same effective date.

Parent Account

This is applicable only if you are maintaining a child account. You need to indicate the parent account for the child here.

Note

You cannot link a child account to more than one parent account.

Booking Account

You need to indicate the account to which the interest amount is to be booked during interest reallocation (after interest is calculated).

Note

The booking account linked to the account should have the same currency as the account.

Scheme

Indicate the type of structure for which the link is being defined. The following types are possible:

Note

Interest Reallocation

Check this option to allow interest to be re-allocated to this account.

3.9.3 Maintaining Sweeping Parameters

Specify the following details.

Sweep Type

This indicates the sweep type of the parent and child account. The sweep type can be either of the following:

Base Amount

The amount depends on the sweep type that you have selected.

Multiples Amount

This indicates the multiples amount in which the system performs sweeps.

3.9.4 Indicating Pooling Parameters

Specify the following details.

Rate Type

This indicates the exchange rate type that would be used by the system to convert child account balances to the currency of the parent account. The system will not allow you to specify the rate type if you have specified the scheme as ‘Sweep’ as the system supports only single currency sweeps.

Spread Indicator

Specify which spread will be applicable - Mid or Buy/Sell. The system default value is ‘Mid’.

If you choose the ‘Buy/Sell’ option, the system applies the ‘Buy’ rate when debiting the customer account and the ‘Sell’ rate when crediting the customer account.

After defining the account structure, you can modify it as well as the Header Account linkages. You can also move accounts from one structure to another and if the account being moved is a Parent Account, all the child accounts associated with it are moved to the new structure. However, you cannot make a back-value dated change to an Account Structure.

Every change in an Account Structure or a Group–Account linkage leads to the creation of new System Accounts for the accounts in the Group. This results in the system closing the existing System Account for the accounts. But the closed records are retained to enable the system to track the history of the Account Structure and are stored based on their ‘Effective Dates’.

3.9.5 Closing Accounts in an Account Structure

The following steps explain how to close an account in a given account structure. Let us assume that, in the structure shown below, we need to close account P2 and attach account C2 directly to H1.

The steps to be followed for the closure are:

After the structure change has been carried out, the new structure appears as shown below:

In the new structure (i.e. after the change), account C2 will have a new ‘System Account’ associated with it.

Note

BVT is not applicable for a group if any of the account structure closes and BVT falls in that period.

3.9.6 Creating Group Account Linkages

You can link the account structure to the group codes that you have maintained in the ’Account Group Linkage Maintenance’ screen. You can invoke the ‘Account Group Linkage Maintenance’ screen by typing ‘ILDGRPLN’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

In this screen, you need to specify the following:

Header Account

The system will display the parent accounts maintained as part of account structure maintenance. Select the account which you want to link to the group.

Effective Date

Indicate the date on which the structure under the group should come into effect.

Group Code

Indicate the group code to which you want to link the account structure.

For example, the following structure may be defined for a Group Code ‘GRP’

HACC (Header Account)

-- PACC1 (Child to HACC)

-- CACC1 (Child to PACC1)

-- PACC2 (Child to HACC)

-- CACC2 (Child to PACC2)

-- CACC3 (Child to PACC2)

In the above structure, PACC2 is the Child Account in the link HACC – PACC2 whereas Parent Account in PACC2 – CACC.

3.9.7 Maintaining Sweeping Eligible Balance

Click on ‘Amounts & Dates’ section in ‘Customer Account Maintenance’ screen to view the current days Sweep Eligible Balance which is available for Sweep Out/ Interest Calculation.