11. Currency Maintenance

This chapter contains the following sections:

11.1 Currency Definition Maintenance

This section contains the following topics:

11.1.1 Maintaining Currency Definition

In the ‘Currency Definition’ screen, you define the attributes of the currencies in which your bank can deal. For each currency, you can define attributes like, the SWIFT code for the currency, the country to which the currency belongs, the interest method, the spot days, the settlement days, etc.

Currencies can be maintained only at the Head Office. The list of currencies will be made available to the branches based on the currencies that have been defined for the country linked to that branch.

Invoke this screen by typing ‘ ‘CYDCDEFE’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

Maintaining Currency Details

Maintenance Country

Specify the country code for which the currency is maintained. Alternatively, you can select the country code from the option list. The list displays all the authorized and open country codes along with their description maintained in the system.

For example, if you maintain the country code for a bank or a branch, which is operating in Singapore for the currency USD, then you should specify the country code as SG. The system defaults the field ‘Country’ as US.

Maintenance Country Name

The system displays the name of the country for which the currency is maintained.

Currency Code

Currencies are identified in Oracle FLEXCUBE by the SWIFT codes assigned to them. The currency will be identified by this code in all transactions that involve it.

Currency Name

You can enter the detailed name of the currency in not more than thirty-five alphanumeric characters.

Currency Type

As per your bank’s requirement you can choose to classify currencies into different currency types. The bank can use its own discretion to decide the basis of classifying currencies into different currency types. A currency type can consist of a maximum of three characters.

Depending on the customer account mask maintained, the value in the currency type field would be used during the generation of customer account numbers through the Customer Accounts Maintenance screen.

If you have decided to include currency type as part of the customer account number (in the account number mask), then at the time of creating a new customer account number, you will need to select the currency of the account number being generated. In the option-list provided for currency, the currency code is displayed along with the associated currency type say, USD – 1, GBP – 2 etc. When the account number gets populated, it is the currency type that forms a part of the customer account number.

ISO Numeric Currency Code

Specify the currency code specified by the International Standardization Organization.

Country

After you have identified the currency, you should indicate the country to which the currency belongs. You can select a country code from the option list available.

Decimals

You can indicate the number of decimal units up to which the currency can be denominated. The number of decimals allowed for any amount in the currency can be:

0 - Currency with no decimals

2 - Currency with two decimals

3 - Currency with three decimals

Interest Method

You can indicate the interest rate to be used for transactions that involve this currency. The interest options available are:

Select the interest method that should be used by default whenever the currency is used in transactions. While processing a transaction that involves this currency, the interest method defined for the currency is defaulted. You have the option to change it for a specific transaction.

However, if you do not specify an interest method for a transaction, the method defined for the currency will be used (For details refer to Annexure on Page 140).

Spot Days

The number of spot working days applicable for the currency is specified here. Payment advises for FX and MM contracts will be generated on a date, which is calculated as the number of spot working days before the Maturity Date of the contract.

For example, the tenor of an MM contract is as follows:

Value Date - 01/01/99

Maturity Date - 31/01/99

Contract Currency - USD

Contract Amount - 5000

For USD, the number of Spot Days is specified as: Spot Days - 3

For this contract, the payment advices will be sent on 28/01/96.

Foreign Exchange Netting Days

Oracle FLEXCUBE provides a facility wherein all transactions relating to a customer, meant to be settled on a particular day and are made before a specific cut off day are collated, netted and a single payment message is sent instead of individual messages for each payment. This cut off day can be parameterized and is called ‘Netting Days’. The number of FX netting days applicable for the specified currency is maintained here.

Note

The system will validate that the FX Netting days are lesser than or equal to the spot days.

Settlement Days

In this screen, you can specify the ‘Settlement Days’ for a currency. Settlement messages for the components of a contract (in the LC, BC, LD, MM, FX, and FT modules) will be generated according to the settlement days specified for the currency of the settlement account. The following example illustrates this.

For example, when maintaining the details of USD in the Currency screen, you specify the ‘Settlement Days’ as ‘2’. This implies that two working days prior to the settlement of a component through a USD account, a settlement message will be automatically generated if specified (when you run the Settlement Messages function at the end of day).

The settlement details of a contract are as follows:

Settlement Date: 06 May 1999

Settlement Account Currency: USD

Component: Principal

Settlement Message: Yes

Component Currency: GBP

When you generate the Settlement Messages function, at the end of day, on 04 May 1999, a settlement message for the Principal component of the contract will be generated.

You can run Settlement Messages function as part of EOD operations from the Application Browser to automatically generate settlement messages for contracts marked out for automatic liquidation.

The settlement day specification for a currency will determine the contracts that are picked up for settlement message generation.

Cut-off Time

The Currency Cut-off time refers to the time by which all transactions involving a currency should be generated. For a currency, you can indicate the cut-off hour and minute. This time should be expressed in the local time of the bank.

The maintenance of a cut-off time for a currency has particular reference to outgoing funds transfers involving it.

Cut-off days

You can also specify the cut-off days and time for payment transactions involving the currency.

For example, the value date of a funds transfer transaction (incoming payment) involving USD, is 3rd June 2001. The number of cut-off days specified for the currency is 2. This means that the payment must be received on or before 1st June 2001. If the payment is received on 1st June, it must be received before the cut-off time specified for USD.

If the USD cut-off time is 1200 hrs, then, if the payment is received on 1st June 2001, it must be received before 1200 hrs.

The cut-off time (in hours and minutes) that you maintain to be applicable for payment transactions involving a currency are applicable to the head office branch of your bank.

If the branches are in time zones other than the head office branch time zone, you must maintain the offset time applicable for each branch, in the Branch Parameters screen.

Note

Even when cut-off days and cut-off time for a currency have both been specified, the cut-off checks are performed for a funds transfer transaction only if specified as applicable for the product involved in the transaction.

Position or Position Equivalent GL for a currency

If you have opted for position accounting in your bank, you should indicate the Position GL and the Position Equivalent GL, when maintaining a foreign currency, in the currency screen (the Currency Definition screen).

When maintaining the GLs in your bank, you can opt to link the different foreign currencies, associated with the GL to either of the following:

Tolerance Limit

When you are maintaining an ‘In’ Currency, or the Euro, in the Currency Definition screen, you can define a ‘Tolerance Limit’ for it. The limit is expressed as a percentage.

The implication:

During the transition period, settlement of components in ‘In’ currencies can be made either in the same currency or in the Euro (EUR) depending on the settlement account(s) maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.) In the settlement messages that are generated (MT 100, MT202), the settlement amount would be reported in the Settlement Account Currency. However, you can opt to additionally furnish the value of the component in Euro Related Information (ERI) currency. You have to manually specify the settlement amount value, in the ERI currency, in the Settlement Message Details screen.

When generating the message towards settlement (MT100, MT202), the system ensures that the value you specify as the ERI Amount conforms to the Tolerance Limit defined for the ERI Currency (in the Currency Definition screen). That is, the system computes the ERI equivalent of the settling amount using the pegged rates, and compares the same against the ERI amount input by the user. If the difference is within the tolerance limits defined for the ERI currency, the user specified amount is used.

If the user specified ERI amount breaches the Tolerance Limit defined for the ERI currency, the system calculates and reports the ERI Amount on the basis of the exchange rate defined for the settlement currency vis-à-vis the ERI currency.

For example, in the SWIFT messages (MT 100 and MT 202) that are generated towards settlement, the value of the component can be reported both in Nostro account currency (in Field 32A) and in an ERI currency that you specify (in Field 72). In Oracle FLEXCUBE, this information is captured in the European Related Information (ERI) fields in the Settlement Message Details screen.

Assume the following scenario:

The settlement amount in Euro would therefore be 7692.36 (rounded to nearest higher cent). This amount will be reported in Field 32A of the settlement messages. Now, if you want to furnish the settlement amount in the ERI currency (in this case, DEM) you have to manually enter the DEM value in the ERI Amount field. You may enter DEM 10000. (EUR 7692.36 actually converts into DEM 10000.068.)

The value that you have entered is well within the Tolerance Limit of 0.05% defined for DEM. Therefore, this value will be reported in Field 72 of the settlement messages.

Since the Tolerance Limit for DEM is 0.05%, you can specify an ERI Amount between DEM 9995 and DEM 10005 (DEM 10000 * 0.05/100 = DEM 5). If you enter an ERI value exceeding DEM 10005 or less than DEM 9950, the system recalculates the ERI Amount at the time of generating the settlement messages. The recalculation will be on the basis of the pegged rates between the Settlement Currency and the ERI currency.

Note

The system validates the ERI amount only when generating the settlement messages. It does not validate the ERI amount at the time of input (in the Settlement Message Details screen).

Index Base Ccy

Specify the currency that should be used to handle index-based securities traded by the banks, wherein the deals are done in index currency and their settlement is done through the local currency.

Commodity Code

Check this box to indicate that maintained currency code is a commodity code which is restricted not to populate in payment messages during message generation in the currency code field.

Generate 103+

You can enable the MT 103 + format option only if you would like to generate outgoing MT 103 messages in the MT 103 + format.

If you are enabling this option for a specific currency, ensure to also enable this option:

Consequently, while processing transactions in the specified currency for such a customer, branch and product, for which the MT 103+ option is enabled, the system generates outgoing payment messages in the MT 103 + format.

Note

Since the system is also capable of processing incoming MT 103 messages in the MT 103 + format. Therefore, during the upload process for your branch, the system considers an MT 103 payment message to be of MT 103+ format for those customer, currency and product combinations, for which the MT 103+ option has been enabled.

CLS currency

To allow customers of your bank to settle their FX deals via the CLS (Continuous Linked Settlements) Bank, you can identify the currency to be a ‘CLS Currency’. FX deals in the CLS currency only will be eligible to be routed through the CLS bank.

From the available list of CLS currencies, you can further maintain a list of ‘allowed’ or ‘disallowed’ currencies for a specific customer. Every customer who is a ‘CLS Participant’ will be allowed to trade in all the available CLS currencies unless specifically mentioned.

Refer the ‘Continuous Linked Settlements’ chapter of the Foreign Exchange User Manual for details on maintaining currency restrictions and other maintenances required for processing CLS deals in Oracle FLEXCUBE.

Index Flag

Check this box to derive index rate of the currency in Lending module.

Validate Tag 50F

Check this box to indicate that validations need to be performed for the 50F details captured for the ordering customer during contract input.

For more details on 50F validations, refer the chapter titled ‘Maintaining Addresses for a Customer’ in Messaging System user manual.

Note

Customer cover messages are always generated in new format (MT202COV or MT205­COV).

For more details on new cover message formats, refer settlements user manual.

Indicating Rounding Preferences

Rule

This refers to the method to be followed for rounding off fractional units of a currency. The rounding preferences available are:

For example,

Amount before Rounding Rounding Method No. of Decimals Rounding Unit Amount after Rounding
1234.678 Truncate 2 - 1234.67
1234.678 Round up to the nearest rounding unit 2 .01 1234.68
1234.678 Round down to the nearest rounding unit 2 .01 1234.67

Unit

If you have selected Round Up or Round Down in the Rule field, you need to indicate the nearest unit to which the rounding should take place. The number of units specified here should not be greater than the number of decimals allowed for the currency.

Example

The decimal points specified for currency ‘A’ is 2. Rounding unit is .05

Amount for transaction is USD 100.326, which will be rounded off depending upon the decimals specified and the rounding rule and rounding unit.

For Rounding Rule ‘Up’, the amount available for transaction would be USD 100.35. For rounding rule ‘Down’, the transaction amount would have been rounded down to 100.30

If the rounding rule was specified as ‘truncate’ then, the amount would have rounded off to 100.32 (simply, knock off all decimal points beyond the stated decimals places to be rounded off). Thus whenever you specify a ‘truncate’ option you need not state the ‘Rounding unit’.

Specifying Amount Format Mask

Specify the format in which amounts in this currency are to be displayed for contracts in this currency. Two options are available:

999,999,999

9,999, 999, 99

The system defaults to the 999,999,999 format.

Euro Type

When maintaining a currency in the Currency Definition screen, you have to specify the ‘type’ of the currency with relation to transition phase of the European Economic and Monetary Union (EMU). You can do this in the ‘Euro Type’ field.

Your specifications in this field enable you to handle the first phase of the EMU, which commenced on 01 January 1999.

For more details on the manner in which Oracle FLEXCUBE handles the Euro, refer the chapter ‘Handling the Euro’.

By choosing the appropriate option, you can indicate if the currency is:

National currencies of ‘In’ countries are referred to as ‘In’ currencies. When maintaining other currencies, you have to choose the ‘Out Ccy’ option under Euro Type.

When the transition period ends, the national currencies of the participating countries would cease to exist as valid legal tenders. The Euro would be the only legal tender in the participating countries. Consequently, the Euro changes made to Oracle FLEXCUBE will no longer be required.

You can turn off the changes at the end of the transition period by:

  1. Closing all ‘In’ currencies, and
  2. Choosing the ‘Euro Closed’ option (for the Euro)

11.1.2 PC Button

Click ‘PC’ button in the Currency Definition screen to invoke ‘Limits’ screen.

You can specify the credit limit and the debit limit for the exchange rate in this screen. The transaction amount of a PC contract must not exceed the limit specified here.

11.1.3 Currency Country Mapping Button

Click ‘Currency Country Mapping’ button in the Currency Definition screen to invoke ‘Clearing Zones Country Codes for Currency’ screen.

The screen appears as shown below:

You can map a currency code to a country in this screen.

Currency Code

The system displays the currency code maintained in the system.

Maintenance Country

The system displays the maintenance country for the currency.

Maintenance Country Name

The system displays the name of the country for which the currency is maintained.

Country Code and Description

Country Code

Specify the clearing zone country code. Alternatively, you can select the country code from the option list. The list displays all the country codes maintained in the system.

Country Name

The system displays the name of the clearing zone country.

11.1.4 Fields Button

You can associate values to all the User Defined fields created and attached to the Currency Definition Screen. You can view the list of User Defined fields associated by clicking the ‘Fields’ button.

The screen appears as shown below:

You can enter the value for the UDFs listed here in the ‘Value’ column.

For more details on how to create user Defined fields, refer chapter ‘Creating custom fields in Oracle FLEXCUBE’ in the User Defined Fields User Manual under Modularity.

11.1.5 Annexure

The treatment for interest calculation varies with each of the interest calculation methods. Each method is dealt with individually below:

Actual/Actual Method

10,000x10/100 x (31/365 + 84/366)

In this method, the number of days is calculated as follows:

Dec. -31 days (include from date exclude to date)

Jan -31 days

Feb.-29 days (leap year)

March - 24 days (include from date exclude to date)

Total = 31 + (31+29+24=84) =115

Note

When the interest period crosses from a non-leap year to a leap year (or otherwise), the basis of actual days has to be treated separately in each year.

Therefore, the denominator for the 31 days in December is 365 as it is a non-leap year and the denominator for the 84 days in 2000 is 366 as it is a leap year.

Actual /365 Method

10,000x10/100x115/365

In this method, the number of days is calculated as follows:

Dec. -31 days (include from date exclude to date)

Jan -31 days

Feb.-29 days (leap year)

March - 24 days (include from date exclude to date)

Total=31+31+29+24=115

Actual/360 Method

10,000x10/100x115/360

In this method, the number of days is calculated as follows:

Dec. -31 days (include from date exclude to date)

Jan -31 days

Feb.-29 days (leap year)

March - 24 days (include from date exclude to date)

Total=31+31+29+24=115

30 Euro/Actual Method

10,000x10/100 x (30/365+84/366)

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)

Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)

March - 24 days (include from date exclude to date)

Total = 113 days

Note

When the interest period crosses from a non-leap year to a leap year (or otherwise), the basis of actual days has to be treated separately in each year.

30 Euro/365 Method

10,000x10/100x114/365

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)

Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)

March - 24 days (include from date exclude to date)

Total = 113 days

30 Euro/360 Method

10,000x10/100x114/360

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 Euro Method, all months have 30 days, February included.)

Feb. - 30 days (In 30 Euro Method, February always has 30 days, leap year or not)

March - 24 days (include from date exclude to date)

Total = 113 days

30 US/Actual Method

10,000x10/100 x (30/365+84/366)

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual number of days calculated.)

Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)

March - 24 days (include from date exclude to date)

Total = 113 days

Note

When the interest period crosses from a non-leap year to a leap year (or otherwise), the basis of actual days has to be treated separately in each year.

30US/365 Method

10,000x10/100x114/365

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual number of days calculated.)

Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)

March - 24 days (include from date exclude to date)

Total = 113 days

30US/360 Method

10,000x10/100x114/360

In this method, the number of days is calculated as follows:

Dec. - 30 days (include from date exclude to date)

Jan - 30 days (In 30 US Method, all months have 30 days, only for February are the actual number of days calculated.)

Feb. - 29 days (In 30 US Method, actual days are accounted for the leap year.)

March - 24 days (include from date exclude to date)

Total = 113 days

11.1.6 Viewing Currency Summary Details

You can view currency summary details in the ‘Currency Summary’ screen. You can invoke this screen by typing ‘CYSCDEFE’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

 

In the above screen, you can base your queries on any or all of the following parameters and fetch records:

Click ‘Search’ button. The system identifies all records satisfying the specified criteria and displays the following details for each one of them:

11.2 Specifying Currency Cut-Off Parameters

You can choose to restrict the time within which (or before which) funds transfer transactions involving a specific customer, product, and a currency, must be received for processing. For a specific customer, product, and a currency, you can specify a certain number of days before which a transaction involving the combination must be received, as well as a cut-off time before which transactions must be received. These parameters are known as currency cut-off parameters, and you maintain these parameters in the ‘Value Dated Spread’ maintenance screen.

Invoke this screen by typing ‘FTDVDSPR’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button. The screen is as shown below:

In this screen, you can maintain the cut-off time, cut-off days and the value spreads to be applicable for:

These currency cut-off parameters are validated in respect of a funds transfer transaction only if currency cut-off checks are specified as applicable in the product preferences, for the product involving the transaction.

For details about how the currency cut-off checks are applied on a funds transfer transaction, refer the chapter ‘Processing a Funds Transfer Contract’ in the Funds Transfer User Manual.

11.3 Handling Euro

This section contains the following topics:

11.3.1 Maintaining Euro Related Information

On 1 January 1999, eleven countries that are part of the European Union embarked on the first phase of economic integration, called the ‘Economic and Monetary Union’ (EMU). In Oracle FLEXCUBE, the eleven countries participating in the first phase of the EMU are referred to as ‘In’ countries and the respective national currencies as ‘In’ currencies. All other countries are referred to as ‘Out’ countries.

The first phase of the EMU, referred to as the ‘transition period’, ushered in a new, single European currency: the Euro (EUR). During this phase, the National Currency Denominations of ‘In’ countries would co-exist with the Euro. That is, transactions involving an ‘In’ currency would, typically, be routed through the Euro during this phase. At the end of the transition period, in mid 2002, however, the national currencies of the participating countries would cease to exist as valid legal tenders. The Euro would be the only legal tender in ‘In’ countries.

In Oracle FLEXCUBE, you can handle the Euro and the attendant implications for your bank, by capturing additional currency and settlements related information. This chapter details how this information is to be captured, and its implications.

In Oracle FLEXCUBE, the details that you need to maintain in order to handle the EMU include:

You can maintain currency related information in the Currency and the Currency Pair Definition screens. ‘Settlement’ details can be captured in the Settlement Instruction Details screen.

11.3.1.1 Maintaining Currency Details

Your specifications for a currency in the Currency Definition screen determine the manner in which transactions in the currency are handled in Oracle FLEXCUBE.

Currency Type

When maintaining a currency in the Currency Definition screen, you have to specify the ‘type’ of the currency. You can do this in the ‘Euro Type’ field. Choose the appropriate option from the following:

National currencies of ‘In’ countries are referred to as ‘In’ currencies. When maintaining other currencies, you have to choose the ‘Out Ccy’ option under Euro Type.

When the transition period ends, the national currencies of the participating countries would cease to exist as valid legal tenders. The Euro would be the only legal tender in the participating countries. Consequently, the Euro changes made to Oracle FLEXCUBE will no longer be required.

You can turn off the changes at the end of the transition period by:

Tolerance Limit

When you are maintaining an ‘In’ Currency, or the Euro, in the Currency Definition screen, you can define a ‘Tolerance Limit’ for it. The limit is expressed as a percentage.

The Implication:

During the transition period, settlements of components in ‘In’ currencies can be made either in the same currency or in the Euro (EUR) depending on the settlement account(s) maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.) In the settlement messages that are generated (MT 100, MT202), the settlement amount would be reported in the Settlement Account Currency. However, you can opt to additionally furnish the value of the component in Euro Related Information (ERI) currency. You have to manually specify the settlement amount value, in the ERI currency, in the Settlement Message Details screen.

When generating the message towards settlement (MT100, MT202), the system ensures that the value you specify as the ERI Amount conforms to the Tolerance Limit defined for the ERI Currency (in the Currency Definition screen). That is, the system computes the ERI equivalent of the settling amount using the pegged rates, and compares the same against the ERI amount input by the user. If the difference is within the tolerance limits defined for the ERI currency, the user specified amount is used.

If the user specified ERI amount breaches the Tolerance Limit defined for the ERI currency, the system calculates and reports the ERI Amount on the basis of the exchange rate defined for the settlement currency vis-à-vis the ERI currency.

The following example illustrates the application of the Tolerance Limit.

Note

The system validates the ERI amount only when generating the settlement messages. It does not validate the ERI amount at the time of input (in the Settlement Message Details screen).

Currency pairs

In the Currency Pair Definition screen, you can specify a ‘Through Currency’. When maintaining a pair involving an ‘In’ currency (‘In’ – ‘Out’ and ‘In’ – ‘In’), you can only specify the Euro as the ‘Through Currency’.

Note

You cannot maintain a ‘Through Currency’ for a pair constituted by an ‘In’ currency and the Euro.

11.3.1.2 Maintaining Conversion GLs

To facilitate the currency conversion process, two additional parameters need to be maintained in the ‘Branch Parameters’ screen. You have to maintain a common Conversion GL and a Transaction Code that identifies redenomination entries.

The screen is as shown below:

Indicating Euro Redenomination General Ledger

Conversion GL

The conversion GL that you specify will be identified as the common Suspense GL for all balance conversions while re-denominating the currency of an account either for specific customers or for generic conversions.

Transaction Code

In addition to the conversion GL, you have to indicate a Transaction Code, which identifies conversion related entries.

11.3.1.3 Implications of Currency Redenomination

In the IC Product Accounting Role Definition screen

For the purpose of currency conversion, an accounting role called ‘Acquired’ is available.

End of day processes

Maintaining a Conversion GL and Transaction Code simplifies the End of day process. Basically two important things happen when the End of day processes are run. Firstly interest is liquidated to the Acquired Interest GL and secondly all balances will be reduced to zero.

When you run the Beginning of day processes the next day the change in the currency conversion will be in place. In addition balances will get restored.

Change in field values due to conversion

The change in currency re-denomination impacts amount based fields pertaining to Accounts, Collaterals, Credit Lines and Customer Limits. The change in the value of these fields is reflected when you run the beginning of day processes.

The amount-based fields, which are affected by the change in currency denomination, will be updated with the equivalent value in the new currency

Accounts

The following fields will reflect the new values:

These fields can be found in the Customer Accounts Maintenance screen.

Collateral

In the Limits Maintenance Collaterals screen the following fields will be updated:

Credit Lines

In the Limits screen of the Limits Maintenance module the following fields will reflect the new values:

Customer Limits

In the Customer Maintenance screen of the Core Services module the following fields will be updated at BOD.

Note

Once the conversion process is complete the advices generated for your customer will car­ry the following information:

As a consequence of currency re-denomination you will not be able to pass entries where the value date falls before the currency conversion date.

11.3.1.4 Specifying Preferred ERI Currency for Counterparty

For a counterparty and currency (combination), you can maintain a preferred ERI currency. You can state this preference in the ‘Settlement Instructions’ screen.

The Implication

During the transition period, settlements of components in ‘In’ currencies can be made either in the same currency or in the Euro (EUR) depending on the settlement account(s) maintained. (Similarly, components in Euro can either be settled in EUR or in an ‘In’ currency.) In the settlement messages that are generated (MT 100, MT202), the settlement amount would be reported in the Settlement Account Currency. However, you can opt to additionally furnish the value of the component in Euro Related Information (ERI) currency. You can maintain this ERI currency (for a counterparty and currency combination) in the ‘Settlement Instructions Maintenance’ screen.

In the SWIFT messages that are generated towards settlement of a component (involving the counterparty and the currency), the component value will be expressed in this (ERI) currency, by default. Invoke this screen by typing ‘ISDINSTN’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The screen is as shown below:

11.3.1.5 Specifying Settlement Message Details

SWIFT messages (MT 100/MT202) generated towards settlement can furnish the value of the settlement amount in both the settlement account currency, and an ‘ERI’ currency. If you opt to furnish the ERI value of the amount, you have to enter the following in the ‘Settlement Details’ screen:

The screen appears as shown below on clicking ‘Settlements’ button in the contract screen:

The system defaults to the ERI currency specified for the customer and currency combination. You can change the default ERI currency. The ERI amount that you specify will be validated against the Tolerance Limit specified for the ERI currency.

11.3.1.6 Settlements of Foreign Exchange Deals

Oracle FLEXCUBE allows cross currency settlements of foreign exchange deals that involve an ‘In’ currency. You can settle the ‘In’ currency leg in another ‘In’ currency or in ‘Euro’.

11.3.1.7 Reports and Advices

The following reports furnish the equivalent Euro values of amounts in an ‘In’ currency. The ‘locked in’ exchange rates defined for the Euro against the ‘In’ currency will be used for currency conversions.

The reports with this feature are the:

Note

These reports will not furnish the ‘In’ currency and equivalent Euro values when you close the ‘In’ currencies, and choose the ‘Euro Closed’ option (for the Euro) in the Currency Definition screen.

All advices that provide ‘In’ currency details will also provide the equivalent Euro values

Account Statements

Statements provided for accounts in an ‘In’ currency provide the Euro equivalent values of the following:

11.3.2 Maintaining Limits Type

You can maintain various limit types and their values through the ‘Limits Types Maintenance’ screen. For example, you can define and maintain various Limit types like price codes, collateral types and price through this screen.

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

The screen is as shown below:

Type

Specify the limit type for which you want to maintain values

Description

Specify the description for the limit type you are maintaining

Values

The values for the limit type that you are maintaining can be listed here. To add a value to the list of values, click on the ‘Add’ icon, and type the value. To remove a value from the list of values, check the box against that value and click on the ‘Delete’ icon.

Value

Specify the list of supported values. For example, MAIL, COURIER, BRANCH and so on.

Code

Specify the codes for the list of value. For example, CO, ML and so on.

11.3.3 Maintaining Transaction Limits

This section explains in detail about maintaining transaction limits, level of authorisations required for the transaction amounts and minimum user authorisation limit required for a transaction.

Oracle FLEXCUBE offers you a facility, whereby, each time a particular transaction processed in the system exceeds a certain limit; an override will be generated by the system.

You can maintain transactional limits for a module and product combination through the ‘Product Transactional Limits Maintenance’ screen. Invoke this screen by typing ‘CSDPLMNT’ in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The screen appears as shown below:

Module Identification

Each module in Oracle FLEXCUBE is identified by a code. First, you have to identify the module for which the currency-wise transactional limit is to be maintained. A list of all the modules operational at your bank will be displayed in the option list. You can choose the appropriate module code.

Module Description

The description associated with the module will be defaulted in the adjacent field.

Product Code

Each module contains a number of products within it. After you identify the module, indicate the product within the module for which you would like to maintain a currency-wise transactional limit. You can select the appropriate product code from the option list.

In the Product Transactional Limits screen, you can maintain the limits for:

Product Description

The description associated with the module will be defaulted in the adjacent field.

Source Code

Specify the source code based on which you need to maintain the product transactional limits. The adjoining option list displays all valid source codes. The transaction limit amount maintained for the selected source code is used to validate transaction limit while authorizing the contract.

If the source code is available in Oracle FLEXCUBE, then the system enables all the fields available under ‘Product Transaction Limit Details’ multi grid.

If the source code external, then the system enables only ‘Transaction Limit’ available under ‘Product Transaction Limit Details’ multi grid.

Note

You cannot select a source code more than once.

Transaction Limit Currency

The transaction limit currency is the currency in which you would like to maintain the amount limit.

Customer Type

Select the type of customer for whom you are maintaining the transaction limits from the adjoining drop-down list. The following are the options available:

Customer Group

Specify the customer group to which the authorization matrix is applicable. Alternatively, you can select the customer group from the option list. The list displays all the customer group maintained in the system.

Role Based Authorization

Check this box to authorize the transaction based on the roles defined in ‘Authorization Role Mapping’ section.

If you select this check box, it is mandatory to define authorization rules in the ‘Authorization Role Mapping’ section.

Follow Sequence

Check this box to follow a sequence during various levels of multiple authorization of a transaction. This field is enabled if the ‘Role Based Authorization’ is checked.

Product Transaction Limit Details

Specify the following transaction limit details:

Transaction Limit

Specify a transaction limit. Each time you process a transaction, the system checks the transaction amount involved in the contract against the limit specified here. If the contract currency is different from the transaction limit currency, then the system converts the contract amount using the standard mid rate to the transaction limit currency and check against the transaction limit amount maintained for the product

The system displays an appropriate message indicating the levels of authorization if the transaction amount booked is in excess of the maintained transaction limit.

Level Of Authorization

Specify the levels of authorization to be involved in the authorizing a particular transaction amount.

Note

The level of authorization should be greater than one. If the number of authorization levels are greater than five, the system displays an error message.

Minimum Authorization Limit

This option is enabled only if the ‘Cumulative’ option is checked. Specify the minimum authorization limit required for a transaction. The authorization limit cannot be greater than the transaction limit. This amount is used to validate authorizer limit while authorizing the contract.

Cumulative

Check this option to indicate that multiple authorisers are allowed to authorise a transaction. The authorisers must have equal or greater than the minimum authorization limit maintained in this screen. The system displays an appropriate error message if the authoriser tries to authorise a transaction having transaction amount greater than the minimum authorising limit.

This field is not applicable if you check the ‘Role Based Authorization’ check box,

Authorization Role Mapping

Authorization Rule

The system displays the authorization rule maintained in the system. The list displays the following values:

Level 1

Specify the user role eligible to authorize the transaction in the first level.

Level 2

Specify the user role eligible to authorize the transaction in the second level.

Level 3

Specify the user role eligible to authorize the transaction in the third level.

Level 4

Specify the user role eligible to authorize the transaction in the fourth level.

Note

For Primary rule, you should specify the role for at least one level.

11.3.3.1 Validating Transaction Amount during Contract Processing

While saving a contract, the system will check the transaction amount against the cut-off amount maintained for the module and product currency involved in the transaction. If both the transaction currency and the limits currency are same, the comparison will be done directly. If different currencies are involved, the system will first convert the transaction amount into the cutoff amount currency using the STANDARD mid rate and then perform the validations.

To perform the check, the System will look for the limits maintained, in the following order:

  1. The System looks for the limits maintained for a specific module and specific product combination
  2. If the first option is not available, it checks the limits maintained for a specific module + ZALP (all products) combination
  3. It checks the maintenance for AL (all modules) + ZALP (all products) combination

If the third option is also not available, the system displays an error message

When a transaction exceeds the amount limit, the system displays an override message while saving the transaction

11.4 Maintaining Sequence Generation Format

Every contract in Oracle FLEXCUBE is identified by a unique Contract Reference Number that is generated internally by the system. You are not allowed to modify this number. In addition, a contract is also identified by a unique User Reference Number. By default, the Contract Reference Number will be taken as the User Reference Number. But you have the option to change the User Ref Number.

Oracle FLEXCUBE also provides you the facility to generate the user reference number in a specific format.

To maintain a specific format, you need to identify the various components that would be part of the user reference number including details such as the length, order, value etc. of each component.

You can maintain a unique format through the ‘Sequence Generation Input’ screen. You can invoke this screen by typing ’ ‘CSDSQGEN’in the field at the top right corner of the Application tool bar and clicking the adjoining arrow button.

The screen appears as shown below:

You can maintain the following details of the sequence format:

Sequence Code

Each sequence format is identified by a unique sequence code. You can devise a code comprising a maximum of 20 alphanumeric characters.

Branch Code and Module Code

You can maintain the format for a specific branch and module combination. Select the branch code and the module code from the option-list. All authorized and active records will be displayed in the list.

Alternatively, you can maintain a sequence format that will be applicable to all the branches (ALL) and all the modules (AL) available in your bank.

Reset Frequency

You need to specify the frequency at which the system will drop and recreate the sequence numbers once again. At the reset frequency that you specify, all sequence numbers of the sequence format will be dropped and recreated again during the End of Day processing.

The options available are:

For example, let us assume that the running number in the sequence format is 4 characters long (starting from 0001) and the reset frequency is Monthly. Further, let us assume that the sequence number of the last contract processed on the last day of the month is 0199. At EOD of the last day of the month, the sequence numbers generated till date will be dropped and the system will begin regeneration starting from 0001 once again for all subsequent contracts.

Range

You can specify a range of sequential reference numbers. If you specify such a range, then no additional details need be specified. If you do not specify a range, you can specify additional details specific to each component of the sequence format.

In addition to the above details, you should also maintain details specific to each component of the sequence format. The details are as follows:

Component Order

Each component is assigned an order number based on which they would appear in the user reference number. The component order is automatically generated by the system and is non-editable.

Component

Each component in the sequence format is identified as one of the following:

Component Type

You need to identify the type of each component in the sequence format. A component can be constant through out or change for every contract processed at your bank. You can associate a component with one of the following types:

Use in Sequence Generation

You need to indicate whether the component being defined should be used in sequence generation or not. Specify ‘YES’ or ‘NO’ as per your choice.

You can also choose to display the reference number in the advices that are generated for a contract.

Component Length

You can also specify the length of each component in the sequence format. The component value is dependent on the component length maintained. For instance, if you specify 2 as the component length, the value should comprise of only two characters.

Component Value

As stated earlier, the component value is dependent on the component length. Based on the length, you can specify a value comprising of as many characters as specified in the Component Length field. However, this field is used only if the value of the component is required to be constant (static type) in all the user reference numbers generated at your bank. If the component value is changing constantly (Dynamic type) for every contract, the system will automatically pick up the value from the DB table based on the SQL query that you maintain for the purpose.

Component Column and Component Table

If your component is of the dynamic type, you will need to mention the name of the Oracle FLEXCUBE column from where the system will pick up the component value. Further, if you wish to include a manipulated column value in sequence generation, you will need to include ‘SUBSTR’ as well in the column name. For eg, to include only the first four characters of the product group associated with the product code involved in a contract, you will specify the following in the Component Column field:

SUBSTR (PRODUCT_GROUP, 1, 4)

You need to mention the table name also, if the component type is dynamic. The following table names are available in the option-list provided.

For our example, the table name would be CSTM_PRODUCT.

Component Where Clause

The condition or the ‘where clause’ of the SQL code is specified here. In the example discussed above, the system will pick up the appropriate product group depending on the product code involved in the contract being processed. You can specify the following where clause as an extension of the SQL statement specified earlier:

WHERE PRODUCT_CODE = SUBSTR (P_CRN, 4, 4);

Click add icon to define each subsequent component in the format. Use the navigating icons to move between the various components of a sequence format.

11.5 Maintaining Corporate Deposits Currency Limits

You can invoke the ‘Corporate Deposits Currency Limits Maintenance’ screen by typing ‘CSDXCCLM’ in the field at the top right corner of the Application tool bar and clicking on the adjoining arrow button.

The ‘Corporate Deposits Currency Limits Maintenance’ screen is shown below:

You can specify the following here:

Start Date

You need to specify the period for which the limit maintenance is applicable. Select the start date of the period here.

End Date

You need to specify the period for which the limit maintenance is applicable. Select the end date of the period here.

Type

Select the type of fund flow to which the limit should be applied.

Customer Number

Specify the CIF of the customer for whom the currency limit should be applied. You can select the appropriate CIF from the option list.

Currency

Specify the currency code for which the limit should be applied. You can select the appropriate currency code from the option list.

Limit Amount

Specify the limit amount. The customer will be allowed to transact using the selected currency for a maximum of this limit amount.

Amount Utilized

The system displays the amount that has already been utilized by the customer.

Once you have captured the details, save the maintenance.