12. Defining a Deal Preference Class

12.1 Introduction

Preferences are the options available for defining the attributes of a deal. Preferences are based on the type of deal you define such as Bank portfolio buys and sells, customer buys and sells, standalone lodge and withdraw, safe keeping location (SKL) to SKL transfer and block securities. The following are some of the preferences that you can define:

A set of such preferences can be grouped together into what is called in Oracle FLEXCUBE, a Preference Class. You can maintain several deal preference classes. The preferences that you define will give a deal distinctiveness unique to the type it represents.

The advantage of Defining a Portfolio Preference Class

While creating a deal product, instead of specifying preferences for each product, you only need to associate the appropriate deal preference class to the product. All the attributes defined for the class will be by default, applicable to the deal product. You can change the preferences that are defaulted, to suit the deal product.

Note

Once defined, a deal preference class can be made applicable to any number of products.

This chapter contains the following sections:

12.2 Deal Preferences Class

12.2.1 Specifying the Deal Preferences Class

You can invoke the Deal Preference Class Maintenance screen from the Application Browser. The Deal Preference Class Maintenance Detailed screen is displayed without any details. If you are setting up a new deal preference class, click ‘New’ from the screen tool bar.

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

After you have defined a deal preference class, click save icon from the tool bar to save the record. Click ‘Exit’ to exit the screen. You will be returned to the Application Browser.

12.3 Features of the Screen

This section contains the following topics.

12.3.1 Identifying a Deal Preference Class

Class Code

In Oracle FLEXCUBE, each Deal Preference Class that you maintain is identified by a unique ten-character code called a Class Code. You can follow your own convention for devising this code, however, one of the characters of the code should necessarily be a letter of the English alphabet.

Description

You can specify a short description that will enable you to identify the deal preference class easily.

The short description that you specify is for information purposes only and will not be printed on any customer correspondence.

Deal Leg Type

Each deal type has characteristic features that are unique to the type. Certain deals also have two legs, a buy and a sell leg. A deal preference class that you set up can cater to a particular leg (buy or sell) of a deal. You can indicate the deal leg type for which you are setting up preferences.

You can select one of the following from the picklist:

By indicating the leg type, you restrict the application of the class to products of the same type. For instance, you can associate a Deal Preference Class of the Leg Type Bank sell, only with products that cater to the selling of securities by the bank.

12.3.2 Exchange Rate Type

You can specify the exchange rates that are to be used when a deal involving a foreign currency, is processed. This is done, by specifying the Rate Type to be used in a deal.

When a deal involves a currency conversion, the Rate Type that you defined will be picked up by default and applied. This defaulted rate type can be changed at the time of processing a deal.

You can define an exchange rate variance (the upper and lower limit), within which the exchange rate can differ from the rate type that is defaulted.

12.3.3 Brokerage Allowed

You can choose to allow or disallow brokers, for a deal that you enter. Brokerage is applicable only for bank buy or sell type of deals. As a preference, you can indicate whether brokerage is applicable to the class you are defining. If you allow brokerage, you can enter deals that may or may not involve brokers. If you disallow brokerage for the product, then the product cannot be associated with deals that are struck through a broker.

To allow brokers, check against this option. To disallow brokers, leave it unchecked.

When a deal involving a broker is processed, the brokerage applicable to the broker will be picked up and applied from the Brokerage maintenance.

12.3.4 Automatic Money Settlement

Money settlement for security deals can be liquidated automatically or manually. While setting up a deal preference class, you can indicate the mode of money settlement. It could be one of the following:

Check against this option, to indicate that money settlement should be automatic. Leave it unchecked to indicate manual settlement.

If you specify the automatic mode of money settlement, deals involving a product to which the class is applied will be automatically settled, on the settlement date.

If the money settlement date falls on a holiday

If the money settlement date of a deal falls on a holiday, the deal will be settled depending on your specifications, in the Branch Parameters screen.

12.3.5 Extension Allowed

You can choose to allow extension of the Settlement Date for deals involving a product to which, a preference class is applied. Check against this option, to allow extension of the settlement date. Leave it unchecked to disallow extension.

This feature is useful when you need to extend the settlement date for the deal. You need not enter a new deal for the extension period but simply amend the settlement date of the deal to a future date.

For example, the settlement date of a deal is 1 April. You need to extend the settlement date of the deal by two days. If you have allowed extension of deal for the product, you can settle the contract on 3 April.

12.3.6 Rekey Requirements

All operations on a deal, (input, amendment, modification, etc.) have to be authorised by a user other than the person who carried out the operation. They need to be authorized before the End of Day operation commences. Authorization is a method of checking the entries made by a user.

As a cross-checking mechanism to ensure that the right deal is invoked for authorization, you can specify that the values of certain fields should be entered, before the other details are displayed. The complete details of the deal will be displayed only after the values to these fields are entered. The fields for which the values have to be given are called the re-key fields.

You can specify any or all of the following as re-key fields:

If no re-key fields have been defined, all details of the deal will be displayed when the authorizer calls the deal for authorisation. The re-key option also serves as a means of ensuring, the accuracy of inputs.

For example, suppose that a user enter a deal to sell 100 units of a bond that belongs to the customer portfolio PF01. The deal involves a product for which the re-key field assigned is the Portfolio ID.

Now, the user makes a mistake and enters the Portfolio ID as PF02.

The authorizer selects the deal for authorization and indicates the re-key field of Portfolio ID as PF01. The details of the deal will not be displayed.

When this happens, the authorizer can inform the user of the mistake and it can be rectified.

The deal details will not be displayed if:

It could also be that the user had correctly captured the Portfolio ID as PF01 but the authorizer made an error while entering the re-key value. In such a case also, the details of the deal will not be displayed for authorisation.

12.3.7 Specifying Other Preferences

Besides the above preferences, you can also specify the following: